기획 문서의 종류와 체계 (1): 발견·정의 단계와 PRD

제품이나 서비스를 만드는 자리에 있다 보면 "기획서 좀 써주세요"라는 말을 자주 듣습니다. 그런데 막상 빈 문서를 열어 놓으면, 무엇을 적어야 할지 막막해질 때가 있습니다. PRD를 말하는 걸까요, 화면설계서를 말하는 걸까요, 아니면 아이디어를 정리한 한 장짜리 메모면 충분한 걸까요. 솔직히 말하면 저는 한동안 이 단어들이 다 비슷한 것을 가리킨다고 생각했고, 그래서 더 헷갈렸습니다.

이 글은 「기획 문서의 종류와 체계」 3부작의 1편입니다. 1편은 전체 지도와 발견·정의 단계를, 2편은 설계 단계(정보 구조와 화면설계서)를, 3편은 기술·검증 단계(기술 명세와 테스트 문서)를 다룹니다. 오늘은 그 첫걸음으로, 기획 문서가 왜 이렇게 여러 종류인지부터 차분히 짚어보려 합니다.

돌이켜 생각해보면, 기획 문서가 헷갈렸던 이유는 그 문서들이 서로 다른 질문에 답하기 때문이었습니다. 문서의 이름을 외우는 일은 본질이 아니었습니다. 중요한 것은 "지금 내가 어떤 질문 앞에 서 있는가"였습니다. 무언가를 만들기 전에 우리는 순서대로 묻습니다. 왜 만드는가, 무엇을 만드는가, 어떻게 생기게 할 것인가, 어떻게 구현할 것인가, 그리고 잘 되었는가. 기획 문서란 결국 이 다섯 가지 질문에 답하는 도구의 묶음입니다.

기획 문서는 '단계 × 질문'의 지도다

제품 개발에는 흐름이 있습니다. 흔히 라이프사이클(lifecycle, 제품의 생애 주기)이라 부르는, 발견에서 검증까지 이어지는 다섯 단계입니다. 각 단계는 고유한 질문을 갖고, 그 질문에 답하는 대표 문서가 따로 있습니다. 아래 표가 이 시리즈 전체의 지도이자, 길을 잃을 때마다 돌아올 자리입니다.

단계	핵심 질문	대표 문서
1. 발견(Discovery)	왜 만드나? 누구를 위해?	리서치, 페르소나, Lean Canvas, JTBD
2. 정의(Definition)	무엇을 만드나? 성공 기준은?	PRD, 비전/로드맵, OKR, PR-FAQ
3. 설계(Design)	어떻게 구성하나?	IA, User Flow, 와이어프레임, 화면설계서
4. 기술(Tech)	어떻게 구현하나?	TRD, API Spec, ERD, ADR
5. 검증(Verify)	잘 됐나?	Test Plan, 인수기준(AC), 릴리즈 노트

여기서 한 가지 오해를 먼저 풀고 싶습니다. 이 문서들을 한 사람이 전부 쓰는 것이 아닙니다. 단계마다 주인이 다릅니다. 발견과 정의는 주로 기획자나 PM(Product Manager, 제품 책임자)이, 설계는 디자이너가, 기술은 개발자가, 검증은 QA가 중심에 섭니다. 그래서 "기획서"라는 한 단어가 사람마다 다른 그림을 떠올리게 했던 것입니다. 1편에서는 이 지도의 위쪽 두 단계, 발견과 정의를 살펴봅니다.

1단계 — 발견(Discovery): "왜 만드는가"

가장 앞 단계는 발견입니다. 아직 코드는 한 줄도 없고, 화면도 없습니다. 이 단계의 문서들은 무언가를 그리기 위한 것이 아니라, 확신을 만들기 위한 것입니다. 가장 비싼 실수 — 아무도 원하지 않는 것을 정성껏 만들어버리는 일 — 을 코드를 쓰기 전에 막는 것이 목적입니다.

발견 단계에서 자주 쓰이는 문서는 다음과 같습니다.

• 요구사항 브리프 / BRD(Business Requirements Document, 비즈니스 요구사항 문서): 비즈니스가 왜 이것을 원하는지, 이해관계자의 요구가 무엇인지를 명문화합니다. "왜 지금 이 일을 하는가"에 대한 사업 쪽의 대답입니다.
• 시장조사 · 경쟁 분석: 시장이 어떤 상태이고 경쟁자는 누구인지를 살핍니다. "왜 하필 우리가 하는가(why us)"의 근거가 여기서 나옵니다.
• 사용자 리서치 · 페르소나 · JTBD(Jobs To Be Done, 고객이 해내려는 과업): 누가, 어떤 일을 해내려 하는지를 봅니다. 제품을 기능의 목록이 아니라 "고객이 고용하는 도구"로 바라보게 하는 관점입니다.
• Lean Canvas / 비즈니스 모델 캔버스: 사업 가설을 한 장에 압축해 빠르게 검증합니다. 길게 쓰기 전에 전체를 한눈에 보려는 도구입니다.

"고객은 1/4인치짜리 드릴을 원하는 것이 아니라, 1/4인치짜리 구멍을 원한다."

JTBD를 설명할 때 자주 인용되는 말입니다. 우리가 만드는 것은 드릴(기능)이지만, 고객이 진짜 원하는 것은 구멍(해결된 과업)입니다. 발견 단계의 문서들은 이 구멍이 정말로 존재하는지를 끈질기게 되묻습니다. 애석하게도 저는 이 단계를 건너뛰고 곧장 화면부터 그리고 싶은 충동을 자주 느낍니다. 다만 그 충동이 가장 비싼 실수로 이어진다는 것을, 돌이켜 보며 조금씩 배우게 되었습니다.

