서비스 기획서 템플릿 - 내가 쓰는 방식

 

기획서를 쓸 때마다 매번 형식을 새로 고민하는 게 비효율적이라는 걸 느끼고, 제가 실제로 쓰는 템플릿을 정리해보기로 했습니다.
요구사항정의서와 겹치는 부분도 있지만, 여기서는 좀 더 초기 단계,
즉 아이디어를 사업적으로 정리하는 단계의 기획서를 다룹니다.

 

1. 한 줄 요약
2. 문제 정의
3. 시장/경쟁 상황
4. 솔루션 개요
5. 기대 효과와 리스크
6. 필요한 리소스와 일정

 

1. 한 줄 요약

먼저, 가장 위에 이 서비스/기능이 무엇인지 한 문장으로 씁니다.
"누구를 위해, 어떤 문제를, 어떻게 해결하는가"를 한 문장에 담으려고 노력해요.
저는 이 문장을 쓰는 데 보통 제일 오래 걸립니다.
한 줄로 못 요약된다는 건 아직 생각이 정리되지 않았다는 신호더라고요.
막상 써보고 팀원에게 읽어달라고 했을 때 "그게 무슨 뜻이에요?"라는 질문이 나오면, 그 문장은 다시 씁니다.

 

2. 문제 정의

왜 이 문제가 문제인지, 어떤 데이터나 사례로 이걸 증명할 수 있는지 적습니다.
저는 여기에 반드시 실제 사용자 인용문이나 CS 문의 내용을 하나 이상 넣으려고 합니다.
숫자만 있으면 추상적으로 느껴지는데, 실제 사용자의 말 한마디가 있으면 훨씬 설득력이 생기더라고요.
예를 들어 "환불 프로세스가 복잡하다"는 문제를 적을 때, "환불하는 데 세 번이나 전화해야 했다"는 실제 CS 인용을 같이 넣는 식입니다.

 

3. 시장/경쟁 상황

경쟁사가 이 문제를 어떻게 풀고 있는지, 우리는 왜 다르게 풀어야 하는지를 씁니다.
저는 이 섹션을 "따라 하기 위한 조사"가 아니라 "우리가 놓치고 있는 게 없는지 확인하는 조사"로 씁니다.
경쟁사 벤치마킹을 나열만 하면 결국 기능이 늘어나는 함정에 빠지기 쉬워서, 항상 "우리 사용자에게 이게 정말 필요한가"라는 질문을 옆에 같이 적어둡니다.

 

4. 솔루션 개요

구체적인 화면 설계보다는 "어떤 방식으로 문제를 풀 것인가"의 큰 그림을 적습니다.
여기서 너무 자세하게 들어가면 다음 단계인 PRD와 내용이 겹치기 시작해요.
저는 이 단계에서는 러프한 스케치나 플로우 다이어그램 정도만 첨부하고, 세부 화면은 의도적으로 남겨둡니다.

 

5. 기대 효과와 리스크

이 기획이 성공했을 때의 효과와, 실패했을 때 감당해야 할 리스크를 같이 적습니다.
저는 리스크를 적을 때 "이게 실패하면 최악의 경우 무엇을 잃는가"를 구체적으로 씁니다.
예산, 개발 리소스, 다른 로드맵 지연 같은 것들을요.
경영진 입장에서는 기대 효과보다 리스크 파악이 의사결정에 더 크게 작용하는 경우가 많았습니다.

 

6. 필요한 리소스와 일정

디자인, 개발, QA, 마케팅 등 어떤 리소스가 얼마나 필요한지 대략적으로 적습니다.
정확한 일정보다는 "이 정도 규모의 프로젝트다"라는 감각을 전달하는 게 이 단계의 목적이에요.
정확한 일정은 실제 PRD와 스프린트 계획 단계에서 나오는 게 맞다고 생각합니다.

 

이 템플릿을 정착시키기 전까지는 기획서마다 형식이 다 달라서, 경영진 리뷰 때마다 "이 기획서엔 왜 리스크가 없냐", "저 기획서엔 왜 경쟁 분석이 없냐" 같은 질문이 반복됐습니다.
템플릿을 통일한 이후로는 리뷰 시간이 확실히 줄었어요.
리뷰하는 사람도 "어느 섹션에 뭐가 있을지"를 예상할 수 있으니 훨씬 빠르게 핵심만 짚어줄 수 있게 됐습니다.

 

다만, 템플릿이 너무 형식적으로 채워지는 부작용도 있었어요.
어떤 팀원은 리스크 섹션에 "특별한 리스크 없음"이라고만 적어서 제출한 적이 있었는데, 이런 경우엔 다시 채워달라고 요청합니다.
템플릿은 생각을 대신해주는 도구가 아니라 생각을 정리하는 틀일 뿐이라는 걸 계속 강조해야 하더라고요.

 

기획서 템플릿은 완성형이 아니라 계속 조금씩 손을 보는 문서라고 생각합니다.

 

이번 정리를 하면서 저도 몇 군데 다시 다듬었는데, 다음에 새 프로젝트를 시작할 때 또 어떤 부분이 부족하게 느껴질지 궁금해지네요.