PRD(Product Requirements Document)란 제품의 목적, 기능, 동작 방식 등을 전반적으로 요약하고 정리한 문서이며, 제품 관리자(PM)가 주로 작성한다.
제품 개발에 참여하는 비지니스·기술자·디자이너 등 다양한 팀원들이 동일한 목표를 공유하도록 돕는 나침반 역할을 한다.
우리 서비스가 가진 문제는 무엇이고, 그것이 왜 중요한 문제인지, 해당 문제를 어떻게 해결할 것인지에 대해 기술하는 문서이기 때문에 PRD를 잘 작성하는 것은 중요하다.
이번 글에서는 PRD 작성법에 대해서 알아보도록 하자.
🔹PRD란 무엇인가?
PRD는 제품이 어떤 문제를 해결하고, 어떤 방식으로 작동해야 하는지를 체계적으로 정리한 기획 문서다.
기획자(PM)가 디자이너, 개발자, 마케터 등 모든 팀원이 같은 방향성을 공유할 수 있도록 작성하는 문서이기 때문에 굉장히 중요한 문서이다.
출처: https://intellisoft.io/product-requirements-document-prd-why-make-it-lean//
즉, PRD는 단순히 기능 명세를 나열하는 문서가 아니다.
- 왜 이 제품을 만들어야 하지?
- 어떤 문제를 해결해야 하지?
- 사용자는 어떤 흐름으로 제품을 사용할까?
다음과 같은 질문에 명확한 답을 줄 수 있도록 구성된 문서이다.
PRD가 꼭 필요한 이유는 다음과 같다.
✔️ 모든 이해관계자가 공통된 방향성과 목표를 이해하고 이를 기반으로 협업할 수 있게 된다.
✔️ 우선순위, 가정사항, 제한 조건, 의존 관계 등을 미리 정리해 혼선과 범위 확장(scope creep)을 방지한다.
✔️ 보수적인 waterfall 방식에서는 필수였고, Agile 방식을 많이 사용하는 현재에도 규제 산업 또는 외부 고객에게 제품을 전달할 경우 중요한 기준 문서로 활용된다.
👉 Waterfall 방식과 Agile 방식에 대해 생소한 분들은 이전에 포스팅 했던 프로젝트 관리 방법론을 참고하길 바란다.
🔹 PRD에는 무슨 내용이 들어가는가?
PRD 즉, 기획서는 현업에서 여러 이름으로 불린다. 기능 요구정의서, 명세서, UX 설계 문서 등 이름도 다양하고 형태도 다양하다.
디자인 툴 역시 여러 디자인 툴을 사용하기 때문에 기업마다, 사람마다 다양한 형태의 PRD를 작성한다.
Google, YouTube, Meta와 같은 대기업들이 실제 사용하는 PRD 구성 항목에 대해서 알아보면 PRD에 어떤 내용이 포함되어야 하는지 알 수 있다.
🔻Google PRD
Google에서 사용하는 PRD 구성 항목을 알아보면 다음과 같다.
- Problem Statement
- 어떤 문제를 해결하려는가?
- 사용자/시장 맥락은 무엇인가?
- Goals & Success Metrics
- 제품이 달성해야 하는 핵심 성과
(예: 활성 사용자 수, 전환율 등)
- User Personas & Flows
- 타깃 사용자는 누구이며, 어떤 흐름으로 이 제품을 쓸까?
- Requirements
- 핵심 기능 목록과 설명
- Out of Scope
- 현재 릴리즈에서 제외되는 기능을 명시하여 범위 오해 방지
- Launch Plan
- QA, 마케팅, CS 대응 등 제품 출시 준비 단계
🔻YouTube / Meta PRD
YouTube와 Meta는 거의 동일한 PRD 양식을 사용한다.
- Executive Summary
- 두세 문장으로 제품 목적을 요약, 임원진 공유용
- Why Now?
- 지금 이 제품이 필요한 이유 (시장 트렌드, 경쟁 등)
- Use Case & CUJ (Critical User Journey)
- 핵심 사용자 시나리오 중심으로 설명
- Tech Consideration / Risk
- 기술적 의존성, 리스크, 인프라 제약 등
- Open Questions
- 아직 정해지지 않은 사안들을 정리해 팀 간 논의 기반 제공
PRD에 꼭 반드시 포함되어야 하는 내용은 다음과 같다.
- 문제 정의와 기획 배경 작성
- 제품 목표 및 성공 지표 설정
- 사용자 페르소나와 시나리오 작성
- 기능 정의 + 우선순위 분류
- 기술 고려사항, 제약, 오픈이슈 정리
- 릴리즈/런칭 계획과 범위 명시
🔹 PRD 작성하는 법
위에서 알아본 PRD에 반드시 포함되어야 하는 공통 항목에 어떤 내용이 들어가야 하는지 자세히 알아보자
✔️ 문제 정의와 기획 배경 작성
- 어떤 문제를 해결하는가?
- 현재의 사용자가 불편함을 느끼는 것은 무엇인가?
- 경쟁사 혹은 기존 제품의 한계는 무엇인가?
✔️ 제품 목표 및 성공 지표 설정
- 비지니스 관점 KPI (ex. 전환율 5% 증가)
- 사용자 관점 UX 목표 (ex. 주문 시간 30%)
✔️ 사용자 페르소나와 시나리오 작성
- 실제 사용자 유형 구체화
- 사용자가 어떤 흐름으로 제품을 사용하는지 스토리로 작성
✔️ 기능 정의 + 우선순위 분류
- 이 문제를 해결하기 위해 꼭 필요한 기능은?
- 기능별 우선순위
✔️ 기술 고려사항, 제약, 오픈이슈 정리
- 기술 스택/시스템 제약
- 외부 API, 팀 간 협업 의존성
- 추가 논의 필요 항목
✔️ 릴리즈/런칭 계획과 범위 명시
- 어떤 기능까지 이번 릴리즈에 포함되고, 무엇은 제외되는지
- QA/CS/마케팅 일정 포함
이러한 항목 외에도 PRD에는 프로젝트 성격이나 팀의 협업 방식에 따라 추가적으로 포함되어야 할 내용들이 있을 수 있다.
앞서 말했듯, 좋은 PRD란 단지 많은 정보를 나열하는 것이 아니라, 누가 읽더라도 "왜 이 제품을 만들고, 어떤 문제를 해결하며, 어떻게 구현할 것인지?"가 명확히 전달되는 문서여야 한다.
따라서 작성자는 항상 읽는 이의 입장에서 간결하되 명료하고 구체적으로 문서를 구성해야 하며, PRD를 단순한 양식이 아닌 제품에 대한 의사결정의 기록이자 커뮤니케이션 도구로 인식하는 태도가 중요하다.
🔹 유의사항
PRD는 3가지 질문(What, Why, How)에 대한 초안을 작성한 다음 빠르게 피드백을 받아야 한다.
좋은 PRD를 작성하기 위해서는 동료들의 피드백이 중요하다. 초안을 쓰고 팀원들에게 피드백을 받는 과정은 상당히 중요하다. 팀원들의 피드백에 동의하지 못할 경우, 맥락을 설명하고 팀원들과 꾸준히 논의를 해보는 것이 좋다.
주요한 문제에 대해 의견 불일치가 있다면 따로 미팅을 잡고 팀원들과 해당 이슈를 다루는 것도 좋은 방법이다.
이를 바탕으로 디자이너 및 개발자와 협력하여 최종 솔루션을 찾고 미팅을 거쳐 이슈들을 해결하며 완성해가야 한다.
✔️ PRD는 꾸준히 업데이트 해야 하는 살아있는 문서이다.
✔️ 너무 길고 상세하게 적는 것은 지양해야 한다.
✔️ 핵심적인 세부 사항을 모두 적는 것이 아닌 필수 요소와 기능을 통해 얻을 수 있는 것에 집중해야 한다.
✔️ 기능과 사용자 스토리를 작은 단위로 나열하여 점진적으로 개선한다.
✔️ 소통을 위한 수단으로 사용해야 한다.
즉, PRD는 솔루션에 도달하는 모든 과정이 담기며, 좋은 PRD를 작성해야 프로젝트가 더 좋은 방향으로 갈 수 있다.
👀 My thoughts
- 저번 프로젝트 관리법에 대해 글을 적으며 Waterfall 방식과 Agile 방식에 대해 알아보았는데, PRD를 쓰는 방식에 있어서도 두 방식이 완전 다르다는 것이 신기하였다. Waterfall 방식의 프로젝트인 경우 PRD가 몇백장의 PPT가 될 수 있고, Agile 방식을 사용하여 작은 가설을 테스트 하는 팀에서는 PRD가 한 장으로도 충분할 수 있다고 한다. PM과 관련된 공부를 하면서 서비스나 회사 특성, 개발 문화가 어떤지, 어떤 프로젝트 방식을 사용하는 지에 따라 모든 것이 바뀐다는 것이 참 신기하였다.
- PM과 관련하여 공부하면서 가장 어렵고 감이 안잡히는 점은 정답이 없다는 것이다. 모든 방식은 장단점이 있고, 같은 문제라도 구성원에 따라 맞는 방식이 다르다. 이렇게 정답이 없기 때문에 현업에서 일하는 PM들은 항상 고민하고, 기존 방식을 어떻게 변화할지 고민하는 것 같다. 또한, 이러한 문제 때문에 당연하게도 PM이라는 직무는 경험이 가장 요구되는 것 이라는 생각이 들었다.
