PRD 생성

기능 아이디어를 체계적인 제품 요구사항 명세서로 변환합니다.

이 스킬의 기능

비공식적인 기능 요청을 사용자 스토리, 수락 기준, 기능적 요구사항, 성공 지표 및 규정 준수 지침이 포함된 완전한 PRD로 변환합니다. 결과물은 엔지니어링 팀이 구현하고 이해관계자가 검토할 준비가 된 상태입니다.

사용 시기

다음과 같은 경우 이 스킬을 활성화하세요:

사용자가 새로운 기능이나 제품 아이디어를 문서화하려는 경우
"PRD 작성", "요구사항 생성", "이 기능 문서화"와 같은 표현
제품 검토, 이해관계자 조정 또는 엔지니어링 인계를 준비하는 경우
사용자가 사용자 스토리, 수락 기준 또는 성공 지표를 언급하는 경우
대략적인 아이디어를 체계적인 문서로 공식화해야 하는 경우

시나리오 감지 (중요 - 첫 번째 단계)

PRD 콘텐츠를 생성하기 전에 반드시 시나리오를 식별해야 합니다.

AskUserQuestion을 사용하여 적용되는 시나리오를 확인합니다.

질문: PRD 생성 시나리오를 선택하세요

옵션	설명
반복 업데이트	기존 기능 기반 반복 최적화
새 기능	기존 제품에 새 모듈 추가
0-1 신제품	처음부터 완전히 새로운 제품 기획

시나리오별 컨텍스트 수집

시나리오가 식별되면 필요한 컨텍스트를 수집합니다.

시나리오	필수 정보	수집 방법
반복 업데이트	1. 현재 기능 설명2. UI 상태 (스크린샷/HTML/링크)3. 반복 목표	사용자 입력 + UI 상태 옵션에 대한 AskUserQuestion
새 기능	1. 제품 전체 아키텍처2. 디자인 규칙 (컴포넌트 라이브러리/상호작용 패턴)3. 진입 위치	`docs/product/`에서 읽거나 사용자 입력
0-1 신제품	1. 제품 배경 및 대상 사용자2. 리소스 제약3. 참조 제품	사용자 입력 + 경쟁 분석

반복 업데이트를 위한 UI 상태 수집: 사용자가 "반복 업데이트"를 선택하면 현재 UI 상태를 제공하는 방법을 묻습니다.

스크린샷 - 사용자가 스크린샷을 제공하고 mcp__zai-mcp-server__ui_to_artifact 또는 mcp__4_5v_mcp__analyze_image를 사용합니다.
HTML 파일 - 사용자가 로컬 HTML 경로를 제공하고 Read 도구를 사용하여 DOM 구조를 구문 분석합니다.
온라인 링크 - 사용자가 URL을 제공하고 mcp__web_reader__webReader를 사용합니다 (로그인 불필요).

0.5단계: 정보 격차 분석 및 PRD 계획 (중요 - 하드 게이트)

하드 게이트: 이 단계가 완료되고 사용자가 계획을 승인할 때까지 업계 벤치마크 확인 또는 PRD 생성을 진행하지 마십시오.

명시적-건너뛰기 프로토콜 (사용자가 명시적으로 상호작용 거부 시): 사용자가 질문을 명시적으로 금지하는 경우 (예: "그만 묻고 바로 작성하세요"), 대화형 게이트를 건너뛸 수 있습니다 — 하지만 반드시 출력을 가정 선언 블록으로 시작하여 모든 가정(시나리오, 선택/제외된 장, 대상 제품, 주요 기본값)을 나열해야 사용자가 수정할 수 있습니다. 가정 선언은 동시에 증거 규율의 완전성 체크리스트 역할을 합니다. 확인되지 않은 정보는 【待確認】, 증거가 없는 주장은 【未驗證】으로 표시하고 (아래 증거 규율 참조), 기본값을 추측하여 채우지 마십시오. 절대 조용히 건너뛰지 마십시오.

시나리오 감지 및 컨텍스트 수집 후:

