Claude Code의 프로덕트 총괄 Cat Wu가 빠르게 진화하는 모델 성능 앞에서 팀이 워크플로우와 로드맵을 어떻게 재정립해야 하는지 이야기한다.
2024년 10월 Claude Sonnet 3.5 (new) 출시 이후, 나는 새 모델이 나올 때마다 Claude Code(당시에는 사내 도구였다)를 이용해 Excalidraw에 테이블 기능을 추가하는 테스트를 습관처럼 반복했다. 매번 이전보다 조금씩 더 나아지긴 했지만, 끝내 성공하지는 못했다.
그러다 2025년 6월 Opus 4가 출시되면서 가끔씩 성공하는 수준까지 올라왔고, 결국 이 테스트는 Claude 4 모델 출시 행사의 사전 녹화 데모로 활용됐다. 최신 모델로 무엇이 가능해졌는지 보여주기 위해서였다.
1년도 채 지나지 않아, Opus 4.6은 수천 명의 현업 개발자들 앞에서 라이브로 시연해도 될 만큼 Excalidraw 기능 요청을 안정적으로 원샷 처리한다.
모델의 발전 속도는 가능성의 경계를 끊임없이 넓히고 있다. 전통적인 프로덕트 매니지먼트 방식은 프로젝트 시작 시점의 기술적 한계가 끝날 때까지 크게 달라지지 않는다는 전제 위에 세워졌다. PM은 미래에 대한 확신을 가지고 초반에 충분한 정보를 수집한 뒤, 수개월에 걸쳐 계획을 실행해 나갔다.
지수적으로 개선되는 모델은 이 전제를 무너뜨린다. 프로젝트를 설계할 때 고려했던 제약이 도중에 사라져버릴 수 있다. 발판 삼아 디딘 땅 자체가 올라가고 있는 셈이다. 팀은 이 현실에 맞게 재편해야 한다. 이제 프로덕트 매니지먼트의 새로운 리듬은 빠른 실험, 지속적인 출시, 그리고 효과 있는 것에 집중하는 것이다.
Anthropic의 프로덕트 매니저로서 가장 자주 받는 질문이 우리의 역할이 어떻게 변하고 있느냐는 것도 놀라운 일이 아니다. 내가 직접 경험하며 배운 것들을 공유한다.
나는 Scale AI, Dagster 같은 스타트업에서 프로덕트 엔지니어로 커리어를 시작했고, 이후 벤처 캐피털리스트로 일했다. VC로 재직하는 동안에도 코드를 직접 짰는데, 신생 기업 발표를 X에서 스캔하거나 오픈소스 프로젝트의 성장 모멘텀을 감지하는 등 반복적인 업무를 자동화하기 위해서였다.
2024년 8월, 나는 Anthropic에 리서치 PM 팀의 프로덕트 매니저로 합류했다. 리서치 PM 팀은 연구팀과 실제 고객 사이를 연결해 더 나은 모델을 만드는 역할을 한다. 그해 가을 Claude Code를 사내에서 사용할 수 있게 되면서, 나는 대규모 사용자 피드백 분석을 위한 Streamlit 앱 구축이나 새로운 신뢰할 만한 벤치마크를 찾는 평가(evaluation) 실행처럼 수동 작업이 많은 업무를 빠르게 처리하는 데 활용했다. 진입 장벽이 낮다 보니 RL 환경을 만들어 학습 과정을 직접 파악하는 등 본래 역할을 넘어 다양한 실험도 할 수 있었다.
이 프로젝트들은 Sonnet 3.5 (new) 기반의 Claude Code와 수백 시간의 프롬프팅으로 완성됐다. 직접 손으로 작성한 코드는 단 한 줄도 없었다.

