AI 시대 PM 역할 재정의: PRD 폐기·리서치 프리뷰, 못 하면 도태된다

AI product team rapidly shipping features in an abstract flat illustration

AI 시대 PM, 이 정도 못 하면 진짜 자격 없다

Kim Jongwook · 2026-04-26

핵심 요약

Comparison of PRD-heavy workflow and fast AI-driven product process

6개월짜리 기능을 하루 만에 내는 구조.
PRD 폐기, 역할 해체, 리서치 프리뷰.
PM 핵심은 코드가 아닌 프로덕트 테이스트.
가장 어려운 건 ‘지금’ 모델에 맞춘 설계다.
인간의 마지막 영역은 EQ와 맥락 판단이다.

Table of Contents

AI 시대 PM, 이 정도 못 하면 진짜 자격 없다

이게 왜 지금 중요한가

AI가 코드를 쓰는 시대에 “기획서 잘 쓰는 PM”만으로는 버티기 어렵다. Anthropic의 Claude Code 팀이 90일 동안 35개 기능을 내며 출시 주기를 6개월에서 하루로 줄인 방식은, PM이라는 역할 자체가 어떻게 바뀌고 있는지를 적나라하게 보여준다.

Cat Wu(Claude Code Head of Product)의 인터뷰를 바탕으로, PRD 폐기부터 프로덕트 테이스트, 모델 역량에 맞춘 설계, 인간이 유지하는 고유 영역까지 AI 시대 PM에게 필요한 핵심을 정리했다. AI 제품 팀과 직접 일하면서 느낀 인사이트와도 맞닿아 있어서, 실무에 바로 가져다 쓸 수 있는 내용들이다.

Anthropic의 폭주 속도란 무엇인가?

PM selecting a few high-taste AI features among many options

Anthropic의 폭주 속도란 90일 동안 35개 기능을 내는 수준의 극단적으로 짧은 출시 주기를 가진 제품 개발 방식이다. 인력 규모나 예산이 아니라 조직 구조와 PM 역할 재정의에서 나온다.

90일 동안 35개 기능을 출시했다.
평균 2.6일에 하나꼴로 메이저 기능이 나온다.
과거 6~12개월 걸리던 기능이 한 달·하루 단위로 줄었다.
AI가 코드 속도를 올린 만큼 조직 구조도 바꿨기 때문이다.

2025년 1~3월, 불과 90일 동안 Anthropic은 모델·제품·Claude Code·엔터프라이즈·플랫폼 전 영역에서 35개 기능을 출시했다. 숫자로 환산하면 2.6일마다 하나의 메이저 기능이 새로 나온 셈이다.

“예전에는 기능 하나에 12개월이 걸리기도 했습니다. 지금은 그 타임라인이 한 달로, 때로는 하루로까지 줄어들었습니다.” — Cat Wu

다른 빅테크·유니콘 PM 조직과 일할 때 보면, 메이저 기능 하나에 3~6개월이 기본이었다. 이 속도는 사실상 완전히 다른 게임이다. 이 차이를 만든 네 가지 기둥이 바로 PRD 폐기, 역할 경계 모호화, 코딩 가능한 PM, 리서치 프리뷰 전략이다.

한눈에 보는 핵심

속도는 인력·예산이 아니라 구조의 문제다.
AI가 코드 속도를 올리면 조직도 바뀌어야 한다.
Anthropic은 출시 단위를 ‘월’에서 ‘일’로 줄였다.
이 속도를 뒷받침하는 네 가지 메커니즘이 있다.

PRD 폐기란 무엇이고 왜 가능한가?

PRD 폐기란 전통적인 Product Requirements Document를 없애고, 숫자와 팀 원칙만으로 제품 결정을 내리는 구조다. 핵심은 문서를 줄이는 대신, 모두가 같은 맥락을 공유하게 만드는 것이다.

