PRD(제품 요구사항 문서) 템플릿 + 그대로 복사할 수 있는 전체 작성 예시

PRD(제품 요구사항 문서) 템플릿 + 그대로 복사할 수 있는 전체 작성 예시

마지막 업데이트: 2026년 7월 28일.

대부분의 PRD(제품 요구사항 문서) 템플릿 페이지는 빈 양식만 던져줍니다. Atlassian의 템플릿은 지침 4개 섹션이 텅 빈 성공 지표 표를 감싸고 있을 뿐입니다. Product School의 템플릿은 제목에 "(예시 포함)"이라고 적혀 있지만 정작 예시는 없습니다. 아래의 12섹션 마크다운 블록이 템플릿 그 자체이며, 무료로 제한 없이 그대로 복사해 쓸 수 있습니다. 이어지는 섹션에서는 그 12개 섹션 전부를 완전한 작성 사례로 채워 보여줍니다. LLM으로 PDF를 읽어들이고, 확신이 서지 않는 건은 사람에게 넘기는 클라이언트용 청구서 포털입니다. 빈 템플릿을 복사하세요. 채워진 예시를 읽으세요. 당신의 것을 쓰세요.

핵심 요약

• PRD는 무엇을 왜 만드는지에 답하고, 기술 설계 문서는 어떻게 만들지에 답한다.
• 12개 섹션은 프로젝트 규모에 상관없이 적용된다. 원페이저는 같은 템플릿에서 행이 줄어든 것뿐이다.
• 비목표(non-goals)는 반드시 글로 적어야 한다. AI 코딩 에이전트는 생략만으로 범위를 유추하지 못한다.
• 인수 기준은 기계가 판정할 수 있어야 한다. "p95가 400ms 이하"는 되지만 "빠르게"는 안 된다.

어떤 형태의 PRD를 써야 할까?

형태는 제품이 얼마나 커 보이는지가 아니라 누가 그 문서를 읽는지로 정한다. 자사 엔지니어에게 넘길 단일 기능이라면 원페이저면 충분하다. 외부 팀에 맡기는 빌드는 전체 12섹션 PRD가 필요한데, 인수 기준이 그대로 승인 게이트 역할을 하기 때문이다. AI 코딩 에이전트에게 넘기는 스펙은 같은 12개 섹션을 단계별로 잘라서 써야 한다.

다들 찾는 한 장짜리 제품 요구사항 문서 템플릿은 별개의 산출물이 아니다. 널리 복사되는 Lenny Rachitsky의 원페이저는 그의 뉴스레터에 실제 사례와 함께 공개돼 있는데, 절차만 걷어낸 같은 뼈대다. 원페이저는 다른 문서가 아니다. 빈 행을 지운 똑같은 12개 섹션일 뿐이다.

애자일 팀도 이 질문을 자주 던진다. 보통은 PRD가 백로그 앞에서도 살아남는지 묻는 식이다. 원페이저 형태라면 살아남는다. PRD는 이유와 경계를 담고, 티켓은 작업 내용을 담는다.

PRD 템플릿 (복사-붙여넣기용 마크다운)

전체를 마크다운으로 준비했다. 무료이고, 이메일 등록도 필요 없다. Notion, Confluence, Google Docs, Linear에 붙여넣거나 PRD.md로 GitHub에 커밋해 코드와 함께 버전 관리해도 된다. 사람들은 이 템플릿을 아홉 가지쯤 되는 형식으로 요청하는데, 그중 어디에 붙여넣어도 무너지지 않는 게 마크다운이고, AI 코딩 에이전트가 구조를 잃지 않고 읽을 수 있는 유일한 형식이기도 하다.

# PRD: [제품 또는 기능 이름]

## 1. 헤더
- 담당자(제품):
- 엔지니어링 리드:
- 디자인 리드:
- 상태: Draft | In review | Approved | Shipped
- 마지막 업데이트:
- 변경 이력: 날짜 / 작성자 / 변경 내용

## 2. 문제 정의
한 문단으로. 누가, 얼마나 자주 겪고, 지금 얼마나 비용이 드는지. 해결책 언어는 쓰지 않는다.

