클로드는 아직 PM이 될 수 없다 — 앤트로픽 CPO 패널

URL: https://www.youtube.com/watch?v=sEXdyK6woKU 날짜: 2026-09-30 채널: Lenny's Podcast

---

📌 핵심 질문 / 이 대화가 관통하는 핵심 논점

==AI가 PM을 없애는 것이 아니라, PM의 중심을 인간 문제에 대한 집착·판단·연결·운영 탁월성으로 이동시킨다.== 기술은 5~10년 주기에서 두 달 주기로 변하지만 인간의 문제는 그만큼 빨리 변하지 않는다. 따라서 좋은 PM은 인간의 문제를 깊이 이해한 채 기존 해법과 자기 전문성을 기꺼이 버리고, 새 모델의 능력에 맞춰 제품과 역할을 다시 설계해야 한다.

• AI 도구로 누구나 빠르게 만들 수 있게 되면서 무엇을 만들지 결정하는 판단과 모호함 속에서 끝까지 밀어붙이는 집요함의 가치가 커졌다.
• Claude는 아직 여러 사람과 팀을 불러 모으고, 조직 맥락을 읽고, 이해관계자를 연결하는 소집자(convenor)가 아니다.
• 에이전트 네이티브(agent-native) 제품은 인간이 할 수 있는 일을 에이전트도 할 수 있게 하는 공통 프리미티브에서 출발하며, 인터페이스 자체도 에이전트와 함께 변형될 수 있어야 한다.
• 빠른 모델 발전기에는 병렬 실험과 오래된 프로젝트의 재평가가 필요하지만, 검증된 실험을 하나의 일관된 제품 경험으로 통합하는 방법은 아직 완성되지 않았다.

1. PM의 역할은 사라지지 않고 인간 문제와 기술의 연결 방식이 바뀐다

PM은 자동화될 업무 목록이 아니라 현실의 문제와 해결 기술 사이를 연결하는 역할이며, 그 연결을 더 빠른 기술 변화 속에서 다시 수행해야 한다.

1.1. 변하지 않는 중심: 인간 문제에 대한 집착

1. 제품의 본질은 문제와 기술 사이의 다리다

   1. 제품의 역할은 사람들이 현실에서 겪는 문제와 그 문제를 해결할 수 있는 기술을 연결하는 것이다.
   2. 기술은 과거 5년 또는 10년 단위로 바뀌었지만 이제는 약 두 달마다 바뀌는 것처럼 느껴질 만큼 빠르게 변한다.
   3. 반대로 인간이 가진 근본적인 문제와 욕구는 기술만큼 빠르게 변하지 않는다.

2. 새로운 해법을 위해 기존 지식을 버리는 능력

   1. 좋은 PM은 인간 문제를 깊이 이해하는 데 집착하되, 그 문제를 해결하는 기술의 작동 방식에는 계속 새로워져야 한다.
   2. 과거에 효과적이었던 해결책 대부분을 버리고, 문제에 대해 이미 알고 있는 지식을 바탕으로 다시 시도할 수 있어야 한다.
   3. 핵심은 기존 방식의 숙련도를 지키는 것이 아니라, 현재 모델이 가능하게 만든 새로운 해결 경로를 다시 탐색하는 것이다.

1.2. 역할의 경계가 흐려지는 새 시대의 일반 문제 해결자

1. 초창기 제품 역할로의 회귀

   1. 과거 제품 관리가 정립되기 전에는 직무 정의가 없었고, 사람들은 일반 문제 해결자로서 조직을 돌아다니며 문제를 해결했다.
   2. 스스로 해결하다가 벽에 부딪히면 다른 사람에게 묻거나 필요한 방법을 찾아 다음 단계로 나아갔다.
   3. AI 시대에는 PM·엔지니어·디자이너·운영의 역할이 다시 겹치고, 문제를 끝까지 따라가되 막히는 순간 모델·사람·도구라는 다양한 발판(scaffolding)을 활용하게 된다.

2. PM이라는 직함보다 연결 기능이 중요해진다

   1. 누구의 직함에 속했는지보다 어떤 문제를 발견하고, 어떤 사람과 도구를 연결하며, 어떤 결과를 끝까지 만들어 내는지가 중요해진다.
   2. 역할이 흐려져도 최종 사용자의 문제를 놓치지 않고, 팀이 실제로 제품을 출하하도록 만드는 기능은 남는다.

2. Claude가 아직 PM이 될 수 없는 이유와 PM 역할의 부활

AI가 코드와 문서를 만들 수 있어도 프로젝트 전체를 연결하는 운영·조정·소집 기능까지 자동으로 수행하지는 못한다.

2.1. Mike의 APM 사례: 만들기만으로는 출하가 완성되지 않는다

1. 빌더 중심의 IC 역할에서 맞닥뜨린 반례

   1. Mike는 연초에 개별 기여자(IC) 역할로 옮겨 대부분 직접 만들고 있었고, 프로젝트는 출하를 앞두고 순조롭게 진행되는 것처럼 보였다.
   2. PM 리드가 Mike에게 프로젝트에 APM이 꼭 필요하다고 말하자, Mike는 Claude가 처리할 수 있고 이미 할 일이 많으니 PM이 정말 필요한지 의문을 제기했다.
   3. 그러나 APM이 합류한 뒤, 팀을 잇는 접착제와 연결 조직, 곧 빠뜨릴 뻔한 수많은 업무가 드러났다.
   4. Mike는 다음 주 PM 리드에게 자신이 틀렸고 그녀가 100% 옳았다고 인정했다.