PRD 대신 매주 메트릭 리뷰와 팀 원칙 문서만 유지한다.
메트릭 리뷰로 정보 비대칭을 줄이고 누구나 판단하게 만든다.
팀 원칙 문서가 모든 의사결정의 기준점이 된다.
PM 승인·결재 라인을 제거해 출시 속도를 끌어올린다.

보통 소프트웨어 조직에서는 PM이 PRD를 쓰고, 디자인 팀에 넘기고, 디자인이 끝나면 개발 팀에 넘기는 핸드오프 체인이 존재한다. 직접 경험해본 대부분의 팀에서 이 체인만으로도 몇 주가 증발했다.

Claude Code 팀은 이 체인을 통째로 없애고 두 가지로 대체한다.

매주 메트릭 리뷰
전원이 회사·제품이 어떻게 돌아가는지 숫자로 함께 본다.
“지금 무엇이 잘되고 있고, 무엇이 안 되는지”를 모두가 안다.
특정 PM에게 허락을 받기보다, 누구나 상황을 이해하고 판단한다.
팀 원칙 문서
핵심 사용자는 누구인지, 왜 그들이 중요한지 명문화한다.
모든 기능·우선순위 결정의 기준점이 된다.
“이게 우리 핵심 사용자에게 도움이 되는가?” 한 줄로 판단한다.

결과적으로 PM은 승인·결재를 위한 문서 작성자가 아니라, 원칙을 설계하고 메트릭을 해석하는 사람이 된다.

핵심만 빠르게 정리하면?

PRD를 없애고 메트릭·원칙만 남긴다.
메트릭 리뷰로 모두가 같은 숫자를 본다.
팀 원칙 문서가 일관된 판단 기준이 된다.
PM은 문서 작성자에서 맥락 설계자로 이동한다.

역할 경계 해소란 무엇인가?

역할 경계 해소란 PM·디자이너·엔지니어 사이의 역할 구분을 흐리고, 한 사람이 아이디어·설계·구현까지 이어서 맡는 구조다. Claude Code 팀에서는 “코딩하는 PM, 프론트 짜는 디자이너, PM 역할도 하는 엔지니어”가 기본값이다.

PM이 직접 코드를 커밋하고 제품을 만든다.
디자이너는 프론트엔드를 직접 개발한다.
엔지니어는 PM 역할을 겸하며 제품 방향에 깊게 관여한다.
채용은 ‘전통적 PM’보다 제품 감각 좋은 엔지니어 위주다.

Cat Wu 본인도 엔지니어 출신이고, 팀의 PM 대부분이 코드를 짜거나 과거에 짰던 사람들이다. 팀 디자이너 상당수는 프론트엔드 엔지니어 출신이다.

아이디어가 나오면 그 사람이 직접 만들고, 일주일 안에 시장에 나가는 구조다. PRD 작성, 디자인 핸드오프, 개발 인계 과정이 사라지기 때문에 납기 대부분이 줄어든다.

“전통적인 조직에서 6개월이 걸리는 진짜 이유는 기능 자체의 복잡성 때문만이 아니라, 반복되는 인계 과정과 대기 시간 때문입니다.”

여러 팀을 보면서 느낀 건, 기능의 본질적 난이도보다도 ‘다른 팀이 줄 때까지 기다리는 시간’이 훨씬 크다는 점이다. Claude Code 팀은 이 병목을 구조적으로 제거했다.

한눈에 보는 핵심

한 사람이 아이디어→코드까지 이어서 맡는다.
디자이너·PM·엔지니어의 경계가 거의 없다.
제품 감각 좋은 엔지니어가 PM을 대체한다.
인계·대기 시간이 사라져 출시 속도가 폭발한다.

리서치 프리뷰란 무엇이며 왜 중요한가?

리서치 프리뷰란 아직 완성되지 않은 기능을 실험적 상태로 명시해 공개하는 출시 레이블이다. “이건 실험 중인 기능이며, 언제든 사라질 수 있다”는 기대치를 미리 합의하는 장치다.

