3장. 기획 — 회의록을 요구사항으로, 그리고 범위 결정

이 장이 끝나면: 뒤죽박죽인 회의록에서 요구사항을 추려 PRD(제품 요구사항 문서)를 만들 수 있다. 그 일을 맡을 PM 역할 스킬 — 우리 AI 개발팀의 첫 팀원 — 이 프로젝트에 들어와 있다. 그리고 온티켓 첫 버전에 무엇을 넣고 무엇을 뺄지가 사람의 결정으로 확정되어, docs/PRD.md의 '범위 제외'에 이유와 함께 박혀 있다.

3.1 개념 — AI 시대에 기획 문서가 더 중요해진 이유

개발은 코딩이 아니라 결정에서 시작된다

온티켓 킥오프 회의가 끝났다. 오대표는 "예쁘고 신뢰감 있게", "3분 안에 결제", "나중엔 플랫폼으로" 같은 말을 쏟아냈고, 회의록에는 그 말들이 뒤섞여 적혀 있다. 이 상태로 "티켓 서비스 만들어줘"라고 AI에게 지시하면 어떻게 될까.

만들어는 진다. 그런데 무엇이 만들어질지는 아무도 모른다. 회의록에는 서로 부딪히는 요구(전부 다 넣고 싶다 vs 3일 안에), 정해지지 않은 것(환불 정책), 측정할 수 없는 말 (예쁘게, 편리하게)이 섞여 있기 때문이다. AI는 빈칸을 만나면 자기 마음대로 채운다. 그 결과물이 내가 원한 것과 다를 때, 우리는 그것을 "AI가 이상하게 만들었다"고 말하지만 — 사실은 내가 결정을 안 한 것이다.

이 대목을 조금 더 풀어 보자. 개발자에게 "티켓 서비스 만들어줘"라고 던지면, 유능한 사람은 곧바로 만들지 않고 되묻는다. "환불은 되나요?", "결제 실패하면 어떻게 하죠?", "매진된 공연은 목록에서 감추나요, 아니면 매진 표시만 하나요?" 이 되물음이 바로 빈칸을 사람에게 되돌려 주는 행위다. 그런데 AI는 대체로 되묻기보다 일단 그럴듯하게 채워서 진행하는 쪽으로 기운다. 속도는 빠르지만, 채운 값이 내 의도와 다르면 그 차이는 화면과 코드까지 고스란히 흘러간다. 그래서 "빈칸을 남기지 않는 것", 즉 결정을 미리 내려 두는 것이 AI 개발에서 특히 중요하다.

여기서 한 가지 오해를 미리 풀어 두자. "AI가 알아서 다 해 준다며, 결정까지 시키면 안 되나?"라는 생각이 들 수 있다. AI에게 의견을 물어보는 것은 좋다 — "환불 정책, 업계에서 흔한 방식 세 가지를 장단점과 함께 제시해줘"는 훌륭한 지시다. 하지만 최종 결정은 사람의 몫으로 남겨야 한다. AI가 제시한 세 안 중 무엇을 고를지는 우리 사정(공연 취소가 잦은지, 환불 문의 응대 여력이 있는지)을 아는 사람이 정한다. AI는 선택지를 넓혀 주고, 사람은 그중에서 고른다 — 이 분업이 이 장의 밑그림이다.

그래서 개발 전에 결정을 문서로 만든다. 그 문서가 PRD다. 이 장은 그 문서가 완성되는 순서대로 간다 — 회의록 → PRD 초안 → 검토 → 무엇을 뺄지 결정 → 확정된 PRD.

[짚고 가기] "결정을 안 한 것"이라는 프레임이 이 장의 핵심 메시지다. AI 결과가 마음에 안 들면 반사적으로 "AI가 못한다"고 결론짓기 쉬운데, 그 대부분은 지시(입력)에 빈칸이 많았던 경우다. 직접 확인해 보고 싶다면, 일부러 애매한 지시("괜찮은 티켓 사이트 하나 만들어줘")를 주고 나온 결과를 보자 — 이건 AI가 이상한 게 아니라 우리가 안 정한 것이다. 이 장의 나머지는 그 빈칸을 없애는 훈련으로 이어진다.

문서는 보고용이 아니라 '다음 작업의 입력'이다

회사에서 기획 문서는 종종 결재받고 잊히는 서류가 된다. AI 개발에서는 다르다. PRD는 AI 개발팀 전체에게 주는 입력값이다. 디자이너 역할은 PRD를 보고 화면을 그리고, 개발자 역할은 PRD의 기능 목록대로 만들고, QA 역할은 PRD의 완료 기준으로 검사한다.

입력이 애매하면 모든 출력이 애매해진다. 반대로 PRD 한 장이 정확하면, 그 뒤의 모든 지시가 짧아진다 — "PRD대로 만들어" 로 충분해지기 때문이다.

이 차이를 조금 더 실감 나게 보자. 전통적인 회사에서 기획서의 독자는 대개 결재자다. 윗사람이 읽고 "진행해"라고 사인하면 기획서의 임무는 끝난다. 그다음 실제로 만드는 사람은 기획서를 흘깃 보고 나머지는 회의·메신저·구두로 채운다. 그래서 기획서에 빈칸이 좀 있어도 굴러갔다 — 사람이 그때그때 물어보며 메웠으니까.

AI 개발에서는 이 '그때그때 물어보며 메우는' 여지가 좁다. AI 개발팀(디자이너·개발자·QA 역할)이 참조하는 것은 결국 우리가 준 문서다. 문서에 안 적힌 것은 AI가 짐작으로 채우고, 짐작이 틀리면 결과가 어긋난다. 즉 PRD의 진짜 독자가 결재를 맡은 상사에서 다음 작업을 맡을 담당자(사람이든 AI든)로 바뀌었다. 이것이 "AI 시대에 기획 문서가 더 중요해진" 첫 번째 이유다.

두 번째 이유는 속도 때문이다. 예전에는 애매한 기획서로 시작해도 개발이 느려서, 만들다가 이상하면 중간에 붙잡고 고칠 시간이 있었다. 지금은 AI가 몇 분 만에 화면 수십 개를 만들어 낸다. 빠르다는 것은 틀린 방향으로도 빠르다는 뜻이다. 잘못된 입력으로 시작하면, 잘못된 결과가 그만큼 빨리·많이 쌓인다. 그래서 첫 입력을 정확히 맞춰 두는 일의 가치가 예전보다 커졌다. 기획에 30분 더 쓰는 것이, 잘못 만든 화면 스무 개를 걷어내는 것보다 비용이 적게 든다.

세 번째 이유는 재사용 때문이다. 좋은 PRD 하나는 이 프로젝트가 끝날 때까지 계속 참조된다. 디자인할 때, 코드 짤 때, 테스트 짤 때, 나중에 "이거 왜 이렇게 만들었지?"를 되짚을 때까지. 문서 한 번 잘 써 두면 그 뒤 수십 번의 지시가 짧아진다는 것은 과장이 아니다 — 뒤에서 우리가 만들 스킬들이 전부 이 PRD를 근거로 일하게 된다.

[짚고 가기] "PRD의 독자는 결재자가 아니라 다음 작업을 맡을 담당자"라는 관점은 처음엔 낯설다. 익숙한 비유로 바꿔 보면 쉽다 — 요리 레시피는 심사위원에게 보여주려고 쓰는 글이 아니라, 그 레시피를 보고 실제로 요리할 사람(또는 로봇)을 위한 지시서다. 재료 분량이 "적당히"라고 적혀 있으면 만드는 사람마다 다른 요리가 나온다. PRD도 똑같다 — 이 감각이 뒤에 나오는 '형용사를 측정 가능한 기준으로'로 자연스럽게 이어진다.

3.2 용어 정리

이 절의 용어들은 이 장뿐 아니라 앞으로 계속 쓰인다. 개발이 처음이라면 낯설 수 있는데, 완벽히 외울 필요는 없다. "이런 개념이 있구나" 정도로 눈에 익혀 두면 실습하며 자연스럽게 손에 붙는다.

요구사항 (Requirements)

만들 것에 대해 "이래야 한다"고 정한 것들. 두 종류를 구분하면 대화가 편해진다.

• 기능 요구: 무엇을 할 수 있어야 하는가 — "티켓 등급을 골라 예매할 수 있다"
• 비기능 요구: 어떤 품질이어야 하는가 — "휴대폰에서 3분 안에 결제까지 끝난다"

용어 자체를 조금 풀어 보자. '요구사항(requirement)'은 말 그대로 "요구되는(required) 것", 즉 만들어진 결과물이 반드시 만족해야 할 조건이다. 소원 목록(wish list)과는 다르다. 소원은 "있으면 좋겠다"지만, 요구사항은 "이걸 만족 못 하면 실패"라는 선이다. 그래서 좋은 요구사항은 나중에 참인지 거짓인지 판정할 수 있는 문장의 형태를 띤다.

기능 요구와 비기능 요구의 구분이 왜 유용할까. 둘은 확인하는 방법이 다르기 때문이다.

기능 요구는 대체로 "있나 없나"로 갈린다 — 예매 버튼이 동작하거나 안 하거나 둘 중 하나다. 비기능 요구는 "얼마나"의 문제라 숫자가 따라붙는다 — 3초냐 10초냐, 100명이 동시에 몰려도 버티냐 등. 비기능 요구는 자주 잊히는데(눈에 잘 안 보이니까), 서비스의 성패는 오히려 여기서 갈리는 경우가 많다. "예매는 되는데 너무 느려서 고객이 떠난다"가 전형적인 비기능 요구의 실패다. 온티켓에서 오대표가 말한 "폰으로 3분 안에"가 바로 비기능 요구이고, "골목 라이브 때처럼 초과 판매되면 안 된다"도 안정성이라는 비기능 요구에 가깝다.

PRD (Product Requirements Document, 제품 요구사항 문서)

무엇을, 누구를 위해, 왜 만드는지와 완성의 기준을 정리한 문서다. 정해진 국제 표준 양식은 없지만, 실무에서 통하는 뼈대는 대체로 이렇다.

이름을 한 글자씩 풀면 이 문서의 성격이 보인다. Product(제품) — 만들 대상, Requirements(요구사항) — 그 대상이 만족해야 할 조건, Document(문서) — 말이 아니라 글로 남긴 것. 세 단어 중 실무에서 가장 자주 잊히는 것이 마지막 'Document'다. 회의에서 다 말했으니 됐다고 넘어가면, 그 결정은 며칠 안에 사람들의 기억 속에서 조금씩 달라진다. 오대표는 "7일 전 전액 환불"이라 기억하고, 개발은 "7일 전 50%"로 기억하는 식이다. 글로 남기는 순간 기억의 어긋남이 사라진다 — 이것이 굳이 문서로 만드는 이유다.

