무료 템플릿

무료 PRD 템플릿, 검증할 수 있게

팀이 그대로 개발에 쓰고, 감사하는 사람이 그대로 대조할 수 있는 제품 요구사항 문서입니다. 문제, 사용자, 범위, 인수 기준이 붙은 번호 매긴 요구사항, 그리고 하지 않기로 한 것까지. Markdown으로 복사하거나 내려받으세요.

무료 · Markdown · 가입 불필요

언제 쓰나요

PRD는 누군가 에디터를 열기 전에 쓰고, 끝까지 읽힐 만큼 짧게 유지하세요. 이후의 모든 작업이 다시 돌아와 확인하는 문서입니다.

  • 새 제품이나 큰 기능의 첫 코드를 쓰기 전에

  • 외주 개발자, 스튜디오, 코딩 에이전트에게 개발을 맡길 때

  • 첫 릴리스에 무엇을 넣을지 의견이 갈릴 때

  • 감사 전에. 대조할 합의된 기준이 있어야 합니다

템플릿

템플릿 전문

아래 내용은 복사하거나 내려받을 때 모두 포함됩니다. [대괄호] 빈칸을 바꾸고, 안내 문장은 쓰면서 지우세요.

제품 요구사항: [제품명]

[대괄호] 안의 내용을 모두 바꾸고, 섹션을 다 쓰면 안내 문장은 지우세요. 팀 밖의 누군가가 이 문서만으로 첫 릴리스를 만들 수 있고, 또 다른 사람이 그것을 검증할 수 있으면 완성입니다.

01개요

두세 줄로. 무엇을, 누구를 위해 만드는지 이만큼 짧게 말할 수 없다면 나머지 문서로도 해결되지 않습니다.

  • 제품: [이름]
  • 책임자: [범위 문제를 결정하는 사람]
  • 상태: [초안 / 검토 중 / 합의됨]
  • 최종 수정: [날짜]
  • 한 줄 요약: [무엇인지, 누구를 위한 것인지, 무엇을 대체하는지]

02문제

빠진 기능이 아니라 사용자가 실제로 겪는 문제로 쓰세요. 지금은 대신 무엇을 하는지, 그걸 어떻게 아는지도 함께 적습니다.

현재 [누가] [무엇을 해야] 할 때 [어떤 임시방편]을 쓴다. 그 결과 [실제로 관찰한 시간, 비용, 위험]이 생긴다.

근거: [인터뷰, 고객 문의, 영업 통화, 직접 사용. 어떤 것을 몇 건인지 적기.]

03대상 사용자

주요 사용자는 한 명으로 좁힙니다. 해결책을 찾기 시작하는 계기와, 대상이 아닌 사람도 적으세요.

  • 주요 사용자: [역할, 회사 규모, 상황]
  • 계기: [새로운 방법을 찾게 만드는 사건]
  • 현재 대안: [스프레드시트, 다른 도구, 사람, 아무것도 안 함]
  • 대상 아님: [일부러 대상으로 삼지 않는 사람과 그 이유]

04해야 할 일 (Jobs to be done)

사용자가 이루려는 일을 사용자의 말로. 세 개에서 다섯 개, 중요한 순서대로.

  • 일 1: [상황]일 때 [행동]하고 싶다. 그래야 [결과]를 얻을 수 있다.
  • 일 2: [상황]일 때 [행동]하고 싶다. 그래야 [결과]를 얻을 수 있다.
  • 일 3: [상황]일 때 [행동]하고 싶다. 그래야 [결과]를 얻을 수 있다.

05MVP 범위

첫 릴리스가 하는 일. 각 줄은 사람이 실제로 동작하는 모습을 볼 수 있는 것이어야 합니다.

  • [이것 없이는 출시할 수 없는 첫 번째 기능]
  • [두 번째 기능]
  • [세 번째 기능]

06요구사항

