Product Manager로 업무를 해오면서 수많은 변화를 겪었다. 하지만 이번에는 정말 다르다. 기존의 PM의 업무 방식과 직군을 철저하게 다시 들여다 봐야할 때이다. 그래서 오늘은 PM이 AI 시대에 어떻게 변화를 해야하는지에 대한 부분에 포커스하여 정리해보고자 한다.
Cat Wu는 PRD를 쓰지 않는다. 대신 프로토타입을 만든다. todo list 기능 하나에 2일 동안 약 20개를 빌드했다. 자연어 prompt를 바꿔가며 수십 분 안에 비교 테스트를 끝낸 결과다.
이 한 문장이 PM 실무 전체를 흔든다. Boris Cherny는 The Pragmatic Engineer 인터뷰에서 단호하게 말했다.
“PRDs are dead on the Claude Code team: prototypes replaced them.”
PRD는 빌드 비용이 비쌌던 시절의 도구다. “한 번 잘못 만들면 2주가 날아간다”는 전제 위에서, 미리 합의문을 쓰는 것이 합리적이었다. 그런데 프로토타입을 한두 시간 안에 만들 수 있다면 어떻게 될까. 합의문보다 학습 속도가 더 중요해진다. 계획이 병목이 된다.
PM 직무는 이 전환점 위에 있다. 무엇이 어떻게 바뀌는지, Cat Wu(Claude Code 창립 PM)와 Boris Cherny(Head Member of Technical Staff)의 1차 발언으로 정리한다.
“능력은 일정하다”는 가정이 무너진 이유
전통 PM의 모든 활동은 한 가지 가정에 기반했다. 프로젝트가 진행되는 동안 도구의 능력은 일정하다는 가정이다. 6개월짜리 로드맵을 짤 수 있는 것도, 분기별 OKR을 세울 수 있는 것도 이 가정 덕분이었다.
Cat Wu는 Anthropic 공식 블로그에서 이 가정을 정면으로 부정한다.
“The constraints you designed around might disappear mid-project.”
Wu는 동일한 작업(“Excalidraw에 테이블 도구 추가”)을 모델별로 반복 테스트했다. 결과는 다음과 같다.
| 시점 | 모델 | 결과 |
|---|---|---|
| 2024년 10월 | Sonnet 3.5 | 일관되게 실패 |
| 2025년 6월 | Opus 4 | 가끔 성공 |
| 16개월 후 | Opus 4.6 | 안정적 one-shot 성공 |
METR 데이터에 따르면 Opus 4.6은 12시간짜리 소프트웨어 작업을 약 절반 시간에 완료한다. 16개월 만에 모델 능력이 21분 작업에서 12시간 작업으로, 약 41배 향상됐다.
이 사실이 PM 업무에 의미하는 바는 분명하다. “오늘 불가능한 것”을 전제로 6개월 PRD를 쓰면, PRD 마감 시점에 그 전제 자체가 무너져 있을 수 있다. Wu는 이를 “AI exponential”이라고 부른다. 능력 자체가 프로젝트 도중에 변하는 환경에서, PM의 가장 중요한 스킬은 합의문 작성이 아니라 변화에 빠르게 적응하는 것이 된다.
PM이 코드를 쓴다 — Member of Technical Staff라는 이름의 의미
Anthropic 전사는 단일 직함을 쓴다. “Member of Technical Staff”다. PM도, 엔지니어도, 디자이너도 모두 같은 베이스 직함을 공유한다. Boris의 공식 직함은 “Head Member of Technical Staff, Claude Code”다.
Boris는 그 의미를 이렇게 설명한다.
“Everyone codes. Our product manager codes, our engineering manager codes, our designer codes.” (Roger Wong 정리)
Cat Wu는 같은 원칙을 PM 관점에서 풀어낸다.
“Designers ship code, engineers make product decisions, product managers build prototypes and evals.” (Anthropic 공식)
여기서 핵심은 PM이 “프로토타입과 eval을 빌드한다”는 표현이다. 단순히 “코드를 짤 줄 안다”가 아니라, PM 업무의 산출물 자체가 바뀌었다는 뜻이다.
| 전통 PM 산출물 | Agentic PM 산출물 |
|---|---|
| PRD 문서 | 작동하는 프로토타입 |
| 사용자 인터뷰 정리 | eval 데이터셋 |
| 우선순위 스프레드시트 | 내부 출시된 기능 |
| 분기별 로드맵 | 1주 단위 데모 |
Boris의 단일 직함 철학은 형식적 통일이 아니다. 행동 지침으로 작동한다.
“It kind of inverts this relationship between people, even if you don’t know each other well yet.” (Pragmatic Engineer)
그림 1. Boris Cherny (Anthropic Head Member of Technical Staff, Claude Code) — “Everyone codes. PM도 엔지도 디자이너도 코드를 ship한다” (출처: Building Claude Code with Boris Cherny, The Pragmatic Engineer)
타이틀이 같으니 누구나 product, design, infrastructure, research에 손을 댈 수 있다는 기본 가정이 작동한다. 핸드오프(handoff)가 사라진다. PM이 PRD를 쓰고 엔지가 구현하고 디자이너가 mockup을 그리는 동안 흘러가던 시간이, AI 도구가 한 사람이 여러 직무를 직접 ship하게 만들면서 그대로 회수된다.
프로토타입 20개 vs PRD 한 장 — 무엇이 더 효율적인가
todo list 기능 사례는 Agentic PM의 작동 방식을 가장 잘 보여준다. Boris는 2일 동안 약 20개 프로토타입을 빌드했다. 검토된 후보 일부는 다음과 같다.
- 입력창 위 고정 todo
- 인라인 진행 표시
- 백그라운드 태스크처럼 보이는 인터랙티브 pill
- 수직 구분선이 있는 사이드 드로어
- 애니메이션 드로어 전환
- “…and X more” 잘림 표시
- 다양한 스피너 위치
- 최종 채택: CTRL+T로 토글되는 버전
자연어 prompt만 바꾸면 수십 분 안에 비교 테스트가 끝난다. 전통 디자인-엔지 핸드오프 구조에서는 1주에 mockup 2~3개가 한계인 작업이다.
Cowork 사례는 더 극적이다. Claude Code 위에서 약 10일 만에 빌드된 이 제품은, 출시 직후 성장 속도가 Claude Code 자체를 능가했다. Boris는 이 제품에 대해 다음과 같이 말한다.
“There’s just no way we could have shipped this if we started with static mocks and Figma or if we started with a PRD.” (Pragmatic Engineer)
여기서 PM이 던져야 할 질문이 바뀐다. “이 PRD가 정확한가”가 아니라 “이 프로토타입을 사람들이 실제로 쓰는가”이다. Aakash Gupta는 이 전환을 한 줄로 정리했다.
“Most product processes optimize for reducing risk before building. Anthropic flips this. They optimize for speed to learning.” (Aakash Gupta)
PRD는 리스크 최소화 도구다. 빌드 비용이 높을 때 합리적이다. 그러나 빌드 비용이 1시간이라면 합의문 작성에 1주를 쓰는 것이 오히려 비합리적이 된다. 프로토타입이 곧 스펙이다(The prototype becomes the spec).
Antfooding — 5분마다 내가 만든 걸 쓴다
Anthropic 직원은 자신을 “ants”라고 부른다. 도그푸딩(자기 제품을 자기가 쓰는 것)을 종교적으로 강조한 표현이다. 이 antfooding 루프는 PM 검증 방식을 근본적으로 바꿨다.
작동 원리는 간단하다.
- 엔지가 기능을 ship하면 즉시 슬랙 채널에 알린다
- 동료들이 5분 안에 써보고 피드백을 던진다
- 같은 날 안에 롤백 또는 정제 결정이 난다
Cat Wu의 표현으로 정리하면 한 줄이다. “Ship demos, not docs.”
이 루프가 PM에게 의미하는 것은 명확하다. 사용자 인터뷰 → 페르소나 작성 → A/B 테스트 설계라는 전통 검증 사이클이, “내가 직접 써보고 5분 안에 판단”으로 압축된다. 데이터는 이 압축을 뒷받침한다.
| 지표 | 1년 전 | 현재 | 변화 |
|---|---|---|---|
| Claude 활용 업무 비중 | 28% | 60% | +114% |
| 자가 보고 생산성 향상 | +20% | +50% | 2.5배 |
| 태스크 복잡도 (5점 척도) | 3.2 | 3.8 | +0.6 |
출처: Anthropic 리서치
여기서 흥미로운 데이터가 있다. Claude 보조 작업의 27%는 “Claude 없었으면 안 했을 작업”이라는 응답을 얻었다. AI는 단순히 기존 업무를 빠르게 처리하는 도구가 아니라, 할 수 없던 일을 가능하게 만드는 보완재라는 의미다.
PM 입장에서 이는 곧 검증 가능한 가설의 폭이 늘어난다는 뜻이다. 전에는 “이건 빌드 비용이 너무 비싸서 검증을 포기”했던 가설을, 지금은 오후 한나절 안에 프로토타입으로 검증할 수 있다.
PM 1명이 엔지니어 N명을 어떻게 지원하는가
전통적으로 PM 1명은 엔지니어 5명을 담당하는 것이 기본 비율이었다. 회의·문서·우선순위 정리에 PM 시간이 다 쓰였기 때문이다. Anthropic의 운영 데이터는 이 비율 자체가 무의미해질 수 있음을 시사한다.
Anthropic 전사 데이터로는 엔지니어 1인당 머지된 PR이 67% 증가했다. Claude Code 팀 평균은 1인 1일 5 PR로, 업계 평균(1~2 PR)의 2.5~5배다. Boris 본인은 1일 10~30 PR을 ship하며, 30일에 259 PR을 기록한 적도 있다.
엔지니어 처리량이 2~3배 늘면 PM 1명이 지원할 수 있는 엔지니어 수도 비례해 줄어든다. 5명 지원이 한계였다면, 같은 시간으로 2~3명만 지원해도 처리량은 같다는 계산이 가능하다.
여기서 PM 직무의 재설계가 필요하다. Cat Wu의 PM 핵심 권고 4가지를 보면 방향이 보인다.
- 짧은 스프린트 + self-directed 사이드 퀘스트. Claude Code Desktop, AskUserQuestion 툴, todo lists는 모두 사이드 퀘스트에서 출시된 기능이다.
- Demos over documentation. 문서로 설명하지 말고 데모로 보여라.
- 모델 신규 출시 시 기존 기능 재방문. 이전에 못 하던 일이 가능해질 수 있다.
- “Do the simple thing.” 모델이 좋아질수록 workaround는 obsolete가 된다.
Wu의 가장 솔직한 자기 보고는 다음과 같다.
“[가장 어려운 적응은] 빠르게 움직이기 위해 놓아주는 것(letting go in order to move quickly)이었다 — 불완전성에 대한 편안함과 제품 경험에 대한 통제 완화가 필요했다.” (Anthropic 공식)
“통제를 놓아주는 능력”이 새 PM 핵심 스킬이다. PM 1명이 5명을 빠듯하게 통제하던 모델에서, PM 1명이 자기 권한을 엔지에게 넘기고 자신은 프로토타입과 eval을 직접 빌드하는 모델로 옮겨가는 중이다.
PM이 매일 운용하는 4종의 에이전트
Anthropic 공식 블로그에서 Claude Managed Agents PM Jess Yan은 자신이 매일 운용하는 에이전트 4종을 공개했다. 이 사례는 일반 PM이 즉시 적용할 수 있는 가장 구체적인 그림을 보여준다.
- 사전 출시 API 시제품화 에이전트. PRD가 아니라 같은 날 오후 안에 작동하는 프로토타입을 빌드한다.
- 어답션 분석 에이전트. 내부 DB를 쿼리해 사용 패턴을 식별하고, 메모리로 학습을 누적한다.
- 개발자 정서 모니터링 에이전트. 웹 검색 툴로 다중 소스를 병렬 조사해 종합한다.
- 데모 빌더 에이전트. 컨퍼런스나 고객 미팅용 데모를 템플릿에서 자동 생성한다.
Yan의 핵심 명제는 두 줄로 요약된다.
“On the AI exponential, we build with what we ship.”
“My work feels more human than ever.”
두 번째 인용이 특히 중요하다. AI가 PM 직무를 자동화한다는 공포 서사를 정면으로 뒤집는 1차 자료다. AI는 PM의 craft를 위협하기보다, 운영 오버헤드를 흡수해 craft에 더 많은 시간을 돌려준다.
PM이 회의·문서·반복 정리에 쓰던 시간이 줄어들면, 그 시간은 어디로 가는가. Yan의 답은 분명하다. 더 깊은 고객 인사이트, 더 복잡한 의사결정, 더 미묘한 디자인 판단. AI에 위임 가능한 것이 늘어날수록, 위임 불가능한 영역의 가치가 더 선명해진다.
일반 PM이 지금 당장 적용할 수 있는 5가지
Anthropic 모델을 통째로 이식할 필요는 없다. 핵심 행동 변화 5가지만 옮겨도 의미가 있다.
첫째, PRD 길이를 절반으로 줄이고 프로토타입을 두 배로 늘린다. 10페이지 PRD 대신 1페이지 의도 메모를 쓴다. 같은 날 오후에 첫 프로토타입을 ship한다. 5분 피드백 루프를 돌린다. 빌드 비용이 1시간이라면 합의문 작성에 1주를 쓰는 것은 비합리적이다.
둘째, Plan 모드를 강제한다. Boris의 워크플로우는 plan 모드로 시작한다. “잘 정의된 계획이 있으면 1-shot으로 끝난다”는 경험적 관찰 위에 작동한다. 모든 PR은 plan 산출물(요구·접근·검증 단계)을 먼저 commit하고, 검토가 끝나면 auto-accept로 구현한다.
셋째, 1인당 토큰 예산을 명시한다. Boris의 권고는 단호하다. “엔지니어에게 가능한 한 많은 토큰을 줘라.” 비용 최적화는 행동 패턴이 안정된 후로 미룬다. 토큰 예산이 부족하면 ‘Underfunding’ 효과가 작동하지 않는다.
넷째, antfooding 채널을 만든다. 슬랙이나 디스코드에 신규 기능 전용 채널 1개를 만든다. 엔지가 ship 즉시 알리고, 5분 안에 동료 1~3명이 써본다. 같은 날 안에 롤백 또는 정제 결정을 내린다. 단, 이는 자기 회사 제품을 절대 다수가 사용하는 환경에서만 작동한다. SaaS·B2B 도구라면 가능하다.
다섯째, PM이 직접 코드/프로토타입에 손을 댄다. Cat Wu의 표현대로 “PM이 prototypes and evals를 빌드”한다. Claude Code, Cursor 같은 도구를 PM이 직접 쓰는 것은 이제 선택이 아니다. 일주일에 한 번이라도 직접 ship해보지 않으면, 엔지가 무엇을 ship할 수 있는지 감이 사라진다.
이 5가지는 모두 도구 도입이 아니라 행동 변화다. 도구를 사도 행동을 바꾸지 않으면 효과는 0에 가깝다. 토큰 예산을 늘려도 PM이 여전히 PRD를 10페이지 쓴다면 아무것도 바뀌지 않는다.
한계 — 이 모델은 모든 조직에 맞지 않는다
Anthropic의 운영 모델을 무비판적으로 받아들이면 위험하다. 외부 데이터와 자기 인정 한계가 분명히 있다.
첫째, DORA 메트릭이 변하지 않을 수 있다. Faros AI 분석에 따르면 같은 팀에서 처리한 태스크는 21% 늘고 머지된 PR은 98% 늘었지만, DORA 4지표(배포 빈도·리드 타임·실패율·복구 시간)는 유의미하게 변하지 않았고, 코드 리뷰 시간은 91% 증가했다. 양적 처리량과 질적 가치 전달은 다른 문제다.
둘째, 위임 한계가 50%+ 엔지에서 0~20%에 머문다. Anthropic 자체 리서치는 이 한계를 인정한다. 핵심 의사결정과 미묘한 디자인은 여전히 인간 판단을 요구한다. PM 입장에서는 “AI에 다 맡기면 된다”는 환상이 통하지 않는다는 뜻이다.
셋째, 시니어 한정 패턴이 다수다. Boris의 5~20개 병렬 에이전트 운영, “100% AI 코딩”은 ① 깊은 도메인 지식, ② 빠른 컨텍스트 스위칭, ③ 결과를 폐기할 결단력을 가진 시니어에게 효과적이다. 주니어 PM이 그대로 모방하면 검증되지 않은 의사결정이 production에 도달할 위험이 크다.
넷째, 적용 한계가 분명하다. Aakash Gupta가 명시적으로 지적한 4가지 한계는 다음과 같다.
| 한계 영역 | 사례 |
|---|---|
| 복잡한 통합 | 금융 결제, 의료 EMR 통합 |
| 규제 산업 | SOC2, HIPAA, GDPR 변경관리 감사 |
| 고위험 제품 | 내부 프로토타입 실패가 즉시 사용자 위험 |
| 약한 도그푸딩 문화 | 공격적 내부 테스트 미지원 |
다섯째, 학습 손실 리스크가 있다. Anthropic 직원의 자가 인용은 무겁다.
“When producing output is so easy and fast, it gets harder and harder to actually take the time to learn something.”
“More junior people don’t come to me with questions as often.”
AI가 일을 빠르게 끝내면 부수적 학습(collateral learning)이 사라진다. 결국 감독에 필요한 스킬도 위축된다. 이는 장기적으로 조직 역량 자체를 갉아먹을 수 있는 리스크다.
이 5가지 한계를 인정한 위에서, 자기 조직에 맞는 변형을 설계하는 것이 합리적이다. Anthropic 모델을 100% 이식하려는 시도보다, 자기 도메인의 제약을 인정하고 적용 가능한 부분만 가져오는 것이 안전하다.
결국 PM에게 무엇이 남는가
Cat Wu의 한 문장으로 돌아가본다.
“Letting go in order to move quickly.”
빠르게 움직이기 위해 통제를 놓아주는 것. 이것이 새 PM 핵심 스킬이다. 그동안 PM의 가치는 통제 능력에 있었다. 우선순위를 통제하고, 스펙을 통제하고, 일정을 통제했다. AI exponential은 이 모델을 무너뜨린다. 능력이 프로젝트 도중 변하는 환경에서 통제는 비용이고, 학습 속도가 자산이다.
PM에게 늘어나는 것과 줄어드는 것을 정리하면 다음과 같다.
| 줄어드는 것 | 늘어나는 것 |
|---|---|
| PRD 작성 | 프로토타입 빌드 |
| 우선순위 회의 | 직접 도그푸딩 |
| 핸드오프 문서 | eval 데이터셋 설계 |
| 분기 로드맵 | 모델 능력 추적 |
| 통제 | 품질 판단 |
당장 실천할 한 가지를 고른다면 이렇다. 이번 주에 PM이 직접 프로토타입 1개를 ship한다. PRD 대신 작동하는 무엇을 만들어 슬랙에 올리고, 5명 이상의 동료에게 5분 안에 써보게 한다. 그 결과를 다음 PRD에 반영한다.
Boris의 마지막 인용으로 마무리한다.
“If you can do something today, you should just do it today.”
오늘 할 수 있다면 오늘 한다. PM 일에서 “다음 분기 로드맵에 넣어두자”는 답은 점점 비효율이 된다. 솔직히 이 변화가 모든 조직에 가능하다고 보지는 않는다. 그러나 자기 도메인에서 가능한 부분만큼이라도 옮기지 않으면, 6개월 사이클을 1일로 압축한 팀과의 격차는 매년 벌어질 수밖에 없다.
비슷한 적용을 시도해본 적이 있다면, 어디서 막혔는지 의견을 들어보고 싶다.
참고 자료
- Product management on the AI exponential — Cat Wu, Anthropic
- Product development in the agentic era — Jess Yan, Anthropic
- How AI is transforming work at Anthropic — Anthropic Research
- Measure Claude Code’s impact with contribution metrics — Anthropic
- How Claude Code is built — Gergely Orosz, The Pragmatic Engineer
- Building Claude Code with Boris Cherny — The Pragmatic Engineer
- The Way Anthropic Builds Products is Wild — Aakash Gupta
- Boris Cherny and Cat Wu: Anthropic’s Batman and Robin — Fernando Comet, Design Bootcamp
- What happens after coding is solved | Boris Cherny — Roger Wong
- How Anthropic’s product team moves faster than anyone else | Cat Wu — Lenny Rachitsky 팟캐스트
