개발자가 읽어본 '서비스 기획 스쿨'

최근 레거시 서비스를 정리하며, 타부서 또는 타조직의 협업이 잦아졌습니다. "그들에게 '도메인'에 대한 답이 어느 정도 있겠지"라는 제 기대와는 다르게 저와 큰 차이가 없다는 사실을 인지하게 되었는데요. 아마도 외주 운영이던 서비스가 내재화되었기에 관리는 익숙하나 실무와는 멀었구나하고 이해했습니다.

 

동시에 커뮤니케이션과 서비스의 방향성이 잘 정리되어 있지 않다는 느낌을 많이 받았습니다. 여러 원인이 있겠지만, 저에게는 '해당 서비스를 담당하는 기획자의 부재'가 크게 다가왔습니다. 그 부분을 조금이라도 이해하고 정리라도 해야겠다는 마음을 먹었는데, 기획자와 관련해 좋은 책을 발견해 읽고 이 글에서 책 내용을 중심으로 개인적으로 이해한 언어로 정리해보려 합니다. 

 

• 서비스 기획자란?
• 서비스 기획의 프로세스

 

책 '서비스 기획 스쿨'

---

서비스 기획자란?

'기획자'는 '기획을 하는 사람'이라는 의미입니다. 기획이란 '일을 꾀하여 계획'하는 것을 의미하는데요. 이러한 '기획'이라는 단어에 관련되는 영어단어로는 plan, design, project, manage가 있으나 모두 미묘하게 다른 의미를 전달합니다. 이는 영미권이 주도한 IT 산업에서 기획자에 의미상으로 매칭되는 role을 찾기가 어려운 이유입니다. 하지만 Job Description으로 볼 때, 유사한 'Product Manager'라는 role이 존재합니다. 

 

사실 기획자라는 명칭은 일본에서 건너왔습니다. 서구의 팀제가 도입되기 전까지 우리나라의 부서 제도는 일본과 유사하였는데요. 우리나라에서 기획이라는 이름의 팀은 전략을 설정하고 신사업을 주도하며 새로운 프로젝트를 발주하는 역할을 해왔습니다. 

 

좀 더 구체적으로, '서비스 기획자'는 기획자에 속한 '전략 기획자', '마케팅 기획자'와는 또 다른 범주에 속하게 되는데요. 초창기 온라인 서비스의 경우 내부에 인력이 없으면 에이전시와 외주 SI/SM 업체를 통해서 진행했기에 이 때의 '서비스 기획자'는 주로 발주만 담당하였습니다. 이후 모바일 중심의 온라인 서비스가 핵심 비즈니스로 떠오르며, 효과적인 운영을 위한 UX 관리 역량이 강조되며 '인하우스' 기획자들은 UX와 비즈니스를 연결시키고 외주 기획자들이 했던 상세한 실무 프로젝트에도 참여하게 되었습니다. 기존의 웹기획 또는 프로젝트 매니징이라는 부분이 조금씩 포함되기 시작한 것입니다. 

 

최근에는 의사결정에 있어 'Data-Driven' 기반의 활동이 강화되면서 서비스와 관련한 데이터 분석 일부까지도 기획 업무에 있어 중요한 요소가 되어가고 있습니다. 

 

서비스 기획자는 어떤 이해관계자와 무엇을 목적으로 어떤 일을 하나?

많은 사람들이 '서비스 기획'이라는 타이틀을 보면, 스티브 잡스와 같은 세상에 혁신을 만드는 일을 하는 것으로 오해하곤 합니다. 하지만 서비스 기획은 '전략 기획'이 만들어 놓은 비즈니스 모델에 기반하여 끊임없이 실제로 구현과 피드백을 반복하며 모델을 정교화 해나가는 일을 목적으로 합니다. 그렇기에 전략 기획이 모두가 지향할 높은 비젼을 제시한다면, 서비스 기획은 그 비젼을 바라보고 현실화하기 위해 고객과, 팀원과, 현실 사이에서 끊임없이 노를 젓는 일을 합니다. 

 

구체적으로 서비스 기획에서는 다음과 같은 사항들을 고민합니다:

 

• 서비스 핵심 전략과의 얼라인먼트: 서비스 기획은 비즈니스의 '핵심 전략'에 기반합니다. 예로, 구글은 '사용자에게 최적화된 검색환경을 통한 트래픽과 광고'라는 핵심 전략에 따라 간결하고도 단순한 검색창만을 제공합니다. 이와 같이 서비스 기획의 세부적인 요소는 대전제인 '비즈니스 모델'과 얼라인먼트 되어야 합니다. 

 

• 개발환경과 비용: 서비스 기획은 지속적으로 개발환경에 변경을 만들게 되고, 그러한 변경들은 하나씩 쌓여서 추후 변경에 있어서의 기반이 되기도, 제약이 되기도 합니다. 그렇기에 어떠한 형태의 기획 요구사항은 현재의 개발환경에서 불가능한 것일 수도 있고, 많은 비용을 발생시키는 변경이 필요하거나 변경 이후 시스템에 장기간 제약사항으로 남을 수도 있습니다. 이러한 점에서 기획은 개발환경과 비용을 항상 고려하며 '얼라인먼트'를 고민하여야 합니다. 

 