2. PM이 연결해야 하는 구체적 업무

   1. Anthropic은 프로슈머(prosumer)부터 대기업까지 섬기므로, 서로 다른 고객군의 요구와 변화가 함께 반영되어야 한다.
   2. 고객 성공(customer success) 팀이 변화가 생기는 즉시 고객 질문에 답할 수 있도록 제품 변화와 설명 방식을 연결해야 한다.
   3. 안전장치(safeguards) 팀을 적시에 참여시키고, 프로젝트의 모든 사람이 일정과 의사결정에 맞춰 움직이는지 확인해야 한다.
   4. 최종 사용자 요구를 유지하면서도 머리를 박고 Claude를 사용하는 빌더들이 계속 만들기에 집중할 수 있도록, 별도의 운영·조정 활동을 맡아야 한다.

3. 속도가 빨라질수록 운영 탁월성이 중요해진다

   1. AI 도구가 있어도 어느 누구에게나 무한한 처리 용량이 생기는 것은 아니다.
   2. 더 빨리 만들 수 있게 된 만큼 PM은 예전보다 더 높은 수준의 운영 탁월성(operational excellence)을 발휘해야 한다.
   3. PM이라는 모자는 사라지지 않았고, 오히려 팀에 이런 모자가 필요할 때 그 중요성이 높아졌다.

2.2. Fable 농담이 드러낸 현재 에이전트의 한계

1. “그냥 Fable에게 시키면 되지 않나?”라는 질문

   1. Lenny는 진지한 질문만 하겠다고 분위기를 잡은 직후, 왜 PM을 두지 않고 Fable 7에게 일을 시키지 않았느냐고 농담했다.
   2. 이 질문은 최신 모델이 연결 조직의 일부를 감지하고 작업을 보조할 수 있는데도, 사람 PM이 맡은 전체 맥락을 자동으로 책임지지는 못한다는 핵심을 찌른다.

2. Claude가 제공하는 연결 조직과 아직 제공하지 못하는 소집 기능

   1. Anthropic은 Claude를 중심으로 일하며, Claude가 조직의 다른 영역에서 벌어지는 일을 찾아 “이 부분도 알아야 한다”고 알려 주는 사례가 있다.
   2. 실제로 슬래시 검색(slash search)을 통해 다른 조직의 관련 정보를 찾아내는 식의 연결은 가능하다.
   3. 하지만 Claude는 아직 소집자(convenor)가 아니다. 사람과 Claude를 불러 모아 공동 작업을 시작하고, 조직적 당김(organizational pull)과 일정 조정(scheduling)을 통해 대화를 성사시키는 역할은 하지 못한다.
   4. 언젠가 Claude가 “이 두 사람이 대화해야 한다”고 판단해 회의를 잡으면 누가 이 회의를 잡았는지 의아해할 순간이 올 수 있지만, 그 설정은 아직 실제로 작동하지 않았다.

3. 소집자의 인간적 기능

   1. 소집자는 여러 사람의 관심·정보·책임을 한 지점으로 모아 일이 실제로 진행되도록 한다.
   2. 이 기능은 단순히 일정표를 채우는 일이 아니라, 누가 무엇을 알아야 하는지와 어떤 대화를 먼저 해야 하는지를 판단하는 조직적 맥락 처리다.

3. 빠른 제작 시대에 PM에게 더 중요해진 판단과 집요함

만들 수 있는 것의 우주가 넓어질수록 만들지 말아야 할 것을 고르는 판단과 선택한 일을 완수하는 집요함이 제품 역할의 핵심이 된다.

3.1. 무한히 갈라지는 선택지 속에서 무엇을 만들지 결정하기

1. 제작 속도가 판단을 대체하지 않는다

   1. 도구가 좋아져 많은 것을 매우 빠르게 만들 수 있게 되면서 실제로 만들 수 있는 제품의 범위가 크게 확장됐다.
   2. 하지만 제한적인 정보만 가지고 무엇을 만들지 결정하는 문제는 여전히 남아 있다.
   3. 선택지가 너무 많아진 만큼 좋은 PM은 만들어 보는 속도뿐 아니라 선택의 질을 책임져야 한다.

2. 모호함 속의 집요함

   1. 좋은 제품 리더는 무엇을 해야 하는지에 대한 가설과 사용할 사람에게서 얻는 피드백 루프를 갖고, 인간 문제가 무엇인지 이해한 채 실행에 들어간다.
   2. “이것이 우리가 해야 할 일이다”라고 판단한 뒤에는 수많은 갈림길 때문에 멈추지 않고 끝까지 밀어붙여야 한다.
   3. 판단(judgment)과 집요함(relentlessness)은 불확실성을 없애는 능력이 아니라, 불확실성이 남아 있는 상태에서 전진하는 능력이다.

3. 수평선 너머의 바다 비유

   1. 새 모델이 나올 때마다 바다 너머에 무엇이 있는지 바라보다가, 빠르게 수평선 너머로 이동해 보면 또 다른 거대한 지형이 나타난다.
   2. 그 지형은 유토피아도 재앙도 아니며, 새롭게 발견하고 항해해야 할 대상이다.
   3. 제품 리더는 이미 정답에 도착했다고 가정하기보다 계속 변하는 지형의 방향을 읽어야 한다.

