Anthropic의 제품팀은 어떻게 누구보다 빠르게 움직이는가 | Cat Wu (Claude Code 제품 총괄)

Chapter 1: Cat Wu 소개와 Boris와의 협업 (00:00-04:30)

[01:42] Cat Wu는 Anthropic의 Claude Code와 Cowork 제품 책임자로, 제품 팀의 빠른 실행과 변화하는 PM 역할의 중심에 있다.
[02:17] 기술 리드 Boris Cherny는 3~6개월 뒤 제품이 어떤 모습이어야 하는지 정하는 비전가이며, Cat은 그 비전까지 가는 경로를 설계한다.
[02:44] Cat의 역할은 마케팅, 영업, 재무, 용량 팀 등 크로스펑셔널 조율에 더 무게가 실리고, 기능이 준비됐을 때 출시를 막는 장애물을 없애는 일이다.
[03:04] Boris와 약 80%는 마음이 통하고, 나머지 20%씩은 각자 더 신경 쓰는 영역을 주도하는 식으로 경계가 흐릿하게 운영된다.

Chapter 2: AI 시대 PM이 갖춰야 할 것 (04:30-09:01)

[04:52] 수백 명의 PM을 인터뷰하면서, 많은 지원자가 AI PM에 필요한 역량을 근본적으로 잘못 이해하고 있다고 느낀다.
[05:34] AI로 엔지니어링이 가속되면서 제품 기능 일정이 6개월에서 한 달, 때로는 일주일이나 하루로 줄었다.
[05:55] 그래서 PM은 여러 분기 로드맵을 협력 팀과 맞추는 일보다 무언가를 가장 빠르게 내보내는 방법을 찾는 데 더 집중해야 한다.

“[06:23] AI 네이티브 제품에서 가장 잘하는 PM은 아이디어가 생긴 시점부터 제품을 사용자 손에 쥐여 주기까지의 시간을 어떻게 줄일지 파악하는 사람들입니다.” — Cat Wu

[06:57] 빠른 실행의 첫 단계는 명확한 목표 설정이다. LLM은 범용적이라 누구를 위해, 어떤 문제를, 어떤 사용 사례로 푸는지에 모호성이 크기 때문이다.
[07:53] Claude Code는 거의 모든 기능을 ‘연구 프리뷰’로 출시해, 초기 제품임을 표시하고 출시 부담을 낮춘다.
[08:18] PM은 엔지니어링, 마케팅, 문서 팀 사이에 긴밀한 프로세스를 세팅해, 엔지니어가 기능을 올리면 다음 날 마케팅 발표가 나오게 만든다.

Chapter 3: PRD, 로드맵, 그리고 빠른 출시의 비결 (09:01-11:55)

[09:14] 매주 전체 팀이 엄격한 지표 리뷰를 해서 모두가 비즈니스의 핵심 목표와 추세를 깊이 이해하게 한다.
[09:33] 팀 원칙 목록(핵심 사용자가 누구이고 왜 그런지 등)을 명문화해, 사람들이 막힘 없이 스스로 트레이드오프 결정을 내리게 한다.
[10:05] PRD가 사라진 것은 아니다. 모호한 기능이나 여러 달 걸리는 무거운 인프라 작업에는 여전히 한 페이지 분량의 PRD를 쓴다.
[11:18] 빠른 출시 속도는 새 모델(Mythos) 덕이 아니라 대부분 적은 프로세스와 팀 기대치 덕분이다. 출시를 막는 모든 장벽을 없애는 것이 핵심이다.

Chapter 4: 소스 코드 유출과 OpenClaw 결정 (11:55-14:22)

[12:14] Claude Code 소스 코드 유출은 패키지 릴리스 업데이트 PR 과정에서 발생한 사람의 실수였고, 두 단계 사람 리뷰를 거쳤음에도 통과됐다. 프로세스 실패로 보고 안전장치를 강화했다.
[13:17] OpenClaw에서 구독을 쓰지 못하게 한 것은, 사용 패턴이 퍼스트파티 제품과 다른 서드파티 제품을 위해 인프라가 설계되지 않았기 때문이다.
[13:52] Anthropic은 퍼스트파티 제품과 API를 우선시해야 했고, 수요가 높은 컴퓨트를 무한정 보조할 수는 없다는 어려운 결정의 결과였다.

Chapter 5: Anthropic PM 팀 구조와 역할의 융합 (14:22-18:15)