기획자가 일하는 2가지 형태: 인하우스 또는 에이전시

기획자는 크게 2가지 형태의 환경 속에서 일을 하게 됩니다. 인하우스는 서비스 주체인 기업의 일원으로 서비스 기획을 담당하거나 발주를 담당하는 형태입니다. 에이전시는 서비스 아웃소싱을 요청받는 대행사의 일원으로 (주로) 발주자의 요청에 맞춰 서비스 기획을 담당하게 됩니다.

 

인하우스	에이전시
서비스 주체 기업의 일원으로 직접 서비스 기획 또는 발주 담당	대행사의 일원으로 아웃소싱 받아 서비스 기획 담당
소수의 프로젝트를 장기간 (좀 더) 주체적으로 경험	다양한 프로젝트 경험
서비스 생애주기 관점에서 end-to-end를 고민해볼 수 있음	주어진 요청사항에 맞게 (주로) 새로운 서비스를 만들어 내는 부분을 배울 수 있음

 

 

 

서비스 기획의 프로세스

앞서 살펴본 바와 같이, 서비스 기획은 해외의 '프로덕트 매니징'과 유사합니다. 그렇기에 '프로덕트'를 만드는 과정인 '프로젝트'의 관리 방법을 따르게 됩니다. 서비스 기획의 가장 첫 단계에는 이러한 '프로젝트' 관리 방법의 선택이 존재합니다.

 

프로젝트 방법론: 워터폴과 애자일

프로젝트 방법론에는 크게 2가지 방식이 존재합니다.

 

먼저 워터폴 방법에서는 '기획-디자인-개발-테스트-출시'의 사이클에 고정된 기간을 할당하여 한 번의 사이클로 프로젝트를 관리합니다. 단계가 명확히 구분되고, 일정이 매우 고정되어 있기에 오픈 일정을 맞추기가 용이하다는 장점이 있습니다.

 

애자일 방법론은 '기획-디자인-개발-테스트' 사이클을 2 ~ 3주 정도의 스프린트 단위로 잘라서 이해관계자 간에 밀접한 커뮤니케이션과 피드백을 통해 서비스를 만들어 나가는 방식입니다. 문서화 시간을 줄이고, 개발된 산출물을 빨리 살펴볼 수 있는 점, 빠른 피드백을 통해 빠르게 진화하는 서비스를 만들 수 있다는 점 등의 장점이 존재합니다. 

 

기획 요구사항 정의 및 분석

보통 기획 업무는 유관 부서의 서비스 개선요청이나 새로운 업무를 위한 시스템 변경 요청으로 시작됩니다. 이 유관 부서의 담당자는 대개 IT와는 거리가 있는 직무입니다. 그렇기에 요구사항을 받는 시점에 정확하게 '기획의 언어'로 요구사항을 이해하는 것이 필요합니다. 또한, 요구사항 자체가 너무 추상적이거나, 현재의 개발환경에서 불가능하거나 많은 비용을 발생시킨다면 이 시점에서 조정을 진행할 수 있어야 합니다.

 

그리고 UX, 데이터, 서비스 핵심 전략 측면에서 분석을 진행하게 됩니다. 기획자는 타부서의 요청을 그대로 수행하기만하는 단순한 오퍼레이터가 아닙니다. 기획자의 역할은 여러 부서에서 발생하는 요청들의 최종 목적을 이해하고, 실제로 그러한 목적이 현재 환경에서 어떻게 가능할지 구체화하여 하나의 서비스를 진화시켜나가는 것에 있습니다. 그렇기에 다양한 측면의 '분석'을 통해 목적을 위하여 정확히 판단하여 '서비스 전략'을 세워야 합니다.

 

서비스 프로세스 설계

다음은 요구사항 정의와 분석을 통해 찾아낸 것을 더욱 구체화하여야 합니다. 이 시점에서 UI와 같은 화면설계보다는 '데이터, 기능, 목표'라는 관점으로 기획을 프로세스로 정의하게 됩니다. 구체적인 내용은 '마인드맵'을 활용하여 아래와 같이 단계별로 그려볼 수 있겠습니다:

 

1. 필요한 기능 및 데이터 정의
2. 내부 및 외부 사용자별(또는 여러 권한이 다른 사용자별) 플로우 정의
3. 정보 구조(IA, Information Architecture) 작성

 

개발 및 디자인 요구사항 정의 및 요청

프로세스 설계가 진행되었다면 개발자와 디자이너에게 요청사항을 전달하여 실제 서비스를 구축해나가게 됩니다. 그러한 부분은 각 직무에게 '소프트웨어 요구사항 정의서', 'UI 설계서'를 통해서 요청하게 됩니다.

 

또한, 해당 서비스에 대한 여러 이해관계자와의 커뮤니케이션을 위해서 '화면설계서'와 '사용자 스토리'를 작성합니다.  이러한 산출물은 기획자가 설계한 하나의 설계도를 바라보고 개발자, 디자이너 등이 '얼라인먼트' 되도록 해줍니다.