## 3. 목표 및 성공 지표
| 목표 | 지표 | 기준값 | 목표값 | 측정 방법 | 날짜 |
|---|---|---|---|---|---|

## 4. 비목표
긍정문으로 서술한다: "이번 단계에는 X를 포함하지 않는다."

## 5. 사용자 및 페르소나
누가 사용하고, 무엇을 이미 알고 있으며, 어떤 기기를 쓰고, 얼마나 자주 쓰는지.

## 6. 사용자 스토리 및 인수 기준
[페르소나]로서 나는 [행동]을 원한다, 그래야 [결과]를 얻기 때문이다.
- [상황]이 주어지고, [사건]이 발생하면, [관찰 가능한 결과]가 나타난다.

## 7. 기능 요구사항
번호를 매긴다. 한 줄에 한 요구사항. 테스트 가능해야 한다. "그리고"가 들어간 문장은 금지.

## 8. 비기능 요구사항
성능 / 보안 및 테넌시 / 데이터 거주지 및 보존 / 접근성 / 가용성.

## 9. 의존성 및 연동
외부 시스템, API, 자격 증명, 접근 권한 담당자, 소요 기간.

## 10. 마일스톤 및 단계 구분
| 단계 | 범위 | 종료 조건 | 목표 날짜 |
|---|---|---|---|

## 11. 미해결 질문 및 리스크
| 질문 또는 리스크 | 담당자 | 필요 시점 | 미해결 시 영향 |
|---|---|---|---|

## 12. 부록 및 링크
디자인, 리서치, 경쟁사 노트, 이전 티켓, 계약서.

12개 섹션을 순서대로 나열하면 이렇다. 헤더, 문제 정의, 목표 및 성공 지표, 비목표, 사용자 및 페르소나, 인수 기준을 포함한 사용자 스토리, 기능 요구사항, 비기능 요구사항, 의존성 및 연동, 마일스톤 및 단계 구분, 미해결 질문 및 리스크, 부록.

PRD에는 무엇이 들어가야 할까? 12개 섹션, 그리고 각 섹션의 부실한 버전

제품 요구사항 문서에는 문제 정의, 측정 가능한 목표, 명시적인 비목표, 페르소나, 인수 기준이 딸린 사용자 스토리, 기능·비기능 요구사항, 의존성, 마일스톤, 담당자가 지정된 미해결 질문, 변경 이력이 들어가야 한다. 그 외에는 전부 부록이다. 각 줄의 기준은 ISO/IEC/IEEE 29148:2018이 요구사항 일반에 적용하는 것과 같다. 검증 가능하고, 모호하지 않고, 단일해야 한다.

대부분의 PRD는 정확히 같은 세 지점에서 이 기준을 통과하지 못한다.

두 섹션은 보통 받는 관심보다 더 큰 관심을 받아야 한다.

비기능 요구사항은 범위가 조용히 두 배로 불어나는 지점이다. 성능, 테넌시, 데이터 거주지, 보존, 접근성, 가용성. 이 각각은 비용이 따르는 엔지니어링 결정이고, 그 어느 것도 사용자 스토리에는 등장하지 않는다. 보안 항목은 두루뭉술하게 넘어가지 말고 여기에 명시하라. 우리의 출시 전 보안 체크리스트를 항목 목록으로 삼아, 실제로 검증하고 싶은 방식 그대로 써라. AI 요소가 들어간 빌드라면 프로덕션 준비 요구사항도 여기에 넣어야 한다. 절대 일정에 잡히지 않는 나중의 "안정화" 단계로 미루면 안 된다. 우리가 실제로 쓰는 버전은 PoC에서 프로덕션까지 체크리스트다.

미해결 질문에는 세 개의 열이 필요하다. 하나가 아니라. 질문, 담당자, 필요 시점. 담당자가 없는 질문은 아무도 내리지 않는 결정이고, 6주 차쯤 변경 요청으로 다시 튀어나온다. 짚어둘 점 하나. PRD는 구매가 아닌 직접 개발을 결정한 뒤 쓰는 문서다. 문제 정의가 여전히 기능 쇼핑 리스트처럼 읽힌다면, 개발이냐 구매냐 하는 결정이 아직 실제로는 내려지지 않은 것이다.