거의 모든 기능을 리서치 프리뷰로 먼저 출시한다.
“초기 단계·실험·영원히 유지되지 않을 수 있음”을 명확히 알린다.
팀은 ‘완벽한 완성도’ 압박에서 자유로워진다.
사용자는 실험적 특성을 알고 쓰기 때문에 기대치를 조정한다.

이 전략의 핵심은 쌍방향 기대치 관리다.

팀 입장에서는 “완성 후 출시”가 아니라 “실험을 위한 출시”이므로 결정을 빨리 내릴 수 있다. 실패·폐기 가능성이 전제되어 있어 내부 논의도 짧아진다. 사용자 입장에서는 기능이 사라지거나 바뀌어도 배신감보다 “실험이었지”라는 이해가 앞서고, 적극적인 피드백 루프에 참여할 심리가 생긴다.

또 하나 흥미로운 결과는 기능 삭제의 가속화다. 모델이 개선되면, 그 모델을 보완하기 위해 만들었던 기능을 주저 없이 지운다. 초기에는 Claude가 컨텍스트를 잃지 않도록 투두 리스트 기능을 달았지만, 모델이 자체 추적·관리가 가능해지자 자연스럽게 전면에서 걷어냈다.

모델이 스스로 만든 도구를 잡아먹는 구조다. 빠르게 만들고, 빠르게 지우는 사이클이 리서치 프리뷰이기에 가능해진다.

핵심만 빠르게 정리하면?

리서치 프리뷰는 실험임을 명시하는 레이블이다.
팀은 완성도 압박 없이 빨리 내놓을 수 있다.
사용자는 변화·삭제 가능성을 알고 사용한다.
모델 개선에 따라 기능을 과감히 삭제한다.

미션 기반 의사결정은 왜 프로세스를 대체하는가?

미션 기반 의사결정이란 개별 팀·제품의 목표보다 회사의 미션을 상위 기준으로 두고, 충돌할 때마다 미션에 더 가까운 쪽으로 즉시 결정하는 방식이다. 이 구조가 있기에 PRD나 복잡한 승인 체계 없이도 조직이 돌아간다.

미션이 모든 의사결정의 디폴트 기준이 된다.
우선순위가 충돌하면 “어느 쪽이 미션에 더 가까운가”로 판단한다.
개인·팀 KPI보다 회사 미션이 우위에 놓인다.
덕분에 긴 회의 없이도 빠른 결정을 내릴 수 있다.

Anthropic의 미션은 “안전한 AGI를 인류에게 가져다 주자”다. 다소 추상적으로 보이지만, Cat Wu에 따르면 실제 일상적 선택의 방향타로 쓰인다.

“미션은 팀들이 자신의 목표를 희생해서라도 Anthropic의 목표를 위해 움직일 의지를 만들어줍니다. 극단적인 예시로, 만약 Claude Code가 실패하더라도 Anthropic이 성공한다면 저는 매우 행복할 것입니다.”

제품 헤드가 “내 제품이 망해도 회사 미션이 달성되면 행복하다”고 말할 수 있다는 건, 성과 구조와 문화가 그 방향으로 이미 정렬되어 있다는 뜻이다. 이런 조직에서는 “Claude Code에는 편하지만 Anthropic 전체에는 안 좋은 선택”이 나오면 긴 논쟁 대신 빠르게 방향을 바꾼다.

물론 대가도 있다. 제품 일관성(consistency)이 떨어진다. 동일한 문제를 해결하는 기능이 둘·셋씩 공존할 수 있고, 사용자는 무엇이 베스트 프랙티스인지 직관적으로 알기 어렵다. Cat Wu는 이를 “일관성을 시장에 위임했다”고 표현한다. 완벽한 내부 정합성보다 시장 피드백이 정리의 기준이다.

한눈에 보는 핵심

미션이 의사결정의 최상위 기준이다.
팀 성과보다 회사 미션이 우선한다.
덕분에 회의·승인 절차가 극적으로 줄어든다.
대신 일관성을 일부 희생하고 시장에 위임한다.

