AI 제품 시대, PM의 역할은 이렇게 달라진다

Part 10. 정답보다 질문, 명세보다 실험, 길을 설계하는 사람

Jul 6. 2025

Part 10. 핵심 요약

- AI PM은 실험/해석을 반복하며 팀과 제품의 방향을 설계한다.
- 기술보다 문제 중심으로 사고하며, 사용자와 제품 사이에서 새로운 경험의 가능성을 검증해야 한다.
- 기능 기획보다도, 정답 없는 시대에서 제품이 나아갈 방향과 그 과정을 함께 설계하는 사람이다.

이제는 누구도 제품의 정답을 알고 시작하지 않는다.
특히 AI 제품을 만들다보면, 예전처럼 명확한 요구사항이나 기능 명세만으로는 부족함을 실감하게 된다.

PM에게 필요한 건 정답이 아니라, 좋은 질문을 잘 던지고, 실험할 수 있는 구조를 만드는 힘이다.

이 글은 그런 시대의 PM에게 필요한 태도와 역할, 그리고 내가 겪은 시행착오의 결과로서 남기는 마지막 이야기다.

더 이상 '명세서'만으로 설명할 수 없는 제품

AI 제품의 시대에서 ‘기획’은 더 이상 예전과 같은 의미를 가지지 않는다. 예측이 어려운 생성형 AI 환경에서는 디테일한 요건이나 스펙 자체가 무의미해지기 때문이다.

하지만 기획이 중요하지 않다는 뜻은 아니다. 오히려 지금 이 시대엔 더 좋은 기획이 필요하다.

사용자의 문제를 정확히 정의하고, 해결 방안을 구상하며, 실험 가능한 가설을 세우고, 반복하며 제품을 다듬는 일—이 모든 과정은 여전히 ‘기획’이다.

이제는 완전히 정해진 정답이나 기능을 그리는 것이 아니라, 불확실한 문제 속에서 가설을 세우고, 사용자와 함께 답을 찾아가는 실험 중심의 제품 설계가 중심이 되어야 한다. 그리고 ‘AI를 적용한다’는 사실을 너무 거창하게 바라볼 필요도 없다. 기존처럼 사용자 중심의 제품 설계 안에서 AI를 하나의 도구로 바라보면, AI '기능'의 세세한 요건 정의에 집착하지 않아도 된다.

결국, AI를 다루는 PM 역시 시장과 사용자의 진짜 문제를 정의하고, 가설을 세우며, 실험하고 학습하는 구조를 앞서 설계하는 사람이라는 본질은 달라지지 않는다.

실험 가능한 구조를 만드는 사람

AI 제품에서는 예측 가능성과 정답이 더욱 희박하다. 모델의 출력은 동일한 입력에서도 달라질 수 있고, 사용자 기대는 복잡하고 모호하며, 제품 사용 과정은 정형화되지 않는다. 전통적인 소프트웨어 제품처럼 명확한 유저 플로우나 conversion funnel을 정의하기도 어렵고, 수치 기반 지표 하나로 만족도를 판단하는 것도 힘들다.

그래서 더더욱, 실험 가능한 구조를 제품에 내장하는 것이 중요해진다.

사용자가 어떤 입력을 할지 예측할 수 없다면, 다양한 케이스에 대응할 수 있는 관찰 시스템을 만들어야 하고,
사용자의 행동이 단순 클릭이 아니라 대화 흐름이라면, 그 안의 맥락을 추출하고 해석할 수 있어야 한다. 즉, 정답이 없기 때문에 실험 기반의 시스템을 설계하는 것이며, PM은 이러한 학습 가능한 제품 구조를 반복 실험과 데이터 관찰을 통해 만들 수 있어야 한다.

이 과정에서 PM은 단순히 실험만 설계하는 사람이 아니라, 다양한 유저 세그먼트에 따라 적절한 실험을 설계하고, 실험의 목적과 해석 기준을 팀과 함께 정리하며, 반복을 통해 팀이 점점 정밀한 의사결정을 할 수 있도록 돕는 촉매제 역할을 하게 된다.

사용자 맥락을 이해하는 직관과 통찰력

AI 제품의 PM은 기술 자체보다 사용자와의 관계를 어떻게 해석하느냐에 따라 제품의 진화가 달라진다.

입력은 했는데 응답 이후 아무 행동도 하지 않고 나가버리는 사용자

여행 일정을 생성해줬지만 “내가 잘못 입력했나?” 하고 조용히 이탈하는 사용자

상담 챗봇에 마음을 터놓다 갑자기 아무 말 없이 대화를 멈춘 사용자

이러한 침묵은 종종 '정상'처럼 보이지만, 사실은 제품이 문제를 제대로 해결하지 못했을 수도 있는 신호다. (Part 9 글 참고) PM은 이 침묵 속에서 신호를 포착해야 한다.

이 때 중요한 것이 바로 사용자 맥락을 이해하는 직관이다. 정량 지표로 드러나지 않는 불편을 짚어내고, 유사한 패턴을 분류하고, 왜 그 반응이 나왔는지 추론하며, 문제를 실험 가능한 가설로 바꾸는 능력이 필요하다

사실 이 직관은 하루 아침에 만들어지지는 않는다. 사용자 피드백을 읽고, 세션 레코딩을 관찰하며, 반복적인 실험을 통해 맥락을 읽는 연습이 필요하다. 그리고 이 과정을 팀과 함께 나눌 수 있어야 한다. 직관은 혼자 갖고 있으면 해석이 다르고, 팀이 신뢰하지 않으면 실행되지 않는다. 데이터와 함께 해석을 공유하고, 팀 내 해석 틀을 일치시키는 ‘내러티브’를 만들어야 한다.

PM은 분석가이자 번역가이고, 전략가이자 관찰자다.

기술보다 앞서야 할 것은, 바로 이러한 사용자의 맥락을 읽는 사고력과 통찰력이다.

PM은 더 멀리, 더 높은 방향부터 설계하는 사람

PM(Product Manager)이라는 역할은 조직마다, 국가마다, 그리고 문화마다 다르게 정의된다.

한국에서의 PM은 종종 기능 중심 기획자 또는 스프린트를 관리하는 역할로, 미국의 PO(Product Owner)에 가까운 업무를 수행하기도 한다. 반면 미국의 PM은 제품의 전략 방향을 리드하고, 문제 정의부터 팀 빌딩, 사업 판단, C-level 의사결정까지 리딩하는 등 더 전략적인 역할을 맡는 경우가 많다. 한국의 PO에 가깝다.

내가 경험한 PM의 역할 및 정의

이 시리즈에서 말하는 PM은 제품 전략과 문제 정의, 사용자 가치 발굴을 중심으로 제품을 설계하고 실행하는 Product Manager다. 단순히 ‘기획자’가 아니라, 사용자 중심 문제 해결자이자, 방향 설계자, 실험 설계자로서의 PM을 의미한다. 팀 내외에서 제품을 대표하고, 조직과 끊임없이 소통하며, 함께 나아갈 방향과 구조를 설계하는 리더에 더 가깝다.

AI 제품을 만들다 보면 기존의 역할과 경계만으로는 부족하다는 걸 자주 실감하게 된다. 예측이 어렵고 명확한 정답이 존재하지 않기 때문이다. 특히 팀 전체가 처음 AI 제품을 다루는 경우, PM은 더 앞서서 방향을 제안하고, 실험 구조를 설계하며, 팀의 일하는 방식조차 함께 만들어가야 할 때가 많다.