안녕하세요, 채원입니다.
지난번 공고 분석에 이어, 이번에는 'AI PM' 관련 공고를 따로 모아 들여다봤습니다.
읽다 보니 눈을 의심하게 만드는 요건이 하나 있었습니다.
"자격 요건: 경력 3년 ~ 20년"
처음엔 오타인 줄 알았습니다. 3년 차와 20년 차는 완전히 다른 역량을 가진 사람인데, 같은 포지션으로 뽑는다니요. 채용 시장조차 'AI PM'이 대체 무슨 일을 하는 직업인지 아직 명확히 정의하지 못하는 과도기로 느껴졌습니다.
실제로 공고들을 자세히 뜯어보니, 분명 같은 “AI PM”을 뽑는다고 적혀있는데 요구하는 역량은 극과 극이었습니다. 한쪽은 LLM 메커니즘을 이해하고 ML 엔지니어와 협업할 사람을 원했고, 다른 쪽은 AI 툴로 기존 업무를 자동화한 경험을 원했습니다.
같은 단어, 다른 기대.
결국 “AI PM”이라는 껍데기 안에는 사실 완전히 다른 두 개의 직업이 섞여 있는 셈입니다. 오늘은 그 구분선에 대해 이야기해보려 합니다.
두 개의 AI PM
공고들을 나눠보면 이렇습니다.
AI-native PM은 AI가 제품의 핵심인 곳에서 일합니다. LLM이 어떻게 작동하는지 이해하고, 모델의 한계를 제품 제약으로 설계하고, ML Engineer와 같은 언어로 대화할 수 있어야 합니다. 공고에는 프롬프트 엔지니어링, 할루시네이션 감지, 응답 안전성 같은 단어들이 등장합니다.
AI-enabled PM은 AI를 도구로 써서 기존 업무를 더 빠르고 똑똑하게 만드는 사람입니다. 기술 이해보다 적용 감각이 중요합니다.
한 공고에는 이런 문장이 있었어요.
- AI를 ‘툴’이 아니라 ‘운영 엔진’으로 활용할 수 있는 분
이 두 유형은 요구하는 스킬도, 협업하는 팀도, 성장 경로도 다릅니다. 그런데 채용 시장에서는 둘 다 “AI PM”이라는 같은 이름으로 불리고 있었습니다.
AI-native PM이 다른 이유
AI-native PM 공고를 읽으면서 기존 PM 공고와 가장 다르다고 느낀 게 세 가지입니다.
첫째, KPI의 언어가 바뀝니다.
실제 공고 문장입니다.
- Deflection Rate, CSAT 달성 / Accuracy, Relevance, Groundedness 추적
Deflection Rate는 AI가 사람 상담사 대신 문제를 해결한 비율입니다. Groundedness는 AI 응답이 실제 데이터에 근거하는 정도를 나타냅니다. 전환율과 DAU를 봐왔던 기존 PM과는 사뭇 다릅니다.
둘째, 리스크 관리가 PM의 일이 됐습니다.
- adversarial inputs (e.g., jailbreaking attempts), policy violations, safety guardrails
- 10대 사용자에게 적합한 안전한 AI 응답 정책을 수립
기존 PM의 리스크 관리는 “이 기능 법적으로 괜찮아요?“를 법무팀에 묻는 수준이었습니다. AI-native PM은 가드레일을 직접 설계하고, 할루시네이션 대응 정책을 직접 만들어야 합니다.
기능이 ‘작동하는가’가 아니라 ‘안전하게 작동하는가’까지 책임 범위가 달라진 겁니다.
셋째, 사고방식 자체가 달라야 합니다.
기존 소프트웨어는 결정론적입니다. 버튼이 작동하거나, 안 하거나. 버그가 있으면 고치면 100% 해결됩니다.
하지만 AI 제품은 확률론적입니다. 같은 질문을 해도 매번 다른 답이 나올 수 있고, 95%는 훌륭하지만 5%는 완전히 틀릴 수 있어요. 이 5%는 고쳐야 할 버그가 아니라, 확률적 시스템의 본질입니다.
AI-native PM의 일은 틀린 답을 없애는 것이 아니라 “틀린 답이 나왔을 때 어떻게 처리할 것인가를 설계하는 것”입니다. 이 전환이 안 되면, AI 제품에서 계속 잘못된 결정을 내리게 됩니다.
그럼 나는 어느 쪽인가
대부분은 AI-enabled PM 쪽일 겁니다. 시장에 두 유형이 모두 필요하고, 현실적으로 AI-enabled PM의 수요가 많을테니까요. 중요한 건 내가 어느 쪽인지 알고 준비하는 겁니다.
유형별로 지금 당장 챙길 것
AI-native PM을 목표로 한다면
이 포지션은 단순히 “개념을 아는 사람”을 원하지 않습니다. 저는 AI-enabled PM에 가깝기에 AI Native PM의 실무를 "이렇게 하라"고 단정 지을 순 없습니다. 하지만 공고가 가리키는 교집합은 선명합니다.
LLM 기초(Token, Context Window, Temperature)를 아는 것에서 끝나는 게 아니라, 응답 품질 지표(Hallucination, Grounding, Deflection Rate)를 제품 결정에 연결하고, 리스크 설계(Safety Guardrail)까지 직접 다룰 수 있어야 합니다.
개념의 정의를 읊는 사람이 아니라, 그 개념이 제품 판단과 어떻게 연결되는지를 언어화할 수 있는 사람, 그게 이 포지션이 찾는 사람입니다.
AI-enabled PM을 목표로 한다면
AI 툴을 잘 쓰는 것만으로는 이제 차별점이 안 됩니다.
세 단계로 생각해보세요.
- 1단계 (본인 생산성): 리서치, 문서, 데이터 해석에 AI를 녹이는 것. 이건 빠르게 기본값이 되고 있습니다.
- 2단계 (팀 워크플로우 설계): 내가 만든 자동화를 팀에 도입하고, 그 성과를 수치로 남기는 것. “AI 도입으로 주간 리포트 3시간 → 30분”처럼 기록된 증거가 이력서에서 강하게 작동합니다.
- 3단계 (판단력): 언제 AI를 쓰지 말아야 하는지 아는 것. 같은 입력에 항상 같은 출력이 필요한 단순 업무에 AI를 쓰면 오히려 복잡성만 늘어납니다. 이 문제는 AI가 필요한가, 단순 자동화로 충분한가”를 구분하는 눈이 AI-enabled PM의 진짜 레벨을 보여줍니다.
AI PM이라는 직업은,
아직 정의가 완성되지 않았습니다. 그게 불안하게 느껴질 수도 있지만, 저는 반대로 읽습니다. 직무 정의가 유동적이라는 건, 역으로 내가 그 자리를 주도적으로 만들어갈 수 있다는 뜻이니까요. 다음 주도 함께 고민하며 자리를 주도적으로 만들어나갈 수 있는 컨텐츠로 찾아뵙겠습니다.
의견을 남겨주세요