PRD 작성하는 방법

NASA low power DIPS [Dynamic Isotope Power System] conceptual design requirements document https://digital.library.unt.edu/ark:/67531/metadc703023/m1/1/

 

시작하기

서비스 기획자로 일하며 가장 큰 비중을 차지하는 업무는 화면 설계와 로직 정의이였으며, 기획자의 의도를 개발자와 디자이너에게 잘 전달하는 것이 중요했다. 

 

첫 직장은 제가 첫 기획자였고, 제가 입사하기 전에는 A4 용지에 손으로 화면을 그려 개발자에게 전달하던 곳이였다. 사수도, 참고할만한 내부 문서/가이드라인도 없어서 네이버/다음 카페, 학원, 스터디모임을 통해 어떻게 기획을 하는지 배우려고 했다. 기획서에 대해 기대치가 낮아서 첫 직장의 환경은 편했지만, '어떻게 하면 더 기획을 잘할까?’, “어떻게 해야 기획서를 잘 쓸까?”의 질문이 항상 머릿속에 멤돌았다.

 

연차가 쌓이며 직군명이 PO/PM으로 변모하는 과정을 지켜보며, 단순한 '화면 설계'를 넘어 문제 정의와 측정 가능한 지표로 팀을 설득하는 영역이 되었다. "어떻게 하면 더 명확하게 문제를 정의하고 제품을 만들 수 있을까?"라는 고민을 통해 그 뿌리인 PRD(Product Requirements Document)의 역사와 본질을 정리해보려고한다.

 

 

 

PRD의 역사

요구사항 정의서는 시대의 요구에 따라 그 철학이 달라졌다.

시대	핵심 철학	문서의 성격 (PM의 관점)
1) 미군 표준 (MIL-STD)	무결성	"오차 없는 명령서" - 기획대로 안 나오면 사고다.
2) 70~90년대 (폭포수)	정교함	"기술 명세서" - 모든 기능을 촘촘히 적어야 개발이 시작된다.
3) 2000년대 (애자일)	가치 전달	"대화의 도구" - 유저가 진짜 원하는 가치를 담는다.
4) 현재 (가설 중심)	임팩트	"가설 검증서" - 이 문제를 풀면 이 지표가 오를 것인가?

1. 1968년 이전(하드웨어 시대) : 소프트웨어는 부속품에 불과했음
2. 1968년 (MIL-STD-490 탄생) : 미 국방부가 “무기 체계가 너무 복잡하니, 만들기 전 규격부터 표준화해서 가져와라”라고 명령했으며, 이것이 모든 기획서의 서막
3. 1970년대(폭포수 확산) : 490 표준이 IBM 등 대형 벤더로 퍼지며 SRS(software requirements specification)가 정착됨
4. 1984년 (IEEE 830) : 군용 표준을 민간에서도 쓰기 좋게 IEEE에서 표준화
5. 1994년 (MIL-STD-498) : 490과 다른 파편화된 군 표준들을 하나로 통합(폭포수 문서화의 정점)
   - 기존 파편화 떄문에 비용과 협동 작전에서 결함이 발견되어서 통합됨
   - 통합되어 “비용”이 절감되었으며, 데이터 정의하기가 편해져 상호 운용성이 좋아짐
   - 미군의 이러한 과정을 보면 “전사 표준 가이드라인”의 필요성을 알 수 있음
6. 2000년대 이후(애자일) : 유연한 User Story 등장하며, 기술명세서가 아닌 비즈니스 목표와 사용자 가치의 요약본으로 변화하기 시작함
7. 현재 : '가설 검증' 중심이 되었으며, 한 페이지 내에 핵심(문제, 목표, 지표)을 담는 방식이 선호된된다. 어떤 지표를 통해 성공을 측정할 것인가(Success Metrics) 가 필수 항목이 되었음

글로벌 기업 PRD 분석

PRD 양식은 기업마다 강조하는 것이 무엇인지에 따라 양식이 조금씩 다르다.