격차 분석: 사용자 제공 정보를 이 시나리오의 컨텍스트 요구사항과 비교합니다. 누락된 모든 필수 필드를 나열하십시오. 또한 기존 인식 데이터(market-analysis.json, competitive-analysis, user-research.json, positioning.md)에 대해 docs/product/를 확인하십시오.

한 번에 하나의 질문: 누락된 각 항목에 대해 AskUserQuestion을 사용하여 객관식 옵션을 제공합니다. 여러 질문을 하나의 메시지에 묶지 마십시오.

누락된 항목	예시 질문
UI 스크린샷	"현재 기능의 인터페이스 상태를 어떻게 제공하시겠습니까?" → A. 이미 스크린샷 있음 B. HTML 파일 있음 C. 온라인 링크 있음 D. 없음, 건너뛰기
경쟁사 목록	"어떤 경쟁사를 분석해야 합니까?" → 다중 선택 + "기타"
대상 사용자	"대상 사용자는 누구입니까?" → A. 이미 정의된 페르소나 B. 제가 구술하면 정리해드립니다 C. 먼저 사용자 조사 필요
참조 제품	"참조할 제품이 있습니까?" → A. 있습니다, 말씀드리겠습니다 B. 업계 벤치마크를 검색해 드리겠습니다 C. 참조 불필요

누락된 자산 처리: 사용자가 "나중에 스크린샷을 제공하겠습니다" 또는 "건너뛰기"라고 말하면 보류 중인 항목을 기록하고 PRD 계획에 [待補充]로 표시합니다.

PRD 계획 생성: PRD 계획 구조를 준비합니다 (아직 표시하지 마십시오). 아래 표는 기본 선택 항목이 있는 템플릿을 보여줍니다.

### 예상 생성 PRD 챕터
| 챕터 | 내용 개요 | 선택 | 종속성 상태 |
|:-----|:---------|:-----|:---------|
| 제0장 산업 벤치마크 분석 | X개의 벤치마크 제품 연구 | ✅ | 완료 / [待補充] |
| 제1장 프로젝트 개요 | 사용자 설명 기반 전개 | ✅ | 완료 |
| 제2장 비즈니스 분석 | 대상 사용자 X, 문제점 Y | ✅ | 완료 / [待補充] |
| 제3장 기능 요구사항 | [주요 기능 목록] | ✅ | 완료 |
| 제4장 비기능적 요구사항 | 업계 표준 요구사항 | ✅ | 자동 생성 |
| 제5장 사용자 경험 흐름 | 기능 기반 추론 | ✅ | UI 보충 필요 |
| 제6장 프로젝트 위험 | 기능 복잡성 기반 | ✅ | 자동 생성 |
| 제7장 규정 준수 권장사항 | 데이터 유형 기반 | ❌ | 자동 생성 |
| 제8장 프로토타입 디자인 | [프로토타입 링크] | ❌ | - |
| 제9장 성공 지표 | 목표 기반 추론 | ❌ | 자동 생성 |

### 제외 목록 (다음 내용은 생성하지 않음)
- 기술 솔루션 / 아키텍처 디자인 — PRD는 제품 요구사항 문서로, 기술 구현 세부 사항을 포함하지 않음
- API 인터페이스 정의 / 엔드포인트 사양 — 개발 팀이 기술 솔루션에서 별도로 작성
- 데이터베이스 테이블 구조 디자인 — 제품 요구사항 범위에 포함되지 않음

참고: 위 표는 기본 선택 사항을 사용합니다. 실제 [선택] 값은 사용자의 챕터 선택 응답을 기반으로 4.5단계에서 채워집니다. 아직 사용자에게 이 표를 제시하지 마십시오.

4.5. 챕터 선택 (하드 게이트 — PRD 계획 제시 전):

AskUserQuestion을 사용하여 다중 선택으로 사용자에게 챕터 선택을 제시합니다. 4개 옵션 제한으로 인해 3개의 순차적 질문으로 분할합니다. 응답에서 selected_chapters 및 excluded_chapters 목록을 작성하고 PRD 계획 테이블의 [선택] 열을 업데이트합니다.

질문 1 — 핵심 챕터 (제0-3장):