작성 예시: 청구서 포털 PRD, 채워서 보기

여기 완전한 작성 예시가 있다. 12개 섹션 모두 채워졌다. 만드는 대상: 중견 물류 업체를 위한 클라이언트용 청구서 포털이다. 고객이 PDF 송장을 업로드하면 LLM이 항목을 추출하고, 시스템이 주문 기록과 불일치하는 부분을 표시하며, 확신이 서지 않는 건은 사람이 검토하는 대기열로 넘어간다. 스택: Next.js, Supabase/Postgres, LLM 추출 단계 하나. 복사하든, 인쇄하든, PDF로 내보내든 필요한 대로 쓰면 된다.

# PRD: 클라이언트 청구서 포털, 1단계

## 1. 헤더
- 담당자(제품): 운영 이사, 클라이언트 측
- 엔지니어링 리드: 딜리버리 리드, Techsy
- 디자인 리드: 프로덕트 디자이너, Techsy
- 상태: Approved for build
- 마지막 업데이트: 2026-07-28
- 변경 이력:
  - 2026-07-14 / 제품 / 첫 초안
  - 2026-07-21 / 엔지니어링 / 6.2에 신뢰도 임계값 규칙 추가
  - 2026-07-28 / 제품 / ERP 재기입을 비목표로 이동

## 2. 문제 정의
운영팀은 고객이 이메일로 보낸 PDF 송장을 받아 주문 시스템에 수기로
재입력한다. 물량은 주당 300건을 넘고, 건당 평균 처리 시간은 약 6분이며,
약 4%는 입력 오류가 월말 정산 때에야 발견된다. 정정 한 건마다 재확인
작업과 통화가 추가로 든다.

## 3. 목표 및 성공 지표
| 목표 | 지표 | 기준값 | 목표값 | 측정 방법 | 날짜 |
|---|---|---|---|---|---|
| 수기 처리 축소 | 평균 처리 시간 | 6분 | 90초 이하 | 운영 대시보드, 주간 중앙값 | 2026-11-01 |
| 입력 오류 축소 | 정산 시 정정된 송장 비율 | 4% | 1% 이하 | 재무 월말 리포트 | 2026-12-01 |
| 검토 부담 억제 | 사람 검토로 넘어가는 비율 | 해당 없음 | 25% 이하 | 포털 대기열 지표 | 2026-11-01 |

## 4. 비목표
이번 단계에서는 다중 통화 송장, ERP 재기입, 고객 셀프서비스 크레딧
노트, 모바일 앱을 지원하지 않는다. 추출은 PDF만 다룬다. 종이 송장
사진과 200 DPI 미만 스캔본은 업로드 시점에 이유 안내와 함께 거부된다.

## 5. 사용자 및 페르소나
- 운영 담당자(주요, 6명): 하루 종일 예외 대기열을 처리하며, 도메인
  지식이 깊고, 데스크톱만 사용한다.
- 고객사 AP 담당자(외부, 약 140개 계정): 송장을 업로드하며, 계정
  설정 과정의 마찰을 잘 견디지 못한다.
- 재무 매니저(부차): 월말 리포트를 뽑으며, 송장별 감사 기록이
  필요하다.

## 6. 사용자 스토리 및 인수 기준
6.1 고객사 AP 담당자로서 나는 송장 PDF를 업로드하고 싶다, 그래야
이메일로 보내고 기다릴 필요가 없기 때문이다.
- 20MB 이하, 200 DPI 이상의 PDF가 주어지고, 업로드하면, 포털은 5초
  이내에 참조 번호를 반환하고 "처리 중"을 표시한다.

6.2 운영 담당자로서 나는 신뢰도가 낮은 추출 결과를 보류시키고 싶다,
그래야 잘못된 항목이 자동 승인되지 않기 때문이다.
- 파싱된 송장이 주어지고, 어느 항목이든 추출 신뢰도가 0.85 미만이면,
  해당 송장은 검토 대기열로 넘어가고 절대 자동 승인되지 않는다.