각 항목이 왜 필요한지 하나씩 짚어 두면, 나중에 PRD를 직접 검토할 때 무엇을 봐야 할지 감이 온다.

• 배경·목표: "왜"가 없으면 판단의 기준이 없다. 온티켓의 "왜"는 "인터파크 수수료가 아까워서 직접 판다"이다. 이 한 줄이 있으면, 애매한 선택 앞에서 "수수료를 아끼는 데 도움이 되나?"로 결정을 내릴 수 있다.
• 사용자: 같은 서비스라도 누구를 위한 화면이냐에 따라 설계가 달라진다. 온티켓에는 두 부류가 있다 — 표를 사는 구매자, 판매 현황을 보는 운영자. 이 둘을 구분해 두지 않으면 한 화면에 뒤섞여 둘 다 불편해진다.
• 기능 요구: 만들 것의 목록. 여기가 곧 개발자 역할의 작업 지시서가 된다.
• 완료 기준: 아래에서 따로 설명한다. PRD의 심장이다.
• 범위 제외: 아래에서 따로 강조한다. 초심자가 가장 자주 빠뜨리는 항목이다.
• 미결사항: 아직 못 정한 것을 숨기지 않고 드러내는 칸. 여기가 비어 있으면 오히려 의심해야 한다 — 진짜 다 정해진 게 아니라, 못 정한 걸 못 본 것일 때가 많다.

'범위 제외'가 왜 결정적인가. 사람은 "만들 것"은 열심히 적지만 "안 만들 것"은 잘 안 적는다. 그런데 오해의 대부분은 적지 않은 곳에서 생긴다. 온티켓 회의에서 오대표가 "나중엔 플랫폼으로"라고 말했다면, 이것을 범위 제외에 "이번 첫 버전에는 다른 주최사 입점 기능을 넣지 않는다"라고 명확히 적어 둬야 한다. 안 그러면 AI(또는 사람 개발자)가 "플랫폼이라니 다른 주최사도 표를 올릴 수 있게 만들어야 하나?" 하고 혼자 판단해 엉뚱한 것을 만들 수 있다. 범위 제외는 "이건 이번에 안 해도 된다"고 서로 확인해 두는 안전선이다.

PRD가 쓰이는 곳은 개발만이 아니다. 감을 잡기 위한 다른 사례들:

• 사내 업무툴 개선 — "경비 정산이 불편하다"는 불만을, 무엇을 어디까지 고칠지의 PRD로
• 마케팅 이벤트 페이지 — 기획자의 머릿속 그림을 디자이너·개발자가 같은 그림으로 보게
• 앱의 신규 기능 하나 — 기능 하나짜리 작은 PRD(1~2쪽)가 실무에선 가장 흔하다
• 외주를 맡길 때 — PRD가 곧 견적과 검수의 기준이 된다. 분쟁의 대부분은 PRD 부재에서 온다

이 목록에서 특히 기억할 것은 마지막 두 개다. PRD는 클수록 좋은 문서가 아니다. 기능 하나짜리 1~2쪽 PRD가 실무에서 가장 많이 쓰인다 — "이번 스프린트에 알림 배지 하나 추가"에도 작은 PRD를 쓴다. 완벽한 대작을 쓰려다 아예 안 쓰는 것보다, 한 장짜리라도 쓰는 편이 낫다. 그리고 외주·계약에서 PRD는 곧 돈이다. "이 정도면 완성이다"의 기준(완료 기준)이 문서에 없으면, 발주자와 수주자가 각자 다른 완성 이미지를 갖게 되고 그것이 분쟁이 된다. 우리는 외주를 주는 게 아니라 자사 서비스 온티켓을 직접 만들지만, "완성의 기준을 문서로 못 박는다"는 원리는 똑같이 유효하다.

[짚고 가기] PRD 양식을 두고 "정답 템플릿이 있나?" 궁금할 수 있다. 표준은 없고, 위 6칸이 실무의 최대공약수다. 회사마다 항목 이름이 조금씩 다르고(예: '배경'을 'Problem', '완료 기준'을 'Acceptance Criteria'로 부르기도 한다), 작은 기능엔 항목을 더 줄인다. 중요한 것은 양식이 아니라 "왜/누가/무엇을/언제 완성/안 하는 것/못 정한 것"이라는 여섯 질문에 답이 있느냐다. 양식 자체를 외우기보다 이 여섯 질문으로 기억하면 된다.

완료 기준 (Acceptance Criteria)

기능이 "됐다"고 인정받기 위한 판정 가능한 조건이다. 핵심은 판정 가능성 — 사람마다 다르게 읽히면 완료 기준이 아니다.

판정 불가능: 예매가 편리하다
판정 가능:   이벤트 목록에서 결제 완료까지 5번의 화면 이동 안에 끝난다

완료 기준은 나중에 QA의 검사 항목이 되고, 테스트 코드의 재료가 된다. 즉 여기서 정확하게 써 두면 뒤의 두 단계가 공짜로 따라온다.

영어 이름 'Acceptance Criteria'를 직역하면 '수용(受容) 기준'이다. 여기서 '수용'은 "이 결과물을 받아들이겠다"는 뜻 — 물건을 납품받을 때 "검수 통과"에 해당한다. 즉 완료 기준은 검수의 체크리스트다. 이 조건들을 다 만족하면 "받는다", 하나라도 안 되면 "아직 아니다". 그래서 완료 기준의 각 항목은 반드시 예/아니오로 답할 수 있는 문장이어야 한다.

판정 가능한 완료 기준을 쓰는 요령은 세 가지다.

1. 관찰 가능한 사실로 쓴다. "빠르다"가 아니라 "3초 안에 뜬다"처럼, 눈으로 보거나 시계로 재거나 세어서 확인할 수 있는 형태로.
2. 주어를 사용자나 화면으로 둔다. "시스템이 잘 처리한다"가 아니라 "사용자가 결제 버튼을 누르면 3초 안에 완료 화면이 보인다"처럼, 누가 무엇을 하면 무엇이 보이는지의 형태로.
3. 실패 경우도 적는다. "결제 성공하면 티켓이 발급된다"만 있으면 절반이다. "결제 실패하면 재고가 원래대로 돌아오고, 실패 안내 문구가 보인다"까지 있어야 완결된다. 초심자는 성공 경로만 적고 실패 경로를 빠뜨리는데, 서비스 사고는 대부분 실패 경로에서 난다.

세 번째가 특히 온티켓과 연결된다. 오대표가 "골목 라이브 때 초과 판매로 환불해주느라 난리났었다"고 한 것이 바로 실패 경로를 안 챙긴 사고다. 그래서 온티켓의 완료 기준에는 "잔여 0이면 예매 버튼 비활성", "결제 직전 서버가 재고를 다시 확인" 같은 실패를 막는 조건이 들어가야 한다.

'완료 기준을 쓰면 뒤 두 단계가 공짜'라는 말을 조금 더 풀면 이렇다. 완료 기준 한 문장은 그대로 세 곳에서 재사용된다.

같은 한 문장이 기획 → 검수 → 자동 테스트로 흘러간다. 그래서 완료 기준을 대충 쓰면 뒤의 두 단계가 전부 흔들리고, 정확히 쓰면 뒤의 두 단계가 거의 저절로 채워진다.

MVP (Minimum Viable Product, 최소 기능 제품)

돌아가는 최소한의 첫 버전. 전부 다 만들고 출시하는 게 아니라, 핵심만 만들어 내보내고 반응을 보며 키우는 방식이다. 온티켓의 MVP가 무엇인지 — 무엇을 넣고 무엇을 뺄지 — 는 PRD 초안을 검토한 뒤, 이 장 뒤쪽의 범위 결정에서 정한다. 여기서는 용어만 잡아 둔다: "MVP에서 뺀다"는 말은 "안 만든다"가 아니라 "첫 버전에서는 안 만든다" 는 뜻이다.

세 단어를 각각 풀면 오해가 줄어든다.

• Minimum(최소): 가능한 한 적게. 기능을 자랑하는 게 아니라, 없어도 되는 걸 덜어내는 것이 핵심이다.
• Viable(생존 가능한): 이 단어가 제일 자주 오해된다. '작다'가 아니라 '작동해서 가치를 준다'는 뜻이다. 반쪽짜리 미완성품이 아니라, 작지만 실제로 쓸 수 있는 온전한 것이어야 한다. 흔한 비유로, MVP는 '자동차의 바퀴 한 짝'이 아니라 '일단 굴러가는 킥보드'다 — 목적지(이동)에 데려다주는가가 기준이다.
• Product(제품): 프로토타입이나 목업이 아니라, 고객이 실제로 돈을 내고 쓰는 것.

온티켓으로 옮기면, MVP는 "표를 골라 결제하고 QR 티켓을 받는" 핵심 흐름 하나가 끝까지 작동하는 첫 버전이다. 여기에 회원 등급, 포인트 적립, 다른 주최사 입점, 자동 환불 같은 것은 처음엔 없어도 고객이 표를 살 수 있다. 그래서 그런 것들은 "안 만든다"가 아니라 "첫 버전에서는 뺀다"로 미룬다. 이 판단(무엇을 첫 버전에 넣고 뺄지)은 뒤의 범위 결정에서 본격적으로 다룬다. 지금은 완료 기준을 쓸 때 "이건 지금 버전 얘기다"라는 감각만 챙기면 된다.

[짚고 가기] MVP를 '싸구려 시제품'으로 오해하기 쉬운데, Viable(생존 가능)에 초점을 두면 바로잡힌다 — 작동해서 고객이 쓸 수 있어야 MVP다. 안 굴러가는 반쪽은 MVP가 아니라 그냥 미완성이다. 또 하나, MVP를 PRD 초안을 쓰는 자리에서 '결정'하지는 않는다는 점을 기억하자. 초안은 회의록의 요구를 '다' 담는 단계이고, 무엇을 첫 버전에 넣을지의 취사선택은 그 초안을 검토한 다음의 일이다. 초안을 쓰다 성급하게 기능을 쳐내고 싶어지더라도, 일단 다 적어 두고 뺄지 말지는 범위 결정으로 미루는 것이 좋다 — 다 적혀 있어야 무엇을 뺐는지도 남는다.

3.3 형용사를 측정 가능한 기준으로

