Show Me The Prd

Show Me The PRD for Codex — 선초안(Draft-First) PRD 생성

한 문장 아이디어 → 열린 탐침 1회 + 번호 카드 2회 → 4종 디자인 문서(+README) 완성 질문으로 사양을 다 채운 뒤 쓰는 게 아니라, 핵심 문제만 깊게 묻고 → 방향 결정 1콜 → 바로 초안 → 가정 일괄 확인으로 간다. 초안이 가장 좋은 질문 생성기다. 이 문서는 참고 문서가 아니라 실행 지시서다. Codex 채팅 환경에서 단계대로 실제로 진행한다.

아이디어: 사용자가 스킬을 부르면서 붙인 설명(이하 "아이디어"). 없으면 Turn 1의 첫 질문으로 시작한다.

먼저 읽기

• $PLUGIN_ROOT/shared/questioning-policy.md — 질문 정책(§1 공통 규칙 · §2 종료 규칙 · §A 채팅 번호 블록)
• $PLUGIN_ROOT/skills/show-me-the-prd/references/interview-guide.md — 인터뷰 방법론, 채팅 질문 설계, 바이브코더 대응
• $PLUGIN_ROOT/skills/show-me-the-prd/references/research-strategy.md — 리서치 라우팅, 배치 타이밍
• $PLUGIN_ROOT/skills/show-me-the-prd/references/document-templates.md — 문서 템플릿과 섹션 구조
• $PLUGIN_ROOT/skills/show-me-the-prd/references/domain-doc-sets.md — 4종 문서 동적 생성 절차 (도메인별)
• $PLUGIN_ROOT/skills/show-me-the-prd/references/design-reference-guide.md — UI 게이트 기준, 스타일 어휘, 레퍼런스 수집 절차 (UI 산출물일 때만)

핵심 원칙

1. 바이브코더 눈높이 — 기술 용어 금지. 모든 선택지에 설명 + 장단점 필수. (기술 용어 번역표는 interview-guide.md)
2. AI가 리드, 유저가 결정 — 유저가 아는 것(목적·대상·원하는 동작)은 질문으로 끌어내고, 모르는 것(기술·구조)은 AI가 조사해서 선택지로 제안.
3. 리서치 기반 — 하드코딩된 추천이 아닌, 실시간 리서치 근거 제시.
4. "진짜 제품" 지향 — 목업/로컬 데모가 아닌 실제 배포 가능한 수준의 기획.
5. 초안 먼저 — 데이터 모델·Phase 분리는 묻지 않고 설계해서 초안에 반영하고, 확인은 구체물로 받는다. (백지 질문보다 초안 교정이 정확하다는 A/B 검증 결과)

규칙 (정책: shared/questioning-policy.md §1·§2·§A + 아래 선초안 규칙)

• 질문 예산: 열린 탐침 1회(§2a 재탐침 +1) + 번호 카드 2콜(콜당 ≤4문항). 예산 초과가 필요해 보이면 질문 설계 실패다 — 기본값+가정 원장으로 돌려라. 예외: 사용자가 명시적으로 깊은 인터뷰를 요청한 경우만 해제.
• 사실 vs 결정: 조사(웹 검색/코드)로 알 수 있는 사실(현재 스택, 버전, 시장 관행, 외부 API 제약)은 묻지 않는다 — 조사해서 카드 옵션에 녹인다. 결정(목표·범위·트레이드오프·원하는 동작)만 사용자에게. 애매하면 결정으로 취급.
• 카드 질문(Turn 2·Turn 4)은 반드시 아래 §A 번호 블록으로 출력한다. 단 Turn 1의 핵심 문제 발굴은 열린 텍스트 질문으로 한다(과거 행동을 묻는 Mom Test식 — 객관식으로 가두지 않는다).
• 리서치 결과를 텍스트로 설명하지 않는다. 결과는 즉시 다음 카드의 선택지에 녹인다.
• 선택지 설명에 "뭔지 + 장점 + 단점". 추천 옵션은 (추천) + 1번. 기술 용어 대신 일상 비유.
• 가정 원장(assumption ledger): 작성 중 만난 미확정 지점은 둘로 나눈다 — 산출물 구조를 갈라놓는 blocking 결정은 질문 큐에 적립(Turn 4 카드에 합류), 그 외는 시장 일반 관행 기본값 채택 + 원장에 기록. 작성 도중 산발적으로 묻지 않는다 — 큐는 Turn 4 한 곳에서만 푼다.
• 중단 신호 존중 (§2c): 사용자가 "알아서 해줘"류로 답하면 남은 문항을 기본값+원장으로 돌리고 즉시 Turn 3 초안으로 직행한다.

