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번으로 진행할게요)