prd

PRD Writer Skill

PRD 의 역할 — 제품 맥락 집합

PRD 는 착수 전에 한 번 쓰고 버리는 기획서가 아니다. 이 버전에서 무엇을 왜 하기로 했고(결정), 어떻게 만들기로 했고(구현 설계 — 기각한 후보 포함), 실제로 어떻게 됐는가(결과) 를 한 곳에 남기는 제품 맥락 집합이다. 버전마다 쌓인 PRD 가 이후 LLM wiki 의 기본 토대가 된다 — 에이전트가 "왜 이렇게 돼 있지?"를 물었을 때 코드 대신 PRD 에서 답을 찾을 수 있어야 한다. 그래서 양식은 하나로 통일하고, 섹션 순서 · 번호 · ID 규칙을 고정한다(맥락 원칙 K1–K5).

양식은 하나다 — 제품 기능 · 내부 개발 · 콘텐츠 · 리포트 모두 같은 양식을 쓰고, 해당하지 않는 하위 절만 비운다. 저장소마다 다른 규칙(버전 체계 · 파일 위치 · 핫픽스 양식 · 배포 게이트)은 그 저장소의 architecture 문서가 정하고, 이 스킬은 그 규칙을 따른다.

양식 (섹션 순서 · 번호 고정)

# vX.Y.Z — <제목>
> **상태:** 초안 / 검토 / 진행 / frozen (YYYY-MM-DD, revN) · **완성도(R7):** NN/100
> **요구사항 유형(R6):** [개발] / [콘텐츠] / [리포트] — LLM·에이전트가 들어가면 "AI 제품" 표기 → §6 AI 부록
> **정본 · 선행:** 상위 PRD · 선행 PRD · 결정 문서 링크
> **대체:** (있을 때만) 이 PRD 가 대체한 문서 / 이 PRD 를 대체한 문서

## 1. 목표
- (R1) 상위 목표 인용 · 이 버전의 목표 · 이 버전이 그 안에서 맡는 조각 — 각 1줄
- 이 버전이 끝나면 무엇이 가능해지나 — 한 문장
- (제품 기능일 때) 배경(사용자 needs · JTBD · 기존 시도와 한계) · 대상(주 segment · 명시적 제외) ·
  가치 문장(누가 · 왜 · 어떻게 · 어떤 가치) · 가설과 가정(V/U/V/F 분류)

## 2. 결정 필요 항목
| ID | 항목 | 막는 것(섹션 · 작업) | 선택지 | 권장안 + 근거 | 결정 시점 | 상태 |
- 사람(오너 · 사용자 · Chief)이 정해야 착수할 수 있는 것을 맨 앞에 둔다. 없으면 "없음".
- 본문의 `[결정 필요: A vs B — 근거]` 인라인 표시(R3)는 모두 여기로 승격한다.
- 닫힌 항목은 지우지 않는다 — 상태를 ✅ 로 바꾸고 **결정 내용 · 결정자 · 일시**를 남긴다(K2).
- 기술 방식 선택(담당 에이전트가 정하는 것)은 여기가 아니라 §4 구현 결정으로 간다.

## 3. 범위
### 3.1 포함
| 영역 | 유형 | 내용 | 관련 결정 |
- 요구사항 1건 = 핵심 내용(무엇을 · 왜) + 작업 체크리스트(R5). 유형은 [개발] / [콘텐츠] / [리포트].
### 3.2 이번 버전 비포함 — 후속으로 미룬 것과 그 버전(R2)
### 3.3 영구 비범위 — 하지 않기로 한 것과 이유(있을 때만)
### 3.4 인수 조건
- `C1` … 기능 단위 Given-When-Then(R8). 테스트로 직역 가능해야 한다.
- "언제 완성인가"의 유일한 정의다. §6 검증은 이 조건을 어떻게 확인하는지를 적는다.

## 4. 구현 방법
R9 에 따라 **작업 담당 에이전트**가 도출한다. 하위 절은 해당될 때만 쓴다.
### 4.1 아키텍처 · 구조 — 층 · 구성요소 · 경계 · 의존 방향(다이어그램 보조, R4)
### 4.2 설계 — 모듈 · 인터페이스 · 상태 · 오류/재시도 · 동시성
### 4.3 데이터 — 스키마 · 저장 위치 · 수명/보존 · 마이그레이션 · 민감도
### 4.4 보안 · 권한 — 위협 · 권한 경계 · 비밀 관리 · 감사 기록
### 4.5 작업 분할 — 손댈 파일/모듈 · 작업 체크리스트(R5) · 담당 에이전트 · 마일스톤 · 의존 관계