회의록의 말들을 PRD로 바꾸는 작업의 핵심 기술이 이것이다. 회의에서 나온 말은 대부분 형용사다 — 예쁘게, 빠르게, 편하게, 안정적으로. 형용사는 사람마다 다르게 읽히고, AI는 그 빈칸을 가장 무난한 것(중앙값) 으로 채운다. 그래서 결과물이 "어디서 본 듯한" 모습이 된다.

왜 하필 형용사가 문제일까. 형용사는 정도를 나타내지만 그 정도의 눈금이 없는 말이기 때문이다. "빠르다"는 3초를 빠르다고 여기는 사람과 0.5초라야 빠르다고 여기는 사람 사이의 폭이 열 배도 넘는다. 회의실에서 오대표가 "빠르게"라고 말할 때 그의 머릿속엔 구체적인 그림이 있지만, 그 그림은 말에 담기지 않는다. 형용사만 전달되고 그림은 전달되지 않는다. 그 결과, 듣는 사람(개발자든 AI든)은 자기 나름의 눈금으로 빈칸을 채운다. AI가 특히 '중앙값'으로 채우는 이유는, AI가 세상의 수많은 사례를 학습해 "보통 이 정도"의 감각을 갖고 있기 때문이다. 그래서 지시가 애매하면 결과가 "무난하지만 남과 똑같은" 모습으로 수렴한다. 우리 서비스만의 특징을 원한다면, 그 특징을 형용사가 아니라 눈금으로 못 박아 줘야 한다.

처방은 기계적이다. 형용사가 보이면 측정 가능한 문장으로 바꾼다.

이 변환을 할 때 스스로에게 던지는 질문이 있다: "이걸 어떻게 확인하지?" 이 질문에 답할 수 있으면 측정 가능한 문장이 된 것이다. "빠르다"는 어떻게 확인하나? 답이 막힌다. "화면 이동 5회 이하"는 어떻게 확인하나? 세어 보면 된다 — 답이 나온다. 확인 방법이 떠오르는 순간, 그 문장은 완료 기준으로 쓸 수 있는 상태가 된 것이다.

세 번째 줄('예쁘고 신뢰감 있게')은 조금 특별하다. 모든 형용사를 이 자리에서 숫자로 바꿀 수 있는 건 아니다. '예쁘다'는 색·글꼴·여백의 문제라 기획 단계에서 못 박기보다 디자인 단계로 넘기는 편이 낫다. 그래서 여기서는 "예쁘게"를 억지로 숫자화하지 않고, "디자인 결정을 따른다"고 위임 표시만 남긴다. 핵심은 형용사를 전부 숫자로 바꾸는 게 아니라, 형용사를 '숫자로 바꾸거나 / 담당 단계로 넘기거나 / 미결로 남기거나' 셋 중 하나로 처리해 빈칸으로 방치하지 않는 것이다.

이 기술은 개발 밖에서도 그대로 쓰인다.

• 쇼핑몰 리뉴얼: "사이트가 느리다" → "상품 목록 첫 화면이 2초 안에 뜬다"
• 사내 교육: "신입이 빨리 적응하게" → "입사 첫 주 안에 혼자 첫 발주를 완료한다"
• 보고서 지시: "간결하게 써" → "핵심 요약 3줄 + 본문 2쪽 이내"
• 고객센터: "응대 품질을 높이자" → "첫 응답까지 평균 1시간 이내"

몇 가지 개발 밖 사례를 더 붙여 본다. 어떤 분야든 '형용사 → 눈금'의 패턴은 똑같이 작동한다는 것을 보여주기 위해서다.

패턴이 보일 것이다. 왼쪽은 전부 "얼마나?"에 답이 없는 말이고, 오른쪽은 전부 숫자·기한·횟수·비율이 붙어 확인 가능한 말이다. 형용사를 만나면 반사적으로 "얼마나? 언제까지? 몇 번? 몇 퍼센트?"를 떠올리는 습관이 이 절의 전부다. 이 습관은 AI에게 지시할 때뿐 아니라, 사람에게 일을 부탁하거나 스스로 목표를 세울 때도 똑같이 결과를 바꾼다.

한 가지 주의도 함께. 숫자를 붙인다고 다 좋은 기준이 되는 건 아니다. 근거 없이 아무 숫자나 박으면("첫 화면 0.1초 안에") 지키지도 못할 기준이 되어 오히려 해롭다. 숫자에는 근거가 있어야 한다 — 업계 관행, 경쟁 서비스 수준, 우리 고객의 실제 인내심. 근거가 아직 없으면, 억지 숫자를 박기보다 미결사항으로 남기고 "기준값 조사 필요"라고 적는 편이 정직하다. 이것이 아래의 안전장치로 이어진다.

한 가지 안전장치를 함께 기억하자. 정하지 못한 것은 지어내지 않고 '미결사항'에 적는다. 온티켓 회의록의 환불 정책("7일 전까지 전액, 이후 50%라는데 확정 아님")이 그 예다. 애매한 것을 그럴듯하게 확정해 버리는 순간, 나중에 오대표와 싸우게 된다.

왜 하필 '싸우게' 되는지 짚어 두자. 확정되지 않은 것을 문서에 확정으로 적으면, 그 문서를 근거로 화면이 만들어지고 코드가 짜인다. 나중에 오대표가 "환불은 5일 전까지로 하자"고 말을 바꾸면(원래 확정한 적이 없으니 말을 바꾼 것도 아니다), 이미 만든 것을 전부 다시 손대야 한다. 이때 "문서에 7일이라고 적혀 있잖아요"라고 해도, 오대표는 "내가 언제 그걸 확정했냐"고 한다 — 그리고 실제로 그는 확정한 적이 없다. 미결을 확정으로 둔갑시킨 것은 문서를 만든 쪽의 잘못이 된다. 그래서 미결은 미결로 남겨 두는 것이 정직할 뿐 아니라 나를 보호하는 길이다. 미결사항 칸은 "아직 못 정했음"을 드러내는 정직함의 자리이자, "이건 사람이 정해 줘야 한다"는 요청서이기도 하다.

[짚고 가기] 이 절은 이 장에서 가장 오래 남는 기술이다. 직접 손을 움직여 보면 각인된다 — 형용사 하나("친절한 안내 문구")를 골라 30초 안에 측정 가능한 문장으로 바꿔 보자. 정답이 하나가 아니라는 것("문의 3건 중 반말 표현 0건" vs "안내문에 다음 행동 1개가 항상 있다")을 확인하면, 이 기술이 창의적 판단이지 기계적 치환이 아님을 알게 된다. 그리고 자주 빠지는 함정 — 억지 숫자 — 을 조심하자. 근거 없는 숫자는 형용사보다 나쁘다. 못 정하면 미결로 남긴다.

3.4 개념 — 기획의 절반은 '빼는 결정'이다

다 넣으면 아무것도 안 나온다

지금까지는 회의록의 요구를 빠짐없이, 측정 가능하게 PRD로 옮기는 법을 다뤘다. 그런데 다 옮겨 적은 PRD를 그대로 만들기 시작하면 안 된다. 킥오프 회의록을 다시 보자. 오대표의 요구는 끝이 없다 — 예매, 결제, QR, 환불, 판매 현황, 엑셀 다운로드, 카카오 알림, 좌석 지정, 대기자 명단, 초대권, 현장 결제, 나중엔 다른 기획사 입점까지. 이걸 다 만들면? 만들 수는 있다. 다만 오픈이 3일이 아니라 석 달 뒤가 된다. 그 사이 리버사이드 재즈 티켓은 또 구글폼으로 판다.

여기서 처음 배우는 사람이 흔히 품는 오해를 하나 풀고 가자. "기능이 많을수록 좋은 서비스 아닌가?"라는 생각이다. 사실은 반대에 가깝다. 기능이 하나 늘 때마다 만들 코드, 테스트할 경우, 나중에 고장 날 수 있는 지점이 함께 늘어난다. 기능 열 개짜리 서비스는 기능 한 개짜리 서비스보다 열 배가 아니라 훨씬 더 복잡해진다 — 기능끼리 서로 얽히기 때문이다. 좌석 지정을 넣으면 환불도 좌석 단위로 처리해야 하고, 판매 현황도 좌석별로 집계해야 한다. 하나를 넣으면 그 하나로 끝나지 않는다.

그래서 첫 버전(MVP)의 범위를 자른다. 중요한 것은 이것이 포기가 아니라 순서 결정 이라는 점이다. "안 만든다"가 아니라 "첫 버전 다음에 만든다". 그리고 이 결정은 AI가 대신해 줄 수 없다 — 무엇이 회사에 중요한지는 사람의 판단이기 때문이다. AI에게는 후보와 근거를 제안하게 하고, 결정은 사람이 한다.

여기서 용어 정리에서 잡아 둔 MVP의 'Viable(생존 가능한)'이 판단의 잣대가 된다. 온티켓의 목적은 "우리 공연 티켓을 수수료 없이 직접 판다"이다. 그러니 예매와 결제가 빠지면 아무리 작아도 MVP가 아니다 — 목적을 못 이루니까. 반대로 카카오 알림이 없어도 티켓은 팔린다. 이 감각이 범위 결정 전체를 관통한다.

범위를 정하는 기준 세 가지

무엇을 남기고 무엇을 미룰지 고민될 때, 이 세 질문을 던진다.

1. 핵심 가치 경로에 있는가 — 이 서비스의 존재 이유가 되는 한 줄기 흐름. 온티켓이라면 "이벤트를 보고 → 예매하고 → 결제하고 → QR로 입장한다". 이 경로 위의 기능은 못 뺀다. 경로 밖 기능은 전부 미룰 후보다.
2. 대체 수단이 있는가 — 로그인이 없어도 주문번호+이메일로 내 티켓을 찾을 수 있다. 카카오 알림이 없어도 화면의 QR을 캡처하면 된다. 대체 수단이 있으면 미룬다.
3. 나중에 붙이기 쉬운가 — 알림·엑셀 다운로드는 나중에 붙여도 기존 구조가 안 흔들린다. 반대로 "여러 기획사 입점"은 데이터 구조 자체를 바꾸므로, 미루더라도 설계 때 그 가능성만 기억해 둔다.

세 기준을 한 번 더, 처음 듣는 사람 눈높이로 풀어 보자. 이 세 질문은 순서대로 던지는 '체'라고 생각하면 편하다. 위에서부터 걸러 내려오는 세 겹의 체다.

