이 단계에서 하는 것: 기획자(PM) 서브에이전트를 설정하고 회의록(
data/킥오프_회의록.md)을 바탕으로 머니노트의 요구사항을docs/PRD.md에 정리한다.docs/templates/PRD-템플릿.md양식을 사용한다. AI가 초안을 작성하고 회의록과 대조하면, 사람이 범위와 세부 사항을 결정해 PRD를 확정한다. 다음 단계로 넘길 것: 상태가 '확정'인 PRD. 이후 디자이너·DBA·아키텍트가 이 문서를 작업 기준으로 삼는다.
개발은 회의에서 나온 요구사항을 정리하는 데서 시작한다. 이 실습에서는 data/킥오프_회의록.md를 사용한다. 회의록의 "귀찮다", "한눈에 안 보인다" 같은 표현만으로는 기능이 완료되었는지 확인하기 어렵다. 따라서 구현 전에 기획자 서브에이전트에게 요구사항과 측정 가능한 완료 기준을 담은 PRD를 작성하도록 맡긴다. 사람은 회의록과 PRD를 대조하고, 아직 정해지지 않은 사항을 결정한다.
PRD는 docs/templates/PRD-템플릿.md의 양식에 따라 작성한다. 양식에는 머리(버전·상태·변경 이력)와 1 배경·목표, 2 사용자, 3 기능 요구(R 번호), 4 완료 기준(AC 번호, 정상·경계·실패), 5 범위 제외, 6 미결사항(Q 번호)의 여섯 절이 있다. 초안은 0.1, 사람이 확정하면 1.0으로 올린다. 양식을 통일하면 다음 역할도 필요한 요구사항을 같은 위치에서 찾을 수 있다.
CLAUDE.md와 docs/가이드/ 문서, 그리고 data/킥오프_회의록.md를 이미 읽은 상태다.docs/templates/PRD-템플릿.md를 한 번 열어 둔다. 여섯 절과 표 아래의 작성 규칙이 있다. 다음 단계의 지시에 이 경로를 쓴다.같은 대화창에서 기획자 서브에이전트를 먼저 만든다. 회의록을 PRD로 정리하는 일만 맡기고 코드 작성은 맡기지 않는다. 템플릿 경로를 지정해 AI가 양식과 작성 규칙을 읽고 역할 파일에 반영하도록 한다.
'기획자(PM)' 서브에이전트를 만들어줘. 회의록을 근거로 PRD를 만들고 관리하는 일만 하고, 코드·화면·DB 설계는 하지 않는다.- 어떤 PM인가: 머니노트의 PM. 팀이 개발과 검증에 사용할 수 있는 완료 기준을 담은 PRD를 작성한다. 결과를 확인할 수 없는 문장은 요구사항으로 확정하지 않는다. 다음 작업자(디자이너·DBA·개발자·QA)가 이 문서를 기준으로 일할 수 있게 작성한다- 일하는 순서: 입력에 나온 요구를 결정 여부와 상관없이 빠짐없이 나열하고 R1, R2… 번호를 붙인다 → '귀찮다·한눈에' 같은 모호한 표현은 측정 가능한 기준으로 바꾸고, 못 바꾸면 [미결]로 남긴다 → 서로 모순되는 요구는 [충돌]로 표시해 질문으로 만든다 → docs/templates/PRD-템플릿.md의 절과 표에 맞춰 PRD를 쓴다. 완료 기준은 정상·경계·실패로 나눠 쓴다- 하면 안 되는 것: 회의록에 없는 기능을 추가하지 않는다. 미결사항을 임의로 확정하지 않는다. 기술 스택과 화면 디자인은 여기서 정하지 않는다. 템플릿의 절과 열을 더하거나 빼지 않는다이렇게 나오면 성공: .claude/agents/ 아래에 기획자 파일을 만들겠다는 퍼미션 창이 뜨고, 승인하면 파일이 생긴다. 파일을 열어 템플릿 경로가 절차에 들어 있는지, "템플릿의 절과 열을 더하거나 빼지 않는다"가 금지에 있는지 본다. 이 두 줄이 없으면 PRD 모양이 사람마다 달라진다.
[중요] 여기서 Claude Code를 한 번 다시 띄운다.
/exit로 나가고claude를 다시 실행한다. 서브에이전트는 세션을 시작할 때 읽히므로, 만든 그 세션에서 바로 "기획자 서브에이전트로…"라고 하면 역할을 못 찾고(Agent type 'pm' not found) 범용 에이전트가 조용히 대신 일한다. 결과물이 나오기는 해서 알아채기 어렵다. 이후 장에서도 서브에이전트를 새로 만들면 같은 방법으로 다시 띄운다.
기획자 서브에이전트에게 회의록을 바탕으로 PRD 초안을 작성하도록 요청한다. 절차와 양식은 역할 파일과 템플릿에 지정했으므로 짧게 지시할 수 있다.
기획자 서브에이전트로 @data/킥오프_회의록.md를 읽고 머니노트 PRD 초안을 작성해 docs/PRD.md에 저장해줘.이렇게 나오면 성공: docs/PRD.md를 만들겠다는 퍼미션 창이 뜨고, 승인하면 파일이 생긴다. 여섯 절이 템플릿 순서대로 있고, 3절에 요구 30개 안팎이 R 번호와 확정·미확정 표시를 달고 있다. 1절 제약에 "다음 달 초 베타", "서버비 최소", "개발자 1명"이 있다. 6절에 질문이 10개 안팎 남아 있다 — 회의록이 정하지 않은 것들이다. 5절 범위 제외에는 회의록이 "나중에"로 미룬 것만 있다. 사람마다 요구 개수와 질문 수는 조금 다르다. 틀이 같으면 된다.
docs/PRD.md를 직접 읽으며 네 가지를 확인한다. 빠진 요구사항(회의록의 기능이 3절에 모두 있는가), 임의로 추가된 기능(회의록에 없는 기능이 들어갔는가), 모호한 문장([미결] 표시 없이 완료 여부를 판단하기 어려운 표현이 있는가), 범위 제외 항목(AI가 회의록에서 미루지 않은 기능까지 제외했는가)이다. 그다음 AI에게도 회의록과 대조하도록 요청한다.
PRD를 회의록과 대조해서, 빠진 요구와 임의로 추가된 내용을 표로 보여줘.이렇게 나오면 성공: 빠진 요구와 추가된 내용을 정리한 표가 나온다. "임의로 추가된 내용"에는 회의록에 직접 적히지 않은 완료 기준(AC)도 포함될 수 있다. 예를 들어 "금액이 0원이면 저장되지 않는다"는 조건은 기획자가 요구사항에서 도출한 실패 사례일 수 있다. 이 단계에서는 삭제하지 않고 목표·사용자 설명에 근거 없는 숫자나 역할이 있는지, 결정자를 임의로 추정했는지 확인한다. 수정할 항목은 다음 단계에서 결정한다.
회의록에 따라 아직 정하지 않은 세부 사항은 개발 리더가 결정한다. 6절의 질문을 범위 / 세부 결정 / 검토 표 처리의 세 묶음으로 정리해 한 번에 전달한다. 그러면 여러 질문을 주고받으며 결정이 누락되는 일을 줄일 수 있다.
개발 리더로서 결정했어. 아래대로 docs/PRD.md를 고치고 상태를 확정, 버전을 1.0으로 바꾸고 변경 이력에 한 줄 적어줘.
1. 범위는 회의록에서 오대표가 정한 그대로. 회원가입과 로그인, 수입·지출 기록, 월별 통계, AI 카테고리 추천, AI 월별 요약은 프리미엄만, 프리미엄 1회 결제. 이 여섯 가지만 1차다. 나중에 목록과 카카오·구글 로그인, 정기 구독, 환불, 화면 디자인 얘기는 범위 제외로.2. 세부 결정. 전부 회의록에 없는 결정이니 요구 문장 끝에 (개발 리더 결정)이라고 표시하고 완료 기준도 써줘. - 가입과 로그인은 이메일과 비밀번호 8자 이상. 가입 때 이메일 확인은 없다. - 메모는 선택이고 100자까지. 카테고리는 고정 목록에서 꼭 하나 고른다. 오늘과 이번 달은 한국 시간. - 거래 목록은 고른 달 거래를 최신 날짜부터. 통계는 달을 골라 보고 미래 달은 못 고른다. 남은 돈은 총수입 빼기 총지출이고 음수면 음수로. - AI 추천은 메모를 적으면 추천 카테고리를 선택란에 채워 두고 사용자가 바꿀 수 있다. 10초 안에 안 오거나 실패하면 기타, 수입이면 기타수입을 채우고 못 받았다고 알린다. - AI 월별 요약은 회의록의 '한 줄'이 아니라 두 문장 이내로. 지난달 기록이 있으면 지난달 대비 증감을 넣고 없으면 이번 달만. 실패하면 안내한다. - 무료 사용자의 요약 자리에는 프리미엄으로 가는 버튼 하나와 한 줄 설명만. 결제가 실패하거나 취소되면 무료 그대로 두고 안내. 이미 프리미엄이면 버튼 없이 요약이 바로.3. 회의록에 없는 문장은 회의록 표현으로 고치거나 지워. 미확정은 남기지 말고, 화면·데이터·API가 정할 것은 '뒤 단계'로, 그 밖은 범위 밖으로 옮겨. 나머지는 템플릿 규칙대로.
바꾼 뒤 변경 내역을 표로 보여줘.위 지시에는 세 가지 의도가 있다. 첫째, PRD마다 R 번호가 달라질 수 있으므로 기능을 번호 대신 이름으로 지정한다. 둘째, 비밀번호 8자·메모 100자·대기 시간 10초·미래 달·기타수입처럼 회의록에 없지만 뒤 단계의 DB·API가 쓰는 값은 개발 리더가 정하고 "(개발 리더 결정)"으로 표시한다 — "상식으로 알겠지" 하고 빼면 AI는 채우지 않고 질문으로 넘기거나 빠뜨린다(두 명씩 세 가지 프롬프트로 확인한 결과다). 셋째, 버튼 이름·안내 문장 같은 화면 문구는 PRD에 적지 않는다. 템플릿 규칙이라 AI가 '안내한다'까지만 쓰고 문구는 화면 설계 단계에서 정한다. 범위 제외의 이유, 결정 없는 요구의 행방, 완료 기준과 요구 문장의 동기화도 템플릿 규칙이 맡는다 — 그래서 프롬프트가 짧다.
이렇게 나오면 성공: 변경 내역 표가 나온다(1장에서 "세션 동안 허용"을 골랐으면 덮어쓰기 승인 창은 뜨지 않는다). PRD를 다시 열어 본다 — 상태 '확정', 3절은 전부 '확정'이고 '미확정'이 없다, 세부 결정 문장 끝에 "(개발 리더 결정)"이 있다, 3절에 영역 열이 있고 기록 영역에 등록·수정·삭제·목록이 다 있다, 5절에 나중에 목록·카카오/구글 로그인·구독·환불·화면 디자인이 템플릿의 이유 셋 중 하나와 함께 있다. 6절에는 결정자가 '뒤 단계(화면|데이터|API)'인 질문만 남는다 — 열 개 넘게 남아도 정상이다. 그 질문은 화면기획서·ERD·API 명세 장에서 자연히 답한다. 결정자가 사람인 질문이 남았다면 그것만 한 줄로 더 정한다.
data/킥오프_회의록.md)을 근거로 docs/PRD.md가 생겼고, 템플릿의 여섯 절(배경·목표 / 사용자 / 기능 요구 / 완료 기준 / 범위 제외 / 미결사항)에 내용이 채워져 상태가 '확정'이다.docs/PRD.md가 맞는지 확인한다.다음 단계에서는 디자이너 서브에이전트에게 이 PRD를 바탕으로 화면기획서를 작성하도록 맡긴다.