각 절 안의 방식 선택은 **구현 결정** 단위로 기록한다:

#### I1. <무엇을 정하나>
| 후보 | 방식 | 장점 | 단점 · 비용 |
|---|---|---|---|
| ⓐ | … | … | … |
| ⓑ | … | … | … |
- **채택:** ⓐ
- **선택 근거:** 업계 관행 · 선례 · 측정값 · 제약(버전 목표 · 일정 · 기존 구조)과의 정합 — 근거 링크(K3)
- **기각 이유:** ⓑ — 왜 아닌가(후보마다 한 줄)
- **반증 조건:** 이것이 사실로 드러나면 이 결정을 다시 연다
- **부작용:** 이 채택이 다른 모듈 · 성능 · 호환성 · 운영에 주는 영향 → §5 에 `I1` 출처로 옮긴다

## 5. 리스크와 보완책
| ID | 리스크 | 출처 | 영향 | 가능성 | 보완책 | 보완 후 잔여 리스크 |
- 출처 = `외부`(시장 · 규제 · 제공사 · 사용자 행동) 또는 **구현 결정 ID**(`I1` …)(R10).
- 리스크만 나열하지 않는다 — 행마다 보완책과 남는 위험을 같이 쓴다.

## 6. 검증
- §3.4 인수 조건(`C1` …)마다 무엇으로 확인하나(자동 테스트 · 골든 · 실기 · 사람 리뷰) · 통과 게이트
- (제품 기능일 때) 성공 기준(공식 + 기간) · 선행 지표 · 후행 지표
- (R6 Yes) AI 부록 4칸

## 7. 결과
검증을 실행한 **뒤** 사실만 기입한다(착수 전에는 "미실행", K4).
- 실행한 검증과 결과(수치 · 통과/실패 · 실행 일시 · 커밋)
- 계획 대비 바뀐 것 — 바뀐 결정 · 구현 결정 ID 와 이유(원래 행은 남기고 "→ §7 참조")
- 남은 것(미충족 인수 조건 · 미검증 항목)과 넘긴 버전

## 8. 후속 문서 (선택)
- 이 버전으로 갱신이 필요한 다른 문서(로드맵 · INDEX · 상·하위 PRD · 정책)

맥락 원칙 (K1–K5) — LLM wiki 토대

#	원칙	규칙
K1	안정 ID	결정 필요 항목은 PRD 별 접두어 + 번호(예: W1), 인수 조건 C1…, 구현 결정 I1…, 리스크 K1…. 한 번 붙인 ID 는 바꾸거나 재사용하지 않는다. 다른 문서에서는 <버전>#<ID>(예: v2.1.0#I3)로 인용한다
K2	결정 보존	닫힌 결정 · 기각한 후보를 지우지 않는다. 번복은 새 행 또는 §7 결과에 쓰고 "이전 결정 X 를 대체"를 명시한다 — 이력이 곧 맥락이다
K3	근거 연결	채택 · 결정마다 근거를 링크한다(리포트 · ideation · 측정 · 외부 URL · 커밋 · 선행 PRD ID). 근거 없는 "그냥 이렇게"는 기록하지 않는다
K4	결과는 사실	§7 은 실행 후 관측한 사실만. 계획과 다르면 차이와 이유를 쓴다 — 다음 버전 PRD 가 이것을 인용해 출발한다
K5	고정 메타	상단 메타 블록의 키(상태 · 완성도 · 유형 · 정본·선행 · 대체)와 섹션 번호를 바꾸지 않는다 — 기계가 문서들을 가로질러 읽을 수 있게

용어는 정본 한 곳(용어집 · 결정 문서)에서 정의하고 PRD 는 링크한다. PRD 가 새 용어를 들이면 처음 쓰는 곳에서 정의한다.

요구사항 3대 유형

