저는 약 10년 동안 Product Manager로 일했고, 지난 3년은 스타트업 창업가로 제품과 사업을 함께 만들고 있습니다. 두 역할의 경계는 생각보다 선명하지 않았습니다. PM일 때도 고객과 매출을 신경 써야 했고, 창업가가 된 뒤에도 결국 매일 하는 일은 문제를 정의하고 우선순위를 정하고 팀과 제품을 앞으로 움직이는 일이었습니다.
그런데 지난 1년 사이 일하는 방식은 이전 10년보다 더 크게 바뀌었습니다. 예전에는 아이디어가 떠올라도 개발 리소스를 확보하고, 디자이너와 화면을 만들고, 요구사항을 문서화하고, 예외 조건을 조율한 뒤에야 무엇이 실제로 가능한지 볼 수 있었습니다. 지금은 AI와 몇 번 대화하면 시장 조사 초안, 요구사항, 데이터 구조, 화면, 작동하는 프로토타입까지 하루 안에 나옵니다.
무엇보다 달라진 것은 속도보다 대기 시간이 사라졌다는 점입니다. 저는 더 이상 생각을 확인하기 위해 누군가의 다음 스프린트를 기다릴 필요가 없습니다. 모호한 아이디어를 바로 화면으로 만들고, 가짜 데이터를 넣고, 고객 앞에서 반응을 볼 수 있습니다. 직접 운영하는 서비스에서는 작은 기능과 자동화 정도라면 실제 사용자에게 전달하는 데까지 걸리는 시간도 극적으로 짧아졌습니다.
이 변화는 PM에게 분명한 기회입니다. 문제를 말로만 설명하던 사람이 이제는 작동하는 것으로 설명할 수 있습니다. 개발자에게 가능 여부를 묻기 전에 스스로 여러 옵션을 탐색할 수 있습니다. 고객 인터뷰가 끝난 오후에, 그 대화에서 나온 가설을 반영한 프로토타입으로 다음 인터뷰를 진행할 수도 있습니다.
하지만 여기에는 불편한 역설이 있습니다. 누구나 더 많이 만들 수 있게 되면, 잘 만드는 것만으로는 예전만큼 엣지를 살리기가 어렵습니다. 시장에는 더 많은 제품이 나오고, 기존 회사도 더 많은 기능을 더 자주 내놓습니다. 고객이 원하는 도구를 찾지 못하면 직접 간단한 도구를 만들거나, 범용 AI에 자신의 업무 방식을 설명해 임시 해결책을 만들 수도 있습니다.
그래서 저는 AI 시대의 PM을 이야기할 때 “PM도 코딩해야 한다”는 결론부터 꺼내고 싶지 않습니다. 그보다 먼저 물어야 할 질문이 있습니다.
제품을 만드는 일이 싸지고 빨라졌다면, 이제 무엇이 비싸고 느리고 어려운가?
제 답은 고객의 선택을 얻는 일입니다. 더 정확히 말하면, 어떤 문제에 회사의 시간을 걸어야 하는지 판단하고, 고객이 실제로 행동을 바꾸거나 돈을 낼 만큼 중요한 문제인지 증명하며, 그 증거를 제품과 사업의 반복 가능한 구조로 만드는 일입니다. (더 치밀해지는 것)
이 글은 PM의 종말에 관한 글이 아닙니다. 오히려 PM이 제품 제작의 관리자를 넘어, 문제에서 사업 성과까지 이어지는 루프를 소유해야 한다는 이야기입니다. 저는 그 역할을 Business Owner라고 부르려고 합니다.
만드는 능력이 희소했던 시대
먼저 과거의 PM이 왜 지금과 같은 방식으로 일하게 되었는지 생각해볼 필요가 있습니다. 오랫동안 소프트웨어 개발은 비싸고 느리고 복잡했습니다. 한 번 잘못 만들면 몇 달의 개발비와 조직의 신뢰가 함께 사라졌습니다. 그러니 무엇을 만들지 미리 정교하게 합의하고, 요구사항을 누락 없이 전달하고, 여러 직군의 일정을 맞추는 능력이 중요할 수밖에 없었습니다.
좋은 PM은 복잡한 문제를 구조화했습니다. 고객이 제각각 표현한 요구를 공통 문제로 묶고, 디자이너와 개발자가 판단할 수 있는 언어로 바꾸고, 비즈니스 목표와 기술 제약 사이에서 우선순위를 정했습니다. PRD와 로드맵은 단순 문서가 아니라 비싼 제작 자원을 올바른 곳에 배분하기 위한 장치였습니다.
그 과정에는 많은 암묵지가 필요했습니다. 어디까지 구체적으로 써야 개발자의 자율성을 해치지 않는지, 어떤 예외 조건은 지금 처리하고 어떤 것은 나중으로 미뤄야 하는지, 이해관계자가 말하는 “급하다”가 실제 고객 가치와 같은 뜻인지 구분해야 했습니다. 시니어 PM이 가진 경험이 가치 있었던 이유입니다.
지금도 이 능력은 사라지지 않았습니다. 복잡한 결제, 권한, 보안, 정산, 의료, 금융, 대규모 플랫폼을 실제로 운영해 본 사람의 판단을 프롬프트 몇 줄이 대체하지는 못합니다. AI가 그럴듯한 예외 조건 목록을 빠르게 만들 수는 있어도, 어떤 장애가 회사의 존립을 위협하는지까지 책임지고 결정하지는 않습니다.
다만 희소성의 위치가 달라지고 있습니다. 예전에는 잘 정리된 요구사항 자체가 높은 가치였습니다. 이제 AI는 방대한 맥락을 읽고, 모순을 찾고, 사용자 흐름과 수용 기준을 만들고, 빠진 예외를 질문합니다. 경험이 많은 PM이 AI를 쓰면 과거보다 훨씬 크고 무거운 문제를 다룰 수 있습니다. 이것은 시니어의 힘을 없애기보다 증폭합니다.
문제는 조직이 그 증폭된 능력을 어디에 쓰느냐입니다. 같은 수의 사람이 예전보다 두 배 많은 기능을 관리하는 데만 쓴다면 생산량은 늘어도 사업은 달라지지 않을 수 있습니다. 더 완벽한 문서, 더 많은 티켓, 더 빠른 릴리스가 고객의 행동을 바꾸지 않으면 그것은 효율적인 실패일 뿐입니다.
과거 PM의 대표 질문이 “이 복잡한 제품을 어떻게 제대로 만들 것인가?”였다면, AI 시대에는 그보다 앞선 질문의 가격이 올라갑니다.
이 문제는 정말 회사가 풀어야 할 문제인가? 그리고 고객은 해결됐다는 사실을 어떤 행동으로 증명할 것인가?
AI가 싸게 만든 것은 제품이 아니라 산출물이다
AI가 소프트웨어 제작 비용을 낮추고 있다는 신호는 이미 충분합니다.
Anthropic의 2025년 분석은 50만 건의 코딩 관련 상호작용에서 Claude Code 대화의 79%를 사람이 AI에게 작업 수행을 맡기는 자동화 형태로 분류했습니다. UI와 사용자 대면 앱 개발이 주요 사용처였고, 초기 사용은 엔터프라이즈보다 스타트업 관련 작업에 더 많이 나타났습니다. 우리가 눈으로 확인하기 쉬운 프로토타입과 웹 화면부터 제작비가 빠르게 내려가고 있다는 뜻입니다.
비개발자도 이전보다 훨씬 더 가용 캐파가 늘어났습니다. Replit은 2026년 사례에서 디자이너·마케터 배경의 SaaS 경력자가 Agent를 이용해 iOS 앱을 만들고 앱스토어에 출시한 과정을 소개했습니다. 초기 다운로드는 300건에 못 미쳤습니다. 이 숫자가 오히려 중요합니다. 앱을 출시했다는 사실과 시장을 얻었다는 사실 사이에는 큰 거리가 남아 있기 때문입니다.
AI의 가치는 “코딩”이라는 한 단어로 결정되지 않습니다. 과제가 작고 정답을 확인하기 쉽고 맥락이 짧을수록 AI가 유리합니다. 반대로 오래된 코드베이스의 숨은 규칙, 높은 품질 기준, 긴 디버깅 루프가 필요한 일에서는 생성 속도보다 검토와 수정 비용이 커질 수 있습니다.
또한 AI는 문서, 화면, 코드, 분석과 같은 산출물의 한계비용을 빠르게 낮춥니다. 그러나 고객이 왜 움직이지 않는지 알아내는 일, 조직 안의 이해관계를 바꾸는 일, 실제 운영 환경에서 품질을 보증하는 일, 유료로 반복되는 수요를 만드는 일의 비용이 같은 속도로 내려가는 것은 아닙니다.
이 구분을 하지 않으면 프로토타입을 제품으로 착각하고, 출시를 검증으로 착각하게 됩니다. 화면이 완성돼 보일수록 조직은 “이미 거의 다 만들었다”고 느끼기 쉽습니다. 하지만 사용자가 다시 돌아올 이유, 데이터의 신뢰성, 장애 대응, 권한과 보안, 운영 비용, 구매 의사결정은 데모 화면 밖에 있습니다.
AI 시대의 위험은 느리게 잘못 만드는 것이 아닙니다. 틀린 문제를 매우 설득력 있게, 매우 빠르게 만드는 것입니다.
제품이 넘치면 무엇이 희소해지는가
제품을 만들기 쉬워지면 시장에는 당연히 더 많은 제품이 나옵니다. 한 회사가 내놓는 기능의 수도 늘고, 작은 팀이 도전할 수 있는 시장도 넓어집니다. 예전에는 개발비 때문에 포기했던 사내 도구, 특정 직군만을 위한 버티컬 소프트웨어, 한 고객의 복잡한 흐름을 위한 맞춤 앱도 경제성이 생깁니다.
이것은 “소프트웨어의 가치가 사라진다”는 뜻이 아닙니다. 오히려 소프트웨어가 닿을 수 있는 문제의 총량은 커질 가능성이 높습니다. 다만 고객에게 보이는 선택지가 늘고, 비슷한 기능을 가진 제품이 더 빨리 따라붙으며, 얇은 기능만으로 가격을 지키기는 어려워집니다.
제품이 넘치는 시장에서 고객이 사는 것은 기능 목록이 아닙니다. 실패해도 책임질 회사라는 신뢰, 우리 조직의 복잡한 흐름을 이해한다는 확신, 기존 데이터와 사람을 안전하게 옮길 수 있다는 보장, 문제가 생겼을 때 같이 해결할 관계를 삽니다.
유통은 점점 더 어려워집니다. 좋은 제품을 올려두면 알아서 발견되던 시대가 아니라는 점을 많은 팀이 체감하고 있습니다.
고객의 검색 결과에는 이미 수십 개의 대안이 있습니다. SaaS를 사지 않아도 스프레드시트, 노코드, 범용 AI, 사내 자동화로 상당 부분을 해결할 수 있습니다. 특히 B2B에서는 “아무것도 사지 않고 지금 방식으로 버틴다”가 여전히 가장 강한 경쟁자입니다. 특히 B2C에서는 설치보다 삭제가 쉽고, 첫 호기심보다 두 번째 방문을 만들기가 어렵습니다.
따라서 AI 시대의 PM은 경쟁 제품만 분석해서는 부족합니다. 고객이 문제를 견디는 방식, 사람을 더 투입하는 방식, 엑셀로 우회하는 방식, 범용 AI로 임시 해결하는 방식까지 모두 대안으로 봐야 합니다. 제품의 진짜 경쟁력은 기능 우위가 아니라 기존 대안을 버릴 만큼 전환의 명분을 만드는 것에서 나옵니다.
이때 PM의 가치도 이동합니다. 기능을 더 정확히 전달하는 사람보다, 어떤 고객의 어떤 순간에 들어가야 하는지 고르는 사람, 제품과 유통을 하나의 설계 문제로 보는 사람, 고객의 거절을 다음 제품 결정으로 번역하는 사람이 더 희소해집니다.
문제 정의는 인터뷰 요약이 아니다
PM은 원래 문제를 정의하는 직업이라고 말해 왔습니다. 그런데 현실의 많은 문제 정의는 인터뷰 내용을 예쁘게 정리하는 수준에 머뭅니다. “사용자가 불편해한다”, “시간이 오래 걸린다”, “통합된 화면이 필요하다” 같은 문장은 출발점이지, 투자할 만한 문제의 증거는 아닙니다.
AI는 이런 정리를 아주 잘합니다. 인터뷰 전사 몇 개를 넣으면 공통 테마, 페르소나, JTBD, 기회 영역, 추천 기능까지 그럴듯하게 제시합니다. 그래서 이제 요약 능력 자체로는 차이를 만들기 어렵습니다. PM은 AI가 만든 패턴을 고객의 실제 행동과 사업의 제약 속에서 다시 검증해야 합니다.
제가 문제를 볼 때는 최소 네 층을 보고 판단하려고 합니다.
• 불편의 층: 사용자가 짜증 나거나 시간이 걸린다고 말하는가.
• 행동의 층: 그 불편 때문에 이미 사람, 도구, 우회 절차를 투입하고 있는가.
• 경제의 층: 해결되지 않을 때 매출, 비용, 위험, 기회비용이 얼마나 생기는가.
• 결정의 층: 누가 예산과 우선순위를 움직일 수 있으며, 지금 바꿀 이유가 있는가.
“매주 보고서를 만드는 데 세 시간이 걸려요”는 불편입니다. 팀원 다섯 명이 서로 다른 파일을 맞추느라 매주 총 이틀을 쓰고, 숫자 오류로 월말 의사결정이 늦어지고, 재무 책임자가 이번 분기 안에 해결 예산을 잡았다는 데까지 가면 사업 문제에 가까워집니다. 같은 기능이라도 어느 층에서 문제를 정의하느냐에 따라 가격, 구매자, 제품 범위, 세일즈 메시지가 모두 달라집니다.
여기서 “뾰족하다”는 것은 시장을 작게 쓰는 일이 아닙니다. 고객, 순간, 손실, 기존 대안, 구매 조건이 서로 맞물려 있는 상태입니다. (입체적으로 이해하는 것) “중소기업을 위한 AI 업무 도구”는 좁지도 넓지도 않습니다. 그냥 흐립니다. 반면 “월말마다 20개 지점의 매출 파일을 사람이 병합하느라 결산이 이틀 늦어지는 외식 프랜차이즈 재무팀”은 작아 보이지만, 누구에게 무엇을 제안하고 어떤 결과를 측정할지 바로 보입니다.
문제 정의가 뾰족하면 AI가 훨씬 유용해집니다. 입력 데이터와 예외 조건을 구체화할 수 있고, 프로토타입이 검증해야 할 질문도 선명해집니다. 반대로 문제가 흐리면 AI는 평균적인 제품을 빠르게 만들어 줍니다. 보기에는 완성도가 높지만 누구의 기존 행동도 바꾸지 못하는 제품입니다.
AI를 통해 우리는 고객에게 더 자주, 더 구체적인 것을 보여주고 더 빨리 틀릴 수 있습니다.
만드는 시간이 하루로 줄었다면 남은 시간을 기능 두 개를 더 만드는 데 쓰는 대신, 고객 다섯 명에게 거절당하는 데 써야 합니다.
좋은 문제 정의는 고객이 한 말을 정리한 문장이 아니라, 고객이 이미 치르고 있는 비용과 바꿀 준비가 된 행동을 설명하는 문장입니다.
실리콘밸리에서는 이미 역할의 경계가 움직이고 있다
해외에서도 비슷한 변화가 있느냐고 묻는다면, 제 답은 “그렇다. 다만 하나의 정답으로 수렴하고 있지는 않다”입니다. PM이 모두 사라지거나 하나의 새로운 직무명으로 통합되는 것이 아니라, 제품과 고객, 기술과 유통 사이의 경계가 여러 방향에서 동시에 흐려지고 있습니다.
가장 많이 회자된 사례는 Airbnb입니다. Brian Chesky는 2023년 Lenny's Podcast에서 전통적 PM의 인바운드 제품 개발 책임과 Product Marketing의 아웃바운드 책임을 합쳤다고 설명했습니다. 프로그램 관리 업무는 실제 Program Manager에게 옮기고, 그룹은 더 작고 시니어하게 만들었다고 했습니다.
이 사례를 “Airbnb가 PM을 없앴다”로 요약하면 핵심을 놓칩니다. 그들이 없애려 한 것은 사람이 아니라, 시장과 제품을 분리하고 조율 업무가 제품 판단을 대체하는 방식에 가까웠습니다.
동시에 Airbnb의 강한 창업자 중심 운영이 모든 조직에서 확장 가능하다는 증거도 없습니다. 실제 PM 커뮤니티에서는 중앙집중과 병목에 대한 비판도 적지 않았습니다. 그래서 이 사례는 정답이 아니라 역할의 무게중심이 이동한다는 신호로 보는 편이 정확합니다.
Siena의 Forward Deployed PM은 한 걸음 더 나갑니다. 전략 고객의 배포 성과를 엔드투엔드로 소유하고, 자동화율과 해결률, time-to-value를 관리하며, 직접 데모하고 영업과 공동 판매를 요구합니다. 고객별 배포에서 발견한 빈틈을 공통 플랫폼 기능으로 바꾸는 것이 핵심 루프입니다.
이런 사례 만으로 “미국 PM 시장이 모두 바뀌었다”고 말할 수는 없습니다. 그러나 새로운 역할의 원형은 분명히 보입니다.
• 고객의 업무 안으로 들어간다.
• 직접 프로토타입을 만들어 학습한다.
• 출시가 아니라 고객 성과를 소유한다.
• 고객별 학습을 반복 가능한 제품으로 바꾼다.
• 필요하면 직접 데모하고 공동 판매한다.
중요한 한계점도 있습니다. 2026년 r/ProductManagement에서 “PM이 AI로 만든 코드를 프로덕션에 직접 넣어야 하는가”를 토론했을 때, 명확한 입장을 낸 약 62명 중 33명은 반대, 20명은 조건부 찬성, 9명은 프로토타입은 좋지만 운영 코드는 아니라는 중간 입장이었습니다. 이는 검토 병목과 장애 책임이 현장에서 실제 쟁점이라는 점을 보여주고 있습니다.
결론은 PM이 엔지니어가 되어야 한다는 것이 아니라 PM이 무엇을 직접 만들어야 학습이 빨라지는지, 어디부터는 전문 직군의 품질 책임이 필요한지 판단해야 한다는 것입니다. 이 경계를 모르면 AI는 협업을 줄이는 도구가 아니라 리뷰 부담을 다른 사람에게 떠넘기는 도구가 됩니다.
Product Owner에서 Business Owner로
제가 말하는 Business Owner는 직급이나 조직도의 이름이 아닙니다. PM에게 디자인, 개발, 데이터, 마케팅, 영업을 전부 혼자 하라는 말도 아닙니다. 그런 만능형 역할은 오래 지속되기 어렵고, 복잡한 제품에서는 위험합니다.
Business Owner는 문제 발견에서 사업 결과까지 이어지는 학습 루프에 끊김이 없도록 책임지는 사람입니다. 각 단계의 실무를 모두 직접 수행하지는 않더라도, 다음 단계로 넘어가기 위해 어떤 증거가 필요한지 알고 그 증거를 얻는 일의 주인이 됩니다.
Product Owner가 백로그와 전달 품질에만 갇히면 성공은 “계획한 기능을 일정에 맞춰 출시했다”가 됩니다. Business Owner의 성공은 “특정 고객의 중요한 문제가 해결됐고, 그 결과가 사용, 지불, 유지, 확장 또는 비용 절감으로 반복됐다”입니다. 전자는 산출물을 소유하고, 후자는 결과로 이어지는 시스템을 소유합니다.
이 차이는 기능을 고르는 순간부터 나타납니다. Product Owner는 가장 많은 고객이 요청한 기능을 우선할 수 있습니다. Business Owner는 그 요청이 어떤 행동과 경제적 결과를 바꾸는지 묻습니다. 누구의 이탈을 막는가, 어떤 거래를 닫는가, 고객의 운영비를 얼마나 줄이는가, 도입을 가로막는 위험을 없애는가, 그리고 그 가치가 가격에 반영될 수 있는가를 봅니다. (내가 맡은 퍼널이 아닌 전체 비즈니스를 바라보는 관점에서)
B2B PM에게는 비교적 문자 그대로의 판매가 중요해집니다. 고객 미팅에 동석하는 수준을 넘어, 문제를 다시 정의하고, 결과와 범위가 담긴 제안을 만들고, 유료 파일럿이나 LOI, 데이터 제공, 담당자 배정 같은 약속을 얻어야 합니다. 고객이 칭찬했는지가 아니라 회사의 시간이나 예산을 실제로 움직였는지가 증거입니다.
B2C PM이 모든 사용자에게 전화해 물건을 팔 수는 없습니다. 이때 판매는 유통과 행동 설계의 형태를 띱니다. 어떤 채널에서 어떤 약속으로 사용자를 데려오는지, 첫 가치 경험까지 얼마나 빨리 가는지, 두 번째 주에 왜 돌아오는지, 무료 행동이 유료 가치로 어떻게 이어지는지 책임져야 합니다. 설치 수보다 활성화와 리텐션, 추천, 수익화가 더 가까운 사업 증거입니다.
Business Owner에게 가장 중요한 변화는 판매 기술 그 자체보다 제품 판단에 상업적 증거를 넣는 것입니다. 가격, 패키징, 유통, 세일즈, 온보딩, 고객 성공을 출시 이후 다른 팀이 처리할 일로 미루지 않습니다. 제품을 만들기 전에 그 조건이 제품 구조에 어떤 영향을 주는지 함께 설계합니다.
예를 들어 엔터프라이즈 고객이 높은 정확도보다 승인 이력과 책임 추적을 더 중요하게 여긴다면, 감사 로그는 부가 기능이 아니라 구매 조건입니다. 셀프서브 고객이 설치 전에 신용카드를 요구받는 순간 이탈한다면, 결제 흐름은 마케팅 문제가 아니라 제품 전략입니다. 고객마다 맞춤 설정이 길어져 매출총이익이 무너진다면, 설정 자동화와 표준화는 운영 개선이 아니라 비즈니스 모델의 핵심입니다.
이 관점에서 PM의 로드맵은 기능 목록이 아니라 사업 가설의 포트폴리오가 됩니다. 각 항목은 누구의 어떤 행동을 바꾸고, 그 결과가 어느 지표와 경제성으로 이어지며, 틀렸을 때 무엇을 배우는지 설명할 수 있어야 합니다.
Business Owner는 모든 일을 혼자 하는 사람이 아니라, 문제에서 사업 성과까지 학습이 끊기지 않게 만드는 사람이다.
AI 시대 PM의 새로운 운영 루프
그렇다면 실제로 어떻게 일해야 할까요. 저는 AI 시대의 PM이 다음 여섯 단계를 더 짧고 자주 반복해야 한다고 생각합니다.
고객이 이미 비용을 치르는 좁은 문제를 찾는다
사람들이 “있으면 좋겠다”고 말하는 문제보다, 지금 사람·시간·도구로 비용을 지불하는 문제를 찾습니다. 고객의 하루에서 문제가 발생하는 정확한 순간, 현재 대안, 실패의 결과, 결정권자를 적습니다. AI는 인터뷰를 요약하고 패턴을 제안할 수 있지만, 현장 맥락과 우선순위는 직접 확인합니다.
좋은 질문은 “어떤 기능이 필요하세요?”가 아닙니다. “마지막으로 이 문제 때문에 일이 꼬인 날이 언제였나요?”, “그날 누가 몇 시간을 썼나요?”, “지금은 무엇으로 막고 있나요?”, “이번 분기에 해결하지 않으면 무엇이 생기나요?” 같은 질문입니다. 의견보다 최근의 실제 행동을 묻습니다.
기능이 아니라 결과와 조건이 담긴 제안을 만든다
문제 정의가 끝나면 곧바로 기능 목록으로 가지 않습니다. “우리는 무엇을 만들어 드리겠다”보다 “어떤 결과를 어떤 조건 안에서 만들겠다”를 제안합니다. 대상 고객, 바뀔 업무, 기대 결과, 필요한 데이터와 협조, 제한 범위, 검증 기간을 함께 씁니다.
이 제안은 제품 콘셉트인 동시에 작은 거래입니다. 고객이 결과에는 관심 있지만 필요한 데이터 제공이나 현업 참여를 거부한다면, 실제 우선순위가 낮거나 제안의 신뢰가 부족하다는 신호입니다. 제품을 다 만든 뒤 알기에는 너무 비싼 정보입니다.
완성품 전에 commitment를 얻는다
“좋네요”는 약한 신호입니다. 다음 미팅을 잡는 것, 실제 데이터를 주는 것, 현업 담당자를 붙이는 것, 파일럿 계약을 검토하는 것, 보증금을 내는 것, 유료 전환 조건에 합의하는 것처럼 고객이 무언가를 포기해야 하는 신호가 더 강합니다.
모든 시장에서 선결제가 가능한 것은 아닙니다. 그렇다고 아무 약속도 받을 수 없는 것은 아닙니다. B2C라면 알림 허용, 데이터 연결, 친구 초대, 두 번째 사용, 유료 대기 목록처럼 점진적인 행동을 볼 수 있습니다. 내부 제품이라면 기존 절차를 중단하고 새 흐름으로 실제 업무를 해보겠다는 약속이 될 수 있습니다.
AI 프로토타입을 가설을 깨는 장치로 쓴다
프로토타입의 목적은 조직을 감탄시키는 데 있지 않습니다. 가장 위험한 가정을 가장 싸게 틀려보는 데 있습니다. 사용자가 흐름을 이해하는지가 위험하면 클릭 가능한 화면이 필요합니다. 데이터로 결과를 만들 수 있는지가 위험하면 백엔드 없는 화면보다 샘플 데이터 실험이 먼저입니다. 구매 의사가 위험하면 완성된 제품보다 가격이 포함된 제안서가 더 좋은 프로토타입일 수 있습니다.
고객별 요청에서 반복되는 구조만 제품으로 승격한다
초기에는 고객 옆에서 수작업으로 문제를 풀어도 됩니다. 오히려 그래야 어떤 예외가 진짜이고 어떤 요구가 한 고객의 습관인지 알 수 있습니다. 하지만 모든 고객의 요청을 코드로 박아 넣으면 서비스가 아니라 맞춤 개발 회사가 됩니다.
Business Owner는 고객별 배포에서 반복되는 원인을 찾습니다. 같은 데이터 누락, 같은 승인 병목, 같은 신뢰 문제, 같은 온보딩 장벽이 여러 고객에게 나타날 때 공통 제품으로 승격합니다. 무엇을 표준화하고 무엇을 서비스로 남길지는 제품성과 수익성을 함께 보고 결정합니다.
출시량이 아니라 사업 증거로 다음 투자를 결정한다
출시는 학습의 시작입니다. B2B라면 유료 파일럿 전환, 실제 사용 팀 수, time-to-value, 갱신, 확장 매출을 봅니다. B2C라면 핵심 행동 완료율, 재방문, 자연 추천, 유료 전환을 봅니다. 내부 제품은 도입률, 처리 시간, 오류, 비용, 지원 요청 변화를 봅니다.
지표는 많을수록 좋은 것이 아닙니다. 이번 가설이 맞다면 가장 먼저 움직여야 할 행동 하나와, 그 행동이 사업 결과로 이어지는지 확인할 지표를 고릅니다. 반응이 없으면 기능을 더 얹기보다 문제, 대상, 제안, 유통 중 어디가 틀렸는지 돌아갑니다.
이 루프에서 AI는 모든 단계의 시간을 줄여줍니다. 인터뷰 준비와 분석, 제안서 변형, 프로토타입, 데이터 탐색, 문서화, 운영 자동화를 돕습니다. 하지만 무엇을 성공으로 볼지와 다음 투자 여부는 사람이 결정합니다. AI에게 일을 위임할 수는 있어도 책임까지 위임할 수는 없습니다.
“만능형 PM”은 현실인가, 업무 전가인가
여기까지 읽으면 PM에게 너무 많은 것을 요구한다고 느낄 수 있습니다. 이미 고객, 전략, 데이터, 디자인, 개발, 이해관계자 관리로 벅찬데 이제 코딩과 영업까지 하라는 말처럼 들립니다. 실제로 AI 도입이 인력 감축과 역할 확대의 명분으로만 쓰이는 조직도 있을 것입니다.
하지만 제가 제안하는 답은 “모든 것을 잘하라”가 아닙니다. (현실적이지도 않고요) 가장 중요한 불확실성을 직접 다룰 수 있을 만큼 경계를 넓히라는 것입니다. 고객 가치가 불확실한 초기에는 PM이 직접 인터뷰하고 프로토타입을 만들어야 할 수 있습니다. 기술 가능성이 핵심이면 엔지니어와 함께 작은 실험을 설계해야 합니다. 구매가 병목이면 영업 현장에 들어가 제안과 반론을 들어야 합니다.
반대로 규제, 보안, 결제, 의료, 금융, 대규모 플랫폼, 고가용성 시스템에서는 깊은 전문성과 명확한 책임 경계가 더 중요합니다. PM이 AI로 코드를 만들 수 있다는 이유로 운영 시스템에 직접 넣는 것이 좋은 판단은 아닙니다. 속도보다 감사 가능성, 재현성, 장애 책임, 데이터 보호가 우선인 구간이 있습니다.
디자이너의 역할도 사라지지 않습니다. PM이 만든 화면은 대화를 구체화하는 커뮤니케이션 프로토타입일 수 있지만, 실제 사용성을 검증하고 일관된 경험을 설계하는 일과는 다릅니다. AI 덕분에 첫 번째가 싸졌다고 두 번째까지 자동으로 해결된 것은 아닙니다. 프로토타입이 너무 그럴듯해져서 그대로 스펙이 되는 순간이 오히려 위험합니다.
좋은 AI 시대의 팀은 경계를 없애지 않습니다. 경계를 학습 속도를 높이는 방향으로 재설계합니다. 누구나 아이디어를 작동하는 형태로 만들 수 있지만, 각 직군은 자신의 전문 영역에서 품질 기준을 지킵니다. PM은 결과를 소유하고, 디자이너는 사용자 경험의 증거를, 엔지니어는 운영 품질과 기술 구조를, 영업과 마케팅은 시장의 반응과 유통을 함께 소유합니다.
Business Owner는 이 모든 전문성을 대체하는 사람이 아니라, 서로 다른 증거가 하나의 사업 판단으로 이어지게 만드는 사람입니다.
시니어 PM의 차이는 어디에서 생기는가
AI가 주니어의 초안을 빠르게 만들고 시니어의 암묵지를 증폭하면, 시니어 PM의 차이는 문서의 완성도에서 덜 드러날 것입니다. 이제 거의 누구나 구조가 좋은 PRD와 보기 좋은 화면을 만들 수 있습니다. 회의록과 경쟁 분석도 일정 수준까지 평준화됩니다.
차이는 다른 곳에서 생깁니다. 고객의 말 뒤에 숨은 조직 정치, 구매자가 감수할 수 없는 위험, 데이터가 왜 존재하지 않는지, 사용자가 현재 대안을 버리지 않는 이유, 단기 매출이 장기 제품성을 해치는 지점을 보는 능력입니다.
또 하나의 차이는 자원 배분의 용기입니다. 제작비가 낮아지면 모든 아이디어를 시험해볼 수 있을 것처럼 보입니다. 하지만 고객의 관심, 팀의 집중력, 운영 복잡성은 여전히 제한돼 있습니다. 무엇을 만들지 결정하는 능력만큼 무엇을 제품으로 키우지 않을지 결정하는 능력이 중요합니다.
시니어 PM은 프로토타입의 완성도에 취하지 않고 증거의 강도를 봅니다. 인터뷰의 칭찬보다 행동을, 방문보다 반복을, 사용량보다 지불 의사를, 한 고객의 강한 요청보다 여러 고객에게 반복되는 원인을 봅니다. 동시에 작은 데이터가 주는 확신을 과대평가하지 않고, 정성 신호와 정량 신호의 빈틈을 압니다.
비즈니스 이해도 재무제표 용어를 외우는 데서 끝나지 않습니다. 가격을 올렸을 때 어떤 고객이 남는지, 커스텀 요구가 매출총이익을 어떻게 바꾸는지, 유통 채널이 제품 경험에 어떤 제약을 주는지, 온보딩 비용이 어느 세그먼트까지 감당 가능한지 제품 결정으로 연결할 수 있어야 합니다.
앞으로 강한 PM은 T자형보다 루프형에 가까울 수 있습니다. 특정 도메인이나 제품 역량에는 깊이가 있고, 그 깊이를 고객 문제, 제작, 유통, 수익, 반복 학습으로 연결합니다. 모든 직군의 전문가가 될 필요는 없지만, 어떤 전문성이 지금 병목인지 알아보고 그 사람과 같은 문제를 볼 수 있어야 합니다.
저는 이것이 PM에게 가혹하지만 현실적인 differentiator라고 생각합니다. 산출물을 관리하는 역할은 AI와 더 강한 실행 직군 사이에서 압박받을 수 있습니다. 반면 문제를 뾰족하게 정의하고, 직접 증거를 만들고, 제품과 시장을 함께 움직이는 PM의 가치는 더 커질 가능성이 높습니다.
다음 월요일부터 바꿀 수 있는 것
Business Owner라는 말을 거창한 직무 전환으로 받아들일 필요는 없습니다. 다음 의사결정에서 증거의 종류를 한 단계 바꾸는 것부터 시작할 수 있습니다.
• 다음 고객 인터뷰에서는 원하는 기능 대신 마지막으로 문제가 발생한 장면과 현재 치르는 비용을 묻습니다.
• 다음 PRD에는 기능 목표뿐 아니라 바뀌어야 할 고객 행동과 사업 결과를 한 줄로 씁니다.
• 다음 프로토타입에는 “무엇을 보여줄까”보다 “어떤 가정을 틀려볼까”를 먼저 적습니다.
• 다음 로드맵 리뷰에서는 출시 예정일 옆에 고객의 commitment와 중단 조건을 둡니다.
• 다음 영업 미팅에는 한 번 직접 들어가 고객이 제품이 아니라 어떤 결과를 진심으로 바이하는지 듣습니다.
• 다음 출시 회고에서는 완료한 범위보다 사용, 지불, 유지, 비용 절감 중 무엇이 바뀌었는지 확인합니다.
AI 사용법도 같은 기준으로 고르면 됩니다. 유행하는 도구를 모두 배우는 대신, 자신의 학습 루프에서 가장 오래 걸리는 한 단계를 찾습니다. 인터뷰 분석이 병목이면 전사와 패턴 추출을 자동화하고, 제안 변형이 병목이면 고객 맥락별 초안을 만들고, 프로토타입 대기가 병목이면 직접 빌드합니다. AI는 역할을 넓히기 위한 목적이 아니라 중요한 증거에 더 빨리 도달하기 위한 수단입니다.
그리고 절약한 시간을 다시 산출물에 모두 쓰지 않는 것이 중요합니다. 문서 작성이 두 시간에서 20분으로 줄었다면, 남은 시간에 문서 아홉 개를 더 만드는 대신 고객을 만나거나 실제 사용 데이터를 파고들어야 합니다. AI가 만든 여유를 어디에 재투자하는지가 PM의 새로운 생산성을 결정합니다. (생산만 하면 안됩니다.)
결국 남는 것은 책임의 범위다
AI는 PM을 없애기보다 PM 업무의 가격표를 다시 붙이고 있습니다. 요구사항 초안, 경쟁사 정리, 화면 시안, 단순 코드, 회의 기록처럼 과거에 많은 시간이 들던 일의 가격은 내려갑니다. 반면 어떤 문제에 베팅할지, 누구의 행동을 바꿀지, 어떤 증거가 충분한지, 어떻게 반복 가능한 사업으로 만들지 결정하는 일의 가격은 올라갑니다.
그래서 “AI 시대에도 PM이 필요한가?”라는 질문은 조금 빗나갔다고 생각합니다. 더 좋은 질문은 이것입니다.
우리 조직의 PM은 산출물을 통과시키는 사람인가, 아니면 고객 문제에서 사업 결과까지 학습을 완결하는 사람인가?
제품을 잘 만드는 능력은 여전히 중요합니다. 다만 이제 그것은 결승점이 아니라 기본 조건에 가까워지고 있습니다. AI 덕분에 더 많은 사람이 더 빨리 만들 수 있다면, PM은 더 뾰족하게 문제를 고르고, 더 일찍 고객의 약속을 얻고, 더 냉정하게 사업의 증거를 확인해야 합니다.
만드는 건 쉬워졌습니다. 그래서 이제 더 잘 팔아야 합니다. 여기서 판다는 것은 고객을 설득해 필요 없는 것을 밀어 넣는 일이 아닙니다. 고객이 이미 겪는 중요한 문제를 정확히 이해하고(입체적으로 이해하고), 해결의 가치를 약속하고, 실제 결과로 그 약속을 지키는 일입니다.
만드는 일이 쉬워졌기 때문에 만드는 능력이 무의미해진 것이 아닙니다. 무엇을 왜 만들고, 누가 실제로 값을 치를지를 증명하는 능력의 가격이 더 올라갔습니다.
참고한 자료
• Y Combinator, Vibe Coding Is The Future, 2025
• Anthropic Economic Index, AI's impact on software development, 2025