기준 1 — 핵심 가치 경로에 있는가. '핵심 가치 경로(critical path)'는 서비스가 사용자에게 약속한 가치가 처음부터 끝까지 이어지는 하나의 가느다란 줄기다. 온티켓의 약속은 "티켓을 사서 공연장에 들어간다"이다. 그 약속이 완성되려면 반드시 거쳐야 하는 단계 — 이벤트를 본다, 예매한다, 결제한다, QR을 받는다, 입장한다 — 이 다섯이 경로다. 이 경로에서 한 칸이라도 빠지면 사용자는 목적을 못 이룬다. 결제를 빼면? 티켓을 못 산다. QR을 빼면? 공연장에 못 들어간다. 그래서 경로 위의 기능은 협상 대상이 아니다. 반대로 "판매 현황 엑셀 다운로드"는 사용자가 공연장에 들어가는 것과 아무 상관이 없다. 경로 밖이다. 경로 밖 기능은 전부 "미룰 후보 명단"에 자동으로 올린다. 미룬다고 확정하는 게 아니라, 일단 후보에 올려 두고 기준 2·3으로 다시 거른다.

기준 2 — 대체 수단이 있는가. 어떤 기능을 지금 안 만들어도, 사용자가 다른 방법으로 같은 목적을 이룰 수 있다면 급하지 않다. 온티켓에서 로그인을 뺀 결정이 이 기준의 대표 사례다. 로그인의 목적은 "내 티켓을 나만 볼 수 있게"인데, 그건 주문번호와 이메일을 아는 사람만 조회하게 해도 충분히 이룬다. 로그인이라는 큰 기능(회원가입, 비밀번호, 찾기, 소셜 연동, 보안 처리…)을 통째로 미루고도 목적은 지켜진다. 카카오 알림도 같다 — 알림의 목적은 "티켓 정보를 사용자에게 전달"인데, 결제 직후 화면에 QR을 크게 띄우고 "이 화면을 캡처하세요"라고 안내하면 목적은 이뤄진다. 대체 수단이 다소 불편해도 괜찮다. 첫 버전의 목표는 '완벽'이 아니라 '끝까지 굴러가는 것'이기 때문이다.

기준 3 — 나중에 붙이기 쉬운가. 같은 '미룰 후보'라도, 나중에 붙일 때 기존 구조를 얼마나 흔드느냐가 다르다. 이 기준은 초심자에게 가장 감이 안 오는 부분이라 비유가 필요하다. 집을 다 지은 뒤에 커튼을 다는 일과 방 하나를 더 만드는 일은 난이도가 다르다. 커튼은 벽을 안 건드리고 나중에 얼마든지 단다. 방을 늘리는 일은 벽을 허물고 배관을 다시 깔아야 한다. 소프트웨어도 똑같다. 알림·엑셀 다운로드는 '커튼'이다 — 이미 있는 데이터를 가져다 형식만 바꿔 내보내는 일이라, 나중에 붙여도 예매·결제 로직을 안 건드린다. 반면 "여러 기획사 입점(플랫폼화)"은 '방 늘리기'다 — 지금은 모든 티켓이 우리(승승장구) 것이라 데이터에 '누구네 공연인가'라는 칸이 아예 없다. 입점을 붙이려면 이벤트·주문·정산 데이터 구조를 근본부터 바꿔야 한다. 그래서 이건 미루더라도, 설계할 때 "언젠가 방을 늘릴 수도 있다"는 가능성만 머릿속 한구석에 남겨 둔다. 벽을 아예 못 허물게 지어 버리면 곤란하니까.

세 기준의 관계도 정리해 두면 좋다. 기준 1은 "미룰 수 있는가"를 가른다. 경로 위면 못 미루고, 경로 밖이면 미룰 후보다. 기준 2와 3은 "미뤄도 괜찮은가"를 확인한다. 대체 수단이 있고(2) 나중에 붙이기도 쉬우면(3), 마음 편히 미룬다. 대체 수단이 없거나 나중에 붙이기가 어려우면, 경로 밖이라도 한 번 더 고민한다.

"제안은 AI, 결정은 사람" — 이 원칙이 왜 중요한가

이 장 첫머리에서 "AI는 선택지를 넓혀 주고, 사람은 그중에서 고른다"는 분업을 밑그림으로 그어 두었다. 그 선이 가장 또렷해지는 곳이 범위 결정이다. 제안은 AI가, 결정은 사람이. 왜 하필 여기서 이 선을 분명히 긋는지, 배경을 짚어 두면 3일 내내 두고두고 쓰인다.

첫째, 범위 결정에는 AI가 모르는 정보가 들어간다. AI는 PRD에 적힌 기능 목록은 읽을 수 있다. 하지만 "리버사이드 재즈 티켓을 이번 주말까지 팔아야 한다", "오대표가 초과 판매 사고로 데인 적이 있어 재고 정확도에 예민하다", "다음 분기에 다른 기획사와 제휴 이야기가 오갈 수도 있다" 같은 회사 안의 사정과 미래 계획은 문서 어디에도 없다. 이런 맥락 없이 자른 범위는 겉보기엔 그럴듯해도 회사에 맞지 않는다. 결정의 재료 중 절반이 사람 머릿속에만 있는 것이다.

둘째, 범위 결정은 되돌리는 데 비용이 많이 드는 결정이다. 색깔을 잘못 고르면 나중에 바꾸면 된다. 하지만 "좌석 지정을 넣는다"고 잘못 결정하면, 그 위에 예매·환불·정산 코드가 전부 좌석 기준으로 쌓인 뒤라 되돌리는 데 비용이 매우 많이 든다. 되돌리는 데 비용이 많이 드는 결정일수록 사람이 직접, 근거를 남기며 내려야 한다. 이건 설치 직후 익힌 퍼미션의 정신과 정확히 같다 — 되돌리기 어려운 일 앞에서 사람이 개입한다.

셋째, 책임의 문제다. "왜 이 기능을 뺐나요?"라는 질문(주로 오대표)에 답할 사람은 AI가 아니라 여러분이다. AI가 자른 범위를 그대로 받아들이면, 나중에 그 결정을 설명할 근거가 없다. 반대로 사람이 제안을 검토하고 스스로 결정하면, 결정마다 이유가 남는다. 그 이유가 곧 답변서가 된다.

그렇다고 AI를 안 쓰는 게 아니다. AI는 이 일에서 가장 좋은 조수다. 기능 목록을 빠짐없이 훑어 "이건 뺄 후보 같습니다"라고 정리해 주고, 각 후보의 대체 수단과 난이도를 표로 만들어 준다. 사람이 백지에서 고민하는 것보다, 잘 정리된 후보 표를 놓고 "이건 동의, 이건 반대"라고 판단하는 편이 훨씬 빠르고 빠뜨림이 적다. 정리하면 — AI는 재료를 모아 상을 차리고, 사람은 그 상에서 무엇을 먹을지 고른다.

[짚고 가기] 이 원칙은 말로만 들으면 잘 안 와닿는다. 직접 해 보면 확실해진다. AI에게 "온티켓 첫 버전에서 뺄 기능을 정해줘"라고 통째로 맡겨 보라. AI는 그럴듯한 표를 내놓지만, 리버사이드 재즈 일정도 오대표의 초과 판매 트라우마도 모른 채 자른다. 그 표를 앞에 놓고 "이 결정, 오대표에게 이대로 보고할 수 있겠는가?"를 스스로 물어보면 빈 곳이 보인다. "제안은 AI, 결정은 사람"이 규칙이 아니라 필요라는 걸 체감하게 되는 지점이다.

온티켓 첫 버전의 결정

이 기준으로 온티켓의 범위를 자르면 이렇게 된다. (실습에서 여러분이 직접 이 결정을 내리고 PRD에 반영한다.)

이 표를 세 기준에 비추어 다시 읽어 보면 결정의 논리가 또렷해진다. '넣는다'로 묶인 것들은 전부 기준 1(핵심 가치 경로) 을 통과했거나, 회의에서 나온 세 가지 문제(입금을 일일이 대조하던 수고, 골목 라이브의 초과 판매 사고, 손으로 적던 입장 명단)를 직접 해결하는 기능이다. 이 문제들은 오대표가 온티켓을 만들기로 한 이유 자체라, 경로만큼이나 못 뺀다.

'뺀다'로 묶인 것들은 각각 다른 기준에서 미룰 만하다고 판정됐다. 로그인은 기준 2(대체 수단) — 주문번호+이메일이 대신한다. 카카오 알림·엑셀은 기준 2와 3을 모두 통과 — 대체 수단도 있고 나중에 붙이기도 쉽다. 좌석 지정과 입점은 기준 3에 걸린다 — 나중에 붙이기가 어렵거나 구조를 바꾼다. 그래서 지금은 미루되 '설계 때 기억해 둘' 항목으로 표시한다. 환불 자동화는 조금 결이 다르다 — 만들기 어려워서가 아니라 정책 자체가 아직 안 정해져서 미룬다. 정책이 없는데 코드부터 만들면, 정책이 정해지는 순간 그 코드를 버리고 다시 만든다. "정해지기 전엔 안 만든다"도 훌륭한 범위 결정이다.

여기서 하나 강조할 점 — 뺀 항목마다 이유가 한 줄씩 붙어 있다는 것이다. 이 이유는 장식이 아니다. 앞서 말했듯 "이거 왜 없어요?"라는 질문에 대한 미리 써 둔 답변서이고, 나중에 그 기능을 붙일 때 "무슨 조건이 충족되면 붙일지"의 힌트이기도 하다. 예를 들어 환불 자동화 옆의 "정책 미확정"은 곧 "정책이 확정되면 만들 차례"라는 뜻이 된다.

[짚고 가기] 이 표를 완성된 결과로 읽기보다, 빈 표를 놓고 한 칸씩 직접 채워 보면 훨씬 오래 남는다. "좌석 지정, 넣을까 뺄까?"를 스스로 물으면 답이 쉽게 안 나온다. 그때 세 기준을 하나씩 대 보며 결론에 이르는 과정을 밟아 보면, 이 표가 결과가 아니라 판단의 산물임을 알게 된다. 여기서 얻을 것은 정답이 아니라 판단하는 법 자체다.

범위 정하기는 어디서나 쓰는 기술이다

• 배달 앱을 만든다면 — 첫 버전은 "메뉴 보고 주문하고 결제"까지. 리뷰·쿠폰·찜은 다음
• 사내 경비 정산 툴 — 첫 버전은 "영수증 올리고 승인받기"까지. 법인카드 연동은 다음
• 유튜브 채널을 시작한다면 — 첫 달은 "일주일에 1편 업로드"까지. 쇼츠·커뮤니티·굿즈는 다음
• 보고서 자동화 — 첫 버전은 "주간 매출표 자동 생성"까지. 예측·이상 감지는 다음