유형	산출물	예시
개발	코드	웹사이트, 제품(앱/기능), 내부 엔진
콘텐츠 제작	글·미디어	광고 소재 · 아티클(긴 글) · 포스트(짧은 글)
리포트 작성	문서	보고서(docs) · PPT(슬라이드)

• 한 PRD 에 복수 · 혼재 가능 — §3.1 포함 표의 "유형" 열로 구분한다.
• 디자인 = 내포, 독립 4번째 유형 아님. 요구사항이 디자인 요소(도표 · 인포그래픽 · UI · 이미지 · 영상 · 데이터 시각화 · PPT 레이아웃)를 포함하면 그 요구사항의 작업 체크리스트에 디자인 작업이 딸린다.
• 요구사항 1건(핵심 내용 + 작업 체크리스트)이 다운스트림 실행(스페셜리스트 dispatch)의 입력 단위다.

기획 워크플로 누적 기입

기획 워크플로(new-build / improvement)는 서브워크플로가 끝날 때마다 같은 양식의 해당 섹션에 누적 기입한다(별도 양식을 만들지 않는다).

서브워크플로 산출	기입 위치
아이디어 · 요구사항	§1 목표(배경) · §3.1 포함
시장(요약 + 리포트 evidence_ref)	§1 배경 · 대상
KPI · 데이터	§1 배경 · §6 성공 기준 · 지표
가설	§1 가설과 가정
문제정의 종착(problem-definition)	§1 ~ §3 확정
wbs	§4.5 작업 분할

작성 규칙 (R1–R10)

(A) R1–R5 = 맥락 · 오버스펙 축 — 세부 구현에 매몰돼 그 버전의 기획 의도를 해치지 않도록 경계와 상위 목표를 PRD 가 직접 들고 있게 한다. (B) R6–R8 = 확률성 · 검증 축 — AI 제품 PRD 는 결정론적 SW PRD 와 다른 종(種)이라는 외부 담론(ideation 260625-ai-planning-insights.md, 21개 소스)을 흡수한다. (C) R9–R10 = 의사결정 기록 축 — 구현 방법을 "정답 하나"가 아니라 후보 · 채택 · 근거 · 부작용의 기록으로 남겨 맥락 집합(K1–K5)을 채운다.

R1. 버전 계층 인지 (상위 목표 상속). 버전의 어느 자리가 바뀌었나로 그 PRD 가 정의할 범위가 달라진다.

바뀐 자리	그 PRD 가 정의	하위 PRD
X(major)	X.n.n 전체의 목표 · 개요(umbrella)	X.. 가 인용
Y(minor)	n.Y.n 전체의 목표 · 개요	n.Y.* 가 인용
Z(patch)	상위 목표를 인용만(재정의 금지) + 그 안에서 맡는 조각	—

• §1 목표에 상위 목표 인용 · 이 버전 목표 · 맡는 조각을 둔다. 상위가 미정의면 관측 · 합성하고 "synthesized" 로 표기한다.
• 버전 표기 · 핫픽스 처리 등 버전 체계 자체는 저장소의 architecture 문서를 따른다.

R2. §범위 = 포함 + 이번 버전 비포함 + 영구 비범위 + 인수 조건. "범위"와 "스코프"는 같은 말이다 — 섹션은 §3 범위 하나다. 이번 비포함(후속 버전 가능)과 영구 비범위(하지 않음)를 구분하고, 인수 조건도 범위 안(§3.4)에 둔다 — 무엇을 하는가와 언제 다 했는가는 같은 경계의 두 면이다.

R3. 지시 요구사항 전사 + 결정 표시. 사용자 · Chief 지시의 요구사항을 PRD 에 그대로 전사해 "요구사항 → 충족"을 추적한다. 사람이 정해야 할 지점은 [결정 필요: A vs B — 근거] 로 표시해 §2 로 승격하고, 기술 방식 선택이면 §4 구현 결정(R9)으로 기록한다. 임의 선택해 묻어두지 않는다.

R4. As-Is/To-Be = 개념 + 형태 이중 표현. 표 · 다이어그램(트리 · 플로우)으로 두 층을 모두 쓴다.

• 개념적 변화 — 역할 · 의미 · 책임의 이동.
• 형태(코드) 변화 — 경로 · 파일 · 시그니처 · 디렉토리 구조의 전후.

