Why Claude can''t be your PM (yet)

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

Claude는 제품 업무를 지원할 수 있지만, 아직 사람들을 움직이고 제품의 방향과 실행을 책임지는 PM을 대체하지 못한다.

📌 핵심 요점

1. PM의 핵심은 사람의 문제와 조직을 연결하는 일이다. Claude는 관련 정보를 찾아낼 수 있지만, 이해관계자를 모으고 팀별 목표를 정렬해 일을 완수하도록 이끄는 조직적 영향력은 아직 부족하다.
2. 제작이 쉬워질수록 제품 판단이 중요해진다. 가능한 선택지가 늘어나면 사용자 문제를 이해하고 제한된 정보로 방향을 정해야 한다. 설계안을 오래 추론하던 방식도 여러 버전을 빠르게 만들어 시험하는 방식으로 재평가된다.
3. 에이전트 네이티브 제품에는 공통 기능 기반이 필요하다. 사람이 수행할 수 있는 일을 에이전트에도 열어주고, 사람·에이전트·REST API가 같은 처리 경로를 이용하도록 설계해야 한다. 변경 가능한 UI에도 정보 출처와 공통 디자인 규칙은 필요하다.
4. 병렬 실험은 공통 인프라와 명확한 책임으로 연결해야 한다. 열의를 가진 팀들이 서로 다른 접근을 탐색하되, 메모리와 정보 기반은 공유하고 투자·중단의 최종 결정권자는 분명히 해야 한다. 검증된 기능은 사용자가 자연스럽게 이해하는 핵심 경험으로 통합하는 과제가 남는다.
5. 실패한 실험도 평가 자산이 될 수 있다. 현재 모델의 한계로 막힌 프로젝트는 보류한 뒤 새 모델로 재시험할 수 있다. 최종 성공 기준은 기능 수가 아니라 실제 사용, 재방문, 만족과 문제 해결이며, 모델 역량을 더 많은 사람의 성과로 연결하는 것이 목표다.

🧩 배경과 문제 정의

• AI가 PM을 대체할 것이라는 전망과, 오히려 모두에게 제품 판단 역량이 필요해지는 현실 사이에서 PM의 역할을 다시 정의해야 한다.
• 제품 업무의 핵심은 사람의 문제와 기술을 연결하는 일이지만, 기술의 변화 속도가 빨라지면서 기존 전문성과 업무 방식도 계속 재검토해야 한다.
• 사람과 에이전트가 함께 사용하는 소프트웨어에서는 기능 접근성, 인터페이스의 변경 가능성, 공통 인프라를 새롭게 설계해야 한다. 동시에 빠른 실험과 사용자가 기대하는 안정성을 조율해야 한다.

🕒 시간순 섹션별 상세정리

1. PM의 중심은 사람의 문제이며, 역할의 경계는 다시 흐려진다

• 제품 업무는 사람의 실제 문제와 이를 해결할 기술을 연결한다. 기술이 과거에는 5~10년에 걸쳐 바뀌었다면 이제는 두 달마다 바뀌는 듯하지만, 사람과 그들의 문제는 같은 속도로 변하지 않는다. [01:35]
• 문제에 대한 이해는 유지하되, 해결 방식에 관한 기존 가정을 버리고 새로 접근해야 한다. PM은 정해진 역할에 머무르기보다 직접 문제를 풀고, 막히면 사람이나 지원 체계를 활용하는 일반적인 문제 해결자에 가까워질 수 있다. [02:38]

2. Claude가 지원해도 조직을 움직이는 PM은 필요하다

• Claude가 프로젝트를 충분히 지원한다고 생각했던 마이크도 PM 합류 후 누락될 수 있었던 업무와 커뮤니케이션이 정리되는 차이를 경험했다. 일주일 뒤에는 PM이 필요하다는 판단이 옳았다고 인정했다. [03:26]
• 개인 고객부터 대기업까지 이해관계자를 연결하고, 고객 성공팀의 대응 준비와 안전장치, 팀별 목표 정렬을 챙길 사람이 필요하다. 제작에 몰입한 구성원의 집중을 보호하는 이 역할은 작업 속도가 빨라질수록 더 높은 역량을 요구한다. [04:37]

3. 만들 수 있는 것이 늘수록 무엇을 만들지 판단하는 힘이 중요해진다

