같은 서비스를 의뢰해도 어떤 기획서는 일주일 만에 정확한 견적이 나오고, 어떤 기획서는 몇 차례 미팅을 거치고도 범위가 계속 흔들립니다. 차이는 아이디어의 크기가 아니라 기획서의 완성도에서 옵니다. 저희가 견적을 검토할 때 실제로 확인하는 네 가지 기준과, 자주 놓치는 실수·체크리스트까지 함께 정리했습니다.
| 구분 | 아쉬운 기획서 | 보완된 기획서 |
|---|---|---|
| 목적 | "쇼핑몰을 만들고 싶어요" | "지방 소농가의 농산물을 도시 소비자에게 정기 배송하는 커머스" |
| 타겟 | 별도 언급 없음 | "월 1회 이상 신선식품을 온라인으로 구매하는 맞벌이 가구" |
| 성공 기준 | 없음 | "출시 3개월 내 정기구독 전환율 15%" |
1. 목적과 타겟이 명확한가
"이런 서비스를 만들고 싶다"보다 "누가, 어떤 상황에서, 왜 쓰는 서비스인가"가 한 문장으로 정리되어 있어야 합니다. 이게 흔들리면 화면 구성부터 우선순위까지 전부 다시 논의하게 됩니다. 특히 타겟이 모호하면 "이 기능이 정말 필요한가"를 판단할 기준 자체가 없어져서, 회의 때마다 의견이 갈리고 결정이 계속 미뤄지는 악순환이 생깁니다.
- 핵심 사용자와 사용 시나리오 1~2개
- 이 서비스가 해결하는 문제(경쟁 서비스와 무엇이 다른지)
- 성공 지표 — 무엇이 되면 "잘 만든 것"인지
이 세 가지가 문서 맨 앞 한 페이지에 정리되어 있는 것만으로도, 개발사 입장에서는 이후 등장하는 세부 기능들의 우선순위를 스스로 유추할 수 있습니다. 반대로 이 부분이 없으면 기능 하나하나에 대해 "이게 왜 필요한가요?"를 되물어야 하고, 그만큼 킥오프 미팅 횟수와 일정이 늘어납니다.
2. 화면 단위로 정리되어 있는가
기능을 줄글로 나열한 기획서와, 화면 단위(와이어프레임 수준이어도 충분합니다)로 정리된 기획서는 견적 정확도가 크게 달라집니다. 화면 수는 곧 개발 공수와 직결되기 때문입니다. 화면이 몇 개인지, 그 화면들이 어떤 순서로 연결되는지가 눈에 보여야 개발사도 "이 정도 규모면 몇 주가 걸린다"는 감을 잡을 수 있습니다.
- 전체 화면(페이지) 목록과 대략적인 레이아웃
- 화면 간 이동 흐름(사용자가 어디서 어디로 가는지)
- 반복되는 화면 패턴(목록/상세/폼 등)이 있다면 표시
화면을 정리할 때는 화면 "수"뿐 아니라 화면의 "성격"도 함께 보입니다. 같은 6개 화면이라도 전부 단순 목록/상세라면 공수가 적게 들지만, 그중 하나가 실시간 재고를 반영하는 대시보드라면 이야기가 달라집니다. 아래처럼 화면 유형을 구분해두면 개발사가 공수를 훨씬 정확하게 산정할 수 있습니다.
| 화면 유형 | 설명 | 공수에 영향을 주는 요소 |
|---|---|---|
| 목록형 | 게시글, 상품 등 리스트를 노출 | 정렬·필터 조건 수, 페이지네이션 방식 |
| 상세형 | 단일 항목의 상세 정보 | 첨부 콘텐츠(이미지·영상) 종류, 연관 데이터 연동 |
| 폼형 | 입력을 받는 화면(가입, 신청 등) | 입력 필드 수, 유효성 검증 규칙 |
| 대시보드형 | 여러 데이터를 요약해 보여주는 화면 | 집계 로직, 실시간 갱신 여부 |
3. 데이터와 예외 케이스를 고려했는가
"정상적으로 잘 되는 경우"만 적힌 기획서가 대부분입니다. 하지만 실제 개발 공수는 예외 처리에서 크게 갈립니다. 화면은 5개인데 그 화면에서 발생할 수 있는 예외 상황이 20가지라면, 실제 공수는 화면 5개짜리가 아니라 그보다 훨씬 큰 프로젝트입니다.
- 입력값이 비어있거나 잘못됐을 때 어떻게 되는지
- 권한이 다른 사용자(관리자/일반회원 등)별로 무엇이 다른지
- 결제·연동 등 외부 요소가 실패했을 때의 처리
| 상황 | 놓치기 쉬운 예외 | 확인해야 할 질문 |
|---|---|---|
| 로그인·가입 | 동일 이메일 중복 가입, 소셜 로그인 시 이메일 미제공 | 같은 이메일로 다른 방식 가입 시 어떻게 처리하나요? |
| 결제 | 결제 중 이탈, PG사 응답 지연·실패 | 결제 실패 시 재고·포인트는 어떻게 복구되나요? |
| 콘텐츠 등록 | 대용량 파일, 금지어·비속어 포함 | 업로드 실패 시 사용자에게 무엇을 보여주나요? |
| 권한 | 관리자의 실수로 인한 중요 데이터 삭제 | 삭제 등 되돌리기 어려운 액션에 확인 단계가 있나요? |
모든 예외를 완벽하게 문서화할 필요는 없습니다. 다만 "이런 상황은 아직 정하지 못했다"는 것을 문서에 표시해두는 것만으로도 큰 도움이 됩니다. 개발사가 견적을 낼 때 그 부분을 별도로 확인하거나, 범위에서 제외하고 안내드릴 수 있기 때문입니다. 반대로 아무 언급이 없으면 "고려하지 않은 것"인지 "당연히 되는 걸로 생각한 것"인지 구분할 수 없어, 나중에 "이건 당연히 되는 거 아니었나요?"라는 오해로 이어지기 쉽습니다.
4. 우선순위가 구분되어 있는가
모든 기능이 "필수"인 기획서는 예산과 일정을 맞추기 어렵습니다. 반드시 있어야 할 것과, 나중에 추가해도 되는 것을 구분해두면 1차 오픈 범위를 훨씬 빠르게 정할 수 있습니다. 저희는 보통 MoSCoW(Must/Should/Could/Won't) 방식으로 정리하는 것을 권장합니다.
- 필수(MVP) / 있으면 좋음 / 다음 단계로 구분
- 예산·일정 제약이 있다면 함께 명시
| 구분 | 의미 | 예시 |
|---|---|---|
| Must (필수) | 없으면 서비스 자체가 성립하지 않음 | 회원가입, 상품 조회, 결제 |
| Should (있으면 좋음) | 경험을 개선하지만 대체 가능 | 위시리스트, 리뷰 정렬 옵션 |
| Could (여유 있으면) | 임팩트는 크지 않지만 차별화 요소 | 다크모드, 화면 전환 애니메이션 |
| Won't (이번엔 제외) | 다음 단계로 명확히 미룸 | 다국어 지원, 추천 알고리즘 고도화 |
우선순위를 나눌 때 가장 중요한 건 "왜 Must인지"를 설명할 수 있어야 한다는 점입니다. 근거 없이 전부 Must로 표시된 목록은 사실상 우선순위가 없는 것과 같습니다. 반대로 각 항목에 이유가 붙어 있으면, 예산이 줄어드는 상황에서도 무엇을 먼저 빼야 할지 팀 내부에서 합의하기가 훨씬 쉬워집니다.
기획서는 어떤 형태여도 괜찮습니다
Notion, PPT, 워드, 엑셀, Figma, 심지어 손으로 그린 스케치를 찍은 사진이어도 상관없습니다. 저희가 보는 건 문서의 디자인이 아니라 위 네 가지 기준이 얼마나 채워져 있는가입니다. 실제로 가장 견적 정확도가 높았던 기획서 중에는 화려한 디자인 툴 대신 슬라이드 몇 장에 손글씨 메모가 섞인 문서도 있었습니다.
반대로 페이지 수가 많고 디자인이 정교해도, 목적·타겟·예외 케이스·우선순위 중 상당수가 비어 있다면 견적 단계에서 다시 질문이 쌓이게 됩니다. 도구보다 중요한 건 "읽는 사람이 판단에 필요한 정보를 얻을 수 있는가"입니다.
한눈에 보는 체크리스트
기획서를 넘기기 전, 아래 항목을 스스로 점검해보시는 것을 권장합니다. 네 가지 모두를 완벽히 채우지 못했더라도 괜찮습니다 — 어디가 비어 있는지 알고 있는 것 자체가 이미 큰 도움이 됩니다.
| 체크 항목 | 기준 |
|---|---|
| 목적과 타겟이 한 문장으로 정리되어 있다 | 1. 목적과 타겟 |
| 전체 화면 목록과 화면 간 이동 흐름이 있다 | 2. 화면 단위 정리 |
| 빈 값·실패·권한 등 예외 상황을 고려했다 | 3. 데이터·예외 케이스 |
| 필수·선택 기능이 구분되고, 그 이유가 적혀 있다 | 4. 우선순위 |
물론 이 모든 걸 처음부터 완벽하게 갖출 필요는 없습니다. 아이디어만 있는 상태여도 괜찮습니다 — 저희가 킥오프 미팅에서 위 네 가지를 함께 정리해드립니다.