티스토리 뷰
앞서 1편에서는 대표와 기획자 사이에 존재하는 역할·권한·책임의 차이를 살펴보며, ‘설득’이라는 접근 자체가 왜 기획자의 본질과 어긋나는지 다뤘습니다. 이제 그 연장선에서, 기획자가 실제로 어떤 방식으로 대표의 방향을 해석하고 실무적으로 구현해야 하는지를 구체적으로 살펴볼 차례입니다.
대표가 말하는 방향성은 종종 모호하고 추상적입니다. 하지만 그 모호함을 구체적 구조로 바꾸는 것이 바로 기획자의 일입니다. 이번 편에서는 대표의 아이디어를 조직이 움직일 수 있는 언어로 번역하는 과정, 그리고 대표와의 충돌을 방지하면서도 기획자로서 전문성을 지키는 방법에 대해 깊이 있게 다뤄보겠습니다.
3. 기획자의 역할은 대표의 방향성을 ‘구체화하는 것’이다
기획자의 핵심 역량은 ‘판단’이 아니라 ‘구조화’입니다. 대표가 제시한 방향성이나 아이디어는 종종 추상적이고 두루뭉술할 수 있는데, 이는 대표의 역량이 부족해서가 아니라 비전과 전략을 이야기하는 위치가 원래 그렇기 때문입니다. 이때 기획자는 대표의 생각을 현실에서 동작할 수 있는 계획, 기능, 흐름으로 번역하는 사람이 되어야 합니다. 아이디어를 실제 서비스로 구현 가능한 언어로 바꾸고, 필요한 리소스와 리스크를 계산하고, 스펙을 만들고, 조직과 커뮤니케이션하는 것이 바로 기획자의 업무입니다. 즉, 대표의 생각이 완벽하길 바라는 것이 아니라, 불완전한 상태의 입력값을 더 정제된 산출물로 만들어내는 것이 기획의 본질입니다. 설득보다 중요한 것은, 주어진 방향을 어떻게 ‘되게 만들 것인가’입니다.
3-1. 기획자의 핵심 임무는 ‘판단’이 아니라 ‘구조화’다
많은 주니어 기획자들이 “기획자가 서비스의 방향성을 결정한다”는 환상을 가지고 있습니다. 하지만 현실에서 기획자의 핵심 능력은 ‘판단력’이 아니라 구조화 능력입니다. 대표나 사업 리더가 제시하는 방향성은 종종 추상적이고, 개념적이며, 표현이 모호할 때가 많습니다. 그러나 그 모호함은 업무 능력이 부족해서 나타나는 것이 아닙니다. 대표는 ‘전체적인 그림’을 이야기하는 사람이기 때문에 자연스럽게 큰 개념, 철학, 방향성 중심의 언어를 사용할 수밖에 없습니다.

이때 기획자가 해야 하는 일은 대표의 말을 논박하거나 정확성을 따지는 것이 아닙니다. 기획자의 역할은 추상적인 아이디어를 현실에서 실행 가능한 형태로 변환하는 것입니다. 대표가 제시한 방향성을 기능으로 쪼개고, 유저 플로우로 만들고, 데이터 수집 포인트로 나누고, 리스크 포인트를 분석해 완성도 높은 서비스 로직으로 정리하는 것. 즉, 기획자의 본질은 ‘판단의 주체’가 아니라 ‘번역의 주체’입니다.
조직 전체가 움직일 수 있는 언어로 방향성을 해석하고, 필요한 작업을 구체화하는 능력이 기획자의 가치입니다. 이 지점을 이해한 순간, 기획자는 더 이상 대표의 의견을 바꾸는 데 에너지를 쓰기보다, 그 의견을 어떻게 가장 효율적이고 안전하게 실현할지를 고민하는 단계로 성장하게 됩니다.
3-2. 기획자는 대표의 언어를 ‘조직이 움직일 수 있는 언어’로 바꾸는 번역자다
기획자에게 가장 중요한 능력 중 하나는 대표의 언어를 조직이 이해할 수 있는 형태로 옮기는 번역 능력입니다. 대표가 말하는 방향성과 비전은 종종 감각적이고 간결합니다. “UX를 더 직관적으로 만들자”, “커뮤니티 활성화를 강화하자”, “리텐션을 올리자” 같은 말들이 그 예입니다. 하지만 이런 말은 의도를 전달하는 데는 충분하지만, 실제로 개발팀·디자인팀·운영팀이 움직이는 데 필요한 단위가 아닙니다. 이때 기획자가 해야 할 일은 그 모호한 표현을 구체적이고 실행 가능한 스펙으로 번역하는 것입니다.
앞서 말한 예시라면, “리텐션 올리자”는 말은 결국 “유저가 서비스를 다시 찾도록 만드는 경험 설계가 필요하다”는 의미입니다. 이를 다시 세분화하면 퍼널 분석, 빈도 분석, 알림 전략 재정비, 콘텐츠 퀄리티 리빌딩 등 다양한 실체적 활동으로 나누어질 수 있습니다. 즉, 기획자는 대표가 제공한 ‘방향성의 입력값’을 설계도, 기능 로직, 정책 문서, 플로우 차트 같은 ‘조직이 움직일 수 있는 출력값’으로 바꿔주는 역할을 합니다.