R5. 작업 체크리스트 = 리뷰 대상(초안, 확정 아님). §3.1 · §4.5 의 체크리스트 · 손댈 파일은 제안이다. requirements-analysis §리뷰 게이트에서 담당 스페셜리스트가 ① 실행 가능성 ② 오버스펙(버전 목표 대비 과대) ③ 누락 · 부작용을 검토해 가감 · 확정한다. 리뷰 전 체크리스트는 binding 아님.

R6. AI 제품 PRD 분기 (결정론/확률론 = 세 번째 축). 먼저 묻는다 — "이 제품에 LLM/에이전트가 들어가나?" No 면 §6 그대로. Yes 면 §6 에 AI 부록 4칸을 강제한다 — 같은 입력에 출력이 달라지므로 "단일 행동"이 아니라 "받아들일 만한 답변의 범위" 를 설계한다.

칸	정의	비고
① 허용 답변 범위	"무엇이 일어나야"가 아니라 "어떤 답이 받아들일 만한가"	범위로 정의
② Eval Plan	입력 · 기대 출력 · 실제 출력 · 합격 여부 셋 20~30 케이스로 시작(운영 시 누적). 프롬프트 수정마다 전체 재실행(회귀)	"프롬프트 수렁" 탈출 수단
③ 실패 정의 + 가드레일	무엇이 실패인가 + Always do / Ask first / Never do 3단 경계	자율성 · 통제 균형
④ 3단계 평가 피라미드	규칙 기반(자동 · 저렴) → LLM-as-Judge(빠르나 편향) → 사람(느리나 최종)	일상=①②, 중대 변경=③

근거: 외부 4소스(원티드랩 PO "정답 대신 시험지", "AI PRD는 무엇이 달라야", "PRD는 죽었다 Evals=Moat", "AI PM 2026 로드맵")가 "AI PRD = 허용 범위 + Eval" 로 수렴. 평가 기준 · 가드레일 · 데이터셋은 모델 교체 후에도 남는 고유 자산이다. 내부 개발 PRD 도 AI 기능이면 Yes.

R7. 완성도 단계 척도. HARD GATE 의 이진 충족과 별개로 성숙도를 메타 블록에 표기한다.

점수	도달 조건	의미
30	목표 · 대상 · 메인 시나리오	리뷰 시작 가능
50	+ 배경 · 맥락 · 중요 유즈케이스 · 결정 필요 항목	본격 검토
80	+ 구현 결정(후보 · 채택 · 근거) · 리스크 · 검증 계획	착수 가능
100	전 섹션 + HARD GATE + §7 결과	frozen(docs 스킬 판정)

R8. 인수 조건 = Given-When-Then. "AC" · "수용 기준" 대신 인수 조건이라고 쓴다. §3.4 에 C1… ID 를 붙여 Given-When-Then 으로 쓰고 테스트로 직역 가능하게 한다. 문서 위계 — PRD(무엇을 만드나) → 인수 조건(언제 완성인가) → Policy(어떤 기준으로 일관성).

C1  Given  사용자가 비회원 상태
    When   이메일로 가입 시도
    Then   인증 메일이 발송된다

R9. 구현 방법 = 담당 에이전트가 전문가 관점에서 후보를 비교해 채택. §4 는 PM 이 혼자 정하지 않는다. 각 작업을 맡을 에이전트가 자기 분야 최고 수준의 전문가라면 어떻게 하겠는가를 기준으로 후보를 내고, 그중 하나를 채택한 의사결정 과정을 구현 결정(I1…) 형식으로 남긴다. PM 은 통합 · 조정한다.

하위 절	주로 도출하는 담당	반드시 담을 것
4.1 아키텍처 · 구조	backend-engineer (설계 단계)	경계 · 의존 방향 · 확장/교체 지점 · 선례(업계 표준 · 레퍼런스 구현)
4.2 설계	해당 구현 담당(backend-engineer · frontend-engineer · infra …)	인터페이스 · 상태 · 오류/재시도 · 동시성 · 테스트 가능성
4.3 데이터	data-engineer (분석이면 data-analyst)	스키마 · 저장 위치 · 보존/삭제 · 마이그레이션 · 민감도
4.4 보안 · 권한	infra (보안)	위협 · 권한 경계 · 비밀 관리 · 감사 기록

