"기획도 AI가 하는데, PM이 왜 필요해요?" 요즘 회사는 PM에게 무엇을 원할까
PM·PO 채용공고 133건을 읽고 AI 시대에 달라진 PM의 역량을 살펴봤습니다. AI 초안을 거르고, 결정의 근거를 남기고, 기획서로 직접 만들어 보는 연습을 제안합니다.
“기획도 AI가 해 주는데, PM이 왜 필요한 거 같으세요?”
얼마 전 한 취업 커뮤니티를 보다가
PM(Project Manager) 신입을 뽑는 면접 자리에서
이런 질문을 받았다는 글을 봤습니다.
일단 본문을 다 읽기도 전에 댓글창부터 열었죠.
댓글을 하나씩 넘기다보니
“결국 결정은 사람이 해야 한다 Human-Decision이 중요하다”
“기획에 포함된 세세한 맥락은 AI가 모른다”
같은 답이 달려 있었는데,
하나씩 읽다 보니 같은 말을 할 수는 있는데
타당한 논리나 근거는 없겠다는 생각이 들었습니다.
그래서 PM 역량을 다룬 책을 찾아 봤어요.
국내 IT 기업과 스타트업에서 PM으로 일해 온 사람들이 꼽은 역량은 이랬습니다.
글쓰기와 말하기, 오너십, 영어, 호기심과 배우는 자세, 다양한 사람과 맞는 성격.
눈에 띄는 게 하나 있는데,
이 목록에는 AI라는 단어가 단 한 번도 나오지 않습니다.
그래서 글도 글이지만 요즘 채용 사이트에 올라온
채용공고까지 읽어 보기로 했습니다.
채용공고는 보통 회사가 작성할 것이고
이런 사람이 우리 회사에 들어왔으면 좋겠다고 정리한 글일테니
어떤 역량이 가장 중요하다고 생각하는지 가장 솔직하게 썼을 것이라고 생각했습니다.
이번 글에서는 그 결과를 정리해 보겠습니다.
PM에게 요구되는 능력 목록이 바뀐 게 아니라,
그 목록 안에서 무엇이 싸졌고, 무엇이 비싸졌고, 무엇이 새로 생겼는지를요.
역량 목록은 그대로입니다
먼저 예전 목록부터 꺼내 볼게요.
국내 IT 기업과 스타트업에서 PM과 PO로 일해 온 9명이 함께 쓴
《프로덕트 매니저 원칙》은 시작하는 PM에게 필요한 스킬로 다섯 가지를 꼽습니다.
글쓰기와 말하기, 오너십, 영어, 호기심과 배우는 자세, 다양한 사람과 맞는 성격.
출처: 이상범 외 8명, 《프로덕트 매니저 원칙》, 골든래빗, 2023
지금 읽어도 의심의 여지가 없고 고개가 끄덕여지는 목록입니다.
그런데 2026년 채용공고를 열어 보면, 이 목록으로는 설명이 안 되는 문장들이 나옵니다.
채용공고 133건을 읽어 봤습니다
2026년 10월 12일 기준으로 원티드에 올라와 있는
PM·PO 직군 공고 중 최신 200건을 받아,
제목이 PM, PO, 프로덕트 매니저, 서비스 기획자인 것만 봤습니다.
그리고 주요 업무, 자격 요건, 우대 사항에
어떤 문구가 들어 있는지만 집중적으로 확인했습니다.
앞부분은 예전 목록 그대로입니다.
커뮤니케이션과 협업은 133건 중 121건(91%)에 있었고,
기획서, 요구사항, 화면 설계 같은 문서 작업은 100건 안팎(75~80%),
우선순위와 의사결정은 90건(68%), 데이터와 지표는 90건 안팎(67~69%)이었습니다.
여기서부터가 예전 목록에 없던 줄입니다.
AI를 업무 도구로 쓴 경험을 묻는 공고가 69건(52%)이었습니다.
자격 요건에 적은 곳이 26건, 우대 사항에 적은 곳이 52건이에요.
직접 만들어 본 경험을 묻는 공고는 28건(21%),
Cursor나 Claude Code 같은 AI 코딩 도구를 이름까지 적은 공고가 13건(10%),
AI가 만든 결과물을 검증하라는 문구가 들어간 공고도 13건(10%)이었습니다.
실제 문장은 이렇습니다.
“Claude Code 등 AI 도구를 업무에 적극 활용하는 분”
“AI 개발 도구를 활용하고 결과를 직접 검증할 수 있는 분”
“직접 만들어 운영해 본 사이드 프로젝트나 개인 제품이 있는 분”
표를 보면 아직 ‘있으면 좋은 것’ 단계입니다.
AI 도구 활용은 자격요건 보다 우대 사항에 두 배 많으니까요.
그런데 당장 몇 년 전 공고에는 아예 존재 조차도 없던 문장들입니다.
값이 내려간 능력: 쓰는 일
기획서와 요구사항 문서는 여전히 공고의 75~80%에 들어 있습니다.
그 뜻은 문서화가 아직 중요하긴 하다는 것이죠.
가장 크게 바뀐 부분을 꼽자면
쓰는 일은 AI로 하는 게 디폴트지만,
무엇을 쓸지 정하는 일이 사람 몫으로 남았습니다.
예를 들어 "첫 구매 쿠폰 기획서 써 줘"라고 하면,
AI는 한 5분 만에 목차와 화면 흐름까지 갖춘 초안을 내놓습니다.
그런데 쿠폰을 다른 할인과 중복으로 쓸 수 있는지,
재가입한 사람도 첫 구매로 볼지는 AI가 그럴듯하게 골라 적어 둘 뿐이에요.
그걸 우리 회사 상황에 맞게 정하는 일은 여전히 사람이 합니다.
Lenny’s Newsletter가 2025년 12월 테크 업계 종사자 1,750명에게 물었을 때,
PM이 AI를 가장 많이 쓰는 일 1위가 PRD 초안 작성(21.5%)이었습니다.
초안을 AI가 내는 시대에 “기획서를 잘 쓴다”는 더 이상 차별이 아닙니다.
대신 AI가 낸 초안에서 어디가 틀렸는지 아는 게 능력이 됐어요.
값이 올라간 능력: 정하는 일과 거르는 일
채용공고에서 우선순위와 의사결정은
자격 요건 기준으로 커뮤니케이션 다음으로 많았습니다(70건).
AI가 많이 만들수록 무엇을 안 만들지 정하는 사람이 중요해지니까요.
그리고 하나가 더 올라갔습니다.
그건 바로 AI 산출물을 거르는 눈이에요.
공고에 “결과를 직접 검증할 수 있는 분”이라는 문구가 들어가기 시작했고,
아답타비스트가 2026년 7월 지식 근로자 2,500명에게 물었을 때
42%는 AI로 아낀 시간보다 결과물을 검증하는 데 더 많은 시간을 쓰고 있고,
52%는 동료가 AI로 만든 산출물을 고친 적이 있다고 답했습니다.
Lenny’s Newsletter의 2026년 조사에서도
AI에 일자리를 뺏길까 걱정하는 응답은 22%뿐이었지만,
결과물의 품질이 떨어질까 걱정하는 응답은 41%였습니다.
AI가 평균을 내면, 평균에서 벗어나는 결정은 사람이 합니다.
그 결정을 할 수 있다는 걸 보여 주는 게 지금 PM의 능력이에요.
새로 생긴 능력: 만들어서 보여 주기
직접 만들어 본 경험 21%, AI 코딩 도구 10%.
숫자는 아직 작습니다. 그런데 이건 2년 전 공고에는 아예 없었던 항목입니다.
해외는 더 갔습니다.
Amazon Ring의 PM 공고는 직함이 “Senior Product Manager, Builder”이고,
자격 요건에 AI 코딩 도구로 직접 프로토타입을 만든 경험을 적어 뒀습니다.
Cursor의 PM 공고에는 이런 문장이 있어요.
“Product at Cursor is not a traditional PM org. PMs here are technical builders.
You should be able to build and deploy an app yourself.”
-> 커서의 프로덕트 조직은 전통적인 PM 조직이 아니고,
이곳의 PM은 직접 만드는 사람이니 앱을 혼자 만들고 배포할 수 있어야 한다는 뜻입니다.
LinkedIn은 오래 운영해 온 신입 PM 프로그램(APM)을 없애고,
코딩, 디자인, PM을 함께 가르치는 Associate Product Builder 프로그램으로 바꿨습니다.
ProductPlan의 「State of Product Management 2026」 조사에서는
제품 직군 응답자의 73.4%가 PM 역할이 디자인, 엔지니어링과 섞인 형태로 갈 거라고 답했어요.
거리감은 정확히 봐야 합니다.
국내는 우대 사항에 들어오기 시작했고, 해외 빅테크는 직함을 바꿨습니다.
기획서를 결과물로 내던 시절에서, 기획서로 만든 것을 결과물로 내는 시절로 가고 있어요.
그럼 이렇게 한 번 해보는 건 어떨까요?
아래 내용을 수행하고 포트폴리오를 강화한다고 해서 채용이 보장되는 것은 아닙니다.
다만 채용공고가 PM에게 묻는 능력이 무엇인지 살펴본 만큼,
실무에서 그 능력을 어떻게 연습해 볼 수 있을지 제안을 드려 보려 합니다.
지금까지 조사 및 정리한 내용을 요약하자면
채용공고에서 대략적으로 묻는 건 세 가지입니다.
AI가 만든 결과물을 보고 회사와 프로젝트 상황에 맞지 않는 부분을 걸러낼 수 있는지.
AI가 내놓은 여러 선택지 중에서 지금 만들 것과 뺄 것,
나중으로 미룰 것을 근거를 갖고 정할 수 있는지.AI를 활용해 기획부터 실제로 돌아가는 결과물까지 직접 만들어 볼 수 있는지.
셋 다 따로 시간을 내서 배우면 물론 좋겠지만,
지금 하고 계시는 개인/사내 프로젝트 기획의
순서를 조금 바꾸는 것만으로 연습할 수 있다고 생각합니다.
1. 거르기: AI가 대신 정해 버린 것부터 찾기
AI 초안을 검토할 때는 문장이 매끄러운지보다
AI가 임의로 정한 값이 어디 있는지를 먼저 봐야 합니다.
위에서 잠깐 얘기했던 쿠폰 예시라면 이런 것들이에요.
정책: 다른 할인과 중복으로 쓸 수 있는가, 재가입자도 첫 구매로 보는가
수치: 할인 폭은 10%인가 5,000원인가, 유효 기간은 며칠인가
범위: 앱에서만 쓰는가, 웹에서도 쓰는가
기존 기능과의 관계: 이미 있는 멤버십 할인과 부딪히지 않는가
AI는 이런 항목을 비워 두지 않고 그럴듯한 값으로 채웁니다.
그래서 검토할 때는 이 값들에 표시를 해 두고,
하나씩 "우리가 정한 값인지, AI가 고른 값인지" 확인하는 게 첫 단계예요.
고친 곳에는 이유를 한 줄 남겨 두면, 다음에 비슷한 기능을 기획할 때 그대로 검토 기준이 됩니다.
2. 정하기: 결정과 함께 이유와 뺀 것까지 남기기
AI가 선택지를 늘려 줄수록, 무엇을 고르고 무엇을 제외하는지가 PM의 일이 됩니다.
결정을 남길 때는 결과만 적지 말고 네 가지를 같이 적어 보세요.
결정: 첫 구매 쿠폰은 다른 할인과 중복 사용 불가
이유: 중복 시 첫 주문 마진이 마이너스가 됨
검토했지만 뺀 것: 금액 상한을 둔 중복 허용안
근거: 10월 2일 회의, 지난 분기 프로모션 데이터
이렇게 남겨 두면 몇 주 뒤 "이건 왜 이렇게 했어요?"라는 질문에
기억이 아니라 기록으로 답할 수 있습니다.
특히 첫 출시에서 뺀 기능 목록은,
무엇을 안 만들지 판단한 흔적이라 다음 우선순위 논의의 출발점이 돼요.
3. 만들기: 기획서로 직접 확인해 보기
아무리 바이브코딩.. 바이브코딩 거려도 어떻게 서비스까지 직접 만들지?
개발자 만큼 개발 지식을 익히고 배우라는 얘기가 아닙니다.
정리한 기획서를 Cursor나 Claude Code 같은 AI 코딩 도구에 넘겨,
화면 하나라도 실제로 기획서에서 의도한대로 돌아가게 만들어 보세요.
핵심은 결과물의 완성도가 아니라 기획서와 결과물이 어디서 다른지 확인하는 것입니다.
쿠폰 화면을 만들어 봤더니 할인 금액이 결제 직전에만 보인다면,
기획서에 "할인 금액은 언제부터 보여 줄지"가 정해져 있지 않았다는 뜻이에요.
여기서 한 걸음 더 나아가, 개발자가 꼭 확인해야 할
예외 상황까지 기획서에 적어 두면 더 좋습니다.
예를 들어 결제 도중 쿠폰 기한이 끝나면 어떻게 할지,
주문을 취소하면 쿠폰을 돌려줄지 같은 것들이죠.
마무리하며
위 세 단계는 노션이나 구글 문서로도 해 볼 수 있습니다.
다만 해 보면 금방 알게 됩니다.
AI 초안, 고친 기록, 결정 이유, AI 코딩 도구에 넘길 기획서가
전부 다른 곳에 흩어진다는 걸요.
매니패스트는 이 세 단계를 한 프로젝트 안에서 이어 갈 수 있는 기획 워크스페이스입니다.
거르기: 아이디어 한 줄을 넣으면 AI가 PRD부터 기능명세서, 유저플로우, 와이어프레임까지 초안을 만들고, 무엇을 고쳤는지는 작업 로그에 전후 비교로 남습니다.
정하기: 팀 프로젝트 회의록을 올리면 확정, 미정,
기각된 결정이 나뉘어 기획서에 반영되고, 결정마다 근거가 붙어요.
만들기: MCP로 Cursor나 Claude Code를 연결하면,
AI 코딩 도구가 그 기획서를 그대로 읽고 화면을 만듭니다.
그래서 AI 초안을 거르고, 결정을 남기고,
결과물로 확인하는 과정이 하나의 기획서 안에서 이어집니다.