3.2. 오래 쌓은 전문성이 쓸모없어지는 개인적 혁신가의 딜레마

1. 버튼 위치를 결정하던 수십 년의 훈련

   1. Amy는 오랫동안 사용자의 관점에 들어가 제품이 삶에 어떻게 들어맞는지 파악하는 법을 배웠다.
   2. 제품을 만들고 출시하는 비용이 높았기 때문에, 리뷰에서는 버튼을 어디에 놓을지, 상호작용 패턴은 무엇인지, 사용자가 주머니에서 휴대폰을 꺼낼 때 손가락이 어디로 갈지까지 논의했다.
   3. 휴대폰을 꺼내는 상황에서 사용자가 무엇을 원하는지 예측하는 제품·디자인 혼합 역량은 과거에 자랑스럽게 여긴 전문성이었다.

2. 세 가지 버전을 먼저 만드는 방식

   1. 이제는 버튼의 최적 위치를 머릿속으로 오래 결정하기보다 세 가지 버전을 빠르게 만들고 실제로 시험하는 편이 더 빠르다.
   2. 따라서 과거에 자랑했던 “사용자의 손가락이 어디에 갈지 정확히 설계하는 능력”은 더 이상 같은 방식으로 요구되지 않을 수 있다.
   3. Fable이 그 문제를 먼저 해결해 버릴 것이라는 농담은 이 변화가 개인의 전문성을 정면으로 건드린다는 점을 보여 준다.

3. 개인의 혁신가의 딜레마

   1. 기업의 혁신가의 딜레마는 잘하던 일을 계속하는 동안 더 중요한 새 방식을 시도하지 못하는 현상이다.
   2. 같은 문제가 개인에게도 생긴다. “나는 이것을 잘하니 계속 이것만 하겠다”는 자기 이미지가 미래의 더 중요한 방법을 가로막을 수 있다.
   3. 기술이 두 달마다 바뀌면 기술을 활용하는 직무에서 자신이 무엇을 잘한다고 생각했는지까지 버리고 다시 시도해야 한다.
   4. Amy도 모델 회사에서 일해 본 적이 없었기 때문에, 몇 달마다 새로운 방식이 자신에게 맞는지 실험하고 있다.

3.3. 적응력을 조직의 심리적 안전으로 전환하기

1. 필요한 개인 역량

   1. 변화에 대한 내성의 상한선을 높이고 변화를 기꺼이 받아들이는 적응력(adaptability)이 필수다.
   2. 판단과 집요함은 급변하는 환경에서 반복적으로 사용되는 핵심 역량이다.
   3. 이런 적응은 한 사람만 감당하는 개인 과제가 아니며 팀 전체가 함께 계속 변화해야 한다.

2. 혼란을 구조화하는 리더십

   1. 불확실할 때 사람들은 통제감을 얻기 위해 앞으로 정확히 어떤 제품을 만들고 경력이 어떻게 흘러갈지 모두 그리려 한다.
   2. 그러나 미래를 지나치게 구체적으로 고정하면 새 가능성을 시험할 기회를 잃는다.
   3. 리더의 역할은 혼란을 없애는 것이 아니라, 혼란을 안전하고 그럴듯한 것으로 프레이밍해 사람들이 참여하고 실험하도록 만드는 것이다.
   4. 감정적으로 어렵다는 사실을 말로 인정하고, 변화에 대한 불안을 조직의 대화 안에 포함해야 한다.

3. 혼란 속에 선명한 DRI를 세우기

   1. 여러 팀이 프런티어를 탐색하더라도 각 영역에는 최종 결정을 내리는 명확한 책임자(DRI, directly responsible individual)가 필요하다.
   2. Anthropic의 랩에서는 이런 실험을 베트(bet)라고 부르고, 베트 리드(bet lead)가 무엇에 더 투자할지, 무엇을 중단할지, 팀에 인력을 늘리거나 줄일지를 결정한다.
   3. 모두가 함께 길을 잃은 상태에서도 다음에 무엇을 해야 위험을 줄이고, 배우고, 전진할 수 있는지에 대한 펜을 쥔 사람이 있어야 한다.

4. 에이전트 네이티브 제품은 기능 추가가 아니라 제품 프리미티브의 재설계다

사람만 소프트웨어를 사용하던 세계에서 사람과 에이전트가 함께 사용하는 세계로 넘어가면서, 제품이 제공하는 기능과 에이전트가 수행하는 행동의 경계가 재편된다.

4.1. 사이드바에서 에이전트 네이티브로 가는 세 단계

1. 1단계: 분리된 AI 사이드바

   1. 초기 AI 기능은 제품 옆의 작은 창이나 사이드바에 들어가 질문에 답하는 형태였다.
   2. 고객 지원 질문처럼 제한된 일을 도왔지만 전체 제품 경험과는 분리되어 있었다.

2. 2단계: AI가 기능 자체가 되기

   1. 다음 단계에서는 제품의 특정 기능 전체가 AI에 의해 작동한다.
   2. AI는 부가 도구가 아니라 일부 업무 흐름을 직접 수행하는 제품 구성요소가 된다.