Codex 렌더링 규칙 — 카드 질문의 채팅 치환 (shared/questioning-policy.md §A)

Codex CLI에는 객관식 카드 UI 도구가 없다. 결정이 필요한 카드 질문은 모두 채팅에 번호형 선택지 블록을 출력하고 사용자의 다음 자유 텍스트 답변을 읽는 §A 패턴으로 한다. 한 콜에 문항이 여러 개면 Q1·Q2… 로 묶어 한 메시지에 출력하고, 답은 "Q1-1, Q2-2"처럼 받는다.

(예시 프리뷰 — 구조화 정보를 보여줄 때만. 단순 선호 질문이면 생략)

Q1. <한 줄 질문>
  1. <추천안> (추천) — 무엇인지, 왜 좋은지, 트레이드오프
  2. <대안> — 무엇인지, 트레이드오프
  3. 문장으로 직접 적기
Q2. <한 줄 질문>
  1. ...
(여러 개 고를 수 있으면: "여러 개면 1,3처럼 적어주세요")
(답은 "Q1-1, Q2-2"처럼. 모르면 전부 1번으로 진행할게요)

• 추천안은 항상 1번. 각 선택지에 "뭔지 + 장점 + 단점"을 한 줄로. 기술 용어 대신 일상 비유.
• "잘 모르겠어요"는 별도 선택지로 만들지 말고 "모르면 1번으로 진행할게요" 문장으로 안내.
• 구조화된 결정(데이터 모델 / Phase / 기술 스택 비교)에는 선택지 위에 짧은 예시 프리뷰(ASCII 관계도·테이블·트리)를 먼저 보여준다 — 카드 UI의 preview 필드 대체.
• 채팅에서는 마크다운 테이블을 피하고, 생성하는 문서 안에서는 템플릿이 요구하는 테이블을 그대로 쓴다.
• 사용자는 번호/문장 아무거나로 답할 수 있게 가두지 않는다.

Turn 0: 사전 확인 (자동, 유저에게 묻지 않음)

리서치 보강용 스킬 의존성을 확인한다 (없어도 동작한다):

• 사용 가능한 스킬 목록에 docs-guide가 있으면 → 공식 문서 기반 기술 조사에 활용.
• insane-research가 있으면 → 종합 시장 리서치에 활용.
• insane-search가 있으면 → 디자인 레퍼런스 수집(Turn 2.5)에 활용.
• 없으면 → 빌트인 웹 검색/브라우저로 폴백 (기본 동작에 문제 없음).

라우팅 상세: $PLUGIN_ROOT/skills/show-me-the-prd/references/research-strategy.md.

동시에 UI 게이트를 판정한다: 아이디어(+이후 Turn 1 답변)로 산출물에 사용자 화면(웹/앱/랜딩/대시보드)이 있는지 본다. 백엔드/CLI/파이프라인/라이브러리면 UI 없음 — Turn 2의 스타일 문항과 Turn 2.5 전체를 생략한다. 부분 UI(예: API+간단 어드민)는 사용자가 디자인을 먼저 언급한 경우에만 UI 있음으로 취급. 판정 기준 상세: $PLUGIN_ROOT/skills/show-me-the-prd/references/design-reference-guide.md

Turn 1: 핵심 문제 발굴 (Mom Test식 열린 질문)

아이디어를 분석해 표면 기능 뒤의 **"진짜 문제"**를 끌어낸다. 이 Turn만큼은 깊게 — 선초안이 대체하지 못하는 유일한 단계다(A/B 검증에서 가장 깊은 잠재 니즈는 2차 탐침에서만 나왔다).

갭 분석 (내부 처리 — 유저에게 출력하지 않음)

아이디어에서 아래를 추출 시도하고, 추론 가능한 건 묻지 않는다:

도메인 감지 시 특화 결정을 Turn 2 재료로 고려: 이커머스(결제/배송/재고) · 소셜(팔로우/피드/신고) · 교육(진도/퀴즈/인증) · 금융(PG/환불/세금) · 생활·헬스(기록 주기/알림/공유). (도메인별 표: interview-guide.md)

질문 규칙