6.3 운영 담당자로서 나는 불일치 내역을 한곳에서 보고 싶다, 그래야
주문 시스템을 열지 않고도 처리할 수 있기 때문이다.
- 주문과 매칭된 송장이 주어지고, 어느 항목의 수량이나 단가가 주문
  기록과 다르면, 포털은 두 값을 나란히 보여주고 차액을 표시한다.

6.4 재무 매니저로서 나는 송장을 필터링하고 싶다, 그래야 월말을
마감할 수 있기 때문이다.
- 송장 목록이 주어지고, 벤더·기간·상태로 필터링하면, 결과는 p95
  400ms 이내에 반환되고 결과 없음 화면에는 "필터 초기화"가 나타난다.

## 7. 기능 요구사항
1. 업로드는 PDF만 허용하며, 최대 20MB, 제출당 파일 1개.
2. 추출 결과는 벤더, 송장 번호, 날짜, 통화, 수량·단가·합계가 포함된
   항목을 반환한다.
3. 각 항목은 0~1 사이의 신뢰도 점수를 갖는다.
4. 매칭은 추출된 송장을 PO 번호 기준으로 열려 있는 주문과 비교한다.
5. 예외 건은 오래된 순으로 정렬된 대기열에 들어가고, 담당자 1명에게
   배정할 수 있다.
6. 모든 상태 변경은 담당자, 타임스탬프, 이전 값을 기록한 감사 항목을
   남긴다.
7. 승인된 송장은 재무 시스템용 CSV 배치로 내보내진다.

## 8. 비기능 요구사항
- 성능: 송장 목록 p95는 400ms 이하. 추출은 업로드 후 p95 90초 이내에
  완료된다.
- 보안 및 테넌시: 테넌트별 격리를 데이터베이스 행 단위에서 강제한다.
  고객은 다른 고객의 송장을 절대 읽을 수 없다. 매 릴리스마다
  자동화 테스트로 검증한다.
- 데이터 거주지 및 보존: 문서는 EU에 저장된다. 원본은 7년, 추출
  페이로드는 90일 보존한다.
- 접근성: 대기열은 키보드만으로 완전히 조작 가능하며, WCAG 2.2 AA
  대비 기준을 충족한다.
- 가용성: 월 99.5%, 업무 시간 중 지원.

## 9. 의존성 및 연동
- 주문 기록: 읽기 전용 Postgres 레플리카. 접근 권한은 클라이언트
  IT팀이 소유하며, 자격 증명은 2026-08-15까지 필요.
- LLM 추출 제공사: 빌드 시작 전에 계약과 데이터 처리 계약서 서명
  완료.
- 이메일 알림: 기존 트랜잭션 메일 제공사, 발신 도메인은 클라이언트가
  검증.

## 10. 마일스톤 및 단계 구분
| 단계 | 범위 | 종료 조건 | 목표 날짜 |
|---|---|---|---|
| P1 | 업로드, 추출, 신뢰도 라우팅 | 실제 송장 50건 종단간 처리, 대기열 비율 25% 미만 | 2026-09-19 |
| P2 | 주문 매칭 및 불일치 화면 | 시드 케이스 20건에서 불일치가 정확히 표시됨 | 2026-10-10 |
| P3 | 감사 기록, CSV 내보내기, 리포팅 | 재무팀이 포털에서 한 달을 마감함 | 2026-11-01 |

## 11. 미해결 질문 및 리스크
| 질문 또는 리스크 | 담당자 | 필요 시점 | 미해결 시 영향 |
|---|---|---|---|
| 송장에 PO 번호가 두 개 표시될 때 어느 쪽이 정본인가? | 클라이언트 운영 이사 | 2026-08-08 | 매칭 로직 막힘 |
| 상위 12개 고객사는 스캔본을 보내는가, 네이티브 PDF를 보내는가? | 딜리버리 리드 | 2026-08-08 | 신뢰도 임계값이 틀릴 수 있음 |
| 7년 보존이 클라이언트 법무팀과 확정됐는가? | 클라이언트 재무 매니저 | 2026-08-22 | 저장 설계와 비용 변경 |
| 주당 300건 기준 송장당 추출 비용 | 딜리버리 리드 | 2026-09-05 | 단위 경제성 불확실 |

