AI 서비스 기획자 : AI PM과 어떤 차이가 있을까요?

AI 서비스 기획자와 AI PM은 직무명만으로 선을 긋기 어렵습니다. 채용에서는 어떤 고객과 지표를 보는지, AI를 업무에 활용하는지 AI 시스템 자체를 기획하는지, 문제 정의와 기술 이해를 어디까지 요구하는지 함께 봐야 합니다. 저는 AI PM 채용공고를 직접 모아 보고 아이엠 AI PM 과정에서 공고와 서비스 기획 실습을 함께 보면서 이 차이를 확인했습니다. 일반 PM과 비교한 기준은 AI PM과 일반 PM의 차이 : 무엇을 먼저 보나요에 따로 정리했습니다.

AI 서비스 기획자 채용공고와 AI PM 공고를 직접 비교하면 어떤 차이를 확인할 수 있나요?

직접 모은 AI PM 채용공고에서는 B2B 비중이 높았고, 만드는 능력보다 모호한 문제를 정의하는 역량이 더 자주 요구됐습니다. 저는 AI PM 채용공고 39건을 모으고, 이 가운데 AI·AX 직군 34건을 따로 분류했습니다. 34건 중 B2B는 29건으로 85.3%였고, 비교군으로 넣은 그로스 PM·CX 기획 공고 5건은 모두 B2C였습니다. 같은 PM이라는 이름이 붙어 있어도 실제로 상대하는 고객부터 달랐습니다.

자격요건의 동사도 세어 봤습니다. 많이 나온 동사 열 개 가운데 만들다·개발하다 계열은 0개였고, 정의하다는 15건이었습니다. 제가 본 공고에서 AI 서비스 기획자에게 요구되는 첫 동작은 직접 만드는 일보다 모호한 요구를 말이 되게 나누는 일이었습니다. AI 서비스 기획자는 보통 이런 문제를 정의하고 서비스 구조와 기능을 구체화하면서 필요한 AI 기술을 구현 과정과 연결하는 역할로 볼 수 있습니다.

다만 이것만으로 AI 서비스 기획 공고 전체와 AI PM 공고 전체가 이렇게 다르다고 말할 수는 없습니다. 아이엠 AI PM 과정 16회차 수업에서도 AI 서비스 기획이라는 직무명은 드문 편이고, 직무 이름만으로 실제 역할을 알기 어렵다는 이야기가 나왔습니다. 그래서 AI 기획자 채용과 AI PM 차이를 볼 때는 제목보다 고객, 지표, 실제 업무 범위를 먼저 확인해야 했습니다.

AI 서비스 기획에서 화면을 역기획해 기능 명세까지 어떻게 작성할 수 있나요?

화면의 상태를 먼저 정한 뒤 UI·Logic·Data·API·Deploy 다섯 층으로 나누면 보이지 않는 규칙까지 기능 명세로 옮길 수 있습니다. 저는 2026년 8월 택시 호출 앱의 TXI-101 목적지 지정 화면을 놓고 역기획했습니다. 화면 하나를 요소 12개로 쪼갠 뒤 사용자에게 보이는 화면, 작동 규칙, 데이터, 기능을 주고받는 연결 지점, 배포까지 다섯 층으로 나눴습니다.

먼저 이 화면이 무엇을 하는 상태인지부터 판정했습니다. 호출 버튼이 없었기 때문에 호출을 실행하는 화면이 아니라 목적지 입력을 기다리는 상태로 잡았습니다. 그다음 뒤로가기를 눌렀을 때 어디로 이동하는지, 입력하던 목적지 값은 어떻게 유지하는지처럼 화면에 보이지 않는 규칙까지 적었습니다.

AI 서비스 기획자에게 필요한 기획 역량도 이런 실습으로 보여줄 수 있습니다. 화면의 상태를 판정하고 기능을 여러 층으로 나눈 뒤 구현 계획까지 이어 가는 방식입니다. 저는 명세에서 끝내지 않고 스토리보드와 구현 계획을 거쳐 단일 HTML 파일 구현까지 이어 갔습니다. AI 서비스 자체를 역기획한 실습은 아니지만, 요구를 기능과 구현 조건으로 바꾸는 과정은 직접 확인할 수 있었습니다.

AI 서비스 기획자와 AI PM의 차이는 어떤 기준으로 구분할 수 있나요?

직무 이름만 보기보다 어떤 지표를 보고 어떤 문제를 맡는지, AI를 활용하는 역할인지 AI 시스템 자체를 기획하는 역할인지로 구분할 수 있습니다. 처음에는 저도 PM·PO·기획자·BM처럼 이름이 달라지면 하는 일도 명확히 갈린다고 생각했습니다. 하지만 멘토와 이야기하면서 어느 이름을 택할지보다 어느 지표까지 볼 수 있는 사람으로 갈지를 먼저 생각하게 됐습니다.

