운영자의 의도가 채팅 세션 바깥에 살아 있는 단일 진실원. PRD가 기획서가 아니라 mind의 영속화 표면인 이유, 무엇을 담고 빼는지, 누적 게이트 패턴, 그리고 PRD를 살아 있게 하는 법.

이 시리즈의 처음 9편은 Alice가 무엇인가에 대한 글이었다. 페르소나·메모리·스킬·훅·멀티에이전트·검증·토큰 경제·세션 프로토콜. 모두 시스템 안쪽에 사는 것들이다.

이어지는 3편은 Alice를 통해 흘러가는 일 자체에 대한 글이다. 코드를 시작하기 전 의도의 모양, 코드가 끝났는지 판정하는 게이트, 그리고 운영자가 키보드에 손을 얹지 않아도 그 둘이 돌아가게 만드는 루프.

그 첫 글이 이것이다. PRD.

0. 출발 전제 — 코드는 가장 마지막에 쓴다

대부분의 운영자가 코드부터 시작한다. 에디터를 열고, 함수를 쓰고, 돌려 본다.

이 패턴은 일이 한나절을 넘어가는 순간 무너진다. 어제 쓴 코드는 자신이 왜 존재하는지 기억하지 못한다. 내일의 세션은 무엇이 "완료"로 카운트되는지 모른다. 팀 리드가 한 조각을 승인하고, 몇 주 뒤 그 조각은 더 이상 전체에 맞지 않는다.

문제는 코드가 아니다. 문제는 의도가 어디에도 영속적으로 기록되어 있지 않다는 점이다. 운영자는 자기 머릿속에, AI는 컨텍스트 윈도우의 파편에 그 의도를 들고 있었는데 — 두 표면은 모두 휘발된다.

PRD — Product Requirement Document — 가 그 답이다. 단순 기획 문서가 아니다. 운영자의 의도가 세션 바깥에 사는 표면, 다음 세션과 다음 협업자가 다시 묻지 않고 읽을 수 있는 표면이다. 의도는 기록되지 않으면 반드시 사라지기 때문이다.

1. PRD가 없을 때 무엇이 무너지는가

운영자가 직접 겪었거나, 다른 사람의 인계를 받으면서 본 패턴 몇 가지.

결정의 부패. 어떤 선택이 채팅 세션에서 내려졌다. 3주 뒤 — 운영자 본인을 포함해 — 아무도 왜 그 선택을 했는지 기억하지 못한다. 코드가 되돌아가거나, 표류하거나, 매 세션마다 같은 논쟁을 다시 한다.
스코프 드리프트. "이왕 하는 김에"가 슬그머니 끼어든다. 한 조각이 출시될 즈음에는 한 가지 대신 네 가지를 하고 있고, 그 네 가지 중 어느 것도 제대로 검토되지 않았다.
완료 정의의 붕괴. 누군가가 "기능이 들어갔습니다"라고 보고한다. 팀 리드가 묻는다 — "어떤 의미로?" 빌드? 테스트? 라이브? 검토 통과? 모든 답이 절반쯤 yes고, 대화는 빙빙 돈다.
온보딩의 붕괴. 새 협업자 — 다른 에이전트, 다른 팀원, 새 컨텍스트의 미래의 Alice — 가 들어갈 진입점이 없다. 그들은 코드에서 의도를 역공학으로 추출하게 되고, 그건 정확히 운영자가 비용을 들여 피하려던 루프다.

공통의 실은 1편 왜 Alice인가가 던진 그 문장과 같다. 운영자의 mind — 코드 뒤의 목적 — 가 세션 경계를 넘지 못하고 있다는 것.

2. PRD는 mind를 영속화한 표면이다

PRD의 역할은 좁고 분명하다. 작업을 계획하지 않는다. 담당자를 배정하지 않는다. 진척을 추적하지 않는다. 그것들은 다른 문서가 한다.

PRD는 한 가지 질문에 답한다. 무엇을 만들고 있는가, 그리고 무엇이 만들어진 것으로 카운트되는가.

레이어	담는 내용	왜 여기에 들어가는가
제품 개요	운영자가 한 호흡에 소리 내 읽을 수 있는 한 문단	운영자가 목적을 한 호흡에 말할 수 있게 강제
타깃 사용자	누구를 위한 것이고, 그 사람이 무엇을 얻고 떠나는가	이후 모든 결정의 필터 — 이 사용자에게 봉사하지 않는 기능은 잘라낸다
기능 요구사항	시스템이 해야 할 일	번호 매김. 각 항목 테스트 가능.
비기능 요구사항	성능·보안·접근성의 하한선	같은 번호 규율. "Lighthouse Perf ≥ 90"이 "빨라야 함"을 이긴다.
마일스톤	M0 → M1 → M2 와 각 단계가 해제하는 것	길의 모양이지, 작업 분해가 아니다
Release gates	각 마일스톤이 라이브로 카운트되기 위한 누적 기준	아래 §4 참조
미해결 질문	명시적으로 아직 결정되지 않은 것들	가장 덜 쓰이는 섹션. 보이는 미결 > 보이지 않는 미결.