이 과정에서 기획자는 단순 전달자가 아니라 해석자이며 조율자가 됩니다. 오해를 줄이고, 의도를 명확히 하며, 실제 실행 가능한 구조를 만드는 사람이 바로 기획자입니다. 결국 기획자의 가치는 설득이 아니라 번역의 정확도에서 나옵니다.
3-3. 대표의 의도는 존중하고, 방법론은 기획자가 정교하게 설계해야 한다
대표가 제시하는 방향성이 언제나 완벽한 것은 아닙니다. 하지만 중요한 점은, 방향성이 완벽하지 않다는 이유로 그것을 ‘틀렸다’고 정의하고 바꾸려 드는 것이 기획자의 역할은 아니라는 사실입니다. 대표의 의도는 회사가 나아가야 할 큰 흐름을 의미하며, 그 의도를 현실에서 가장 효과적으로 구현하는 방법을 찾는 것이 기획자의 역할입니다. 즉, 방향은 대표가 정하고, 방법은 기획자가 만든다가 더 정확한 표현입니다.
대표가 “탈퇴율을 줄이자”고 말하면, 그 목표 자체는 그대로 존중해야 합니다. 하지만 이를 실행하는 방법 -탈퇴 사유 수집 방식, UX 흐름 개선, 리스크 안내 방식 등- 은 기획자가 더 정교하고 논리적으로 설계할 수 있습니다. 대표의 말은 ‘결정’이 아니라 ‘의도’이고, 기획자의 기획은 ‘반박’이 아니라 ‘구체화’입니다.

이 역할 구분이 명확해질 때 기획자는 대표와 갈등하는 대신 대표와 협력하게 되고, 대표에게 인정받고 신뢰를 얻는 방식도 설득이 아니라 완성도 높은 실행 구조에서 나오게 됩니다. 기획자가 대표의 의도를 무시하거나 수정하려 들면 갈등이 생기지만, 대표의 의도를 존중하면서 더 나은 설계로 보완할 때 기획자는 팀 내에서 가장 강력한 영향력을 발휘하게 됩니다. 즉, 성숙한 기획자는 대표의 생각을 ‘바꾸는 사람’이 아니라, 그 생각을 ‘현실에서 작동 가능하게 만드는 사람’입니다.
4. 대표의 의견을 꺾으려 할 때 발생하는 조직적 충돌
대표의 의견에 정면으로 반기를 드는 순간, 기획자는 단순한 의견 충돌을 넘어 권한의 충돌을 만들어냅니다. 이는 실제 일보다 감정과 정치가 앞서는 불필요한 소모전으로 이어지기 쉽습니다. 특히 주니어 기획자들은 자신의 논리적 판단이 명확하면 대표가 다르게 판단했다는 이유만으로 ‘틀렸다’고 규정하며 설득을 시도합니다. 하지만 조직은 논리적으로 옳은 사람의 의견으로 움직이지 않습니다.
책임을 지는 사람이 의사결정을 합니다. 기획자가 대표의 방향성을 바꾸려 할 때 문제는 단순한 의견 불일치가 아니라 ‘비전 충돌’이라는 점입니다. 이 경우 설득은 거의 성공하기 어렵고, 설령 성공하더라도 조직의 신뢰 구조를 무너뜨리기 쉽습니다. 따라서 기획자는 충돌보다 조율, 설득보다 보완을 선택해야 합니다.
4-1. 대표의 의견을 꺾는 순간, 기획자는 ‘권한 충돌’을 일으킨다
기획자가 대표와 의견 충돌을 겪을 때 가장 흔한 접근은 “내 논리가 맞고 대표가 틀렸다”는 인식에서 출발하는 경우입니다. 논리적으로 보면 맞을 수 있습니다. 데이터로 보면 기획자의 판단이 더 타당할 수도 있습니다. 하지만 문제는 ‘누가 맞느냐’가 아니라, 기획자가 대표의 의견을 공개적으로 꺾는 순간 발생하는 권한 충돌 구조입니다.

