AI PM 커리어, 어떻게 준비할까 — 연봉 2억 직무 진입 설계

“AI PM이 되려면 코딩부터 배워야 하나요?” 커리어 전환을 고민하는 사람들이 가장 먼저 묻는 질문이다. 그런데 미국 AI PM 채용 공고 592건을 뜯어보면 정반대 답이 나온다. 프롬프트 엔지니어링을 요구한 공고는 9%뿐이었다. 대신 크로스펑셔널 협업 32%, 제품 전략 29%, 데이터 분석 27%가 상위를 차지했다.

AI PM(AI Product Manager, 인공지능 제품 관리자)은 지금 테크 업계에서 가장 빠르게 커지는 직무다. 미국에서 2024년 1월부터 2025년 10월까지 신규 채용만 12,339건이 확인됐고, 중앙값 연봉은 $200,500(약 2억 8천만 원)다. 좋은 소식은, 이 자리로 가는 문이 학위가 아니라 다른 것에 걸려 있다는 점이다.

핵심 요약
AI PM은 새 직업이 아니라 기존 PM 위에 ‘확률’을 얹은 직무다. 전통 PM 기본기는 그대로 유효하고, AI 리터러시·데이터 직관·시스템 사고 세 층만 새로 얹으면 된다. 진입의 열쇠는 완성된 경력이 아니라, 확률적 시스템을 직접 다뤄본 포트폴리오 한 건이다.

AI PM이란 무엇인가

AI PM은 확률적으로 동작하는 시스템을 설계하는 PM이다. 완전히 새로운 직업이 아니라, 기술 패러다임 변화가 만들어낸 자연발생 직무에 가깝다.

돌아보면 2010년경 모바일 PM, 2015년경 그로스 PM이 그렇게 생겨났다. 스마트폰이 나오자 모바일 PM이 필요해졌고, 성장 지표를 다루는 문화가 자리잡자 그로스 PM이 뜬 것과 같은 흐름이다. AI PM도 기존 PM 역량 위에 새 층을 얹는 구조다.

본질 차이는 딱 하나, 결정론이냐 확률론이냐다. 일반 소프트웨어 PM은 “이 기능이 잘 동작하는가”를 설계한다. 버튼을 누르면 항상 같은 화면이 뜨는 세계다. 반면 AI PM은 “이 확률적 시스템이 일관되게 작동하는가”를 설계한다. 같은 질문을 던져도 AI는 매번 조금씩 다른 답을 내놓는다. 그 흔들림을 어떻게 관리할지가 일의 핵심이 된다.

규모로 보면 이 직무는 이미 담론이 아니라 실체다. LinkedIn 기준 전 세계 4만 개 이상, Indeed 기준 미국 내 3천 개 이상의 AI PM 공고가 존재한다. Google(Vertex AI)·Amazon·Microsoft(Copilot)·Meta·Scale AI 같은 빅테크가 전담 AI PM을 뽑으면서 직군 자체가 표준으로 굳었다.

전통 PM과 AI PM은 무엇이 다른가

핵심 질문, 산출물, 지표, 실패 관리, 시스템을 보는 눈까지 다섯 축이 전부 바뀌었다. 도구 몇 개 갈아 끼우는 수준이 아니라 사고방식을 통째로 다시 짜는 일에 가깝다.

차원	전통 PM (~2022)	AI PM (2026)
핵심 질문	기능이 잘 동작하는가	확률적 시스템이 일관되는가
주 산출물	PRD(요구사항 명세)	Evals(품질 분포 기준)
핵심 지표	전환율·리텐션(평균)	환각률·응답 속도·근거 충실도(분포)
실패 관리	배포 전 QA로 차단	배포 후 모니터링·개입률 관리
시스템 뷰	기능 단위	입력→프롬프트→출력→조율 전체 흐름

여기서 눈여겨볼 단어가 Evals(Evaluations, AI 출력 품질을 정량 측정하는 평가 체계)다. 전통 PM이 PRD(Product Requirements Document, 제품 요구사항 정의서)로 “무엇을 만들지”를 적었다면, AI PM은 Evals로 “무엇이 좋은 출력인지”를 정의한다. 간결함·친절함·정확함처럼 원래 말로만 하던 걸 숫자로 바꿔 재는 것이다. 실무자들 사이에서 “Evals가 PRD를 대체한다”는 말이 나오는 이유다.

그런데 다섯 축이 다 바뀌었어도 토대는 그대로다. 사용자 중심 사고, 가설을 세우고 검증하는 습관, 데이터로 판단하는 태도. 이 기본기는 전통 PM이든 AI PM이든 변하지 않는다. 그래서 비전공자에게도 문이 열려 있고, 진입 장벽이 학위가 아니라 ‘확률을 다뤄본 증거’로 옮겨간 것이다.

AI PM에게 필요한 역량은 무엇인가