이 목록에 없는 것을 보라. 작업 목록 없고, 일일 로그 없고, 누가 무엇을 했는지 없다. 그것들은 매 세션 바뀐다. PRD는 의도가 바뀔 때만 바뀌고, 그건 훨씬 느리다.

PRD는 도착점을 기술한다. 나머지 모든 것은 가는 길을 기술한다.

3. 무엇을 넣고, 무엇은 빼는가

PRD를 40페이지짜리로 키웠던 시기와, 엽서 한 장에 담을 수 있던 시기를 다 거친 뒤 운영자가 수렴한 규칙:

PRD에 넣는다: 그 줄을 바꾸면 시스템이 무엇인지 자체가 바뀐다면. 예 — "i18n 필수, 6 locale," "다운로드는 SHA-256을 표기해야 함," "운영자 실명은 어디에도 노출 금지."

PRD에 넣지 않는다: 그 줄을 바꿔도 시스템이 어떻게 만들어지는가만 바뀐다면. 예 — "빌드는 pnpm," "UI primitive는 shadcn," "커밋 메시지는 [devAlice] prefix."

두 번째 목록은 CLAUDE.md나 README, 또는 도구 관련 문서에 산다. PRD가 아니다.

이 분리의 이유는 미학이 아니다. 수명이다. PRD의 줄들은 1년을 넘겨야 한다. 빌드 시스템 관련 줄들은 두 분기를 못 넘길 수도 있다. 다른 문서에 두면 각자가 자기 속도로 부패해도 다른 쪽을 끌어내리지 않는다.

4. 누적 게이트 패턴

운영자가 PRD에서 가장 유용하게 써 온 패턴이 누적형 release gate 섹션이다.

모양:

게이트 0: M0 출시 (임시 도메인)
  - 빌드 통과
  - 카테고리 4 라우트 렌더
  - 카테고리당 시드 1편
  - ESLint clean

게이트 1: 컴플라이언스 (게시 직전 필수)
  - Privacy Policy (ko + en)
  - 컨텐츠 라이선스 (CC BY)
  - 코드 라이선스 (MIT)
  - About 페이지
  - ...

게이트 2: 인프라
  - 자체 도메인 연결
  - SSL 활성 (자동)
  - 프로덕션 env 설정
  - ...

게이트 3: 보안
  - 시크릿 하드코딩 없음
  - .env.example 모든 키 명시
  - 사용자 테이블 RLS 활성
  - ...

... 게이트 10

각 게이트는 표다. 각 행은 [항목 | 상태 | 비고]. 상태는 다섯 중 하나 — ✅ 통과 / ⏳ 진행 중 / 🔒 운영자 대기 / ❌ 미시작 / — 해당 없음.

이 패턴이 작동하는 이유 세 가지.

누적. 게이트 2는 게이트 1이 통과한 상태를 가정한다. 게이트 9는 0~8이 통과한 상태를 가정한다. 길의 모양이 문서에 내장되어 있다. "어떤 순서로?"를 묻는 사람이 없어진다 — 문서가 답한다.

원자 단위 행. 한 행은 통과거나 아니거나다. "거의 동작함"은 상태가 아니다. 이 규율이 운영자에게 모호한 항목 ("성능 괜찮음")을 체크 가능한 행 ("Lighthouse Performance ≥ 90, 기준 5 페이지")으로 쪼개도록 강제한다.

행 단위 가시 상태. 운영자가 산문을 읽지 않아도 프로젝트 위치를 안다. 컬럼을 훑어 — ✅ 개수 vs 🔒 개수 — 그림이 즉시 나온다.

팀 리드가 매 세션 가장 먼저 읽는 섹션이다. 그리고 이 섹션이 11편 Release gates와 12편 Ralph loop를 굴린다.

5. PRD와 일회성 plan은 다르다

운영자들은 종종 PRD와 세션 단위 plan을 혼동한다. 다르다. 사는 시간 단위가 다르다.

문서	시간 단위	무엇이 이것을 바꾸는가
PRD	개월	운영자가 무엇이 제품인지를 결정
PLAN.md	일~주	운영자가 한 조각을 어떻게 만들지 결정
HANDOFF.md	한 세션	직전 세션이 다음 세션에 남기는 메모
TASK_BOARD	시간~일	활성 스프린트의 작업 분해
Lessons-learned	개월, append-only	시스템이 반복하지 않게 하고 싶은 실수

의도의 한 줄이 이들 사이를 떠돌면 — 어느 날은 HANDOFF에, 다음 날은 PLAN에, 그 다음 날은 채팅 세션에 — 절대 누적되지 않는다. 같은 의도는 하나의 일관된 자리에서 표현될 수 있어야 한다. PRD가 그 자리다.

