10년이 넘게 마케팅과 신사업 기획, 플랫폼 기획, 광고 기획 등을 진행하면서 경험한 서비스 관련 경험 사례를 통해 서비스 기획을 정리하려 합니다. 우선 전체 서비스 기획 그림이 한눈에 들어올 수 있도록 정리한 후 세부 내용은 다른 글에서 자세히 작성하겠습니다.
서비스라는 용어의 정의는 기업 또는 업종에 따라 조금 다르게 사용하기도 합니다. 여기서는 서비스를 웹 또는 앱으로 제공되는 기능의 집합체로써 사용자가 느끼는 차별적이고 가치 있는 경험이라고 정의하겠습니다.
웹 또는 앱에서 기능을 제공하더라도 단순히 앱으로 식당을 검색하고 주문하는 기능이 아니라 배달의 민족, 쿠팡 이츠처럼 각 앱의 배달 경험이 차별적이고 사용 유저가 돈을 낼 만한 가치의 경험을 제공하는 것을 서비스라 하겠습니다. 전자는 앱 개발로 서비스 이루어질 수 있는 공간과 기능을 만드는 것으로 구분합니다.
서비스 기획의 시작 - 비즈니스(사업) 기획
서비스 기획을 위해서는 서비스 대상과 목표를 구체화할 비즈니스 기획이 있어야 합니다. 흔히 비즈니스 기획 문서는 무엇을 해서 돈을 벌 것인가에 대한 실행 문서를 의미합니다.
비즈니스 문서에는 비용과 수익 항목으로 크게 구분이 됩니다. 비용은 서비스 제공을 위한 것이고 수익은 서비스 제공에 하면서 발생하는 사용 유저들의 구매를 통해 생깁니다.
이 과정을 가치를 생산하는 과정과 교환하는 과정으로 구분하여 볼 수 있으며, 이를 도식화한 것을 비즈니스 모델 캔버스라고 합니다. 서비스 기획은 가치를 생산하는 과정에 대한 기획 문서라고 할 수 있습니다.
어떤 서비스를 제공할 것인가?
비즈니스 기획이 완료되었다면 이에 따라 어떤 서비스를 제공할지에 대한 기획을 진행합니다. 이 단계에서부터 본격적인 서비스 기획이 시작된다고 보아도 맞을 것입니다.
서비스 기획은 크게 다음 세 가지 질문을 통해 그림을 잡아가기 시작합니다.
- 누구에게 제공할 서비스인가?
- 무엇을 제공할 서비스인가?
- 어떻게 제공할 서비스인가?
누구는 핵심이 되는 목표 사용 유저를 의미합니다. 누구에게 제공할 것인가를 통해 핵심 기능과 서비스 프로세스가 결정될 수 있습니다.
무엇은 배달 서비스인지, 쇼핑 서비스인지 등 서비스 범위를 규정하는 질문이 됩니다.
누구와 무엇이 결합되면 서비스가 진행될 시장이 결정되고 그러면 경쟁해야 할 다른 서비스도 구체적으로 규정할 수 있게 됩니다. 더하여 핵심 기능과 프로세스, 경쟁 우위를 위해 여기에 추가해야 하는 기능과 프로세스 등이 구체적으로 도출될 수 있게 됩니다.
어떻게는 서비스 개발 방법에 대한 것이자 비용에 관한 질문입니다. 서비스 구현을 위한 기업 내 자원 상황을 파악하여 시장 내 경쟁 서비스보다 나은 가치를 제공할 서비스 개발 방법을 선택합니다.
MVP와 핵심 기능
스타트업이 되었던, 대기업이 되었던 서비스 기획의 시작은 가치를 구현할 핵심 기능이 무엇인가에서 시작되어야 합니다. 많은 대기업 서비스 개발 프로젝트가 수 십억 때로는 백억 원이 넘는 개발 비용을 투자하고도 실패하는 것은 처음부터 너무 많은 기능과 화면들을 개발하려고 하기 때문입니다.
프리랜서로 개발 프로젝트에 참여해 보면 3~4명의 스타트업도 만들 수 있는 정도의 개발 결과물을 수십 명이 만들고 있는 것을 보게 됩니다. 어떤 기능은 개발에 참여한 어느 누구도 왜 개발해야 하는지도 모르는 경우도 있습니다. 한 번은 상황 파악을 위해 고객 TF팀과 미팅을 하는데 고객도 지금 왜 해당 기능을 개발하고 있는지 모르겠다고 이야기하는 프로젝트도 있었습니다.
이런 개발 프로젝트는 대부분 벤치마킹 대상이 되는 유명 서비스가 존재합니다. 벤치마킹 해당 기업이 수년을 고민하고 사용자 데이터를 분석해 가면서 만들어 낸 서비스를 앱만 둘러보고 1년에 만들려고 하기 때문에 문제가 되는 것입니다.
대부분의 서비스는 처음부터 복잡하지는 않습니다. 처음에 간단하던 서비스가 사용자가 늘어나고, 많아진 사용자만큼 충분히 경제성 있는 요구가 발생하면서 제공하는 서비스 종류가 늘어나게 됩니다. 이렇게 시간이 흐르면 전체 서비스는 복잡해지는 것입니다.
그런데 복잡도는 문제를 일으킵니다. 실제 서비스를 운영해 보면 문제는 복잡도의 제곱 이상으로 발생하게 됩니다. 서비스 기능이 2배 늘면 문제는 4배 늘어나는 것입니다. 그래서 서비스가 커지면 개발자는 그 이상 늘어나는 것이 보통입니다.
그러므로 성공적인 서비스 기획을 위해서는 최대한 간단히 시작해야 합니다. 그리고 기획자는 항상 서비스의 핵심이 무엇인지를 파악하고 기획을 해야 합니다. 서비스 핵심에서 벗어난 기능은 아무리 요즘 인기 있는 기능이라도 과감히 빼야 합니다.
대기업에서 진행하는 대부분의 개발 프로젝트는 서비스 핵심부터 시작하지 않습니다. 대기업 가오가 있기 때문에 일단 화려하고 복잡하게 시작하려고 합니다. 여기서 문제를 가지고 시작하는 것입니다.
물론 서비스 기획의 시작은 MVP인 최소 기능 제품 또는 핵심 기능에서 시작해야 하지만 외주 개발이 되는 순간 고객 담당자와 외주 개발사의 니즈에 의해 그렇게 되지는 않게 되기는 합니다.
서비스 프로세스의 중요성
서비스의 핵심과 서비스를 통해 제공될 사용 유저의 가치를 서비스가 개발되어 운영되기 전에 알 수 있는 방법은 프로세스를 통해서 밖에 없습니다.
서비스 프로세스는 서비스 사용자가 경험할 서비스 가치를 나타내면서, 개발자에게는 무엇을 개발해야 하는지와 어떻게 개발할지에 대한 설계 기반이 되기도 합니다. 또한 서비스 프로세스가 있어야 기능과 기능의 연결과 데이터 이동에 대해서도 파악이 용이해집니다.
결국 서비스 기획은 서비스 프로세스에 의해 구체화된다고 해도 틀린 말이 아닐 정도로 서비스 프로세스는 중요합니다. 그렇다고 정해진 규칙이나 방법이 있는 것은 아닙니다. 비즈니스 목적이나 개발에 적합하게 설계되면 그것으로 족합니다.
그러므로 반드시 비즈니스 기획자와 개발자와 논의는 필요합니다.
디자인, 화면 구조 정의
사용자의 서비스 가치를 제공하는데 디자인, 화면 구조 또한 개발 이상 중요한 역할을 합니다. 그러므로 서비스 기획 문서에는 서비스 디자인 기획 관련 내용이 포함되어 있어야 합니다.
이는 디자이너가 작업하는 내용을 말하는 것이 아닌 디자인 작업 시 룩앤필의 방향성, 반드시 지켜야 하는 서비스 아이덴티티 관련 내용 등을 의미합니다.
또한 사용 유저의 서비스 경험 측면에서 준수해야 할 화면 구조가 있다면 이를 표시해야 합니다.
앞의 내용들이 주로 개발자를 위한 서비스 기획 내용이었다면 이번의 내용은 디자이너를 위한 서비스 기획 내용이라고도 할 수 있습니다. 문서는 이 기준으로 작성되면 충분하고 반드시 지켜야 할 양식이 있는 것은 아닙니다. 만약 기업에 따라 특정 양식이 있다면 그대로 진행하면 됩니다.
서비스 카테고리 정의
IA(Information Architecture)라고 하는 정보 구조 작업으로 간단히 하면 사이트맵으로도 이해될 수 있습니다. 서비스 기획 시 작업되는 정보 구조는 핵심 서비스 프로세스에 기반합니다.
데이터 구조는 ERD 작업을 통해 개발자가 진행함으로 기획자가 작업하는 IA 작업은 서비스 카테고리를 구체화하는 작업에 가까울 것 같습니다. 이 관점에서 본다면 사이트맵이라고 해도 크게 틀린 말은 아닐 듯 생각합니다.
서비스 카테고리 작업은 제공되는 기능을 특성에 따라 묶는 작업에서, 화면을 구성하는 작업, 사용 유저의 이동 경로를 설정하는 작업 관점에서 진행할 수 있습니다.
각 관점에서 진행한 서비스 카테고리 작업의 결과는 같은 모습 같지만 관점의 차이로 세부적 내용에는 차이가 생기게 됩니다. 그렇다고 무엇이 맞다는 것은 없으므로 서비스 기획 상황에 따라 선택하여 진행해도 큰 문제는 없습니다.
서비스 카테고리 작업은 전문 프로그램을 활용하거나, PPT로도 작업할 수 있고, 엑셀로도 작업할 수 있습니다. 엑셀 작업의 경우 개발 시 앞으로 진행할 요구사항 상세화 작업 후 디자인 작업 화면을 도출하는데 활용되기도 합니다.
어떻게 개발할 것인가?
넓은 시각으로 보면 서비스 기획과 개발 기획의 차이는 없지만 좁은 시각으로 본다면 서비스 기획과 개발 기획은 다른 기획 작업으로 구분됩니다. 일종의 서비스 프러덕트 매니저의 업무와 제품 OEM 기업의 개발/생산 관리자 정도의 차이라 할 수도 있을 것입니다.
보통 온라인 서비스 개발이 외주로 진행될 때 서비스 기획은 고객이 하며 개발 기획은 SI에서 진행하기도 합니다. 그래서 서비스 기획자는 개발 목적물을 표현하기 위해, 개발 기획자는 서비스 기획자(또는 고객)의 의도를 파악하기 위해 요구사항 명세서를 작성하기도 합니다.
이때 서비스 기획 시 작업한 문서인 핵심 기능 정의서, 서비스 프로세스, 화면 정의서, 서비스 카테고리 정의, 디자인 아이덴티티 문서가 있으면 개발되어야 할 서비스를 파악하는 것이 용이해집니다.
주의 사항 - 서비스 보안
서비스 기획과 개발 기획의 차이는 문서의 보안 레벨에 있습니다. 서비스 기획의 상당 부분은 높은 보안을 요하는 것입니다. 그러나 개발 기획의 상당 부분은 서비스가 공개되면 누구나 알게 되는 부분으로 높은 보안 사항은 아닙니다.
유저가 서비스를 사용하면서 경험하는 차별적 가치가 단지 기능이나 디자인으로만 이루어지지 않는다는 사실에서 서비스 기획의 보안은 매우 중요한 것입니다. 이는 넷플릭스에서 추천 기능을 적용하여 공개하는 것과 이 추천 기능이 어떻게 작동하는지 알고리즘을 공개하는 것의 차이라 할 수 있습니다.
그러므로 외주 개발사에 전달하는 서비스 기획 문서와 내부적으로 진행하는 서비스 기획 문서는 달라야 합니다. 또한 보안 유지 각서도 반드시 필요합니다. 그래서 외주 개발 시에는 직접적인 서비스 기획 문서보다는 주로 요구사항 명세서로 개발 의뢰를 합니다.
기본적으로 서비스 핵심 알고리즘이나 데이터 관리 시스템은 외주 개발을 하는 것은 추천하지 않습니다.
많은 경우 SI 개발 프로젝트를 참여해 보면 전체를 외주 개발하는 경우가 대부분입니다. 그러기에 대부분의 외주 개발이 시작은 창대하고 마지막은 초라한 경우가 많은 것입니다.
괜히 개발자 연봉이 오르고 있는 것이 아닙니다. 바로 핵심 개발 부분을 개발하고 관리하는 것에서 온라인 서비스의 경우 사용자 경험이 달라지기 때문에 개발자에게 높은 연봉과 스톡옵션을 주는 것입니다.
솔직히 이런 핵심 개발 부분은 외주 개발로 흉내를 내는 정도이지 개발이 불가능하다고 보아도 틀리지 않을 것입니다. SI 개발자가 핵심 기능 개발을 할 수 있는 수준이라면 아마 쿠팡, 배민, 토스, 야놀자 같은 국내 기업이면 연봉 1억 이상에 스톡옵션, 구글이나 페이스북 등의 경우는 연봉 3~4억 원에 스톡옵션까지 제공하면서 모셔갈 것입니다.
요구사항 명세서와 개발 기능 정의, 서비스 정책 파악
특히 외주 개발 시 요구사항 명세서는 개발 목표 서비스를 한정하고 무엇을 최종 결과물로 해야 하는지를 알려주는 기준 자료입니다.
그러나 대부분 서비스 개발 관련 전문가가 아닌 개발 의뢰 고객의 관점에서 작성된 요구사항 명세서는 개발 목적물을 모호하게 표현하는 경우가 대부분입니다. 그러므로 개발 기획자는 요구사항 명세서 상세화를 통해 정확한 고객의 개발 목적물을 파악할 필요가 있습니다. 그리고 고객의 개발 의도에 대한 명확한 규정이 개발 완료 시 발생할 분쟁을 피할 수 있는 길이기도 합니다.
요구사항 명세서는 주로 개발 프로젝트 PM과 기획 PL이 진행하지만, 때로는 PM와 기획 PL이 실제 개발이 아닌 관리 목적으로 투입되는 경우도 있어 참여 기획자는 관심을 두고 있어야 합니다.
내부 개발의 경우 서비스 기획 문서를 통해 개발을 진행하고, 서비스 기획자가 개발 기획자이기도 하는 경우가 대부분이므로 요구사항 명세서가 필요하지는 않습니다.
요구사항 명세서 상세화 작업을 통해 도출되는 결과물은 크게 3종류가 있습니다.
- 서비스 정책
- 개발할 서비스 기능
- 최종 화면
서비스 정책은 전반적인 기능과 화면 개발 시 반영되어야 하는 것이므로 정확히 파악되어야 합니다. 기능과 화면은 백엔드 개발과 프런트엔드 개발의 범위와 규모에 직접적인 영향을 미치므로 또한 정확히 파악되어야 합니다.
요구사항 명세서 상세화는 한 번에 끝나는 것이 아닌 여러 번 협의와 수정을 거칠 수 있으므로 버전 관리가 중요합니다. 상세화 작업 버전 관리가 안되어 있는 경우 처음 요구사항과 최종 요구사항 차이의 근거가 부족하게 되어 분쟁의 소지가 되기도 합니다.
보통 요구사항 명세서는 엑셀로 관리합니다.
기능 프로세스 정의
요구사항 명세서에서 확정된 개발 기능의 프로세스를 정의하는 작업입니다. 위의 서비스 프로세스가 사용 유저의 경험 극대화를 위한 프로세스였다면, 여기서 진행할 프로세스는 개발 기능의 프로세스로 차이가 있습니다.
- 서비스 경험 프로세스 - 가치 형성을 중심으로 기획
- 기능 개발 프로세스 - 유저가 사용할 기능의 작동 과정과 그 기능과 연관되는 기능들의 관계를 중심으로 기획
기능 프로세스는 단순히 그 기능을 사용하는 유저의 과정을 구체화하는 것이 아닙니다. 이 과정에서 기능의 작동과 데이터의 형성, 조회, 변경, 저장 그리고 다른 기능과 연동 사항까지 꼼꼼히 작업합니다.
IA(Information Architecture)
제가 작업했던 외주 개발 프로젝트에서는 IA 작업을 사이트맵 정도이거나 최종 개발할 화면을 확정하는 관점에서 작업 정도 었습니다. 그래서 요구사항 명세서 상세화 작업만 잘해놓아도 어느 정도 IA는 작업이 되었습니다.
문제는 기획 PL 요구사항 명세서 상세화 작업을 하지 않거나, 요구사항 명세서를 고객이 아니라 기획 PL 의도대로 작성하는데에서 발생했습니다.
개인적으로 개발 작업했던 것 중 IA가 복잡하고 상세했던 것은 주로 자체 개발 시였습니다. 이때는 IA를 고민할 때 유저 경험 형성과 추천 및 취향 분석에 영향이 있을지, 정보 구조에 따라 발생 데이터가 어떤 차이가 있을지를 고민해 가면서 작업을 했었습니다.
디자인 기획, 와이어프레임
디자인과 디자인 기획은 다릅니다. 한때 이름을 대면 누구나 알만한 대기업에서 마케터를 하면서 특정 부분 디자인 기획을 총괄했던 적이 있습니다. 이때 경쟁 대기업 디자이너가 우리 기업 디자인이 좋다고 벤치마킹 차원에서 미팅을 요청했던 적이 있었습니다. 이때 저는 디자인 자체를 할 수 없어 대화가 곤욕스러웠던 적이 있습니다.
디자인 기획은 디자이너가 디자인을 잘할 수 있도록 콘셉트, 톤 앤 매너 등 방향성을 알려주고, 디자인 과정 중 불필요한 요인으로 영향받지 않게 관리해 주는 것이 주 업무입니다.
서비스 개발 시에도 이는 같습니다. 서비스 아이덴티티와 서비스 운영 기업의 CI, BI에 맞게 디자인 작업을 할 수 있게 기준과 방향을 제시해 주는 것이 디자인 기획의 핵심이 되어야 합니다. 안 그러면 디자인이 개인의 취향이나 유행에 흔들리게 됩니다.
화면 디자인과 화면이 기능 프로세스에서 어떻게 보이는지를 명확히 하기 위해 때로는 와이어프레임 작업을 진행하는 것이 좋습니다. 와이어프레임은 위의 화면 구성처럼 해도 되고 PPT로 주요 화면의 구조만 표시하는 형태, 이를 유저의 기능 사용 프로세스에 맞추어 표시하는 형태, 엑셀로 간단히 구조만 정리하는 형태 등 프로젝트 상황에 따라 다양하게 만들어 사용할 수 있습니다.
스토리보드
개발 기획의 최종 결과물은 바로 스토리보드일 것입니다. 위에서 작업한 모든 내용이 스토리보드에 들어있어야 합니다. 개발자나 디자이너는 때로는 스토리보드만으로 작업할 정도로 개발 기획의 최종 결과물입니다.
그렇다고 스토리보드 작업이 난이도가 매우 높다는 것은 아닙니다. 보통의 경우 스토리보드는 어느 정도 경력 있는 초급 기획자도 할 수 있는 작업입니다. 스토리보드 작업이 어려워지는 것은 스토리보드 이전에 완료되어야 하는 위의 기획 작업이 안 되어 있기 때문이 대부분입니다.
스토리보드 유형을 크게 나누면 2가지로 구분할 수 있습니다.
- 디자인을 위한 스토리보드
- 기능 개발을 위한 스토리보드
이 두 스토리보드의 성격은 완전히 다르므로 작성에 주의를 해야 할 필요가 있습니다. 디자인을 위한 스토리보드로는 기능 개발이 어렵고, 기능 개발을 위한 스토리보드로는 디자이너가 작업할 화면을 다 표시하는데 한계가 있을 수 있습니다.
작은 규모의 프로젝트에서는 하나의 스토리보드로 작업할 수 있지만 규모가 큰 프로젝트에서는 하나의 스토리보드로 디자인과 개발을 작업하는 게 어려운 경우가 생기게 됩니다.
그러므로 위에서 앞서 언급한 요구사항 명세서, 정책 정의, 기능 정의서, 화면 정의서, 기능 프로세스, IA, 디자인 기획, 와이어프레임 등의 문서가 중요한 것입니다.
이렇게 스토리보드 작업까지 완료되었으면 이를 개발자와 디자이너에 전달하고 기획자는 이들과 함께 개발을 진행합니다. 이제 본격적인 개발이 진행되는 것입니다.
댓글