프로덕트 테이스트란 무엇이며 왜 PM의 핵심인가?

프로덕트 테이스트(Product Taste)란 수많은 기능 요청 중 무엇을 만들지, 어떻게 만들어야 사용자가 가장 좋아할지를 가려내는 제품 감각이다. AI 시대에는 이 감각이 PM의 최핵심 역량으로 떠올랐다.

코드는 싸졌고, 진짜 희소한 것은 ‘무엇을 만들지’ 결정하는 안목이다.
Claude Code 팀에는 매일 수만 개의 GitHub 이슈가 쏟아진다.
그중 무엇을 어떤 UX로 구현할지 고르는 것이 PM의 핵심 역할이다.
이 감각은 자격증이 아니라 경험·피드백·직접 사용에서 길러진다.

“코드 작성이 훨씬 저렴해짐에 따라 더 가치 있어지는 것은 무엇을 쓸지 결정하는 것입니다. 수만 개의 GitHub 이슈 중 어떤 것을 만들지 판단하는 데는 많은 안목과 감각이 필요합니다.”

AI가 코드를 대신 쓰기 시작하면서, ‘어떻게 만들지(How to build)’의 희소성은 떨어지고 ‘무엇을 만들지(What to build)’의 희소성이 폭발적으로 올라갔다. 매일 수만 개의 기능 요청이 GitHub에 쏟아지는 신호의 바다 속에서, 무엇이 진짜 가치 있는지 판단하는 것이 PM의 본질이 됐다.

Cat Wu에 따르면 이 프로덕트 테이스트는 학교나 부트캠프에서 가르치기 어렵다. 사용자 피드백을 끝없이 읽고, 제품을 매일 직접 쓰고, 모델의 한계를 몸으로 겪어보며 서서히 길러진다. 그래서 Claude Code 팀의 PM들은 단순 ‘관리자’가 아니라 도구의 헤비 유저다.

실제로 AI 도구를 다루는 PM을 보면, 하루에 그 도구를 몇 시간이나 쓰는지가 성과와 거의 1:1로 비례한다. 책상 위에서만 제품을 보는 PM과, 매일 자신의 워크플로를 그 제품 위에 올려놓고 사는 PM은 전혀 다른 결정을 내린다.

한눈에 보는 핵심

AI 시대 PM의 핵심은 ‘무엇을 만들지’ 감각이다.
코드 비용이 낮아질수록 기획 결정의 가치가 커진다.
프로덕트 테이스트는 실사용과 피드백 속에서만 자란다.
PM은 도구의 관리자이자 헤비 유저여야 한다.

모델 역량에 맞는 제품 설계란 무엇인가?

모델 역량에 맞는 제품 설계란, 현재 모델이 실제로 할 수 있는 수준에 정확히 맞춘 UX·기능 범위를 정의하는 작업이다. Cat Wu는 이를 “AGI 필드의 적정선 찾기”라고 부른다.

모델 성능과 사용자 행동이 매달 변하는 전제에서 설계해야 한다.
AGI를 과신하면 현재 작동하지 않는 ‘미래형 제품’을 만들게 된다.
모델을 과소평가하면 6개월 뒤 쓸모없는 보수적 제품을 만들게 된다.
PM은 새 모델이 나올 때마다 이 다이얼을 계속 재조정해야 한다.

두 가지 극단이 있다.

첫 번째는 AGI 과신형이다. “언젠가 슈퍼 AGI가 다 해줄 테니 텍스트 박스 하나면 충분해.” 하지만 현재 모델은 그 수준이 아니라서 실제로는 제대로 작동하지 않는다.

두 번째는 AGI 불신형이다. “모델은 여전히 멍청하니 안전하게 보수적으로 설계하자.” 그러면 6개월 뒤 모델이 크게 좋아졌을 때 기존 제품이 구시대 유물이 된다.

