prd-generatorlisted

# PRD 작성 (Layer 1) ## 이 스킬의 목적 PRD는 **"무엇을 만들 것인가"**에 대한 합의문이다. 여기서 정의한 요구사항 하나하나가 뒤에서 이렇게 흘러간다. ``` PRD의 요구사항 FR-007 → 아키텍처에서 어느 컴포넌트가 책임지는지 결정 (Layer 2) → 태스크로 쪼개져 구현 (Layer 3~5) → 수용 기준이 그대로 검증 항목이 됨 (Layer 4 품질 게이트) ``` 그래서 이 문서의 품질은 "읽기 좋은가"가 아니라 **"나중에 기계적으로 추적하고 검증할 수 있는가"**로 판정된다. "사용자가 편리하게 로그인할 수 있다" 같은 문장은 읽기엔 좋지만, 태스크로 쪼갤 수도 없고 통과 여부를 판정할 수도 없다. 그런 문장이 PRD에 남으면 Layer 4의 task validation 단계에서 검증자가 무엇을 확인해야 할지 몰라 그냥 통과시키게 된다. ### 여기서 하는 일과 하지 않는 일 | 하지 않는 것 | 어디서 하는가 | |---|---| | 기술 스택, 프레임워크, DB, 배포 방식 | TRD (`trd-generator`) | | 테이블 설계, API 엔드포인트, 컴포넌트 구조 | Layer 2 아키텍처 | | 개발 순서, 일정, 태스크 분할 | Layer 3 마스터 플랜 | | 화면 픽셀 디자인 | 별도 디자인 작업 | PRD와 TRD를 나누는 이유는 형식이 아니다. **요구사항은 기술 선택보다 오래 살기 때문**이다. "결제 기능이 필요하다"는 3년 뒤에도 유효하지만 "Stripe를 쓴다"는 6개월 만에 바뀔 수 있다. 둘을 한 문서에 섞으면 기술을 바꿀 때 요구사항까지 함께 흔들리고, 무엇이 합의된 것이고 무엇이 구현 선택이었는지 아무도 구별하지 못하게 된다. 다만 요구사항이 특정 기술을 **강제하는 제약**이라면(예: "관공서 납품이라 국내 리전에 저장해야 함) 그건 비기능 요구사항으로 PRD에 적는다. 선택이 아니라 제약이기 때문이다. 판단 기준은 이것이다 — **"이걸 다른 걸로 바꿔도 사용자에게 약속한 것이 지켜지는가?"** 지켜지면 기술 선택(TRD), 안 지켜지면 제약(PRD). --- ## 1단계. 입력 확보 먼저 `docs/IDEA.md` 가 있는지 확인한다. 있으면 그것이 주 입력이다. **IDEA.md 가 있는 경우** — 전부 읽고, 특히 **'미결 사항'과 '(가정)' 표기를 최우선으로 처리한다.** 아이디어 단계에서 미뤄 둔 결정이 PRD에 그대로 넘어오면, 요구사항이 가정 위에 세워진다. 그 가정이 틀어지면 요구사항 절반이 무효가 된다. 미결 항목마다 아래 넷 중 하나로 처리하고, 어느 쪽인지 문서에 남긴다. 1. **지금 결정한다** — 사용자에게 선택지와 함께 묻는다. 요구사항의 존재 여부를 가르는 것이면 반드시 여기에 해당한다. 2. **가정으로 확정하고 표시한다** — 세부 사항이면 합리적 값으로 정하고 `(가정)` 표기를 유지한다. 3. **범위 밖으로 밀