공통점: 끝까지 가는 가장 가는 줄기 하나를 먼저 완성하고, 살은 나중에 붙인다.

이 사례들을 세 기준으로 다시 보면 패턴이 보인다. 배달 앱의 "메뉴 보고 주문하고 결제"는 핵심 가치 경로다(기준 1). 리뷰·쿠폰은 없어도 배달이 되니 미룰 후보다. 경비 정산 툴의 법인카드 연동은 '방 늘리기'에 가까워(기준 3) 신중히 미룬다 — 반면 영수증을 손으로 올리는 건 불편해도 되긴 되니(기준 2 대체 수단), 첫 버전에선 그걸로 간다. 도메인이 무엇이든 던지는 질문은 똑같다는 게 핵심이다.

이 기술은 개발 밖에서도 그대로 쓰인다. 창업 초기의 사업 계획, 새 부서의 첫 분기 목표, 심지어 이사할 때 무엇을 먼저 옮길지까지 — "핵심 줄기 하나를 먼저 끝내고 나머지는 순서대로"는 자원이 부족한 모든 상황의 기본 전략이다. 3일 안에 서비스를 만드는 우리에게는 특히 그렇다. 시간이라는 자원이 늘 부족하기 때문이다.

3.5 첫 스킬 만들기 — PM을 팀에 앉힌다

왜 이 일을 스킬로 만드는가

회의록을 PRD로 바꾸는 일은 이번 한 번으로 끝나지 않는다. 기능이 추가될 때마다, 새 프로젝트를 시작할 때마다 같은 절차를 반복한다. 그때마다 "형용사를 바꾸고, 미결사항을 분리하고, 완료 기준을 넣고…"를 처음부터 지시할 것인가?

반복되는 절차는 스킬로 만든다. 그리고 이 스킬에는 절차만이 아니라 역할을 담는다 — "너는 (주)승승장구의 PM이다"라는 정체성, 판단 기준, 하지 말아야 할 것까지. 이렇게 만들어 두면 /pm 한마디로 언제든 같은 품질의 기획 작업을 시킬 수 있다.

'스킬(skill)'이라는 말을 잠깐 풀어 두자. 여기서 스킬은 "이런 일은 이렇게 해라"를 적어 둔 지시서 파일이다. 사람으로 치면 신입에게 건네는 업무 매뉴얼과 같다. 좋은 매뉴얼이 있으면 새 사람이 와도 같은 품질로 일하듯, 좋은 스킬이 있으면 매번 같은 품질의 결과가 나온다. 그리고 여기에 역할까지 담는다는 것이 핵심이다. 단순한 "PRD 쓰는 법 5단계" 매뉴얼과, "너는 우리 회사 PM이고 이런 가치관으로 일한다"는 역할 규정은 다르다. 후자는 절차에 없는 새로운 상황이 와도 그 가치관으로 스스로 판단한다. 그래서 우리는 절차만이 아니라 정체성과 판단 기준을 함께 넣는다.

왜 매번 프롬프트로 길게 지시하지 않고 굳이 파일로 만드느냐. 세 가지 이유다.

• 일관성: 매번 손으로 지시하면 그때그때 빠뜨리는 게 생긴다. 파일로 고정하면 언제 불러도 같은 절차를 밟는다.
• 간결함: /pm 한마디면 그 긴 지시가 통째로 불려 온다. 지시가 짧아진다.
• 개선의 축적: 스킬을 쓰다 부족한 점을 발견하면 파일을 고친다. 그 개선이 다음부터 계속 적용된다. 즉 스킬은 쓸수록 좋아진다 — 매번 새로 지시하면 개선이 쌓이지 않는다.

[짚고 가기] "그냥 매번 프롬프트에 붙여넣으면 안 되나?" 싶을 수 있다. 된다 — 하지만 팀원이 다섯이 되고 프로젝트가 길어지면, 매번 긴 지시를 복붙하는 것은 관리가 안 된다. 스킬은 저장해 둔 프롬프트이자 역할 규정서라고 보면 된다. 사람 팀에 빗대면, 매번 알바를 새로 뽑아 처음부터 가르치느냐, 매뉴얼을 갖춘 정직원을 두느냐의 차이다.

PM 스킬의 설계

파일 위치는 정해져 있다: .claude/skills/pm/SKILL.md. 내용을 먼저 사람 눈으로 설계해 보자. 좋은 역할 스킬에는 세 덩어리가 들어간다.

1. 정체성과 판단 기준 — 누구이며, 무엇을 중요하게 여기는가
2. 작업 절차 — 어떤 순서로 일하는가
3. 금지 사항 — 무엇을 하면 안 되는가

경로를 한 조각씩 뜯어 보면 왜 이 자리인지 이해가 된다.

• .claude/ — 앞에 점이 붙은 폴더는 '숨김 폴더'로, 프로젝트 설정을 모아 두는 약속된 자리다. Claude Code는 여기를 보고 프로젝트별 설정·스킬을 읽는다.
• skills/ — 스킬들을 모아 두는 폴더. 앞으로 팀원(스킬)이 늘면 이 아래에 하나씩 쌓인다.
• pm/ — 이 스킬의 이름. 이 폴더 이름이 곧 /pm 이라는 호출 명령이 된다.
• SKILL.md — 실제 내용이 담긴 파일. 이름과 확장자는 이 대문자 형태로 고정이다.

즉 "PM이라는 팀원의 업무 매뉴얼을, 프로젝트 설정 폴더 안 스킬 서랍에 넣는다"는 구조다. 이름을 pm으로 지었으니 호출도 /pm이 된다. 나중에 디자이너 스킬을 만들면 .claude/skills/designer/SKILL.md가 되고 /designer로 부르는 식이다.

이 설계를 반영한 SKILL.md 전문이다. (직접 타이핑할 필요 없다 — 아래 실습에서 Claude Code에게 만들게 시킨다. 지금은 구조를 눈에 익히자.)

---
description: 회의록·메모·요구 목록을 PRD로 정리할 때 사용한다.
  요구사항 정리, 기획 문서 작성, PRD 작성/수정 요청이 오면 이 스킬을 따른다.
---

너는 (주)승승장구의 PM이다. 산출물은 기획서가 아니라 팀이 그대로 실행할 수
있는 '완료 기준'이다.

## 판단 기준
- 측정할 수 없는 문장은 요구사항이 아니다
- 결정되지 않은 것을 확정된 것처럼 쓰지 않는다
- 문서는 다음 작업자(디자이너·개발자·QA)의 입력이다 — 그들이 질문할 것을 미리 없앤다

## 절차
1. 입력 문서의 요구를 하나도 빠뜨리지 말고 전부 나열한다
2. '예쁘게' 같은 형용사는 전부 측정 가능한 기준으로 바꾼다.
   바꿀 수 없으면 [미결] 표시를 남긴다
3. 서로 모순되는 요구는 그대로 두지 말고 [충돌] 표시와 함께 질문으로 만든다
4. PRD를 작성한다: 배경·목표 / 사용자 / 기능 요구 / 완료 기준 / 범위 제외 / 미결사항
5. 마지막에 "사람이 결정해야 할 질문 목록"을 따로 정리해 보여준다

## 금지
- 입력에 없는 기능을 임의로 추가하지 않는다
- 미결사항을 빈칸을 채우듯 멋대로 확정하지 않는다
- 기술 스택·화면 디자인을 이 단계에서 정하지 않는다

이 파일의 생김새를 조금 뜯어 보자. 맨 위 --- 두 줄 사이에 낀 부분을 프런트매터 (front matter) 라고 부른다. '본문 앞(front)에 붙는 설명 머리말'이라는 뜻으로, 문서 본문이 아니라 이 문서에 대한 정보(메타데이터)를 담는 자리다. 여기 description이 들어간다. 그 아래 --- 뒤부터가 실제 스킬의 본문(정체성·절차·금지)이다.

description을 눈여겨보자. Claude는 이 설명을 보고 "지금 요청이 이 스킬과 관련 있는가"를 판단해 자동 호출한다. 그래서 description에는 이 스킬이 다루는 일과, 어떤 요청이 오면 써야 하는지를 적는 것이 요령이다.

조금 더 풀면, description은 이 팀원의 명찰이자 업무 소개다. 사무실에 "저는 PRD·요구사항 정리를 맡습니다"라고 써 붙인 명찰이 있으면, 누가 "회의록 좀 정리해 줄 사람?" 하고 물을 때 이 사람이 손을 든다. Claude도 똑같이 동작한다 — 사용자가 "회의록으로 기획서 만들어줘"라고 하면, 여러 스킬의 description을 훑어 이 PM 스킬을 알아보고 자동으로 불러온다. 그래서 description을 잘 쓰는 것이 중요하다. 좋은 description과 나쁜 description을 비교하면 감이 온다.

세 번째 줄이 알려주는 함정도 기억하자. description이 너무 넓으면("문서 작성") 관련 없는 요청에까지 이 스킬이 튀어나와 방해가 된다. 다루는 일은 구체적으로, 범위는 너무 넓지 않게 — 명찰은 정확할수록 좋다.

본문의 세 덩어리도 각각 왜 필요한지 다시 짚자.

• 판단 기준(정체성) 이 있으면, 절차에 없는 새 상황에서도 AI가 방향을 잡는다. "측정할 수 없는 문장은 요구사항이 아니다"라는 원칙 하나가, 온갖 형용사 앞에서 일관된 판단을 만든다.
• 절차 는 결과의 재현성을 만든다. 순서가 정해져 있으니 매번 같은 품질이 나온다.
• 금지 는 AI가 자주 넘는 선을 미리 막는다. "입력에 없는 기능을 추가하지 마라"가 없으면, AI는 종종 친절하게 시키지도 않은 기능을 얹는다 — 이것이 나중에 회의록에 없던 기능이 PRD에 섞여 드는 원인이다.

[짚고 가기] SKILL.md의 세 덩어리를 나눠 보면 구조가 한눈에 들어온다 — 정체성은 가치관, 절차는 순서, 금지는 울타리다. 특히 '금지'의 힘은 직접 비교해 보면 실감난다. 금지 항목을 뺀 스킬과 넣은 스킬로 각각 PRD를 만들어 보면, 금지가 없을 때 AI가 시키지도 않은 '추천 공연' 같은 기능을 슬쩍 넣는 것을 볼 수 있다. 그리고 프런트매터의 ---를 빼먹으면 description이 인식되지 않으니, 실습할 때 이 점을 주의하자.