내 워크플로우를 지탱하는 건 Claude Code만이 아니다. 시간이 지나면서 세 가지 제품 사이에 자연스러운 역할 분담이 자리를 잡았다. 대화형 협업 도구인 Claude.ai, 에이전틱 코딩 도구인 Claude Code, 그리고 지식 업무 도구인 Cowork다.
Claude.ai는 Claude를 직접 실행하지 않고 사고 파트너로 대화할 때 활용한다. 전략 문서 아이디어를 다듬거나, 까다로운 상황을 어떻게 풀어갈지 논의하고, 빠른 답을 구할 때 쓴다.
Claude Code는 프로토타입, 평가, 스크립트를 만들 때 쓴다. Claude API를 호출하는 코드도 여기서 작성한다. 결과물이 코드일 때는 Claude Code를 사용한다.
Cowork는 그 외 모든 업무를 처리하는 공간이다. 받은 편지함을 비우거나, 할 일 목록을 관리하고, 슬라이드를 만들거나, Slack을 검색해 의사결정의 맥락을 파악하고, 출장 예약까지 여기서 한다.
업계의 다른 프로덕트 매니저들과 이야기해보니, 각자의 방식으로 비슷한 워크플로우를 만들어 가고 있었다.
"Claude는 뛰어난 제품 팀이 만들 수 있는 것의 한계를 높이고, 아이디어에서 프로토타입까지의 거리를 획기적으로 단축했습니다. 고객에게 실체 있는 무언가를 보여주려면 몇 주에 걸친 개발이 필요했는데, 이제는 Claude Cowork에서 Slack, 코드베이스, 문서 등 맥락을 불러와 시작한 뒤 Claude Code로 넘어가면 몇 시간 안에 데모 가능한 수준의 결과물이 나옵니다. 좋은 제품 팀이 항상 실제 고객과 아이디어를 검증해온 건 변하지 않았습니다. 달라진 건 그 루프에 올릴 수 있는 고품질 아이디어의 수가 훨씬 늘었다는 점입니다." — Bihan Jiang, Decagon 프로덕트 총괄
"저에게 AI 네이티브 세계에서의 PM이란 창의적인 동시에 학문적인 일입니다. 새 모델이 나올 때마다 가능한 것이 달라지고, Datadog의 Bits AI SRE 에이전트를 구축하는 과정에서는 실제 프로덕션 장애 사례를 바탕으로 오프라인 평가를 진행해 모델의 강점과 실패 패턴을 파악합니다. 또한 에이전트가 어려움을 겪는 지점을 UX에서 드러낼 수 있도록 피드백 루프를 촘촘하게 설계하고, 그 인사이트를 제품 개선으로 이어가고 있습니다. 그런 의미에서 PM의 역량은 초반에 확실성을 정의하는 것에서, 발견의 속도를 높이는 것으로 이동했습니다." — Kai Xin Tai, Datadog 시니어 프로덕트 매니저
오늘날 프로덕트 매니저로서 가장 흥미로운 점 중 하나는, 이 워크플로우가 계속 진화하면서 우리에게 더 큰 레버리지를 안겨준다는 사실이다.

