PM, PO, 서비스 기획자는 어떤 차이가 있을까
대한민국의 Product Manager 직무 시장의 역사에 대해
이 글을 보러 오는 독자라면 대개 IT 회사에서의 '기획' 업무에 관심이 있을 것이다. 그러다 보니 자연스럽게 여러 JD들을 보았을 것인데, 회사마다 어느 회사는 Product Manager라 뽑기도 하고 어느 회사는 서비스 기획자라는 이름으로 채용 공고를 관리한다. 어떤 회사는 Product Manager가 아닌 Product Owner라는 직무로 뽑기도 하는데, 대관절 이 직무들은 어떤 차이가 있을까.
IT 기획을 꿈꾸는 취준생이나 초년생 입장에서는 이러한 직무의 차이들이 다소 혼란스러울 것이다. 하지만 한 가지 좋은 소식(?)이 있다. 취준생이나 초년생 뿐 아니라 현업 실무자들 역시 이 직무들의 차이에 대해 잘 모르는 사람이 많다는 것이다.
이번 글에서는 왜 이런 직무 이름에 대한 혼란이 있는지, 직무들의 진짜 차이가 무엇인지에 대해서 알아보도록 하자.
1. 한국 개발 환경의 역사: 워터폴과 애자일
서비스 기획자와 PM/PO의 차이를 이해하기 위해서는 먼저 개발 환경의 차이에 대해서 알아야 한다. 흔히 워터폴 개발 환경, 애자일 개발 환경이라 부르는 그것이다.
출처: https://www.bairesdev.com/blog/agile-vs-waterfall/워터폴은 [기획 -> 디자인 -> 개발]과 같이 각 프로세스가 단계별로 진행되는 프로세스를 중시하는 환경이고, 애자일은 기획, 디자인, 개발을 동시에 진행하며 빠르게 기능을 내보내는 환경이다.
이러한 차이에 따라 워터폴 환경의 회사는 대개 직무별로 기능팀을 구성한다. 예컨대 기획팀, 디자인팀, 개발팀이 나누어져 있고 프로젝트에 따라 팀별로 협업하는 구조다. 반면 애자일 환경에서는 제품팀(목적팀이라고도 한다)으로 구성된다. PM, 디자이너, 개발자가 각기 다른 팀이 아닌 하나의 팀에서 하나의 제품(혹은 목적)만을 바라보고 일한다.
(워터폴과 애자일 환경은 기회가 될 때 별도의 글로 좀 더 자세히 설명하도록 하겠다.)
인류가 아직 개발 환경에 대한 경험치가 부족하던 시절 굳이 따지자면 IT회사들은 워터폴 개발 환경에 따라 일해왔다. 반면 애자일 개발 환경은 2001년 애자일 선언에 의해 탄생했다.(물론 그 전에서 비슷하게 일하는 경우는 많았을 것이다) 즉 애자일은 비교적 최근에 각광받기 시작한 개발 환경이다.
대한민국 IT 개발 환경의 역사 역시 다르지 않다. 각 회사는 서비스 기획자라는 이름으로 IT기획자를 채용하였으며, 이들은 기획팀 안에 소속되어 있었다. 그러다가 2010년대 중반의 스마트폰 시대 이후, 모바일 환경/UX/사용자 기반의 제품 환경 등의 개념이 각광받기 시작하며 애자일 개발 환경을 도입하는 회사들이 하나 둘씩 생겨나게 되었다. 이런 회사들은 기존처럼 기획팀, 개발팀, 디자인팀을 두지 않고, 이들을 각 제품별로 하나의 팀으로 묶어서 관리하기 시작했다.
문제는 여기서 발생했다. 이렇게 기존 업무 환경과 다른 제품팀(목적팀)이 구성되었는데, 기존 서비스 기획자의 역할이 이러한 제품팀(목적팀)에서 요구되는 역할과 역량과는 생각보다 많은 차이가 있었다는 것이다.
여기에는 어떤 차이가 있었으며, 이를 어떻게 해결해야 했는가를 추적하는 것이 서비스 기획자와 PM/PO의 차이를 알아보는 것의 핵심이다.
2. 서비스 기획자
잠깐 시간을 돌려 다시 전통적인 워터폴 모델에서의 서비스 기획자의 역할에 대해 알아보자.
서비스 기획자는 디자이너가 화면을 그리기 위해 필요한 전체 그림과 세부 요건들을 정의한다. 전체 화면의 구조를 잡고, 이 버튼을 누르면 어떻게 동작해야 하고, 회원별 상태에 따라 쿠폰이 어떻게 노출되어야 하는지를 세분화한다. 각 에러 케이스별 문구를 정의하고, 회원 가입시 도로명 주소를 입력받을 것인지 지번 주소를 입력받을 것인지 등과 같은 세부 케이스들을 잡는다.
서비스 기획자의 주 산출물은 IA, 와이어프레임, 스토리보드, 화면설계서나 기능명세서와 같은 것들이다. 서비스 기획자가 전달한 문서를 바탕으로 디자이너나 개발자가 개발하는데, 기본적으로 '이 버튼을 누르면 어떤 동작이 되죠?'와 같은 질문이 나오지 않을 정도의 완성도를 목표로 한다.
서비스 기획자의 기획서가 완료되면 디자이너는 이를 바탕으로 UI 작업을 하고, 개발자에게 넘긴다. 개발자는 UI 디자인과 기획서를 보고 실제 개발이 들어간다.
와이어프레임한 가지 흥미로운 사실은 서비스 기획자라는 직무가 우리나라에만 존재한다는 것이다. 서비스 기획자를 해외 사이트에서 검색해보기 위해 Service Planner와 같은 직무명으로 검색해도 나타나지 않는다. 해외에서의 서비스 기획자는 Service Designer나 Product Designer라는 직무로 불린다. 와이어프레임 정도를 제외하면 화면설계서나 기능정의서와 같은 포맷도 잘 사용되지 않는다.
3. Product Manager
그렇다면 Product Manager란 무엇인가.
워터폴 개발 환경과 애자일 개발 환경은 굉장히 큰 차이가 난다. 워터폴은 정해진 프로젝트를 안정적으로 잘 끝내기 위함을 목표으로 돌아가지만, 애자일 개발 환경은 사용자가 원하는 제품을 만드는 것을 목표로 한다.
애자일의 핵심은 다음과 같다.
우리는 고객이 정확히 원하는 제품이 무엇인지 모른다. 때문에 어쩌면 고객이 원하지도 않을 완벽한 제품을 만들기 위해 큰 시간과 비용을 들이지 않는다.
대신 작은 제품을 빠르게 여러 번 만들어 선보이면서 사용자의 피드백을 수집한다.
사용자 피드백을 바탕으로 제품을 계속 수정하고, 때로는 완전히 새롭게 만들기도(pivot) 하면서 사용자가 원하는 제품을 찾아나간다.
핵심은 '완벽함'보다는 사용자 반응에 따른 '기민한 반응'이다.
(애초에 애자일agile이 기민함, 민첩함이라는 뜻이다)
여기서 문제가 발생한다. 서비스 기획자는 기획을 최대한 자세하게 만드는 것에 특화되어 있는 직무다. 하지만 애자일 팀에서 자세한 기획 따위는 필요가 없다. 오히려 자세한 기획은 빠른 개발과 검증에 독이 된다는 입장이다.
대신, 고객에게 빠르게 제품을 선보여가면서 고객 반응에 따라 제품을 변화시키는 것이 중요하다. 고객의 반응을 수집하고 빠르게 제품 의사결정을 이끌어내는 역량이 필요하다.
또한 애자일 개발 환경은 제품팀(목적팀)에 기반한다. PM이 개발자, 디자이너들과 하나의 팀을 이끌면서 제품 의사결정을 주도한다. 때문에 기본적으로 다른 팀에 기획서를 전달한다는 서비스 기획자적 느낌보다는, 기본적인 팀 리딩 역할 역시 필요로 한다.
이러한 제품팀에서 PM은 화면 기획을 하지 않는다. 그렇다면 서비스 기획자가 담당하던 화면 기획은 누가 담당하는가? 제품팀에서의 화면 기획은 Product Designer가 담당한다. PM의 의사결정을 바탕으로 Product Designer가 실제 만들고자 하는 화면을 디자인한다. Product Designer는 Figma나 Framer와 같은 툴로 화면을 기획/디자인한다. 이 과정에서 기능명세서나 화면설계서 등은 보통 사용되지 않는다.
4. PM과 서비스 기획자의 차이
결론부터 말하자면 서비스 기획자와 PM은 완전히 다른 직무고, 겹치는 영역도 생각보다는 매우 적다.
앞서 말했던 것처럼 Product Manager 직무의 탄생/도입 배경은 제품에 대한 의사결정을 주도적으로 내릴 수 있는 사람이 필요해서다. 즉 PM과 서비스 기획자의 직무 차이를 이해하는 데에 이 배경을 이해하는 것이 중요하다.
이에 따라 서비스 기획자에 비교한 PM의 핵심적인 필요조건은 2가지다.
1. 제품에 대한 기본적인 의사결정 권한이 있는가
2. 기능팀이 아닌 목적형 제품팀으로 구성되어 있는가
두 조건 모두 필수로 필요하며, 둘 중 하나라도 없다면 서비스 기획자이지만 Product Manager로 직무명만 바꾼 케이스(실제로는 서비스 기획자)다.
때문에 이런 이름만 PM인 경우를 제외하면, 서비스 기획자와 PM은 아예 다른 직무이다. 서비스 기획자와 PM의 주요 차이는 다음과 같다.
서비스 기획자
기능팀에서 근무
서비스/화면 기획이 메인 업무
IA, 화면설계서, 스토리보드, 와이어프레임 등이 핵심 산출물
디테일한 기획 문서 작성과 내부 커뮤니케이션이 중요 역량
팀 리딩 역량이 요구되지 않음
Product Manager
목적팀(제품팀)에서 근무
팀 목표/과제 설정, 요구사항 수집 및 의사결정이 메인 업무
1-pager, 제품 로드맵, OKR, PRD 등이 핵심 산출물
팀 리딩과 제품 의사결정, 내부 뿐 아니라 외부 커뮤니케이션이 중요 역량
5. 이름만 PM인 서비스 기획자가 존재하게 된 배경
직무명은 product manager이지만 실무는 서비스 기획 역할을 담당하는 직무가 있다. 그렇다면 이러한 직무는 왜 생겼을까?
2010년대 중후반부터 IT 제품팀에서 애자일 방법론이 주목받기 시작하면서, 기능팀을 목적형 제품팀 중심으로 재편하려는 시도가 이어지고 있다. 이 과정에서 단일 제품팀을 이끌기 위한 직무의 필요성이 발생했고, 이에 따라 PM 포지션 역시 해당 시점부터 한국에 도입되기 시작했다.
그러나 그 전까지 한국에서의 개발-기획 문화는 기능팀과 서비스 기획자 형태로 구성되어 있었기 때문에 아직 그 잔재가 상당히 남아있다. 비교적 새롭게 만들어진 회사들이나, 체제 전환에 성공한 회사의 경우 Product Manager가 비교적 본연의 역할을 충실히 할 수 있는 구조가 만들어져 있다.
그러나 이전에 기능팀과 서비스 기획자 형태로 운용된 역사가 오래되고 고착화된 회사들의 경우, 서비스 기획자를 계속 운영하거나 서비스 기획자의 역할은 그대로 가져가면서 직무명만 Product Manager로 바꾼 경우도 제법 많다. 이 회사들에서는 직무명만 PM이고 실질적으로는 서비스 기획자인데, 대개 기존 기능팀에서 목적팀으로 전환하려다가 여러가지 한계를 느끼고 기존 체제로 복귀한 경험들을 가지고 있다.
(사실 기능팀을 목적팀으로 바꾸는 것은 난이도가 매우 높은 과제다. HR 구조를 완전히 바꾸는 것은 생각보다 어렵기 때문이다. 기존의 관성도 있고, 평가/보상 체계와도 연결되어 있는 등 생각치 못한 이슈들이 많다.)
한국어로 Product Manager 직무에 대해 검색을 했을 때, 크게 서비스 기획자 형태로 소개를 하는 경우와 애자일 제품팀을 리딩하는 형태로 소개하는 경우로 나누어진 까닭은 위와 같다. 때문에 이 두 그룹별로 PM의 역할을 정의하는 바가 굉장히 다른데, 특정 회사가 PM을 어떤 형태로 정의하는지(진짜 PM 역할인지, 서비스 기획자 역할인지)를 보기 위해서는 JD를 보고 직접 판단해야 한다. (심지어는 같은 회사에서도 부서별로 pm의 역할이 이름만 pm인지, 제품팀의 pm인지 다른 경우도 있다!)
JD에 위와 같이 서비스 기획, UI 기획 등과 같은 단어가 있다면 이름은 PM, 실질적으로는 서비스 기획자 역할을 하는 곳이다. 이러한 형태의 JD에서는 PM으로 근무한다 하더라도 서비스기획실(또는 이름만 바꾼 PM실) 형태의 기능팀에 소속될 가능성이 높다.
반면 본래 의미의 PM 형태는 위와 같은 형태다. 개발자/디자이너와 같은 팀으로 일한다는 내용, 주요 업무가 기획이 아닌 우선순위 의사결정, 임팩트 즉정과 같은 단어들을 보고 일하는 방식을 유추할 수 있다.
6. Product Manager와 Product Owner의 차이
Product Manager와 동시에 Product Owner라는 직무도 있다.
결론부터 말하자면 국내에서 Product Manager와 Product Owner의 직무 차이는 존재하지 않는다고 보아도 좋다. 둘은 같은 직무로 생각해도 취업/이직 시장에서 실질적으로 거의 영향이 없고, 같은 직무로 취급한다.(단, 앞 꼭지에서 얘기한 '직무명만 PM인 서비스 기획자'와는 완전히 다르다!)
사실 엄밀히 따지자면 PM이 제품 관리자의 역할을 하면서, 제품에 대한 주요 의사결정을 담당한다. PO는 애자일 스크럼 팀을 리딩하면서, 조금 더 제품의 개발 실무를 전담하는 역할에 가깝다. PM이 제품팀을 리딩하는 느낌이라면 PO는 제품 개발팀을 운영하는 느낌이랄까.
다만 한국에서 이 정도로 엄밀하게 직무를 구분하는 경우는 없고, 대부분의 회사가 PM과 PO 둘 중 하나의 직무만 취급하기 때문이다.
간혹 PO는 0 to 1, PM은 1 to 100을 하는 직무로 이해하는 경우도 있다. 그러나 이것은 PM과 PO의 본래 의미와는 거리가 멀다. 토스에서 자체적으로 잡 타이틀을 저렇게 구분하여 인식이 그렇게 퍼진 느낌이 있는데, 토스 외에는 그렇게 구분하는 곳을 찾아보기 힘들 뿐더러 PM과 PO를 구분할 정도로 제품 조직을 굴리는 회사는 찾아보기 어렵다.
다시 말하지만 한국에서 거의 대부분의 회사는 PM과 PO 둘 중 하나의 직무만 존재하고, 여러분이 PM이나 PO 둘 중 어느 잡 타이틀을 달더라도 나머지 한쪽의 직무와 완벽히 호환되므로 두 직무의 차이를 구분하는 것은 의미가 없다 하겠다.
7. Product Manager ≠ Project Manager
PM직무를 얘기해야 할 때 주의해야할 점은 Product Manager와 Project Manager의 차이점이다. 둘 모두 약칭이 PM이고, 하필 똑같이 IT필드에서의 용어이기 때문에 자주 혼선이 발생한다.
약칭은 둘 다 PM이지만 둘은 완전히 다른 직무다. 비유하자면 사슴과 사슴벌레 만큼의 차이랄까.
Product Manager는 이 글에서 내내 썼던 것처럼 고객과 비즈니스를 기반으로 제품에 대한 의사결정을 메인으로 하는 직무다. 고객에게 어떤 제품을 전달할까를 핵심적으로 고민한다.
반면 Proejct Manager는 프로젝트의 성공적인 완수를 메인으로 하는 직책이다. 직무로 존재하는 경우도 있지만 대부분 직책으로서, 본업을 가지고 있으면서 특정 프로젝트의 Project Manager로 선임된다. (SI/외주를 전업으로 하거나 프리랜서 시장에서는 Project Manager를 본업 직무로 하는 경우도 많다)
Project Manager는 고객/비즈니스에 대한 고민보다는, 정해진 프로젝트를 기한 안에 얼마나 성공적으로 끝마치는지를 관리한다. 이들에게는 리소스, task, 일정, 비용 관리 등이 핵심이다. WBS나 Gantt Chart와 같은 프로젝트 관리 시트가 메인 산출물이다.
마치며
글 쓴 시점을 기준으로 국내에 Product Manager라는 직무가 본격적으로 도입된 것은 아무리 넉넉히 잡아도 아직 10년이 안되었다. 그러다 보니 이 직무에 대한 정보도 적을 뿐더러 오해 역시 상당히 많다. 또 회사마다 각자가 정의하는 Product Manager의 역할이 다르다 보니(앞서 말한 서비스 기획자 이슈), 이러한 정보들이 꽤 파편화되어 있기도 하다.
그러한 배경에서, 취준생과 초년생, PM으로의 이직을 꿈꾸는 독자에게 이 글이 조금이라도 도움이 되길 바란다.
#PM, #PO, #Product Manager #서비스기획자