• 발전한 도구는 빠르게 만들 수 있는 제품의 범위를 넓혔지만, 변화가 빠르기 때문에 제한된 정보로 방향을 선택해야 한다. 가능한 경로가 많아질수록 하나의 방향을 정하고 추진하는 결단력이 중요해진다. [06:28]
• 사용자와 직접 연결되어 있고 사람의 문제를 이해하는 사람이 제품의 방향을 제시해야 한다. 불확실성 속에서도 판단하고 실행하는 힘이 핵심이다. [06:48]

4. 설계안을 오래 논의하던 전문성은 빠른 제작과 실험으로 재평가된다

• 제품을 만들고 출시하는 비용이 높았을 때는 버튼 위치, 손가락의 이동, 휴대전화를 꺼내는 상황까지 사전에 추론하는 능력이 중요했다. 이제는 세 가지 버전을 직접 만들어 시험하고 무엇이 작동하는지 확인하는 편이 더 빠르고 쉽다. [08:41]
• 익숙하고 잘하는 일을 반복하는 ‘혁신가의 딜레마’는 개인에게도 적용된다. 과거의 전문성이 새로운 방식의 도입을 막을 수 있으며, 기술이 바뀔 때마다 기존 자기 인식을 내려놓고 아직 능숙하지 않은 일을 시도해야 한다. [09:41]

5. 변화를 견딜 환경과 최종 결정의 책임을 함께 마련해야 한다

• 적응력, 판단력, 끈기가 중요하며, 계속 적응해야 하는 부담은 개인만의 문제가 아니다. 팀이 그 어려움과 감정을 함께 인정해야 변화가 고립된 경험이 되지 않는다. [10:31]
• 불확실성을 통제하려고 제품과 경력의 미래를 지나치게 미리 정하면 새로운 시도를 막을 수 있다. 혼란 속에서도 안전하게 실험할 수 있는 환경을 만드는 것이 생산성을 높이는 조건이다. [11:23]

6. 에이전트 네이티브 제품은 사람이 할 수 있는 일을 에이전트에도 열어준다

• AI 제품은 분리된 사이드바에서 질문에 답하는 단계에서, 기능 자체를 AI가 수행하는 단계와 에이전트 네이티브 구조로 발전하고 있다. 핵심 원칙은 사람이 할 수 있는 일을 에이전트도 수행할 수 있어야 한다는 것이다. [13:34]
• 이 원칙을 제대로 구현한 제품은 아직 드물고 Anthropic의 제품도 완전히 도달하지 못했다. 구현이 가능해지면 에이전트가 기존 기능들을 새로운 방식으로 조합하거나 작업 방법을 제안할 수 있다. [13:53]

7. 업무에 맞춰 바뀌는 UI에는 데이터 출처와 설계 규칙이 필요하다

• 최소 네 개의 독립적인 작업 흐름이 있는 복잡한 프로젝트에서 Claude가 전체 상황을 관찰하고 UI를 만들었다. 이 UI는 먼저 TPM이, 이후에는 전체 팀이 프로젝트 상태를 이해하는 데 쓰이며, 표시 방식도 Claude와 함께 수정할 수 있다. [14:42]
• Anthropic 내부에서 사용하는 소프트웨어의 상당 부분은 Claude가 만들고 유지·개선하며, 조직의 변화에 따라 계속 달라진다. 이에 따라 누가 정보를 갱신했는지, 사람이 조작했는지 Claude가 뒤에서 변경했는지, 정보의 출처를 어떻게 확인할지가 문제가 된다. [15:07]

8. 기존 SaaS의 전환은 공통 기능 기반과 점진적 UI 실험에서 시작된다

• 사람과 에이전트, REST API가 같은 처리 경로를 이용하도록 제품의 기본 기능과 구조를 설계해야 한다. 20년 동안 발전시킨 애플리케이션에 이를 뒤늦게 연결하는 일은 어렵고, 여러 기업이 전환을 진행하는 단계다. [16:26]
• 전체 UI를 곧바로 생성형으로 바꾸기보다 사이드 패널에서 시작하거나, 기존 기반과 매개변수를 활용하는 유연한 개인화 랜딩 페이지를 시험할 수 있다. 에이전트 기능이 따로 붙인 부속물처럼 느껴지지 않도록 제품 자체를 점진적으로 발전시켜야 한다. [16:56]

9. 초기에는 넓게 실험하고, 검증된 경험은 안정성을 원하는 사용자에게 정리한다