아이엠 AI PM 과정 17회차 AI 서비스 개발 수업에서도 비슷한 구분을 배웠습니다. 수업에서는 AI를 업무에 활용하는 PM과 AI 시스템 자체를 구축하는 기획 역량을 나눠 봤고, AI 전환을 중심으로 맡는 PM과 기술적인 깊이가 더 필요한 AI PM도 따로 이야기했습니다. 그래서 AI 기획자 차이나 AI PM 차이를 볼 때 코드를 직접 구현하느냐 하나만 기준으로 삼기는 어려웠습니다.

AI 기획자와 일반 기획자의 차이도 기술을 직접 만드는 능력에서만 갈리는 것은 아닙니다. 재료에서 반복해서 나온 기준은 AI 개념을 이해하고, 모호한 요구를 정의한 뒤 개발 과정과 연결할 수 있느냐였습니다.

AI 서비스 기획을 준비하는 비개발자는 RAG, LangChain, LangGraph를 어떻게 공부할 수 있나요?

직접 구현 자체를 목표로 하기보다 채용공고에 나오는 기술의 개념을 이해하고 실습으로 서비스 구조와 작동 방식을 익히는 방향으로 공부할 수 있습니다. 저는 아이엠 AI PM 과정 17회차 수업 전까지 AI 서비스는 사용해 봤지만 RAG라는 용어는 처음 접했습니다. 수업에서는 RAG를 검색 증강 생성이라고 설명했고, 채용공고에서 보였던 LangChain과 LangGraph도 함께 학습 범위로 다뤘습니다.

제가 궁금했던 것은 이 기술을 개발자처럼 모두 구현할 수 있느냐가 아니었습니다. 공고에 이런 이름이 나왔을 때 어디까지 알아야 하는지, 실무에서 질문을 받으면 어떤 수준으로 설명해야 하는지가 더 큰 문제였습니다. 그래서 기술 이름을 외우기보다 예제와 AI를 직접 사용하면서 서비스 안에서 어떤 역할을 하는지 이해하는 쪽으로 학습했습니다.

AI 서비스 기획을 준비하는 비개발자라면 이 구분이 필요합니다. 기술을 직접 구현하는 역량과 기술 개념을 이해해 기획과 개발을 연결하는 역량은 같은 것이 아닙니다. 제가 기술을 어느 수준까지 보려고 했는지는 AI 기획자 기술 지식 : 어디까지 알아야 하나요에 따로 정리했습니다.

AI 기획자 채용 공고에서 겉보기 난이도와 실제 업무를 어떻게 구분할 수 있나요?

직무명이나 자격요건만 보지 말고 기업이 AI 서비스의 방향을 얼마나 정해 두었는지와 실제로 처음부터 서비스를 만들어야 하는지를 함께 봐야 합니다. 아이엠 AI PM 과정 16회차 수업에서는 AI 서비스 기획 공고가 겉으로는 진입 장벽이 낮아 보여도 실제 채용에서는 다르게 느껴질 수 있다는 이야기가 나왔습니다. 반대로 단순한 업무처럼 보이는 AI PM 공고가 실제로는 서비스를 처음부터 구축해야 하는 일일 수도 있었습니다.

그래서 저는 공고를 볼 때 직무 이름만 읽지 않게 됐습니다. 담당 고객이 B2B인지 B2C인지, 성과 지표가 적혀 있는지, 문제를 정의하는 역할까지 맡는지, RAG나 LangChain 같은 기술 이해를 요구하는지를 함께 봅니다. 제가 모은 공고 가운데 성과 지표 이름이 아예 없는 공고도 7건 있었고 모두 B2B·SI·컨설팅형이었습니다.

AI 기획자와 AI PM의 차이는 채용 단계에서도 이런 식으로 드러납니다. 이름 자체보다 담당 고객, 보는 지표, 기술 이해와 문제 정의의 범위를 읽어야 실제 업무에 가까워집니다.

AI 서비스 기획자와 AI PM은 결국 어떻게 구분해야 하나요?

AI 서비스 기획자와 AI PM은 이름 하나로 나누기보다 어떤 문제를 정의하고 어떤 지표까지 책임지는지, AI 기술을 어느 수준으로 연결하는지를 같이 봐야 합니다. 제가 공고 39건을 모으고 서비스 기획 실습을 해 보면서 확인한 것도 직무 이름보다 실제로 하는 일을 쪼개 보는 편이 더 정확하다는 점이었습니다.

AI 서비스 기획에서는 화면과 기능을 구체화하는 능력이 필요했고, AI PM 공고에서는 모호한 문제를 정의하고 고객과 지표를 읽는 요구가 반복됐습니다. 여기에 AI 기술을 직접 구현해야 하는지, 개념을 이해해 개발 과정과 연결하면 되는지를 확인하면 지원하려는 자리의 성격이 더 분명해집니다.

채용공고에서 실제로 반복된 역량은 AI PM 채용공고에서 가장 많이 요구하는 역량 7가지는?에서 확인할 수 있습니다.