서비스 개발 기획 과정 및 기본 산출물 정리

서비스 개발 기획 과정은 개발 대상 구체화에서 시작됩니다. 이에 따른 기능을 파악하고 개발 목표 대상의 작업 분할 구조 (WBS)를 작성합니다. 이후 기능상 세화 및 기능 프로세스 작업을 통해 일정을 구체화합니다. 이를 바탕으로 스토리보드가 작성됩니다.

 

 

개발을 위한 서비스 기획 과정 요약

 

서비스 기획 과정과 단계별 과정 기본 산출물을 요약하면 다음과 같습니다.

• 서비스 요구사항 (명세서)
• WBS
• 서비스 기능 정의
• 시비스 기능 상세화
• 서비스 기능 프로세스
• 서비스 개발 일정
• IA
• 와이어프레임
• 스토리보드

 

서비스-개발-기획-과정-및-기본-산출물-관계도

 

서비스 기획 과정이라는 의미에서 알 수 있는 각 과정의 산출물은 이전 과정의 산출물을 바탕으로 하는 연속성 상 작업 결과가 될 수 있습니다. 말 그대로 과정의 산물입니다.

 

기획이라는 의미가 계획과 이에 따른 실행 관리를 통한 목표를 달성하도록 하는 것이므로 당연히 이전 작업과 현재 작업, 미래 작업의 상호작용 속에 결과가 산출되는 것은 당연할 것입니다.

 

 

서비스 기획 산출물 정리

 

먼저 어떤 서비스를 개발할 것인가 목표를 분명히 하는 것은 앞으로 진행될 기획의 질과 성과를 좌우하게 됩니다. 그냥 눈에 간단해 보인다고 기획 과정과 개발 과정이 간단한 것은 아닙니다. 

 

때로는 간단해 보이게 만들기 위해, 너무나 쉽게 작동되는 기능을 위해, 편리한 기능을 구현하기 위해 수 백 명 또는 수 천명의 기획자, 개발자, 디자이너의 수년간의 노력과 열정이 들어가기도 합니다.

 

그냥 추상적으로 쿠팡, 네이버 또는 유튜브를 목표로 한다는 것은 서비스 기획자의 기획 방향이 될 수 없습니다. 종종 개발 현장에서 인플루언서 커머스가 유행이면 이 앱처럼 만들어 달라, 라이브 커머스가 유행이면 저 앱처럼 만들자는 것은 서비스 기획을 잘 모르는 사업가의 요구일 뿐입니다. 

 

카카오 뱅크가 인기 있으면 카카오 뱅크처럼, 네이버가 새로운 내비게이션을 적용하여, 쿠팡이 나스닥에 상장하면 쿠팡을 만들자, 넷플릭스 추천 기능이 주목을 받으면 넷플릭스 같은 추천 기능을 넣자고 하는 것은 기획자가 아니라 고객이 비용을 많이 쓰게 하는 영업의 영역입니다,

 

이런 기능 하나 흉내 내서 넣는 것만으로도 종종 수억 원의 개발 비용과 수개월의 개발 기간이 늘어나기에 개발을 대행하는 입자에서는 수입이 증가합니다.

 

 

요구사항 파악과 구체화 산출물

 

요구사항 하나가 늘어남에 따라 개발 비용 증가하고 기간은 늘어날 수 있습니다. 물론 기능의 내용과 개발 기획되는 다른 작업과의 연관성, 사용될 솔루션과 오픈 소스 여부, 개발자 역량에 따라 차이는 날 수 있습니다.

 

서비스 구현 요구사항을 상세히 파악하고 이를 개발 자원에 따라 구체화하는 것은 서비스 기획 과정에서 가장 중요하고 어려운 작업이라고 말할 수도 있습니다.

 

그러므로 요구사항의 파악과 구체화는 경험이 많고 기획 역량이 뛰어난 기획자가 작업을 해야 합니다. 요구사항 파악하고 구체화한 후 이를 협의하여 개발할 서비스를 구체화하는 작업의 수준에 따라 해당 서비스 개발 프로젝트 성공과 실패는 이미 80% 이상 결정된다고 해도 지나친 과장은 아니라 생각합니다.

 

요구사항-정리-문서-예시

 

• 요구사항 파악 후 구체화는 철저히 요구하는 담당자의 입장에서 시작되어야 함.

