Article Image
read

우리나라 소프트웨어 개발업계에서 혼란스러운 직함을 하나 고르라면 기획자일 것이다. 무슨일을 하는지 조직마다 다르며, 부서마다 다른 경우도 많다. 다른 직군과 의사소통이 어렵다는 글들이 인터넷엔 넘쳐난다.

이 글을 쓴 이유도 기획자 역할을 정리 해 봄으로써, 커뮤니케이션을 원활히 하고 기획자의 생산성을 높이는 데 있다. 우선 기획자의 역할에 대한 의견들을 모아 정리하고, 소프트웨어 공학 그 중에서도 애자일 팀에서 정의된 역할들을 가져와 대입해 보려고 한다.

기획자는 ?? 을 하는 사람이다.

인터넷 검색을 통해 찾아본 기획자의 역할에서 가장 큰 비중을 차지하는 것은 프로젝트의 개발 방향을 정하는 사람이었다. 아래 관련 내용들을 인용한다.

  • 결국 기획자는 디자이너와 개발자를 납득을 시키고 이 방향성으로 가야 하는 이유를 내놓아야만 하는 사람이다 (출처)
  • 기획자는 first user, ‘첫번째’ 사용자입니다. (출처)
  • 서비스 운영과 개발에 필요한 내용을 문서화 한다. (출처)
  • 서비스에 대한 정책을 정하고, 프로세스를 설계한 후 스토리 보드로 작성하는 것이다. (출처)

그 다음 많았던 의견은 사업을 만들어 내는 사람이라는 것이었다. 아래에 관련 내용들을 인용했다.

  • 사업을 통째로 만들어 내는 일이다. (출처)
  • 미래에 대한 예측을 포함하는 조직화된 노력이다.
  • 기획이란 “통찰력, 계획적인 사고, 조사를 통해서 문제를 해결하고 앞으로 발생할 문제를 해결하기 위한 의도적인 시도이며, 다양한 행동 노선 중에서 어떤 노선을 취할 것인가에 대한 가치선호를 행사하는 것”이라고 규정하고 있다(출처)

그외에 개발진행상황을 확인하는 사람이라는 의견(출처) 과 생각을 정리하는 일을 하는 사람이라는 의견(출처)도 있었다.

정리하자면 다음과 같다.

  • (기획자는) 프로젝트의 개발방향을 정하는 사람이다.
  • (기획자는) 사업을 만들어내는 일을 하는 사람이다.
  • (기획자는) 프로젝트 진행 관리를 하는 사람이다.
  • (기획자는) 운영과 개발에 필요한 문서를 작성하는 사람이다.
  • (기획자는) 생각들을 정리하는 사람이다.

Product Owner, Program Manager

2008 년에 쓰여진 Agile Team Members – Roles and Responsibilities 이 글에 활용할 수 있는 역할 개념들이 잘 정의되어 있다. 이 중 논의되고 있는 것과 관련 있어 보이는 것들을 가져와 봤다.

먼저 Product Owner (또는 Product Manager, 이하 줄여서 PO) 다. 이 역할은 해당 제품의 CEO 라고 할 수 있다. 제품에 대한 장기 및 단기 비전을 가지고 있고, 고객을 대변하는 일을 한다. 개발된 제품을 외부에 알리기 위한 일도 여기에 포함된다. PO 는 트레이드오프가 발생하는 제품상의 의사결정을 한다.

(Product Manager 가 일반적으로 더 많이 쓰이는 용어고, Product Owner 는 스크럼 같은 애자일 방법론에서 쓰고 있는 용어이다. 뒤에 설명할 Program Manager 와 약자표기가 동일한 문제가 있어 이 글에서는 Product Owner 를 사용하고 있다.)

그 다음은 Program Manager (이하 줄여서 PM) 다. 프로젝트에 속한 다양한 직군의 그룹들이 문제를 해결하도록 독려하고 이끄는 역할을 한다. 적절한 기능을 적절한 시간 안에 출시하는 것이 주임무다. 때로는 프로젝트의 스케줄을 산정하고 릴리즈 계획 등도 세우며, 프로젝트의 진행상황을 관리한다. PM 은 PO 가 만든 의사결정을 기반으로 해서 이를 실행하는 일을 한다.

PO 와 PM 은 어떻게 다를까? 하나의 평면 좌표 체계를 생각해보자. 제품이라는 세로 축과, 팀이라는 가로축을 놓고 본다면, PO 는 세로로 길게 일을 하는 역할이고, PM 은 가로로 넓게 일을 하는 역할이라고 볼 수 있다. PO 는 하나의 제품에 있어 전문가라고 볼 수 있다면, PM 은 여러개의 제품을 만들어 내는 팀전문가라고 할 수 있다.

