정리와 실습

핵심 요점

• 명세는 짧고 평이한 언어로 된 작업 노트다 — 무엇을 만들고 무엇을 안 만드는지. 동결하는 계약이 아니며, 한 페이지면 충분하다.
• 기능 이전에 문제와 그 문제를 가진 사람을 명확히 하고, 논골(non-goals)을 적어라. AI가 "도움이 되는" 추가 기능을 넣는 것에 맞서는 가장 날카로운 방어다.
• so that 절이 있는 유저 스토리와 구체적인 "Done When" 줄이 있는 작은 PRD는 의도를 테스트 가능하고 구축 가능한 동작으로 바꾼다.
• 데이터 모델을 일찍 못 박아라 — 필드 이름은 어디에나 새어 나간다 — 그리고 명세를 한 번에 하나씩 검증할 수 있는 바이브 크기 작업으로 쪼개라.
• 해법이 아니라 문제를 기술하라. 결과는 명세에서는 바꾸기 싸고 코드에서는 비싸다. 배워가면서 명세를 살아있게 유지하라.

해보기

묵혀둔 아이디어 하나를 골라 단일 AI 세션 안에서 한 페이지 명세로 바꿔라. 먼저 AI가 다섯 개의 날카로운 질문으로 당신을 인터뷰하게 한 다음 — 당신 자신의 언어로 — 문제, 사용자, 세 개의 유저 스토리(각각 so that 포함), 명시적인 논골 목록, 여섯 줄짜리 데이터 모델, 그리고 물리적으로 수행할 수 있는 "Done When" 줄 하나를 써라. SPEC.md로 저장하라. 좋은 명세의 시험: 내일 완전히 새로운 대화에 붙여 넣어도 AI가 정확히 무엇을 만들어야 할지 알 수 있어야 한다.

이 장의 프롬프트

나에게 막연한 아이디어가 있어: <한 줄 설명>.

내 제품 기획 파트너 역할을 해 줘. 먼저, 날카로운 질문 5개를
한 번에 하나씩 던져서 문제, 타깃 사용자, "완료"가 어떤 모습인지
명확히 해 줘. 아직 기능을 제안하지 마.

내가 답하면, 다음 섹션으로 한 페이지짜리 스펙 초안을 작성해 줘:
- 문제  - 사용자  - 목표
- 작업 범위 (v1)  - 비목표 (v1)
- 사용자 스토리 (각각 "~로서, ~하고 싶다, ~하기 위해")
- 데이터 모델 (필드의 짧은 목록)
- 완료 기준 (구체적이고 직접 수행 가능한 인수 테스트)

간결하게 — 한 페이지 이내로. 모호한 게 있으면, 가정하기 전에
물어봐. 모든 줄에 동의할 때까지 초안을 고칠게.