7년 차 기획자의 커뮤니케이션 실제 사례

7년 차 기획자가 직접 겪은 디자이너, 개발자와의 실무 커뮤니케이션 실제 사례를 통해 협업의 난관을 극복하는 구체적인 방법을 배울 수 있습니다. 이 글은 단순히 이론을 나열하는 대신, '창의력의 방향성 제시', '시안과 기획서 맵핑', '요구사항의 명확한 전달' 등 각 직군과의 갈등을 해결하는 실용적인 노하우를 제공하여, 당신의 프로젝트 소통 효율을 즉각적으로 높여줄 것입니다.

 

1. 7년 차 기획자의 커뮤니케이션 실제 사례 개요

1.1. 커뮤니케이션도 기획의 영역이다

1. 기획자의 역할과 소통의 중요성: 서비스 기획자는 프로젝트를 관리하는 PM의 역할을 수행하며, 디자이너, 개발자뿐만 아니라 영업팀, 유관부서, 외부 협업사 등 내외부 소통 능력이 특히 중요하다.
2. 소통 부재의 위험성: 프로젝트를 이끄는 데 소통이 없다면 사공이 적어도 배가 산으로 갈 수 있으며, 이는 자칫 큰 비용 손실로 이어질 수 있다.
3. JD에서 강조하는 역량: 국내 유수 기업의 서비스 기획자 JD(Job Description)를 보면, 이 직군에서는 타 직군 대비 커뮤니케이션 역량을 특히 강조하고 있다.
4. 기획자 커뮤니케이션의 정의: 기획자가 커뮤니케이션을 잘한다는 것은 단순히 친절하거나 유창하다는 의미가 아니다.
5. 외유내강의 필요성: 프로젝트의 목표 달성을 위해 팀원의 불편 사항은 빠르게 이해하되, 업무 전달은 명확해야 하는 외유내강의 자세가 필요하다.
6. 협업의 기본 원칙: 나와 일하는 사람이 어떤 논리를 갖고 어떻게 일하는지 **알아가는 것('지피지기 백전백승')**이 중요하며, 필자는 이직 시 강조했던 커뮤니케이션 역량도 '동료를 배운다'는 점이었다고 언급한다.
7. 본문의 목적: 이 글은 이상적인 성공담이 아닌, 7년간 여러 서비스 도메인을 거치며 겪은 필자의 경험담과 극복기를 공유하는 것이며, 실무자와의 에피소드를 중심으로 구성되었다.
8. 사례 구성: 디자이너, 프론트엔드 개발자 및 퍼블리셔, 백엔드 개발자와의 사례로 나누어 사건의 발단, 결과, 발생 이유, 해결 방법, 의의를 중심으로 정리하였다.
9. 타 직군에 대한 제언: 이 글을 읽는 다른 직군의 실무자라면, 기획자가 해당 직군을 어떤 시선으로 바라보는지 참고할 수 있다.

 

2. 디자이너: 창의력의 방향성 제시하기

2.1. 발단 및 결과: 기획 의도와 다른 디자인 도출

1. 발단: 개발 명세에 집중한 나머지 디자인 톤앤매너, 디테일, 기획 의도에 대한 설명이 부족했으며, 스토리보드를 그렸으니 디자이너가 알아서 구현해 줄 것이라는 게으른 생각으로 업무를 맡겼다.
2. 결과: 기획 의도와는 다른 디자인이 나왔으며, 심지어 스토리보드와 다르게 중요도가 낮은 기능이 강조되는 경우도 발생했다.
3. 기획자의 푸념: 기획자는 남몰래 '왜 디자이너는 디자인만 생각할까'라고 푸념하기도 한다.

2.2. 문제의 이유와 해결 방안

