AI 프로덕트 매니저(AI PM)에게 필요한 역량

 

올해 채용 공고를 보면 "AI PM"이라는 직무명이 눈에 띄게 늘었습니다.
저희 회사에서도 비슷한 포지션을 신설하는 논의가 있었고, 그 논의에 참여하면서 "AI PM에게 정확히 어떤 역량이 필요한가"를 꽤 오래 고민하게 됐어요.
기존 PM 역량에 뭘 더 얹어야 하는 건지, 아니면 완전히 다른 직무인 건지부터 명확히 해야 했습니다.
이번 글은 그 고민을 정리한 결과물입니다.

 

기존 PM 역량이 사라지는 게 아니다

먼저 분명히 하고 싶은 건, AI PM이 기존 PM 역량을 대체하는 자리가 아니라는 점입니다.
사용자 문제를 발견하고, 우선순위를 정하고, 팀을 조율하는 기본 역량은 여전히 핵심이에요.
저희 회사에서 처음 이 논의가 나왔을 때, 일부는 "AI를 잘 아는 엔지니어 출신을 뽑자"는 의견이었는데, 실제로 몇 번의 인터뷰를 진행해보니 기술은 잘 알지만 사용자 문제를 정의하는 기본기가 부족한 후보들이 꽤 있었어요.
결국 기존 PM 역량 위에 몇 가지가 추가로 필요한 구조라고 결론을 내렸습니다.

 

첫 번째, 데이터와 실험에 대한 감각

AI 기능은 배포하고 끝나는 게 아니라, 지속적으로 실험하고 개선하는 과정이 훨씬 중요합니다.
A/B 테스트 설계, 오프라인 평가셋 구성, 실패 사례 분류 같은 작업을 직접 하지는 않더라도 최소한 그 결과를 읽고 판단할 수 있어야 해요.
저희 팀에서 AI PM 역할을 맡은 동료는 매주 실패 사례 30건을 직접 읽고 분류하는 걸 루틴으로 만들었는데, 이 과정에서 나온 인사이트가 로드맵에 실제로 반영되는 걸 여러 번 봤습니다.
데이터를 다루는 감각이 있는 PM과 없는 PM의 의사결정 속도 차이가 꽤 크더라고요.

 

두 번째, 리스크와 윤리에 대한 감각

AI 기능은 잘못됐을 때 파급 범위가 기존 기능보다 넓은 경우가 많습니다.
편향된 답변, 개인정보 노출, 잘못된 정보로 인한 사용자 피해 같은 리스크를 사전에 상상할 수 있어야 해요.
저희는 실제로 채용 추천 기능을 검토하다가, 특정 조건의 사용자에게 불리하게 작동할 수 있는 패턴을 발견해서 출시를 두 달 미룬 적이 있습니다.
이때 결정을 내린 건 개발팀이 아니라 PM이었는데, "기술적으로 가능한가"가 아니라 "이게 우리 사용자에게 공정한가"를 판단하는 역할이 결국 PM에게 있다는 걸 그때 다시 느꼈어요.

 

세 번째, 프롬프트와 명세를 함께 다루는 능력

앞서 다른 글에서도 다뤘지만, 프롬프트를 명세서처럼 다룰 줄 아는 것도 중요한 역량입니다.
직접 프롬프트를 짜는 것까지는 아니어도, 입력과 출력 형식, 실패 시 동작을 구체적으로 정의할 수 있어야 개발팀과 정확하게 소통할 수 있어요.
저는 이 역량이 부족한 상태로 프로젝트를 시작했다가, "AI가 알아서 잘해줄 것"이라는 모호한 기대로 명세를 넘겨서 몇 번 다시 작업한 경험이 있습니다.

 

네 번째, 불확실성을 다루는 커뮤니케이션

AI 기능은 "이렇게 하면 이런 결과가 나온다"고 확실하게 약속하기 어려운 경우가 많습니다.
경영진이나 다른 팀에 결과를 보고할 때, 이 불확실성을 숨기지 않고 정직하게 전달하는 능력이 중요해요.
저희 팀 리더는 항상 "지금 이 지표는 몇 퍼센트 확신 구간에서 봐야 한다"는 식으로 숫자에 항상 범위를 붙여서 이야기하는데, 처음엔 답답하게 느껴졌지만 나중엔 이게 훨씬 신뢰를 준다는 걸 알게 됐습니다.
확실한 척하다가 나중에 틀리는 것보다, 처음부터 불확실성을 인정하는 게 장기적으로 신뢰를 지키는 방법이라는 걸 느꼈어요.

 