• 핵심 문제는 객관식이 아니라 열린 텍스트로, 과거 행동을 묻는다: "지금은 이 문제를 어떻게 해결하고 계세요?" · "최근에 가장 불편했던 순간을 한 장면으로 들려주세요." 가정형("이런 기능 쓰실래요?") 금지. "왜" 대신 "무엇/어떻게".
• 조기 종료 금지 (§2a): 첫 답이 표면적이면("그냥 기록 앱이요") 결론으로 받지 말고, 한 문장 반영한 뒤 한 번 더 구체적으로 탐침한다 — "그 방식에서 제일 막히거나 그만두게 된 지점이 언제였어요?". 기존 방식이 왜 안 되는지(진짜 문제)가 드러날 때까지.
• 과잉질문 가드 (§2c): 아이디어가 이미 문제를 구체적으로 설명했으면 탐침을 생략하고 바로 Turn 2로.
• 핵심 문제 + 원하는 결과가 잡히면 한 문장으로 반영·확정하고 Turn 2로.

아이디어가 비어 있으면 "어떤 문제 때문에 이 앱/서비스를 생각하게 되셨어요?" 한 질문으로 시작한다.

Turn 1 → Turn 2 전환 (리서치)

답변을 받으면 웹 검색으로 "{아이디어} app features best practices 2026" + "best tech stack for {플랫폼} {도메인} app 2026" 리서치 (docs-guide/insane-research가 있으면 활용). 텍스트로 설명하지 말고 즉시 Turn 2의 카드를 출력한다.

Turn 2: 방향 결정 카드 (§A 번호 블록 1콜, ≤4문항)

초안의 방향을 가르는 결정만 한 메시지에 배치한다. 추론으로 확정된 항목은 문항에서 뺀다 — 4문항을 채우는 게 목표가 아니다.

한 메시지에 Q1~Q4로 묶어 출력한다:

1. MVP 범위 — 리서치 기반 기능 조합 3개(최소/중간/풀). 각 조합에 포함 기능 + 복잡도(간단해요/좀 복잡해요/많이 복잡해요) 한 줄. 추천(최소 핵심)을 1번에.
2. 기술 방향 — 스택 후보 2~3개. 선택지 위에 비교 프리뷰(무료 시작 / AI 코딩 호환 / 커뮤니티 / 배포 난이도)를 짧게 먼저 보여준다.
3. 로그인 방식 — 1. 소셜 로그인 (추천 — 구글/카카오, 비밀번호 관리 불필요, 다만 의존) / 2. 이메일+비밀번호 (자유도 높지만 비밀번호 찾기까지 만들어야 함) / 3. 매직링크 (간편하지만 매번 이메일 열어야 함) / 4. 불필요 (나만 쓰면 가장 간단).
4. 플랫폼 확인 — 추론 결과를 기본값+확인형으로 ("모바일 웹으로 가정했어요 — 맞나요?"). 추론이 확실하면 이 문항은 빼고 원장에 기록.
5. 디자인 스타일 (UI 게이트 통과 시에만, 총 4문항 한도 내에서) — 사용자가 스타일을 이미 말했거나 레퍼런스 URL을 줬으면 이 문항은 빼고 그대로 쓴다. 아니면 도메인에 어울리는 스타일 3~4개(미니멀 / 네오브루탈 / 다크 / 기타 — 각각 일상 언어 설명)를 선택지로. 문항이 5개가 되면 우선순위 낮은 것(보통 4번 플랫폼 확인)을 원장으로 돌린다.

Q1. 첫 버전(MVP)에 어디까지 넣을까요?
  1. 최소 조합 (추천) — [기능 A, B] · 간단해요 · 빠르게 완성, 부가 기능은 나중에
  2. 중간 조합 — [기능 A, B, C] · 좀 복잡해요 · 시간이 더 걸림
  3. 풀 조합 — [A~E] · 많이 복잡해요 · 첫 버전엔 과함
Q2. 코드를 만들 때 쓸 도구(기술 스택)
  (프리뷰) 스택A: 무료 시작 O / AI 코딩 호환 높음 / 배포 쉬움 · 스택B: ... · 스택C: ...
  1. 스택A (추천) — ... 2. 스택B — ... 3. 스택C — ...
Q3. 로그인 방식  1. 소셜 (추천) — ... 2. 이메일+비밀번호 — ... 3. 매직링크 — ... 4. 불필요 — ...
Q4. 모바일 웹으로 가정했어요 — 맞나요?  1. 맞아요 (추천)  2. 데스크톱 웹  3. 네이티브 앱
(답은 "Q1-1, Q2-2, Q3-1, Q4-1"처럼. 모르면 전부 1번으로 진행할게요)