3. 3단계: 에이전트 네이티브와 가변적 인터페이스

   1. 에이전트 네이티브의 좋은 요약은 “인간이 할 수 있는 모든 일을 에이전트도 할 수 있어야 한다”는 원칙이다.
   2. 대부분의 제품은 아직 이 원칙을 제대로 구현하지 못했지만, 구현되면 에이전트가 기존에 연결되지 않던 행동을 조합하고 새로운 작업 방식을 선제적으로 제안하는 창발적 행동이 나타난다.
   3. 다음 단계는 인터페이스 자체가 에이전트에 의해 변형될 수 있는 가변적 소프트웨어(malleable software)다.

4.2. 네 개 이상의 작업 흐름을 Claude가 관리하는 내부 사례

1. 프로젝트 상태판을 만드는 Claude

   1. Anthropic이 출하를 준비하는 복잡한 프로젝트에는 최소 네 개의 독립적인 작업 흐름이 있다.
   2. Claude가 각 흐름의 진행 상황을 지켜보고, 먼저 기술 프로그램 관리자(TPM)가 이해할 수 있는 UI를 만들고, 이어서 전체 팀이 프로젝트 상태를 이해하는 UI로 확장했다.
   3. 사람이 미리 정한 내부 가속 팀이나 외부 업체의 화면에 묶이지 않고, 마음에 들지 않으면 Claude와 함께 표시 방식을 바꿀 수 있다.

2. 조직 소프트웨어의 제작·유지·반복을 Claude가 맡기 시작하다

   1. 지난 1년 동안 Anthropic 내부에서 사용하는 소프트웨어 상당 부분이 Claude에 의해 만들어지고, 유지되고, 반복 개선됐다.
   2. 조직에서 일어나는 변화에 따라 소프트웨어가 계속 바뀌므로 제품의 화면이 한 번 고정된 산출물이 아니라 업무 맥락에 따라 진화하는 작업 공간이 된다.

3. 새로 생기는 데이터 거버넌스 질문

   1. 데이터는 사람만 클릭해서 업데이트해야 하는지, Claude가 배경에서 갱신해도 되는지 결정해야 한다.
   2. 누가 어떤 데이터를 언제 바꿨는지 추적하는 데이터 출처(provenance)와 권한 체계가 필요하다.
   3. 가변적 UI를 허용하더라도 기본 블록, 예측 가능성, 디자인 시스템은 제품을 미쳐 버리지 않게 하는 경계로 남아야 한다.
   4. 최종 목표는 특정 작업·프로젝트·사용자에게 알맞은 기능과 표현을 끌어와 개인적이면서도 매우 유용한 경험을 만드는 것이다.

4.3. 기존 SaaS가 에이전트를 받아들이는 방법

1. 에이전트와 REST API가 같은 배관을 사용하게 만들기

   1. 20년 된 SaaS에 에이전트를 마지막에 덧붙이는 일은 어렵지만, 제품의 기반 프리미티브를 인프라 계층처럼 설계하는 것이 출발점이다.
   2. 사람이 할 수 있는 일을 에이전트에게 요청해 보고, 그 행동이 공통 배관을 통해 실행되는지 확인해야 한다.
   3. 에이전트와 제품이 만든 REST API가 서로 다른 우회로를 사용하지 않고 같은 공유 플럼빙(shared plumbing)을 통과해야 한다.

2. 전체 UI를 한 번에 파괴할 필요는 없다

   1. 처음에는 기존 사이드 패널을 유지한 채 실험할 수 있다.
   2. 같은 프리미티브를 사용하는 개인화된 랜딩 페이지처럼 더 가변적인 표면을 추가할 수 있다.
   3. 새 인프라를 매번 별도로 발명하지 않고 동일한 기반을 따라가면 제품은 사이드바에서 완전한 생성형 UI로 점진적으로 진화할 수 있다.
   4. 기능이 제품 안에 자연스럽게 들어온 것인지, 아니면 급히 덧붙인 기능처럼 느껴지는지가 사용자 경험의 차이를 만든다.

5. 프런티어 실험과 안정적인 제품 경험을 함께 운영하기

Anthropic은 단순한 채팅 사용자부터 거대한 엔터프라이즈 계약 고객까지 모두 섬겨야 하므로, 실험의 속도와 이해 가능한 경험을 동시에 확보해야 한다.

5.1. 아직 정답을 모를 때는 겹치는 실험을 허용하기

1. 모델과 사용 방식이 함께 변한다

   1. 두 달마다 모델만 바뀌는 것이 아니라 사람들이 모델을 사용하는 방식과 제품에 기대하는 방식도 바뀐다.
   2. 그래서 “이미 정답을 알아냈으니 안정적인 제품을 만들면 된다”는 전제가 아직 성립하지 않는다.
   3. 팀은 사람들이 있는 곳에서 시작해, 프런티어를 탐색하고, 작동하는 패턴을 발견한 뒤 안정적이고 완성된 경험으로 정리해야 한다.

2. 다섯 개의 겹치는 시도가 하나의 과도한 제약보다 낫다

   1. 과거 제품 문화는 단순성·신뢰성·완전한 예측 가능성을 중시해 사용자가 근육 기억과 직관을 만들 수 있게 했다.
   2. 하지만 아직 형태를 모르는 제품을 처음부터 하나의 이론으로 과도하게 제한하면 시장을 만날 기회 자체를 잃는다.
   3. 서로 겹치거나 중복되는 다섯 가지 제품을 시도한 뒤 제품-시장 적합성 신호가 보이면 하나로 재통합하는 편이 낫다.