“미래의 슈퍼 AGI용 제품을 만드는 건 정말 쉽다. 진짜 어려운 건 지금 모델의 능력을 최대로 끌어내는 제품을 만드는 것이다.”

그 사이 어딘가, 즉 지금 이 모델을 100% 쓰되 3~6개월 뒤에도 완전히 버려지지 않는 제품을 설계하는 게 PM의 실력이다. 새 모델이 나올 때마다 계획을 과감히 뜯어고치는 용기도 필요하다.

여러 LLM 기반 제품 로드맵을 보며 느낀 건, 연간 로드맵이 의미를 잃고 1~2분기 단위의 가변 계획이 표준이 되어 간다는 점이다. 모델 릴리스 한 번에 UX 설계 철학이 바뀌기 때문이다.

한눈에 보는 핵심

PM의 가장 어려운 스킬은 ‘지금 모델에 맞춘 설계’다.
AGI 과신과 불신 양극단 모두 위험하다.
새 모델이 나올 때마다 제품 방향을 재조정해야 한다.
연간 고정 로드맵보다 유동적 설계 감각이 중요하다.

인간 고유 영역이란 무엇이고 얼마나 남았는가?

인간 고유 영역이란, 현재 AI 모델이 대체하기 어려운 관계·맥락·감정 기반 판단 영역이다. Cat Wu는 “초지능이 오기 전까지 인간 두뇌가 계속 필요한 영역”을 네 가지로 정리한다.

이해관계자 파악: 이번 출시가 누구에게 어떤 영향을 미치는지.
관계 구조 이해: 이해관계자들이 서로 어떻게 얽혀 있는지.
개인 선호 인식: 각자가 좋아하고 불편해하는 소통 방식이 무엇인지.
소통 채널 판단: 누구에게 언제, 어떤 자리에서, 어떤 형식으로 알려야 하는지.

“현재 모델이 가지지 못한 수준의 상식을 인간이 제공합니다. 이해관계자가 누구인지, 그들이 서로 어떻게 연결되어 있는지, 각자의 선호가 무엇인지 모델은 아직 잘 알지 못합니다.”

이건 문서에 잘 적히지 않는 맥락적 상식(Contextual Common Sense)과 EQ 기반 지식이다. 조직 안에서 수년간 축적된 관계·역사·암묵적 규칙이 섞여 있고, 지금 LLM들이 가장 손대기 어려운 영역이기도 하다.

다만 Cat Wu는 중요한 단서를 달았다. 이 영역도 결국 모델이 점점 잘하게 될 거라는 점이다. 영구적인 인간 우위가 아니라 “현재 시점의 갭”에 가깝다.

현업에서 느끼는 것도 비슷하다. 오늘의 인간 고유 영역이 내일도 고유할 거라는 보장은 없다. 살아남는 PM은 고정된 스킬셋보다 갭이 이동할 때마다 따라붙는 민첩성을 가진 사람이다.

한눈에 보는 핵심

지금 AI가 가장 약한 부분은 EQ·관계·맥락 판단이다.
이해관계자·관계 구조·개인 선호·소통 채널이 핵심 예시다.
이 영역은 문서화되지 않은 암묵지에 가깝다.
하지만 이 우위도 영구적이진 않으며, 결국 줄어든다.

Claude Code PM vs 전통 PM: 무엇이 더 적합할까?

Claude Code PM과 전통 PM은 역할 정의부터 채용 기준까지 완전히 다른 직업에 가깝다. 어느 쪽이 “더 낫다”기보다, 어떤 환경에 더 잘 맞는가의 문제다.

Claude Code PM은 코드를 직접 쓰고, 모델 역량에 맞춰 방향을 수시로 조정한다.
전통 PM은 기획·조율·커뮤니케이션 중심의 허브 역할을 수행한다.
Anthropic은 ‘프로덕트 테이스트 뛰어난 엔지니어’를 PM으로 본다.
AI 중심 조직일수록 Claude Code식 PM 모델이 적합하다.

