SHWsgithub PRD 작성 스킬
디자이너 관점에서 사용자 경험·인터랙션·엣지케이스를 우선하되, 모든 섹션은 AI 코딩 툴이 추가 질문 없이 빌드 브리프로 쓸 수 있을 만큼 구체적으로 쓴다. 표·타입 정의·API 스펙 같은 구조화된 부분은 영어 용어를 그대로 쓰고, 설명 산문은 아래 §3 문체 원칙에 따라 자연스러운 한글로 쓴다.
0. 시작 질문
한 번에 하나씩, 대화하듯 묻는다:
- 어떤 문제를 해결하나요? 누가 가장 영향을 받나요?
- 주 사용자와 부 사용자는 누구인가요?
- 선호하는 기술 스택이 있나요? 없으면 문제 유형에 맞춰 제안한다.
- 하드 제약이 있나요? (플랫폼, 인증 체계, 오프라인 지원, 접근성 수준)
인자로 기능/프로젝트명이 주어졌으면 질문을 건너뛰고 그 이름을 작업 타이틀로 쓴다.
1. PRD 구조 (15섹션)
섹션은 필요한 만큼만 채운다 — 해당 없으면 패딩하지 말고 통째로 생략한다.
1. 개요 — 문제 정의(24문장) · 제안 솔루션(12문장) · AI Build Summary(명령형으로 "무엇을·어떤 스택으로·가장 힘든 제약은 무엇인지"를 압축한 한 문단, AI 프로토타이핑 툴이 제일 먼저 읽는 부분)
2. 목표 & 성공 지표 — 핵심 목표 1개, 측정 가능한 지표 1~3개, 안티골 목록(성공에 포함되지 않는 것 — 스코프 관리에 필수)
3. 스코프 & 제약 — 포함/제외 범위, 플랫폼·인증·접근성 등급(WCAG AA/AAA)·오프라인 지원 여부·성능 요구·데이터 규제 요건
4. JTBD (Jobs to Be Done) — "[상황]일 때, [동기]하고 싶다, 그래서 [기대 결과]를 얻는다" 형식. 빈도·중요도 순 2~5개.
| 우선순위 | Job Statement |
|---|---|
| 1 | ... |
5. 유저 스토리 — 각 스토리는 §4 Job과 §13 수용 기준에 교차 참조된다.
| ID | 역할 | 액션 | 효익 | JTBD Ref |
|---|---|---|---|---|
| US1 | J1 |
6. 경험 설계 — 인터랙션 모델·화면/상태 목록(빈 상태·에러 상태·로딩 상태 포함)·접근성 노트(키보드 탐색·스크린리더·색 대비)
7. 컴포넌트 인벤토리 — v0/Lovable 같은 컴포넌트 단위 AI 툴이 바로 쓸 수 있는 평면 목록
| 컴포넌트 | 타입 | 설명 | 관련 스토리 |
|---|
8. 데이터 모델 — TypeScript interface로 정의 (스택이 TS가 아니면 JSON Schema나 평문 필드 설명)
9. API / 연동 스펙 — 엔드포인트 표 또는 BaaS 테이블 오퍼레이션
| Method | Path | 설명 | 인증 필요 | 응답 형태 |
|---|
10. 상태 관리 맵 — 어떤 상태가 어디(서버/로컬/URL/인증 컨텍스트/캐시)에 있고 왜인지
11. 기술 스택 추천 — 사용자 선호가 없으면 문제 유형 기반 기본안 제시, 레이어별 선택 이유 명시
12. 파일 구조 — 기능 코드용 ASCII 디렉토리 트리, 변경 없는 파일은 생략
13. 수용 기준 — 유저 스토리 1개당 체크리스트 1묶음. 이진 판정 가능하게("정상 동작" 금지, "인증 상태에서 HTTP 200과 아이템 목록 반환" 같이 구체적으로)
14. 미해결 질문 & 리스크 — 질문(오너 명시) · 리스크(완화책 명시) · 트레이드오프
15. 롤아웃 & 다음 단계 — MVP 스코프(포함/제외) · Phase 2+ 아이디어 · 승인 필요 대상 · 액션 아이템(오너·기한)
2. 작성 원칙
- 디자이너 관점: 어포던스·멘탈 모델·정보 위계를 먼저 생각하고, PM/엔지니어링이 이해할 언어로 번역한다
- 모든 결정에 "왜"를 함께 쓴다
- 접근성·에러 상태·빈 상태·오프라인 동작처럼 사용자가 놓치기 쉬운 것을 먼저 제안한다
- 산문보다 불릿, 장황함보다 간결함
- 생성 후 어느 섹션이든 더 깊이 파고들거나 스코프를 조정할 수 있다고 안내한다
3. 문체 원칙 — 자연스러운 한글
산문 섹션(§1 문제 정의·제안 솔루션, §6 경험 설계, §14 미해결 질문, §15 롤아웃 설명 등 자유 서술 구간)에만 적용한다. 표·타입 정의·API 스펙·ASCII 트리는 대상이 아니다.
4대 철칙
- 의미 불변 — 수치·고유명사·기술 용어·직접 인용은 100% 그대로 둔다
- 근거 기반 수정 — 아래 체크리스트에 실제로 걸리는 표현만 손댄다. 걸리지 않은 문장은 건드리지 않는다
- 장르 유지 — PRD는 실무 문서다. 에세이·마케팅 카피·블로그 톤으로 옮기지 않는다
- 과윤문 금지 — 산문 섹션에서 손댄 문장 비율이 체감상 30%를 넘으면 "이 정도까지 수정했습니다"라고 사용자에게 알린다. 50%를 넘길 정도면 원래 표현이 대부분 자연스러웠다는 뜻이니 되돌아본다
체크리스트 (걸리는 것만 수술적으로 고친다)
| 카테고리 | 예시 | 처방 |
|---|---|---|
| 번역투 | " |
능동태·간결형으로: " |
| 구조적 AI 패턴 | 기계적 "첫째/둘째/셋째" 나열, 불릿·이모지·볼드 과다 | 자연스러운 접속 또는 표로 대체 |
| AI 특유 관용구 | "결론적으로", "시사하는 바가 크다", "주목할 만하다", "혁신적인" | 삭제하거나 구체적 진술로 교체 |
| 수식·중복 | "매우", "정말", 동의어 이중 수식("완전히 전면적으로") | 하나만 남기거나 삭제 |
| 접속사 남발 | 문두 "또한/따라서/즉/나아가" 연속 사용 | 문장 합치기 또는 접속사 제거 |
| 형식명사 과다 | " |
서술어로 직접 교체 |
4. 생성 흐름
- §0 질문으로 컨텍스트 수집
- §1 구조로 전체 초안 작성 (해당 없는 섹션은 생략)
- 산문 섹션만 §3 체크리스트로 자체 검수, 걸린 표현만 수정
- 최종본 제시
- 놓쳤을 수 있는 것 제안: 접근성·에러 상태·빈 상태·오프라인 동작
- 섹션 드릴다운이나 스코프 조정 의향 확인