[14:26] PM은 현재 30~40명 규모로, 리서치 PM, Claude Developer Platform, Claude Code/Cowork, 엔터프라이즈, 성장 등 여러 팀으로 나뉜다.
[15:14] Boris의 견해는 엔지니어가 너무 빨리 움직여 PM/디자이너가 압박을 받으므로 오히려 PM이 더 필요하다는 것이다.

“[16:15] 모든 역할이 합쳐지고 있습니다. PM은 엔지니어링을 하고, 엔지니어는 PM 일을 하고, 디자이너는 PM 역할을 하면서 코드도 배포합니다.” — Cat Wu

[16:43] Cat의 팀은 제품 감각이 뛰어난 엔지니어 채용에 집중한다. 출시에 필요한 오버헤드를 줄여, Twitter 피드백을 보고 주말까지 엔드투엔드로 출시하는 엔지니어가 많다.
[17:37] 팀의 거의 모든 PM이 엔지니어 출신이거나 Claude Code로 코드를 출시한 경험이 있어, 신뢰를 쌓고 더 빠르게 움직일 수 있다. 디자이너들도 전직 프런트엔드 엔지니어다.

Chapter 6: 제품 감각이 가장 가치 있는 이유 (18:15-22:14)

“[18:15] 코드를 작성하는 비용이 훨씬 낮아질수록 더 가치 있어지는 것은 무엇을 작성할지 결정하는 일입니다.” — Cat Wu

[18:33] 수만 건의 GitHub 이슈 중 무엇을 만들 가치가 있는지, 어떻게 만들지 판단하는 데는 많은 세심함과 감각이 필요하다.
[18:55] 엔지니어링 배경은 어떤 일이 얼마나 어려운지 감을 잡게 해 우선순위 결정에 도움이 되지만, 가치 있는 역량은 몇 달마다 바뀐다.
[20:10] 가장 중요한 것은 제1원칙 사고다. 기술 환경이 어떻게 변하는지, 팀에 무엇이 필요한지 파악하고 뛰어들어 빈틈을 메우는 능력이다.
[20:54] 일이 점점 덜 정형화되므로, 여러 역할을 바꿔 맡고 자아를 낮춰 팀이 빨리 움직이도록 돕는 사람이 가치 있다.

Chapter 7: 혼돈 속에서 제정신 유지하기 (22:14-27:48)

[21:43] 인간은 여전히 모델에 없는 상식과 EQ를 제공한다. 모델은 이해관계자들의 관계와 선호, 적절한 소통 방식을 항상 잘 파악하지는 못한다.
[22:39] 팀은 혼돈을 받아들이고 모든 도전에 미소로 맞선다. 어렵겠지만 해내는 게 기대된다고 여겨야 번아웃되지 않는다.
[23:44] 할 수 있는 일에는 한계가 있음을 인정해야 한다. 잠을 잘 자고, 냉정하게 우선순위를 정하고, 일부를 내려놓는 것에 편안해져야 한다.
[24:14] 핵심 사용 사례를 막지 않는 한 다듬어지지 않은 제품을 출시해도 괜찮다. 빠르게 피드백을 받아 다음 릴리스에서 고칠 것을 알기 때문이다.
[25:34] 빠른 출시로 희생하는 것은 제품 일관성이다. 겹치는 기능이 생기고, 신규 사용자가 최선의 경로를 모를 수 있어 더 많은 교육이 필요해진다.
[27:24] 사용자들도 점점 빨라지는 러닝머신 위에 있다고 느낀다. 도구를 열면 알아서 교육해 주도록 만드는 것이 과제다.

Chapter 8: Anthropic이 성공한 이유: 미션과 집중 (27:48-34:00)

[27:48] /powerup 명령은 원래 온보딩을 두지 않는다는 원칙에서 벗어난 것이지만, 기능이 100개일 때 꼭 써야 할 10개를 알려달라는 수요가 커서 추가했다.
[29:08] 한 달 만에 ARR 110억 달러 등 Anthropic의 행보는 비현실적이다. 시작 때는 자금도 적고 유통망도 없는 후발주자였다.
[29:31] 성공의 첫 번째 요인은 하나로 묶어 주는 미션이다. 안전한 AGI를 인류에게 제공한다는 미션을 개별 제품 라인보다 우선해, 조직 전체를 가로지르는 결정을 빠르게 내린다.
[31:01] 미션의 진짜 의미는 팀들이 자신의 KR에 손해가 되는 희생을 감수하면서도 Anthropic 전체 목표를 위해 기꺼이 일한다는 것이다.

“[31:46] 아주 극단적인 예로, Claude Code는 실패했지만 Anthropic은 성공했다면 저는 정말 기쁠 것입니다.” — Cat Wu

