AI PM의 정체성: 기능 정의자에서 확률적 시스템 설계자로
전통적인 PM의 선형적 로드맵을 넘어, 불확실성과 데이터 피드백 루프를 관리하는 AI PM의 핵심 역량 분석
예전에 함께 일했던 어느 팀의 PM분은 정말 꼼꼼하셨어요. 18개월 치 로드맵을 엑셀에 분 단위로 쪼개서 설계하실 정도였죠. 그런데 AI 제품을 만들기 시작하면서 그 정교한 계획표가 완전히 무너지는 걸 옆에서 지켜봤습니다. AI 제품은 고정된 스펙대로 움직이는 게 아니라, 어떤 데이터가 들어오느냐에 따라 스스로 진화하고 때로는 예상치 못한 방향으로 튀어버리거든요 [1].
결국 AI PM은 단순히 AI 도구를 잘 쓰는 PM이 아닙니다. ‘A를 입력하면 반드시 B가 나온다’는 결정론적인 소프트웨어 사고방식을 과감히 버려야 해요. 대신 확률적인 결과물(Probabilistic Outputs)을 인정하고, 제품이 계속해서 학습할 수 있는 ‘시스템’ 자체를 설계하는 새로운 지표의 관리자가 되어야 합니다.
AI PM과 전통적 PM: 도구의 차이가 아닌 패러다임의 차이
가장 먼저 짚고 넘어갈 점이 있어요. 많은 분이 “나 챗GPT로 PRD 쓰니까 이제 AI PM이야”라고 생각하시는데, 이건 엄밀히 말하면 ‘AI-Enabled PM(AI 활용자)’에 가깝습니다. 단순히 효율성을 위해 도구를 쓰는 것과, 제품의 핵심 엔진으로 AI를 설계하는 ‘AI PM’은 완전히 다른 이야기거든요 [4].
전통적인 PM은 ‘기능(Feature)’을 정의합니다. “사용자가 이 버튼을 누르면 이런 화면이 나와야 해”라고 결정론적인 워크플로우를 짜죠. 반면 AI PM은 ‘결과(Outcome)’에 집중합니다. AI는 매번 똑같은 답을 내놓지 않기 때문에, “이 기능이 구현되었는가”보다 “사용자가 원하는 결과에 얼마나 근접했는가”를 측정하는 게 훨씬 중요합니다 [2].
개발 경로도 완전히 달라집니다. 기존에는 기획 → 개발 → 테스트 → 배포라는 선형적인 경로를 탔다면, AI 제품은 데이터를 통해 모델을 정제하는 반복적(Iterative) 과정의 연속입니다. 여기서 아주 중요한 통찰 하나 공유할게요.
“The PM who ships the most features loses. The PM who builds the best learning system wins.” [1]
(기능을 가장 많이 출시하는 PM이 지는 것이고, 최고의 학습 시스템을 구축하는 PM이 승리한다.)
결국 AI PM의 핵심은 ‘무엇을 만들 것인가’를 넘어 ‘제품이 어떻게 스스로 배우게 할 것인가’를 설계하는 데 있습니다.
AI PM이 반드시 갖춰야 할 기술적 문해력(Technical Literacy)
그렇다고 PM이 갑자기 파이토치(PyTorch) 코드를 짜거나 수학 논문을 읽어야 한다는 뜻은 아니에요. 하지만 엔지니어와 대화가 통하고, 합리적인 의사결정을 내릴 수 있는 ‘최소한의 문해력’은 필수입니다.
우선 모델의 기본 원리를 알아야 해요. 트랜스포머 아키텍처가 개념적으로 어떻게 돌아가는지, 온도(Temperature) 설정이 결과의 창의성에 어떤 영향을 주는지, 컨텍스트 윈도우의 크기가 왜 중요한지 정도는 이해하고 있어야 합니다 [4]. 이걸 모르면 엔지니어가 “지금 컨텍스트 윈도우가 부족해서 환각이 심해요”라고 말할 때, 그냥 “열심히 수정해 주세요”라고밖에 말할 수 없게 되거든요.
특히 제가 강조하고 싶은 건 ‘평가 설계(Evaluation Design)’ 능력입니다. AI 제품에서 가장 어려운 게 “이 결과가 좋은 결과인가?”를 정의하는 거예요. 실제로 제가 과거에 정성적인 ‘느낌’만으로 모델 성능을 판단했다가, 배포 후 특정 엣지 케이스에서 답변 품질이 급락해 롤백했던 뼈아픈 경험이 있습니다. 단순히 “느낌상 괜찮네”가 아니라, 정량적/정성적 지표를 세워 모델의 성능을 측정할 수 있는 체계를 잡는 능력이 AI PM과 일반 PM을 가르는 가장 큰 기술적 격차가 됩니다 [4, 1].
불확실성의 관리: 신뢰성과 윤리적 가드레일 설계
전통적인 소프트웨어에서 버그는 ‘제거해야 할 대상’이지만, AI 제품에서 확률적 오차는 ‘관리해야 할 대상’입니다. AI PM은 100% 정확도라는 환상에서 벗어나야 해요. 대신 “어느 정도의 오차까지 사용자가 수용할 수 있는가”라는 ‘수용 가능한 파라미터’를 설정하고, 그 범위 내에서 신뢰성을 확보하는 전략을 짜야 합니다 [2].
여기서 ‘책임감 있는 AI(Responsible AI)’라는 개념이 등장합니다. AI PM은 모델의 편향성, 공정성, 투명성, 그리고 개인정보 보호 같은 윤리적 가드레일을 설계해야 할 책임이 훨씬 큽니다 [3].
한번은 가드레일을 너무 타이트하게 설정했다가 AI가 지나치게 방어적인 답변만 내놓아 사용성(Usability)이 심각하게 떨어진 사례가 있었어요. 결국 ‘안전’과 ‘유용성’ 사이의 최적점을 찾는 정교한 튜닝 과정이 필수적이라는 걸 깨달았죠. 모델이 엉뚱한 소리를 하는 ‘환각’ 현상을 마주하면 당황스럽겠지만, 이걸 오히려 학습의 기회로 전환하는 팀 문화를 만드는 게 PM의 역량이에요. “왜 이런 결과가 나왔지?”를 분석해 데이터셋을 보강하는 루프로 연결하는 거죠.
짚고 넘어갈 한계와 안티패턴
현장에서 보면 정말 안타까운 케이스가 많아요. 특히 디지털 제품 경험이 풍부한 기술 PM(TPM)분들이 AI 제품을 맡았을 때 흔히 빠지는 함정이 있습니다. “지금까지 이렇게 해서 성공했으니 AI 제품도 똑같이 하면 되겠지”라는 생각이에요. 하지만 결정론적 세계의 문법을 확률적 세계에 그대로 적용하면, 예측 불가능한 타임라인 때문에 실패할 확률이 매우 높습니다 [2].
또 하나는 ‘FOMO(소외되는 것에 대한 두려움)’ 기반의 학습입니다. “요즘 다들 RAG 쓴다는데 우리도 넣자”, “에이전트 기능이 유행이라는데 추가해” 같은 식의 접근이죠. 정작 제품과 AI의 적합성(AI-Product Fit)에 대한 고민 없이 유행하는 기능을 덕지덕지 붙이는 건 ‘AI 제품’을 만드는 게 아니라, 그냥 ‘AI 기능을 추가한 기존 제품’을 만드는 것뿐입니다 [1].
AI 시대의 새로운 비즈니스 모델과 가격 전략
제품의 성격이 변하면 돈을 버는 방식도 변해야 합니다. 기존의 SaaS 모델처럼 “기능 A를 쓰려면 월 20달러” 식의 가격 책정은 AI 제품에 맞지 않을 수 있어요. AI는 추론 비용(Inference Cost)이 계속 발생하고, 제공하는 가치가 기능 그 자체보다 ‘결과’에 있기 때문입니다.
그래서 최근에는 결과 기반(Outcome-based) 가격 책정이나 사용량 기반(Usage-based), 혹은 AI가 만들어낸 이익을 나누는 가치 공유(Value-sharing) 모델 같은 창의적인 전략이 필요해지고 있습니다 [2].
중요한 건, 이런 복잡한 기술적 가치를 이해관계자들에게 “우리 모델의 파라미터가 얼마라서 좋습니다”가 아니라, “이 시스템이 비즈니스 결과(Outcome)를 어떻게 개선하는가”라는 비즈니스 언어로 설득하는 능력입니다.
핵심 요약
- 역할의 변화: AI PM은 결정론적 소프트웨어가 아니라 확률적 시스템을 관리하는 역할입니다.
- 핵심 역량: 단순한 기능 정의보다 ‘평가 설계(Evaluation Design)’와 ‘데이터 피드백 루프’ 구축이 훨씬 중요합니다.
- 주의할 패턴: 18개월짜리 선형적 로드맵에 집착하는 것은 AI 제품의 반복적 특성과 충돌하는 전형적인 실패 경로입니다.
- 가치 기준: 측정 기준을 ‘기능 구현 완료’에서 ‘비즈니스 결과(Outcome) 달성’으로 옮겨야 합니다.
- 기술적 문해력: 직접 구현하는 능력이 아니라, 무엇이 가능하고 불가능한지를 구분해 의사결정을 내리는 능력입니다.
사실 AI가 PM의 PRD 초안을 잡아주고 데이터 분석까지 해주는 시대가 왔습니다. 업무의 일부는 대체되겠죠. 하지만 “우리가 왜 이 문제를 풀어야 하는가”에 대한 본질적인 판단과, 인간 중심의 가치를 설계하는 일은 여전히 PM의 영역으로 남을 겁니다. 도구의 숙련도를 높이는 것도 좋지만, 이제는 사고의 틀 자체를 ‘확률적 시스템’으로 바꾸는 용기가 필요한 때인 것 같습니다.
참고 자료 (References)
1. [linkedin.com] How AI PM differs from traditional PM — https://www.linkedin.com/posts/siddhartharoraisb_what-is-the-main-difference-between-a-traditional-activity-7383849997462777856-ALKo 2. [vinvashishta.substack.com] What’s The Difference Between A Data & AI Product Manager & A Digital Technical Product Manager? — https://vinvashishta.substack.com/p/whats-the-difference-between-a-data 3. [scaledagile.com] AI Product Manager: A Guide to AI/ML Strategy — https://scaledagile.com/blog/ai-ml-product-managers-guide 4. [recruited.tech] The AI-enabled PM vs AI PM / Recruited — https://www.recruited.tech/blog/ai-enabled-pm-vs-ai-pm
관련 글 추천
- https://infobuza.com/2026/06/19/20260619-b0lrb2/
- https://infobuza.com/2026/06/19/20260619-7l1jw7/
FAQ
AI-Enabled PM과 AI PM의 차이점은 무엇인가요?
AI-Enabled PM은 챗GPT와 같은 AI 도구를 사용하여 PRD 작성 등 업무 효율성을 높이는 'AI 활용자'인 반면, AI PM은 제품의 핵심 엔진으로 AI를 설계하고 확률적 시스템을 관리하는 역할을 합니다.
AI PM이 갖춰야 할 '기술적 문해력'이란 구체적으로 무엇을 의미하나요?
직접 코드를 짜는 능력이 아니라, 트랜스포머 아키텍처의 기본 원리, 온도(Temperature) 설정, 컨텍스트 윈도우의 중요성 등을 이해하여 엔지니어와 소통하고 합리적인 의사결정을 내릴 수 있는 능력을 의미합니다.
AI 제품에서 '평가 설계(Evaluation Design)'가 왜 중요한가요?
AI는 매번 똑같은 답을 내놓지 않기 때문에, 단순히 '느낌'이 아니라 정량적/정성적 지표를 통해 결과물이 사용자가 원하는 결과에 얼마나 근접했는지 측정하는 체계를 잡는 것이 제품의 품질 유지와 직결되기 때문입니다.
AI PM이 전통적인 PM과 다르게 접근해야 하는 로드맵과 개발 방식은 무엇인가요?
전통적인 PM은 꼼꼼한 선형적 로드맵과 '기획→개발→테스트→배포'의 경로를 따르지만, AI PM은 불확실성을 인정하고 데이터를 통해 모델을 정제하는 반복적(Iterative) 과정과 학습 시스템 구축에 집중해야 합니다.
AI 제품의 가격 전략은 기존 SaaS 모델과 어떻게 달라야 하나요?
AI는 추론 비용(Inference Cost)이 지속적으로 발생하고 가치가 '결과'에 있기 때문에, 단순 기능별 월정액보다는 결과 기반(Outcome-based), 사용량 기반(Usage-based), 또는 가치 공유(Value-sharing) 모델과 같은 창의적인 전략이 필요합니다.