3. 팀의 열의가 실험의 전제다

   1. 두 제품 방향 중 하나에는 강한 확신을 가진 팀이 있고 다른 방향에는 아무도 진심으로 부르지 않는다면, 후자를 억지로 맡기는 것은 제조된 실험이 된다.
   2. 사람들이 흥미를 느끼지 않는 제품 영역을 B팀처럼 배정하면 최종 제품이 좋게 나오기 어렵다.
   3. 반대로 두세 팀이 각자의 방향에 실제로 흥미와 확신을 갖고 있다면 병렬로 탐색하게 해야 한다.

5.2. 기반 인프라가 병렬 실험을 서로 보완하게 만든다

1. Chat과 Cowork의 분리 문제

   1. 불과 몇 달 전만 해도 Chat과 Cowork가 서로 다른 메모리 시스템, MCP, 파일 저장 방식을 사용했다.
   2. 그 위에 세 번째 실험 제품을 만들면 기존 어느 제품과도 메모리를 공유하지 못해 시작부터 단절되고 불리해진다.
   3. 표면에서 서로 다른 실험을 하더라도 핵심 상태를 공유할 수 있는 기반이 필요하다.

2. Foundations 팀의 역할

   1. Foundations 팀은 사용자가 Anthropic 제품 어디에 있든 자신의 메모리를 사용할 수 있도록 공통 기반을 해결한다.
   2. 단순해 보이는 요구도 여덟 가지 이유로 복잡해질 수 있지만, 실험 팀들이 공통으로 사용하는 문제이므로 별도 기반 팀에서 해결할 가치가 있다.
   3. 공통 메모리·MCP·파일 프리미티브가 있으면 겹치는 프런티어 실험도 서로 경쟁하는 고립된 제품이 아니라 보완적인 실험이 된다.

3. 불확실성을 공개적으로 이름 붙이기

   1. 세 가지 베트가 있으면 한 팀이 실패하도록 설계된 것처럼 느껴질 수 있고, 이는 사기를 떨어뜨릴 수 있다.
   2. 리더는 “우리는 답을 모른다. 누구도 모른다. 무엇이 작동하는지 함께 발견한다. 우리는 같은 팀이다”라고 직접 말해야 한다.
   3. 사람들이 어둠 속에서 모두 탐색하고 있다는 사실을 말로 확인하는 것만으로도 병렬 탐색의 감정적 비용이 낮아진다.

6. 제품이 작동하는지 판단하고, 아직 이르다면 프로젝트를 보관하기

새 모델이 과거의 실패를 갑자기 성공으로 바꿀 수 있으므로, 초기 실험은 버리기보다 재평가 가능한 형태로 보관해야 한다.

6.1. 제품-시장 적합성은 여전히 기본 질문에서 시작한다

1. 사용과 반복이 첫 번째 신호다

   1. 사람들이 실제로 사용하는가를 본다.
   2. 사람들이 좋아하는가를 본다.
   3. 다시 찾아오는가, 다른 사람에게 이야기하는가를 본다.
   4. 실제 가치를 얻는가를 본다.

2. 기술이 새로워져도 제품의 목적은 그대로다

   1. 제품의 목적은 문제를 해결하는 것이다.
   2. 사용자가 쉽게 사용할 수 있고, 사용하면서 좋다고 느끼는 방식으로 문제가 해결되는지가 핵심이다.
   3. 에이전트 네이티브 여부보다 먼저, 그 기능이 인간의 문제를 실제로 해결하는지 확인해야 한다.

6.2. 2024년 컴퓨터 사용 프로젝트와 능력 맹점

1. 너무 일찍 실패한 컴퓨터 사용 제품

   1. Anthropic은 2024년에 내부 최초의 컴퓨터 사용(computer use) 제품을 만들었다.
   2. 당시 모델이 충분히 강하지 않아 자동화에는 약하고 교육에는 강할 것이라는 초기 가설을 세웠다.
   3. 복잡한 Photoshop 작업을 시키면 모델은 “이 동작이 됐나? 아니, 안 됐으니 닫고 다시 해야 한다”고 반복했다.
   4. 20분 뒤 겨우 성공해도 사용자는 그 과정에서 아무것도 배우지 못했으므로 자동화에도 교육에도 적합하지 않았다.

2. 프로젝트를 버리지 않고 보관하기

   1. 팀은 프로젝트를 중단해 폐기하지 않고 보관(park)했다.
   2. 새 모델이 나올 때마다 같은 과제를 다시 시도할 수 있도록 평가 하네스(eval harness)에서 계속 돌렸다.
   3. 프로젝트가 “현재 모델은 아직 이 일을 할 수 없다”는 사실만 보여 줘도, 그 사실을 평가 항목으로 외부화하고 연구팀과 연결했다면 성공으로 본다.

3. 모델 3.7에서 일어난 도약

   1. 어느 순간 모델 3.7이 컴퓨터 사용 평가에서 갑자기 이전과 다른 성능을 보였다.
   2. 로그를 확인하니 실패보다 성공이 많아졌고, 그때 비로소 실제 능력 도약이라고 판단할 수 있었다.
   3. 2·3·4·5·6개월 뒤 다시 방문할 수 있도록 초기 제품과 평가를 남겨 두면 연구 발전이 제품 직관으로 이어진다.