한 행에 검증 가능한 문장 하나. 인수 기준은 운영 중인 제품에서 어떻게 확인하는지를 적습니다. 인수 기준이 없는 요구사항은 감사할 수 없습니다. 우선순위는 MoSCoW(Must, Should, Could, Won't), 유형은 기능(동작), 비기능(속도, 가용성, 접근성), 제약(규제, 플랫폼, 예산) 중 하나입니다.

키는 영구적입니다. 번호를 다시 매기거나 재사용하지 마세요. 작업, 커밋, 감사가 이 키를 참조합니다.

키요구사항인수 기준우선순위유형
REQ-001사용자는 [눈에 보이는 동작]을 할 수 있다[운영 중인 시스템에서 동작을 보여 주는 절차]Must기능
REQ-002[페이지나 동작]이 [부하]에서 [시간] 안에 응답한다[어디서 어떻게 측정하는지]Should비기능
REQ-003[규제, 플랫폼, 예산 한도][지켜지고 있다는 증거]Must제약
REQ-004[언급했지만 미루는 것][나중에 어떻게 확인할지]Won't기능

07성공 지표

릴리스가 효과가 있었는지 어떻게 알지. 지표, 측정 위치, 목표를 적습니다. 목표를 지어내느니 비워 두세요.

  • 핵심 지표: [무엇]을 [도구]에서 측정, 목표 [값, 또는 기준선 측정 후 설정]
  • 보조 지표: [무엇]을 [도구]에서 측정, 목표 [값]
  • 가드레일: [나빠지면 안 되는 수치. 오류율, 환불 등]

08비목표

이번 릴리스에서 일부러 하지 않는 것. 가장 많은 논쟁을 막아 주는 섹션입니다.

  • [다들 포함됐다고 생각할 만한 것과, 포함하지 않는 이유]
  • [두 번째 비목표]

09미결 사항

아직 정하지 못한 모든 것에 담당자와 기한을 붙이세요. 담당자 없는 질문은 계속 열려 있습니다.

  • [질문] (담당: [이름], 기한: [날짜])
  • [질문] (담당: [이름], 기한: [날짜])

10승인

이 버전에 합의한 사람. 이후의 범위 변경은 제안하고 기록하는 것이지, 슬쩍 끼워 넣는 것이 아닙니다.

  • 승인자: [이름]
  • 승인일: [날짜]
  • 범위 변경 방법: [변경을 제안하는 방법과 기록 위치]

Atrix AI

Atrix AI로 하면

Develop 모드가 프로젝트의 브리프, 아이디어, 페이지를 바탕으로 이 문서를 쓰고, 첫 초안 이후에도 쓸모 있게 유지합니다.

  • 요구사항 초안 작성

    에이전트가 워크스페이스에 PRD를 씁니다. 문제, 대상 사용자, 해야 할 일, MVP 범위, 성공 지표, 비목표까지. 한 번 실행하면 사본을 늘리지 않고 같은 문서를 갱신합니다.

  • 검증 가능한 행으로 변환

    Atrix가 문서 속 약속을 하나씩 키, 인수 기준, MoSCoW 우선순위가 붙은 요구사항으로 추출하고 원문 문장을 인용합니다. 승인하기 전까지는 모두 '제안' 상태입니다.

  • 계획하고 넘기기

    승인된 요구사항은 보드의 이슈로 나뉘고, 인계 번들이 문서와 키를 코딩 에이전트에게 전달합니다. 그래서 나중에 작업을 감사할 수 있습니다.

FAQ

자주 묻는 질문

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

문제와 그 문제를 겪는 사람, 사용자가 이루려는 일, 첫 릴리스의 범위, 확인 방법이 붙은 번호 매긴 요구사항, 성공 지표, 비목표, 미결 사항, 그리고 승인자입니다. 이 템플릿에는 각각의 섹션이 있습니다.

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

당신에게 묻지 않고도 첫 릴리스를 만들 수 있는 선에서 최대한 짧게. 대부분 2~5페이지면 충분합니다. 길어지는 이유는 보통 해결책 설명이니, 문제와 검증 가능한 요구사항에 집중하세요.

왜 모든 요구사항에 인수 기준이 필요한가요?

그게 없으면 요구사항을 충족했는지 아무도 판단할 수 없기 때문입니다. 인수 기준은 운영 중인 제품에서 확인하는 방법을 적은 것으로, 문서를 감사로 검증할 수 있는 대상으로 바꿔 줍니다.

Notion, Google Docs, GitHub에서도 쓸 수 있나요?

네. 일반 Markdown이라 Markdown을 지원하는 편집기에 그대로 붙여 넣을 수 있고, 저장소 안에서 코드 옆 파일로 읽기에도 좋습니다.

템플릿은 무료인가요?

네. 가입 없이 복사하거나 내려받을 수 있습니다. Atrix AI는 선택 사항으로, 문서 작성과 갱신을 맡기고 싶을 때 쓰면 됩니다.

회사 전체를 한곳에서 운영하세요.

무료 플랜으로 시작하세요. 준비가 되면 팀, 캘린더, 코드를 연결하면 됩니다.