요구사항 파악은 철저히 기획자의 생각이 아닌 서비스 개발을 요구하는 담당자 입장에서 시작되어야 합니다. 만약 SI나 웹에이전시 개발 프로젝트의 경우 고객이 될 것입니다.

 

• 요구사항 상세화는 개발 관점을 포함.

요구사항 상세화는 앞으로 개발을 진행할 부분을 고려하여 진행되어야 합니다. 요구사항 파악과 구체화는 무엇을 만들지를 파악하는 것이라면 요구사항 상세화에는 어떻게 서비스를 만들 것인가가 포함되어야 합니다.

 

• 요구사항 파악, 구체화, 상세화는 문서를 통해 상호 확인된 것만 공식 문서가 될 수 있음.

서비스 개발을 위한 기획 작업의 시작인 요구사항 관련 내용은 반드시 문서화되고 이것이 상호 협의 완료되었다는 것이 확인된 문서만 의미가 있습니다. 그렇지 않은 문서는 과정 문서일 뿐 요구사항과 관련한 공식 산출물이 아닙니다.

 

 

WBS

 

WBS는 작업 분할 구조도로 해석될 수 있습니다. 서비스 개발을 위한 작업의 구분과 내용을 정리한 것입니다. 이를 기반으로 서비스 개발을 위해 어떤 작업이 필요한지를 파악하여 투입 인력을 결정하고, 각 인력별 작업 기간을 산출하게 됩니다.

 

WBS가 있어야 구체적인 R&R과 개발 스케줄을 확정할 수 있고 서비스 개발 관리가 가능해집니다.

 

 

기능 정의서

 

서비스 기능을 구체적으로 정의하는 산출물을 의미합니다. 서비스 기획자의 기능 정의서에는 데이터와 UI, UX 목표 등이 구체적으로 설명되어 있어야 합니다. 이를 기준으로 기능 개발을 위한 프로그램 또는 시스템 설계가 진행됩니다.

 

기능정의-문서-예시

 

기능 기획은 사용 유저와 시스템의 상호작용으로 제공되는 서비스 가치의 단위 프로세스입니다. 일종의 서비스 가치사슬로 MVP의 최소 단위입니다.

 

 

기능 프로세스  

 

기능 프로세스는 기능 상세화의 한 부분으로 볼 수도 있습니다. 기획자가 아닌 프로그래머나 디자이너 또는 제삼자가 기능을 쉽게 파악할 수 있게 도와주는 문서라고도 할 수 있습니다. 

 

또한 기능 프로세스는 기능이 시스템에서 어떤 방식으로 서비스되는지도 한눈에 파악할 수 있게 도와주는 기획의 효율성을 높이는 산출물입니다. 

  

 

IA와 화면 정의서

 

인포메이션 아키텍처로 간단히 말하면 사이트맵이라고도 할 수 있습니다. 물론 그 이상 많은 정보를 내포하는 문서로 작성할 수도 있습니다.

 

핵심은 서비스에 대한 정보를 담고 있어야 한다는 것입니다. 서비스가 어떻게 구성되고 이용 흐름에 따른 각 분기에 어떤 정보를 노출할 것인지를 정리하여 구체화하여 보여주는 기획 산출물입니다.

 

IA를 기반으로 개발 기능의 위치와 사용자가 사용하게 될 화면을 정리하게 되는데 이것을 화면 정의서라고 합니다.  

 

화면정의서-문서-예시

 

그러므로 요구사항 구체화 산출물과 WBS, 기능 정의서 산출물이 없는 상황에서 작성된 IA는 해당 서비스를 개발하기 위한 기획 문서로 의미가 있다고 말할 수 없습니다. 그냥 어디나 있을 법한 기본 IA 양식 정도가 될 수는 있을 것입니다. 이를 바탕으로 사용자 화면을 분개한 화면 정의서도 차별적 서비스 이용을 이끌어 내기 못하게 될 것입니다. 

 

 

와이어프레임

 

와이어프레임은 화면의 모습을 선과 프레임으로 표현한 문서를 말합니다. 디자인이 입혀지지 않은 화면 설계서라고도 할 수 있습니다.

 

기획자에 따라 와이어프레임은 전반적인 설계 흐름과 화면 구조를 잡는 데 사용하고 상세 개발 내용은 스토리보드에 표현하기도 합니다. 이때 와이어 프레임은 기능 정의와 화면 정의에서 스토리보드로 넘어가는 중간 과정 문서로 볼 수도 있습니다.

 