역할 스킬은 어디에나 만들 수 있다

PM은 시작일 뿐이다. 같은 3덩어리 구조(정체성·절차·금지)로 어떤 역할이든 만들 수 있다.

회사에서 내가 자주 하는 일 하나를 떠올려 보라. 그것의 정체성·절차·금지를 적을 수 있다면, 그 일은 스킬이 된다.

이 발상이 왜 강력한지 한 예를 끝까지 펼쳐 보자. '고객응대' 스킬을 실제로 3덩어리로 써 보면 이렇게 된다.

---
description: 고객 문의에 대한 답변 초안을 쓸 때 사용한다.
  컴플레인 응대, 문의 회신, CS 답변 작성 요청이 오면 이 스킬을 따른다.
---

너는 온티켓의 고객응대 담당이다. 산출물은 완결된 발송문이 아니라,
사람이 검토 후 보낼 수 있는 '답변 초안'이다.

## 판단 기준
- 고객의 불편을 먼저 인정한다 — 변명보다 공감이 앞선다
- 확답할 수 없는 것(환불 가능 여부 등)은 확답하지 않고, 확인 후 회신을 약속한다
- 한 번의 답변으로 끝나게 — 고객이 다시 물어볼 것을 미리 답한다

## 절차
1. 문의의 핵심 불편이 무엇인지 한 줄로 요약한다
2. 사과 → 상황 설명 → 해결책 또는 다음 안내 → 마무리 순서로 초안을 쓴다
3. 확인이 필요한 부분은 [담당 확인] 표시로 남긴다

## 금지
- 규정에 없는 보상(추가 할인 등)을 임의로 약속하지 않는다
- "무조건", "절대", "100%" 같은 법적 확답 표현을 쓰지 않는다
- 고객을 탓하거나 원인을 고객에게 돌리지 않는다

PM 스킬과 뼈대가 완전히 같다는 것을 눈으로 확인할 수 있다. description으로 언제 부를지 정하고, 정체성으로 가치관을 심고, 절차로 순서를 고정하고, 금지로 넘지 말 선을 긋는다. 일의 내용만 갈아 끼우면 어떤 직무든 스킬이 된다. 온티켓 프로젝트 밖에서도 마찬가지다 — 학원 강사라면 '수업 후기 작성' 스킬을, 부동산 중개라면 '매물 소개 문구' 스킬을, 개인이라면 '주간 업무 회고' 스킬을 같은 구조로 만들 수 있다.

역할 스킬을 만들 때 초심자가 자주 빠뜨리는 것은 대개 금지 사항이다. 정체성과 절차는 술술 나오는데, "무엇을 하면 안 되는가"는 잘 안 떠오른다. 요령은 "이 일을 서투른 사람이 했을 때 저지르는 실수"를 떠올리는 것이다. 마케터라면 근거 없는 과장, 채용 담당이라면 '열정' 같은 모호한 자격요건, 고객응대라면 고객 탓하기. 그 실수들의 반대가 곧 금지 항목이 된다.

[짚고 가기] 이 절은 "이 책을 다 읽고 나면 나는 무엇을 할 수 있게 되나"에 대한 답을 넓혀 주는 대목이다. 온티켓이라는 예제에만 갇히지 않으려면, "내가 회사에서 반복하는 일 하나를 스킬로 만든다면?"을 직접 떠올려 보면 좋다. 대개 정체성·절차는 술술 나오는데 금지가 잘 안 떠오르는데, "그 일을 초보가 하면 저지르는 실수 하나"를 생각하면 거기서 금지 항목이 나온다. 이 절은 스킬 하나가 곧 재사용 가능한 자산이라는 감각을 심는 자리다.

3.6 프롬프트 작성법 — 기획 작업을 시키는 요령

입력 문서를 함께 준다

기획 지시의 절반은 입력을 제대로 주는 것이다. Claude Code에서는 프롬프트에 @파일명 을 쓰면 그 파일을 읽게 할 수 있다. "회의 내용은 대충 이랬어"라고 요약해 주는 것보다, 원본 문서를 통째로 주는 쪽이 언제나 낫다 — 요약하는 순간 정보가 죽는다.

/pm @data/킥오프_회의록.md 이 회의록으로 온티켓 PRD 초안을 만들어줘.

@ 기호를 잠깐 짚자. 채팅에서 사람을 부를 때 @이름을 쓰듯, 여기서 @파일명은 "이 파일을 데려와서 같이 보라"는 뜻이다. 파일 내용을 복사해 붙여넣을 필요 없이, 경로만 가리키면 Claude Code가 그 파일을 직접 열어 읽는다. @를 입력하면 프로젝트 안의 파일 목록이 자동완성으로 떠서 고르기도 편하다.

'요약하는 순간 정보가 죽는다'는 말은 이 장 전체의 주제와 맞닿아 있다. 회의록을 "대충 티켓 팔고 환불도 되게 하는 거였어"로 요약해 주면, 그 요약에는 이미 사람의 판단이 섞여 들어가 원본의 미묘한 것들(환불이 '확정 아님'이라는 단서, 골목 라이브 사고라는 배경)이 사라진다. PRD를 만드는 목적 자체가 그 미묘한 것들을 빠짐없이 붙잡는 것인데, 입력에서부터 뭉개 버리면 앞뒤가 안 맞는다. 원본을 주고 정리는 스킬에게 맡긴다 — 이것이 순서다.

지시에 함께 넣으면 좋은 것들도 정리해 두자.

• 입력 원본: @로 회의록 등 근거 문서를 준다. (가장 중요)
• 산출물의 형태: "docs/PRD.md 파일로 저장해줘"처럼 결과를 어디에 어떤 형태로 둘지 지정한다. 안 그러면 화면에만 출력하고 파일로 안 남기기도 한다.
• 맥락: 이미 스킬 안에 정체성이 담겨 있으니 매번 길게 줄 필요는 없지만, 이번 건에만 해당하는 사정("이번 PRD는 오대표 보고용이라 배경을 조금 자세히")은 덧붙인다.

초안은 반드시 사람이 검토한다 — 그대로 받지 않기

AI가 만든 PRD 초안은 어디까지나 초안이다. 검토 없이 다음 단계로 넘기면, 초안의 오류가 화면과 코드까지 그대로 흘러간다. 검토할 때 볼 것은 세 가지다.

1. 빠진 것: 회의록에 있는데 PRD에 없는 요구가 있는가
2. 더해진 것: 회의록에 없는데 AI가 임의로 추가한 기능이 있는가
3. 남은 형용사: 아직 측정 불가능한 문장이 남아 있는가

이 세 관점에는 각각 이유가 있다. 빠진 것은 요구가 통째로 증발하는 사고다 — 오대표가 분명 말한 "운영자용 판매 현황"이 PRD에 없으면, 그 기능은 아무도 안 만든다. 더해진 것은 반대 방향의 사고다 — AI가 친절하게 얹은 '추천 공연' 같은 기능은 아무도 요청한 적이 없는데 개발 시간을 잡아먹고, 3일 안에 출시라는 목표를 위협한다. AI는 없애는 것보다 더하는 쪽으로 실수하는 경향이 있어서, 두 번째 관점이 특히 중요하다. 남은 형용사는 앞의 '형용사를 측정 가능한 기준으로'에서 다룬 그대로 — 측정 불가능한 문장이 하나라도 남으면 그 자리에서 빈칸이 다시 생긴다.

검토 자체도 AI에게 시킬 수 있다. 다만 지시 방향이 중요하다 —

방금 만든 PRD를 회의록과 대조해줘.
회의록에는 있는데 PRD에 빠진 요구, 회의록에 없는데 PRD에 추가된 내용을
각각 표로 보여줘.

이 지시가 왜 잘 작동하는지 보자. "PRD 검토해줘"라고만 하면 AI는 "전반적으로 잘 되어 있습니다"류의 두루뭉술한 답을 내놓기 쉽다. 위 지시는 대조 대상(회의록)과 찾을 것(빠진 것/더해진 것)을 콕 집어 준다. 그래서 AI가 두 문서를 나란히 놓고 줄 단위로 맞춰 보게 되고, 결과가 표로 나와 사람이 한눈에 검토한다. 검토를 AI에게 맡기더라도 무엇을 어떻게 볼지는 사람이 지정한다 — 이것이 검토를 위임하는 요령이다.

수정은 '다시 써'가 아니라 '이 부분을 이렇게'

초안이 마음에 안 들 때 "다시 써줘"라고 하면 잘된 부분까지 흔들린다. 수정 지시는 대상과 방향을 집어서 한다.

완료 기준에서 "결제가 빠르게 처리된다"는 아직 형용사야.
화면 이동 횟수나 입력 개수 기준으로 바꿔줘.
환불 정책은 확정된 게 아니니까 완료 기준에서 빼고 미결사항으로 옮겨.

'다시 써줘'가 왜 위험한지 짚어 두자. AI에게 전체를 다시 쓰게 하면, 마음에 들던 부분까지 새로 생성된다. 어제는 완벽했던 배경 설명이 오늘은 미묘하게 달라지고, 잘 잡아 둔 완료 기준 하나가 슬쩍 사라지기도 한다. 통째로 다시 쓰는 것은 고칠 한 곳 때문에 멀쩡한 아홉 곳을 위험에 빠뜨리는 일이다. 그래서 수정은 언제나 "어디를(대상) 어떻게(방향)"의 형태로, 건드릴 곳만 집어서 지시한다.

약한 수정 지시와 강한 수정 지시를 비교하면 감이 온다.

오른쪽 지시들의 공통점은, 회의록의 형용사를 다룰 때 배운 것과 똑같다 — 형용사('자세히', '완성도')를 확인 가능한 행동으로 바꿨다. AI에게 일을 시키는 모든 국면에서 같은 원리가 반복된다. 좋은 프롬프트는 결국 형용사를 걷어내고 구체를 채운 프롬프트다.

[짚고 가기] 수정 루프는 가장 답답해지기 쉬운 지점이다. "고쳐줘 → 다른 데가 틀어짐 → 또 고쳐줘"의 무한 루프에 빠지곤 하는데, 원인은 대개 '다시 써' 식의 통짜 지시다. "한 번에 한 곳, 대상과 방향을 집어서"를 규칙으로 삼고, 위 비교표의 왼쪽을 오른쪽으로 바꿔 보는 연습을 해 보면 좋다. 여기서도 결국 '형용사를 측정 가능하게'라는 같은 기술이 다시 등장한다는 점을 알아두면, 장 전체가 하나의 원리로 꿰인다.

범위 결정: 제안받고, 사람이 자른다