세션이 시작되면 Alice는 PRD.md를 가장 먼저 읽고, 그 다음 HANDOFF.md, 그 다음 PLAN.md. 읽기가 누적된다. PRD는 무엇이 카운트되는가를 정하고, HANDOFF는 운영자가 어디까지 했는가를 말하고, PLAN은 이번 조각에서 무엇이 일어나는가를 말한다.

6. PRD를 살아 있게 유지하는 법

부패한 PRD는 PRD가 없는 것보다 나쁘다. 모두가 그것을 계속 읽고, 그 stale한 의도에 따라 행동하기 때문이다. 운영자가 굴리는 습관 세 가지.

파일 안에서 버전 관리. 파일 상단: v1.0 → v1.1 → v1.2. 각 버전마다 변경 한 줄 메모. 현재 버전은 가장 마지막 줄. 별도 changelog 파일을 두지 않는다.

미해결 질문 섹션은 필수. 운영자가 쓰는 모든 PRD에는 "미해결 질문" 섹션이 있고, 활성 개발 동안 절대 비지 않는다. 그 섹션이 비는 날은 프로젝트가 끝났거나, 누군가 결정을 머릿속에 숨기고 있는 날이다.

마일스톤마다 상태 검토. 한 마일스톤이 닫힐 때, 전체 게이트 표를 한 번 훑는다. 마일스톤 동안 ✅로 옮겨간 항목은 승격. 손도 못 댄 항목은 미해결 질문 섹션으로 이주. PRD는 현재 의도의 스냅샷이지, 과거 의도의 스냅샷이 아니다.

7. 함정

운영자가 실전에서 PRD가 무너지는 걸 본 패턴들.

7.1 마케팅 문구로서의 PRD

"즐거운 UX", "세계 최고 수준의 성능" 같은 줄. 그 줄 안에서 테스트 가능한 게 없다. 지운다. "성능"이 중요하다면 "Lighthouse Performance ≥ 90, 모바일, 기준 5 페이지"로 쓴다.

7.2 작업 목록으로서의 PRD

모든 줄이 동사로 시작. "X 구현. Y 빌드. Z 연결." 그건 작업 보드지 PRD가 아니다. PRD의 줄들은 시스템을 기술한다 — 그것이 무엇인지, 무엇을 해야 하는지 — 그것을 만드는 작업이 아니다.

7.3 손보지 않는 PRD

PRD 상단에 v1.0이 박혀 있는데 마일스톤은 M3다. 결정이 채팅 세션에서 일어나고 여기로 돌아오지 않았거나, 프로젝트가 stale한 의도 위에 표류하고 있는 것. 둘 다 경고 신호.

7.4 PRD가 아니라 채팅에 사는 결정

팀 리드가 슬랙 메시지나 세션 답장에서 무언가를 승인한다. 2주 뒤 아무도 이유를 기억하지 못한다. PRD를 바꾸는 결정은 세션이 끝나기 전에 PRD에 들어간다. 그게 승인의 비용이다.

7.5 PRD 두 개

누군가 "진짜 PRD"와 "요약 PRD"를 따로 쓰거나, "한국어 PRD"와 "영어 PRD"가 표류한다. 하나만 골라라. 다국어 표면은 사용자용이고, PRD는 팀용이라 한 언어·한 파일에 산다.

다운로드 — PRD 템플릿

바로 복사해 쓰는 PRD 템플릿: 작업 범위, 글로벌 제약, 검증 명령, 결정 권한 매트릭스, 항목별 완료 기준. 이 글이 설명한 형태를 한 파일로.

PRD-code.md

shasum -a 256 PRD-code.md
# 기대값: 1c41c0e61b3dd027fa261e10a8b1f06381e40ee3ce476c24a8df673acb310e7c

8. 한 원칙

운영자가 PRD를 다루는 전체 모양은 한 줄로 줄어든다.

"운영자의 mind가 세션 사이에 잃을 만한 것은 모두 PRD에 쓴다. 한 분기를 살아남지 못할 것은 모두 PRD 바깥에 둔다."

이 원칙을 지키면 PRD는 살아 있다. 지키지 않으면 — PRD는 이전에는 의도의 기록이었다가, 이후에는 아무도 읽지 않는 문서가 되고, 이후에는 오래된 결정의 묘지가 된다. 문서의 수명은 그것이 가장 마지막으로 작동한 날이 결정한다고 생각한다.

이것이 또한 다음 두 글로 가는 다리다. PRD는 도착점이 어디인가에 답한다. 11편 Release gates는 도착했는지 어떻게 아는가에 답한다. 12편 Ralph loop는 운영자가 손을 얹지 않고도 시스템이 그 길의 대부분을 어떻게 걷는가에 답한다.

이 셋이 함께, 운영자의 의도 — 1편의 mind — 를 세션·일·협업자의 경계를 넘어 시스템이 잃지 않고 운반할 수 있는 무언가로 바꾼다.

10. PRD — 코드 한 줄 쓰기 전에 결정되어야 하는 것