4. 능력 맹점(capability blind)

   1. 한 번 시도한 뒤 다시 시도하지 않거나 평가를 남기지 않으면 “모델은 절대 이 일을 못 한다”고 잘못 결론내릴 수 있다.
   2. 불과 3개월 뒤 새 모델이 예상하지 못한 방식으로 해당 능력을 크게 향상시킬 수 있다.
   3. 따라서 모델의 최신 능력을 모른 채 과거 버전의 한계를 영구적인 사실로 취급하지 말아야 한다.

6.3. 관객 반응이 보여 준 최신 모델 격차

1. Fable과 Astra 사용 경험

   1. 관객에게 Fable을 사용해 본 사람을 묻자 많은 사람이 손을 들었다.
   2. Astra 사용자는 더 적었고, 이는 일부 관객이 최신 모델과 제품의 가장자리를 먼저 탐색하고 있음을 보여 줬다.

2. “안 된다”는 말의 버전 확인

   1. 사용자가 어떤 기능이 안 된다고 말할 때, 실제로 최신 모델을 사용했는지 묻는 경우가 많다.
   2. 사용자는 Sonnet 4.5로 들리는 과거 버전이나 예전 모델을 사용한 뒤 최신 능력까지 안 된다고 판단할 수 있다.
   3. 마지막으로 확인한 모델의 상태가 영원히 참이라고 믿지 않으려면, 과거 지식과 제품 직관을 기꺼이 버려야 한다.

7. 병렬 실험을 일관된 제품으로 통합하는 미완의 기술

여러 실험 중 하나가 성공한 뒤 탭·별도 앱·기존 제품 통합 중 무엇을 선택할지는 아직 업계 전체가 정답을 찾지 못한 문제다.

7.1. 성공한 실험을 탭과 별도 앱으로 흩어지게 하지 않기

1. 탭의 함정

   1. 새 실험을 탭으로 추가하면 탭이 계속 늘어나고, 각 탭의 기능이 약간씩 다른 방식으로 작동하게 된다.
   2. 사용자는 도구를 선택하는 인지 부담을 떠안고, 제품이 무엇을 주된 경험으로 삼는지 알기 어려워진다.

2. 별도 앱의 함정

   1. 실험을 별도 앱으로 유지하면 기존 제품과 결합되지 않아 발견성과 일관성이 떨어진다.
   2. 반대로 너무 이르게 합치면 아직 검증되지 않은 방식이 주 제품의 안정성을 훼손할 수 있다.

3. 아직 확정되지 않은 통합 원리

   1. Anthropic도 병렬 실험을 일관된 제품으로 바꾸는 정답을 완전히 찾지 못했다고 인정했다.
   2. 통합은 실험을 죽이지 않으면서, 성공 신호가 생긴 뒤 사용자가 자연스럽게 접근하는 하나의 경험으로 재구성하는 문제다.

7.2. 프리미티브와 주 경험으로 인지 부하를 줄이기

1. 사용자가 도구를 고르는 부담을 제품이 다시 가져오기

   1. 사용자는 제품에 다가가 별다른 생각 없이 사용할 수 있기를 기대한다.
   2. “여기 도구가 여러 개 있으니 골라 보라”고 말하는 것은 인지 부담을 사용자에게 이전하는 방식이다.
   3. 공통 프리미티브가 사용자를 이해하고 적절한 시스템을 선택하도록 만들어, 언제나 접근 가능한 UI를 제공해야 한다.

2. 가변성과 예측 가능성의 균형

   1. 사용자의 맥락에 맞게 UI가 변하되 기본 블록과 디자인 시스템이 있어 어디서 무엇을 할 수 있는지 감을 잃지 않아야 한다.
   2. 어떤 실험을 주 경험으로 채택할지는 사용자 반응과 반복 신호를 보면서 점진적으로 결정한다.

7.3. Instagram의 80% 주 피드 법칙

1. 강한 사용량의 멱법칙(power law)

   1. Instagram에서 메인 피드는 전체 사용량의 약 80%를 차지했다.
   2. 탐색(Explore)을 개선해 사용 비중을 10%에서 15%로 늘릴 수 있어도, 사용자가 도착하는 중심 경험인 메인 피드와는 격차가 크다.

2. 제품의 주 탭을 지키기

   1. 제품 개발의 핵심 질문은 사용자가 처음 도착하는 메인 탭과 그 경험을 어떻게 훌륭하게 만들지다.
   2. 메인 경험은 다른 흥미로운 하위 경험으로 들어가는 출발점이 될 수 있다.
   3. 검증되지 않은 기능을 사이드바나 또 다른 탭으로 계속 추가하지 않고, 충분히 입증된 뒤 주 경험 안으로 녹일지 결정하는 것이 PM의 중요한 판단이다.

8. 1년 뒤 PM의 모습과 AI의 민주화

다음 단계의 PM은 더 많은 일을 직접 만들 수 있으면서도 모델의 능력을 대부분의 사람이 실제로 활용하게 만드는 연결자다.

8.1. 더 작은 팀과 개인의 역량 증폭

1. 더 많은 사람이 원하는 방식으로 만들기

   1. 사람들은 필요할 때 답을 얻고, 원하는 방식으로 직접 만들고, 작은 팀이나 혼자서도 사업을 시작할 수 있게 되기를 기대한다.
   2. 제품과 모델이 그 흐름을 쉽게 만들면 소수의 빌더가 훨씬 많은 사람에게 영향을 증폭시킬 수 있다.
   3. 도구를 직접 사용하지 않는 사람도 빌더가 만든 결과의 혜택을 받으므로, 빌더의 생산성 증가는 사회 전체의 영향으로 이어진다.