다섯 번째, 도메인 전문가와의 협업

AI 기능의 품질은 결국 그 분야의 전문 지식에서 나오는 경우가 많습니다.
저희가 예약 상담 관련 기능을 만들 때, PM인 저보다 서비스를 운영하는 지원팀의 검토가 훨씬 중요한 역할을 했어요.
AI PM은 이런 도메인 전문가와 개발팀 사이에서 번역가 역할을 해야 하는데, 이게 생각보다 쉽지 않았습니다.
운영팀과 개발팀! 이 둘을 이어주는 게 결국 PM의 몫이었어요.

 

여섯 번째, 변화하는 도구에 대한 학습 속도

이 역량은 좀 다른 성격입니다.
특정 기술을 깊이 아는 것보다, 새로운 도구나 모델이 나왔을 때 그걸 빠르게 파악하고 우리 서비스에 적용 가능한지 판단하는 속도 자체가 역량이 되고 있어요.
올해만 해도 새로운 모델이 나올 때마다 기존 프롬프트가 그대로 통하지 않거나, 오히려 더 짧은 프롬프트로도 같은 품질이 나오는 경우가 여러 번 있었습니다.
저희 팀의 AI PM은 새 모델이 나오면 항상 기존 벤치마크 질문 셋으로 먼저 테스트를 돌려보고, 결과를 팀에 공유하는 걸 루틴으로 삼고 있어요.
이 루틴이 있어서, 새로운 모델로 전환할지 말지를 감이 아니라 데이터로 결정할 수 있게 됐습니다.
개인적으로는 이 학습 속도가 앞으로 다른 역량들보다 훨씬 중요해질 거라고 보고 있어요.

 

채용 시장에서 본 AI PM의 실제 모습

올해 여러 회사의 AI PM 채용 공고를 눈여겨봤는데, 회사마다 기대하는 역할이 상당히 다르다는 걸 알게 됐습니다.
어떤 회사는 사실상 데이터 사이언티스트에 가까운 역량을 요구했고, 어떤 회사는 기존 PM 역량에 AI 관련 이해만 살짝 더한 정도를 요구했어요.
지인이 다니는 한 스타트업은 AI PM에게 프롬프트 작성부터 간단한 평가 스크립트 작성까지 요구했는데, 정작 사용자 리서치나 우선순위 설계에는 크게 신경 쓰지 않는다는 이야기를 듣고 조금 걱정이 되기도 했습니다.
기술적인 역량에 치우쳐서 기존 PM의 기본기가 흐려지면, 결국 기능은 정교한데 사용자에게 필요 없는 제품이 나올 위험이 있다고 생각해요.
이런 사례들을 보면서, 저는 오히려 "AI PM"이라는 이름표보다 균형 잡힌 역량 구성이 더 중요하다는 확신이 강해졌습니다.

 

우리 조직에서 시도한 역량 진단 방법

역량을 말로만 나열하지 않고, 실제로 팀원들이 어느 정도 위치에 있는지 점검해보고 싶었습니다.
그래서 저희는 앞서 정리한 여섯 가지 역량을 각각 1~5점으로 자가 진단하고, 그 위에 동료 평가를 더해서 팀 전체의 역량 지도를 그려봤어요.
결과는 꽤 흥미로웠습니다.
데이터와 실험에 대한 감각은 팀 전체적으로 평균 이상이었는데, 도메인 전문가와의 협업 역량은 상대적으로 낮게 나왔어요.

AI PM 채용 시 저희가 실제로 쓰는 평가 루브릭