주요 옵션 비교

항목	Claude Code형 PM	전통 PM
주요 스킬	코딩, 모델 이해, 제품 감각	요구사항 정리, 커뮤니케이션
역할 정의	아이디어→설계→구현까지 직접 수행	아이디어→설계 후 팀에 인계
조직 구조 적합도	AI·개발 중심, 빠른 실험 조직	대규모, 기능 조직, 규제 환경
문서 의존도	낮음 (메트릭·원칙 중심)	높음 (PRD·로드맵 중심)
채용 기준	엔지니어 출신·헤비 유저·테이스트	기획 경험·도메인 지식·조율 능력

Claude Code 팀은 PM을 “기획자”라기보다 제품 감각 좋은 엔지니어로 정의한다. 매일 도구를 쓰고, 모델 변화에 촉이 빠르고, 코드를 직접 건드려 실험을 굴릴 수 있는 사람이 기준이다.

반면, 복잡한 규제·다수의 이해관계자·장기 프로젝트가 많은 조직에서는 전통 PM의 장점이 여전히 크다. 여러 팀을 정렬하고, 리스크를 관리하고, 중장기 로드맵을 그리는 능력이 중요한 환경이다.

경험상 느끼는 건 이렇다. AI 제품이 비즈니스의 중심인 조직일수록 Claude Code형 PM이 유리하고, AI가 여러 기능 중 하나에 불과한 대기업·레거시 환경에서는 전통 PM이 여전히 필요하다.

요약 체크리스트: AI 시대 PM 전환 점검

[ ] 매일 내가 만드는 도구를 직접 사용하기
[ ] 팀 핵심 메트릭과 원칙을 암기 수준으로 이해하기
[ ] 코드를 최소한 실험 가능한 수준까지 다뤄 보기
[ ] PRD 분량 줄이고 실험 주기부터 줄이기
[ ] 기능 대신 문제·사용자 경험 중심으로 사고하기
[ ] 새 모델 릴리스 때마다 제품 방향 재점검하기

지금 당장 무엇부터 할까?

거창한 커리어 계획보다 오늘 당장 할 수 있는 작은 전환이 중요하다.

지금 사용하는 AI 도구 한 개를 골라 매일 1시간 이상 진짜 업무에 써 본다.
팀 제품의 핵심 메트릭과 미션 문장을 적어두고, 의사결정 때마다 비교해 본다.
사이드 프로젝트 수준이라도 좋으니, 직접 코드 커밋이 포함된 작은 기능을 한 번 끝까지 만들어 본다.
PRD를 쓴다면, 다음 스프린트에는 분량을 절반으로 줄이고 실험 가설·메트릭만 남겨 보기를 시도한다.
매주 출시되는 모델·기능 업데이트를 보며, “이 변화가 3개월 뒤 우리 제품에 주는 영향”을 글로 적어 본다.
팀 내에서 이해관계자·관계 구조·선호·소통 채널을 맵으로 그려 보며 맥락 이해 훈련을 한다.

자주 묻는 질문 (FAQ)

Q. PRD를 완전히 없애야만 Anthropic 같은 속도를 낼 수 있나요?

반드시 그렇지는 않다. 핵심은 문서를 줄이는 게 아니라, 정보 대칭과 명확한 원칙을 만드는 것이다. 규제가 많거나 이해관계자가 복잡한 조직에서는 PRD가 여전히 필요할 수 있다. 다만 PRD의 목적을 “승인용”이 아니라 “실험 가설·메트릭 정리용”으로 재정의하는 것만으로도 속도는 크게 달라진다.

Q. 코딩을 못하면 AI 시대 PM으로서 생존이 어렵나요?

