PRD(Product Requirements Document／제품 요구사항 문서)는 무엇을 만들지, 그리고 왜인지를 정하는 문서입니다. 문제·범위·요구사항과 그 뒤의 결정을 모아 팀과 이해관계자가 같은 그림을 갖게 합니다. 약점은 그다음입니다——두세 스프린트면 PRD는 현실과 어긋나 드리프트합니다. 이 페이지는 구성과 양식, 그리고 드리프트를 막는 법을 다룹니다.
이 양식은 그대로 써도 됩니다. 가장 가치 있고 가장 빨리 낡는 건 4번——결정입니다. PRD는 로드맵과 그 아래 결정의 '보이는 끝'일 뿐입니다.
PRD는 승인된 날엔 옳습니다. 그다음 회의가 전제를 바꾸고 엣지 케이스가 결정을 뒤집는데——문서는 멈춰 있습니다. 12쪽짜리 문서를 손으로 따라 고치는 사람은 없습니다. 몇 주 뒤 AI 에이전트는 이미 성립하지 않는 스펙 위에서 작업을 시작합니다.
모든 요구사항과 결정이 7쪽의 한 줄이 아니라 참조 가능한 카드로——이유와 담당자를 담고 ID로 찾을 수 있습니다.
나중 결정이 앞 결정을 뒤집으면 의존 카드——즉 해당 PRD 부분——가 자동으로 stale. 문서가 3주간 조용히 거짓말하지 않습니다.
Claude Code·Cursor가 MCP로 PRD를 읽습니다——최신이거나 명시적으로 stale. 상태를 아무도 모르는 정적 문서가 아닙니다.
PRD는 승인된 날엔 옳다. 문제는 그 뒤 6주, 아무도 따라 고치지 않는다는 것이다.요구사항을 카드로 만들면, PRD가 스스로 "나 낡았다"고 알린다. 그게 Draftlize.
PRD는 "무엇을·왜"를 정하는 상위 문서, 스펙은 "어떻게 만들지"로 들어갑니다. PRD의 결정이 바뀌면 스펙도 바뀌어야 하며, 그 연동이 핵심입니다.
대개 PM이 엔지니어·디자인과 함께 작성합니다. 중요한 건 안의 결정을 나중에 되짚을 수 있고 이유가 남는 것입니다.
문제·범위·요구사항·결정이 전달되면 충분합니다. 길이보다, 뒤집혔을 때 알아챌 수 있는 구조가 중요합니다.
요구사항과 결정을 고정된 문단이 아니라 연결된 카드로 만드세요. 결정이 바뀌면 Draftlize가 의존하는 곳을 자동으로 stale 처리합니다. 이어서 의사결정 기록.
PRD를 연결된 카드로 쓰면 각 요구사항이 참조 가능해집니다. 결정이 바뀌면 해당 부분을 자동 stale——PRD 드리프트는 끝입니다.
$5 무료로 시작하기