제품 요구사항 문서 템플릿 (복사 가능한 완전한 작성 예시 포함)

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

대부분의 제품 요구사항 문서 템플릿 페이지는 빈 양식만 제공합니다. Atlassian의 것은 빈 성공 지표 표를 둘러싼 4개 섹션의 지침으로 이루어져 있습니다. Product School의 것은 제목에는 "(예시 포함)"이라고 명시되어 있지만 실제 예시는 없습니다. 아래의 12개 섹션 마크다운 블록이 전체 템플릿이며, 제약이 없고 복사하여 사용할 수 있습니다. 그 다음 4번 섹션에서 이 12개 섹션 모두를 채워 완전한 작성 예시를 제공합니다: LLM으로 PDF를 읽고 의심스러운 것들을 인간에게 라우팅하는 클라이언트 청구서 포털입니다. 빈 템플릿을 복사하고, 작성된 예시를 읽고, 당신의 것을 작성하세요.

핵심 내용

PRD는 무엇을 만들지, 왜 만들지를 답변합니다. 기술 설계 문서는 어떻게 만들지를 답변합니다.
12개 섹션은 모든 규모의 프로젝트에 맞습니다. 1페이지 버전은 행이 적은 같은 템플릿입니다.
제외 목표는 반드시 기록되어야 합니다. AI 코딩 에이전트는 생략된 내용에서 범위를 추론할 수 없습니다.
수락 기준은 기계적으로 검증 가능해야 합니다: "p95 400ms 이하", "빠르다"는 안 됩니다.

어떤 형태의 PRD를 사용해야 할까요?

문서의 크기가 아니라 누가 문서를 읽을지에 따라 형태를 선택하세요. 자신의 엔지니어에게 가는 단일 기능은 1페이지 버전이 필요합니다. 외부 팀에 인수되는 빌드는 전체 12개 섹션 PRD가 필요합니다. 수락 기준이 승인 관문으로도 작용하기 때문입니다. AI 코딩 에이전트에 가는 스펙은 페이즈로 분할된 같은 12개 섹션이 필요합니다.

모두가 원하는 1페이지 제품 요구사항 문서 템플릿은 별도의 산출물이 아닙니다. Lenny Rachitsky의 널리 복사되는 1페이저는 그의 뉴스레터에 실제 예시와 함께 출판되었으며, 의식적 부분을 제거한 같은 골격입니다. 1페이져는 다른 문서가 아닙니다. 빈 행을 삭제한 같은 12개 섹션입니다.

애자일 팀도 이 질문을 자주 합니다. 보통 "PRD가 백로그와의 만남에서 살아남는가"로 표현됩니다. 살아남습니다, 1페이져로: PRD는 왜와 경계를 담고, 티켓은 작업을 담습니다.

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

여기 전체 내용을 마크다운으로 제공합니다, 제약 없이, 이메일 벽 없이. Notion, Confluence, Google Docs, Linear, Word에 붙여넣거나, 또는 GitHub에 PRD.md로 커밋하고 코드와 함께 버전 관리하세요. 사람들은 이 템플릿을 9가지 다른 형식으로 요청합니다. 마크다운은 모두에 붙여넣어도 살아남는 형식이며, AI 코딩 에이전트가 깔끔하게 읽을 수 있는 유일한 형식입니다.

12개 섹션의 순서: 헤더, 문제 진술, 목표 및 성공 지표, 제외 목표, 사용자 및 페르소나, 수락 기준이 포함된 사용자 스토리, 기능 요구사항, 비기능 요구사항, 의존성 및 통합, 마일스톤 및 페이징, 미해결 질문 및 위험, 부록.

PRD에 포함되어야 할 것은? 12개 섹션 및 각각의 약한 버전

제품 요구사항 문서에는 문제 진술, 측정 가능한 목표, 명시적 제외 목표, 페르소나, 수락 기준이 포함된 사용자 스토리, 기능 및 비기능 요구사항, 의존성, 마일스톤, 담당자가 있는 미해결 질문, 그리고 변경 이력이 포함되어야 합니다. 다른 모든 것은 부록입니다. 각 라인의 테스트는 ISO/IEC/IEEE 29148:2018이 일반적으로 요구사항에 적용하는 것입니다: 검증 가능성, 명확성, 단일성.

대부분의 PRD는 같은 세 곳에서 이 테스트를 실패합니다.

두 섹션은 보통 받는 것보다 더 많은 관심을 받아야 합니다.

비기능 요구사항은 범위가 조용히 두 배가 되는 곳입니다. 성능, 테넌시, 데이터 거주지, 보존, 접근성, 가용성: 이들 각각은 비용이 드는 엔지니어링 결정이며, 사용자 스토리에는 그 중 어느 것도 나타나지 않습니다. 보안 라인을 손 흔드는 것보다는 여기 넣고, 우리의 출시 전 보안 체크리스트 같은 것을 소스 리스트로 사용하여 검증하고 싶은 방식으로 작성하세요. 빌드에 AI 구성요소가 있다면, 프로덕션 준비 요구사항도 여기 속하고, 절대 예약되지 않는 나중의 "강화" 페이즈에 있으면 안 됩니다: 우리의 PoC-to-프로덕션 체크리스트가 우리가 사용하는 버전입니다.