코딩 자체가 필수 자격은 아니다. 하지만 코드를 통해 빠르게 실험을 돌려볼 수 있는 능력은 분명 경쟁력이다. 간단한 스크립트나 프로토타입을 모델과 함께 만들 수 있으면, 개발팀 의존도가 줄고 아이디어 검증 속도가 빨라진다. 중요한 건 프로덕트 테이스트와 실험 속도이지, 정교한 엔지니어링 능력이 아니다.

Q. 리서치 프리뷰 전략은 B2B 엔터프라이즈 제품에도 통할까요?

고객 성향에 따라 조정이 필요하지만, 기대치 관리라는 본질은 그대로 통한다. “파일럿”, “베타”, “리서치 프리뷰” 등 어떤 라벨을 쓰든, 실험이라는 사실을 분명히 하면 완성도 부담이 줄고 피드백 루프가 빨라진다. SLA나 규제가 중요한 환경에서는 적용 범위와 고객 그룹을 제한하는 게 현실적이다.

Q. 프로덕트 테이스트를 어떻게 키울 수 있나요?

정식 교육보다 직접 사용과 피드백 노출이 핵심이다. 매일 제품을 쓰면서 “어디가 거슬리는지”를 기록하고, 고객 피드백·리뷰·이슈를 꾸준히 읽는 게 중요하다. 잘 만든 제품들을 많이 써보고, “왜 이 패턴이 좋은지”를 언어로 설명해 보는 연습도 도움이 된다. 이 과정을 6~12개월만 꾸준히 해도 제품 감각이 눈에 띄게 달라진다.

Q. 인간 고유 영역도 결국 AI가 대체한다면, PM은 어디로 가야 하나요?

포인트는 영구적인 안전지대를 찾는 게 아니라, 갭이 이동할 때마다 자신도 함께 이동하는 유연성을 확보하는 것이다. 지금은 EQ·관계·맥락이 인간 우위지만, 시간이 지나면 또 다른 갭이 생긴다. 제품 감각·실험 속도·모델 이해·조직 설계 등을 폭넓게 익혀 두면, 갭이 어디로 이동하든 그 근처에서 새로운 역할을 만들 수 있다.

핵심 정리와 다음 단계

Anthropic Claude Code 팀은 PRD 폐기, 역할 경계 해체, 리서치 프리뷰, 미션 기반 의사결정이라는 네 가지 축을 통해 과거 6~12개월 걸리던 기능 출시를 한 달, 심지어 하루 단위로 줄였다. AI가 엔지니어링 속도를 끌어올리자 병목은 완전히 “무엇을 만들지 결정하는 감각과 현재 모델에 맞춘 설계”로 옮겨갔다.

AI 시대 PM에게 남은 본질은 세 가지다.

프로덕트 테이스트. 수많은 요청 속에서 진짜를 고르고, 잘 만들 줄 아는 안목이다. 모델·시장 변화에 맞춘 다이얼 조정 능력. AGI 과신도 불신도 아닌, 지금 쓸 만한 제품을 반복해서 만드는 힘이다. 그리고 EQ와 맥락 이해. 이해관계자, 관계 구조, 선호, 소통 채널을 읽고 조직을 움직이는 인간 고유 영역이다.

직접 적용해보면, 이 세 가지를 의식적으로 훈련하는 것만으로도 PM으로서의 의사결정 질과 속도가 눈에 띄게 달라진다. “기획서를 얼마나 잘 쓰는가”보다 “모델·조직·사용자를 얼마나 깊이 이해하고, 얼마나 빨리 실험할 수 있는가”가 커리어의 핵심 축이 되고 있다.

참고할 만한 추가 자료

Anthropic 헌장 및 미션: https://www.anthropic.com/
Lenny’s Podcast (제품·성장·PM 인사이트): https://www.lennyspodcast.com/
Google 제품 개발·PM 가이드: https://productmanagement.google/
OpenAI 모델 및 제품 업데이트 로그: https://platform.openai.com/docs/
GitHub Issues 사용 패턴 소개: https://docs.github.com/ko/issues

Found this article helpful?

Get more tech insights delivered to you.

이메일로 블로그 구독하기