AI 시대 PM의 역할, 세 가지 역량으로 다시 정의하다

출처: SVPG (Marty Cagan)
원문: https://www.svpg.com/a-fresh-definition-of-the-product-role/
원문 발행일: 2026-08-10
작성자: 팔복소프트-김팔복

한눈에 보기

• SVPG의 Marty Cagan이 애널리스트 Benedict Evans의 글에서 "AI 시대 PM 역할에 대한 가장 좋은 설명"을 발견했다며 소개했다.
• Evans의 글 제목은 "Most People Aren't Tool Builders"로, 유료 구독자만 볼 수 있지만 같은 내용을 다룬 팟캐스트는 공개되어 있다.
• 핵심 주장은 "AI 덕분에 누구나 도구를 만들 수 있게 됐어도, 대부분의 사람과 기업은 만들지 않고, 시도해도 성공하기 어렵다"는 것이다.
• Evans는 강한 프로덕트 인재의 역량을 세 가지로 구분한다: 불편 뒤에 숨은 일반적인 문제를 보는 능력, 그 문제에 맞는 해결책을 찾는 능력, 회사 전체에서 통하는 해결책을 찾는 능력.
• Cagan은 이를 각각 문제 발견(problem discovery), 가치 리스크(value risk), 사업성 리스크(viability risk)에 대응시킨다.
• Cagan은 1년 전 "The Era of the Product Creator"에서 기대했던 만큼 새로운 프로덕트 크리에이터가 늘지 않았음을 인정한다.
• 결론은 분명하다. 문제는 도구가 아니라 사고방식과 프로덕트 역량이며, PM 역할은 앞으로도 필수적이다.

배경

Marty Cagan은 『Inspired』 저자이자 SVPG 창립자로, 실리콘밸리식 프로덕트 조직 운영 모델을 오랫동안 설파해 온 인물이다. 그가 자주 쓰는 "네 가지 리스크"(가치·사용성·실현 가능성·사업성) 프레임은 국내 프로덕트 팀에서도 익숙하다. Benedict Evans는 a16z 출신 기술 산업 애널리스트로, 매년 발표하는 산업 트렌드 슬라이드로 잘 알려져 있다. 이번 글은 Cursor, Claude Code, Lovable 같은 도구로 "비개발자도 앱을 만든다"는 이야기가 흔해진 시점에, 그 기대가 왜 현실과 어긋나는지를 프로덕트 역할 관점에서 짚는다.

주요 내용

100가지 정의가 있는 역할

Cagan은 PM/PO 역할의 정의를 지금까지 100개는 봤을 거라고 말한다. 조직 운영 모델마다 요구하는 책임과 스킬이 다르고, 사람들이 짧은 캐치프레이즈로 복잡한 역할을 압축하려 하기 때문이다. 그는 면접에서 "당신의 역할을 어떻게 정의하느냐"를 수십 년간 물어 왔는데, 정답을 찾으려는 게 아니라 후보자가 어떤 프로덕트 모델에서 일했고 이 역할이 왜 존재한다고 믿는지가 드러나기 때문이라고 설명한다.

그런 그가 "프로덕트라는 단어를 거의 쓰지도 않은 글"에서 최고의 정의를 발견했다는 점이 이번 글의 출발점이다.

도구를 잘 쓰는 사람과 만드는 사람은 다르다

Evans의 원래 논지는 이렇다. 바이브 코딩이든 에이전트 기반 업무 자동화든, 고객이 스스로 해결책을 만들 수단이 생겼다고 해서 실제로 만들지는 않는다. Cagan이 옮긴 Evans의 표현이 이 논지를 압축한다.

"영업을 잘 알아야 좋은 영업 소프트웨어를 만들 수 있지만, 영업을 잘한다고 영업 소프트웨어를 잘 만들게 되는 것은 아니다." — Benedict Evans (Cagan의 인용)

Evans는 이 논지를 펴는 과정에서 일반 사용자의 사고방식과, 새로운 도구를 잘 만드는 사람의 사고방식을 대비시킨다. Cagan은 바로 이 대비가 강한 PM의 역량 정의로 읽힌다고 봤다.

세 가지 역량과 Cagan의 매핑

Cagan은 이 세 가지가 PM만의 전유물은 아니지만, 세 가지를 모두 갖춘 사람은 드물다고 강조한다.