[33:04] 두 번째 요인은 집중이다. 소셜 네트워크나 정보 피드처럼 미션과 맞지 않는 것은 출시하지 않는 명확한 선택이 성공의 핵심이다.

Chapter 9: Claude Code, 데스크톱, Cowork를 언제 쓸까 (34:00-39:01)

[32:34] 일회성 코딩 작업이나 최신 기능을 원하면 터미널의 Claude Code를 쓴다. CLI는 기능이 가장 먼저 적용되는 가장 강력한 표면이다.
[33:13] 데스크톱은 프런트엔드 작업에 빛을 발한다. 프리뷰 패널을 열어 만드는 웹 앱을 실시간으로 보며, 터미널이 낯선 비기술 사용자에게도 좋다.
[34:01] 데스크톱은 CLI/데스크톱/웹/모바일의 모든 세션을 한눈에 보는 컨트롤 플레인 역할도 한다.
[35:05] Cowork는 결과물이 코드가 아닌 모든 작업(Slack/inbox zero, 슬라이드 덱, 문서)에 가장 적합하다. 코드면 Claude Code, 아니면 Cowork로 머릿속에서 나눈다.
[35:48] 사람들은 Cowork의 성공을 크게 과소평가하고 있다. 매우 빠르게 성장 중이다.

Chapter 10: Cowork로 하룻밤 만에 슬라이드 덱 만들기 (39:01-44:42)

[36:08] Cowork를 시작하면 먼저 역할과 관련된 모든 데이터 소스(캘린더, Slack, Gmail, Google Drive)를 연결해야 한다. 맥락이 결과 품질을 크게 좌우한다.
[36:44] 어젯밤 Cowork에 콘퍼런스 발표 자료를 맡겼더니, Twitter와 사내 채널을 훑어 한 시간 만에 20페이지 덱을 만들었고, 디자인 시스템에 접근해 디자이너가 만든 것처럼 보였다.
[40:05] PM의 역할은 여전히 최종 결정이다. Claude는 훌륭한 브레인스토밍 파트너로 모든 가능성을 제시하지만, 무엇을 넣을지 마지막 결정은 사람이 내린다.
[41:11] 디자인 일관성은 이미 표준화된 외부 발표용 덱을 Claude에 접근시켜 색상, 폰트, 슬라이드 형식 예시 20장을 참고하게 함으로써 얻었다. Figma MCP 연결도 가능하다.

Chapter 11: PM의 도구 스택과 사내 맞춤 도구 (44:42-51:16)

[42:02] Cat의 스택은 Claude Code, Cowork, Slack에 치우쳐 있다. Slack이 사실상 회사의 핵심 OS다.
[42:37] 시간의 약 30%를 Cowork와 Claude Code의 한계를 밀어붙이는 데 쓰며, 모델이 왜 실수하는지 이해하려 모델과 많이 대화한다.
[43:42] Claude Code가 사내에 연 가장 큰 변화는 맞춤형 앱 제작 장벽을 낮춰, 특정 사용 사례를 위한 개인화된 업무 소프트웨어가 급증한 것이다.
[44:42] 한 영업 담당자는 Salesforce, Gong, 노트에서 고객 맥락을 가져와 덱을 자동 맞춤화하는 웹 앱을 만들었다. 수작업 20~30분이 몇 초로 줄었다.
[49:50] 모델이 좋아질수록 사람들이 더 많은 작업을 위임해 1인당 토큰 비용이 증가한다. 아직 평균 엔지니어 급여보다는 훨씬 낮지만 그 비율은 높아지고 있다.

Chapter 12: AI 회사 PM에게 필요한 새로운 역량과 평가 (51:16-59:18)

[51:39] 가장 어려운 역량은 한 달 뒤 제품이 어떤 모습이어야 하는지 정의하는 것이다. 사용자가 기존 제품을 어떻게 비틀어 쓰는지에서 패턴을 보고 방향을 설정해야 한다.

“[52:47] 초강력 AGI 모델을 위한 제품을 만드는 것은 매우 쉽습니다. 어려운 것은 현재 모델에서 어떻게 최대 역량을 끌어낼지 파악하는 것입니다.” — Cat Wu

