채용 사이트를 열 때마다 "AI PM" 공고가 눈에 띄게 늘었다. 잡코리아에서 검색하면 700건이 넘는 공고가 뜬다. 그런데 공고를 하나하나 열어보면 묘한 점을 발견한다. 같은 타이틀인데 하는 일이 전혀 다르다.
같은 타이틀, 전혀 다른 JD
어떤 회사는 LLM 기반 챗봇 기획을 원하고, 어떤 회사는 추천 시스템 고도화를 원하고, 또 어떤 곳은 기존 서비스에 GPT API를 붙이는 걸 "AI 프로덕트"라고 부른다. 타이틀은 같은데 실제 업무 범위가 회사마다 완전히 다르다.
한 스타트업의 공고를 보면 우대사항에 "PyTorch 경험"이 들어가 있고, 대기업 공고에는 "MLOps 파이프라인 이해"가 적혀 있다. 반면 어떤 곳은 일반 PM 공고에 "AI에 대한 관심"만 한 줄 추가한 수준이다. 결국 이 타이틀이 업계 표준 없이 각자 편의대로 쓰이고 있는 셈이다.
문제는 지원자도 면접관도 서로 다른 그림을 그린다는 거다. 면접장에서 "AI 프로덕트 경험 있으시죠?"라는 질문에 지원자는 프롬프트 엔지니어링을 떠올리고, 면접관은 모델 학습 데이터 큐레이션을 기대하고 있을 수 있다. 그래서 이 포지션에 관심이 있다면, 합류 전에 반드시 확인해야 할 것들이 있다.
모델을 직접 다루는 건가, 감싸는 건가
첫 번째 질문이다. 모델 자체의 성능을 책임지는 역할인지, 아니면 모델이 내뱉는 결과물을 사용자에게 좋은 경험으로 전달하는 역할인지. 둘은 하루가 완전히 다르게 돌아간다.
| 모델 중심 | 서비스 레이어 중심 | |
|---|---|---|
| 일상 업무 | ML 엔지니어와 메트릭 리뷰, 데이터셋 검수 | UX 설계, 에러 핸들링, 프롬프트 튜닝 |
| 핵심 역량 | precision-recall 트레이드오프, 데이터 파이프라인 감각 | 사용자 기대치 관리, 할루시네이션 대응 |
| 리스크 | 모델 성능 미달 시 PM 책임론 | 모델은 괜찮은데 UX에서 가치 전달 실패 |
모델 중심 포지션이면 ML 배경이 사실상 필수고, 서비스 레이어 중심이면 기존 PM 역량에 인공지능 특성 이해를 얹는 형태다. 이 구분 없이 채용하면 입사 후 미스매치가 거의 확정된다.
불확실성을 조직이 감당할 준비가 되어 있는가
두 번째로 물어봐야 할 건 조직 문화다. 인공지능 프로덕트의 가장 큰 차이는 아웃풋이 결정적(deterministic)이지 않다는 것이다. 같은 인풋에도 다른 결과가 나올 수 있고, 모델을 업데이트할 때마다 사용자 경험이 미묘하게 바뀐다.
기존 프로덕트 개발에서는 "이 기능을 만들면 이렇게 동작한다"가 명확했다. 로드맵도 상대적으로 예측 가능했다. 반면 모델 기반 서비스는 "이걸 적용하면 아마 이 정도 성능이 나올 것이다"에서 출발한다. 아마. 이 단어가 핵심이다.
조직이 이 불확실성을 받아들일 준비가 안 되어 있으면, 해당 포지션의 PM은 끊임없이 "왜 일정이 밀리냐", "왜 결과가 매번 다르냐"는 질문을 받게 된다. C레벨이 "우리도 해야 한다"고 해서 포지션을 열었는데, 실험 문화 없이 워터폴 방식으로 운영하면 그 사람은 6개월 안에 소진된다.
면접에서 "실험이 기대한 결과를 못 냈을 때 팀이 어떻게 반응했는가"를 꼭 물어보길 권한다. 대답이 구체적이면 좋은 신호다. "그런 적은 없었다"라고 하면 빨간불이다 — 실험을 안 해봤거나, 실패를 인정하지 않는 조직이라는 뜻이니까.
이 자리가 정말 프로덕트 매니저인가
프로덕트 매니저와 프로젝트 매니저의 차이는 오래된 얘기지만, 이 영역에서 경계가 다시 흐려지고 있다. "도입 프로젝트"를 관리하는 건 프로젝트 매니지먼트에 가깝고, "모델 기반 서비스에서 사용자 가치를 발견하고 검증하는 것"은 프로덕트 매니지먼트다.
채용 공고에서는 이 구분이 거의 없다. 실제로 들어가보면 "GPT 연동 일정 관리"를 시키는 곳이 있고, "우리 서비스에서 어떤 문제를 풀어야 하는지 정의하라"는 곳이 있다. 어느 쪽이든 의미 있는 일이다. 다만 본인이 원하는 게 뭔지는 알고 들어가야 한다.
화려한 키워드에 끌리기 전에, 그 뒤에 어떤 일상이 있는지를 먼저 파악하자. 매일 아침 노트북을 열었을 때 실제로 마주할 업무가 타이틀보다 훨씬 중요하다.