우연히 유튜브를 보다가 재미있는 영상 하나를 발견하게 되었다.
Claude Sonnet 4.5 한 번 찍먹해보겠습니다
대략적인 내용은 새롭게 출시한 Claude 의 Sonnet 4.5 모델 사용기었는데, 영상 중간에서 "PRD" 라는 단어가 나왔다. 영상 속에서는 이 PRD를 Claude Code를 활용해서 AI 가 직접 작성하게 하고, 그 PRD를 바탕으로 Claude Code가 프로젝트를 진행하는 모습을 보여주었다.
요구사항 명세서 혹은 기능 명세서 라는 말은 자주 들어보았으나 PRD 라는 말은 처음 들어보았다. 그래서 이번 기회에 PRD가 무엇이고, 어떻게 작성하는건지 알아보자!
PRD 란 무엇인가?
PRD(Product Requirements Document)는 제품 요구사항 정의서를 의미한다. 제품을 만들거나 업데이트하기 위해 기능을 기획하는 단계에서 요구사항을 개괄적으로 설명하는 문서로, 제품 개발 프로세스 전반에 걸쳐 필수적인 문서이다.
PRD의 역할
PRD는 제품의 목적, 기능, 동작 방식을 전반적으로 요약하고 정리한 문서로, 주로 제품 관리자(PM)가 작성한다. 제품 개발에 참여하는 비지니스 팀, 기술자, 디자이너 등 다양한 팀원들이 동일한 목표를 공유하도록 돕는 나침반 같은 역할을 한다.
개발자에게 PRD는 "무엇을 만들고, 왜 만드는가?" 를 알려주는 가이드북이며, 혼란 없이 개발을 진행할 수 있도록 돕는 문서와 같은 역할을 한다. 기획 단계에서는 제품의 비전과 전략을 정의하고, 디자인 단계에서는 사용자 요구사항 충족 여부를 확인하며, 개발 단계에서는 기능의 목적과 구현을 확인하는 데 활용된다.
PRD의 핵심 특징
PRD의 핵심은 자세하고 구체적인 기획서를 지양한다는 점이다. PRD는 새로운 제품의 목적과 방향성을 정의하는 문서로 나침반이 되어줄 뿐 구체적이고 장황한 세부사항을 담지 않는다. PRD에는 제품의 목적, 기능, 동작 방식, 그리고 시작에서 제품을 성공적으로 출시하는 데 필요한 모든 요소가 포함되어야 한다.
PRD의 효과
PRD를 통해 기획자, 디자이너, 개발자가 같은 기준으로 협업할 수 있으며, 어떤 기능이 중요한지 분명해져 리소스를 효율적으로 배분할 수 있다. 또한 중복 개발과 재작업을 최소화하고, QA 및 테스트 케이스 작성 시 기준점이 명확해져 품질 향상이 기여한다.
목표 설정
PRD 작성 의 목적과 제품의 비전을 명확히 정의한다. 예를 들어 "신규 기능 도입을 통해 사용자 경험을 개선하고, 월간 활성 사용자 수(MAU)를 20% 증가시키는 것"과 같은 구체적인 목표를 설정한다. 이를 통해 팀원들이 프로젝트의 방향성을 이해하고, 목표 달성을 위해 집중할 수 있도록 돕는다.
그럼 PRD는 어떻게 작성할까?
PRD는 회사마다, 팀마다 각자 다른 템플릿을 사용하기 때문에 정답은 없다. 하지만 핵심적으로 담겨야 할 내용은 비슷하기 때문에 아래 요소들을 참고해보면 좋을 것 같다.
1. 제품 개요 (Overview)
우리 프로덕트에 어떤 문제가 있는지, 이를 해결하기 위해 무엇을 할것인지에 대해 간략하게 배경과 목적을 작성한다.
주로 이 프로덕트(또는 기능)을 왜 (Why) 만드는 것인지, 마주한 문제는 어떻게 해결할 수 있는지를 작성하여 팀원들이 모두 같은 이해도를 가지고 진행할 수 있도록 설명해야한다.
2. 목표 (Goals)
목표 또한 크게 정해진 것이 없다. 다만 나의 경우는 Business Goals, User Goals, Non Goals로 나누어 작성해볼려고 한다. 이렇게 목표를 나누어서 작성하게 되면 추후에 팀원들과 의사결정을 하게될 때 기준으로 삼을 수 있을 것 같다는 생각이 들었다.
Business Goals
주로 회사의 KPI(핵심성과지표, Key Performance Indicator)와 연관지어서 '매출 증가', 'MAU', 'Retention' 등의 지표를 목표를 두고 작성한다.
예시 1: 신규 기능 런칭 이후 3개월 이내 MAU 20% 증가
예시 2: 신규 기능 런칭 이후 6개월 이내 고객 이탈률 15% 감소
단순하게 숫자만 높이는것 보다 특정 지표를 어떤 방식(신규 기능 / 마케팅 / 제품 개선 등) 으로 언제까지 달성할 것인지 에 대해 명확하게 작성해야 팀원들이 쉽게 이해하고 움직일 수 있다.
Business Goals는 회사 전체의 성장을 견인하는 것이므로 다양한 부서와 협업이 필요할 수 있다. 부서별, 직군별로 협의하여 모든 이해관계자가 공감대와 책임을 갖도록 하는 것이 중요하다.
User Goals
이 프로젝트(또는 기능)을 통해 우리의 고객이 어떤 가치를 얻을 수 있는지에 대해 작성한다. 주로 UX와 연관된 목표들이 포함된다. 항상 사용자 관점에서 생각하고 작성하는 것이 중요하다.
예시 1: 사용자가 목표에 집중할 수 있도록 UX 간소화
예시 2: 사용자가 한 눈에 다양한 기능을 파악할 수 있도록 UI 개선
실제 사용자 피드백이나 사용자 조사 등을 통해 정량적, 정성적 인사이트를 얻어두면 User Goals 작성에 큰 도움이 된다.
User Goals를 통해 사용자 중심 의사결정을 할 수 있게 되며 장기적으로 제품 품질과 브랜드 이미지를 향상시키는 데 크게 기여할 수 있다.
Non Goals
우선순위가 낮거나 이번 프로젝트 범위에 포함되지 않는 목표를 적는다.
"이 기능을 넣게 되면 기능이 너무 복잡해질 것 같다."
"이 기능은 다음 버전에 넣는게 좋을 것 같다."
이런 식으로 분류해두게 되면 이후 이슈가 발생했을 때 빠르게 의사결정을 할 수 있다. "이 기능은 Non Goals에 해당하므로 이번 프로젝트에서는 다루지 않는다." 라고 말할 수 있기 때문이다.
다만 목표를 작성할 때는 너무 많지 않으면서 수치를 포함하여 구체적으로 2~3개 정도만 작성하여 집중할 수 있도록 하고, 지표간의 충돌이 발생하여 고객 경험이 헤쳐지지 않도록 하는것이 중요하다.
3. 사용자 시나리오 (User Scenarios)
사용자 관점으로 구체화하기 위해서는 시나리오가 필요하다. 기능이 추가되었을 때 고객들이 어떻게 사용할지 예상할 수 있고, 그 과정에서 고려해야하는 UX가 무엇인지를 알 수 있다.
또한 이를 바탕으로 엔지니어들은 예외 케이스를 찾아낼 수 있어 좀 더 안정적인 프로덕트를 만들 수 있도록 돕는 역할을 한다.
[시나리오 예시]
사용자 유형: 취업 준비생 도비
- 아침 9시 : 오늘의 면접 질문 푸시 알림 수신
- 12시 전: 알고리즘 문제 풀이 (뽀모도로 4 세선)
- 점심 후 : 오늘의 질문에 대한 답변 작성 및 모범답안 확인
- 저녁 : TIL 작성으로 하루 학습 정리
- 취침 전 : 통계를 확인하며 성취감 획득
4. 성공 지표 (Metrics / KPIs)
프로젝트가 끝난 뒤, 우리가 도입한 기능이나 서비스가 실제로 어떤 성과를 냈는지 확인하고, 회고하기 위해서는 명확한 성공 지표가 필요하다.
예를 들어 "고객이 이 기능을 얼마나 자주 이용하는가?", "우리 매출에 얼마만큼 기여하는가?", "서비스 평판은 어떻게 달라졌는가?" 등 구체적인 수치와 데이터를 통해 성공 여부를 파악할 수 있어야 한다.
단순히 '지표 수치'만을 확인하는 것이 아니라 지표별 목표치를 사전에 설정해두고 그 원인과 인사이트를 찾는 것이 중요하다.
성공 지표 : "도입 후 3개월 이내 활성 사용자 수 20% 증가"
결과 회고 : "활성 사용자 수가 15% 증가했으나 목표치에 미달. 주요 원인은 A/B 테스트 결과에서 나타난 UI 불편함으로 인한 이탈률 증가로 분석됨."
5. 핵심 기능 목록 (Features & Requirements)
프로젝트에서 모든 기능을 다 개발하면 좋겠지만, 보통 스프린트라는 제약된 일정과 리소스에서 진행하기 때문에 기능은 우선순위를 3가지로 나누어 분류한다.
Must Have
- 필수 조건, 반드시 구현되어야 하는 기능
- 이 기능이 없다면 제품 / 서비스의 핵심 가치를 전달할 수 없음
Should Have
- 필요조건, 매우 필요하다고 생각하는 기능
- 사용 편의성을 높이거나 핵심 프로세스 효율화를 위해 필요한 요소
Could Have
- 선택 조건, 사용자 만족도를 높일 수 있으나, 반드시 필요한 것은 아님
- 일정과 리소스에 여유가 없을 때 추가적으로 개발할 기능
해결해야하는 문제에 따라 Must Have, Should Have 까지는 포함하고, 여유가 된다면 Could Have 까지 개발하기도 한다. 문제를 해결하기 위해 필요하다고 생각하는 기능을 모두 리스트업한 이후에 목표에 따라 기능별 우선순위를 매기고 팀의 속도에 따라 Could Have 까지 진행해도 되고, 백로그로 남겨도 된다.
6. 기술 요구사항 (Technical Requirements)
프로젝트를 진행하는 과정에서 외부 API, 시스템, 클라우드 서비스, 데이터베이스 인프라, 보안 규칙 등 기술적인 의사결정이 필요한 순간들이 많다. 이때는 관련 내용을 사전에 충분히 리서치하고 문서화해두면 엔지니어들과 긴밀하게 협의할 수 있어서 개발 리스크를 크게 줄일 수 있고, 필요한 일정을 빠르게 파악할 수 있다.
외부 서비스를 이용하게 되면 제약사항도 생기고, 경우에 따라 개발 스펙 자체를 조정해야하는 경우도 생기기 때문에 반드시 사전에 리서치하고, 커뮤니케이션 하는 것이 중요하다. (QA 엔지니어와 커뮤니케이션 하는 과정에서도 반드시 필요하다.)
7. 일정 계획 (Time-line) 또는 목표일 (Target date)
프로젝트 진행 시 세부적인 일정은 보통 스프린트 플래닝에서 최종적으로 결정하지만 때로는 경영진과 협의된 날짜나 마케팅 일정 등에 맞추어 출시해야하는 경우가 있다. 비즈니스와의 연관성을 고려하여 중요한 이정표(Milestone) 이나 목표 일정을 간단히 명시해두면 팀원들에게 설명할때도 여러모로 도움이 된다.
일정에 따라 개발 범위가 조정될 수 있으니 경영진과 최대한 많이 소통하여 주요 일정에 변동이 있는지 꼭 체크하는 것이 중요하다.
8. 예상 질문 (Q & A)
프로젝트나 기능 기획을 정리한 PRD를 읽다 보면 문서를 읽는 팀원, 경영진 등 모두가 궁금해할 만한 질문이 자연스럽게 생긴다. 이때 자주 나올 법한 질문과 해당 질문에 대한 답변을 미리 문서에 작성해두면 커뮤니케이션을 효율적으로 진행할 수 있다.
스스로 작성한 문서를 보고 예상 질문에 대한 내용을 추가하다보면 '본문에 적는게 좀 더 명확하겠다' 같은 생각을 할 수 있기 때문에 전체적으로 문서가 탄탄해지는데 도움이 된다.
9. 추가 자료 (References)
PRD를 작성하면서 참고했던 사이트나 사용자 인터뷰, 시장 조사, 경쟁사 분석 등은 프로젝트의 출발점이자 근거가 된다. 이 자료들을 링크 또는 별첨 형식으로 정리해두면, 프로젝트를 검토하는 모든 이해관계자가 쉽게 배경 지식을 확인하고, 논리적 근거를 파악할 수 있다.
마무리
요즘 Vibe 코딩을 많이 시도하게 되는데, PRD를 명확하게 작성하고 시도하게 된다면 조금 더 높은 퀄리티의 프로젝트를 기대할 수 있을 것 같다. 실제로 PRD를 작성해서 "디스코드 번역 봇 만들기" 프로젝트를 진행해본 경험이 있다. 물론 중간중간에 마음에 들지 않는 코드나 잘못 구현된 기능이 존재했지만, 실제로 사용하기에는 크게 문제없을 정도로 높은 완성도의 프로젝트를 만들 수 있었다.
Vibe 코딩뿐만 아니라 프로젝트 기획 단계에서도 PRD를 작성한 이후에 진행하게 된다면 팀원들 간 소통에서 올바른 방향성을 제시할 수 있을 것 같다. 항상 문서를 작성하여 프로젝트를 진행하는 습관은 중요하다고 생각한다. 길을 잃었을 때 다시 돌아올 수 있는 나침반은 문서화된 기획서들이 유일하다는 것을 잊지말자. AI에 과하게 의존하는 것 보다는 더 똑똑하고 현명한 팀원들과 소통하기 위해 많은 노력을 해보자!