옵션	기본값	설명
제0장 산업 벤치마크 분석	✅ 선택됨	벤치마크 제품 및 모범 사례 연구
제1장 프로젝트 개요	✅ 선택됨	프로젝트 배경, 목표, 범위
제2장 비즈니스 분석	✅ 선택됨	대상 사용자, 문제점, 시장 분석
제3장 기능 요구사항	✅ 선택됨	기능 목록, 사용자 스토리, 상세 요구사항

질문 2 — 확장 챕터 (제4-7장):

옵션	기본값	설명
제4장 비기능적 요구사항	✅ 선택됨	성능, 보안, 가용성, 호환성
제5장 사용자 경험 흐름	✅ 선택됨	사용자 여정, 페이지 흐름 다이어그램
제6장 프로젝트 위험	✅ 선택됨	프로젝트 위험 및 완화 전략
제7장 규정 준수 권장사항	⬜ 선택 안 됨	규정 준수 지침 및 위험 범주

질문 3 — 선택적 챕터 (제8-9장):

옵션	기본값	설명
제8장 프로토타입 디자인	⬜ 선택 안 됨	프로토타입 링크 및 디자인 노트
제9장 성공 지표	⬜ 선택 안 됨	North Star, 프로세스 및 결과 지표

영구 제외 사항 (선택 목록에 없으며 절대 생성되지 않음):

기술 솔루션 / 아키텍처 디자인 — PRD는 기술 구현 세부 사항을 포함하지 않음
API 인터페이스 정의 — 인터페이스 문서는 개발 팀에서 별도로 작성
데이터베이스 테이블 구조 디자인 — 제품 요구사항 범위에 포함되지 않음

선택 수집 후: PRD 계획 테이블의 [선택] 열을 사용자 선택을 반영하도록 업데이트합니다 (✅ 선택됨, ❌ 제외됨).

사용자 승인: AskUserQuestion을 사용하여 PRD 계획(챕터 선택 포함)을 제시하고 명시적인 승인을 받습니다.

옵션	설명
확인, 이 챕터 계획으로 PRD 생성	1단계 업계 벤치마크 및 2단계 PRD 생성으로 이동
챕터 선택 조정	생성할 챕터 재선택
계획 조정 필요	PRD 계획 수정 후 재확인
추가 정보 제공	0.5단계로 돌아가 정보 보충 후 계획 재생성
먼저 인식 데이터 보충	market-research / competitive-analysis 호출

안티 패턴: "충분한 정보가 있으니 그냥 생성하겠습니다" — 금지됩니다. 격차가 최소인 경우에도 계획을 제시하고 승인을 받으십시오.

TUI 환경의 이미지 처리 가이드

터미널 (TUI) 환경에서 사용자는 다음 방법으로 이미지를 제공할 수 있습니다.

방법 1: 로컬 파일 경로 (가장 간단함)

이미지의 로컬 경로를 직접 제공하고 Read 도구를 사용하여 읽습니다.

# 사용자 대화 예시
"이 UI 스크린샷 분석: /Users/fh/Desktop/screenshot.png"
"현재 인터페이스: ~/Screenshots/ui-2025-03-12.png"
"참조 이미지: ./docs/product/images/reference.png"

지원되는 경로 형식:

절대 경로: /Users/fh/Desktop/screenshot.png
홈 디렉토리 약어: ~/Screenshots/ui.png
상대 경로: ./images/ui.png

지원되는 이미지 형식: PNG, JPG, JPEG, WebP, GIF

방법 2: 온라인 이미지 URL

사용자가 이미지를 이미지 호스팅/클라우드 스토리지에 업로드한 후 URL을 제공합니다.

# 사용자 대화 예시
"UI 스크린샷: https://i.imgur.com/xyz.png"
"참조 이미지: https://s3.aws.com/bucket/screenshot.png"

mcp__4_5v_mcp__analyze_image 또는 mcp__zai-mcp-server__ui_to_artifact 도구를 사용하여 원격 이미지를 읽습니다.

권장 이미지 호스팅:

imgur.com (무료, 등록 불필요)
GitHub (이슈 첨부 파일로)
클라우드 스토리지 (AWS S3, Alibaba Cloud OSS)

