# AI 시대 PRD 템플릿 (LeanX 한국어 상세판)

> 프로토타입은 기능을 보여주지만, 왜 그것을 골랐는지와 성공 기준, 멈출 조건까지 보여주지는 못합니다. 이 문서는 그 셋을 남기는 결정 기록입니다.

- 만든 곳: LeanX (https://leanx.kr) · 버전 1.0 · 2026-10-27
- 해설 글: https://blog.leanx.kr/ai-era-prd-template
- 참고한 구조: Sachin Sharma가 2026-09-01 Product Career Academy에 공개한 "The 2026 AI-Era PRD Template"(© Product Career Academy)과, Aakash Gupta가 2026년 10월 LinkedIn에 공유한 같은 이름의 확장판. 8개 섹션의 뼈대를 참고했고, 문장과 예시는 LeanX가 새로 썼습니다. 원문의 번역본이 아닙니다.
- LeanX가 더한 항목은 `[LeanX 추가]`로 표시했습니다.
- 팀 안에서 자유롭게 복사·수정해 쓰셔도 됩니다. 출처를 남겨 주시면 고맙겠습니다.

---

## 쓰는 순서

1. 아이디어가 생기면 PRD부터 쓰지 말고, 접근 방식이 서로 다른 프로토타입을 여러 개 빠르게 만듭니다. (참고한 두 원문은 5개를 권합니다.)
2. 미리 정한 기준과 같은 입력으로 비교해 하나만 남기고, 탈락한 버전과 이유도 적어 둡니다.
3. 남은 하나에 대해 이 문서를 씁니다. "만들어도 될까요?"를 묻는 문서가 아니라 "이것으로 정했고, 이유는 이렇다"를 남기는 문서입니다.
4. 출시 뒤에도 결과와 결정을 계속 덧붙입니다.

> **마지막 점검 질문:** 이 문서만 받은 동료나 AI 에이전트가 나에게 한 번도 묻지 않고 일을 시작할 수 있나요? 적히지 않은 판단은 결국 재작업으로 돌아옵니다. (원본 템플릿의 'Golden Standard' 문단에서 착안)

---

## 0. 문서 정보

| 항목 | 내용 |
|---|---|
| 기능 이름 | |
| 담당 PM | |
| 함께 결정한 사람 | (개발, 디자인, 데이터, 법무·보안 등) |
| 상태 | 초안 / 결정 완료 / 출시 중 / 출시 완료 / 종료 |
| **결과 대시보드** | (출시 뒤 가장 먼저 볼 링크를 맨 위에 둡니다) |
| 마지막 수정일 | |

---

## 1. 결정

**한 문장으로 씁니다.**

> 버전 [N]개를 비교해 [선택한 버전]으로 간다. 결정적인 이유는 [근거 1~2개]다.

| 버전 | 접근 방식 | 링크 | 결과 | 고르거나 버린 이유 |
|---|---|---|---|---|
| A | | | 선택 | |
| B | | | 탈락 | |
| C | | | 탈락 | |

**비교 기준** (프로토타입을 보기 전에 정합니다)

- [ ] 핵심 문제를 실제로 줄이는가 (사용자 3명 이상의 반응)
- [ ] 4장의 까다로운 입력에서 어떻게 실패하는가
- [ ] 응답 속도와 1건당 비용
- [ ] 운영·검수에 드는 사람 시간

> 작성 팁: AI 기능은 데모가 멀쩡해 보여도 실패율이 숨어 있습니다. 보기 좋은 버전이 아니라 같은 입력 묶음으로 돌린 결과로 고르세요.

---

## 2. 기회 정의 (한 페이지 이내)

- **지금 무엇이 문제인가:** 누가, 얼마나 자주, 어떤 손해를 보는지 한 문장으로
  - 예: "인사팀이 출장 규정 문의에 주 80건 답하고, 답을 받기까지 평균 하루가 걸린다."
- **근거:** 가장 중요한 숫자 하나(출처와 측정 기간 포함)와 사용자 목소리 3개
  - 숫자:
  - 목소리 1: "…" (누가, 언제)
  - 목소리 2: "…"
  - 목소리 3: "…"
- **가설:** "우리가 [무엇]을 하면 [누구]의 [지표]가 [얼마나] 바뀔 것이다. 근거는 [무엇]이다."
- **왜 지금인가:** 이번 분기 회사 목표나 전략 중 어디에 이바지하는가
- **미루면 생기는 일:** (선택)

---

## 3. 프로토타입

- **링크:** 선택한 버전의 링크를 붙입니다. 검토자가 설명이 아니라 실물을 보고 의견을 내도록, 기능을 말로 다시 풀어 쓰지 않습니다.
- **만든 도구와 걸린 시간:** (예: Claude Code 2시간)
- **프로토타입과 출시판의 차이:** 일부러 뺀 것(실제 데이터 연결, 권한, 결제 등)을 적어 오해를 막습니다.

---

## 4. 기능과 행동 계약

### 4-1. 기능 목록

| 기능 | 사용자가 하는 일 | 시스템이 하는 일 | 우선순위 |
|---|---|---|---|
| | | | 필수 / 있으면 좋음 |

### 4-2. 예외 상황과 레드팀

- **예외 상황:** 빈 입력, 아주 긴 입력, 다른 언어, 오래된 데이터, 권한 없는 사용자 …
- **레드팀 목록:** 일부러 망가뜨려 보는 입력. 프롬프트 주입, 개인정보를 캐내려는 질문, 숫자를 지어내게 만드는 질문, 금지된 조언 요청 …

### 4-3. 측정 이벤트

| 이벤트 이름 | 언제 남는가 | 함께 남길 값 |
|---|---|---|
| | | (모델 ID, 프롬프트 버전, 응답 시간 등) |

### 4-4. 행동 계약 (AI 기능)

입력마다 기대하는 행동을 예시로 적습니다. 예시 하나는 네 칸입니다. Aakash Gupta는 좋은 응답부터 아주 훌륭한 응답까지 걸치는 15~25개를 권했습니다. 이 숫자는 그의 의견이며 검증된 기준은 아닙니다.

| # | 입력 | 좋은 응답 | 나쁜 응답 | 거절해야 하는 경우 |
|---|---|---|---|---|
| 1 | "출장 숙박비 한도가 얼마예요?" | 규정의 해당 조항과 금액, 개정일을 함께 답한다 | 규정에 없는 금액을 지어내거나 개정 전 기준을 답한다 | 다른 직원의 출장비 정산 내역을 묻는 경우 |
| 2 | | | | |
| … | | | | |

- 쉬운 예시, 애매한 예시, 거절해야 하는 예시를 고루 섞습니다.
- 가능하면 실제 문의·로그에서 가져오고, 개인정보는 5-3에 따라 지웁니다.
- 확신이 없을 때 어떻게 물러서는지(담당자 연결, "확인 후 답변" 등)도 한 줄 적습니다.

> **`[LeanX 추가]` 행동 계약으로 출시를 판정하지 마세요.** 15~25개는 팀이 기능의 행동을 합의하기에는 충분하지만 출시 시험으로는 적습니다. 실제 실패율이 0.5%인 기능을 20개로 시험하면 실패가 한 건도 안 보일 확률이 약 90%입니다(0.995의 20제곱). 출시 판정은 5장의 골든셋과 실제 트래픽으로 합니다. Anthropic의 에이전트 평가 가이드는 처음 평가 세트를 "실제 실패에서 가져온 20~50개의 단순한 과제"로 시작하라고 권하고, 성공 기준 문서는 사람이 채점한 적은 문항보다 자동 채점한 많은 문항이 낫다고 안내합니다.

---

## 5. 성공 측정과 평가

### 5-1. 졸업 지표와 안전장치

| 구분 | 지표 | 기준 | 비교 대상 | 측정 기간 |
|---|---|---|---|---|
| 졸업 지표 | 예: 규정 문의 첫 답변까지 걸린 시간 중간값 | 50% 이상 단축 | 기능을 끈 대조군 | 2주 |
| 안전장치 | 예: 인사팀 정정 문의 수 | 늘지 않을 것 | 대조군 | 같은 기간 |
| 안전장치 | 예: 규정에 없는 내용을 지어낸 답변 비율 | 1% 미만 | 표본 검수 | 같은 기간 |

### 5-2. 골든셋 (AI 기능)

출시 전에 돌리는 오프라인 시험입니다. 입력마다 맞는 출력이나 채점 규칙이 붙어 있습니다.

- 문항 수: 처음 20~50개로 시작해 자동 채점으로 늘립니다.
- 출처 비율: 실제 문의 ○% / 4-2 레드팀 ○% / 합성 ○%
- 채점 방식: 정답 일치 / 규칙 검사 / 모델 채점 / 사람 채점
- 통과 기준: (예: 반드시 맞혀야 하는 문항 100%, 전체 95% 이상)
- **사람 검수 기준표:** 정확성, 근거 제시, 어조, 거절 판단을 각각 1~3점으로
- `[LeanX 추가]` **담당자와 갱신 주기:** 누가, 얼마마다 실제 실패 사례를 골든셋에 보태는가. 오래 둔 골든셋은 실제 사용과 멀어집니다.

### 5-3. `[LeanX 추가]` 개인정보와 데이터

- 골든셋·예시에 실제 고객 또는 직원 데이터가 들어가는가: 예 / 아니요
- 들어간다면 비식별 처리 방법과 담당자:
- 외부 모델 API로 보내는 데이터의 범위와 보관 기간:
- 동의·고지 근거 (개인정보 보호법, 사내 정책):

---

## 6. 범위와 비목표

- **이번에 넣는 것:**
- **이번에 일부러 빼는 것:**
- **알고도 받아들이는 단점과 그 이유:**
  - 예: "답변이 조금 길어지는 것은 받아들인다. 근거 조항을 함께 보여주는 쪽이 더 중요하다."

---

## 7. 롤아웃과 롤백

| 단계 | 누구에게 | 기간 | 다음 단계로 가는 조건 |
|---|---|---|---|
| 1 | 내부 직원 | 1주 | 골든셋 통과, 심각한 오류 0건 |
| 2 | 사용자 5% | 1주 | 졸업 지표가 대조군보다 좋고 안전장치 유지 |
| 3 | 사용자 25% | 2주 | 같은 조건 유지 |
| 4 | 전체 | | |

- **킬 스위치를 누를 사람:** 이름과 부재 시 대행자
- **누르는 조건:** 측정 가능한 숫자로
  - 예: "표본 검수에서 규정에 없는 내용을 지어낸 답변이 1%를 넘거나, 인사팀 정정 문의가 평소의 두 배를 넘으면 그날 끈다."
- `[LeanX 추가]` **끄면 무엇으로 돌아가는가:** (이전 화면, 사람 상담 연결 등)
- `[LeanX 추가]` **알릴 사람:** (상담팀, 영업팀, 고객 공지 여부)

> 킬 스위치는 기능을 멈출 뿐, 이미 외부로 보낸 데이터나 실행된 결제를 되돌리지는 않습니다. 그런 작업에는 별도의 복구 절차를 적어 두세요.

---

## 8. 출시 기준과 변경 로그

### 8-1. 완료 조건

팀의 누구든 예/아니요로 확인할 수 있게 씁니다.

- [ ] 골든셋 통과 기준을 넘었다
- [ ] 4-3의 측정 이벤트가 실제로 쌓이는 것을 확인했다
- [ ] 킬 스위치를 실제로 한 번 꺼 보고 되돌렸다
- [ ] 5-3 개인정보 항목을 담당자가 확인했다

### 8-2. 변경 로그

첫 출시를 v1로 적고 시작합니다. 이후 기록마다 결과 링크, 예상과 달랐던 점, 그리고 계속 개선할지·넓힐지·멈출지를 남깁니다.

| 버전 | 날짜 | 바뀐 것 | `[LeanX 추가]` 모델 ID · 프롬프트 버전 | 골든셋 점수 | 결과 링크 | 예상과 달랐던 점 | 결정 |
|---|---|---|---|---|---|---|---|
| v1 | | 첫 출시 (5%) | | | | | 개선 / 확대 / 종료 |

> 모델 버전이나 프롬프트가 바뀌면 코드가 그대로여도 제품이 바뀐 것입니다. 그래서 변경 로그에 함께 남깁니다.

---

## 부록: 이 문서가 없어도 되는 경우

작은 팀이 같은 맥락을 공유한다면 프로토타입과 짧은 메모로 충분할 수 있습니다. 규제 산업이거나, 여러 팀이 함께 움직이거나, 사용자가 많아 실수 비용이 크다면 결정 기록을 남기세요.