2. PM은 제작과 확산을 함께 설계한다

   1. PM은 모델을 호출하는 기능만 기획하는 것이 아니라, 더 많은 사람이 결과를 이해하고 신뢰하고 반복해서 쓰게 만드는 제품 구조를 설계한다.
   2. 작은 팀과 개인의 자율성이 커질수록 PM의 연결·운영·판단 역할은 오히려 더 중요해진다.

8.2. 모델의 가능성과 실제 사용 사이의 간극 닫기

1. 문제는 사용자가 아니라 제품에 있다

   1. 현재 모델이 할 수 있는 일과 대부분의 사람이 모델을 사용해 실제로 하는 일 사이에는 큰 간극이 있다.
   2. 그 간극은 사용자의 잘못이 아니라, 모델의 능력을 드러내고 사용하게 만드는 제품을 아직 충분히 만들지 못한 개발사의 책임이다.
   3. 모델이 강해질수록 이 간극을 닫는 일은 더 어려워지지만, 동시에 더 민주화적인 효과를 낸다.

2. Claude에 익숙한 엔지니어 밖으로 확장하기

   1. 목표는 완전한 다중 에이전트 설정을 스스로 구축한 가장 Claude에 몰입한 소프트웨어 엔지니어만 혜택을 보는 상태를 끝내는 것이다.
   2. 여러 연구를 동시에 수행하는 사람과 자신의 사업을 운영하는 사람도 모델의 힘을 체감할 수 있어야 한다.
   3. 사용자가 어떤 구성요소가 움직이는지 이해하고, 적절한 지점에서 확인하고, 장기 작업을 수행하되 통제권을 빼앗겼다고 느끼지 않게 하는 것이 제품의 예술이다.

주요 발언 모음

“The job of product is always to be a bridge between the real problems that people have in the world and the technology that you can use to solve it.”

“제품의 일은 언제나 사람들이 현실에서 겪는 문제와 그 문제를 해결하는 데 쓸 수 있는 기술 사이의 다리가 되는 것이다.”

“I don't think Claude is a convenor yet.”

“Claude는 아직 소집자가 아니라고 생각한다.”

“Everything a human could do an agent should be able to do as well.”

“인간이 할 수 있는 모든 일을 에이전트도 할 수 있어야 한다.”

“We have to frame the chaos so it feels safe and it feels plausible to engage with it.”

“혼란을 안전하고 참여할 만한 것으로 프레이밍해야 한다.”

“You can get capability blind.”

“능력 맹점에 빠질 수 있다.”

“The user expects to walk up to something and hopefully not have to think about it too much.”

“사용자는 제품에 다가가서 많은 것을 고민하지 않고 쓸 수 있기를 기대한다.”

“I don't know what you're talking about.”

병렬 실험을 일관된 제품으로 통합하는 문제를 완전히 해결했느냐는 질문에 대한 Amy의 농담 섞인 답변이다.

“It’s on us. We’ve got to build the products to make that possible.”

“그것은 우리의 책임이다. 가능하게 만드는 제품을 우리가 만들어야 한다.”

핵심 데이터 & 수치

• 기술 변화 주기: 과거 5~10년 주기에서 현재 약 2개월 주기로 체감될 만큼 빨라졌다.
• 복잡한 내부 프로젝트: 최소 4개의 독립적인 작업 흐름을 Claude가 추적하고 상태 UI를 생성했다.
• 컴퓨터 사용 제품: Anthropic의 최초 내부 컴퓨터 사용 제품은 2024년에 만들어졌고, 초기에는 자동화·교육 어느 쪽에도 만족스럽지 못했다.
• 재평가 간격: 모델이 발전할 때마다, 대화 중 2·3·4·5·6개월 후에도 다시 시도할 수 있도록 평가를 남기는 방식이 언급됐다.
• 모델 3.7: 평가 하네스에서 성공이 실패보다 많아지며 컴퓨터 사용 능력의 도약이 관찰됐다.
• Instagram 메인 피드: 전체 사용량의 약 80%가 메인 피드에 집중되는 강한 멱법칙이 관찰됐다.
• 탐색 탭 개선 예시: 탐색 사용량을 10%에서 15%로 늘려도 메인 피드의 중심성은 유지된다.
• 관객 제품 사용: Fable 사용자는 많았고 Astra 사용자는 상대적으로 적었다.
• Anthropic 사용자 범위: 프로슈머부터 대규모 엔터프라이즈까지 포함한다.

결론 및 시사점

