npx claudepluginhub unicorn-plugins/npd --plugin npdWant just this skill?
Add to a custom plugin, then install with one command.
기획 단계 AI 협업 — 18단계 서비스 기획 워크플로우 (MVP정의 → 고객분석 → 시장조사 → 고객경험 → 문제가설 → 솔루션 → 비즈니스모델 → 이벤트스토밍 → 유저스토리 → UI/UX → 프로토타입 → 플로우 스크립트)
This skill uses the workspace's default tool permissions.
Plan
[NPD Plan 활성화]
목표
PO·서비스기획자·도메인전문가·아키텍트·AI엔지니어가 협업하여 6단계 18스텝의 완전한 서비스 기획을 수행함. MVP 정의부터 프로토타입까지 체계적으로 산출물을 생성하며, 각 단계의 산출물이 다음 단계의 컨텍스트로 누적 연결됨.
활성화 조건
사용자가 /npd:plan 호출 시 또는 "기획 시작", "기획해줘", "서비스 기획" 키워드 감지 시.
주의사항: 중간 단계부터 시작할 때도 각 단계별 승인 여부를 선택하는 Step 0은 항상 수행하여 진행 모드를 설정해야 합니다.
선행 조건
/npd:create완료 (프로젝트 디렉토리 및 CLAUDE.md 존재).npd/domain-context.yaml존재 (도메인 컨텍스트)
에이전트 호출 규칙
| 에이전트 | FQN |
|---|---|
| product-owner | npd:product-owner:product-owner |
| service-planner | npd:service-planner:service-planner |
| architect | npd:architect:architect |
| domain-expert | npd:domain-expert:domain-expert |
| ai-engineer | npd:ai-engineer:ai-engineer |
프롬프트 조립
agents/{agent-name}/에서 3파일 로드 (AGENT.md + agentcard.yaml + tools.yaml)gateway/runtime-mapping.yaml참조하여 구체화:- 모델 구체화: agentcard.yaml의
tier→tier_mapping에서 모델 결정 - 툴 구체화: tools.yaml의 추상 도구 →
tool_mapping에서 실제 도구 결정 - 금지액션 구체화: agentcard.yaml의
forbidden_actions→action_mapping에서 제외할 실제 도구 결정 - 최종 도구 = (구체화된 도구) - (제외 도구)
- 모델 구체화: agentcard.yaml의
- 도메인 컨텍스트 주입:
domain-expert에이전트 호출 시 프로젝트의.npd/domain-context.yaml을 읽어 프롬프트에 포함. 도메인명, 배경(background), 전문성(expertise), 규제/표준(regulations) 정보를 동적 컨텍스트로 주입하여 도메인 특화 자문을 수행 - 프롬프트 조립: 공통 정적(runtime-mapping) → 에이전트별 정적(3파일) → 인격(persona) → 도메인 컨텍스트(domain-expert만) → 동적(작업 지시)
Task(subagent_type=FQN, model=구체화된 모델, prompt=조립된 프롬프트)호출
Step 0. 진행 모드 선택
기획 워크플로우 시작 전, 각 단계별 승인 여부를 선택합니다.
<!--ASK_USER-->{"title":"진행 모드 선택","questions":[ {"question":"각 단계 완료 후 승인을 받고 진행할까요, 자동으로 진행할까요?","type":"radio","options":["단계별 승인","자동 진행"]} ]}
<!--/ASK_USER-->- 단계별 승인 선택 시 → 각 스텝 완료 후 아래 형식의 승인 요청을 표시하고 사용자 승인 후 다음 스텝 진행:
{"title":"단계 승인","questions":[ {"question":"{완료된 스텝명} 단계가 완료되었습니다. 결과 파일({생성된 파일 경로})을 검토하고 {다음 스텝명} 단계로 계속 진행할 지 승인해 주십시오.","type":"radio","options":["승인","재작업 요청","중단"]} ]}
<!--/ASK_USER-->-
승인 → 다음 스텝 진행
-
재작업 요청 → 사용자 피드백을 받아 현재 스텝 재수행
-
중단 → 현재까지 산출물 보존 후 스킬 종료
-
자동 진행 선택 시 → 승인 없이 연속 실행
상태 기록 (/clear 대비)
Step 0 완료 후, 프로젝트 루트 CLAUDE.md의 ## NPD 워크플로우 상태 섹션 하위에 ### plan 서브섹션을 생성(이미 있으면 갱신)합니다:
## NPD 워크플로우 상태
### plan
- 진행 모드: {선택값}
- 마지막 완료 Step: Step 0
이후 각 Step 완료 시 마지막 완료 Step 값을 갱신합니다.
워크플로우 개요
1단계: 정의 (MVP정의 + 고객분석 + 시장조사)
↓
2단계: 문제 발견 (고객경험단계 + 고객경험조사 + 여정맵 + 문제가설 + 방향성)
↓
3단계: 솔루션 (아이디어발상 + 솔루션선정)
↓
4단계: 비즈니스 모델 (비즈니스모델 + 발표자료)
↓
5단계: 제품 설계 (이벤트스토밍 + 유저스토리 + UI/UX설계)
↓
6단계: 프로토타입 + 플로우 스크립트
1단계: 정의 (Define)
Step 1. MVP 주제 정의 → Agent: product-owner (/plan 활용)
- GUIDE:
{PLUGIN_DIR}/resources/guides/plan/01-mvp-definition-guide.md - TASK: CLAUDE.md의 MVP 주제를 기반으로 비즈니스 도메인을 정의하고, MVP 후보를 시장 잠재력·사용자 pain points·실현 가능성·경쟁 우위 4가지 팩터로 평가하여 최종 MVP 주제를 확정
- EXPECTED OUTCOME:
docs/plan/define/MVP정의.md— MVP 주제 정의, 선정 이유(4가지 팩터 평가표), 목표 비즈니스 도메인 - POST-ACTION: 프로젝트 CLAUDE.md의
## 목표섹션 다음에## MVP 주제섹션을 추가하고, 확정된 MVP 주제와 한 줄 설명을 기록
Step 2. 고객 분석 → Agent: service-planner (/plan 활용)
- GUIDE:
{PLUGIN_DIR}/resources/guides/plan/02-customer-analysis-guide.md - TASK: JTBD 프레임워크로 타겟 고객 유형을 정의하고 사용자 세그먼트(3-5개)별 인구통계·행동 패턴·현재 상황, 주요 Job과 원하는 결과를 도출
- EXPECTED OUTCOME:
docs/plan/define/고객분석.md— 타겟 고객 유형(JTBD 형식), 사용자 세그먼트 3-5개, Job to be Done - POST-ACTION: 프로젝트 CLAUDE.md의
## MVP 주제섹션 다음에## 고객유형섹션을 추가하고, 선정된 고객유형과 최우선 고객 세그먼트를 기록
Step 3. 시장 조사 → Agent: domain-expert (/plan 활용)
도메인 컨텍스트 주입:
domain-expert호출 시 프로젝트의.npd/domain-context.yaml을 읽어 프롬프트에 포함하여 도메인 특화 자문을 수행합니다.
- GUIDE:
{PLUGIN_DIR}/resources/guides/plan/03-market-research-guide.md - TASK: MVP 주제와 타겟 고객에 대해 시장 규모(TAM/SAM/SOM), 경쟁 환경(3-5개 경쟁사), 고객 트렌드, 규제 환경, SWOT 분석, 시장 진입 전략을 포함한 철저한 시장 조사를 수행
- EXPECTED OUTCOME:
docs/plan/define/시장조사.md— 시장 규모·성장, 경쟁 환경, 고객 트렌드, 규제 환경, SWOT, 시장 진입 전략
2단계: 문제 발견 및 방향성 (Discover)
Step 4. 고객경험 단계 정의 → Agent: service-planner (/plan 활용)
- GUIDE:
{PLUGIN_DIR}/resources/guides/plan/04-customer-journey-stages-guide.md - TASK: MVP 주제와 고객유형을 기반으로 현재 고객이 겪는 경험 단계(5-7개)를 문제 인식부터 해결/관리까지 순차적으로 정의
- EXPECTED OUTCOME:
docs/plan/define/고객경험단계.md— 고객경험 단계(화살표 연결), 단계별 설명(주요 행동·긍정/부정 느낌·Pain Points), 단계 도출 근거
Step 5. 고객 경험 조사 → Agent: service-planner × 3 병렬 (/ralph 활용)
조사 규모 설정: Step 5 시작 전, 고객 경험 조사의 규모를 사용자로부터 입력받습니다.
<!--ASK_USER-->{"title":"고객 경험 조사 규모 설정","questions":[ {"question":"고객경험 인터뷰 대상자 수를 입력해 주세요. (기본값: 10명)","type":"text","placeholder":"10"}, {"question":"관찰 조사 횟수를 입력해 주세요. (기본값: 10회)","type":"text","placeholder":"10"}, {"question":"체험 테스트 횟수를 입력해 주세요. (기본값: 10회)","type":"text","placeholder":"10"} ]}
<!--/ASK_USER-->사용자가 입력한 값을 각각
{인터뷰수},{관찰수},{체험수}로 사용합니다. 미입력 시 기본값 10을 적용합니다.
- GUIDE:
{PLUGIN_DIR}/resources/guides/plan/05-customer-experience-guide.md - 실행 방식: 3가지 조사를 서브에이전트로 병렬 수행한 후, 인터뷰 결과 취합을 순차 수행합니다.
┌─────────────────────────────────────────────────┐
│ Step 5 시작 (조사 규모 입력 완료) │
│ │
│ ┌───────────┐ ┌───────────┐ ┌───────────────┐ │
│ │ 5-A 관찰 │ │ 5-B 체험 │ │ 5-C 인터뷰 │ │
│ │ (병렬) │ │ (병렬) │ │ (병렬) │ │
│ └─────┬─────┘ └─────┬─────┘ └──────┬────────┘ │
│ └──────────────┼──────────────┘ │
│ ▼ │
│ ┌────────────────────┐ │
│ │ 5-D 인터뷰 취합 │ │
│ │ (5-C 완료 후 순차) │ │
│ └────────────────────┘ │
└─────────────────────────────────────────────────┘
Step 5-A. 관찰 조사 (병렬) → Agent: service-planner
- TASK: 고객경험 단계를 기준으로 {관찰수}회의 관찰 조사를 수행하여 고객 행동 데이터를 생성
- EXPECTED OUTCOME:
docs/plan/define/관찰결과.md— 관찰 {관찰수}회 결과(고객경험 단계별 관찰 행동·어려움·Pain Point·니즈·행동 패턴)
Step 5-B. 체험 조사 (병렬) → Agent: service-planner
- TASK: 고객경험 단계를 기준으로 {체험수}회의 체험 테스트를 수행하여 사용자 경험 데이터를 생성
- EXPECTED OUTCOME:
docs/plan/define/체험결과.md— 체험 {체험수}회 결과(고객경험 단계별 경험 내용·긍정/부정 측면·만족도)
Step 5-C. 고객경험 인터뷰 (병렬) → Agent: service-planner
- TASK: 고객경험 단계를 기준으로 {인터뷰수}명 대상 심층 인터뷰를 수행하여 개별 인터뷰 결과를 생성
- EXPECTED OUTCOME:
docs/plan/define/고객경험인터뷰결과.md— 인터뷰 {인터뷰수}명 개별 결과(고객경험 단계별 행동·생각·긍정적/부정적 느낌)
Step 5-D. 인터뷰 결과 취합 (5-C 완료 후 순차) → Agent: service-planner
- TASK: 5-C에서 생성된 개별 인터뷰 결과를 종합 분석하여 핵심 인사이트를 도출
- EXPECTED OUTCOME:
docs/plan/define/고객경험인터뷰결과취합.md— 인터뷰 종합 분석(핵심 인사이트·Pain Points·Needs·기대 가치)
실행 지침: Step 5-A, 5-B, 5-C를
Task(run_in_background=true)로 동시에 실행합니다. 3개 모두 완료되면 5-D를 순차 실행합니다. 모든 서브스텝이 완료되어야 Step 5 완료로 간주합니다.
Step 6. 고객 여정 맵 작성 → Agent: service-planner (/ralph 활용)
- GUIDE:
{PLUGIN_DIR}/resources/guides/plan/06-journey-mapping-guide.md - TASK: 고객경험 단계를 X축으로, 경험 조사 데이터를 기반으로 페르소나 정의·단계별 행동/생각/감정/터치포인트/Pain Points/Gain Points·감정 곡선·핵심 인사이트·기회 영역이 포함된 User Journey Map을 작성
- EXPECTED OUTCOME:
docs/plan/define/유저저니맵.md— 페르소나·여정 맵 상세·감정 곡선·핵심 인사이트·기회 영역 /docs/plan/define/유저저니맵.svg— 시각화된 여정 맵
Step 7. 문제 가설 정의 → 전체 팀 협업 (발산-수렴-선택 패턴) (/ralph 활용)
도메인 컨텍스트 주입:
domain-expert호출 시 프로젝트의.npd/domain-context.yaml을 읽어 프롬프트에 포함합니다.
- GUIDE:
{PLUGIN_DIR}/resources/guides/plan/07-problem-hypothesis-guide.md - 실행 방식: 5개 서브스텝을 순차/병렬 조합으로 수행합니다.
┌──────────────────────────────────────────────────────────────┐
│ Step 7 시작 │
│ │
│ ── 7-1. 문제가설 정의 (발산-수렴-선택) ── │
│ ┌────┐ ┌────┐ ┌────┐ ┌────┐ ┌────┐ │
│ │ PO │ │ SP │ │ DE │ │ AR │ │ AI │ ← 5WHY 병렬 (5명) │
│ └─┬──┘ └─┬──┘ └─┬──┘ └─┬──┘ └─┬──┘ │
│ └───────┼──────┼──────┼──────┘ │
│ ▼ │
│ ┌─────────────────┐ │
│ │ SP: 수렴 (합치기)│ │
│ └────────┬────────┘ │
│ ▼ │
│ ┌─────────────────┐ │
│ │ PO: 선택 (확정) │ → 문제가설.md │
│ └────────┬────────┘ │
│ ▼ │
│ ── 7-2. 문제 검증 인터뷰 (병렬) ── │
│ ┌────┐ ┌────┐ ┌────┐ ┌────┐ ┌────┐ │
│ │ PO │ │ SP │ │ DE │ │ AR │ │ AI │ ← 인터뷰 병렬 (5명) │
│ └─┬──┘ └─┬──┘ └─┬──┘ └─┬──┘ └─┬──┘ │
│ └───────┼──────┼──────┼──────┘ │
│ ▼ │
│ ── 7-3. 인터뷰 결과 취합 ── │
│ ┌─────────────────┐ │
│ │ SP: 결과 취합 │ → 문제검증인터뷰결과취합.md │
│ └────────┬────────┘ │
│ ▼ │
│ ── 7-4. 문제가설 피보팅 ── │
│ ┌─────────────────┐ │
│ │ PO: 가설 수정 │ → 문제가설.md (덮어쓰기) │
│ └────────┬────────┘ │
│ ▼ │
│ ── 7-5. 비즈니스 가치 도출 (발산-수렴-선택) ── │
│ ┌────┐ ┌────┐ ┌────┐ ┌────┐ ┌────┐ │
│ │ PO │ │ SP │ │ DE │ │ AR │ │ AI │ ← 발산 병렬 (5명) │
│ └─┬──┘ └─┬──┘ └─┬──┘ └─┬──┘ └─┬──┘ │
│ └───────┼──────┼──────┼──────┘ │
│ ▼ │
│ ┌─────────────────┐ │
│ │ SP: 수렴 (합치기)│ │
│ └────────┬────────┘ │
│ ▼ │
│ ┌─────────────────┐ │
│ │ PO: 선택 (확정) │ → 비즈니스가치.md │
│ └─────────────────┘ │
└──────────────────────────────────────────────────────────────┘
PO=product-owner, SP=service-planner, DE=domain-expert, AR=architect, AI=ai-engineer
Step 7-1. 문제가설 정의 (발산-수렴-선택)
7-1a. 발산 — 5WHY 수행 (병렬) → Agent: product-owner, service-planner, domain-expert, architect, ai-engineer
- TASK: 각 팀원이 자신의 전문 관점에서 현상문제 3개를 도출하고 각각 5WHY로 근본원인을 분석
- EXPECTED OUTCOME: 팀원별 5WHY 분석 결과 (팀원당 문제 3개 × 5WHY)
- CONTEXT:
docs/plan/define/고객분석.md,docs/plan/define/유저저니맵.md, 고객 경험 조사 데이터 전체 - 실행: 5개 에이전트를
Task(run_in_background=true)로 동시 실행
7-1b. 수렴 — 유사 항목 합치기 (순차) → Agent: service-planner
- TASK: 7-1a에서 도출된 5명의 5WHY 결과를 취합하고 유사한 문제와 근본원인을 그룹핑하여 다층적 근본원인 관점으로 재구조화
- EXPECTED OUTCOME: 수렴된 문제가설 후보 목록 (그룹핑된 문제 + 근본원인 + 출처 팀원 표기)
- CONTEXT: 7-1a 결과
7-1c. 선택 — 최종 문제가설 확정 (순차) → Agent: product-owner
- TASK: 수렴된 후보 중 핵심 문제 3개와 근본원인을 영향력·빈도·심각도 관점에서 선정하여 최종 문제가설로 확정
- EXPECTED OUTCOME:
docs/plan/define/문제가설.md— 문제 3개, 5WHY 분석, 다층적 근본원인 검토, 핵심 근본원인 선정
Step 7-2. 문제 검증 인터뷰 (병렬) → Agent: product-owner, service-planner, domain-expert, architect, ai-engineer
인터뷰 규모 설정: Step 7-2 시작 전, 문제검증 인터뷰 대상자 수를 사용자로부터 입력받습니다.
<!--ASK_USER-->{"title":"문제검증 인터뷰 규모 설정","questions":[ {"question":"문제검증 인터뷰 대상자 수를 입력해 주세요. (기본값: 10명)","type":"text","placeholder":"10"} ]}
<!--/ASK_USER-->사용자가 입력한 값을
{문제검증인터뷰수}로 사용합니다. 미입력 시 기본값 10을 적용합니다.
- TASK: 확정된 문제가설을 기반으로 {문제검증인터뷰수}명 대상 문제검증 인터뷰를 5명이 분담하여 병렬 수행
- EXPECTED OUTCOME:
docs/plan/define/문제검증인터뷰결과.md— {문제검증인터뷰수}명 개별 인터뷰 결과(중요도·불편도·근본원인 동의여부) - 실행: 5개 에이전트를
Task(run_in_background=true)로 동시 실행, 각 에이전트가 분담된 인터뷰 수만큼 수행 후 결과를 하나의 파일로 병합
Step 7-3. 인터뷰 결과 취합 (순차) → Agent: service-planner
- TASK: 수집된 전체 인터뷰 결과를 종합 분석하여 문제별 중요도/불편도 평균, 근본원인 동의율, 핵심 인사이트를 도출
- EXPECTED OUTCOME:
docs/plan/define/문제검증인터뷰결과취합.md— 인터뷰 결과 종합 취합(문제별 통계·근본원인 검증·핵심 인사이트)
Step 7-4. 문제가설 피보팅 (순차) → Agent: product-owner
- TASK: 인터뷰 결과 취합을 반영하여 중요도/불편도가 낮거나 동의율이 낮은 항목을 조정하고 새로 발견된 문제를 반영하여 문제가설을 수정
- EXPECTED OUTCOME:
docs/plan/define/문제가설.md— 피보팅된 문제가설(기존 파일 덮어쓰기), 변경 사항과 피보팅 근거를 파일 상단에 명시
Step 7-5. 비즈니스 가치 도출 (발산-수렴-선택)
7-5a. 발산 — 가치 도출 (병렬) → Agent: product-owner, service-planner, domain-expert, architect, ai-engineer
- TASK: 피보팅된 문제가설의 근본원인 해소 시 고객·회사 각각의 비즈니스 가치를 자신의 전문 관점에서 도출
- EXPECTED OUTCOME: 팀원별 비즈니스 가치 후보 (고객 측면 + 회사 측면)
- CONTEXT:
docs/plan/define/문제가설.md(피보팅 버전),docs/plan/define/문제검증인터뷰결과취합.md - 실행: 5개 에이전트를
Task(run_in_background=true)로 동시 실행
7-5b. 수렴 — 유사 항목 합치기 (순차) → Agent: service-planner
- TASK: 5명의 비즈니스 가치 후보를 취합하고 유사한 가치를 그룹핑하여 정리
- EXPECTED OUTCOME: 수렴된 비즈니스 가치 후보 목록 (고객 측면 + 회사 측면, 출처 팀원 표기)
- CONTEXT: 7-5a 결과
7-5c. 선택 — 최종 비즈니스 가치 확정 (순차) → Agent: product-owner
- TASK: 수렴된 후보 중 고객·회사 각각 가장 중요한 비즈니스 가치 3개 이하를 측정 가능한 지표와 연결하여 선정
- EXPECTED OUTCOME:
docs/plan/define/비즈니스가치.md— 고객/회사 측면 비즈니스 가치(각 3개 이하, 선정 근거 포함)
전체 산출물:
문제가설.md(피보팅 최종본),문제검증인터뷰결과.md,문제검증인터뷰결과취합.md,비즈니스가치.md
Step 8. 방향성 정의 → Agent: product-owner (/plan 활용)
- GUIDE:
{PLUGIN_DIR}/resources/guides/plan/08-direction-setting-guide.md - TASK: 검증된 문제들을 영향력·빈도·심각도·근본성·해결가능성 5가지 기준으로 평가하여 킹핀 문제를 선정하고,
'<고객유형>는 <목적>을 위하여 <원하는 것>이 필요하다.'형식의 Needs Statement로 방향성을 정의 - EXPECTED OUTCOME:
docs/plan/think/킹핀문제.md— 검증된 문제 리스트·인과관계·5가지 기준 평가·킹핀 문제 선정 /docs/plan/think/문제해결방향성.md— Needs Statement·상세 설명(고객유형·목적·원하는 것)
3단계: 솔루션 (Solution)
Step 9. 아이디어 발상 → Agent: product-owner, service-planner(리드), domain-expert, architect, ai-engineer, backend-developer, frontend-developer, qa-engineer, devops-engineer (/ralph 활용)
- GUIDE:
{PLUGIN_DIR}/resources/guides/plan/09-ideation-guide.md - TASK: 모든 팀원(9명)이 SCAMPER·Steal & Synthesize 기법으로 각자 Big Idea 3개, Little Win Idea 2개, Crazy Idea 1개를 도출(병렬)한 후, service-planner가 유사도 평가표(기능 70%/경험 30%)를 작성하여 유사도 0.7 이상 아이디어를 합쳐 솔루션 후보를 수렴
- EXPECTED OUTCOME:
docs/plan/think/솔루션탐색.md— 팀원별 아이디어 표 /docs/plan/think/솔루션후보.md— 수렴된 솔루션 후보(각 후보 상세 설명) - 실행: 솔루션 탐색은 9개 에이전트를
Task(run_in_background=true)로 동시 실행, 솔루션 수렴은 service-planner가 순차 수행
Step 10. 솔루션 선정 → Agent: product-owner(리드), service-planner, domain-expert, architect, ai-engineer, backend-developer, frontend-developer, qa-engineer, devops-engineer (/plan 활용)
- GUIDE:
{PLUGIN_DIR}/resources/guides/plan/10-solution-selection-guide.md - TASK: 모든 팀원(9명)이 비즈니스 가치(B) 3표·실현 가능성(F) 3표를 투표(병렬)한 후, product-owner가 결과를 집계하고 X축=실현가능성/Y축=비즈니스 영향도의 2x2 매트릭스로 시각화하여 핵심 솔루션 3개 이하를 선정
- EXPECTED OUTCOME:
docs/plan/think/솔루션평가.md— 투표 결과 집계표 /docs/plan/think/솔루션우선순위평가.svg— 우선순위 매트릭스 SVG /docs/plan/think/핵심솔루션.md— 선정된 핵심 솔루션(3개 이하, 상세 설명) - 실행: 투표는 9개 에이전트를
Task(run_in_background=true)로 동시 실행, 집계 및 선정은 product-owner가 순차 수행
4단계: 비즈니스 모델 (Business Model)
Step 11. 비즈니스 모델 설계 → Agent: product-owner (/plan 활용)
- GUIDE:
{PLUGIN_DIR}/resources/guides/plan/11-business-modeling-guide.md - TASK: Lean Canvas 프레임워크로 9개 영역(Problem·Customer Segments·UVP·Solution·Channels·Revenue Streams·Cost Structure·Key Metrics·Unfair Advantage)과 경쟁 분석·GTM 전략·3개년 재무 계획(손익계산서·BEP)을 포함한 비즈니스 모델을 설계
- EXPECTED OUTCOME:
docs/plan/think/비즈니스모델.md— Lean Canvas 9영역 전체·가격 전략·수익 전망·비용 구조·Key Metrics·경쟁 매트릭스·GTM 전략·재무 계획
Step 12. 발표자료 스크립트 → Agent: service-planner (/ralph 활용)
- GUIDE:
{PLUGIN_DIR}/resources/guides/plan/12-presentation-guide.md - TASK: 비즈니스 모델을 기반으로 린캔버스 9영역·경쟁 분석·GTM 전략·재무 계획을 10-15장으로 구성하고 장표별 핵심 메시지 3개 이하·비주얼 제안을 포함한 발표자료 스크립트를 작성
- EXPECTED OUTCOME:
docs/plan/think/서비스기획서스크립트.md— 10-15장 슬라이드 스크립트(각 장표 핵심 메시지 3개 이하, 장표 간---구분, 비주얼 제안 포함)
5단계: 제품 설계 (Product Design)
Step 13. 이벤트 스토밍 → Agent: architect(리드), product-owner, service-planner, domain-expert, ai-engineer, backend-developer, frontend-developer, qa-engineer, devops-engineer (/ralph 활용)
- GUIDE:
{PLUGIN_DIR}/resources/guides/plan/13-event-storming-guide.md - 실행 방식: 3단계(초안-리뷰-반영)로 수행합니다.
Step 13-1. 초안 작성 (순차) → Agent: architect
- TASK: DDD Event Storming 기법으로 핵심 솔루션의 시스템 이벤트 흐름을 분석하고, 주요 유저플로우 식별·연결도·시퀀스 다이어그램·마이크로서비스 정의를 PlantUML로 작성
- EXPECTED OUTCOME:
docs/plan/think/es/userflow.puml— 유저플로우 연결도 /docs/plan/think/es/{순번}-{유저플로우명}.puml— 각 유저플로우 시퀀스 다이어그램
Step 13-2. 팀 리뷰 (병렬) → Agent: product-owner, service-planner, domain-expert, ai-engineer, backend-developer, frontend-developer, qa-engineer, devops-engineer
- TASK: 13-1에서 작성된 이벤트 스토밍 초안을 각자의 전문성 관점에서 리뷰하고 의견을 제시
- product-owner: 비즈니스 가치·MVP 범위 관점에서 누락된 유저플로우나 이벤트 확인
- service-planner: 사용자 경험·서비스 흐름 관점에서 유저플로우 완성도 검토
- domain-expert: 도메인 규칙·규제·업계 관행 관점에서 정책/규칙 검증
- ai-engineer: AI 기회 발굴 — AI/ML 적용 가능한 이벤트·데이터 흐름 식별, AI 자동화·지능화 기회 제안
- backend-developer: 백엔드 구현 가능성·API 설계·데이터 처리 관점에서 기술적 타당성 검토
- frontend-developer: 사용자 인터랙션·화면 흐름 관점에서 프론트엔드 구현 이슈 식별
- qa-engineer: 테스트 용이성·예외 시나리오·경계값 관점에서 누락된 케이스 식별
- devops-engineer: 배포·운영·확장성 관점에서 서비스 분할 및 인프라 이슈 검토
- EXPECTED OUTCOME:
docs/plan/think/es/리뷰의견.md— 팀원별 리뷰 의견(관점·의견·수정 제안) - CONTEXT:
docs/plan/think/es/userflow.puml,docs/plan/think/es/*.puml - 실행: 8개 에이전트를
Task(run_in_background=true)로 동시 실행
Step 13-3. 의견 반영 및 업데이트 (순차) → Agent: architect
- TASK: 팀 리뷰 의견을 검토하고 타당한 의견을 반영하여 이벤트 스토밍 산출물을 업데이트
- EXPECTED OUTCOME: 기존
docs/plan/think/es/*.puml파일 업데이트(반영 사항 주석 추가),docs/plan/think/es/리뷰반영결과.md— 반영/미반영 판단 근거(ai-engineer AI 기회 발굴 의견 별도 섹션) - CONTEXT:
docs/plan/think/es/리뷰의견.md, 기존 이벤트 스토밍 산출물
Step 14. 유저스토리 작성 → Agent: service-planner(리드), product-owner, architect, ai-engineer, domain-expert (/ralph 활용)
- GUIDE:
14-user-stories-guide.md - 실행 방식: 3단계(초안-리뷰-반영)로 수행합니다.
Step 14-1. 초안 작성 (순차) → Agent: service-planner
- TASK: 이벤트 스토밍 결과를 기반으로 유저플로우→Epic, 이벤트→User Story, 커맨드→시나리오/Task, 정책/규칙→Acceptance Criteria 변환, UFR 포맷·우선순위·Story Points·Feature Story Map·스프린트 계획·비기능 요구사항을 포함한 유저스토리를 작성
- EXPECTED OUTCOME:
docs/plan/design/userstory.md— 마이크로서비스별 유저스토리(최소 20개 UFR)·사용자 역할·Feature Story Map·우선순위 매트릭스·스프린트 계획·비기능 요구사항·Definition of Done·리스크
Step 14-2. 검토 (병렬) → Agent: product-owner, architect, ai-engineer, domain-expert
- TASK: 14-1에서 작성된 유저스토리 초안을 각자의 전문성 관점에서 검토하고 의견을 제시
- product-owner: MVP 범위·비즈니스 우선순위 관점에서 우선순위(M/S/C) 적절성 검토, 누락된 비즈니스 요구사항 식별
- architect: 기술 실현 가능성·시스템 아키텍처 관점에서 Story Points 적절성 검토, 기술적 의존성·제약 사항 식별
- ai-engineer: AI/ML 적용 가능한 유저스토리 식별, AI 기능 관련 UFR 누락 여부 확인, AI 연동 요구사항 보완 제안
- domain-expert: 도메인 규칙·규제·업계 관행 관점에서 Acceptance Criteria 검증, 도메인 특화 요구사항 누락 확인
- EXPECTED OUTCOME:
docs/plan/design/userstory-리뷰의견.md— 검토자별 의견(관점·의견·수정 제안) - CONTEXT:
docs/plan/design/userstory.md,docs/plan/think/es/*.puml - 실행: 4개 에이전트를
Task(run_in_background=true)로 동시 실행
Step 14-3. 의견 반영 및 업데이트 (순차) → Agent: service-planner
- TASK: 검토 의견을 반영하여 유저스토리를 업데이트하고 반영/미반영 판단 근거를 기록
- EXPECTED OUTCOME:
docs/plan/design/userstory.md업데이트(기존 파일 덮어쓰기),docs/plan/design/userstory-리뷰반영결과.md— 반영/미반영 판단 근거(최종 UFR 최소 20개 확인) - CONTEXT:
docs/plan/design/userstory-리뷰의견.md, 기존 유저스토리
Step 15. UI/UX 설계 → Agent: service-planner (/ralph 활용)
<!--ASK_USER-->
{"title":"디자인 레퍼런스 입력 (선택)","questions":[ {"question":"참고할 디자인 레퍼런스(추천: https://wwit.design)가 있으시면 제공해 주세요. URL, 이미지 경로, 이미지 붙여넣기 모두 가능합니다. 없으면 '없음'을 입력해 주세요.","type":"text","placeholder":"없음"} ]}
<!--/ASK_USER-->- 사용자가 URL을 제공한 경우: 아래 레퍼런스 분석 워크플로우 실행 후 UI/UX 설계 진행
- 사용자가 이미지를 제공한 경우:
docs/plan/design/uiux/references/에 저장하고 Vision 에이전트로 디자인 분석 - 사용자가 '없음' 또는 미응답 시: 레퍼런스 없이 진행
Step 15-R. 레퍼런스 사이트 디자인 분석 (URL 제공 시에만 실행)
- Playwright로 사이트 접속 및 스크린샷 촬영
- 데스크톱 뷰포트(1280x800)로 주요 페이지 스크린샷 촬영
- 모바일 뷰포트(375x812)로 동일 페이지 스크린샷 촬영
- 스크린샷을
docs/plan/design/uiux/references/에 저장
- Playwright accessibility snapshot으로 페이지 구조 파악
- 네비게이션 구조, 컴포넌트 계층, 폼 요소 등 구조 정보 수집
- Vision 에이전트로 디자인 분석
- 촬영된 스크린샷을
oh-my-claudecode:vision에이전트에 전달 - 분석 항목: 컬러 팔레트, 레이아웃 패턴, 타이포그래피, 컴포넌트 스타일, 간격 시스템, 인터랙션 패턴
- 촬영된 스크린샷을
- 분석 결과 정리
docs/plan/design/uiux/references/레퍼런스분석.md에 분석 결과 저장- 이 파일을 후속 UI/UX 설계의 CONTEXT에 포함
- GUIDE:
15-uiux-design-guide.md - TASK: 유저스토리를 기반으로 디자인 원칙·정보 아키텍처·사용자 플로우·와이어프레임(최소 5개 화면)·컴포넌트 라이브러리·접근성(WCAG 2.1 AA)·스타일 가이드·인터랙션 디자인을 포함한 UI/UX 디자인 명세를 작성 (레퍼런스 분석 결과 있는 경우 디자인 톤·레이아웃·컴포넌트 스타일 반영)
- EXPECTED OUTCOME:
docs/plan/design/uiux/uiux.md— UI/UX 디자인 명세 전체 /docs/plan/design/uiux/style-guide.md— 스타일 가이드
6단계: 프로토타입 (Prototype)
Step 16. 프로토타입 개발 → Agent: frontend-developer (/ralph 활용)
<!--ASK_USER-->
{"title":"이미지 생성용 Gemini API Key (선택)","questions":[ {"question":"프로토타입에 이미지가 필요한 경우 AI로 생성할 수 있습니다. Gemini API Key를 입력해 주세요. 없으면 '없음'을 입력하세요. (https://aistudio.google.com/apikey 에서 발급)","type":"text","placeholder":"없음"} ]}
<!--/ASK_USER-->-
사용자가 API Key를 제공한 경우:
.npd/.env파일에GEMINI_API_KEY={입력값}저장 (.npd/는.gitignore에 포함되어 git에 업로드되지 않음) -
사용자가 '없음' 또는 미응답 시: 이미지 없이 진행 (placeholder 텍스트 사용)
-
GUIDE:
16-prototype-development-guide.md -
EXPECTED OUTCOME:
docs/plan/design/uiux/prototype/디렉토리 —common.css·common.js·{2자리번호}-{한글화면명}.html·테스트결과.md
Step 16-1. 공통 파일 개발 (순차)
- TASK: 스타일가이드를 기반으로 CSS 변수·Mobile First 레이아웃·접근성 유틸리티가 포함된
common.css와 Web Components 공통 UI·샘플 데이터·화면 전환·localStorage 유틸리티가 포함된common.js를 개발
Step 16-2. 화면별 개발-테스트 루프 (ralph 활용)
의존관계 분석 및 병렬 개발
UI/UX 설계서의 사용자 플로우를 분석하여 화면 간 의존관계를 파악하고, 독립적인 화면은 병렬로 개발함.
- 의존관계 분석: 사용자 플로우에서 화면 간 의존관계를 도출
- 독립 화면: 다른 화면의 데이터/상태에 의존하지 않는 화면 (예: 로그인, 회원가입, 소개)
- 의존 화면: 이전 화면의 결과가 필요한 화면 (예: 목록→상세, 장바구니→결제)
- 개발 레벨 그룹핑: 의존관계가 없는 화면끼리 같은 레벨로 그룹화
Level 1: [로그인] [회원가입] [소개] ← 병렬 개발 Level 2: [메인홈] [마이페이지] ← Level 1 완료 후 병렬 개발 Level 3: [상세] [결제] ← Level 2 완료 후 병렬 개발 - 병렬 개발: 같은 레벨의 화면들을 병렬 에이전트로 동시 개발 → 각 에이전트가 개발-테스트 사이클 수행
- 레벨 순차 진행: 현재 레벨의 모든 화면 완료 후 다음 레벨로 진행
화면 1개당 개발-테스트 사이클
- 개발: UI/UX 설계서의 와이어프레임과 일대일 매핑하여 HTML 작성
- Playwright 즉시 테스트:
browser_navigate로 해당 HTML 파일 열기browser_console_messages로 콘솔 에러 확인 → 에러 있으면 즉시 수정browser_snapshot으로 접근성 구조 확인browser_take_screenshot으로 UI 렌더링 상태 확인 (캡처 이미지는.temp디렉토리에 저장)- 모바일 뷰포트(
browser_resize375x812)로 반응형 확인 (캡처 이미지는.temp디렉토리에 저장)
- 수정: 에러/UI 이슈 발견 시 수정 후 재테스트
- 완료: 테스트 통과 후 해당 화면 완료 처리
Step 16-3. 통합 테스트 (Playwright 자동 검증)
모든 화면 개발 완료 후, Playwright로 전체 프로토타입을 자동 검증함.
캡처 이미지 저장 경로: 통합 테스트 중 촬영하는 모든 스크린샷은
.temp디렉토리에 저장합니다.
- 화면간 연결성 테스트: 각 화면의 모든 링크/버튼을
browser_click으로 클릭 → 올바른 페이지로 이동하는지 확인 - 화면별 기능 동작 테스트: 폼 입력(
browser_type), 버튼 클릭, 모달/드롭다운 동작 확인 - 데이터 일관성 테스트: 화면 간 전달되는 샘플 데이터가 일치하는지 확인
- 반응형 테스트: 데스크톱(1280x800) → 태블릿(768x1024) → 모바일(375x812)로 뷰포트 변경하며 레이아웃 확인 (각 뷰포트 스크린샷은
.temp디렉토리에 저장) - 콘솔 에러 전수 검사: 모든 화면에서
browser_console_messages에러 레벨 확인
테스트 결과를 테스트결과.md에 기록:
### 화면별 기능 동작
| 화면 | 기능/액션 | 예상 결과 | 실제 결과 | 상태 |
### 화면간 연결성
| 출발화면 | 연결방법 | 도착화면 | 상태 |
### 화면간 데이터 일관성
| 데이터 | 사용 화면 | 일관성 |
Step 16-4. 버그 수정 루프 (ralph 활용)
Step 16-3에서 발견된 실패 항목을 수정 → 재테스트 → 모두 통과할 때까지 반복함.
- 테스트결과.md의 실패/비정상 항목 확인
- 해당 HTML 파일 수정
- Playwright로 수정된 항목만 재테스트
- 모든 항목 통과 시 완료, 미통과 시 1번으로 복귀
Step 17. 사용자 플로우 프리젠테이션 → Agent: frontend-developer (/ralph 활용)
- GUIDE:
17-flow-presentation-guide.md - TASK: Playwright로 각 프로토타입 화면을 스크린샷 촬영(일련번호+한글 자막 오버레이)하고, 테스트결과.md의 화면간 연결성 데이터를 분석하여 3-5개 주요 플로우를 도출한 후, 3단 레이아웃(좌측 스텝 리스트/중앙 폰 프레임/우측 나레이션)의 인터랙티브 HTML 프리젠테이션을 개발
- EXPECTED OUTCOME:
docs/plan/design/uiux/prototype/screenshots/{번호}-{화면명}.png— 자막 포함 화면별 스크린샷 /docs/plan/design/uiux/prototype/flow-script.html— 사용자 플로우 인터랙티브 프리젠테이션
Step 18. 기획 완료 보고
## 기획 완료
### 생성된 산출물
#### define/ (정의 단계)
- docs/plan/define/MVP정의.md — MVP 주제 정의
- docs/plan/define/고객분석.md — 고객 분석 (JTBD)
- docs/plan/define/시장조사.md — 시장 조사
- docs/plan/define/고객경험단계.md — 고객경험 단계
- docs/plan/define/관찰결과.md — 관찰 조사 결과
- docs/plan/define/체험결과.md — 체험 조사 결과
- docs/plan/define/고객경험인터뷰결과.md — 고객 경험 인터뷰 결과
- docs/plan/define/고객경험인터뷰결과취합.md — 인터뷰 결과 취합
- docs/plan/define/유저저니맵.md — 고객 여정 맵
- docs/plan/define/유저저니맵.svg — 고객 여정 맵 시각화
- docs/plan/define/문제가설.md — 문제 가설 및 5WHY 분석
- docs/plan/define/문제검증인터뷰결과.md — 문제 검증 인터뷰
- docs/plan/define/문제검증인터뷰결과취합.md — 문제 검증 취합
- docs/plan/define/비즈니스가치.md — 비즈니스 가치
#### think/ (사고 단계)
- docs/plan/think/킹핀문제.md — 킹핀 문제 분석
- docs/plan/think/문제해결방향성.md — Needs Statement
- docs/plan/think/솔루션탐색.md — 솔루션 탐색 (팀원별)
- docs/plan/think/솔루션후보.md — 솔루션 후보 (수렴)
- docs/plan/think/솔루션평가.md — 솔루션 투표 평가
- docs/plan/think/솔루션우선순위평가.svg — 우선순위 매트릭스
- docs/plan/think/핵심솔루션.md — 핵심 솔루션
- docs/plan/think/비즈니스모델.md — 비즈니스 모델 (Lean Canvas)
- docs/plan/think/서비스기획서스크립트.md — 발표자료 스크립트
- docs/plan/think/es/userflow.puml — 유저플로우 연결도
- docs/plan/think/es/{순번}-{유저플로우명}.puml — 시퀀스 다이어그램
#### design/ (설계 단계)
- docs/plan/design/userstory.md — 유저스토리
- docs/plan/design/uiux/uiux.md — UI/UX 설계
- docs/plan/design/uiux/style-guide.md — 스타일 가이드
- docs/plan/design/uiux/prototype/*.html — 프로토타입
- docs/plan/design/uiux/prototype/screenshots/*.png — 화면 캡처 (자막 포함)
- docs/plan/design/uiux/prototype/flow-script.html — 사용자 플로우 프리젠테이션
### 다음 단계
`/npd:design` 으로 기술 설계를 시작하세요.
실행 지침
순차적 처리
- 다음 단계로 넘어가기 전에 각 스텝을 완료합니다
- 이전 산출물을 다음 스텝의 CONTEXT로 전달합니다
- 진행하기 전에 산출물 파일 생성을 검증합니다
진행 상황 보고
각 스텝 완료 후:
- 완료된 스텝 이름
- 생성된 파일 목록
- 다음 스텝 미리보기
부분 실행 지원
특정 단계만 실행 가능:
- "1-2단계만 실행해줘" (정의 + 문제 발견)
- "5단계부터 시작해줘" (제품 설계부터)
- "유저스토리만 작성해줘" → Step 14만 실행
에러 처리
스텝 실패 시:
- 에러를 명확히 보고
- 사용자에게 설명/입력 요청
- 실패한 스텝 재시도
- 중단된 지점부터 계속
MUST 규칙
| # | 규칙 |
|---|---|
| 1 | <!--ASK_USER--> 발견 시 AskUserQuestion 도구를 호출할 것 (텍스트 출력 금지) |
완료 조건
- 모든 워크플로우 단계(6단계 18스텝)가 정상 완료됨
- 산출물이
docs/plan/하위 디렉토리(define/think/design/)에 생성됨 - 프로토타입이
docs/plan/design/uiux/prototype/에 생성됨 - 검증 프로토콜을 통과함
- 에러 0건
검증 프로토콜
- 산출물 파일 존재 확인 (define/, think/, design/ 하위 전체 파일)
- 산출물 내용 품질 검증 (고객 조사 사용자 입력 규모 충족, UFR 20개 이상, Lean Canvas 9영역)
- 이전 Phase 산출물과의 일관성 확인 (각 Step의 CONTEXT 체인 연결)
상태 정리
완료 시 임시 상태 파일 정리. 산출물은 유지.
취소
사용자가 "cancelomc" 또는 "stopomc" 요청 시 현재 단계를 안전하게 중단하고 진행 상태를 보고함.
재개
마지막 완료된 Step부터 재시작. 이전 산출물이 존재하면 해당 단계는 건너뜀.
CLAUDE.md의## NPD 워크플로우 상태 > ### plan섹션에서진행 모드,마지막 완료 Step을 읽어 복원- 상태 섹션이 없으면 Step 0. 진행 모드 선택을 먼저 수행
- 복원된 마지막 완료 Step의 다음 Step부터 진행