방법 3: 터미널 스크린샷 명령어

사용자가 터미널 스크린샷 도구를 사용하여 빠르게 스크린샷을 생성하도록 안내합니다.

macOS:

# 선택한 영역 캡처 (대화형)
screencapture -i ~/screenshot.png

# 전체 창 캡처
screencapture -w ~/screenshot.png

# 전체 화면 캡처
screencapture ~/screenshot.png

Linux:

# ImageMagick (먼저 설치 필요: sudo apt install imagemagick)
import ~/screenshot.png

# gnome-screenshot (Ubuntu/GNOME)
gnome-screenshot -a -f ~/screenshot.png

# spectacle (KDE)
spectacle -r -o ~/screenshot.png

방법 4: 클립보드에서 직접 가져오기 (macOS)

# pngpaste 도구 설치
brew install pngpaste

# 클립보드의 이미지를 파일로 저장
pngpaste ~/screenshot.png

처리 흐름

사용자가 이미지를 제공하면:

로컬 경로 → Read 도구를 사용하여 직접 읽기
원격 URL → mcp__4_5v_mcp__analyze_image 또는 mcp__zai-mcp-server__ui_to_artifact 사용
이미지 내용 분석 → UI 구조, 레이아웃, 상호작용 요소 추출
PRD 생성 → 이미지 분석 결과를 기반으로 요구사항 문서 생성

업계 벤치마크 확인

시나리오 감지, 컨텍스트 수집 및 정보 명확화 후:

사용자 제공 벤치마크 (우선 순위): 사용자가 지정한 참조 제품
에이전트 보충 검색: 시나리오 키워드를 기반으로 업계 모범 사례 자동 검색
모범 사례 추출: 3-5개의 벤치마크 상호작용 패턴/기능 디자인
PRD에서 인용: 채택/차별화 이유와 함께 벤치마크 솔루션 참조

검색 키워드 매핑:

시나리오	검색 키워드
반복 업데이트	"{기능명} 모범 사례", "업계 {기능명} 디자인"
새 기능	"{제품 유형} {모듈명} 솔루션", "유사 제품 {기능}"
0-1 신제품	"{산업} 제품 프레임워크", "{분야} 제품 맵"

작동 방식

생성 프로세스는 완전하고 실행 가능한 PRD를 보장합니다.

시나리오 감지 - AskUserQuestion을 사용하여 반복/신규 기능/신제품 식별
컨텍스트 수집 - 시나리오 유형에 따라 필수 정보 수집
정보 격차 분석 - 누락된 정보 식별, 한 번에 하나의 질문
챕터 선택 - 사용자가 생성할 PRD 챕터 선택 (다중 선택)
PRD 계획 제시 - 사용자 승인을 위해 챕터 선택이 포함된 계획 제시 (하드 게이트)
업계 벤치마크 연구 - 모범 사례 검색 및 추출 (사용자 지정 + 에이전트 검색)
요구사항 구문 분석 - 사용자의 기능 요청을 주요 구성 요소로 구조화
컨텍스트 수집 - 시장 분석, 경쟁 인사이트, 사용자 조사 읽기
섹션 조립 - 적절한 세부 정보로 선택된 PRD 섹션만 빌드
완전성 확인 - 품질 표준에 대해 확인 (선택된 챕터만)
전달 전 자체 검토 - PRD 사전 검토 (챕터 자체 점검 + 이해관계자 관점 도전) 실행; 차단 항목 수정 또는 【待確認】 표시
출력 생성 - docs/product/prd/{feature-name}-{date}-v{version}.md에 작성 (끝에 [사전 검토 기록] 섹션 포함)

콘텐츠 제약 조건 (하드 규칙):

PRD 콘텐츠를 생성하기 전에 다음 사항에 유의하십시오.

사용자가 선택한 챕터만 생성하십시오. 선택되지 않은 챕터는 완전히 건너뜁니다.
사용자 입력에 관계없이 다음 콘텐츠 유형을 절대 생성하지 마십시오:
- 기술 아키텍처 / 구현 세부 사항
- API 엔드포인트 정의 또는 사양
- 데이터베이스 스키마 또는 테이블 디자인
사용자의 기능 설명에 기술적 세부 사항이 언급된 경우, 구현 세부 사항을 노출하지 않고 기능적 요구사항으로 요약하십시오.