1. 문제의 이유: 디자인은 옳고 그름이 명확하지 않아 수정이 쉽지 않다. 기획자가 단순히 '마음에 들지 않는다'는 이유로 설득력 없이 반대하면 상대의 기분을 상하게 할 수 있으며, 디자이너의 공수가 낭비되어 일을 두 번 하게 되는 상황을 피할 수 없다.
2. 해결을 위한 사전 회의: 이후에는 디자인 방향성에 대해 사전 회의를 진행하였다.
3. 레퍼런스 정리: 기획서는 별도로 디자인의 톤앤매너 레퍼런스를 정리할 필요가 있으며, 레퍼런스 선택 기준은 경쟁사, 시장 점유율, 트렌드 등의 논리로 선별한다. (보통 디자인 상 수상 이력이나 시장 점유율이 설득력이 높다.)
4. 논리 기반 회의: 레퍼런스 문서를 토대로 디자이너와 회의를 열어 경쟁사 UI/UX 및 프로젝트에서 중요한 정보의 강약을 설명하였다.
5. 해결의 효과: 논리를 가지고 회의하니 의도에 벗어난 디자인이 나오는 횟수가 줄었고, 수정 방향도 명확해졌다. 또한 디자이너는 초기 컨셉이나 레퍼런스를 찾을 필요 없이 디자인 구현에 집중할 수 있게 되었다.
6. 의의: 디자인은 창작의 영역이므로 경우의 수가 무한하다. 기획자는 이러한 경우의 수를 좁히려는 노력이 필요하며, 방향성 회의는 '창작은 자유지만 이 틀에서 벗어나지 않았으면' 하는 정중한 제안이다.

 

3. 프론트엔드 개발자/퍼블리셔: 시안과 기획서를 동시에 봐야 하는 고충 해결하기

3.1. 발단 및 결과: 시안과 기획서 간의 맵핑 문제

1. 발단: 백엔드 개발자는 주로 기획서를 보지만, 프론트엔드/퍼블리셔는 시안과 기획서를 동시에 봐야 한다. 기획자는 '기획서에 썼으니', 디자이너는 '디자인은 했지만 상세 내용은 기획서에 있으니'라고 생각하기 쉽다.
2. 결과: 겉보기에는 시안처럼 구현되었으나, 데이터의 노출 케이스나 동작 등 스크립트 누락이 빈번하게 발생했다.
3. 디자이너와 퍼블리셔 간의 갈등: 작업자에 따라 디자인 시안을 기획서처럼 자세하게 요구하는 경우가 있으며, 이 경우 디자이너는 '시안일 뿐이니 기획서를 보라'고 반박하며 사이가 안 좋아지는 케이스가 발생한다.
4. 문제의 이유: 디자인 시안은 데이터의 모든 노출 케이스와 동적 흐름을 보여주지 못하며, 시안이 많아지면 시안과 기획서 간의 맵핑이 되지 않아 일일이 찾아보기 힘들어진다. 결국 프론트엔드 개발/퍼블리셔는 퍼즐 맞추듯 시안과 기획서를 번갈아 보게 되어 시간은 많이 들고 효율은 떨어진다.

3.2. 해결 방안 및 의의

1. 별도 리뷰 회의 진행: 작업 범위가 큰 경우, 디자인 시안이 1차적으로 완성되면 개발에 넘기기 전 별도로 리뷰 회의를 진행하였다.
2. 리뷰 회의 목적: 이 회의는 전체 킥오프와 달리, 시안의 수정사항과 프론트 구현 시 이슈에 대해 취합하는 '프론트엔드'만을 위한 자리이다.
3. 사전 작업 1: 넘버링 매칭: 시안을 제작할 때 기획서 페이지와 매칭될 수 있도록 대분류의 넘버링을 맞추어 시안별로 어떤 기획서를 봐야 하는지 쉽게 찾을 수 있도록 하였다.
4. 사전 작업 2: 기획서 정의: 기획서는 시안에 담기지 못한 데이터 노출 표현과 동작 시점을 정의해야 한다. (예: 몇 줄까지 노출, 절삭처리, 이미지 자름 기능 등)
5. 의의: 프론트엔드 개발/퍼블리싱은 디자인과 백엔드 개발의 중간 단계이므로, 해당 시안이 어느 기획서를 참고하는지 제목 등에 넘버링을 잘 표기해야 한다.
6. 리뷰 회의를 통한 구분: 백엔드 개발에 넘기기 전, 디자이너와 함께 구현 이슈는 없는지 체크하고, 리뷰 회의를 통해 디자인 가이드에 표기할 것과 기획서에서 확인해야 할 것을 구분해야 제 목적에 맞는 산출물이 나온다.

 

4. 백엔드 개발자: 요구는 명확하게, 일정 협의는 유연하게, 기획서는 읽기 쉽게

4.1. 발단 및 결과: 스펙 추가와 방어적인 태도

1. 발단: 개발 도중 기획서에 없던 스펙이 추가되어 공수가 늘어났으며, 이는 주로 기획자의 누락이나 외부 요구사항으로 발생한다. 애자일 환경에서 단위별로 개발과 기획이 계속 변경되는 경우도 있다.
2. 결과: 개발자는 "지금 말하는 내용은 기획서에 없었잖아요", "이건 추가하려면 시간이 오래 걸려요"와 같이 요구사항에 대해 방어적인 태도를 취하게 되며, 이는 기획자와 껄끄러운 상황을 만든다.
3. 경직된 소통: 일부 개발자는 방어를 넘어 공격적으로 이야기하기도 하며, 이로 인해 기획자는 갈등이 싫어 퀄리티 향상을 위한 추가 사항도 그냥 덮어두게 된다.

4.2. 문제의 이유와 해결 방안: 확장성 고려 및 협상 능력

1. 문제의 이유: 개발자는 폭포수든 애자일이든 전체 모듈을 생각하여 코드를 짜야 하므로, 큰 그림 없이 단위별로 코드를 짜면 추후 불필요한 리팩토링이 발생할 수 있다. 따라서 개발자의 방어적인 말은 정당한 항의일 경우가 많다.
2. 기획자의 무기: 협상 능력이야말로 기획자의 가장 큰 무기이므로, 확장성을 고려한 사전 문서 작성과 방향성 회의, 그리고 추가되는 일정과 구현 사항에 대한 유연한 협상이 필요하다.

4.3. Case 1: 사전 문서 작성 및 킥오프 회의

1. 공유 내용: 개발자가 전체 코드 설계를 잘할 수 있도록 **'프로덕트의 목표와 쓰임새, 그리고 확장 가능성'**을 기획하고 사전에 공유해야 한다.
2. 이상적인 문서: 폭포수 모델처럼 가능한 모든 케이스를 작성해주는 것이 베스트이다.
3. 애자일 환경에서의 정의: 애자일일 경우라도 MVP의 핵심 기능과 목표는 반드시 정의해야 한다.
4. 명확한 설명: "이 프로젝트는 000 기능을 구현해서 000 성격의 프로덕트를 출시하는 게 목표이고요. 나중에 000 기능까지 확장할 수 있어요."와 같이 깔끔하게 설명해야 한다.
5. 개발자의 이점: 개발자는 확정 기능과 가변 기능을 분리하여 아키텍처 설계와 모듈 단위 작업을 시작할 수 있다.

4.4. Case 2: 개발 진행 도중 누락/추가 기능 요청

1. 요청 시 필수 논리: 요청 배경과 중요도를 먼저 설명해야 하며, "00 영업 이슈로 이 기획을 추가하게 되었어요. 이 기획 여부에 따라 매출에 영향이 있어요"와 같은 설득 논리가 필수이다.
2. 기획자 누락 시 대처: 기획자의 누락으로 발생한 경우, 솔직하게 잘못을 인정하는 태도가 중요하다.
3. 필자의 대처 예시: "제가 이 부분은 미처 파악하지 못했네요. 죄송합니다. 다음부터는 더 신경 쓸게요. 그러나 현재는 이 부분이 필요해요. 개발 공수 말씀해 주시면 일정을 조정하거나, 나머지 스펙들을 조정해 볼게요"라고 말하였다.
4. 공수 확보 및 조정: 누락된 개발 공수를 파악한 뒤 그만큼의 개발 일정을 확보해야 한다 (예: 오픈일에서 D+3일 딜레이).
5. 일정 확보 불가 시 대안: 일정 확보가 불가하다면 핵심 기능만 구현하거나, 덜 중요한 스펙을 제외한 뒤 후속 개발로 산정할 수 있다 (예: 1차로 조회 기능만 구현하고, 오픈 후 후속 개발에서 수정 기능 추가 요청).
6. 기획자의 역할: 기획자는 조정 가능한 일정과 스펙을 가지고 개발자와 원만한 협의를 도출해야 한다.

4.5. 의의

1. 기획자의 정체성: 기획자는 국어로 코딩하는 사람이므로, 개발자의 입장에서 기획 문서를 설계해야 한다.
2. 핵심 정의의 중요성: 프로덕트의 핵심 기능과 부속 기능에 대해 정의하고 개발자들과 공유해야 한다.
3. 개발자의 이점: 핵심 기능 정의를 통해 개발자는 변동 가능성을 고려하여 코드 전체를 설계할 수 있고, 중간 수정 사항에 대해서도 유연하게 받아들일 수 있다.
4. 개발자 이해 방법: 개발자를 이해하기 위해서는 특정 개발 언어를 익히는 것도 좋지만, 개발자가 일하는 방식에 대해 끊임없이 탐구하는 것을 추천한다.

 

5. 커뮤니케이션도 프로덕트 기획처럼, ‘이해’가 먼저다

1. 피드백의 현실: 프로젝트 중 불필요한 회의가 많아지거나 동료의 불만 사항을 듣는다면 상대를 탓하기 전에 스스로를 돌아볼 필요가 있다. 기획자에 대한 피드백은 이상적으로 오지 않고, 대부분 동료들의 감정적인 토로이거나 타인을 통해 건너 듣는 경우가 많다.
2. 피드백의 원인: 피드백의 원인은 주로 '각 실무자들의 특성'을 이해하지 못한 탓이다. (예: 디자이너, 개발자가 쓰지 않는 용어를 사용하거나 작업 방식을 이해하지 못하고 기획서만 들이민 경우)
3. 협업의 기본: 프로덕트 출시 전 사용자와 시장을 파악하듯, 동료와의 협업도 그들의 특성을 이해하고, 업계의 언어로 이야기해야 한다.
4. 안일한 생각 금지: '디자이너가 알아서 해주겠지', '난 개발을 잘 모르니까 요구사항만 말해주면 잘 구현해주겠지'라는 생각은 **'내 생각을 남에게 미루는 행위'**이며, 일을 미루는 동료를 좋아할 사람은 없다.
5. 실마리 찾기: 소통 시행착오를 줄이려면 당사자에게서 이야기를 들어야 하며, 커뮤니케이션이 문제 해결 역량이라고 해서 딱딱하게 풀 필요는 없다.
6. 솔직한 질문: 필자는 동료와 친해지면 메신저나 커피를 마시며 **"제 기획서 읽기 편해요?"**라고 솔직하게 물어보곤 했다.
7. 역량 강화: 실무자마다 다양한 대답에서 실마리를 캐치하고 필요한 역량을 쌓는 것부터 시작해야 한다. 필자는 기획자임에도 불구하고 피그마, XD 실습, HTML/CSS 강의 수강, SQL 및 개발 언어 학습 등을 통해 함께 일하는 동료들의 특성을 이해하기 위해 노력하였다.
8. 소통의 전제: 상대에 대해 아는 것이 없는데 어떻게 소통이 가능하겠는가? 결국 동료를 이해해야 소통이 원활해지고 프로젝트도 성공적으로 이끌 수 있다.
9. 지속적인 학습: 필자는 가끔 '개발자가 좋아하는 기획자' 등의 키워드로 블로그 글을 찾아 읽으며 다양한 직군과의 '커뮤니케이션'이 가능해지도록 한다.
10. 기획자의 책임: 프로젝트의 리드는 기획의 영역이며, 커뮤니케이션은 문제 해결 역량이라는 책임감을 가지고 소통에 임하는 것이 좋다.