대표의 판단은 회사 전체의 방향성을 기반으로 합니다. 반면 기획자가 보는 정보는 제품 단위, 기능 단위, 특정 데이터 단위에 국한됩니다. 이 차이를 이해하지 못하고 대표의 결정을 뒤집으려 하면, 기획자는 의도치 않게 자신의 역할 범위를 넘어서 대표의 판단권에 도전하게 됩니다. 이 순간 기획자는 실무적 의견 충돌을 넘어, 대표가 느끼는 ‘권한 침해’라는 정서적 거부감을 불러일으킬 수 있습니다.
더 큰 문제는, 대표의 판단을 꺾는 데 성공한다고 해도 기획자가 그 결정의 책임을 대신 지지 않는다는 점입니다. 대표는 여전히 최종 책임을 지고 있기 때문에 자신의 판단 구조가 흔들리는 경험을 불편하게 받아들일 수밖에 없습니다. 즉, 대표를 설득하는 일은 단순 의견 조율이 아니라 구조적 권한 관계를 건드리는 행동입니다. 이 사실을 이해하는 기획자는 의견이 달라도 ‘꺾기’보다는 ‘보완’을 선택하게 되고, 불필요한 갈등 대신 생산적인 협업을 만들어가게 됩니다.
4-2. 주니어 기획자가 흔히 빠지는 착각: “내가 더 맞으니까 바뀌어야 한다”
주니어 기획자들이 대표와 갈등에 빠지는 이유 중 하나는, 자신이 가진 논리적 판단이나 데이터 근거가 ‘정답’이라고 믿는 경향 때문입니다. 경험이 적을수록 “정답 중심 사고”에 갇혀 다양한 요소를 고려하기보다 하나의 논리로 전체 상황을 판단하려는 경향이 나타납니다.

