AI PRD 템플릿: 각 섹션과 섹션별 프롬프트, 그리고 완성된 작성 예시

템플릿이 해내야 하는 일

제품 요구사항 문서의 독자는 둘입니다. 만드는 쪽은 동료든 외주든 코딩 에이전트든 무엇을 만들고 어디서 멈출지 알아야 합니다. 검토하는 쪽은 출시된 것이 합의한 것과 같은지 확인해야 합니다. 모든 요구사항이 검증 가능한 한 문장이고 모든 비목표가 적혀 있을 때 템플릿은 둘 모두에게 쓸모가 있습니다.

각 섹션은 서로 다른 종류의 질문에 답하도록 골랐습니다.

전체를 두 쪽 이내로 유지하세요. 아무도 읽지 않는 PRD는 없는 PRD와 같습니다.

Markdown PRD 템플릿

이 블록을 페이지, 저장소의 파일, 혹은 편집기에 복사하세요. 대괄호 안은 모두 바꾸고, 섹션을 다 쓰면 안내 줄은 지웁니다.

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

책임자: [이름]
상태: [초안 / 검토 중 / 합의됨]
최종 수정: [YYYY-MM-DD]
요약: [한 문장: 무엇인지, 누구를 위한 것인지, 무엇을 대체하는지]

**1. 문제**
현재 [누구]는 [무언가를 해내야] 할 때 [어떤 우회 방법]을 쓴다.
그로 인해 [실제로 관찰한 시간, 비용 또는 리스크]가 든다.
근거: [인터뷰, 지원 티켓, 영업 통화, 직접 사용 경험. 몇 건인지 적을 것]

**2. 목표**
G1. [지표]를 [현재 값]에서 [목표 값]으로, [날짜]까지.
G2. [지표]를 [현재 값]에서 [목표 값]으로, [날짜]까지.
측정 방법: [대시보드, 쿼리 또는 보고서]

**3. 사용자 스토리**
US-1. [역할]로서, [상황]일 때, [행동]하고 싶다. [결과]를 얻기 위해.
US-2. [역할]로서, [상황]일 때, [행동]하고 싶다. [결과]를 얻기 위해.
US-3. [역할]로서, [상황]일 때, [행동]하고 싶다. [결과]를 얻기 위해.

**4. 인수 기준**
각 스토리마다 리뷰어가 통과/실패를 판정할 수 있는 검사 하나 이상.
AC-1a. [상태]에서, [행동]하면, [관찰 가능한 결과]가 된다.
AC-1b. [상태]에서, [행동]하면, [관찰 가능한 결과]가 된다.
AC-2a. [상태]에서, [행동]하면, [관찰 가능한 결과]가 된다.
우선순위: 각 스토리에 [Must / Should / Could].

**5. 비목표**
이번 릴리스에서는 [것]을 하지 않는다. 이유는 [이유].
이번 릴리스에서는 [것]을 하지 않는다. 이유는 [이유].

**6. 리스크와 미해결 질문**
R1. [리스크]. 가능성 [낮음/중간/높음]. 발생 시: [대응].
R2. [리스크]. 가능성 [낮음/중간/높음]. 발생 시: [대응].
미해결: [착수 전에 답해야 할 질문과, 누가 답하는지]

무게의 대부분을 두 가지 관례가 떠받칩니다. 모든 스토리와 기준에 안정된 키(US-1, AC-1a)가 있어 커밋 메시지, 이슈, 감사가 그것을 가리킬 수 있다는 것. 그리고 모든 기준이 "~에서, ~하면, ~된다" 형식으로 쓰여 코드가 되기 전에 이미 테스트라는 것입니다.

섹션별 프롬프트

"PRD 써 줘"라는 한 번의 프롬프트는 근거를 지어내고 목표가 뻔한, 자신감만 넘치는 문서를 만듭니다. 실제로 가진 사실을 붙여 섹션 하나씩 요청하면 모델이 꾸며낼 여지가 줄어듭니다. 아래는 우리가 쓰는 프롬프트입니다. 대괄호 부분은 보내기 전에 채우세요.