[53:43] 이 감각은 모델과 대화하고, 예상 밖 행동을 했을 때 왜 그랬는지 모델 스스로 성찰하게 해 하네스의 격차를 고치며 기른다.
[54:31] 모델에 대해 정확한 피드백을 줄 수 있는 신뢰할 만한 5명 정도를 찾는 것이 매우 빠른 피드백을 얻는 데 중요하다.
[55:07] 모두가 좋아하진 않지만 평가(eval) 만들기가 과소평가돼 있다. 수백 개가 아니라 훌륭한 10개만 있어도 목표와 진척을 정량화할 수 있다.
[57:48] 새 모델 테스트 때 팀 점심 자리에서 모두에게 느낌을 물어 빠르게 피드백을 모으고, 그것으로 어떤 가설을 데이터로 검증할지 정한다.

Chapter 13: Claude의 성격과 새 모델이 바꾸는 제품 (59:18-1:07:23)

[56:43] Amanda는 Claude의 캐릭터를 빚어낸다. 코딩보다 어려운데, 성공 여부를 검증하기 어렵고 Claude가 어떤 존재여야 하는지 강한 확신이 필요하기 때문이다.
[59:53] 사람들이 Claude를 좋아하는 이유는 가볍고 재미있으면서 유능하고, 자존심이 낮으며, 긍정적이고 행동 지향적이며, 무조건 동의하지 않고 진심 어린 피드백을 주기 때문이다.
[1:00:48] 새 모델이 나오면 변경의 상당수는 더 이상 필요 없는 기능을 제거하는 일이다. 모델이 똑똑해질수록 보완용 목발을 떼낼 수 있다.
[1:01:20] 할 일 목록이 전형적 예다. 예전엔 큰 리팩터링을 끝까지 못 해 강제했지만, Opus 4 이후로는 모델이 자연스럽게 스스로 사용한다.
[1:03:11] 모델을 출시할 때마다 전체 시스템 프롬프트를 처음부터 읽으며 아직도 필요한 알림인지 점검하고, 불필요하면 제거한다.
[1:04:36] 코드 리뷰처럼 새 모델이 여는 완전히 새로운 역량도 있다. 최신 모델에 이르러서야 여러 리뷰 에이전트를 동시 실행해 PR 병합 전 의존할 만한 수준이 됐다.
[1:04:58] 아직 작동하지 않는 프로토타입을 미리 만들어 두면 무엇이 빠졌는지 알 수 있고, 새 모델이 나오면 바꿔 끼워 격차가 메워지는지 확인할 수 있다.

Chapter 14: AI 시대에 번창하는 법 (1:07:23-1:14:34)

[1:07:48] 어떤 수작업을 여러 번 반복하고 있음을 깨달을 때마다 AI 도구로 자동화할 방법을 생각하라. AI는 지루한 부분을 대신해 창의적인 일에 집중하게 해 준다.
[1:08:51] 늘 해야 한다고 생각했지만 여력이 없던 애착 프로젝트에 AI가 만든 여분의 20% 시간을 쓸 수 있다.

“[1:09:53] 자동화가 100퍼센트 작동하지 않으면 그것은 사실 자동화가 아닙니다.” — Cat Wu

[1:09:47] 많은 사람이 90~~95% 정확도에서 포기하지만, 그 마지막 5~~10%까지 끌어올려 정말 의존할 수 있게 만드는 데 집중해야 한다.
[1:12:01] 프로토타입에 그치지 말고 매일 실제로 쓰는 앱을 만들라. 그래야 진짜 가치를 얻고 배운다.
[1:13:18] 반대로 도구 커스터마이징(스킬, MCP)에 집착해 정작 핵심 작업을 못 하는 것도 함정이다. 단순한 설정이 실제로 더 잘 작동한다.
[1:14:34] 2024년 세대 제품은 채팅 기반이었고 Claude Code 세대는 행동 기반이다. 에이전트가 스스로 일을 해내는 것을 처음 느끼는 순간이 눈이 뜨이는 순간이다.

Chapter 15: 라이트닝 라운드 (1:14:34-1:25:34)

[1:19:11] Claude 외에 삶을 가장 많이 바꾼 제품은 Waymo다. 기다리게 해도 미안하지 않고, 차 안에서 편하게 업무 통화를 할 수 있어 매일 30분을 돌려받는 느낌이다.
[1:21:14] 인생 모토는 “그냥 일을 하라(just do the work)”. 제약과 제1원칙을 이해하면 올바른 행동을 추론할 수 있으니, 직무 정의에 갇히지 말고 빠르게 시도하고 실수에서 배우면 된다.
[1:23:34] 가장 도움이 되는 피드백은 Claude Code나 Cowork가 실패하는 재현 가능한 구체적 사례다. 사내 ‘사용자 사랑’ 채널과 피드백 채널로 팀에 공유돼 조치된다.