• 사용자마다 현재의 사용 방식과 변화 수용 수준이 다르며, 무엇이 효과적인지도 아직 초기 탐색 단계다. 모델과 사용 방식이 함께 변하므로 제품팀도 계속 접근법을 갱신해야 한다. [18:08]
• 새로운 경계를 찾는 동안에는 다양한 실험이 필요하다. 작동하는 방식을 발견한 뒤에는 더 안정적이고 완성된 경험을 원하는 사용자도 이해할 수 있도록 정리해야 하며, 이는 기존의 단순성·신뢰성·예측 가능성 중심 설계와 어려운 절충을 만든다. [18:46]

10. 병렬 실험은 팀의 의욕과 공통 인프라로 연결한다

• 팀이 관심을 갖지 않는 아이디어를 억지로 추진하기보다, 서로 다른 좋은 아이디어에 열의를 가진 두세 팀에 실험 기회를 주는 편이 낫다. 제품에 대한 팀의 의욕은 성공에 필요한 조건이라는 판단이다. [20:28]
• 약 3~6개월 전에는 Chat과 Cowork의 메모리, MCP, 파일 저장 방식이 분리되어 새 제품도 처음부터 단절될 위험이 있었다. Foundation 팀은 어느 제품에서든 메모리와 정보를 활용하도록 기반을 통합하며, 이 작업을 개별 탐색 제품팀 밖에서 맡아 실험 간 연결을 지원한다. [21:20]

11. 성공 여부는 여전히 사용과 재방문, 실제 문제 해결로 판단한다

• 제품과 시장의 적합성은 사람들이 사용하는지, 좋아하는지, 돌아오는지, 다른 사람에게 이야기하는지, 실제 도움을 얻는지로 확인한다. [22:05]
• 제품의 근본 목표는 계속 문제 해결이다. 사람들이 쉽게 사용할 수 있고 사용 후 만족을 느끼는 방식으로 문제를 해결하는지가 기준이다. [22:18]

12. 현재 모델의 한계로 막힌 프로젝트는 잠시 보류할 수 있다

• 지금 작동하지 않는 아이디어도 새 모델이 나오면 유효해질 수 있어, 너무 빨리 폐기하거나 기술 수준보다 지나치게 앞서 투자하는 판단 모두 어렵다. Labs에서는 일부 프로젝트를 한동안 보류하는 방식을 사용한다. [22:33]
• 2024년 처음 만든 컴퓨터 사용 제품은 모델 역량이 부족해 성능이 나빴다. 자동화에는 부적합하더라도 Photoshop 같은 복잡한 소프트웨어의 사용법을 익히는 데는 도움이 될 수 있다는 초기 가설이 있었지만, 실제 작동은 성공 여부를 확인하고 실패하면 중단하는 초기 에이전트 방식이었다. [23:02]

13. 실패한 실험을 평가로 남기고 모델의 한계를 다시 검증한다

• 자동화에도 학습에도 도움이 되지 않았던 시도를 보류한 뒤, 새 모델이 나올 때마다 평가 환경에서 다시 시험했다. 3.7의 컴퓨터 사용 능력이 크게 향상됐다는 판단은 실제 동작과 기록에서 실패보다 성공이 많아진 모습을 확인한 데서 나왔다. [23:24]
• 현재 모델이 준비되지 않았음을 확인한 프로젝트도 평가로 공개하거나 연구팀과 연결하면 가치가 있다. 2~6개월 뒤 다시 검토하며 새로운 배움을 얻을 가능성이 있으므로, 실험을 일찍 시작해 한계를 구체적으로 파악중요하다. [23:50]

14. 검증된 기능을 핵심 경험에 통합해 사용자의 선택 부담을 줄인다

• 성공한 병렬 실험을 각각 탭으로 추가하면 동작 방식이 제각각인 제품이 될 수 있고, 별도 앱으로 유지하면 경험이 통합되지 않을 수 있다. 여러 실험을 일관된 제품으로 만드는 문제에는 아직 완전한 해법이 없다. [25:37]
• 사용자는 도구 목록을 받아 직접 선택하기보다, 많은 고민 없이 자연스럽게 제품을 사용하기를 기대한다. 시스템이 사용자를 이해하고 UI가 직관적으로 느껴지도록 기본 구조를 만들되, 사용자 반응에 따라 반복적으로 조정해야 한다. [26:16]

15. 향후 제품의 과제는 모델 역량을 더 많은 사람의 실제 성과로 연결하는 것이다

