기획안 문서 정리

보통 “기획안”이라고 말할 때는 전체 그림을 잡는 문서이고, 그 안에 여러 하위 문서(요구사항, 정보구조도, 정책, 기능 명세 등)가 포함되거나 각 문서가 단계별로 만들어지는 경우가 많다. 프로젝트의 크기마다 해당 문서가 따로 작성되거나 통합해서 작성 되는 경우가 있지만 오늘은 일반적인 기획안 문서에 대해서 총정리 해보았다.

일반적인 작성 순서 (서비스 기획 프로세스 기준)

1. 요구사항 정의서 = 비즈니스 요구(무엇이 필요하다)
   • 가장 먼저 작성.
   • 왜 필요한지(배경), 누가 쓸지(타겟), 무엇을 해야 하는지(핵심 기능·목표)를 정리.
   • 이 단계는 “비즈니스 요구”를 기술하는 단계라 이후 모든 문서의 기준.
   • 각 팀(개발, 디자인, QA 등)이 동일한 목표를 가지고 작업할 수 있도록 공유.
   • 프로덕트 개발 과정에서의 지침서 역할.
   • 개발 팀은 물론, 이해관계자들 간의 커뮤니케이션을 원활히 하고 프로젝트 진행이 명확해짐.
   • 제품이나 서비스에서 제공해야 할 구체적인 기능들을 나열
     • 기능 이름
     • 기능 설명
     • 우선 순위
     • 구현 기준
2. 정보구조도 (IA) = 정보의 구조(어떻게 배치할까)
   • 요구사항을 토대로, 서비스 내 콘텐츠·기능을 어떻게 배치할지 그림으로 설계.
   • 화면 설계(와이어프레임) 전에 작성하는 게 일반적.
3. 서비스 정책서 = 규칙/정책(운영 원칙은 무엇인가)
   • 서비스의 운영 원칙과 규칙을 정의.
   • 서비스 개발이나 개선 과정에서 기능에 대한 명확한 정의와 구현 기준을 설정.
   • 정보구조와 요구사항이 잡히면, “이 기능을 어떤 조건에서 허용/제한할지” 정책이 필요하기 때문.
   • (예: 회원가입 가능 연령, 탈퇴 시 데이터 보관기간, 결제 환불 규칙 등)
   • 순서
     • 서비스 정책서의 목적 정의 -> 정책 범위 설정 -> 정책의 주요 항목 및 세부사항 작성 -> 정책 문서화 및 공유 -> 정기적인 검토 및 업데이트
4. 에러케이스 = 예외대응(문제가 생기면 어떻게 처리할까)
   • 정책과 기능을 정한 뒤, 예상 가능한 예외 상황을 정리.
   • QA/개발 단계에서 많이 쓰이지만, 기획 단계에서 정리해두면 사용자 경험 설계에도 도움.
5. 상세 기능 명세서 = 개발 가이드 (구체적으로 어떻게 구현할까)
   • 마지막에 작성.
   • 앞의 모든 내용을 바탕으로, 실제 개발자가 구현할 수 있도록 화면별 상세 동작, 데이터 흐름, 조건을 기술.
   • 여기서 와이어프레임·프로토타입도 같이 나오기도 함.
   • 프로젝트의 목표, 요구 사항, 일정, 기능 설계(명세) 등을 정의하는 과정.
   • 구체적이면서 실현가능한 계획

요구 사항 정의서는 상위개념으로서 그 안에 정보 구조도, 정책, 에러케이스, 상세 기능 명세서가 포함될 수 있고, 혹은 프로젝트 크기에 따라 별도 문서로 분리 된다.

• 작은 프로젝트: “요구사항 정의서” 하나 안에 다 들어감.
• 큰 프로젝트: 요구사항 정의서(상위) + IA 문서 + 정책 문서 + 기능 명세서 등으로 분리.

예>

• 요구사항 정의서 = 집을 짓기 전 “무엇을 지을지”를 적은 설계 개요
• 정보구조도 = 집의 방 구조도 (방, 주방, 화장실 위치)
• 서비스 정책서 = 집의 사용 규칙 (입주 조건, 관리 규칙)
• 에러케이스 = 집에서 생길 수 있는 문제와 대응책 (정전 시, 누수 시 대처법)
• 상세 기능 명세서 = 실제 건축 도면과 시공 매뉴얼

상세 기획안에서 보통 프로젝트의 배경과 목표를 작성해 왔어서 PRD랑 무엇이 다를 수 있을까 생각해 왔는데, 역시 문서를 읽는 독자와 프로젝트의 규모에 따라서 서로의 내용이 겹치기도 그리고 더 추가 될지도 아니면 그냥 합쳐질 수도 있나보다.