본문 바로가기
Planning

서비스 기획자 vs. PM vs. PO

by 세균무기 2020. 7. 20.

요즘 기업이나 채용 공고에서 IT서비스를 기획하는 기획자를 지칭하는 표현이 너무 제각각이다.
어디서는 '서비스 기획자'라고 부르는데, 또 어디서는 '프로덕트 매니저(PM, Product Manager)'라 부르고, UX에 대한 중요성이 강조되다 보니 'UX기획자'나 'UX디자이너'로 부르는 곳도 있으며, 최근엔 '프로덕트 오너(PO, Product Owner)'라는 표현도 눈에 자주 띈다.
채용 공고를 읽어보면 하는 일이 다 비슷비슷한 것 같은데 왜 이렇게 표현이 다를까?

재미있는 사실은 정작 해당 직군에 종사하는 기획자들도 그렇고, 기획자를 채용하는 회사들도 정확히 구분해서 사용하고 있지 않다는 것이다. 그러니 보고 듣고 쓰는 모든 사람들이 헷갈릴 수밖에.
물론 회사 입장에서는 부르고 싶은 데로 불러도 회사가 요구하는 업무만 하면 되니까 표현이 중요하지 않을 수도 있겠지만 그래도 회사(의 조직 문화나 개발 방법론)에 적합한 기획자를 채용하기 위해서는 적절한 표현을 사용해주는 것이 좋은데 그렇지 못하다.
여하튼 한 기획자로서 이 상황을 보고 있자면 웃프지 않을 수가 없다. :(

 

 

서비스 기획자와 프로덕트 매니저, 프로덕트 오너는 분명 다르다!

 

그런데 서비스 기획자와 프로덕트 매니저, 프로덕트 오너의 역할과 그 차이점을 여러 사람들이 설명하려 들지만 그 설명에 '대한민국이라는 지역적 특수성'과 '시간의 흐름에 따른 개발 환경과 개발 방법론의 변화'에 대한 이야기가 전제로 깔려있지 않다면 제대로 이해하거나 설명하지 못하고 있는 것이 분명하다. 
시간의 흐름에 따른 개발 환경과 개발 방법론의 변화에 약간의 지역적 특수성이 결합되어 기획자에게 요구되는 역량과 역할이 변화하였고 이에 따라 기획자 직군을 표현하는 용어도 변했기 때문이다.

 

 

 

라스트 제다이와 같이 사라진 웹마스터,

그리고 포털 서비스와 함께 성장한 서비스 기획자


서비스 기획자는 간단한 랜딩 페이지나 게시판 등의 웹서비스를 개발하던 웹 1~2세대, 즉 1990년 대 이전까지 프로젝트의 관리 및 개발, 디자인까지 모두 담당 또는 총괄하던 (네이밍마저도 신화 속의 존재 같았던) '웹마스터(Webmaster)'라는 직군에서 서비스가 대규모 포털 서비스로 성장하고 발전하며 분업화된 직군 중 하나이다. 서비스의 규모가 커지고 구성원들이 늘어나며 업무가 세분화되고 관리 업무가 많아지면서 등장한 직군인 것이다.


영미권에선 웹마스터에서 애자일 스크럼 개발 방법론의 등장과 함께 프로덕트 매니저로 분업화되었지만 국내에선 애자일 스크럼 개발 방법론을 받아들이기엔 상명하복의 경직된 의사소통, 복잡한 보고 체계, 부서 간의 이기주의, 연공서열식 평가제도 등 매우 수직적이고 폐쇄적인 기업문화로 인해 프로덕트 매니저가 아닌 중간 관리자가 필요했으며, 개발자보다는 경영진이나 여러 구성원들과 의사소통이 수월하고 비즈니스를 빨리 이해할 수 있는 경상대 출신 등의 문과대 출신이 중간 관리자로서 등용되었다. 이렇게 등용된 관리자들이 IT업종에서 경영진과 개발자, 퍼블리셔, 디자이너, 운영자, 마케터, AE, CS 등 여러 구성원들과 커뮤니케이션을 하면서 서비스 기획자로 자리를 잡게 된 것이다. 그렇게 한국의 문과대 출신 기획자들이 등용되고 포털의 성장과 함께 성장하며 1990년 대를 거쳐 2000년 중반까지 한국형 서비스 기획자 전성시대를 누리게 된다. 
그리고 이들은 개발 및 퍼블리싱, 디자인 업무를 제외한 데스크 리서치, 유저 인터뷰, 벤치마킹 등을 통한 서비스 전략 수립부터 서비스 정책 은 물론이거니와 와이어프레임을 포함한 스토리보드 작성, 프로덕트 매니징, QA 진행, 운영, 고도화 등 웹서비스의 A부터 Z까지 모든 영역에 깊숙이 참여하며 웹서비스의 핵심 직군으로 자리를 잡을 수 있었다.

 

 

모바일이 쏘아 올린 스타트업 전성시대,

린스타트업 문화와 애자일 스크럼 개발 방법론의 확산으로 등판한 프로덕트 매니저

 

2009년 아이폰의 등장과 함께 스마트폰이 빠르게 보급되며 규모도 작고 리소스가 부족한 스타트업들이 우후죽순 등장하였다. 스타트업 전성시대가 시작된 것이다. 스타트업에서는 포털의 서비스 기획자를 중심으로 하는 워터폴 방식으로는 비용 대비 효율성도 떨어지고 리스크 관리도 어려운 데다 부족한 리소스로 인해 포털이나 큰 IT기업에서 일하는 좋은 서비스 기획자를 채용하기도 쉽지 않았다. 
때문에 린스타트업, MVP 등이 지지를 얻으며 작고 빠르게 프로젝트를 실행하고 검증하는 애자일 스크럼 개발 방법론이 확산되기 시작했으며 A부터 Z까지 모두 참여하고 책임지는 워터폴 문화에서의 서비스 기획자보다는 최대한 수평적이고 자율적인 조직 문화를 장점으로 내세우며 칸반 보드를 통해 백로그와 이슈 기반의 프로덕트 매니징, 즉 실행에만 집중하는 프로덕트 매니저의 역할이 강조되기 시작했다.
또한 서비스 기획 및 개발의 복잡도도 높아지고 대응해야 할 OS도 늘어나다 보니 한 서비스 기획자가 감당하기 버거울 정도로 업무 범위도 넓어져 이를 모두 처리하기 어려워진 상황에서 웹과 모바일 둘 다 경험 있는 서비스 기획자를 스타트업이 채용하기도 쉽지 않다 보니 결국 경험이 부족한 주니어 기획자를 채용하여 기획 및 프로덕트 매니징을 맡겼고 포털의 서비스 기획자 역량을 기대하기엔 역부족이었으니 프로덕트 매니징 역할 정도를 기대할 수밖에 없었다. (그래 놓고 한편에서는 서비스 기획자의 역량을 기대하며 잊을 만하면 무용론을 언급하고 있다.)

 

그리고 이렇게 성장한 스타트업에서 한 서비스 기획자가 처리하던 업무를 상위 기획자 또는 전략 기획자라고 일컫는 사람들에게 일부를, 와이어프레임과 목업 등을 만드는데 집중하는 UX기획자 또는 UX 디자이너에게 일부를, 애자일 스크럼 개발 방법론을 도입하며 프로덕트 매니징에 집중하는 프로덕트 매니저에게 일부를 분할하며 더 세분화하기 시작한 것이다.

 

 

애자일의 실패를 경험하며 성장한 스타트업에서 등장하고 있는 프로덕트 오너

 

그런데 최근 스타트업들도 성장을 하며 사업 규모가 커지고 구성원들이 많아지는 데다 애자일 스크럼으로 대표되는 개발 중심 문화로는 빠른 비즈니스 환경의 변화나 회사의 전략에 빠르게 대응하지 못하고 의사 결정이 비효율적이며 빠른 업무 진행이 어렵다 보니 개발 방법론에는 애자일 스크럼을 적용하더라도 의사 결정과 매니징 등은 워터폴로 회귀하는 경향을 보이며 빠른 의사결정에 대한 권한과 그 의사결정에 책임을 지는 프로덕트 오너라는 표현이 등장하기 시작했다.
그래서 프로덕트 오너의 등장은 개발자 중심의 스타트업 문화가 규모가 커지면서 실패를 경험하고 축적하며 이를 해결하기 위한 방법론으로 워터폴로 회귀하는 과정인 것이다.

 

이는 어떠한 방법론이 확산되어 일반화되면 문제들이 반복, 재상산 되면서 무용론이나 이를 개선하려는 노력들이 등장하며 정반합을 따르기 마련인데 프로덕트 매니저의 등장이 스타트업 환경에서 워터폴의 실패에 기인했다면, 프로덕트 오너의 등장은 성장한 스타트업이 경험한 애자일의 실패에 기인했다고 볼 수 있다.

그래서 프로덕트 오너라는 표현을 쓰는 쿠팡이나 토스와 같은 조직은 애자일 스크럼 개발 문화를 가지고 있다지만 비즈니스 프로세스나 의사 결정은 워터폴에 가깝다고 할 수 있다.

 

때문에 회사는 자신의 회사가 어떠한 조직 문화와 개발 방법론을 채택하고 있는지에 따라 어떠한 업무를 담당하는 포지션이 필요한지 명확히 제시해야 할 필요가 있고 기획자들도 자신이 어떠한 역량에 강점을 가지고 있는 기획자인지 정확히 인지해 서로 Fit이 맞는 구인과 구직을 할 필요가 있는 것이다.

반응형

'Planning' 카테고리의 다른 글

서비스 지표 정리  (5) 2020.08.11
UX Writing 가이드  (11) 2020.07.24
서비스 기획자를 위한 툴  (24) 2020.04.26
기획자의 데이터 분석  (7) 2020.04.05
이렇게 기획하면 안 돼요! #다크패턴  (6) 2020.03.30

댓글5

  • 깔끔한 정리 감사합니다!
    답글

  • 와우 2020.12.17 15:10

    기획자, PM, PO에 대해 모호한 설명들 밖에 없었는데 제가 본 글 중 가장 명확하고 깔끔하게 정리해놓으셨네요. 글 잘 읽었습니다. 감사합니다!!
    답글

  • 기획 최고 2022.05.07 15:59

    안녕하세요 세균무기님! 좋은 글 덕분에 직무에 관련해서 명쾌하게 이해되었습니다.
    그런데, 프로덕트 오너가 등장한 배경과 관련해서 개발에서는 애자일 방법론이 유용하지만
    비즈니스나 의사결정 업무에서는 애자일 방법론이 비효율적이기 때문이라고 하셨는데,
    어떤 문제가 발생하는지 사례를 말씀해주실 수 있을까요??
    사례가 있다면 조금 더 쉽게 이해할 수 있을것 같습니다.

    감사합니다.
    답글

    • Favicon of https://germweapon.tistory.com BlogIcon 세균무기 2022.05.08 16:21 신고

      답변에 앞서 저는 특정 방법론이 나쁘거나 비효율적이라고 생각하지는 않습니다.
      워터폴이든 애자일이든 모든 방법론에는 장단점이 있으며 이는 회사의 도메인이나 조직의 구성, 리소스, 구성원 등에 따라 적합한 방법론을 채택하고 운영하며 최적화하는 과정이 중요하다고 생각합니다.

      부족한 리소스로 실패에 대한 리스크를 줄이며 제품 개발이 중요한 초기 스타트업은 경영진의 의지이든 구성원들의 합의에 의해서든 채용 경쟁력을 높이기 위해서든 애자일 & 스크럼 개발 방법론을 채택하곤 하는데 특정 방법론을 운영하다 보면 여러 문제들이 누적되기 마련입니다. 게다가 회사가 성장하며 조직의 규모가 커지고 제품 개발이 일정 완성도에 도달하면 제품 개발보다는 사용자의 니즈나 시장의 변화를 반영하고 경쟁사들과의 경쟁에서 승리하기 위해 전략적 판단과 의사결정, 그리고 권한과 책임 부여를 통해 이를 빠르게 실행하는 것이 중요해집니다. 때문에 프로덕트 오너에게 강력한 권한을 부여하고 빠른 의사결정 및 실행을 할 수 있도록 한 것입니다.

      ICE Scoring 등을 통해 Task간 우선순위를 결정하거나 Planning Porker를 치며 Story Point를 부여하는 등 Product Planning meeting을 진행하는 과정들이 수평적인 문화를 유지하는데 도움이 되는 것은 사실이지만 이런 의사결정 과정들이 사실 빠른 의사결정을 방해하거나 중우 정치로 전락할 수 있으며 권한이 분산되어 책임을 묻기에도 어려울 수 있기 때문에 의사결정에 강력한 권한과 책임을 부여한 프로덕트 오너가 등장했다고 생각합니다.

      애자일 & 스크럼 ‘개발 방법론’이라고 부르는 것처럼 이는 제품 개발에 최적화된 방법론이지 제품 개발이 완료되어 운영을 위한 비 IT직군이 늘어난 시점에 모든 직군에 애자일 방법론을 적용할 수도 없고 비 IT직군과의 협업이 필요한 상황에서 빠른 의사결정 및 실행에 대한 비즈니스적인 요구가 프로덕트 오너를 등장시켰다고 봅니다.

    • BlogIcon 기획최고 2022.05.09 12:00

      상세한 답변 정말 감사합니다!!