Lennys newsletter가 추천하는 PRD 문서를 보고 내가 얻은 인사이트는 다음과 같다.

 

Insight 1. What 보다 Why에 많은 시간을 할당한다.

• 모든 항목의 시작은 Why이다. 어떤 배경이고 어떤 문제가 있는지 정의한다.
• 문제 정의에 대해 합의 후, 문제 해결 방안에 대해 진행한다.

Insight 2. 해결해야 할 문제에 대한 경계선을 정확하게 정의한다.

• 목표가 무엇인지, 목표가 아닌 것이 무엇인지 정의한다.
• 작업을 해야하는 것, 하지 않는 것을 정의한다.

Insight 3. 지표는 결과가 아니라 설계이다.

• 측정 가능한 지표와 측정 하기 어려운 지표를 작성하여, 솔루션에 대한 성과를 객관적으로 분석할 수 있도록 한다.

Insight 4. 투명하게 공개하고 커뮤니케이션을 원활하게 진행한다.

• 누구나 PRD 문서를 확인하고, 질문할 후 있으면, 질문과 답변은 기록된다.
• 이를 통해 모두가 문제가 무엇이고, 솔루션이 무엇인지 이해할 수 있도록 한다.

 

PRD, 꼭 모든 업무에 작성해야 할까? (활용 범위에 대한 고찰)

PRD 양식을 고집하다보면, "단순 문구 수정인데 PRD를 써야 하나?", "핫픽스 대응 중인데 문서화해야하나?" 하는 의문이 들때가 있다. 나는 PRD는 프로젝트의 '크기'가 아니라 '복잡도와 소통의 비용'에 따라 무게를 달리해야 하는 문서라고 생각한다.

"이 문서가 없다면, 동료들이 나에게 10번 이상 질문하러 올 것인가?"

 

이 질문에 대한 대답이 "YES"라면, 아무리 작은 기능이라도 핵심 로직은 기록해야한다. 반대로 대답이 "NO"라면 과감하게 안해도 된다. PRD는 우리의 목적을 팀원들이 오해하지 않게 만드는 '도구'일 뿐이지, 그 자체가 '목적'이 되어서는 안 되기 때문이다.

 

PRD가 '약'이 되는 순간 (작성 권장)

• 신규 서비스 런칭: 서비스의 전체 목적, 타겟, 핵심 가치를 한 방향으로 정렬할 때.
• 주요 기능 업데이트: 예) 커머스 앱에 '선물하기' 추가 시. (결제/배송/알림 시스템과의 복잡한 연동 정의)
• 대규모 실험 및 개선: 로직이 크게 변경되는 A/B 테스트나 복잡한 정책 변경 시.

PRD가 '독'이 되는 순간 (생략/간소화 권장)

• 단순 문구/UI 개선: 기획 의도 설명에 5분도 안 걸리는 자잘한 수정.
• 긴급 버그 수정(Hotfix): 일단 고치고 사후 기록으로 대체
• 초기 가설 검증 단계: '가설 검증 단계에서의 PRD는 '설계도'가 아니라 '실험 계획서'여야 한다

프로젝트 규모에 따른 '문서 해상도'를 조절한다.

업무의 성격에 따라 문서의 디테일을 조절 한다.

구분	소규모 (단순 개선, 티켓 처리)	중·대규모 (신규 기능, 개편)
방식	지라(Jira) 등 티켓 본문 설명	정식 PRD 문서 작성
핵심 내용	변경 전/후 비교, 기대 효과	배경, 유저 스토리, 상세 로직, 예외 케이스
소통	메신저나 구두 공유 후 기록	공식 킥오프 및 문서 리뷰 세션

 

마치며...

A4 용지에 그림을 그리던 시절부터 지표를 설계하는 지금까지, 형태는 변했지만 " 우리가 무엇을, 왜 만드는가? "라는 본질은 같다.

문서를 통해 팀원들의 오해를 줄여주며, 하나의 목표를 향해 나아갈 수 있도록 한다.

위에서 이야기한것처럼 PRD는 도구일 뿐이지 목적이 되어서는 안된다.