AI PM 되는 법

AI PM은 코드를 직접 만드는 사람이라기보다 모호한 요구를 정의하고, 기능과 절차를 설계하며, 데이터를 분석해 흩어진 내용을 구조화하는 직무다. LLM과 RAG 같은 기술이 작동하고 실패하는 구조를 이해하며, 이해관계자를 조율해 AI로 실제 업무와 서비스를 바꾸는 일까지 맡는다.

AI PM 관련 공고 39건에서 가장 자주 나온 동사는 정의하다 15건, 설계하다 14건, 분석하다 9건, 구조화하다 7건이었다. 만들다와 개발하다는 상위 10위 안에 없었다.

비개발자로 시작해도 만드는 일은 가능했다. 다만 에러가 없는데 안 되는 순간, 배포 범위와 권한을 놓친 순간, 실패를 기록하지 않은 순간까지 다룰 수 있어야 했다. 이 글은 채용공고 읽기, 과정 고르기, 서비스 만들기, 막힌 자리 기록하기를 한 갈래로 묶는다.

AI PM은 무슨 일을 하나

공고에서 먼저 보인 일은 코드를 직접 만드는 일이 아니었다. 모호한 요구를 정의하고, 기능과 절차를 설계하고, 데이터를 분석하고, 흩어진 내용을 구조화하는 일이었다. 상위 네 동사가 자격요건 117개 중 38.5%를 차지했다.

우대 기술은 LLM과 LLM API 9건, RAG 8건, SQL 7건 순이었다. ChatGPT와 Claude는 각 6건이었다. 도구를 눌러 본 경험만으로는 부족하고, 그 도구가 어떤 구조에서 작동하고 왜 실패하는지 말할 감각이 필요했다.

AI PMC, AI PMDC, AI PMO처럼 비슷해 보이는 이름도 직무명만 보고 같은 자리라고 단정하기 어렵다. 제공된 기록에는 이 약어들의 뜻이나 차이를 확인할 자료가 없다. 이름보다 공고 안의 요구사항 정의, 기능 명세, 화면 설계, 우선순위 조정, 데이터 분석 같은 업무 문장을 보고 판단하는 편이 맞았다.

AI PM 채용공고는 어떻게 읽나

2026년 8월 10일 기준으로 AI·AX 직군과 비교군 공고 39건을 모았다. 이 가운데 B2B는 29건으로 74.4%였고, 6건은 회사 밖 고객이 아니라 사내 구성원을 위한 자리였다. 성과 지표 이름이 없는 공고도 7건 있었다.

AI를 쓸 줄 아는 사람보다 AI로 다른 사람의 일을 바꿔 본 사람을 찾는다는 쪽으로 읽혔다. 설득, 조율, 설명, 입증이 자격요건에 나타났고 사내 AX 자리도 있었다. 지표가 아직 없는 곳이라면 지표를 처음 정해 본 경험도 증거가 될 수 있다. 다만 이것은 공고에서 확인한 사실을 바탕으로 한 해석이다.

AI PM 채용공고는 PM이라는 이름으로만 올라오지 않았다. 서비스 기획, 기획자, Product Owner, CX, CRM, 그로스, 상품기획, 사업기획처럼 흩어져 있었다. 검색은 넓게 하고 지원 여부는 직무명보다 업무 문장으로 가르는 방식은 따로 쓴다.

신입이나 비개발자도 지원할 수 있나

39건 중 신입 지원이 가능한 공고는 6건, 개발 이해가 없어도 된다고 읽힌 공고는 10건이었다. 두 조건을 모두 만족한 공고는 3건뿐이었다. 신입 가능과 비개발자 가능은 같은 말이 아니었다.

포트폴리오를 필수로 요구한 공고는 10건이었다. 그중 절반은 완성된 결과물보다 가설, 실패, 수정 이력 같은 과정을 요구했다. 코드를 얼마나 많이 썼는지만 보여주기보다 무엇을 정의했고, 무엇을 시험했고, 왜 바꿨는지 남길 자리가 필요하다.

기존 경험도 버릴 필요는 없었다. AI 툴 평가 기준을 만든 일은 모델·툴 평가 프레임워크 설계로, 요청서 양식을 고친 일은 요구사항 수집 프로세스 재설계로 다시 부를 수 있었다. 사실을 부풀리는 일이 아니라 같은 경험을 가려는 자리의 동사로 옮기는 일이다. 경험을 재명명하는 방법은 따로 쓴다.

코딩을 몰라도 AI 서비스를 만들 수 있나

비개발자인 나도 개인 OS를 0에서 만들어 굴렸다. 2026년 5월에는 자료 1건과 사전 라벨 0개로 시작했고, 두 달 뒤에는 진행판, 대화, 구조, 기록, 사전, 항해일기, 출항까지 7개 탭이 생겼다. 21일 동안 기록된 작업시간은 329.5시간, 전체 완결도는 169개 중 181개로 93%, 사전 단어는 379개였다.

코딩을 모른다는 말과 서비스를 만들 수 없다는 말은 같지 않았다. 목표 시간을 넣고, 할 일을 끌어오고, AI가 글감 후보를 제안하고, 사람이 고르고, 초안과 발행을 나누는 흐름을 직접 설계했다. 화면과 기능보다 먼저 누가 무엇을 넣고, 무엇이 쌓이고, 어디서 사람이 판단할지를 정한 셈이다.

에러는 없는데 왜 안 될까

실제로 막힌 자리는 코드 밖에 더 많았다. 저장소를 비공개로 바꿔도 배포된 문서는 공개 상태였고, 폴더 링크는 로컬에서 열렸지만 배포 환경에서는 제대로 작동하지 않았다. 운영체제가 바뀌자 설치 과정을 처음부터 다시 확인해야 했고, Python 버전이 도구의 조건과 맞지 않는 일도 있었다.

코드가 맞아도 배포 범위, 파일 경로, 권한, 환경이 틀리면 서비스는 작동하지 않는다. 배포 폴더를 좁히고, 폴더 대신 파일 경로를 명시하고, 맥과 윈도우 설치 과정을 다시 밟고, 반복된 절차는 SOP로 뺐다.

텔레그램 봇에서는 봇에서 폰으로 가는 길만 살아 있고 반대 방향은 죽어 있었다. 다섯 번 답장했지만 봇이 하나도 받지 못했고 확인에 50분이 걸렸다. 에러 메시지가 없는 문제를 어디서부터 살필지는 따로 쓴다.

그래서 무엇부터 준비해야 하나

먼저 가고 싶은 자리의 공고를 모아 직무명보다 동사를 센다. 그다음 기존 경험을 정의, 설계, 분석, 구조화의 언어로 다시 적는다. 작은 서비스 하나를 만들며 요구사항, 실패, 수정, 검증 기록을 함께 남긴다.

나 역시 이러한 인사이트를 바탕으로, AI PM이 되기 위한 도전과 기록을 계속해서 남길 예정이다.