그러다 보니 대표의 결정이 자신의 정답과 다를 때, 기획자는 이를 불합리로 받아들이며 설득을 시도합니다. 하지만 서비스 기획은 정답을 찾는 일이 아니라, 결정된 방향을 가장 잘 실행하는 방법을 찾는 일입니다. 대표가 가진 정보는 기획자보다 넓고, 리스크 감수성도 다르고, 판단의 기준값도 다릅니다. 그럼에도 주니어는 자신의 논리가 더 타당해 보이면 대표의 판단을 바꾸는 것이 기획자의 역할이라고 착각합니다.
이 착각은 곧바로 갈등을 낳습니다. 기획자가 정답을 주장하면 대표는 이를 ‘리더십 도전’으로 인식하고, 대표가 기획자의 의견을 거절하면 기획자는 이를 ‘비합리적 판단’으로 받아들여 조직 구조를 오해하게 됩니다. 성숙한 기획자는 대표의 판단을 바꾸는 것이 자신의 역할이 아님을 이해합니다. 기획자의 역할은 정답을 내는 것이 아니라, 결정된 방향을 어떻게 성공적으로 구현할지 구조화하는 것입니다. 이 착각에서 벗어나야 비로소 갈등 없는 기획 커리어가 시작됩니다.
4-3. 대표와 충돌이 발생했을 때의 진짜 문제는 ‘비전 충돌’이다
대표와 기획자가 특정 기능이나 정책을 두고 의견 충돌을 겪을 때, 기획자는 “왜 이 작은 차이로 이렇게 크게 부딪히지?”라고 생각하곤 합니다. 하지만 실제로는 그 기능의 옳고 그름 때문이 아니라, 그 뒤에 숨어 있는 비전·철학의 차이 때문일 때가 많습니다.
대표는 회사의 장기적 방향성과 브랜드 정체성, 사업 구조, 리스크 감수성을 기반으로 판단합니다. 반면 기획자는 사용자 관점, 제품 경험, 데이터 효율성 등 실무적인 기준으로 판단합니다. 이 두 기준은 충돌할 수밖에 없고, 충돌하는 순간 문제는 단순 기능 논쟁이 아니라 비전 충돌의 형태로 나타납니다. 비전이 충돌한 상황에서 설득을 시도하면 갈등은 더 심화됩니다.
대표는 자신의 리더십에 대한 도전으로 느끼고, 기획자는 자신이 무시당한다고 느끼기 때문입니다. 이때 필요한 접근은 설득이 아니라 ‘비전의 맥락을 이해하고 그 안에서 최적의 방법을 설계하는 것’입니다. 즉, 대표의 비전을 최대한 존중하면서도 기획자가 가진 전문성을 활용해 실행 구조를 보완하는 방식이 훨씬 실질적입니다.
만약 비전 자체가 완전히 다르다면, 설득이 답이 아니라 애초에 함께 일할 기반 자체가 맞지 않는 것입니다. 이 경우 기획자가 할 수 있는 최선의 선택은 설득이 아니라 결별 또는 창업이라는 대안입니다. 대표와 충돌할 때 문제의 본질이 ‘기능 논쟁’이 아니라 ‘비전 충돌’임을 이해하면, 기획자 스스로 갈등에서 한 발 물러서고 훨씬 더 성숙한 방식으로 문제를 바라볼 수 있게 됩니다.
왜 기획자는 대표를 설득하려 해선 안 되는가? (3)편에서 계속...
온라인 공간에서 야메군이란 닉네임으로 활동 중인 25년 차 서비스 기획자. 네이버 웹/모바일 기획자 커뮤니티 웹(WWW)을 만드는 사람들에서 운영진으로 활동했으며, 딴지일보를 시작으로 아이러브스쿨, 메가엔터프라이즈, 짱공유닷컴, YES24를 거쳐 IT 원천기술 연구소 Valhalla Lab에서 Pattern recognition과 Machine learning 기반의 Natural language processing 기술의 상업적 이용방법에 대한 연구. 최근 스타트업계로 이직, 반려동물과 온라인 피트니스 분야를 경험했고 자율주행 도메인을 거쳐 현재 SaaS 기반 Monitoring 도메인에서 유일한 기획자로 재직 중. 2016년 7월, 웹/모바일 기획자의 업무능력 향상을 위한 서적 “처음부터 다시 배우는 웹 기획”(정재용, 최준호, 조영수 공저) 출간. 2008년부터 약 15년간 서비스기획자의 성장을 위한 온/오프 강의를 통해 후배 기획자를 양성 중.
'똘끼의 웹기획론. > 서비스 기획 가이드' 카테고리의 다른 글
| 왜 기획자는 대표를 설득하려 해선 안 되는가? (1) (0) | 2025.11.16 |
|---|---|
| MS의 웹/모바일 분석 툴, Clarity를 알아볼까요? - 활용편 (0) | 2025.09.23 |
| MS의 웹/모바일 분석 툴, Clarity를 알아볼까요? - 소개편 (0) | 2025.09.22 |
| 기획자의 새로운 무기, 프롬프트 엔지니어링 - 실무 (3) | 2025.09.08 |
| 기획자, 프롬프트 엔지니어링이 필요한 이유 - 개념 (2) | 2025.09.02 |