METR 조사에 따르면, Opus 4.6는 약 절반의 확률로 사람이 거의 12시간이 걸리는 소프트웨어 작업을 완료할 수 있다. Claude Code를 처음 만들기 시작했을 때의 최신 모델은 Sonnet 3.5 (new)였고, 당시 METR 측정 결과 사람 기준으로 약 21분짜리 작업을 처리할 수 있는 수준이었다. 16개월 만에 약 41배가 늘어난 셈이다.
Claude Code 팀은 모델이 빠르게 발전하는 속도에 맞춰 함께 진화해왔다. 역할의 경계도 자연스럽게 섞였다. 디자이너가 코드를 배포하고, 엔지니어가 제품 결정을 내리고, 프로덕트 매니저가 프로토타입을 만들고 평가를 설계한다. 명확한 전략과 목표가 있기 때문에 누구나 자율적으로 우선순위를 판단할 수 있어서 가능한 일이다. 프로덕트 매니저의 역할은 빠른 모델 발전이 만들어내는 모호함 속에서 방향을 명확하게 제시하고, 팀이 가능성에 대해 더 크게 생각하도록 이끌며, 더 빠르게 출시할 수 있도록 길을 여는 것이다.
우리가 실천해온 네 가지 변화를 소개한다.
짧은 스프린트로 계획하기
전통적인 프로덕트 매니지먼트에서는 탐색이 로드맵을 확정하기 전에 끝나야 하는 단계였다. 조사를 마치고, PRD를 작성한 뒤, 엔지니어링 팀에 넘기는 방식이었다.
우리는 장기 로드맵 대신, 팀원 모두(엔지니어, 프로덕트 매니저, 디자이너)가 '사이드 퀘스트'를 자율적으로 수행하도록 장려한다. 사이드 퀘스트란 공식 로드맵 밖에서 스스로 설계하는 짧은 실험이다. 오후 한나절을 써서 아이디어를 프로토타입으로 만들거나, 불가능하다고 생각했던 기능을 테스트하거나, 모델을 예상보다 더 세게 밀어붙여보는 식이다.
Anthropic에서 가장 인기 있는 기능들, Claude Code on Desktop, AskUserQuestion 도구, 할 일 목록이 모두 이런 방식으로 탄생했다.
문서 대신 데모와 평가를 중심에 두기
우리 팀은 문서 우선에서 프로토타입 우선으로 사고방식을 바꿨다. 전통적인 스탠드업 대신 새로운 아이디어의 데모를 공유한다. 사내 사용자들이 직접 써보고, 실제 반응이 있는 것만 다듬어 더 넓게 공유한다. 오후 한나절이면 프로토타입을 만들 수 있으니, 틀린 방향에 베팅하더라도 비용이 크지 않다.
예를 들어 Noah가 플러그인 스펙을 Claude Code에 넘겼더니, 돌아온 프로토타입이 거의 프로덕션 수준에 가까웠다. 그 프로토타입이 UX를 빠르게 검증할 수 있게 해줬고, 팀이 최종적으로 출시한 기능의 기반이 됐다.
팁: 스펙을 작성했다면 Claude Code에 넘겨서 직접 만들어보게 해라. 거친 프로토타입 하나가 논의의 질을 완전히 바꿔놓는다.
데모 외에도 평가는 추상적인 제품을 구체화하는 데 도움이 된다. 예를 들어, 여러 Claude Code 인스턴스를 함께 조율하는 에이전트 팀 기능의 경우, Conner가 평가 세트를 직접 설계해 에이전트 팀이 잘 작동하는 조건, 실패하는 조건, 그리고 개선 방향을 파악했다. 기능이 제대로 작동하는지 측정할 수 있어야 개선도 빨라진다.
새 모델이 나오면 기존 기능 다시 보기
이제는 기능을 출시하고 나서 더 뛰어난 모델이 나오면, 그 기능이 한 단계 도약할 기회가 생긴다. 모델이 새로 나올 때마다 이미 만든 것을 다시 돌아보라는 신호로 받아들여야 한다.
이런 순간을 포착하는 가장 좋은 방법은 매일 직접 사용하면서 '이건 아직 못 하겠지'라고 생각하는 작업을 의도적으로 시켜보는 것이다. 가끔은 된다. 그게 곧 제품이 따라잡아야 한다는 신호다.
Chrome과 연동된 Claude Code도 그렇게 탄생했다. 사용자들이 Claude Code로 웹 앱을 만든 뒤, 테스트를 위해 Chrome의 Claude로 수동으로 전환하는 패턴을 발견한 것이다. 두 도구 사이를 오가며 직접 프롬프팅하고 복붙을 반복하고 있었다. 그 방식이 꽤 잘 작동한다는 게 눈에 들어왔고, 이건 제품에 기본 탑재돼야 한다고 판단했다. 사용자가 직접 임시방편으로 엮어내고 있다면, 그 발판을 제품으로 만들면 된다.
아이디어를 프로토타입으로 만들 때는 항상 기능 구현을 최우선으로 삼아라. 생각보다 많은 토큰을 써도 좋다. 초반에 토큰 비용을 너무 일찍 줄이려다 훨씬 성능이 낮은 결과물을 출시하는 실수를 흔히 본다. 비용은 더 저렴한 모델이 따라잡으면서 나중에 얼마든지 낮출 수 있다. 하지만 먼저 그 기능 자체가 가능한지부터 확인해야 한다.
단순한 것을 선택하기
Anthropic 전체 팀을 관통하는 원칙이 있다. 작동하는 가장 단순한 방법을 선택하라는 것이다.
모델의 한계를 영리하게 우회하도록 설계된 제품은, 다음 모델이 나오는 순간 그 우회책이 불필요한 복잡성으로 남는다. '단순한 것을 선택하라'는 원칙이 중요한 이유가 여기 있다. 구현이 단순할수록 새로운 기능으로 교체하기도 쉽다.
처음 Claude Code에 할 일 목록을 도입했을 때, 모델이 항목을 완료하면서 체크하는 동작이 안정적이지 않았다. 그래서 몇 메시지마다 에이전트가 자신의 할 일 목록을 업데이트하도록 유도하는 시스템 알림을 추가했다. 효과는 있었지만 일종의 임시방편이었다. 다음 모델에서는 그 동작이 별도 처리 없이도 자연스럽게 이뤄졌고, 알림을 완전히 걷어낼 수 있었다. 이런 패턴은 반복해서 나타났다. 모델의 한계를 보완하기 위해 정교하게 다듬어졌던 시스템 프롬프트와 도구 설명이, 모델이 발전할수록 단순해지고 있다. Opus 4.6에서는 프롬프팅을 20% 줄이는 것도 가능했다.
많은 프로덕트 매니저들이 제품 경험 전반을 촘촘하게 통제하는 방식에 익숙하지만, AI 시대에는 빠르게 움직이려면 일정 부분 놓아줄 수 있어야 한다. AI 제품을 만드는 일은 파도를 서핑하는 것과 비슷한데, 가장 중요한 건 파도에서 떨어지지 않는 것이다. 완벽주의자인 내게 이 변화에 적응하는 것이 가장 힘들었지만, 지금 프로덕트 매니저의 역할은 진짜 타협할 수 없는 몇 가지를 정하고 나머지는 내려놓는 것이다.
이런 변화들이 쌓이면 제품 팀의 속도가 눈에 띄게 빨라진다. 프로덕트 매니저가 오후 한나절에 아이디어를 작동하는 프로토타입으로 만들 수 있다면, "이런 거 해보면 어떨까?"와 "자, 한번 써봐"사이의 간격이 거의 사라진다.
Anthropic에서 Claude로 워크플로우를 바꾼 건 프로덕트 매니저만이 아니다. 데이터 사이언스, 재무, 마케팅, 법무, 디자인 팀이 각자 주도적으로 이 도구들을 도입했다. 누군가의 결과물을 기다리는 시간 없이, 조직 전체가 같은 속도로 움직인다.
지금 PM의 역할은 두 가지를 동시에 추적하는 것이다. AI가 일하는 방식을 어떻게 바꾸고 있는지, 그리고 제품에서 무엇이 가능해지고 있는지. 이 두 가지를 잘 포착한다면, 테이블 기능이 마침내 작동하는 순간에 놀라지 않을 것이다. 그 가능성을 먼저 내다본 사람이 되어 있을 테니.
지금 바로 Claude Code로 더 나은 제품을 만들어보세요.
글쓴이: 이 글은 Anthropic에서 Claude Code 프로덕트 총괄을 맡고 있는 Cat Wu가 작성했습니다. X와 LinkedIn에서 만나볼 수 있습니다. 이 글에 기여해준 Bihan Jiang과 Kai Xin Tai에게 감사드립니다.