서비스 개발에 참여하는 기획자나 디자이너가 많을 경우 화면 설계 기준 문서로 활용될 수도 있고, 서비스 기능 프로세스를 화면 중심으로 상세화 하는 데 사용될 수도 있습니다.

 

전자의 경우 여려 기획자의 스토리보드를 하나로 합칠 때 효율이 높아집니다. 여러 명 디자이너의 작업 룩앤필을 일치시키는데도 도움이 됩니다. 

 

후자의 경우 기능 프로세스가 좀 더 서비스적으로 구체화될 수 있습니다. 

 

와이어프레임은 목적성에 따라 다양한 양식으로로 사용될 수 있고, 그냥 스토리보드를 화면용, 기능용으로 분리하여 작업할 수도 있습니다. 

 

만약 IA를 작업 화면 수준까지 세분화하고 이를 통해 화면 번호를 붙일 경우 와이어프레임을 화면 정의서로 사용할 수도 있을 것입니다. 

 

기능 개발에 참여해야 할 데이터와 다른 기능과 연동 관계가 중요한 경우,  UX가 중요하여 가설과 설계 내용의 적용이 치밀해야 한다면 와이어프레임을 통해 기능 프로세스에서 발생하는 내외적 이벤트를 상세히 표시할 수도 있을 것입니다.   

 

서비스의 내용과 규모, 개발 참여 인력 규모에 따라 와이어프레임의 수준이나 활용 내용은 달라질 수 있을 것입니다. 서비스 규모가 작을 경우 와이어프레임 없이 스토리보드 작업을 해도 큰 문제가 없을 수 있습니다.

 

 

스토리보드

 

서비스 기획의 최종 문서이면서 프로그램 개발자나 디자이너 개발자가 가장 많이 보는 기획 산출물일 것입니다. 그러므로 때로는 영업이나 디자이너 출신으로 기획자로 전향한 지 얼만 안되어 프로젝트 참여 회사여서 기획 PL(리더)를 맡은 경우 기획 산출물의 전부가 스토리보드 작업이라 생각해서 기획 초기부터 스토리보드를 요청하기도 합니다.

 

서비스 기획 과정에서 스토리보드는 가장 마지막 작업이고, 이전 기획 산출물이 잘 되어 있다면 산출물 난이도 측면에서도 낮은 난이도 작업입니다. 그러나 앞의 기획 내용이 없다면 지금까지 이야기한 모든 내용이 담겨야 하는 최악 난이도 작업이 됩니다. 

 

서비스 기획에 있어 스토리보드는 앞서 진행한 기획 작업 내용을 정리하여 실제 화면에서 서비스나 운영되듯이 시뮬레이션하여 보여주고 이를 기획적으로 설명하는 문서라고 할 수 있습니다.

 

스토리보드-문서-예시

 

원칙적으로 스토리보드에는 화면과 제공 기능을 기준으로 기획자가 설계한 내용에 이를 구현하기 위한 개발 기획 내용, 디자인 기획 내용이 담깁니다. 

 

그러나 주로 PPT로 작업되는 스토리보드 양식 특성상 이렇게 많은 내용을 담으면 복잡하고 화면 표현 부분이 너무 작아져서 주로 기획자의 설계 내용만 넣게 됩니다. 

 

여담으로 요즘은 다양한 목업 툴이나 디자인 툴, 프로토타이핑 툴을 서비스 기획에 사용하기도 합니다. 사용이 효율적일 수도 있지만 개인적으로는 PPT를 권합니다.

 

10여 년 이전 스타트업 씬에서 기획 툴에 대한 이슈가 있었고 지속되어 왔기는 했지만, 지금의 기획 툴의 사용은 비주얼적 측면을 강조해야 하거나 개발자 없이 서비스 시뮬레이션하려는 목적이 서비스 기획의 완성도보다는 더 큰 것 같습니다.

 

기획 툴이 시작되었고 스타트업 문화가 국내보다 활발한 해외에서도 기획 툴에 대한 이슈는 이제 거의 끝난 것으로 보입니다. 최고의 기획 툴은 A4용지나 화이트보드이고 그다음은 PPT가 위치한 것으로 보입니다. 투자자 프레젠테이션이나 개발사가 영업이 필요하거나, 디자인 부티크 제안용으로 앞서 언급된 기획 툴이 주로 사용되는 것으로 보입니다.