PRD는 한 번 쓰고 끝나는 문서가 아니다
기획자가 가장 자주 듣는 질문 중 하나는 "PRD를 어떻게 써야 하나요"다. 정답 템플릿을 찾으려는 욕심은 오히려 첫 문서를 마지막 문서로 만든다. Mind the Product에 정리된 Adam Darcy의 글은 70명의 PM을 조사해 표준 양식의 부재가 불안을 키운다는 점을 짚는다. 흥미롭게도 그 해법은 더 엄격한 템플릿이 아니라, 프로젝트 성격에 맞게 섹션을 골라 쓰는 유연한 도구였다.
"많은 PM이 겪는 불안은 표준화된 PRD 템플릿과 명확한 기대치가 없다는 데서 비롯된다."Mind the Product
무슨 일인가
Darcy는 회사마다 PRD 기준이 제각각이라 신입 PM일수록 "제대로 쓰고 있는가"라는 사회적 불안에 시달린다고 본다. 그래서 그는 고정 양식 대신, 필요한 섹션을 선택하고 각 항목에 가이드를 붙인 PRD 생성기를 만들었다. 핵심은 문서의 형식이 아니라 문서가 담아야 할 의도와 맥락이며, 첫 PRD는 완성본이 아니라 계속 다듬어지는 살아있는 산출물이라는 것이다.
여러 시각
세 출처는 "무엇을 만들지 정의하기"를 서로 다른 각도에서 본다.
- Mind the Product (Darcy) — PRD는 불확실성과 팀 맥락에 맞춰 유연하게 진화해야 하며, 형식보다 의도 전달이 중요하다.
- Mind the Product (Massey) — 좋은 명세는 제품의 의도, 개발 목표, 제약을 명확히 담아야 하며 디테일 부족이 값비싼 실패를 부른다는 점을 강조한다.
- Ministry of Testing — 같은 요구사항을 테스터 관점에서 보면, given/when/then 같은 검증 가능한 수용 기준으로 다듬어야 모호함과 버그를 줄일 수 있다.
왜 중요한가
기획 문서의 목적은 합의와 검증이지, 형식 채우기가 아니다. 의도와 제약을 담되 그것이 테스트 가능한 기준으로 환원되지 않으면, 개발과 QA 단계에서 해석 차이가 폭발한다. 반대로 수용 기준만 잔뜩 나열하고 "왜 만드는가"라는 의도가 빠지면, 만들 수는 있어도 잘못된 것을 만들게 된다. 결국 좋은 기획은 의도와 검증 가능성을 한 문서 안에서 잇는 일이다.
실무 적용
- PRD를 고정 템플릿이 아니라 프로젝트 불확실성에 맞춰 섹션을 가감하는 살아있는 문서로 운영한다.
- 각 요구사항 옆에 의도(왜)와 제약을 명시하고, 동시에 given/when/then 형태의 수용 기준을 함께 적는다.
- 기획 리뷰에 QA를 초대해 모호한 문장을 검증 가능한 기준으로 일찍 바꾼다.
Kenny의 관점
프론트엔드를 구현하다 보면 PRD의 모호한 한 줄이 가장 비싼 비용이라는 걸 매번 느낀다. "적절히 노출한다" 같은 문장은 화면 구현 시점에 반드시 협의로 되돌아온다. 그래서 나는 기획 단계에서부터 의도를 문장으로 남기되, 그 문장을 곧바로 컴포넌트 상태와 수용 기준으로 번역해 본다. 기획·프론트·QA가 같은 문서를 읽고 같은 화면을 떠올릴 때, PRD는 비로소 첫 문서로 끝나지 않는다.
출처
이 글은 아래 원문을 바탕으로 Kenny가 한국어로 요약·정리한 큐레이션입니다.
원문 보기 — Mind the Product ↗