범위 정하기를 통째로 AI에게 맡기면 안 된다. 회사 사정(오대표의 우선순위, 리버사이드 재즈 일정)은 AI가 모른다. 대신 제안을 시키면 좋은 재료가 나온다.

/pm @docs/PRD.md 의 기능 요구를 보고, 첫 버전에서 뺄 후보를 골라줘.
각 후보마다 "빼는 이유 / 대체 수단 / 나중에 붙일 때의 난이도"를 표로.
결정은 내가 한다.

이 프롬프트가 왜 좋은지 뜯어 보자. 앞에서 세운 '제안은 AI, 결정은 사람' 원칙이 문장에 그대로 녹아 있다. "뺄 후보를 골라줘"까지만 시키고 "무엇을 뺄지 정해줘"라고는 하지 않는다 — 결정을 넘기지 않은 것이다. 그리고 각 후보마다 요구하는 세 가지("빼는 이유 / 대체 수단 / 나중에 붙일 때의 난이도")가 정확히 범위를 정하는 세 기준과 짝을 이룬다. 사람이 판단할 때 필요한 재료를 미리 지정해 두는 것이다. 마지막 "결정은 내가 한다"는 한 줄은 AI에게 역할의 경계를 못 박는다 — "너는 상을 차려라, 고르는 건 내 몫이다".

제안을 받으면 사람이 결정을 내리고, 결정을 문서에 못 박는다.

결정했어. 로그인·좌석지정·알림·엑셀·환불자동화·입점은 첫 버전에서 뺀다.
마이티켓은 주문번호+이메일 조회로 대체한다.
@docs/PRD.md 의 '범위 제외' 절만 이 결정대로 갱신하고, 각 항목에 이유를 한 줄씩 붙여줘.
다른 절은 건드리지 마.

이 두 번째 프롬프트에서 역할이 완전히 뒤집힌 점을 보자. 첫 번째에서 AI는 '제안하는 역할', 사람은 '검토하는 역할'이었다. 두 번째에서 사람은 이미 '결정을 내린 상태'가 되었고("결정했어"), AI는 그 결정을 문서에 옮겨 적는 역할을 맡는다. 결정 자체는 사람이 내렸고, AI는 그걸 PRD에 정리해 넣을 뿐이다. "각 항목에 이유를 한 줄씩"이라는 지시가 중요한데, 이 이유들이 앞서 말한 '답변서'가 된다. AI에게 이유까지 다 짓게 하지 않고, 사람이 결정한 근거를 문서화하도록 시키는 것이다.

약한 지시와 강한 지시를 나란히 놓으면 차이가 뚜렷하다.

표의 세 번째 줄은 바로 위 '수정은 이 부분을 이렇게'와 같은 원리다. 결정을 문서에 옮길 때도 손댈 곳을 한 절로 좁혀 주면, 공들여 검토한 나머지 절이 흔들리지 않는다.

3.7 실습 — 온티켓 PRD를 만들고 범위를 확정한다

준비물: data/킥오프_회의록.md (승승장구 온티켓 킥오프 회의록). 회의록은 실제 회의록답게 형용사와 미결사항투성이다 — 일부만 보면 이렇다.

원하는 거:
- 우리 공연 티켓을 우리 사이트에서 직접 판매. 예쁘고 신뢰감 있게. (요즘 감성으로)
- 고객이 폰으로 3분 안에 결제까지 끝났으면 좋겠다고 함
- 매진되면 자동으로 못 사게 — 골목 라이브 때 초과 판매로 환불해주느라 난리났었음
- 환불도 사이트에서 되면 좋겠다 함 (공연 7일 전까지 전액, 이후 50%라는데 확정 아님)
...

이 짧은 조각만 봐도, 앞 절들에서 다룬 것들이 전부 들어 있다. "예쁘고 신뢰감 있게"는 디자인으로 넘길 형용사, "폰으로 3분 안에"는 측정 가능하게 바꿀 비기능 요구, "매진되면 못 사게"는 실패 경로를 챙길 기능 요구, "환불… 확정 아님"은 미결사항으로 남길 것. 실습은 이 회의록 전체를 상대로 지금까지 배운 것을 한 번에 적용하는 과정이다. 앞의 여섯 단계로 PRD를 만들어 검토하고, 마지막 두 단계에서 첫 버전의 범위를 결정해 PRD를 확정한다.

따라하기 1 — 회의록 확인하기

실습 폴더를 열 때 받은 data 폴더 안에 킥오프_회의록.md 가 이미 들어 있다. 왼쪽 탐색기에서 data/킥오프_회의록.md를 열어 한 번 훑어본다 — 형용사와 미결정이 뒤섞인 실제 회의록의 모습을 눈에 담아 두면, 다음 단계(PRD로 정리)가 왜 필요한지 와닿는다.

정리 습관 하나를 짚어 두자. 입력 데이터(회의록·CSV 등)는 data/에 들어 있고, 앞으로 만들 문서류(PRD·설계 메모)는 docs/에 저장한다. 'docs'는 documents(문서)의 줄임으로, 프로젝트의 문서를 한곳에 모으는 관례적 폴더 이름이다. 코드와 문서를 섞어 두면 나중에 찾기 어렵다 — 입력은 data/, 산출 문서는 docs/, 코드는 코드대로 나눠 두는 습관을 처음부터 들이면 프로젝트가 커져도 헤매지 않는다. (docs 폴더는 다음 단계에서 PRD를 저장할 때 자동으로 생긴다.)

따라하기 2 — PM 스킬을 만든다 (첫 스킬)

스킬 파일을 직접 타이핑하지 않는다. 만드는 것도 지시한다.

.claude/skills/pm/SKILL.md 로 PM 역할 스킬을 만들어줘. 내용은:

- 정체성: (주)승승장구의 PM. 산출물은 기획서가 아니라 팀이 실행할 완료 기준.
- 판단 기준: 측정할 수 없는 문장은 요구사항이 아니다 /
  결정 안 된 것을 확정하지 않는다 / 문서는 다음 작업자의 입력이다
- 절차: 요구 전부 나열 → 형용사를 측정 가능한 기준으로(불가하면 [미결]) →
  모순은 [충돌]로 질문화 → PRD 작성(배경·목표/사용자/기능 요구/완료 기준/
  범위 제외/미결사항) → 사람이 결정할 질문 목록 정리
- 금지: 입력에 없는 기능 추가 금지, 미결사항 멋대로 확정 금지,
  기술 스택·디자인 결정 금지
- description에는 "회의록·메모를 PRD로 정리할 때 사용"이라고 명시해줘.

위 프롬프트를 그대로 복사해 입력하면 된다. 다른 내용으로 바꿔서 해 보고 싶다면 자유롭게 바꿔도 좋다.

이 지시가 왜 이렇게 생겼는지 보자. 위 'PM 스킬의 설계'에서 잡은 세 덩어리(정체성·절차·금지)를 그대로 불러 주고, 마지막에 description까지 지정했다. 스킬을 만드는 지시 자체가 그 스킬의 목차인 셈이다. 이렇게 항목을 또박또박 나눠 주면, AI가 임의로 항목을 빼거나 순서를 바꾸지 않는다. 반대로 "PM 스킬 하나 만들어줘"라고만 하면, AI가 자기 나름의 PM 상(像)을 지어내 우리가 설계한 것과 다른 스킬이 나온다 — 여기서도 '빈칸을 남기지 않는다'는 이 장의 원리가 그대로 적용된다.

퍼미션을 승인하면 .claude/skills/pm/SKILL.md가 생긴다. 파일을 열어 읽어 보자. 내 지시가 어떤 구조로 담겼는지 확인하는 것 — 이것도 검토다. 마음에 안 드는 문구가 있으면 지금 고치게 시킨다.

파일을 열었을 때 확인할 것을 콕 집어 주면 이렇다.

• 맨 위에 ---로 감싼 description이 있고, "회의록·메모를 PRD로 정리"라는 문구가 들어갔는가
• 판단 기준·절차·금지 세 덩어리가 다 있는가
• 절차의 순서가 "요구 나열 → 형용사 변환 → 충돌 질문화 → PRD 작성 → 질문 목록"으로 되어 있는가

하나라도 빠졌거나 어긋났으면 "description이 빠졌어. '회의록·메모를 PRD로 정리할 때 사용'으로 넣어줘"처럼 위 '프롬프트 작성법'에서 본 방식(대상과 방향을 집어)으로 고치게 시킨다.

따라하기 3 — 스킬이 등록됐는지 확인한다

입력창에 / 를 치면 사용할 수 있는 명령 목록이 뜬다. 목록에 pm이 보이면 등록된 것이다. 우리 팀의 첫 팀원이 출근했다.

만약 목록에 pm이 안 보이면 대개 두 가지다. 첫째, 파일 경로나 이름이 틀린 경우 — 반드시 .claude/skills/pm/SKILL.md여야 하고 SKILL.md는 대문자다. 둘째, 프런트매터의 ---가 빠졌거나 형식이 깨진 경우 — 이러면 Claude Code가 스킬로 인식하지 못한다. "방금 만든 PM 스킬이 / 목록에 안 보여. 파일 경로와 프런트매터 형식을 점검해줘"라고 시키면 원인을 찾아 고쳐 준다.

따라하기 4 — PRD 초안을 만들게 한다

/pm @data/킥오프_회의록.md 이 회의록으로 온티켓 PRD 초안을 만들어서
docs/PRD.md 로 저장해줘.

위 프롬프트를 그대로 복사해 입력하면 된다. 다른 내용으로 바꿔서 해 보고 싶다면 자유롭게 바꿔도 좋다.

AI가 절차대로 일하는지 지켜보자 — 요구를 나열하고, 형용사를 바꾸고, 환불 정책 같은 미확정 건을 [미결]로 표시하는가. 끝에 "사람이 결정해야 할 질문 목록"을 내놓는가.

이 지시 한 줄에 위 '프롬프트 작성법'에서 정리한 요령이 다 들어 있다는 것을 보자 — /pm으로 스킬(역할)을 부르고, @data/킥오프_회의록.md로 입력 원본을 주고, "docs/PRD.md로 저장해줘"로 산출물의 형태와 위치를 지정했다. 스킬 안에 절차·판단 기준이 이미 담겨 있으니, 지시 자체는 이렇게 짧아진다. 장 첫머리에서 예고한 "PRD 한 장이 정확하면 그 뒤 지시가 짧아진다"의 축소판을, 스킬 단계에서 먼저 체감하는 셈이다.

따라하기 5 — 사람이 검토한다