프롬프트를 잘 쓰는 기술이 아니라 판단하는 능력이다. 기존 PM 기본기 위에 세 개의 층이 새로 얹힌다.

(AI PM은 테크 업계에서 가장 빠르게 진화하는 프로덕트 직무다, 출처: Aakash Gupta / The State of AI Product Management)

세 층을 알약 흐름으로 그리면 이렇게 된다. 아래로 갈수록 좁은 기술이 아니라 넓은 판단으로 향한다.

첫째, AI 리터러시(AI literacy, AI를 이해하는 능력)다. 엔지니어처럼 깊이 아는 게 아니라 의사결정에 필요한 직관 수준이면 된다. 토큰·컨텍스트·추론·RAG(Retrieval-Augmented Generation, 검색으로 근거를 찾아와 답을 만드는 방식)·에이전트 같은 개념을 이해해서, “이 기능은 RAG로 가면 어떨까요?”처럼 엔지니어와 같은 언어로 대화할 수 있으면 충분하다.

둘째, 데이터 직관이다. 평균이 아니라 분포를 보는 감각이다. AI는 열 번 중 아홉 번 잘하다가 한 번 크게 어긋난다. 그래서 평균 응답 시간이 아니라 상위 5% 지점의 느린 응답, 환각률, 근거 충실도, 사용자 개입률 같은 AI 특화 지표를 읽어야 한다.

셋째, 시스템 사고다. 부품이 아니라 전체 흐름을 본다. 입력 처리부터 프롬프트, 출력 처리, 여러 구성요소를 조율하는 단계까지 하나의 흐름으로 그린다. “입력이 너무 길면? 검색이 실패하면? 모델이 없는 사실을 지어내면? 비용이 폭주하면?” 이런 실패 시나리오를 미리 짚는 감각이다.

이 세 역량은 결국 하나로 모인다. 채용 데이터가 그 방향을 정확히 가리킨다. 미국 공고 592건 분석에서 상위 요구는 협업·전략·데이터 분석이었고, 프롬프트 엔지니어링은 9%, 생성AI는 8%에 그쳤다(axialsearch 592건 분석).

판단·조율 역량이 기술 스킬보다 3배 이상 요구된다는 뜻이다. 프롬프트 잘 짜는 법을 파고들 시간에 협업·전략·데이터를 다지는 편이 채용 시장 논리에 맞는다.

비전공자도 AI PM이 될 수 있는가

될 수 있다. 오히려 AI PM의 다수가 비전공자다. 출처마다 숫자는 58~84%로 갈리지만, “컴퓨터공학 전공이 아닌 사람이 다수”라는 방향은 여러 조사가 일치한다.

주니어에서 중급으로 넘어갈 때 중앙값 연봉이 $110,000에서 $195,000으로 78% 뛴다(출처: The State of AI Product Management, Aakash Gupta, 2025-11). 경력이 쌓일수록 확실히 보상이 커지는 구조다.

코딩을 꼭 배워야 하냐는 질문에는, 엔지니어 수준까지는 필요 없다는 게 답이다. Marily Nika(전 Google·Meta AI PM, Maven AI PM 강좌 창시자)는 자신감을 위해 기초 코딩을 익혀두라고 권하면서도, 자동화가 진행되더라도 동작 원리를 아는 게 핵심이라고 본다. 코드를 직접 짜는 능력보다, 이 시스템이 어떻게 굴러가는지 이해하는 감각이 중요하다는 얘기다.

(Marily Nika는 Meta Reality Labs의 AI 프로덕트 리더로, 이전 Google에서 8년간 일했다, 출처: AI and product management — Lenny’s Podcast)

그가 강조하는 것은 오히려 태도다. “AI를 위한 AI를 하지 마라. 반드시 실제 문제와 페인포인트가 있어야 한다”는 말인데, 기술을 화려하게 쓰는 게 아니라 올바른 문제를 고르는 능력이 AI PM의 출발점이라는 뜻이다.

AI PM이 되려면 무엇부터 준비할까

포트폴리오 한 건부터다. 채용 담당자가 보는 것은 완성된 경력이 아니라 “AI PM이 될 수 있는 사고방식의 증거”다. 핵심 원리는 단순하다. 시도하고, 실패하고, 거기서 배운 걸 글로 남기는 것이다.

무엇을 만들지 감이 안 온다면, 아래 세 가지가 실제로 통하는 사례다.

포트폴리오 아이디어	무엇을 보여주나
FAQ 기반 RAG 챗봇으로 환각률 12%→3% 개선	확률적 출력의 품질을 숫자로 관리한 경험
노션 데이터 기반 GPT 요약 도구에서 토큰 비용 5배 급증 문제 해결	비용·성능 트레이드오프를 다룬 시스템 사고
AI 코딩 도구의 코드 채택률을 부서별로 분석한 리포트	데이터로 도입 효과를 판단하는 감각