다시 돌아와서, 기획자는 ?? 을 하는 사람이다.

앞에서 나온 기획자의 역할을 이 두가지 기준으로 다시 정리해보자.

  • 프로젝트의 개발방향을 정하는 사람이다. (PO)
  • 사업을 만들어내는 일을 하는 사람이다. (PO)
  • 프로젝트 진행 관리를 하는 사람이다. (PM)
  • 운영과 개발에 필요한 문서를 작성하는 사람이다. (PM)
  • 생각들을 정리하는 사람이다. (PM)

보다시피 PO 로서 기대하는 일들이 있고, PM 으로서 기대하는 것들이 있다. PO 로 분류된 일들은 어떤 제품을 만들어 낼지 결정하는 것들이고, PM 으로 분류된 일들은 제품을 내놓기 위해서 진행되는 절차상의 관리 작업들이다.

기획 작업의 산출물도 마찬가지로 나눌 수 있다. 사업계획서 또는 제품계획서의 경우 PO 로서 기획자가 만들어내는 산출물에 해당할 것이다. 한편 기능 명세서, UI 명세서 등은 PM 으로서 기획자가 만들어내는 산출물이라고 보면 된다.

기획 이전에 전문성부터

기획 업무의 혼란은 한 사람의 기획자가 PO 역할과 PM 역할을 동시에 맡을 때 발생한다. 그때그때 다른 역할을 하는 것은 무척 어려운 일이다. 프로젝트를 진행하며 PO 와 PM 이 바라보는 관점이 다른데, 이 컨텍스트 스위칭에 큰 비용이 들어가기 때문이다.

다행히 기획팀이 존재하여 다수의 기획자들이 해당 역할을 나눠가진다면 문제가 되지 않겠으나, 그렇지 않은 경우 혼란이 발생한다. 특히 인력이 부족한 스타트업에서 자주 발생할 가능성이 높다.

만약 당신이 신입 기획자로서 커리어를 시작한다면, 자신의 베이스를 명확히 해두라고 조언하고 싶다. PO 인가 아니면 PM 인가 정해야 할 것이다. 그리고 해당 역할에서 충분한 전문성을 확보한 다음, 영역의 확장을 통해 다른 역할로 넓혀 갈 수 있을 것이다.

경험이 충분치 않은 상태에서 PO 와 PM 역할을 동시에 한다는 것은 스스로에게 독이 되는 행위이다. 많은 경험을 통해 커리어의 고속성장을 할 것 처럼 보이지만, 커리어가 망가질 리스크가 크고 그 만큼의 비싼 댓가를 치룰 수 있다.

기획자에게 일을 시키는 입장이라면, 이 사람이 어떤 모드로 동작하길 기대하고 있는지 명확히 해두고 커리어패스를 잡아줘야 한다. 만약 일하고 있는 조직의 상사가 두가지 역할에 대해 구분하고 있지 않다면 여기에 대해 진지한 상담을 하여 결정을 내려야 할 것이다.

작은 조직이라면 다른 사람의 참여로 풀어보자.

논의의 범위를 스타트업으로 줄여보자. 다행히 스타트업은 생존을 위해 애자일한 개발방법론을 택하는 경우가 많고, 애자일 개발은 역할 간의 겹치는 영역을 중시한다. 역할간의 겹침을 통해 전체적인 커뮤니케이션 비용을 낮추는 것이다.

만약 당신이 PM 지향적인 기획자라면, 제품의 방향과 관련된 일들은 대표이사나 마케팅 또는 세일즈 팀의 담당자들과 함께 해결하도록 하자. 반대로 PO 지향적인 기획자라면 개발팀 담당자나 디자인 담당자와 함께 PM 의 일들을 풀어보자.

이 때 주의할 것은 도움을 받아 다른 업무를 떠안는 것이 아니라, 모두의 참여로 문제를 풀어갈 수 있는 운영자 역할을 하는 것이다. 본인의 기본 역할에 대해서 잊지 말아야 하고, 여기에 대해 주변 동료들과 공감대를 만들어 둬야 커뮤니케이션 상의 혼란을 방지할 수 있을 것이다.

참고글

Blog Logo

Ki Sung Bae


Published

Image

Gsong's Blog

Developer + Entrepreneur = Entreveloper

Back to Overview