입력 파라미터

파라미터	유형	필수	설명
`requirements`	string	예	문서화할 기능 설명 또는 사용자 스토리
`target_audience`	string	아니오	대상 사용자 세그먼트 또는 페르소나
`context_refs`	list	아니오	참조할 관련 컨텍스트 파일

증거 규율 (證據紀律)

누락 정보 표시【待確認】：입력 또는 컨텍스트에서 얻을 수 없는 정보는 【待確認】으로 표시하고 기본값을 추측하여 채우지 마십시오.
증거 추적【未驗證】：사용자 요구사항/시장 주장은 증거 출처를 반드시 질문해야 합니다. 증거가 없는 것은 【未驗證】으로 표시하고 필요한 검증 방법을 명시하십시오.
완전성 검사 게이트: 공식 출력물을 전달하기 전에 먼저 정보 완전성 체크리스트 (확인됨 ✅ / 확인 필요 ⚠️ / 미확인 ❓)를 출력하고 사용자가 확인한 후에야 본문을 생성하십시오.

명시적-건너뛰기 프로토콜(0.5단계)과의 관계: 증거 규율은 출력 규율(정보 표시 및 전달 전 자체 점검)이고, 명시적-건너뛰기는 상호작용 규율(사용자가 명시적으로 상호작용을 거부할 때의 다운그레이드 처리)이며, 둘은 상호 보완적이며 충돌하지 않습니다. 명시적-건너뛰기 시나리오에서 완전성 체크리스트는 면제되지 않습니다 — [가정 선언]과 병합되어 출력되지만 사용자 확인을 기다리지 않습니다. 가정 선언의 확인되지 않은 정보도 이 섹션의 규칙에 따라 【待確認】 / 【未驗證】으로 표시됩니다.

출력 구조

PRD는 다음 구조를 따릅니다 (표준 PRD 템플릿에 따름). 중요: 이 템플릿은 가능한 모든 챕터를 보여줍니다. 사용자가 선택한 챕터만 생성하십시오. 선택되지 않은 챕터는 완전히 건너뜁니다. 어떤 상황에서도 기술 아키텍처, API 사양 또는 데이터베이스 디자인을 생성하지 마십시오.

# [기능 이름] PRD

## 문서 기본 정보
- **문서 버전**: v1.0
- **생성 날짜**: YYYY-MM-DD
- **마지막 업데이트**: YYYY-MM-DD
- **문서 상태**: 초안/검토/승인됨
- **작성자**: [사용자 이름]
- **검토자**: [待定]

## 수정 기록
| 버전 | 날짜 | 수정 내용 | 수정자 |
|:-----|:-----|:---------|:-------|
| v1.0 | YYYY-MM-DD | 초기 버전 | [작성자] |

## 0. 산업 벤치마크 분석
### 0.1 참조 제품
| 제품 | 주요 기능 | 채택/차별화 |
|:-----|:---------|:-----------|
| [경쟁사 A] | XXX | XXX 패턴 채택, 이유는 ... |
| [경쟁사 B] | XXX | 차별화 포인트는 ... |

### 0.2 모범 사례 요약
- **상호작용 패턴**: [채택된 업계 표준 상호작용 패턴]
- **핵심 차별화**: [이 솔루션의 독특한 점]

## 1. 프로젝트 개요
### 1.1 프로젝트 배경
[시장 배경, 경쟁 배경, 사용자 요구 배경]

### 1.2 프로젝트 목표
#### 1.2.1 핵심 목표
- [측정 가능한 핵심 목표]

#### 1.2.2 부차적 목표
- [지원 목표]

### 1.3 프로젝트 범위
#### 1.3.1 포함 범위
- [이번 반복/기능에 포함되는 내용]

#### 1.3.2 불포함 범위
- [이번 범위에서 명확히 제외되는 사항]