## 12. 부록 및 링크
익명화된 샘플 송장 세트(40개 파일), 주문 테이블 스키마, 현재 처리
시간 조사 자료, 업로드·대기열 Figma 플로우, 서명된 작업지시서.

여기서 네 가지 선택은 짚고 넘어갈 가치가 있다. 대충 넘기는 버전이 실제 돈으로 되돌아오기 때문이다.

3번 섹션, 기준값. "6분"은 장식이 아니다. 기준값이 없으면 효과가 있었는지 판단할 수 없고, 6개월 뒤 회의에서 데이터 없이 누군가와 언쟁하게 된다. "효율을 개선한다"는 대충 넘긴 버전은 프로젝트를 반증 불가능하게 만든다.

4번 섹션, 비목표. ERP 재기입은 리뷰 통화 중에 슬쩍 전제로 들어와 있다가 2026-07-28에 비목표로 옮겨졌다. 비목표로 적어두는 데는 한 줄이면 됐고, 범위 다툼 하나를 막았다.

6.2 섹션, 신뢰도 임계값. 우리 자신의 초안이 가장 자주 빠뜨리는 규칙이다. 이걸 빼면 시스템은 사람이 봤어야 할 송장을 자동 승인하게 되고, 이는 3번 섹션에서 약속한 시간 절감을 그대로 지워버리는 실패 유형과 정확히 같다.

11번 섹션, 담당자. 모든 미해결 질문에 이름과 날짜가 붙어 있다. 그 열이 문서와 아무도 안 챙기는 할 일 목록 사이의 차이를 만든다.

PRD는 무엇을 만들지 알려준다. 얼마나 걸리고 얼마가 드는지는 알려주지 않는데, 그건 별도의 작업이다. 그 절반은 빌드 범위 산정을 참고하라. 그리고 적어두지 않은 비목표는 누군가 만들게 될 기능이다.

AI 코딩 에이전트가 실제로 작업할 수 있는 PRD는 어떻게 쓸까?

AI 코딩 에이전트를 위한 PRD는 간결함 대신 명시성을 택한다. 에이전트에게는 복도에서 주워들은 맥락도, 공유된 히스토리도, 당신이 굳이 말하지 않은 의도를 짐작할 감각도 없다. 이 차이의 대부분은 네 가지 규칙으로 정리되며, 우리가 직접 진행한 에이전트 협업 빌드에서 스펙이 성공하고 실패하는 걸 지켜보며 얻은 것이다.

1. 비목표는 긍정문으로 적는다. 사람은 생략에서 범위를 유추한다. 에이전트는 그러지 못한다. "이번 단계에는 인증을 추가하지 않는다"는 반드시 문서에 문장으로 존재해야 한다. 안 그러면 인증이 만들어지고, 테스트되고, 돌려받게 된다.

2. 작업을 단계별로 잘게 나눈다. 40페이지짜리 하나의 덩어리는 자신만만하고, 산만하고, 절반만 맞는 풀 리퀘스트를 만들어낸다. PRD를 에이전트가 한 번의 실행으로 끝낼 수 있는 단위로 쪼개고, 각 단위마다 종료 조건을 명시한다.

3. 인수 기준을 기계가 판정할 수 있게 만든다. "빠르다"는 요구사항이 아니라 기분이다. "송장 목록 엔드포인트에서 p95 400ms 이하"는 에이전트가 기능을 작성하기 전에 테스트로 먼저 쓸 수 있는 조건이다.