Turn 2.5: 디자인 레퍼런스 수집 (UI 게이트 통과 시에만, 질문 없음)

UI 없음이면 이 단계를 통째로 건너뛰고 Turn 3으로 직행한다.

UI 있음이면 카드 답의 스타일로 레퍼런스를 수집한다 — 절차 상세: $PLUGIN_ROOT/skills/show-me-the-prd/references/design-reference-guide.md

• 쿼리 = {서비스 도메인} + {스타일} (영문 변환) → Dribbble/Cosmos 등에서 이미지 6~8장 회수 (insane-search 있으면 그 엔진 우선, 없으면 브라우저 폴백)
• 비전 스크리닝 필수: 이미지를 직접 열어 스타일·도메인·화면종류(모바일/데스크톱) 부합을 판정, 상위 3~5장만 keep
• PRD/references/에 이미지 + sources.json(출처·라이선스 노트) 저장
• 사용자가 레퍼런스 URL을 직접 준 경우: 수집 대신 그 URL을 sources.json에 기록
• 전 소스 실패 시: 막지 말고 가정 원장에 "레퍼런스 미수집" 기록 후 진행

Turn 3: 초안 작성 (질문 없음)

카드 답을 받으면 즉시 현재 프로젝트 루트의 PRD/ 폴더에 5개 파일을 작성한다:

PRD/
├── 01_PRD.md            # 요구사항 (Product Requirements Document)
├── 02_DATA_MODEL.md     # 구조 (개념적 ERD)
├── 03_PHASES.md         # Phase 분리 계획 (Phase 1 = MVP, 2 = 확장, 3 = 고도화)
├── 04_PROJECT_SPEC.md   # 프로젝트 스펙 (AI 행동 규칙)
└── README.md            # 네비게이션

개수 4 + README = 5 파일 항상 출력(사용자 예측가능성의 본질). 4종이 어떤 4종인지는 도메인을 보고 동적으로 결정할 수 있다 — 4 차원(요구사항 / 구조 / 도메인 특화 / AI 행동 규칙) 슬롯을 도메인 키워드로 채워 즉석 정의. 도메인이 모호하면 위 기본 set. 절차: $PLUGIN_ROOT/skills/show-me-the-prd/references/domain-doc-sets.md. 단, 이 확인은 별도 질문으로 늘리지 말고 Turn 4 카드 문항 한도 안에서만 묻거나 원장에 기록한다.

문서 템플릿: $PLUGIN_ROOT/skills/show-me-the-prd/references/document-templates.md

핵심 규칙:

• 데이터 모델과 Phase 분리는 묻지 않고 설계해서 초안에 반영한다. (확인은 Turn 4에서 구체물로 받는다.)
• 모든 기술 선택에 "왜 이걸 골랐는지" 근거 포함 (리서치 결과 인용). Phase별 "진짜 제품" 체크리스트(실제 배포 + 실제 데이터 + 실제 로그인) 포함. 프로젝트 스펙에 "절대 하지 마(DO NOT)" 목록 반드시 포함.
• 레퍼런스 연결 (Turn 2.5 실행 시): PRD/01_PRD.md에 ## 디자인 방향 섹션을 추가 — 스타일 키워드 + keep한 레퍼런스 파일 경로/출처 링크 + 각 이미지에서 참고할 포인트 한 줄. "레퍼런스는 방향 합의용, 산출물에 재게시 금지" 한 줄 명시.
• 미확정 지점 처리:
  • 산출물 구조를 갈라놓는 blocking 결정 → 질문 큐에 적립 (Turn 4 카드에 합류)
  • 그 외 → 시장 일반 관행 기준 기본값 채택 + 가정 원장에 기록
• 가정 원장 규약: 가정이 반영된 문서 위치마다 > ⚠️ 가정: {내용} — 아니라면 알려주세요 인용 블록을 넣고, PRD/01_PRD.md 말미에 ## 가정 원장 섹션으로 전체 목록(번호 / 가정 내용 / 영향 문서 / 확인 여부)을 모은다.

Turn 4: 확인 카드 (§A 번호 블록 1콜, ≤4문항)

초안 위치를 한 줄로 알린 뒤 즉시 카드를 출력한다. 텍스트로 문서 내용을 다시 설명하지 않는다.