미해결 질문은 세 개 칼럼이 필요합니다, 하나가 아니라. 질문, 담당자, 필요 기한. 담당자 없는 질문은 아무도 하지 않는 결정이며, 6주 차에 변경 요청으로 나타날 것입니다. 말할 가치가 있는 것: PRD는 구매가 아니라 구축하기로 결정한 후에 작성하는 것입니다. 문제 진술이 여전히 기능의 쇼핑 리스트처럼 읽힌다면, 구매 대 구축 결정이 실제로 일어나지 않은 것입니다.

작성된 예시: 청구서 포털 PRD, 작성 완료

여기 완전한 작성 예시가 있습니다, 12개 섹션 모두 작성됨. 빌드: 중소 규모 물류 운영자를 위한 클라이언트 청구서 포털. 고객이 PDF 청구서를 업로드하고, LLM이 라인 항목을 추출하고, 시스템이 주문 기록과의 불일치를 표시하고, 확실하지 않은 모든 것은 인간 검토 큐로 이동합니다. 스택: Next.js, Supabase/Postgres, 하나의 LLM 추출 단계. 복사하고, 인쇄하고, PDF로 내보내고, 필요한 것을 하세요.

거기에 있는 네 가지 선택은 주목할 가치가 있습니다. 각각의 게으른 버전이 실제 비용이 들기 때문입니다.

3번 섹션, 기준선. "6분"은 장식이 아닙니다. 기준선이 없으면 작동했는지 알 수 없으며, 6개월 후 누군가 데이터 없이 회의에서 그것에 대해 논쟁할 것입니다. 게으른 버전인 "효율성 개선"은 프로젝트를 반증 불가능하게 만듭니다.

4번 섹션, 제외 목표. ERP 역쓰기가 검토 통화 중에 존재한다고 가정된 후 2026-07-28에 제외 목표로 이동했습니다. 제외 목표로 작성하는 것은 한 줄이 드는 비용이고 범위 논쟁을 절약했습니다.

6.2번 섹션, 신뢰 임계값. 이것은 우리 첫 번째 초안이 가장 자주 놓치는 규칙입니다. 생략하면 시스템이 인간이 봐야 할 청구서를 자동 승인하며, 이것은 3번 섹션에서 약속한 시간 절약을 지우는 정확한 실패입니다.

11번 섹션, 담당자들. 모든 미해결 질문에는 이름과 날짜가 있습니다. 그 칼럼이 문서와 아무도 소유하지 않는 할일 목록의 차이입니다.

PRD는 무엇을 말합니다. 얼마나 오래 걸리거나 얼마나 드는지는 말하지 않으며, 이것은 별도의 연습입니다: 그 부분을 위해 빌드 범위 설정을 보세요. 그리고 작성하지 않은 제외 목표는 누군가 구축할 기능입니다.

AI 코딩 에이전트가 실제로 구축할 수 있는 PRD를 어떻게 작성할까요?

AI 코딩 에이전트를 위해 작성된 PRD는 간결함을 명시성과 바꿉니다. 에이전트는 복도 맥락이 없고, 공유된 역사가 없으며, 당신이 명백히 의도하지 않은 것이 무엇인지에 대한 본능이 없습니다. 네 가지 규칙이 대부분의 차이를 다루며, 우리 자신의 에이전트 보조 빌드에서 스펙이 성공하고 실패하는 것을 지켜보면서 나온 것입니다.

제외 목표를 긍정적으로 표현하세요. 인간은 생략에서 범위를 추론합니다. 에이전트는 하지 않습니다. "이 페이즈에서 인증을 추가하지 마세요"는 문서의 문장이어야 하며, 그렇지 않으면 인증이 구축되고, 테스트되고, 당신에게 반환됩니다.
작업의 페이즈 크기를 정하세요. 하나의 40페이지 거대 문서는 자신감 있고, 널리 퍼진, 반 정도만 맞는 풀 리퀘스트를 만듭니다. PRD를 에이전트가 하나의 제한된 실행으로 완료하는 패스로 분할하고, 각각은 자체 종료 기준이 있습니다.
수락 기준을 기계적으로 검증 가능하게 만드세요. "빠르다"는 요구사항이 아니라 분위기입니다. "청구서 목록 엔드포인트의 p95 400ms 이하"는 에이전트가 기능을 작성하기 전에 작성할 수 있는 테스트입니다.
파일 경로와 스택 제약을 문서에 넣으세요, 채팅에 아니라. 채팅 맥락은 세션 간에 사라집니다. 스펙은 그렇지 않습니다. 이것도 Claude Code의 계획 모드가 중요한 이유입니다: 파일을 읽고 당신이 승인할 때까지 아무것도 편집하지 않고 계획을 제안하며, 그 승인 단계는 당신이 요청한 것의 메모리 대신 작성된 스펙에 대해 계획이 검증될 때 훨씬 더 유용합니다.

여기 청구서 포털이 있습니다, 에이전트가 한 번의 패스로 실행할 수 있는 하나의 페이즈로 분할됨.

...

출처 바로가기