여기서 한 단계 더 나아가면 상위 AI PM으로 갈린다. 기술 지표를 비즈니스 언어로 번역하는 능력이다. 예를 들어 “정확도를 8%에서 3%로 개선했다”에서 멈추지 않고, 그게 전환율을 얼마나 끌어올렸는지 연결해 설명할 수 있어야 한다. AI 정확도라는 숫자를 매출·이탈 같은 회사가 알아듣는 지표로 바꾸는 것이다.

이런 경험이 왜 희소한지는 시장 데이터가 보여준다. 실제 서비스 단계까지 가는 AI 프로젝트는 48%에 불과하고, 30%는 개념 검증 단계에서 폐기된다(What Does an AI PM Do?, Reforge). 확률적 시스템을 끝까지 다뤄 배포해본 경험 자체가 드문 자산이라는 뜻이다.

(AI 시대에 어떤 스킬이 대체되고 어떤 스킬이 더 가치 있어지는가, 출처: How AI will impact product management — Lenny Rachitsky)

흥미로운 역설도 있다. Lenny Rachitsky는 AI가 단순 실무보다 전략·비전 같은 고차원 업무에 더 큰 영향을 준다고 본다. AI가 실행을 맡을수록, 팀을 조율하는 ‘지휘자’ 역할이 오히려 핵심이 된다는 것이다. 기계가 손발을 대신할수록 사람의 판단과 방향 잡기가 더 비싸진다. AI PM 준비가 프롬프트 기술이 아니라 판단력으로 향해야 하는 이유가 여기 있다.

지금 시작하는 실천 계획

준비를 세 단계로 쪼개면 막막함이 줄어든다. 지금 당장, 몇 달 안에, 그 이후로 나눠 본다.

시점	할 일
지금	확률적 시스템(RAG 챗봇·간단한 Eval 파이프라인) 한 건을 직접 만들고, 실패와 학습을 글로 기록한다
지금	주변의 실제 불편함을 관찰하는 루틴을 만든다 — 기술이 아니라 문제에서 출발한다
몇 달 안	Evals 설계를 익힌다 — 좋은 출력의 기준을 숫자로 세우는 연습
이후로	에이전트·멀티모달 같은 흐름을 월 1회라도 추적하는 습관을 붙인다

가장 흔한 실수는 이론만 공부하는 것이다. 책과 강의로 개념을 아무리 쌓아도, 확률적 시스템을 실제로 배포해본 기록 하나를 못 이긴다. 완벽한 결과물이 아니어도 된다. 오히려 “여기서 이렇게 막혔고, 이렇게 돌아갔다”는 과정이 사고방식의 증거가 된다.

정리

AI PM 커리어를 준비한다면 세 가지만 기억하면 된다. 첫째, 진입 장벽은 학위가 아니라 확률적 시스템을 다뤄본 증거다. 둘째, 시장이 사는 건 프롬프트 기술이 아니라 협업·전략·데이터 판단력이다(요구율 32%·29%·27% vs 9%). 셋째, 이론이 아니라 직접 만들고 실패를 기록한 포트폴리오 한 건이 열쇠다.

세 가지가 한 방향을 가리킨다. AI가 실행을 대신할수록, 무엇이 좋은 결과인지 정의하고 팀을 올바른 문제로 이끄는 인간의 판단이 더 비싸진다. AI PM은 그 판단을 확률과 함께 설계하는 직무다. 코딩 강의부터 결제하기 전에, 작은 확률적 시스템 하나를 오늘 만들어보는 편이 그 자리에 훨씬 가깝다.

한가지를 집고 넘어가고 싶다. 지금까지 이야기한 AI PM은 AI 경험을 설계하는 쪽에 가깝다. 실제 AI 모델자체를 담당하거나 AI 플랫폼을 만들고 있다면 조금 다른 접근이 필요 할 수도있다.

---

참고 자료

1. The State of AI Product Management (Aakash Gupta) — 2025-11
2. Market Insights from 592 AI Product Management Jobs (axialsearch) — 2025
3. Agents, robots, and us: Skill partnerships in the age of AI (McKinsey MGI) — 2026
4. How AI will impact product management (Lenny Rachitsky) — 2026
5. AI and product management — Marily Nika (Lenny’s Podcast) — 2026
6. What Does an AI PM Do? (Reforge) — 2026
7. AI PM의 커리어를 설계하라 (요즘IT, 김영욱) — 2026
8. To Drive AI Adoption, Build Your Team’s Product Management Skills (HBR) — 2026-02-03

함께 읽으면 좋은 글

AI PM의 새로운 필수 역량: AI Eval (평가)PRD를 대체한다는 그 Evals, 실제로 어떻게 설계하는지 한 걸음 더 들어간다.