1. 문제. "고객 대화 [N]건과 지원 티켓 [N]건의 메모입니다: [붙여넣기]. 문제 섹션을 120단어 이내로, '현재 [누구]는 [작업]이 필요할 때 [우회 방법]을 쓴다. 그로 인해 [비용]이 든다' 형식으로 쓰세요. 메모에 나오는 비용만 쓰세요. 마지막에 출처 수를 센 근거 줄을 붙이세요."
2. 목표. "문제는 다음과 같습니다: [붙여넣기]. 현재 수치는: [지표, 값]. 'G#. [지표]를 [현재 값]에서 [목표 값]으로, [날짜]까지' 형식으로 목표 세 개를 제안하세요. 현재 값을 지어내지 마세요. 내가 주지 않은 값이 필요하면 TBD라고 쓰세요."
3. 사용자 스토리. "문제와 목표: [붙여넣기]. '[역할]로서, [상황]일 때, [행동]하고 싶다. [결과]를 얻기 위해' 형식으로 사용자 스토리를 최대 다섯 개 쓰세요. 스토리당 역할은 하나. G1에 얼마나 직접 기여하는지 순으로 정렬하세요."
4. 인수 기준. "아래 각 스토리에 대해 '[상태]에서, [행동]하면, [관찰 가능한 결과]가 된다' 형식으로 인수 기준을 두세 개 쓰세요. 각각 코드를 볼 수 없는 사람이 확인할 수 있어야 합니다. 검증 가능한 기준을 쓸 수 없는 스토리가 있으면 표시하세요." 약한 스토리가 드러나는 단계입니다. 모델이 테스트를 못 쓰면 당신도 못 씁니다.
5. 비목표. "이 스토리들을 바탕으로, 합리적인 엔지니어라면 포함됐다고 생각할 법하지만 실제로는 아닌 것 여섯 가지를 나열하세요. 각각 '이번 릴리스에서는 [것]을 하지 않는다. 이유는 [이유]' 형식으로 쓰세요." 그런 다음 팀이 실제로 손댈 법한 것만 남기고 줄이세요.
6. 리스크. "이 기능이 출시 후 실패할 가장 가능성 높은 경로 네 가지를 기술적이든 사업적이든 나열하세요. 각각 가능성과 우리가 취할 대응을 적으세요. 추측한 부분은 표시하세요."

한 섹션을 요청하고, 읽고, 고치고, 고친 버전을 다음 프롬프트에 붙입니다. 고쳐진 섹션의 연쇄가 진짜 안전장치입니다. 모델은 당신이 이미 승인한 것만 봅니다.

작성 예시: 두 명짜리 컨설팅 회사의 예약 링크

작고 현실적인 모양의 기능에 템플릿을 채운 예입니다. 수치는 예시용입니다.

PRD: 공개 예약 링크

책임자: Dana
상태: 합의됨
최종 수정: 2026-10-28
요약: 잠재 고객이 우리 공유 캘린더에서 30분 슬롯을 고르는 공개 페이지.
지금 하고 있는 이메일 핑퐁을 대체한다.

**1. 문제**
현재 통화를 원하는 잠재 고객은 이메일을 보내고, 시간을 정하기까지
평균 네 통을 주고받는다. 지난 분기 22건의 통화에서 창업자 시간이
약 세 시간 들었고, 두 명의 잠재 고객은 시간이 정해지기 전에
연락이 끊겼다.
근거: 최근 90일 보낸 메일 검색. 22개 스레드 집계.

**2. 목표**
G1. 예약된 통화당 주고받은 메시지 수를 4에서 1로, 12월 15일까지.
G2. 월간 예약 통화 수를 7에서 10으로, 1월 31일까지.
측정 방법: 공유 받은편지함에서 "일정" 태그가 붙은 스레드 수.
워크스페이스의 예약 테이블.

