김영욱
23시간 전
1.2K
AI 프로덕트 매니지먼트 특별 연재 ➀
모든 PM은 AI PM이 된다.
김영욱
Product Expert, SAP
2017년 12월, 체스의 세계가 뒤집혔습니다. 딥마인드가 만든 AI 엔진 알파제로가 당시 세계 최강 엔진 스톡피시(Stockfish)와 100판을 두어 28승 72무 0패를 기록했습니다. 한 판도 지지 않았죠. 그런데 진짜 흥미로운 건 숫자 하나입니다. 알파제로는 1초에 8만 개의 수를 계산했고, 스톡피시는 7천만 개를 계산했습니다.
계산량으로만 보면 스톡피시가 압도적이었습니다. 거의 900배 더 열심히 계산한 쪽이 진 겁니다. 알파제로가 바꾼 건 체스의 규칙이 아니었습니다. 왕을 지키고 체크메이트로 끝낸다는 규칙은 하나도 안 바뀌었죠. 바뀐 건 '그 규칙 안에서 어떻게 잘 두는가'였습니다. 수백 년간 정석으로 통하던 수들이, 더 이상 정석이 아니게 된 겁니다.
PM의 세계에도 지금 똑같은 일이 벌어지고 있습니다. 사용자의 문제를 찾고, 무엇을 만들지 정하고, 팀을 이끄는 이런 PM이 하는 일의 규칙은 바뀌지 않았습니다. 그런데 그 게임을 잘 두는 방법이 근본적으로 달라졌습니다. AI를 모르는 PM은, 말하자면 오늘의 스톡피시입니다. 규칙은 알고, 누구보다 열심히 계산하지만, 게임이 달라진 걸 아직 눈치채지 못한 플레이어요.
이 글은 그 '달라진 방식'을 세 가지 차이로 정리합니다. 그전에, 한 가지 오해부터 풀고 가겠습니다.
'AI 프로덕트 매니저'를 검색하면 채용 공고가 쏟아집니다. 구글, 메타, 앤스로픽, 오픈AI까지 어디서나 보이죠. 숫자로 보겠습니다. 2024년 1월부터 2025년 10월까지, 전 세계에서 1만 2,339명이 'AI PM' 타이틀로 채용됐습니다.
여기서 많은 분이 놀라는 숫자가 하나 더 있습니다. 이 채용에서 컴퓨터공학 전공자는 16%뿐이었습니다. 나머지는 디자인·심리학·인문학(34%), 경영·비즈니스(18%) 같은 배경이었죠.
다시 말해, AI PM은 엔지니어의 전유물이 아닙니다. 생각해보면 익숙한 패턴입니다. 모바일이 처음 등장했을 때 '모바일 PM'은 특수한 직함이었습니다. 클라우드도 그랬죠. 그런데 지금 '모바일 PM', '클라우드 PM'이라는 말을 따로 쓰나요? 그냥 PM이 하는 일이 됐습니다. AI PM도 몇 년 안에 그냥 'PM'이 됩니다. 지금의 AI PM은 희귀한 전문가가 아니라, 모든 PM이 향하는 방향입니다.
혹시 지금 여러분이 담당하는 프로덕트에 검색, 추천, 요약, 챗봇 같은 기능이 하나라도 있다면, 여러분은 이미 AI PM의 입구에 서 있는 겁니다.
기존 소프트웨어에는 오래된 약속이 하나 있습니다. 같은 입력에는 항상 같은 출력. 버튼을 누르면 기능이 실행되고, 같은 쿼리에는 같은 결과가 나옵니다. 그래서 버그도 명쾌합니다. 원인을 찾아 고치면, 같은 오류는 두 번 다시 나오지 않습니다. AI는 다릅니다. 같은 질문을 두 번 해도 답이 조금씩 다를 수 있습니다. 이건 고장이 아니라 설계입니다. AI는 규칙을 실행하는 게 아니라, 학습한 패턴에서 '가장 그럴듯한' 답을 확률적으로 만들어내니까요.
이 차이는 PM의 하루를 바꿉니다. 사용자가 "AI가 이상한 답을 했어요"라고 문의합니다. 엔지니어가 재현을 시도합니다. 그런데 같은 상황이 다시 만들어지지 않습니다. 그 사용자의 특정 맥락에서만 벌어진 일이거든요. 코드를 바꾼다고 풀리는 문제가 아닐 수도 있습니다.
"이건 버그입니다" → 재현 → 수정 → 릴리스로 이어지던 그 명확한 품질 관리 사이클이, AI 앞에서는 통째로 흔들립니다. 실제로 매킨지의 2024년 조사에서 기업의 40%가 생성형 AI의 핵심 위험으로 '설명 가능성 부족'을 꼽았지만, 실제로 대응하고 있다는 답은 17%에 그쳤습니다. 알고는 있지만 손을 못 대고 있다는 뜻입니다.
기존 시스템은 틀리면 티가 납니다. 에러를 내거나, 멈추거나, 빈 화면을 보여줍니다.
AI는 다르게 틀립니다. 자신감 있게, 그럴듯하게 틀립니다. 존재하지 않는 논문을 진짜처럼 인용하고, 틀린 숫자를 확신에 차서 말합니다. 이걸 환각이라고 부릅니다. 여기에 더해, 개발 환경에서는 멀쩡하다가 실제 사용자 앞에서만 무너지는 취약성, 그리고 비용 폭발까지 기존 PM이 겪어본 적 없는 실패들이 줄줄이 등장합니다.
비용 이야기는 특히 뼈아픕니다. 한 스타트업이 AI 고객 지원 챗봇을 냈습니다. 베타 반응도 좋았고, 사용자도 빠르게 늘었죠. 그런데 다음 달 청구서를 받고 팀 전체가 얼어붙었습니다. 예상 서버 비용의 20배가 찍혀 있었거든요. 사용자가 는 게 문제가 아니었습니다. 사용자들이 긴 대화를 나누며 컨텍스트가 쌓였고, 복잡한 요청이 에이전트 루프를 여러 번 돌았고, 시스템 프롬프트가 생각보다 길었던 겁니다. 이 모든 게 토큰으로 환산돼 비용이 됐습니다. AI 프로덕트에서는 '사용자 수'가 아니라 '사용자당 토큰 소비 패턴'이 비용을 결정합니다.
그래서 AI PM이 던지는 질문 자체가 달라집니다. 예전에는 "이 기능, 얼마나 정확하게 동작하나요?"라고 물었습니다. 이제는 이렇게 묻습니다. "이 기능에서 AI가 틀렸을 때, 사용자 피해는 어느 정도인가요? 검증 단계가 필요한가요, 아니면 사용자가 직접 확인하는 구조면 충분한가요?" 정확도를 100%로 수렴시키는 게 목표였던 세계에서, 완벽한 정확도란 애초에 존재하지 않는 세계로 넘어온 겁니다.
지금 PM은 하루를 어떻게 보내고 있을까요? 피드백 분류, 문서 작성, 회의 정리, 데이터 뽑아 보고서 만들기. 한 분석에 따르면 PM은 평균적으로 시간의 약 30%를 데이터 수집에, 20%를 문서 작업에 씁니다. 그런데 이 비중이 2030년까지 각각 5% 수준으로 줄어들 거라고 합니다. AI가 피드백을 요약하고, PRD 초안을 쓰고, 리포트를 자동으로 만들어주니까요.
그럼 그 빈 시간은 어디로 갈까요? 전략적 사고, 이해관계자 조율, 그리고 AI 시스템 오케스트레이션으로 갑니다. 한마디로 PM의 무게 중심이 '실행'에서 '판단과 방향 설정'으로 옮겨갑니다. 좋은 소식입니다. 원래 PM이 잘해야 하는 게 바로 그거였으니까요. 동시에 경고이기도 합니다. 반복 업무만 잘하던 PM에게는 역할이 줄어든다는 신호거든요.
기존 PM이 '무엇을 만들 것인가'를 정하는 사람이었다면, AI PM은 여기에 하나를 더 책임집니다. '이 시스템이 어떻게 동작하고, 어떻게 틀리며, 그 오류를 어떻게 설계할 것인가'까지요.
오해는 마세요. PM의 본질은 그대로입니다. 여러 이해관계자를 하나의 방향으로 맞추는 일, 즉 정렬(alignment)은 여전히 PM만이 할 수 있는 일입니다. 오히려 기술이 복잡해질수록 "왜 만드는가"가 흔들리면 프로덕트 전체가 흔들립니다. 본질은 그대로, 체스를 잘 두는 방법만 달라진 겁니다.
솔직한 이야기를 하나 하겠습니다. 이 세 가지 차이 앞에서 가장 크게 흔들리는 건 오히려 경력이 오래된 시니어 PM입니다.
결정론에 익숙했던 사고를 확률론으로 옮기는 일은, 업무 경력이 길수록 더 어렵습니다. 지난 10년, 20년간 몸에 밴 직관이 어떤 지점에서는 오히려 방해가 되거든요. 그래서 요즘 저는 시니어 PM들에게서 같은 고백을 자주 듣습니다. "AI 앞에서만큼은, 나도 다시 초보가 된 기분이다." 그리고 이 말이 이상하게 위안이 됩니다. 그게 나만 겪는 일이 아니라는 뜻이니까요.
지금 AI 앞에서 초보가 된 기분이 든다면, 그건 뒤처진 게 아니라 정확한 자리에 서 있는 겁니다. 그리고 여기서부터가 중요합니다. 이건 커리어의 위기가 아니라 격차의 기회입니다. 지금 벌어지는 격차는 실행 속도가 아니라 '문제를 정의하고 방향을 제시하는 역량'에서 나옵니다. 그리고 그건 정확히, 좋은 PM이 원래 잘하던 일입니다. AI를 경쟁 상대로 볼 필요도 없습니다. 망치가 좋아졌다고 목수를 걱정하지는 않죠. 목수가 더 좋은 망치를 쓸 줄 알아야 한다고 말할 뿐입니다. AI는 여러분의 경쟁자가 아니라, 여러분이 다루는 재료입니다.
거창한 계획은 필요 없습니다. 이번 주에 시작할 수 있는 것부터 가볍게 해보세요.
이번 주 PRD 초안이나 사용자 인터뷰 요약 하나를 AI로 써보세요. 출력이 마음에 안 들어도 괜찮습니다. 오히려 어디서, 어떻게 틀리는지를 관찰하는 게 목적입니다. AI 리터러시는 읽어서 생기지 않고, 써봐야 생깁니다.
지금 맡은 프로덕트에서 AI 기능 하나를 골라, "이게 틀렸을 때 사용자 피해는 어느 정도인가?"를 딱 한 줄로 적어보세요. 이 한 줄이 AI 프로덕트 설계의 출발점입니다.
분기에 한 번, 스스로에게 물어보세요. "지난 3개월 동안 나는 AI에 대해 무엇을 새로 배웠는가?" 배움을 커리어의 일부로 설계하는 습관, 그 자체가 AI 시대의 경쟁력입니다.
다시 체스로 돌아가 볼까요. 알파제로 이후에도 체스의 규칙은 하나도 바뀌지 않았습니다. 킹을 지키고, 체크메이트로 끝냅니다. 바뀐 건 잘 두는 방법뿐이었죠. PM도 마찬가지입니다. 사용자의 문제를 발견하고, 우선순위를 정하고, 팀을 이끌어 좋은 프로덕트를 만드는 일, 그 규칙은 그대로입니다. 우리는 그저, 새로운 방식으로 잘 두는 법을 배우면 됩니다. 그리고 그 방식은 결국, 여러분이 원래 좋아하던 문제를 찾고, 실험하고, 만들어보는 일과 크게 다르지 않습니다.
AI를 모르는 PM은 오늘의 스톡피시입니다. 하지만 스톡피시는, 마음만 먹으면 언제든 새로운 게임을 배울 수 있습니다.
위 콘텐츠는 『AI 프로덕트 매니지먼트』김영욱 저자가 작성한 특별 기고문입니다.
『프로덕트 매니지먼트』로 PM의 성장 가이드를 제시한 김영욱 저자가 이번에는 AI 시대에 맞춰 PM의 역할과 책임을 다시 정의합니다. 책은 소프트웨어와 AI 시스템이 근본적으로 어떻게 다르게 작동하는지에서 출발해 AI 프로덕트에서 발생하는 새로운 실패를 설계 단계부터 어떻게 다뤄야 하는지, 그 판단이 PRD와 지표, 팀의 협업 방식을 어떻게 바꾸는지 짚습니다.
더 나아가 AI PRD와 평가 플랜 작성, 하네스 설계, AI 지표와 모니터링, 머신러닝 엔지니어와의 협업까지. 아이디어를 실제 프로덕트로 만들고 운영하는 전 과정을 한 권에 담았습니다. 과거의 PM이 '어떤 기능을 만들 것인가'를 결정했다면, AI 시대의 PM은 '시스템이 어떻게 동작하고, 틀리며, 오류를 어떻게 설계할 것인가'까지 책임져야 합니다. AI를 ‘프로덕트’로 만드는 방법이 필요한 모든 분께 추천합니다.
0
4 
댓글