도구는 좋아졌는데 사람은 따라오지 않았다

Cagan은 자기 반성도 덧붙인다. 약 1년 전 발표한 "The Era of the Product Creator"에서 새로운 도구가 발견과 전달 과정을 크게 개선했다며 많은 사람이 프로덕트 크리에이터가 될 거라 기대했지만, 그 기대는 "조금은 맞았지만 바라던 수준에는 한참 못 미쳤다"고 쓴다. 그는 이것이 "우리 자신을 고객과 혼동하는" 실수였다고 본다. 많은 프로덕트 담당자가 고객도 자신처럼 AI를 쓸 거라고 가정하지만, 대부분의 사람과 기업은 도구를 만드는 사람이 아니다.

"AI는 문턱을 바꾸지만 문제 자체를 바꾸지는 않는다." — Benedict Evans (Cagan의 인용)

코드를 쓰는 것도, 도구를 만드는 것도 어려운 부분이 아니며, 어려운 것은 그 도구가 존재해야 한다는 것과 어떤 모습이어야 하는지를 아는 일이고 그건 다른 사람의 몫이라는 게 Evans의 결론이다.

팔복소프트 관점

• 국내에서 이 프레임이 유용한 이유는, PM·PO·서비스 기획자라는 호칭이 뒤섞여 있고 조직마다 실제 하는 일이 다르기 때문이다. Evans의 세 역량으로 자기 직무를 비춰 보면, 국내 "기획" 직무 상당수는 두 번째(해결책 구체화)에 집중되어 있고 첫 번째(문제 정의)와 세 번째(사업성 판단)는 상급자나 사업 부서가 쥐고 있는 경우가 많다. 호칭보다 이 세 가지 중 무엇을 하고 있는지 점검하는 편이 낫다.
• 지금 국내 커뮤니티에는 Cursor나 Claude Code로 비개발자가 사내 도구를 만들었다는 사례가 넘친다. 그런데 몇 달 뒤에도 유지·사용되는 도구는 그중 일부다. 만든 사람이 흥미를 잃어서가 아니라, 처음부터 "존재해야 할 이유"와 "조직에서 굴러갈 형태"가 정의되지 않은 채 만들어졌기 때문이라는 게 이 글의 설명이고, 우리 경험과도 맞다.
• 개발자 입장에서 "AI가 코딩을 대신하니 기획자가 직접 만들고 개발자는 필요 없어진다"는 불안은 절반만 맞다. 이 글의 논리대로라면 코드 작성 자체는 병목이 아니게 되지만, 문제를 정의하고 사업성을 따지는 역량은 여전히 희소하다. 기술 이해도가 높은 개발자가 그 역량까지 갖추면 오히려 가장 유리한 위치에 선다.
• 아쉬운 점도 있다. Evans의 원문이 유료라 Cagan의 인용에 의존해야 하고, "시도해도 성공하기 어렵다"는 주장은 이 글만으로는 근거를 확인할 수 없다. 또 Cagan의 프레임은 PM이 사업성 판단 권한을 가진 실리콘밸리식 조직을 전제한다. SI·수주 구조나 사업 부서가 요구사항을 내려보내는 조직에서는 세 번째 역량을 발휘할 권한 자체가 없어서, 역량 부족과 권한 부재를 구분해서 봐야 한다.
• 특히 B2B SaaS나 사내 플랫폼을 만드는 팀에 던지는 메시지가 명확하다. "고객이 알아서 AI로 커스터마이징할 것"이라는 가정 위에 제품 전략을 세우면 위험하다. 고객사 담당자는 대부분 도구를 만드는 사람이 아니고, 만들어 주는 쪽의 가치는 오히려 커진다.

정리

기억할 것은 하나다. AI가 낮춘 것은 "만드는" 문턱이지 "무엇을 왜 만들어야 하는지 아는" 문턱이 아니다. PM이든 개발자든 자신의 가치를 코드나 화면을 만드는 데 두고 있다면 이 글은 불편할 수 있지만, 문제 정의와 사업성 판단 쪽으로 무게를 옮길 이유이기도 하다. 그리고 고객을 자신처럼 도구를 만드는 사람으로 가정하지 말라는 경고는 지금 AI 기능을 붙이고 있는 모든 팀에 해당한다.

• 프로덕트매니저
• Marty Cagan
• Benedict Evans
• 바이브코딩
• 프로덕트디스커버리