**3. 사용자 스토리**
US-1. 잠재 고객으로서, 링크를 열었을 때, 내 시간대로 슬롯을 보고
싶다. 실수로 새벽 3시에 예약하지 않기 위해.
US-2. 창업자로서, 슬롯이 예약되면, 잠재 고객 정보와 함께 내
캘린더에 들어오길 원한다. 기억에 의존해 준비하지 않기 위해.
US-3. 창업자로서, 휴가 중일 때, 슬롯이 전혀 제공되지 않길 원한다.
내가 없는 주에 아무도 예약하지 못하게 하기 위해.

**4. 인수 기준**
AC-1a. UTC+9 방문자가 페이지를 열면, 시간이 UTC+9로 표시되고
시간대 이름이 보인다.
AC-1b. 이미 예약된 슬롯이 있는 상태에서 페이지를 열면, 그 슬롯은
제공되지 않는다.
AC-2a. 예약이 완료된 상태에서 캘린더를 열면, 잠재 고객의 이름,
이메일, 메모가 담긴 일정이 60초 이내에 존재한다.
AC-3a. 승인된 휴가 신청이 있는 날에 페이지를 열면, 그날의 슬롯은
제공되지 않는다.
우선순위: US-1 Must, US-2 Must, US-3 Should.

**5. 비목표**
예약 시 결제는 하지 않는다. 첫 통화는 무료이기 때문이다.
그룹 이벤트는 하지 않는다. 요청받은 적이 한 번도 없기 때문이다.
브랜드 커스터마이징은 하지 않는다. 우리 둘이 곧 브랜드이기 때문이다.

**6. 리스크와 미해결 질문**
R1. 캘린더 동기화 지연으로 인한 이중 예약. 가능성 중간. 발생 시:
일정 변경 링크가 담긴 확인 메일을 보내고 매일 점검한다.
R2. 스팸 예약. 가능성 낮음. 발생 시: 슬롯을 잡기 전에 이메일
확인을 요구한다.
미해결: 15분 슬롯도 제공할 것인가? Dana가 금요일까지 결정한다.

예시에 없는 것을 보세요. "즐거운 경험"도, 아키텍처도, 스크린샷도 없습니다. AC-3a는 리뷰어가 2분 안에 실행할 수 있는 테스트입니다. 비목표는 외주 개발자가 가장 물어볼 법한 세 가지입니다.

어디에 보관하고, 다음에 무엇을 할까

채팅창 안의 PRD는 탭을 닫는 순간 사라집니다. "초안"과 "합의됨" 사이에 무엇이 바뀌었는지 볼 수 있는 버전 이력이 있는 자리와, 스토리를 작업으로 바꾸는 방법이 필요합니다.

Atrix에서 PRD 템플릿은 위 Markdown과 같은 섹션을 가진 호스팅 페이지이며, 각 행에 키, 검증 가능한 한 문장, 인수 조건, MoSCoW 우선순위가 있는 요구사항 테이블이 더해져 있습니다. 에이전트의 Develop 실행은 반대 방향으로도 작동합니다. 짧은 브리프를 주면 "요구사항 초안 작성" 단계가 문제, 대상 사용자, 범위, 번호 매긴 요구사항, 비목표를 페이지에 쓰고, 다음 단계들이 아키텍처와 계획된 이슈를 제안해 백로그에 받아들일 수 있습니다. 한계도 알아 두세요. 실행 한 번에 플랜의 월간 실행 횟수(Builder 100회, Studio 500회) 하나를 쓰고, 무료 플랜은 없으며, 에이전트는 브리프를 바탕으로 쓰기 때문에 얇은 브리프에서는 얇은 PRD가 나옵니다. AI 에이전트 페이지에 각 실행이 만들어내는 것이 정리되어 있습니다.

PRD를 사람이 아닌 코딩 에이전트에게 읽히고 싶다면, 자매 글인 Claude Code나 Cursor가 구현할 수 있는 PRD 쓰는 법에서 추가 제약을 다룹니다.