## 2. 비즈니스 분석
### 2.1 대상 사용자
| 사용자 역할 | 설명 | 핵심 요구사항 |
|:---------|:-----|:---------|
| 사용자 A | [사용자 조사 출처] | XXX |
| 사용자 B | [사용자 조사 출처] | XXX |

### 2.2 사용자 문제점
| 문제 ID | 문제 설명 | 영향 정도 |
|:-------|:---------|:---------|
| P-001 | XXX | 높음/중간/낮음 |
| P-002 | XXX | 높음/중간/낮음 |

### 2.3 시장 분석
[산업 동향, 경쟁 구도, 시장 기회]

## 3. 기능 요구사항
### 3.1 핵심 기능 목록
| 기능 ID | 기능 이름 | 우선 순위 | 설명 |
|:-------|:---------|:-------|:-----|
| F-001 | XXX | P0/P1/P2 | XXX |
| F-002 | XXX | P0/P1/P2 | XXX |

### 3.2 사용자 스토리
#### US-1: [기능 이름]
**역할로서** [사용자 역할]
**나는 다음을 원합니다** [기능 설명]
**그래서** [비즈니스 가치]

**수락 기준**:
- Given [전제 조건]
- When [실행 작업]
- Then [예상 결과]

**우선 순위**: P0/P1/P2
**예상 크기**: X Story Points

#### US-2: [기능 이름]
...

### 3.3 기능 세부 사항
#### F-001: [기능 이름]
**설명**: [상세 기능 설명]

**상호작용 흐름**:
1. 1단계
2. 2단계
3. 3단계

**경계 조건**:
- 정상 흐름: ...
- 예외 상황: ...

## 4. 비기능적 요구사항
### 4.1 성능 요구사항
- 페이지 응답 시간 < XXXms
- XXX 동시 사용자 지원
### 4.2 보안 요구사항
- 데이터 암호화 저장
- 사용자 권한 제어
### 4.3 가용성 요구사항
- 시스템 가용성 > 99.9%
### 4.4 호환성 요구사항
- iOS 14+, Android 10+
- 주요 브라우저 호환

## 5. 사용자 경험 흐름
### 5.1 사용자 여정
[주요 사용자 경로 설명]
1. 사용자 진입 → 2. 작업 실행 → 3. 목표 달성

### 5.2 페이지 흐름도
[페이지 이동 관계 설명]
- 페이지 A → 페이지 B → 페이지 C

## 6. 프로젝트 위험 및 대응
> 참고: 이 섹션은 제품/비즈니스 위험만 포함하며, 기술 구현 위험은 포함하지 않습니다 (기술 위험은 개발 팀이 기술 솔루션에서 평가함).
| 위험 ID | 위험 설명 | 확률 | 영향 | 대응 조치 |
|:-------|:---------|:-----|:-----|:---------|
| R-001 | XXX | 높음/중간/낮음 | 높음/중간/낮음 | XXX |
| R-002 | XXX | 높음/중간/낮음 | 높음/중간/낮음 | XXX |

## 7. 규정 준수 권장사항

### 7.1 규정 준수 요점 개요
[규정 준수 전문가 검토의 주요 요점 요약]

### 7.2 위험 알림
| 위험 범주 | 설명 | 권장사항 |
|:---------|:-----|:---------|
| 개인정보 보호 규정 준수 | [사용자 데이터 처리 방식 관련] | [규정 준수 권장사항] |
| 콘텐츠 규정 준수 | [콘텐츠 검토 요점 관련] | [규정 준수 권장사항] |
| 데이터 보안 | [데이터 저장 및 전송 요구사항 관련] | [규정 준수 권장사항] |
| 타사 규정 준수 | [의존하는 타사 서비스 규정 준수 관련] | [규정 준수 권장사항] |

### 7.3 규정 준수 보고서 첨부 파일
- [ ] 규정 준수 분석 보고서 첨부됨 (있는 경우, 경로 제공)
- [ ] 규정 준수 검토 대기 중 (필요한 경우, 규정 준수 전문가 검토 일정)

...

[번역을 위해 잘림]

kelegele/oh-my-pm

oh-my-pm란 무엇인가요?

즐겨 사용하는 AI에게 물어보기

문서