단계 2: PRD - 제품 요구사항 문서 생성
PRD 단계는 Agent App Factory 파이프라인의 두 번째 단계로, input/idea.md를 완전한 MVP(최소 기능 제품) 중심의 제품 요구사항 문서로 변환하는 역할을 합니다. 이 단계에서는 목표 사용자, 핵심 기능, MVP 범위 및 비목표를 명확히 정의하여 후속 UI 설계와 기술 아키텍처에 명확한 지침을 제공합니다.
배우면 할 수 있는 것
input/idea.md를 표준 템플릿에 맞는artifacts/prd/prd.md문서로 변환- PRD Agent의 책임 범위 이해(요구사항 정의만 하고 기술 구현은 다루지 않음)
- MoSCoW 기능 우선순위 프레임워크를 활용하여 MVP가 핵심 가치에 집중하도록 보장
- 고품질의 사용자 스토리와 검증 가능한 수락 기준 작성
- PRD에 포함되어야 할 내용과 후속 단계에서 다룰 내용 구분
현재의 어려움
Bootstrap 단계를 완료하여 명확한 제품 아이디어가 있을 수 있지만, 요구사항 문서로 변환할 때 어려움을 겪을 수 있습니다:
- "어떤 기능을 포함해야 할지 모르겠고, 누락이나 과도한 설계를 걱정함"
- "기능이 많은데, 어떤 것이 MVP에 필수적인지 모르겠음"
- "사용자 스토리를 명확하게 작성하지 못해 개발팀이 이해하지 못함"
- "실수로 기술 구현 세부사항을 요구사항에 섞어 범위가 확장됨"
이러한 불분명한 PRD는 후속 UI 설계와 코드 개발에 명확한 지침이 부족하게 되어, 최종적으로 생성된 애플리케이션이 예상과 다르거나 불필요한 복잡성을 포함할 수 있습니다.
이 방법을 사용할 때
Bootstrap 단계가 완료되고 다음 조건을 충족할 때:
- idea.md 구조화 완료 (Bootstrap 단계 출력)
- 아직 UI 설계나 기술 아키텍처를 시작하지 않음 (이는 후속 단계에서 진행)
- MVP 범위를 명확히 하길 원함 (기능 과도 설계 방지)
- 개발과 디자인을 위한 명확한 지침이 필요함 (사용자 스토리, 수락 기준)
🎒 시작하기 전 준비
전제 조건
PRD 단계를 시작하기 전에 다음을 확인하세요:
- ✅ 프로젝트 초기화 완료
- ✅ 7단계 파이프라인 개요 이해
- ✅ Bootstrap 단계 완료하여
input/idea.md생성 - ✅ AI 어시스턴트 설치 및 구성 완료 (Claude Code 권장)
핵심 개념
PRD 단계란 무엇인가?
PRD(Product Requirements Document, 제품 요구사항 문서) 단계의 핵심 책임은 무엇을 할지 정의하고, 어떻게 할지는 정의하지 않는 것입니다.
기술 문서가 아님
PRD Agent는 아키텍트나 UI 디자이너가 아니므로 다음을 결정하지 않습니다:
- ❌ 어떤 기술 스택을 사용할지 (React vs Vue, Express vs Koa)
- ❌ 데이터베이스 설계 방법 (테이블 구조, 인덱스)
- ❌ UI 레이아웃과 상호작용 세부사항 (버튼 위치, 색상 구성)
그의 임무는:
- ✅ 목표 사용자와 그들의 고통 포인트 정의
- ✅ 핵심 기능과 우선순위 나열
- ✅ MVP 범위와 비목표 명확히 정의
- ✅ 테스트 가능한 사용자 스토리와 수락 기준 제공
왜 PRD가 필요한가?
상상해 보세요, 시공팀에게 "집을 짓고 싶어요"라고 말하는 것과 같습니다.
- ❌ 도면 없음: 시공팀이 추측만 하여 완전히 원하지 않는 집을 지을 수 있음
- ✅ 상세 도면 있음: 방 수, 기능 레이아웃, 자재 요구사항이 명확하여 시공팀이 도면에 따라 시공
PRD 단계는 "집을 짓고 싶어요"를 "3베드 2바스, 마스터 침실 남향, 오픈형 주방"의 상세 도면으로 변환하는 것입니다.
MoSCoW 기능 우선순위 프레임워크
PRD 단계는 MoSCoW 프레임워크를 사용하여 기능을 분류하고 MVP가 핵심 가치에 집중하도록 합니다:
| 분류 | 정의 | 판단 기준 | 예시 |
|---|---|---|---|
| Must Have | MVP에 절대 없어서는 안 될 기능 | 없으면 제품이 핵심 가치를 전달할 수 없음 | 가계부 앱: 지출 기록 추가, 지출 목록 보기 |
| Should Have | 중요하지만 차단되지 않는 기능 | 사용자가 눈에 띄게 누락을 느끼지만, 임시 해결책으로 대체 가능 | 가계부 앱: 보고서보내기, 분류 통계 |
| Could Have | 덤으로 추가되는 기능 | 핵심 경험에 영향을 주지 않으며, 사용자가 특별히 누락을 느끼지 않음 | 가계부 앱: 예산 알림, 다중 통화 지원 |
| Won't Have | 명확히 제외된 기능 | 핵심 가치와 무관하거나 기술 복잡도가 높음 | 가계부 앱: 소셜 공유, 투자 조언 |
MVP 핵심
Must Have 기능은 5-7개 이내로 제한하여 MVP가 핵심 가치에 집중하고 범위 확장을 방지하세요.
따라하기
1단계: Bootstrap 단계 완료 확인
PRD 단계를 시작하기 전에 input/idea.md가 존재하고 표준에 맞는지 확인하세요.
# idea.md 존재 여부 확인
cat input/idea.md보게 될 내용: 간단한 설명, 문제, 목표 사용자, 핵심 가치, 가정, 비목표 등의 섹션이 포함된 구조화된 문서.
idea.md가 표준에 맞지 않는 경우
Bootstrap 단계로 돌아가 다시 생성하거나, 수동으로 편집하여 정보를 보완하세요.
2단계: PRD 단계로 파이프라인 실행
Factory 프로젝트 디렉토리에서 실행:
# 파이프라인이 이미 시작된 경우, PRD 단계로 계속 진행
factory run prd
# 또는 처음부터 파이프라인 시작
factory runCLI는 현재 상태와 사용 가능한 단계를 표시하고, PRD Agent의 도움말 지침을 생성합니다.
3단계: AI 어시스턴트가 PRD Agent 정의 읽기
AI 어시스턴트(예: Claude Code)는 자동으로 agents/prd.agent.md를 읽어 그 책임과 제약을 이해합니다.
PRD Agent 책임
PRD Agent는 다음만 할 수 있습니다:
input/idea.md읽기artifacts/prd/prd.md쓰기skills/prd/skill.md의 사고 프레임워크와 결정 원칙 사용
다음은 할 수 없습니다:
- 기술 구현 세부사항이나 UI 설계에 대해 논의
- 다른 파일 읽기(업스트림 산출물 포함)
- 다른 디렉토리에 쓰기
4단계: skills/prd/skill.md 로드
PRD Agent는 skills/prd/skill.md를 로드하여 다음 지침을 얻습니다:
사고 프레임워크:
- 목표 사용자: 누가 사용할 것인가? 배경, 역할, 고통 포인트는 무엇인가?
- 핵심 문제: 제품이 해결할 근본적인 문제는 무엇인가?
- 핵심 가치: 이 솔루션이 왜 가치가 있는가? 경쟁 제품과 비교한 장점은 무엇인가?
- 성공 지표: 성공을 어떻게 측정할 것인가?
MoSCoW 기능 우선순위:
- Must Have(반드시 필요): MVP에 절대 없어서는 안 될 기능
- Should Have(가지면 좋음): 중요하지만 차단되지 않는 기능
- Could Have(있으면 좋음): 덤으로 추가되는 기능
- Won't Have(없음): 명확히 제외된 기능
사용자 스토리 작성 가이드:
[역할/사용자 유형]으로서
[기능/작업]을 원합니다
[비즈니스 가치/목표]를 위해PRD 문서 구조 요구사항 (8개 섹션):
- 개요
- 목표 사용자 프로필
- 핵심 가치 제안
- 기능 요구사항 (MoSCoW 분류)
- 사용자 흐름
- 비목표 (Won't Have)
- 성공 지표
- 가정 및 위험
5단계: PRD 문서 생성
AI 어시스턴트는 input/idea.md의 내용을 기반으로 기술의 사고 프레임워크와 결정 원칙을 사용하여 완전한 PRD 문서를 생성합니다.
PRD Agent가 하는 일:
input/idea.md읽고 핵심 요소 추출(목표 사용자, 문제, 핵심 가치 등)- MoSCoW 프레임워크에 따라 기능 분류
- Must Have 기능에 대한 사용자 스토리와 수락 기준 작성
- 비목표 나열하여 범위 확장 방지
- 정량화 가능한 성공 지표 제공
- 정리된 문서를
artifacts/prd/prd.md에 쓰기
핵심 제약
PRD Agent는 기술 구현 세부사항이나 UI 설계에 대해 논의하는 것이 금지되어 있습니다. 이러한 내용이 발견되면 PRD Agent는 쓰기를 거부합니다.
6단계: prd.md 내용 확인
PRD Agent가 완료되면 artifacts/prd/prd.md가 생성됩니다. 다음을 주의 깊게 확인하세요:
확인 포인트 ✅:
목표 사용자가 구체적인가?
- ✅ 구체적인 프로필 있음(나이/직업/기술 능력/사용 시나리오/고통 포인트)
- ❌ 모호함: "모든 사람" 또는 "가계부가 필요한 사람"
핵심 문제가 명확한가?
- ✅ 사용자가 현실적인 시나리오에서 겪는 어려움을 설명
- ❌ 공허함: "사용자 경험이 좋지 않음"
핵심 가치가 정량화 가능한가?
- ✅ 구체적인 이점 있음(80% 시간 절약, 50% 효율성 향상)
- ❌ 공허함: "효율성 향상", "더 나은 경험"
Must Have 기능이 집중되어 있는가?
- ✅ 5-7개 핵심 기능 이내
- ❌ 기능이 너무 많거나 부차적인 기능 포함
각 Must Have 기능에 사용자 스토리가 있는가?
- ✅ 표준 형식 사용(~~로서... 원합니다... 위해...)
- ❌ 사용자 스토리 누락 또는 형식 불일치
수락 기준이 검증 가능한가?
- ✅ 구체적이고 검증 가능한 기준 있음(금액 입력 가능, 목록에 표시)
- ❌ 모호함("사용자 친화적", "경험이 원활함")
Should Have와 Won't Have가 명확히 나열되었는가?
- ✅ Should Have는 "향후 반복"으로 표시하고 이유 설명
- ✅ Won't Have는 제외 이유 설명
- ❌ 누락 또는 너무 적음
성공 지표가 정량화 가능한가?
- ✅ 구체적인 수치 있음(사용자 유지율 > 30%, 작업 완료 시간 < 30초)
- ❌ 모호함("사용자가 좋아함", "경험이 좋음")
가정이 검증 가능한가?
- ✅ 사용자 조사를 통해 검증 가능
- ❌ 주관적 판단("사용자가 좋아할 것")
기술 구현 세부사항이나 UI 설계가 포함되어 있는가?
- ✅ 기술 세부사항과 UI 설명 없음
- ❌ 기술 스택 선택, 데이터베이스 설계, UI 레이아웃 등 포함
7단계: 계속 진행, 재시도 또는 일시 중지 선택
확인이 완료되면 CLI는 옵션을 표시합니다:
작업을 선택하세요:
[1] 계속 (UI 단계로 진행)
[2] 재시도 (prd.md 다시 생성)
[3] 일시 중지 (나중에 계속)코드 편집기에서 먼저 확인하세요
AI 어시스턴트에서 확인하기 전에 코드 편집기에서 artifacts/prd/prd.md를 열어 한 글자씩 확인하세요. UI 단계로 진입하면 수정 비용이 더 높아집니다.
함정 경고
함정 1: Must Have 기능이 너무 많음
잘못된 예시:
Must Have:
1. 지출 기록 추가
2. 지출 목록 보기
3. 보고서보내기
4. 분류 통계
5. 예산 알림
6. 다중 통화 지원
7. 소셜 공유
8. 투자 조언결과: MVP 범위가 너무 커져 개발 기간이 길어지고 위험이 높아집니다.
제안: 5-7개 핵심 기능으로 제한:
Must Have:
1. 지출 기록 추가
2. 지출 목록 보기
3. 지출 분류 선택
Should Have (향후 반복):
4. 보고서보내기
5. 분류 통계
Won't Have (명확히 제외):
6. 소셜 공유 (핵심 가치와 무관)
7. 투자 조언 (전문 자격 필요, 기술 복잡도 높음)함정 2: 사용자 스토리 누락 또는 형식 불일치
잘못된 예시:
기능: 지출 기록 추가
설명: 사용자가 지출 기록을 추가할 수 있음결과: 개발팀이 누구를 위해, 어떤 문제를 해결하는지 알 수 없습니다.
제안: 표준 형식 사용:
기능: 지출 기록 추가
사용자 스토리: 예산 의식이 강한 사용자로서
매 지출을 기록하고 싶습니다
내 소비 방향과 예산 통제를 파악하기 위해
수락 기준:
- 지출 금액과 설명 입력 가능
- 지출 분류 선택 가능
- 기록이 지출 목록에 즉시 표시됨
- 현재 날짜와 시간 표시함정 3: 수락 기준이 검증 불가능함
잘못된 예시:
수락 기준:
- 사용자 인터페이스가 친화적임
- 작업이 원활함
- 경험이 좋음결과: 테스트할 수 없어 개발팀이 "친화적", "원활함", "좋음"의 기준을 알 수 없습니다.
제안: 구체적이고 검증 가능한 기준 작성:
수락 기준:
- 지출 금액과 설명 입력 가능
- 10개의 사전 설정 분류에서 선택 가능
- 기록이 1초 이내에 지출 목록에 표시됨
- 현재 날짜와 시간 자동 기록함정 4: 목표 사용자 설명이 너무 광범위함
잘못된 예시:
목표 사용자: 가계부가 필요한 모든 사람결과: 후속 UI 설계와 기술 아키텍처가 명확한 방향을 잡을 수 없습니다.
제안: 명확한 프로필 정의:
주요 사용자 그룹:
- 역할: 18-30세 갓 입사한 젊은이
- 나이: 18-30세
- 기술 능력: 중급, 스마트폰 애플리케이션에 익숙함
- 사용 시나리오: 일상 소비 후 즉시 기록, 월말 통계 확인
- 고통 포인트: 월말에 초과 지출을 발견하지만 돈이 어디로 갔는지 모름, 예산 통제 없음함정 5: 비목표 누락 또는 너무 적음
잘못된 예시:
비목표: 없음결과: 후속 PRD와 Code 단계에서 과도한 설계가 이루어져 기술 복잡도가 증가할 수 있습니다.
제안: 최소 3개 이상 나열:
비목표 (Out of Scope):
- 소셜 공유 기능 (MVP는 개인 가계부에 집중)
- 재무 조언 및 투자 분석 (전문 자격 필요, 핵심 가치를 벗어남)
- 타사 금융 시스템과의 통합 (기술 복잡도 높음, MVP에 불필요)
- 복잡한 데이터 분석 및 보고서 (Should Have, 향후 반복)함정 6: 기술 구현 세부사항 포함
잘못된 예시:
기능: 지출 기록 추가
기술 구현: React Hook Form으로 폼 관리, API 엔드포인트 POST /api/expenses결과: PRD Agent가 이러한 내용을 거부합니다(요구사항만 정의하고 기술 구현은 다루지 않음).
제안: "무엇을"만 말하고 "어떻게"는 말하지 않음:
기능: 지출 기록 추가
사용자 스토리: 예산 의식이 강한 사용자로서
매 지출을 기록하고 싶습니다
내 소비 방향과 예산 통제를 파악하기 위해
수락 기준:
- 지출 금액과 설명 입력 가능
- 지출 분류 선택 가능
- 기록이 지출 목록에 즉시 표시됨
- 현재 날짜와 시간 표시함정 7: 성공 지표가 정량화되지 않음
잘못된 예시:
성공 지표:
- 사용자가 우리 애플리케이션을 좋아함
- 경험이 원활함
- 사용자 유지율이 높음결과: 제품이 성공적인지 측정할 수 없습니다.
제안: 정량화 가능한 지표 작성:
성공 지표:
제품 목표:
- 첫 달에 100명의 활성 사용자 확보
- 사용자가 주당 최소 3회 사용
- 핵심 기능(지출 기록 추가) 사용률 > 80%
핵심 지표 (KPIs):
- 사용자 유지율: 7일 유지율 > 30%, 30일 유지율 > 15%
- 핵심 기능 사용률: 지출 기록 추가 사용률 > 80%
- 작업 완료 시간: 지출 추가 1회 < 30초
검증 방법:
- 백엔드 로그로 사용자 행동 기록
- A/B 테스트로 사용자 유지율 검증
- 사용자 피드백 설문조사로 만족도 수집함정 8: 가정이 검증 불가능함
잘못된 예시:
가정: 사용자가 우리의 디자인을 좋아할 것결과: 사용자 조사를 통해 검증할 수 없어 MVP가 실패할 수 있습니다.
제안: 검증 가능한 가정 작성:
가정:
시장 가정:
- 18-30세 젊은이들이 "돈이 어디로 갔는지 모르겠다"는 고통을 겪고 있음
- 기존 가계부 애플리케이션이 너무 복잡하여 젊은이들이 더 간단한 솔루션 필요
사용자 행동 가정:
- 사용자가 예산 통제에 도움이 된다면 매 소비 후 2분을 들여 지출 기록할 의향이 있음
- 사용자는 복잡한 차트와 분석이 필요 없는 미니멀한 UI를 선호함
기술 가능성 가정:
- 모바일 애플리케이션에서 빠른 3단계 가계부 프로세스 구현 가능
- 오프라인 저장으로 기본 요구사항 충족 가능본 강의 요약
PRD 단계의 핵심은 요구사항 정의, 구현이 아님:
- 입력: 구조화된
input/idea.md(Bootstrap 단계 출력) - 과정: AI 어시스턴트가
skills/prd/skill.md의 사고 프레임워크와 MoSCoW 우선순위 프레임워크 사용 - 출력: 완전한
artifacts/prd/prd.md문서 - 검증: 사용자가 명확한지, 가치가 정량화 가능한지, 기능이 집중되어 있는지, 기술 세부사항이 포함되지 않았는지 확인
핵심 원칙
- ❌ 하지 않는 것: 기술 구현 논의, UI 레이아웃 설계, 데이터베이스 구조 결정
- ✅ 하는 것: 목표 사용자 정의, 핵심 기능 나열, MVP 범위 명확화, 테스트 가능한 사용자 스토리 제공
다음 강의 예고
다음 강의에서는 **단계 3: UI - 인터페이스 및 프로토타입 설계**를 배웁니다.
배울 내용:
- PRD에 따라 UI 구조를 설계하는 방법
- ui-ux-pro-max 기술로 디자인 시스템을 생성하는 방법
- 미리보기 가능한 HTML 프로토타입을 생성하는 방법
- UI 단계의 출력 파일과 종료 조건
부록: 소스 코드 참조
클릭하여 소스 위치 보기
업데이트 시간: 2026-01-29
| 기능 | 파일 경로 | 라인 |
|---|---|---|
| PRD Agent 정의 | agents/prd.agent.md | 1-33 |
| PRD Skill | skills/prd/skill.md | 1-325 |
| 파이프라인 정의 (PRD 단계) | pipeline.yaml | 20-33 |
| 오케스트레이터 정의 | agents/orchestrator.checkpoint.md | 1-100+ |
핵심 제약:
- 기술 구현 세부사항 금지: prd.agent.md:23
- UI 설계 설명 금지: prd.agent.md:23
- 목표 사용자 포함 필수: pipeline.yaml:29
- MVP 범위 정의 필수: pipeline.yaml:30
- 비목표 나열 필수: pipeline.yaml:31
- 출력 파일은 artifacts/prd/prd.md에 저장: prd.agent.md:13
종료 조건 (pipeline.yaml:28-32):
- PRD에 목표 사용자 포함
- PRD에 MVP 범위 정의
- PRD에 비목표(Out of Scope) 나열
- PRD에 기술 구현 세부사항 없음
Skill 내용 프레임워크:
- 사고 프레임워크: 목표 사용자, 핵심 문제, 핵심 가치, 성공 지표
- MoSCoW 기능 우선순위 프레임워크: Must Have, Should Have, Could Have, Won't Have
- 사용자 스토리 작성 가이드: 표준 형식 및 예시
- PRD 문서 구조 요구사항: 8개 필수 섹션
- 결정 원칙: 사용자 중심, MVP 중심, 비목표 명확, 테스트 가능성
- 품질 확인 목록: 사용자 및 문제, 기능 범위, 사용자 스토리, 문서 완성도, 금지 항목 확인
- 하지 말 것 (NEVER): 7가지 명확히 금지된 행위
PRD 문서 필수 섹션:
- 개요 (제품 개요, 배경 및 목표)
- 목표 사용자 프로필 (주요 사용자 그룹, 부차적 사용자 그룹)
- 핵심 가치 제안 (해결하는 문제, 우리의 솔루션, 차별화된 장점)
- 기능 요구사항 (Must Have, Should Have, Could Have)
- 사용자 흐름 (주요 흐름 설명)
- 비목표 (Won't Have)
- 성공 지표 (제품 목표, 핵심 지표, 검증 방법)
- 가정 및 위험 (시장 가정, 사용자 행동 가정, 기술 가능성 가정, 위험표)