• 향후 1년에는 사람들이 원하는 것을 만들고, 필요한 때와 장소에서 답을 얻으며, 사업을 시작하기가 더 쉬워지기를 기대한다. 소규모 팀과 개인 창업자의 역량이 커지면, 도구를 직접 사용하지 않는 사람도 이들이 만든 결과물에서 혜택을 얻을 수 있다. [27:54]
• 모델의 능력과 대다수 사람의 실제 활용 사이의 격차는 사용자 탓이 아니라, 그 능력을 활용하게 만드는 제품을 충분히 제공하지 못한 책임으로 본다. 이를 가능하게 하는 제품 개발은 갈수록 어려워지고 있지만, 격차를 줄이는 것이 가장 큰 목표이며 더 많은 사람에게 역량을 열어 주는 방향이다. [28:18]

🧾 결론

• PM의 역할은 고정된 업무 목록보다 사용자 이해, 제품 판단, 조직 조율과 실행 책임을 중심으로 다시 정의된다.
• 빠른 실험을 허용하는 환경과 최종 결정을 책임지는 사람을 함께 마련해야 탐색이 다음 행동으로 이어진다.
• 에이전트 기능의 확대는 제품 구조와 사용자 경험을 함께 바꾸는 과제다. 공통 기반, 정보 출처, 예측 가능성이 개인화와 함께 필요하다.
• 모델의 발전을 놓치지 않으려면 과거의 실패를 기록하고 재평가해야 한다. 동시에 실제 사용자에게 도움이 되는지는 별도로 확인해야 한다.

📈 투자·시사 포인트

• 제품·기업 평가: 모델 성능이나 구현 속도와 함께 사용자가 돌아오는지, 만족하는지, 실제 문제를 해결하는지를 확인필요가 있다.
• 기존 SaaS의 전환: 사람과 에이전트가 공유하는 기능 구조를 갖추는 능력이 주요 검토 항목이다. 오래된 애플리케이션에 이를 뒤늦게 연결하는 데는 어려움이 있다는 설명이다.
• 개발 자원 배분: 현재 작동하지 않는 아이디어를 즉시 폐기하거나 계속 투자하기보다, 보류와 재평가를 선택지로 둘 수 있다. 다음 투자의 근거는 새 모델에서 확인한 실제 동작과 학습이어야 한다.
• 인력과 조직: 제작 속도가 빨라질수록 사용자 문제를 이해하고 팀을 정렬하며 방향을 결정하는 역량의 필요성이 커진다. 패널의 사례는 AI 도입만으로 PM 역할이 사라진다고 보기 어렵다는 점을 보여준다.

⚠️ 불확실하거나 확인이 필요한 부분

• Claude의 조직적 영향력 한계와 PM 합류 효과는 패널에서 소개한 경험에 근거한다. 모든 조직에 적용할 수 있는 비교 실험이나 정량 지표는 제시되지 않았다.
• 에이전트 네이티브 원칙은 Anthropic 제품에서도 완전히 구현되지 않았다고 설명한다. 인터페이스 변경과 기능 조합의 가능성을 보편적으로 검증된 상태로 받아들이기는 어렵다.
• 병렬 실험을 일관된 제품 경험으로 통합하는 데는 아직 완전한 해법이 없다. 빠른 탐색과 안정성·예측 가능성 사이의 절충도 남아 있다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• 현재 제품 업무에서 Claude가 지원하는 작업과 사람이 책임지는 이해관계자 조율·방향 결정·실행 관리를 정리한다.
• 해결할 사용자 문제를 명시하고, 여러 작은 버전을 만들어 실제 사용과 반응을 비교한다.
• 병렬 실험마다 최종 결정권자와 다음 학습 행동을 정하고, 제품 간 공유해야 할 메모리·정보·기능 기반을 점검한다.
• 사람이 수행하는 핵심 기능을 에이전트도 이용할 수 있는지 확인하고, 변경 가능한 UI의 정보 출처와 갱신 주체를 추적할 방법을 마련한다.

❓ 열린 질문

• Claude가 조직적 영향력까지 갖췄다고 판단하려면 어떤 행동과 결과가 확인되어야 할까?
• 병렬 실험의 다양성을 유지하면서 사용자에게 일관되고 예측 가능한 경험을 제공하려면 무엇을 공통화해야 할까?
• 모델 한계로 막힌 프로젝트의 보류·재개·중단을 어떤 평가 결과로 결정할 수 있을까?