Manual 07

PRD 작성법 — 에이전트가 실행할 수 있는 명세

에이전트는 당신이 쓴 대로가 아니라 당신이 쓴 것을 해석한 대로 움직입니다. 결과 품질을 가장 크게 좌우하는 건 모델 선택이 아니라 명세의 명확도입니다.

왜 여전히 PRD가 필요한가

"AI한테 시키면 되는데 무슨 기획서냐"는 오해입니다. 사람 개발자에게 모호한 요청을 주면 질문이라도 돌아오지만, 에이전트는 모호함을 자의로 해석하고 그 혼란을 티 내지 않는 경향이 있습니다. PRD는 사람을 위한 형식이 아니라, 에이전트가 "무엇이 성공인지" 스스로 판정할 수 있게 만드는 실행 계약입니다.

최소 요소 6가지

목표(Objective) — 관찰 가능한 결과 하나. "개선해줘"가 아니라 "이 조건이 참이 되면 성공"
범위(Scope)와 비목표(Non-goals) — 이번에 하지 않는 것을 명시. 범위는 축소보다 확대가 훨씬 위험합니다
입력(Inputs) — 근거로 삼을 파일·URL·기존 결정. "알아서 찾아봐"는 환각의 씨앗입니다
쓰기 권한(Allowed writes) — 건드려도 되는 경로를 명시. 나머지는 기본적으로 금지
검증 기준(Verification) — 통과해야 할 정확한 명령어나 관찰 절차. "잘 작동해야 함"은 기준이 아닙니다
승인 지점(Approval required) — 비가역이거나 외부에 영향을 주는 지점은 사람 승인으로 명시

여섯 개 다 문장 하나씩이어도 됩니다. 길이가 아니라 빠짐이 없는지가 품질을 만듭니다.

나쁜 PRD → 좋은 PRD

나쁜 예

"로그인 페이지 좀 예쁘게 다듬고 버그도 있으면 고쳐줘."

→ "예쁘게"는 검증 불가. "버그도"는 범위가 무한대. 승인 지점도 없음.

좋은 예

"로그인 폼의 에러 메시지가 필드 옆이 아니라 페이지 하단에 뜨는 걸 필드 옆으로 옮긴다. 대상은 LoginForm.tsx뿐. 스타일 토큰은 기존 것만 사용. 완료 기준: 잘못된 비밀번호 입력 시 에러가 필드 아래 12px 안에 표시되고 기존 접근성 테스트가 통과. 배포는 별도 승인."

성공 기준을 검증 가능한 문장으로

"완료"는 에이전트의 주관적 판단이 아니라 외부에서 확인 가능한 조건이어야 합니다. "이 재현 절차를 실행했을 때 에러가 발생하지 않는다", "이 명령이 exit code 0을 반환한다", "이 텍스트가 페이지에 존재한다" 같은 문장으로 바꾸세요. 검증 방법은 매뉴얼 04 — 검증 게이트가 실제로 실행합니다.

작업 계약으로 굳히기

여러 도구(코딩 에이전트·상시 운영 에이전트·사람)에 걸친 작업이라면, PRD를 아래처럼 구조화된 계약으로 압축해두면 어떤 실행자가 맡아도 같은 기준으로 움직입니다.

{
  "objective": "관찰 가능한 결과 한 문장",
  "inputs": ["근거로 삼을 경로/URL"],
  "allowedWrites": ["건드려도 되는 경로"],
  "forbiddenActions": ["commit", "push", "deploy"],
  "verification": ["정확한 명령 또는 확인 절차"],
  "approvalRequired": ["비가역·외부 영향 행위"],
  "status": "ready | running | verifying | awaiting_approval | done"
}

필드 이름은 팀 사정에 맞게 바꿔도 됩니다. 중요한 건 모든 실행자가 같은 최소 형식을 받는다는 것 — 형식이 사람마다 다르면 경계도 매번 다시 협상해야 합니다.

흔한 실패

범위 없이 목표만 던지기 — "리팩터링 좀"은 파일 100개를 건드려도 "범위 안"입니다.
검증을 사람 눈으로 미루기 — "보기에 괜찮으면 됨"은 에이전트가 스스로 통과 판정을 내리게 둡니다.
승인 지점을 사후에 정하기 — 배포·발행·삭제처럼 되돌리기 어려운 지점은 PRD 작성 시점에 미리 박아야 합니다.
PRD와 실제 대화가 따로 놀기 — 채팅에서 조건을 바꿨다면 PRD도 같이 갱신하세요. 원본이 낡으면 다음 세션이 낡은 기준으로 검증합니다.

← 명령어·프롬프트 · 다음 장: 1인 기업의 집중과 스킬 →