docs/PRD.md를 직접 읽는다. 검토 관점 세 가지(빠진 것 / 더해진 것 / 남은 형용사)로 훑고, 대조 검토도 시킨다.

PRD를 회의록과 대조해서, 빠진 요구와 임의로 추가된 내용을 표로 보여줘.

위 프롬프트를 그대로 복사해 입력하면 된다. 다른 내용으로 바꿔서 해 보고 싶다면 자유롭게 바꿔도 좋다.

여기서 순서가 중요하다 — 사람이 먼저 눈으로 읽고, 그다음 AI 대조를 시킨다. AI 대조를 먼저 보면 그 결과에 생각이 끌려가, 사람이 스스로 발견했을 것을 놓친다. 내 눈으로 세 관점을 훑어 의심 가는 곳을 찜해 두고, 그다음 AI 대조 결과와 맞춰 보면 검토가 두 겹이 된다. AI가 놓친 것을 사람이, 사람이 놓친 것을 AI가 잡는다.

따라하기 6 — 수정 지시로 마무리한다

찾아낸 문제를 집어서 고친다. 예를 들면:

- "예쁘고 신뢰감 있게"가 완료 기준에 남아 있네. 디자인 결정은 이 단계에서
  하지 않기로 했으니 "디자인 토큰 문서를 따른다"로 바꿔.
- 환불 자동화는 미결사항으로 옮기고, 질문 목록에 "환불 정책 확정 요청(오대표)"을 추가해.

위 프롬프트를 그대로 복사해 입력하면 된다. 다른 내용으로 바꿔서 해 보고 싶다면 자유롭게 바꿔도 좋다.

두 수정 지시 모두 '수정은 이 부분을 이렇게'의 원칙 그대로 — 대상("예쁘고 신뢰감 있게", "환불 자동화")과 방향("디자인 토큰 문서를 따른다로 바꿔", "미결사항으로 옮겨")을 집었다. '다시 써'가 아니라 '이 부분을 이렇게'다. 그리고 두 번째 지시에서 질문 목록에 "(오대표)"라고 담당자를 붙인 것에 주목하자 — 미결은 그냥 미결로 두는 게 아니라 누가 정해 줘야 풀리는지까지 적어야 실제로 풀린다.

수정이 끝나면 PRD 마지막의 질문 목록을 확인한다. 이 목록이 다음 회의 때 오대표에게 들고 갈 안건이 된다 — AI가 못 정하는 것을 사람이 정하러 가는 것이다.

이 문장이 이 장을 꿰는 생각이기도 하다. AI는 회의록을 정리하고, 형용사를 숫자로 바꾸고, 빠진 것을 찾아 준다. 하지만 "환불을 7일 전으로 할지 5일 전으로 할지" 같은 결정은 AI가 대신할 수 없다. 그것은 우리 사정과 고객을 아는 사람의 몫이다. PRD 끝의 질문 목록은 바로 그 "사람만 정할 수 있는 것들"을 추려 놓은 것이고, 그것을 들고 오대표에게 가는 것까지가 PRD 초안 작업이다.

그런데 사람이 정할 것이 하나 더 남았다. 지금 PRD에는 회의록의 요구가 전부 들어 있다. 이대로 만들기 시작하면 오픈은 석 달 뒤다. 첫 버전에 무엇을 넣고 무엇을 뺄지 — 이 결정은 다음 회의까지 미룰 수 없다. 범위가 정해져야 화면도 데이터도 설계를 시작할 수 있기 때문이다. 그래서 지금 여기서 내린다.

따라하기 7 — 뺄 후보를 제안받는다

다음 프롬프트를 입력한다.

/pm @docs/PRD.md 의 기능 요구를 보고, 첫 버전에서 뺄 후보를 골라줘.
각 후보마다 "빼는 이유 / 대체 수단 / 나중에 붙일 때의 난이도"를 표로.
결정은 내가 한다.

위 프롬프트를 그대로 복사해 입력하면 된다. 다른 내용으로 바꿔서 해 보고 싶다면 자유롭게 바꿔도 좋다.

AI의 제안 표를 읽고 — 동의하는가? 온티켓의 사정(3일, 리버사이드 재즈, 오대표가 겪은 문제 3가지)을 떠올리며 내 결정을 내린다. AI 제안과 다르게 결정해도 좋다. 근거가 있다면 그쪽이 낫다.

제안 표를 읽을 때, 범위를 정하는 세 기준을 손에 쥐고 한 줄씩 따져 보자. "이건 핵심 가치 경로 위인가(1)? 대체 수단이 있나(2)? 나중에 붙이기 쉬운가(3)?" AI가 "빼자"고 한 항목이라도, 이 세 질문을 스스로 대 보고 납득이 되어야 뺀다. 납득이 안 되면 남긴다. 결정의 주인이 사람이라는 말은, 바로 이 "AI 말을 그대로 받지 않고 내 기준으로 다시 따진다"는 뜻이다.

따라하기 8 — 결정을 PRD에 못 박는다

다음 프롬프트로 PRD의 '범위 제외'를 갱신한다.

결정했어. 로그인·좌석지정·알림·엑셀·환불자동화·입점은 첫 버전에서 뺀다.
마이티켓은 주문번호+이메일 조회로 대체한다.
@docs/PRD.md 의 '범위 제외' 절만 이 결정대로 갱신하고, 각 항목에 이유를 한 줄씩 붙여줘.
다른 절은 건드리지 마.

위 프롬프트를 그대로 복사해 입력하면 된다. 다른 내용으로 바꿔서 해 보고 싶다면 자유롭게 바꿔도 좋다.

갱신된 PRD를 열어 확인한다 — 뺀 항목마다 이유가 붙어 있는가. 이유가 붙은 제외 목록은 나중에 "이거 왜 없어요?" 라는 질문(주로 오대표)에 대한 답변서가 된다.

여기서 퍼미션 요청을 잘 읽는 습관을 다시 살리자. AI가 PRD를 고치겠다며 퍼미션을 물을 때, 정말 '범위 제외' 절만 손대는지, 다른 멀쩡한 내용을 건드리진 않는지 미리보기를 훑는다. 첫 지시 때부터 들인 "읽고 누르는" 습관이 이런 문서 수정에서도 그대로 쓰인다.

여기까지 오면 docs/PRD.md는 초안이 아니라 확정된 PRD다. 무엇을 만들지, 언제 '됐다'고 할지, 무엇을 안 만들고 왜 안 만드는지가 한 문서에 들어 있다.

완료 기준 체크리스트

• .claude/skills/pm/SKILL.md가 존재하고, / 목록에 pm이 보인다
• docs/PRD.md가 존재한다
• PRD의 완료 기준에 측정 불가능한 형용사가 남아 있지 않다
• 환불 정책이 확정 사항이 아니라 미결사항에 들어 있다
• PRD의 '범위 제외'에 뺀 항목과 이유가 적혀 있다
• 마이티켓이 로그인이 아니라 주문번호+이메일 조회로 정의되어 있다
• "사람이 결정해야 할 질문 목록"을 설명할 수 있다

[짚고 가기] 실습에서 가장 흔히 막히는 세 곳. (1) 스킬이 / 목록에 안 뜬다 — 십중팔구 파일 경로·이름(SKILL.md 대소문자) 또는 프런트매터 --- 문제다. 스킬 등록을 확인할 때 본 두 가지 점검 항목을 다시 짚어 보면 스스로 진단할 수 있다. (2) PRD가 그럴듯해 보여 검토를 대충 넘기기 쉽다 — "회의록에는 있는데 PRD에 빠진 것"을 하나만 일부러 찾아보면, '빠진 것' 관점으로 실제로 대조하게 된다. (3) AI의 '뺄 후보' 표를 그대로 승인하고 넘어가기 쉽다 — 후보 하나를 골라 "나는 왜 이걸 빼는가"를 세 기준으로 한 줄 적어 보면, 승인이 아니라 결정을 하게 된다. 마지막 질문 목록은 소리 내어 설명해 보자. "이걸 오대표에게 뭐라고 물을 것인가"까지 말해 보면, PRD가 문서가 아니라 다음 행동의 입력임을 실감하게 된다.

3.8 정리

• AI에게 개발을 맡기는 시대에 기획 문서는 보고서가 아니라 AI 팀 전체의 입력값이다. 입력이 애매하면 AI는 빈칸을 무난한 것으로 채우고, 그 결과가 '어디서 본 듯한' 결과물이다.
• PRD의 뼈대: 배경·목표 / 사용자 / 기능 요구 / 완료 기준 / 범위 제외 / 미결사항. 완료 기준은 판정 가능해야 하며, 정하지 못한 것은 지어내지 않고 미결사항에 드러낸다.
• 핵심 기술은 형용사를 측정 가능한 기준으로 바꾸는 것이다. 이 기술은 보고서 지시, 교육 목표, 고객센터 운영 등 개발 밖에서도 그대로 쓰인다. 형용사를 만나면 "얼마나? 언제까지? 몇 번?"을 떠올리되, 근거 없는 억지 숫자는 오히려 미결로 남긴다.
• 반복되는 절차 + 역할 정체성은 스킬로 만든다. 역할 스킬의 3덩어리 — 정체성·절차·금지. 같은 3덩어리로 PM 말고 어떤 직무든 스킬이 되며, 스킬을 만드는 일 자체도 AI에게 시킨다.
• 초안은 반드시 사람이 검토한다. 볼 것은 세 가지 — 빠진 것, 더해진 것, 남은 형용사. 수정은 '다시 써'가 아니라 대상과 방향을 집어서. 그리고 사람만 정할 수 있는 것은 PRD 끝의 질문 목록으로 남겨, 사람이 결정하러 간다.
• 기획의 절반은 빼는 결정이다. 기준 세 가지 — 핵심 가치 경로인가, 대체 수단이 있는가, 나중에 붙이기 쉬운가. 빼는 것은 포기가 아니라 순서다.
• 범위 결정은 AI에게 맡기지 않는다. 제안은 AI, 결정은 사람. 결정은 이유와 함께 PRD의 '범위 제외'에 못 박는다. AI는 회사 사정을 모르고, 범위 결정은 되돌리는 데 비용이 많이 들며, 그 결정을 설명할 책임은 사람에게 있기 때문이다.
• 이렇게 확정된 docs/PRD.md가 다음 작업의 입력이다. 바로 다음 차례는 화면기획서 — 디자이너 역할이 이 PRD를 읽고 "어떤 화면에 무엇이 보여야 하는가"를 적는다. 범위에서 뺀 기능은 화면에도 나오지 않는다.