1. PM의 생존 여부를 직함의 존속으로 판단하지 말고, 인간 문제를 이해하고 여러 기능을 연결해 실제 결과를 출하하는 기능의 필요성으로 판단해야 한다.
2. AI가 코드·문서·화면을 만드는 능력이 커질수록 무엇을 만들지 결정하고, 책임자를 세우고, 고객·안전·운영을 연결하는 PM의 가치는 높아진다.
3. PM은 버튼 위치를 오래 결정하는 사람에서 빠른 프로토타입을 통해 학습하고, 인간 문제를 기준으로 선택하는 사람으로 이동해야 한다.
4. 변화 속에서 살아남는 개인 역량은 적응력, 모호함 속의 판단, 선택한 일을 끝까지 밀어붙이는 집요함이다.
5. 리더는 불확실성을 숨기거나 거짓 정밀도로 계획하지 말고, 혼란을 안전하게 탐색할 수 있도록 감정과 구조를 함께 제공해야 한다.
6. 여러 실험을 허용하되 각 베트에는 명확한 DRI 또는 베트 리드를 두어 다음의 위험 감소·학습·투자 결정을 한 사람이 책임지게 해야 한다.
7. 에이전트 네이티브 제품은 사이드바에 챗봇을 추가하는 것이 아니라, 사람이 할 수 있는 모든 행동을 에이전트가 수행하도록 공통 프리미티브를 설계하는 일이다.
8. 제품의 UI가 작업·프로젝트·사용자에 맞게 바뀌더라도 기본 프리미티브, 예측 가능성, 데이터 출처와 권한의 경계를 유지해야 한다.
9. 오래된 SaaS는 에이전트용 별도 우회로를 만들기보다 사람과 에이전트와 REST API가 같은 공유 배관을 사용하도록 기반부터 정비해야 한다.
10. 실험이 실패해도 평가 하네스와 연구팀 연결을 남기면 미래 모델이 능력을 갖추는 순간을 포착할 수 있으므로, 초기에 만드는 일 자체가 학습 자산이다.
11. 최신 모델을 사용하지 않은 상태에서 “불가능하다”고 단정하면 능력 맹점에 빠질 수 있으므로, 모델 버전과 평가 시점을 함께 기록해야 한다.
12. 성공한 병렬 실험을 탭과 별도 앱으로 무한히 늘리는 대신, 사용자가 도구를 선택하지 않아도 적절한 경험으로 들어가도록 주 제품의 메인 흐름에 통합해야 한다.
13. 다음 해의 목표는 모델의 잠재력을 소수의 고숙련 엔지니어가 독점하는 것이 아니라 연구자·사업 운영자·소규모 팀까지 이해 가능한 방식으로 확장하는 것이다.

핵심 요약 (20줄)

제품의 본질은 현실의 인간 문제와 이를 해결할 기술을 연결하는 다리이며 이 중심은 AI 시대에도 변하지 않는다. 기술은 과거 5년이나 10년 주기에서 이제 약 두 달마다 바뀌지만 인간의 근본적인 문제는 그만큼 빠르게 변하지 않는다. 좋은 PM은 인간 문제를 깊이 이해하면서도 기존 해결책 대부분을 버리고 새 모델의 능력에 맞춰 다시 시도한다. AI가 역할의 경계를 흐려도 최종 사용자 요구와 고객 성공과 안전장치와 팀 실행을 연결하는 PM의 기능은 사라지지 않는다. Mike의 프로젝트 사례는 Claude가 있어도 접착제와 연결 조직과 출하 준비를 맡는 APM이 필요하다는 사실을 보여 준다. Claude는 정보를 찾아 알려 줄 수 있지만 사람과 조직을 소집하고 맥락에 맞는 회의를 만드는 convenor는 아직 아니다. 만들 수 있는 것이 폭발적으로 늘어날수록 무엇을 만들지 결정하는 판단과 모호함 속에서 끝까지 밀어붙이는 집요함이 중요해진다. 과거에 버튼 위치와 사용자의 손가락 움직임을 깊이 설계하던 전문성은 여러 버전을 먼저 만들고 시험하는 방식으로 대체될 수 있다. 개인도 기업처럼 과거에 잘하던 방식을 계속 고집하는 혁신가의 딜레마에 빠질 수 있으므로 자신의 전문성을 주기적으로 다시 써야 한다. 리더는 혼란을 없애려 하기보다 안전하게 탐색할 수 있도록 프레이밍하고 각 실험에는 명확한 DRI와 베트 리드를 둬야 한다. 에이전트 네이티브 제품은 AI 사이드바를 붙이는 단계를 넘어 인간이 할 수 있는 모든 일을 에이전트도 수행하게 하는 제품이다. 에이전트가 프로젝트 상태 UI까지 만들고 고치는 가변적 소프트웨어는 Anthropic 내부 업무 방식의 큰 변화를 보여 준다. 가변적 UI를 도입해도 공통 프리미티브와 예측 가능성 디자인 시스템 데이터 출처 권한은 유지해야 한다. 기존 SaaS는 사람과 에이전트와 REST API가 같은 공유 배관을 쓰도록 기반을 만들면서 사이드바에서 점진적으로 진화할 수 있다. 프런티어 제품은 아직 정답을 모르므로 겹치는 실험을 허용하되 시장 신호가 생기면 안정적인 경험으로 통합해야 한다. Chat과 Cowork가 메모리와 MCP와 파일 저장 방식을 공유하게 만드는 기반 인프라는 병렬 실험을 서로 보완하게 한다. 제품이 작동하는지는 사용량과 선호도와 재방문과 추천과 실제 가치라는 기본 제품 시장 적합성 신호로 판단한다. 초기 컴퓨터 사용 제품은 실패했지만 평가 하네스에 보관됐고 모델 3.7에서 성공이 실패를 앞서는 도약을 포착했다. 오래된 모델만 사용하고 불가능하다고 단정하면 능력 맹점에 빠지므로 최신 모델로 다시 시험하고 평가를 남겨야 한다. 미래의 PM은 작은 팀과 개인이 모델의 잠재력을 실제로 활용하도록 연결과 판단과 운영을 설계하는 사람이다.