4. 파일 경로와 스택 제약은 채팅이 아니라 문서에 넣는다. 채팅 맥락은 세션 사이에 사라진다. 스펙은 사라지지 않는다. Claude Code의 플랜 모드가 중요한 이유도 여기에 있다. 파일을 읽고 계획을 제안하되 승인 전까지는 아무것도 수정하지 않는데, 그 계획을 당신의 기억이 아니라 작성된 스펙과 대조해 검토할 수 있을 때 승인 단계가 훨씬 쓸모 있어진다.

이제 청구서 포털을 에이전트가 한 번에 실행할 수 있는 단계 하나로 잘라본다.

# 빌드 작업: 송장 업로드 및 추출 (3단계 중 1단계)

## 스택 제약 (대체 금지)
Next.js 15 App Router, TypeScript, Supabase Postgres with row-level security,
Vercel deploy. No new dependencies without asking first.

## 만들거나 수정해도 되는 파일
- app/(portal)/invoices/upload/page.tsx
- app/api/invoices/route.ts
- lib/extraction/parse-invoice.ts
- supabase/migrations/0007_invoices.sql

## 건드리지 말 것
- lib/auth/*  (auth ships in Phase 2; do not add sign-in flows now)
- Anything under app/(marketing)/
- The existing orders schema. Read it. Never migrate it.

## 인수 기준 (테스트부터 작성할 것)
1. POST /api/invoices rejects non-PDF with 415 and files over 20 MB with 413.
2. A line item with confidence < 0.85 sets invoice.status = 'review',
   never 'approved'.
3. Every insert writes an audit row with actor_id, action, created_at.
4. GET /api/invoices?vendor=&from=&to=&status= returns under 400ms on a
   10,000-row seed.

## 이번 단계 범위 밖
Order matching, mismatch UI, CSV export, email notifications.

사람이 쓴 버전과 비교하면 세 가지가 달라졌다. 파일 경로가 등장했고, 건드리지 말 목록이 생겼고, 인수 기준이 문장이 아니라 코드로 확인 가능한 조건이 됐다. 어느 에이전트에게 맡기느냐는 생각보다 덜 중요하지만, 코딩 에이전트 비교는 커밋 전에 읽어볼 가치가 있다. 요구사항과 프로젝트 규칙은 별도 파일에 두는 게 좋다. Cursor 규칙과 CLAUDE.md는 컨벤션과 툴링을 담고, PRD는 무엇을 만들지를 담는다. 범위 자체를 AI 도움으로 뽑아내고 싶다면 그건 별개의 워크플로다. 추출 단계 자체는, 모델 선택과 평가 루프가 별도의 AI 통합 작업이다.

외부 팀에 PRD를 넘기면 무엇이 달라질까

에이전시나 외주 업체에 PRD를 넘기는 순간, 이 문서는 정렬용 문서에서 계약 언어로 바뀐다. 사내 팀이라면 2분짜리 대화로 풀릴 모호함이 여기서는 가격표가 붙은 변경 요청이 된다. PMI의 Pulse of the Profession 조사에 따르면 실패한 프로젝트의 47%가 부정확한 요구사항 관리 때문에 목표를 달성하지 못한다. 이 문서가 존재하는 이유 전부가 여기에 있다.

이런 상황에서는 세 섹션이 유독 무겁게 작용한다. 인수 기준은 승인 게이트가 되므로, 엔지니어가 아닌 사람도 관찰 가능하게 써야 한다. 미해결 질문은 클라이언트 측에 이름이 지정된 담당자가 있어야 한다. 벤더는 그 질문에 답할 수 없고, 빈틈을 임의로 채워 만들 수밖에 없기 때문이다. 그리고 변경 이력은 더 이상 형식적인 절차가 아니다. 언제 무엇이 합의됐는지 남은 기록이며, 분쟁이 생기면 누구나 가장 먼저 꺼내 드는 자료다.

우리가 여러 번 잘못되는 걸 지켜본 문장은 대개 "사용자는 데이터를 내보낼 수 있다" 비슷한 것이다. 어떤 형식인지는 아무도 적지 않는다. 우리에게 비쌌던 실제 사례는, 클라이언트가 원한 건 자사 브랜딩이 들어간 서식 있는 PDF 청구서 묶음이었는데 CSV로 내보내기가 나가버린 경우였다. 다시 만드느라 아무도 산정하지 않은 엔지니어링 공수가 약 일주일 날아갔다. 솔직히 말하면 그 잘못은 전달이 아니라 문서에 있었다. 인수 기준 하나면 5분 만에 잡아냈을 일이었다. 내보내기 요청이 주어지고, 파일이 생성되면, 그 파일은 제공된 레이아웃과 일치하는 PDF다. 비목표 항목도 반대 방향에서 같은 걸 잡아냈을 것이다. 그래서 이제 우리 디스커버리 과정의 규칙은 이렇다. "내보내기", "리포트", "알림" 같은 명사에 걸린 요구사항은 형식, 트리거, 작성 예시가 함께 붙어야 작업지시서에 서명한다.

우리가 웹 애플리케이션 빌드를 진행하는 방식의 상당 부분이 바로 이것이다. 클라이언트 스펙의 모호한 절반을 코드를 쓰기 전에 테스트 가능한 문장으로 바꾸는 일.

r/ProductManagement은 PRD 템플릿에 대해 실제로 뭐라고 말할까

product requirements document template reddit을 검색하면 r/ProductManagement에서 같은 불만이 반복되는 걸 보게 된다. 템플릿 비대화. 아무도 안 읽는 PRD. 템플릿에 제목이 있다는 이유만으로 채워진 섹션들. 킥오프 다음 날 바로 낡아버려 슬랙 스레드로 조용히 대체되는 문서들. 대부분의 템플릿, 이 검색어 상위 10개 결과 중 여럿을 포함해서, 정당한 비판이다.

우리의 답은 이렇다. 빈 내용으로 채우느니 섹션을 지워라. 사용자가 명확하면 페르소나를 먼저 쓴다. 부록은 두 번째로 미룬다. 마일스톤은 트래커에만 남겨도 된다. 우리가 절대 지우지 않는 섹션은 비목표다. 일을 하면 할수록 오히려 짧아지는 유일한 섹션이고, 6주 차에 벌어질 언쟁을 안정적으로 막아주는 유일한 섹션이기 때문이다.

저자 소개

Mert Batur Gurbuz, Techsy.io 공동 창업자. 자격: Techsy.io 공동 창업자, University of Birmingham. LinkedIn

Mert Batur Gurbuz는 Techsy.io의 공동 창업자로, 그의 팀은 B2B 클라이언트를 위해 AI 에이전트, 자동화 시스템, 음성/SDR 파이프라인을 만든다. University of Birmingham에서 공부하고 있으며, Techsy 팀이 실제 프로덕션에서 쓰는 LLM 툴링 스택에 대해 글을 쓴다.

자주 묻는 질문

제품 요구사항 문서란 무엇인가?

제품 요구사항 문서(PRD)는 팀이 무엇을 왜 만드는지 명시한 문서다. 문제, 목표와 그 지표, 비목표, 대상 사용자, 완료를 정의하는 요구사항이 담긴다. 구현 세부사항은 의도적으로 제외되며, 이는 나중에 엔지니어링이 작성하는 기술 설계 문서에 속한다.

제품 요구사항 문서는 어떻게 쓰는가?

문제 정의부터 시작하고, 여기에는 해결책 언어를 쓰지 않는다. 기준값과 목표 날짜가 있는 측정 가능한 목표를 추가한 뒤 비목표를 쓴다. 페르소나, Given/When/Then 인수 기준이 딸린 사용자 스토리, 기능·비기능 요구사항, 의존성, 마일스톤, 담당자가 지정된 미해결 질문을 채운다.

PRD에는 무엇이 들어가야 하는가?

12개 섹션이다. 변경 이력이 포함된 헤더, 문제 정의, 목표 및 성공 지표, 비목표, 사용자 및 페르소나, 인수 기준이 딸린 사용자 스토리, 기능 요구사항, 비기능 요구사항, 의존성 및 연동, 마일스톤 및 단계 구분, 미해결 질문 및 리스크, 부록. 이 중 어디에도 속하지 않는 내용은 대개 요구사항이 아니다.

PRD는 얼마나 길어야 하는가?

단일 기능이면 12페이지, 제품 단계 전체면 35페이지, 외부 팀이 빌드하고 인수 기준이 승인 게이트 역할을 하면 5~8페이지다. 분량은 제품의 크기가 아니라 기록되는 의사결정의 개수를 따라간다. 빈 섹션은 채우지 말고 지워라.

PRD와 BRD는 같은가?

아니다. 사업 요구사항 문서(BRD)는 보통 솔루션을 정하기 전에 조직이 원하는 상업적 결과와 그 제약을 명시한다. PRD는 그 결과를 전달하는 제품을 서술한다. 사용자, 동작, 인수 기준, 비목표다. 소규모 회사에서는 BRD가 문제 정의 섹션 하나로 끝나는 경우가 많다.

애자일 팀도 여전히 PRD를 쓰는가?

쓴다. 대개 원페이저 형태로. 백로그가 작업을 담지만, 티켓은 이유와 비목표, 성공 지표를 담는 데는 형편없다. PRD를 아예 건너뛴 팀은 스프린트 3회쯤 지나 "컨텍스트"라는 이름의 컨플루언스 페이지로 그걸 다시 만들어내곤 한다.

PRD를 마크다운으로 쓸 수 있는가?

마크다운이 가장 좋은 형식이다. Notion, Confluence, Google Docs, Linear에 그대로 붙여넣을 수 있고, PRD.md로 코드 옆에서 Git으로 버전 관리할 수 있으며, 풀 리퀘스트에서 제대로 diff가 되고, 구조를 잃지 않고 읽을 수 있는 유일한 형식이 AI 코딩 에이전트에게도 통한다. 위 템플릿이 마크다운인 이유가 바로 이것들이다.

AI 코딩 에이전트를 위한 PRD는 어떻게 쓰는가?

평소라면 간결하게 넘어갈 부분을 명시적으로 써야 한다. 비목표는 긍정문으로 적는다. 에이전트는 생략에서 범위를 유추하지 못하기 때문이다. 문서를 한 번에 끝낼 수 있는 단계로 쪼갠다. 인수 기준은 숫자가 들어간 검증 조건으로 쓴다. 에이전트가 수정해도 되는 파일과 건드리면 안 되는 파일의 이름을 명시한다.

PRD와 기술 설계 문서의 차이는 무엇인가?

PRD는 무엇을, 왜에 답한다. 문제, 사용자, 동작, 인수 기준, 비목표다. 기술 설계 문서는 어떻게에 답한다. 아키텍처, 데이터 모델, API 계약, 검토된 트레이드오프다. 보통 제품 조직이 전자를, 엔지니어링이 후자를 소유하며, 설계 문서는 PRD에 대한 응답으로 읽힐 수 있어야 한다.

PRD는 누가 소유하는가, 제품인가 엔지니어링인가 클라이언트인가?

제품이 문서와 그 안의 결정을 소유한다. 엔지니어링은 실현 가능성 피드백과 비기능 요구사항을 소유한다. 에이전시 빌드에서는 클라이언트가 문제 정의, 목표, 자사 사업에 관한 모든 미해결 질문을 소유한다. 문서 전체를 공동 소유로 두면 대개 아무도 관리하지 않게 된다.

마무리

세 가지만 기억하면 된다. 템플릿은 채워졌을 때만 쓸모가 있으므로, 빈 것보다 채워진 예시의 형태를 따라 하라. 비목표는 이 문서에서 단어당 가치가 가장 높은 섹션이면서 사람들이 가장 먼저 건너뛰는 섹션이다. 그리고 테스트 가능한 조건으로 쓴 인수 기준은 두 독자 모두에게 똑같이 유용하다. 인도를 승인하는 엔지니어와, 테스트를 작성하는 에이전트다.

외부 팀에 넘길 PRD를 계약이 되기 전에 한 번 더 검토받고 싶다면, 언제든 읽고 모호한 줄을 짚어드린다. 우리 자신의 웹 애플리케이션 빌드에서도 똑같이 거치는 과정이다.