2단계 — 정의(Definition): "무엇을 만드는가"

왜 만드는지에 어느 정도 확신이 섰다면, 다음 질문은 "그래서 무엇을 만들 것인가"입니다. 정의 단계는 모호한 의지를 합의 가능한 명세로 바꾸는 자리입니다. 그리고 이 단계의 한가운데에 이 시리즈의 주인공 중 하나인 PRD가 있습니다.

PRD — 정의 단계의 중심

PRD(Product Requirements Document, 제품 요구사항 문서)는 "무엇을 만들 것인가"를 정리한 문서입니다. 보통 다음을 담습니다.

• 문제 정의와 목표 — 왜 이 기능이 필요한가
• 사용자 스토리와 기능 요구사항 — 무엇을 할 수 있어야 하는가
• 범위 — 하는 것과 하지 않는 것(in/out of scope)
• 성공 지표 — 무엇으로 성공을 판단하는가
• 비기능 요구사항 — 성능, 보안 같은 제약

PRD에서 가장 중요한 원칙은 "어떻게(How)"가 아니라 "무엇/왜(What/Why)"에 집중한다는 것입니다. 흔한 안티패턴은 PRD에 구현 방법까지 적어버리는 것입니다. 어떤 라이브러리를 쓰고 테이블을 어떻게 설계할지까지 PRD가 못박아 버리면, 정작 그 문제를 가장 잘 푸는 방법을 찾아야 할 설계·기술 단계의 자유도가 사라집니다. PRD는 목적지를 정하는 문서이지, 거기까지 가는 경로까지 지정하는 문서가 아닙니다.

한 가지 덧붙이면, PRD는 가끔 MRD(Market Requirements Document, 시장 요구사항 문서)와 혼동됩니다. MRD가 시장의 관점이라면 PRD는 제품의 관점입니다. 요즘은 대체로 PRD로 통합해 부르는 추세입니다.

정의 단계의 나머지 문서들

PRD 곁에는 결이 비슷한 문서들이 함께 놓입니다. 제품이 향하는 장기 방향을 적는 비전·전략은 흔들릴 때 돌아보는 '북극성'이고, 로드맵(Roadmap)은 언제 무엇을 할지를 Now/Next/Later처럼 흐름으로 보여줍니다. 성공을 숫자로 정의하는 OKR(Objectives and Key Results, 목표와 핵심 결과)은 PRD의 성공 지표 섹션과 자연스럽게 이어집니다. 작은 기능이라면 굳이 무거운 PRD 대신 한 장짜리 One-pager로 갈음하기도 합니다.

그중 두 가지는 따로 짚어둘 만합니다. 하나는 PR-FAQ입니다. 아마존의 'Working Backwards(거꾸로 일하기)'에서 나온 기법으로, 제품을 만들기 전에 출시 보도자료(Press Release)와 예상 질문(FAQ)을 먼저 써보는 방식입니다. 다 만든 뒤의 모습을 미리 글로 그려보면, 이것이 고객에게 어떤 가치가 있는지가 적나라하게 드러납니다. 멋진 보도자료가 써지지 않는다면, 그 제품은 다시 생각해봐야 한다는 신호인 셈입니다. 다른 하나는 RFC(Request for Comments, 의견 요청)입니다. 큰 결정을 혼자 내리지 않고 팀의 검토와 합의를 구하는 문서인데, 기술적인 RFC는 3편에서 다시 만나게 됩니다.

정의 단계의 문서들을 한눈에 정리하면 다음과 같습니다.

문서	무엇에 답하나
PRD	무엇을 만들 것인가 — 문제, 범위, 성공 지표.
비전 · 전략	우리가 향하는 장기 방향. '북극성'.
로드맵	언제 무엇을 할 것인가. Now/Next/Later.
OKR · 성공지표	성공을 어떻게 측정할 것인가.
One-pager	PRD의 경량 버전. 작은 기능엔 한 장으로 충분.
PR-FAQ	출시 모습을 미리 써보고 가치를 거꾸로 검증.

정리 — '왜'와 '무엇'을 지나며

여기까지가 기획 문서 지도의 앞쪽 절반입니다. 발견 단계는 "왜 만드는가"에, 정의 단계는 "무엇을 만드는가"에 답합니다. 둘을 합치면 제품의 '왜/무엇' 레이어가 됩니다. 이 레이어가 단단할수록, 뒤따르는 설계와 구현이 덜 흔들립니다.

다시 처음의 이야기로 돌아가면, "기획서 좀 써주세요"라는 말 앞에서 제가 막막했던 이유는 도구가 너무 많아서가 아니었습니다. 지금 어떤 질문에 답해야 하는지를 몰랐기 때문이었습니다. 질문이 정해지면 문서는 자연히 따라옵니다. 그리고 모든 문서를 다 쓸 필요도 없습니다. 문서는 의무가 아니라 목적을 위한 도구라는 것 — 이것이 이 시리즈를 관통하는 생각입니다.

다음 2편에서는 "무엇을 만들지"가 정해진 뒤의 이야기, 즉 설계 단계를 다룹니다. 추상적인 요구사항이 어떻게 구체적인 화면이 되는지 — 정보 구조(IA), 사용자 플로우, 그리고 한국 현업의 핵심 산출물인 화면설계서와 와이어프레임의 차이를 차분히 살펴보겠습니다.