한 메시지에 Q1~Q4로 묶어 출력한다:

1. 데이터 모델 — 선택지 위에 ASCII 관계도 + 핵심 필드 목록 프리뷰. 1. 좋아요 (추천) / 2. 수정할 부분 있어요 (문장으로).
2. Phase 분리 — 선택지 위에 Phase별 기능 체크리스트 프리뷰. 1. 좋아요 (추천) / 2. 순서 변경 / 3. 합치기·나누기 (문장으로). 34. **가정 원장에서 틀렸을 때 영향이 큰 가정 12개** + Turn 3에서 적립된 blocking 큐 항목. 각각 기본값을 1번(추천)으로.

초안을 PRD/ 폴더에 썼어요 (01_PRD · 02_DATA_MODEL · 03_PHASES · 04_PROJECT_SPEC · README). 확인만 부탁드려요.

(프리뷰) [User] --1:N--> [Record] --1:N--> [Tag]   ·  User: email, name / Record: date, note ...
Q1. 데이터 구조를 이렇게 잡았는데 괜찮아요?
  1. 좋아요 (추천) — 일반적인 구조라 확장하기 좋음
  2. 수정할 부분이 있어요 — 바꾸고 싶은 곳을 문장으로
(프리뷰) Phase 1: [ ] 기록 [ ] 목록 · Phase 2: [ ] 알림 [ ] 공유 · Phase 3: [ ] 통계
Q2. 이렇게 나눠서 하나씩 완성하는 걸 추천해요.
  1. 좋아요 (추천)  2. 순서를 바꾸고 싶어요  3. Phase를 합치거나 나누고 싶어요 (문장으로)
Q3. ⚠️ 가정 #2 "기록은 하루 1회"로 잡았어요.  1. 맞아요 (추천)  2. 하루 여러 번  3. 문장으로
Q4. (blocking) 팀 공유가 있나요?  1. 없음, 나만 (추천)  2. 초대 링크로 공유  3. 문장으로
(답은 "Q1-1, Q2-1, Q3-2, Q4-1"처럼. 모르면 전부 1번으로 진행할게요)

수정 답변은 해당 문서에 반영하고 원장의 확인 여부를 갱신한다. 수정이 연쇄적으로 커지는 경우에만(구조 변경) 추가 확인 1회를 예외 허용한다.

Turn 5: 납품

교정 반영 후 마무리:

• 완성도 X/10 + 개선 포인트
• 잔여 가정 목록 — 확인받지 못한 원장 항목을 그대로 노출한다 (사용자가 나중에 훑고 고칠 수 있게. 어떤 인터뷰로도 못 잡는 잠재 항목의 유일한 방어선이다.)
• 문서 위치 + 다음 단계 가이드 (§A 번호 블록):
  1. Phase 1 바로 시작 — 이 PRD로 Phase 1 개발 시작 (시작 프롬프트 예시 제공). 골 기반 실행이 필요하면 goaljaby 스킬에 이 PRD 폴더를 넘기라고 안내 — 가정 원장과 PRD/references/는 goaljaby가 골 컨텍스트로 승계한다.
  2. SDD 도구로 넘기기 — Spec Kit 등에 PRD를 넘겨 더 상세한 구현 계획.
  3. 문서 수정 — 바꾸고 싶은 부분을 알려주세요.
• 레퍼런스 URL을 받은 경우, insane-design 스킬이 설치돼 있으면 그 URL로 CSS 수준 분석(analysis)이 가능함도 한 줄 안내.

완료 요약은 단순 선택 목록이 아니라 의도+이유 중심으로 ("로그인 제거 → 나만 쓸 거라 불필요"). 근거가 이후 개발 단계의 마이크로 결정에 반영된다.

Enhancement Mode (기존 기획 보강)

유저가 기존 기획 문서를 공유한 경우:

1. 문서를 읽는다.
2. 5 파일 기준으로 갭 분석 (빠진 섹션, 모호한 부분 식별).
3. 미확정 항목을 가정 원장으로 정리 — blocking만 질문 큐에.
4. Turn 1 탐침은 생략(§2c — 이미 충분한 건 묻지 않음). 필요하면 Turn 2 카드 1콜로 방향만 확정하고 바로 보강 초안 → Turn 4 확인 카드 1콜.
5. 보강된 5 파일 생성. 기존 의도는 보존하고 구조만 템플릿에 맞춰 정규화한다.

References

$PLUGIN_ROOT/skills/show-me-the-prd/references/: