﻿ 기획 자 와 프로덕트 매니저 ( PM ) 의 차이점 은 ? - ' Startup ' s Story Platform ’ 
 박 재환 Posted On 2016 / 09 / 20 
 ‘ PM 과 기획 자 는 ‘ 아이디어 를 만들 어 내 는 것 ’ 만 으로 역할 이 끝 날까 ? ‘ 라는 기고 를 한지 3 년 반 이 지났 다 . 그럼 글 을 쓴 이후 3 년 반 , 짧 지 않 은 시간 동안 무슨 일 이 있 었 을까 . 
 개인 적 으로 는 그 사이 이직 을 한번 하 면서 회사 에서 PM ( Product Manager ) 를 비롯 해서 , UX 기획 , Business Development , Sales / Marketing 등 다양 한 업무 를 했 다 . 하지만 인원 이 적 은 회사 특성 상 PM 역할 을 겸업 했 다 . 대 기업 시절 에 는 업무 가 매우 세분 되 어 있 었 지만 , 이후 재직 한 회사 들 은 전체 인원 도 작 았 지만 , 단위 사업 당 인원 수도 매우 적 었 기 에 여러 역할 을 할 수 밖 에 없 었 다 . 
 MBA 졸업 후 S / W 쪽 으로 전환 해 여러 모바일 서비스 를 담당 했었 다 . 개인용 클라우드 앱 , 뮤직 , 비디오 서비스 , 카메라 앱 , 웨어 러블 디바이스 앱 , 고속버스 앱 , 콜택시 앱 , 포인트 등 짧 은 기간 에 10 여 개 의 다양 한 서비스 들 을 거쳤 다 . 뭔가 만들 어 지 고 , 발전 돼 가 는 모습 을 좋아해서 혼자 서 채찍질 해 가 며 , 욕 도 먹 어 가 며 , 그렇게 시간 은 흘러왔 다 . 다행히 성과 가 좋 았 던 것 들 도 있 었 다 . 업무 를 맡 은 것 중 에 는 Product Renewal 을 통해서 전체 플랫 폼 매출 대비 3 % 에서 40 % 까지 급격히 상승 하 게 만든 것 도 있 으며 ( 기존 매출 의 10 배 이상 증가 ) , 마케팅 비용 0 원 으로 다운로드 50 만 까지 가 보 는 경험 도 해 보 았 다 . 물론 망해서 소리 소문 없이 사라진 서비스 도 있 었 다 . 
 그렇 다면 PM 역할 을 하 면서 느낀 점 은 ? 
 여러 가지 토픽 이 있 을 수 있 겠 지만 , 가장 먼저 선결 한 부분 은 ‘ 기획 자 ’ 와 ‘ PM ’ 의 차이점 을 상정 해 기준 을 세웠 다는 것 이 다 . 
 대한민국 에서 IT S / W 산업 은 기존 기업 이 디지털 분야 에 대해 니즈 가 발생 하 면서 단기 적 인 시스템 / 서비스 구축 을 위해 외주 형태 로 성장 했 다 . 90 년 대 중반 이후 다수 의 IT 프로젝트 들 이 생겨나 면서 , 개발자 와 디자이너 가 필요 해졌 고 , 기존 기업 의 직원 들 ( 사업 관련 팀 / 관리 팀 / 기타 타 전문 직무 팀 ) 의 요구 사항 들 을 개발자 와 디자이너 가 구현 할 수 있 도록 커뮤니케이션 해 주 고 , 밑그림 을 그려 주 는 ‘ 기획 자 ’ 라는 역할 이 본격 적 으로 생겨났 다 . 상위 레벨 의 전략 이나 컨셉 을 정하 기 보 다는 제안 을 하 고 컨 펌 받 는 역할 이 었 다 . 그리고 그 전략 / 컨셉 / 방향 이 결정 되 면 , 스케치 ( Wireframe , User Interface ) 를 만드 는 것 까지 를 책임지 는 것 이 일반 적 인 기획 자 가 하 는 역할 이 었 다 . 
 그러 다 보 니 , 아래 와 같 은 업무 영역 으로 나누 어 지 게 되 었 다 . 
 가 . 위 와 같 은 조직 및 업무 구조 에서 볼 때 , 개발 방식 은 아 시 다시피 Waterfall ( 폭포수 방법론 ) 이 고 , 의사 결정 권한 이 아래 로 갈 수록 매우 적 기 때문 에 , 아래 로부터 위로 의 피드백 은 정말 심각 한 이슈 외 에 는 무시 된다 
 나 . 또한 , 1 번 요구사항 발주자 과 2 번 의 기획 자 의 역할 이 일부분 겹치 고 ( 의사 결정 , 컨셉 , 커뮤니케이션 ) , 2 번 기획 자 와 디자이너 의 역할 이 일부 겹치 게 된다 ( 사실 요즘 은 UI 문서 를 따로 제작 하 지 않 고 UX 를 담당 하 는 전체 디자이너 가 모두 설계 하 는 경우 도 많 다 ) 
 각자 의 전문 영역 이 있 는 데 반해 ‘ 가 ’ 의 이슈 로 인해 피드백 및 전문 성 상실 은 무시 되 고 , 3 번 , 4 번 으로 갈수록 더 잘 알 고 있 는 문제점 들 에 대해 입 을 다물 게 되 고 , 그 로 인해 서비스 들 은 성공 적 으로 진행 되 기 쉽 지 않 게 된다 . 또한 ‘ 나 ’ 이슈 로 인해 원청 , 기획 자 , 디자이너 간 R & R 이 불 분명 해 지 고 , 전문 성 을 무시 하 면서 잘 모르 면서 도 소위 ‘ 훈수 ’ 를 두 면서 품질 자체 를 떨어뜨리 게 되 는 경우 도 빈번히 발생 하 게 된다 . 아마 자체 개발 하 는 회사 만 경험 한 이 들 은 이해 못 하 거나 , 무언가 이상 한 조직 / 역할 구조 라고 느낄 것 이 다 . 
 그렇 다면 ‘ 기획 자 ’ 와 PM 은 뭐 가 다르 고 , 어떻게 해야 저 구조 의 문제점 들 을 해결 할 수 있 을까 ? 
 PM 과 기획 자 의 가장 큰 차이점 은 세 가지 라고 생각 되 는데 , 첫 번 째 로 의사 결정 권한 의 확대 , 둘째 로 해당 Product 에 대한 확고 하 고 다양 한 지식 , 세 번 째 가 다양 한 부서 와 협업 의 중심 이 되 는 것 이 다 . 
 1 . 의사 결정 권한 의 확대 
 Wikipedia 에 Product Manager 에 대한 정의 를 보 면 Product Manager 는 ‘ often called the product ‘ CEO ’ 라고 할 만큼 단위 Product 에서 는 나름 높 은 권한 을 가지 고 있 어야 한다 . 세부 설명 에서 도 사업 적 , 기술 적 , 기타 스 케 쥴 링 등 Project manage 및 전체 적 인 사항 들 에 모두 관여 할 만 한 권한 과 역할 을 가지 고 있 어야 한다 . 
 또한 , 원활 한 개발자 와 디자이너 와 커뮤니케이션 을 위해서 는 대화법 및 R & R , 기타 Project Management 스킬 뿐 만 아니 라 , Product 관련 분야 에 대해 지식 이 필요 하 다 . 사업 / 서비스 적 인 도메인 지식 은 당연 하 고 , 개발자 / 디자이너 와 소통 을 위한 전문 지식 또한 일정 부분 알 고 있 어야 한다 . 물론 개발자 의 코드 문법 까지 알 필요 는 없 다 . 디자인 의 컬러 값 까지 외우 고 있 어야 할 필요 는 없 지만 , 모바일 서비스 기준 으로 는 무언가 만들 고 싶 은 기능 이 있 을 때 , 개발자 에게 내용 을 정확히 전달 하 고 , 필요시 기본 적 인 개발 문서 를 찾아보 면서 같이 의논 해 줄 필요 는 있 다 . 어느 OS 에서 는 해당 기능 이 되 는지 , 안 되 는지 , 만드 는 앱 은 어느 정도 수준 이상 의 OS 나 device 를 지원 해야 되 는지 정도 는 최소한 을 알 필요 가 있 다 . 알 아야 할 모든 기술 적 인 지식 들 은 그 구현 가능 여부 뿐 만 아니 라 , 사업 적 인 목표 달성 을 위한 효율 성 측면 에서 의 선택 을 위해 알 아야 할 부분 이 다 . 
 디자인 부분 도 마찬가지 라서 가이드 는 어떻게 생성 되 는지 , 왜 안드로이드 에서 는 PX 이 아니 라 dp 값 을 사용 하 는지 , 나 인 패치 가 무엇 인지 등 기본 적 인 지식 을 알 고 있 다면 , 개발자 , 디자이너 와 의 협업 에 더욱 도움 을 줄 것 이 며 , 프로젝트 가 효율 적 으로 돌아가 게 할 수 있 을 것 이 다 . 
 Product 가 만들 어 지 고 , 이후 에 도 제 기능 을 다 하 려면 , 기술 적 인 부분 외 에 도 아래 그림 처럼 다양 한 부서 / 역할 과 협업 이 필요 하 다 . Partnership , revenue flow , Cost , Sales / Marketing / Resource 등 여러 부분 에 대한 지식 을 가지 고 커뮤니케이션 이 가능 해야 하 고 , 그 중심 적 인 역할 을 원활 하 게 돌아갈 수 있 도록 해야 한다 . 요구사항 발주자 가 아닌 , Product Manager 가 중심 이 되 어 , 전문 지식 들 을 관리 하 고 프로젝트 를 운영 하 며 , 이해 관계자 들 을 조율 하 는 역할 을 하 는 것 말 이 다 . 
 위 내용 을 정리 해 보 면 시사 하 는 바 는 다음 과 같 다 . 
 만약 본인 이 있 는 조직 이 의사 결정 권한 의 확대 까지 해 주 게 된다면 금상첨화 지만 , 불 가능 할 경우 에 는 해당 Product 에 대한 지식 을 먼저 습득 해야 한다 . 단순히 상상 속 에 만 가능 하 고 실제 구현 이 불 가능 하 거나 , 사실상 실현 되 기 어려운 상황 을 무리 하 게 주장 하 지 않 으려면 필수 적 일 것 이 다 . 지식 기반 의 커뮤니케이션 이 원활 해질 때 , 개발 / 디자인 의 성능 도 올라갈 것 이 고 , 전체 Product 의 성공 확률 도 높 아 진다고 본다 . 
 조직 을 관리 할 수 있 는 권한 이 있 다면 , 산업 / 카테고리 마다 다르 긴 하 겠 지만 , 1 번 요구사항 발주자 의 권한 을 축소 하 고 ( 사업 관리 기획 / 마케팅 의 전문 역할 에 집중 ) , 서비스 자체 는 PM 가 세부 적 인 의사 결정 을 하 게 하 는 것 이 효율 적 이 라는 소견 이 다 . 디자이너 가 UX 를 총괄 할 수 있 도록 하 고 PM 은 기획 자 와 는 다르 게 모든 전문 분야 담당자 들 과 커뮤니케이션 하 고 조율 하 는 역할 을 하 는 형태 다 . 
 원문 : 기획 자 와 Product Manager 의 차이점 
 Project manager , Program manager 와 의 차이 는 Wikipedia 의 문서 를 참조 해 볼 수 있 을 것 같 다 . 또한 , 산업 마다 회사 마다 조금 씩 용어 의 차이 가 있 으므로 정확 한 definition 보 다는 의미론 적 으로 받아들이 길 바란다 . 
 PMProduct Manager 기획 자 프로덕트 매니저