• 구현 결정마다 후보 ≥2 · 채택안 · 선택 근거(근거 링크) · 후보별 기각 이유 · 반증 조건 · 부작용. 후보가 사실상 하나뿐이면 "검토한 대안 없음 — 이유"를 쓴다.
• 최고 전문가 관점은 "가장 정교한"이 아니라 "이 버전 목표에 가장 적합한" 이다 — 버전 목표를 넘는 설계는 R5 리뷰에서 오버스펙으로 깎는다.
• 담당이 정해지지 않은 작업은 §4.5 에서 담당을 먼저 배정한 뒤 도출한다.

R10. 리스크 = 외부 위험 + 채택안의 부작용. §5 는 바깥에서 오는 위험만이 아니라 §4 에서 채택한 방식이 만들어내는 부작용도 다룬다. 구현 결정(I#)마다 다음을 점검해 해당하면 그 ID 를 출처로 행을 만든다 — 다른 모듈 · 기존 사용자에 대한 영향 · 성능 · 비용 · 호환성/마이그레이션 · 운영 부담 · 보안 표면 · 되돌리기 어려움. 부작용이 없다고 판단한 결정도 §4 의 "부작용"에 "없음 — 이유"를 남긴다.

어휘 · 프레임 정렬

• Spec Kit 4게이트 — requirements-analysis 를 Specify → Plan → Tasks → Implement 어휘로 정렬.
• 가치 문장 4요소 — §1 가치 문장을 "누가 · 왜 · 어떻게 · 어떤 가치" 구조로.
• 산문 우선 — 텍스트 서술형 우선, 다이어그램은 보조(R4 형태 층).
• 지시의 저주 회피 — 한 프롬프트에 요구사항이 많을수록 준수율이 급락. 작업 체크리스트는 다운스트림 스페셜리스트에 1건씩 dispatch.

저장 위치

<repo>/docs/prd/<version>_<name>.md      ← PRD 본체 (repo 계층 · 릴리스 버전 1:1)
<org>/docs/reports/<name>_<YYMMDD>.md    ← 리포트 (org 계층 · evidence_ref 대상)
<org>/docs/ideation/<name>_<YYMMDD>.md   ← ideation (org 계층 · 발산)

분류 · 배치 · INDEX 는 docs 스킬, 저장소별 명명 · 버전 · 핫픽스 규칙은 그 저장소 architecture 문서.

HARD GATE: PRD ship 조건

• [ ] §1~§7 순서 · 번호 그대로, 메타 블록 키 고정(K5)
• [ ] §1 상위 목표 인용 · 이 버전 목표 · 맡는 조각(R1)
• [ ] §2 결정 필요 항목 — blocking 항목 모두 ✅ + 결정 내용 · 결정자 · 일시(K2)
• [ ] §3 포함 · 이번 비포함 · (영구 비범위) · 인수 조건 C# Given-When-Then(R2 · R8)
• [ ] 지시 요구사항 전사(R3) · As-Is/To-Be 개념+형태(R4) · 작업 체크리스트 리뷰 통과(R5)
• [ ] §4 구현 결정마다 후보 ≥2(또는 사유) · 채택 · 근거 링크 · 기각 이유 · 반증 조건 · 부작용(R9 · K3)
• [ ] §5 리스크마다 보완책 · 잔여 리스크, 채택안 부작용이 I# 출처로 반영(R10)
• [ ] §6 인수 조건마다 확인 수단 · (R6 Yes) AI 부록 4칸
• [ ] §7 결과는 검증 실행 후 사실로 기입(K4) · R7 완성도 표기

Anti-Sycophancy

PRD 본문에 다음 표현 금지:

• "검토 부탁드립니다 :)"
• "흥미로운 기능"
• "한번 생각해보시면 좋을"

대신:

• "권고: X. 반증 조건: Y."
• "결정 필요 항목: Z 의 trade-off (A vs B)"

Reference

• phuryn/pm-skills/pm-execution/create-prd (배경 · 대상 · 가치 · 지표 항목을 §1 · §6 에 흡수)
• gstack /office-hours design doc · Anti-Sycophancy · minimum approaches 2
• ADR(Architecture Decision Record) 관행 — 구현 결정의 후보 · 채택 · 근거 · 결과 기록