앞서 말한 여섯 가지 역량을 정리한 뒤로, 채용 면접에서도 이걸 그대로 루브릭으로 활용하고 있습니다.
각 역량마다 "이 정도면 충분", "성장 가능성 있음", "우려됨" 세 단계로 나누고, 면접관마다 근거가 되는 실제 발언이나 사례를 기록하도록 했어요.
예를 들어 데이터와 실험 감각을 평가할 때는 "과거에 실패한 실험을 하나 설명해달라"는 질문을 반드시 넣고, 그 실패에서 무엇을 배웠는지까지 들어보는 식입니다.
이 루브릭을 도입하기 전에는 면접관마다 평가 기준이 달라서 최종 합의에 시간이 오래 걸렸는데, 지금은 같은 기준으로 각자 평가한 걸 모아보니 합의가 훨씬 빨라졌어요.
다만 이 루브릭도 계속 손보고 있습니다.
처음 만들었을 때는 "여섯 번째, 변화하는 도구에 대한 학습 속도"를 평가하는 질문이 마땅치 않았는데, 지금은 "최근 6개월 사이에 스스로 학습해서 업무에 적용한 새로운 도구나 방법"을 구체적으로 물어보는 질문으로 정착됐습니다.

 

작은 조직과 큰 조직에서 다르게 적용해야 할 부분

이 여섯 가지 역량을 다른 회사 동료들과 이야기하면서 느낀 건, 조직 규모에 따라 우선순위가 꽤 달라진다는 점이었습니다.
저희처럼 PM 한 명이 여러 역할을 겸해야 하는 작은 조직에서는 여섯 가지를 한 사람이 최소한이라도 다 갖추고 있어야 프로젝트가 굴러갑니다.
반면 대규모 조직에서 일하는 지인의 이야기를 들어보니, 그쪽은 역량을 역할별로 나눠서 여러 명의 AI PM이 각자 하나씩 깊게 파고드는 구조였어요.
한 명은 데이터와 실험에, 다른 한 명은 리스크와 윤리에 집중하는 식으로 말이죠.
이 이야기를 듣고, "AI PM에게 필요한 역량"이라는 질문에 하나의 정답은 없다는 걸 다시 확인했습니다.
결국 조직의 규모와 리스크 수준에 맞게 이 역량들을 어떻게 배분할지가 진짜 질문이었어요.

 

실험 결과를 조직 전체에 설득하는 능력

여섯 가지 역량 목록에는 넣지 않았지만, 실무를 하면서 새롭게 중요하다고 느낀 역량이 하나 더 있습니다.
AI 기능의 실험 결과는 기존 기능보다 훨씬 설명하기 까다로운 경우가 많아요.
"정확도가 87%다"라는 숫자만 던지면, 다른 팀에서는 "그게 좋은 건지 나쁜 건지 모르겠다"는 반응이 돌아옵니다.
저는 이 숫자를 항상 비교 기준과 함께 제시하는 습관을 들였어요.
"기존 방식은 정확도가 65%였고, 이번 방식은 87%다"처럼 비교 대상을 함께 보여주니 다른 팀도 훨씬 쉽게 판단을 내리더라고요.
또 한 번은 정확도가 오히려 낮게 나온 실험 결과를 경영진에게 보고해야 했는데, 숫자만 보여줬다면 "실패한 프로젝트"로 낙인찍힐 상황이었습니다.
그래서 저는 "이 실패를 통해 다음에 무엇을 다르게 할 것인지"까지 같이 정리해서 보고했고, 결과적으로 프로젝트가 중단되지 않고 다음 단계로 이어질 수 있었어요.
숫자 자체보다, 그 숫자를 어떤 맥락 안에 놓고 설명하느냐가 조직의 의사결정에 훨씬 큰 영향을 준다는 걸 이 경험을 통해 배웠습니다.

 

직무명보다 중요한 것

이렇게 정리하고 나니, 결국 AI PM이라는 직무명 자체보다 "기존 PM 역량에 어떤 층위를 얼마나 더 쌓았는가"가 더 중요한 질문이라는 생각이 들었습니다.
저희 회사는 결국 별도 직무를 신설하지 않고, 기존 PM들이 이 여섯 가지 역량을 프로젝트별로 나눠서 학습하는 방향으로 정리했어요.
직무명을 새로 만드는 것보다, 팀 전체의 역량을 끌어올리는 게 지금 시점에는 더 현실적이라고 판단했습니다.

이 역량들을 하나씩 적어놓고 보니, 사실 새로운 게 아니라 기존 PM 역량의 연장선이라는 생각도 듭니다.
다만 그 연장선의 폭이 예전보다 훨씬 넓어졌고, 그만큼 배워야 할 것도 많아졌다는 게 부담스러우면서도 흥미로운 지점인 것 같아요.
내년에는 이 여섯 가지 중 어떤 게 더 중요해질지, 아니면 또 새로운 항목이 추가될지 지켜볼 계획입니다.