템플릿이 막도록 설계된 흔한 실수

• 현재 값이 없는 목표. "전환율 높이기"는 바람입니다. "3월까지 2.1%에서 3%로"가 목표입니다. 현재 값을 모르면 TBD라고 쓰고 착수 전에 찾으세요.
• 기능을 가장한 스토리. "사용자로서 대시보드를 원한다"에는 상황도 결과도 없습니다. 무엇을 해내려는지 물으세요.
• 코드를 봐야 확인되는 기준. "API가 200을 반환한다"는 구현 세부사항입니다. "예약이 완료된 상태에서 캘린더를 열면 일정이 존재한다"가 사용자가 보는 것입니다.
• 비어 있는 비목표. 이 섹션이 비어 있으면 범위가 정해지지 않은 것입니다. 만드는 사람이 정하게 됩니다.
• 기술 리스크만 나열한 리스크 섹션. "아무도 쓰지 않는다"가 가장 흔한 실패이고, 목록에 올라야 합니다.

FAQ

AI PRD 템플릿이란 무엇인가요?

당신이 제공한 사실로 AI 어시스턴트가 각 섹션의 초안을 쓸 수 있고, 리뷰어가 그 결과를 검토할 수 있도록 쓰인 제품 요구사항 문서 템플릿입니다. 위 템플릿은 문제, 목표, 사용자 스토리, 인수 기준, 비목표, 리스크의 여섯 섹션으로 되어 있고 각각 프롬프트가 붙어 있습니다.

AI 제품용 PRD는 일반 PRD와 다른가요?

섹션은 같습니다. 달라지는 것은 인수 기준입니다. AI 기능에는 모델이 틀리거나, 느리거나, 사용할 수 없을 때의 기준과 "정상 동작한다" 대신 명시된 정확도 기준치가 필요합니다. 첫 릴리스에서 다루지 않을 동작은 비목표에 추가하세요.

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

기능이면 두 쪽 이내, 새 제품이면 서너 쪽입니다. 어떤 섹션이 그보다 길어진다면 대개 설계 문서나 백로그가 PRD 안에 숨어 있는 것입니다. 밖으로 빼고 링크하세요.

그냥 ChatGPT나 Claude에게 PRD 전체를 쓰라고 하면 안 되나요?

할 수 있고, 결과는 읽기 좋을 것입니다. 바로 그것이 문제입니다. 한 번의 프롬프트로 쓴 PRD는 근거도 현재 값도 없기 때문에 지어냅니다. 자기 숫자를 붙여 섹션 하나씩 요청하고, 다음으로 넘어가기 전에 각각을 고치면 문서는 정직하게 유지됩니다.

GitHub Spec Kit과는 무엇이 다른가요?

Spec Kit은 에이전트 채팅의 명령으로 명세를 계획, 작업, 코드로 바꿔 가는 코딩 에이전트용 툴킷입니다. 이 템플릿은 명세 그 자체이며, 그 과정이 시작되기 전에 사람이 합의하기 위해 쓰인 것입니다. 둘은 맞물립니다. PRD를 쓰고, 그것을 specify 단계에 넘기세요.

PRD가 합의된 뒤 인수 기준은 어디로 가나요?

각각이 이슈의 완료 정의가 됩니다. Atrix에서는 PRD 페이지의 요구사항 테이블이 나중에 요구사항 감사가 대조하는 대상입니다. 감사는 계획된 내용을 고정된 기준선과 비교하는 것이지 소스 코드를 보는 것이 아닙니다. 용어집의 PRD 항목에서 용어를 설명합니다.

다음 단계

위 Markdown을 복사하거나, 호스팅된 PRD 템플릿을 열어 팀과 함께 채우세요. 브리프에서 시작하고 싶다면 7일 체험 기간 동안 Atrix 에이전트가 첫 번째 버전을 페이지에 초안으로 써 줍니다.

출처

ChatPRD 요금과 GitHub Spec Kit. 모두 2026년 10월에 확인.