AI가 프로토타입을 90개 뽑을 때, PM의 일은 무엇인가
AI가 프로토타입을 분 단위로 생성하는 시대에 PM의 병목은 더 이상 '구현'이 아니다. 메르카리·LangChain·Anthropic이 동시에 가리키는 방향: 선택과 검증이 PM의 새로운 핵심 업무다.
AI가 하루에 프로토타입을 90개 뽑아낼 수 있다면, PM이 해야 할 일은 무엇인가.
이 질문이 최근 6개월 사이 PM 커뮤니티에서 실제로 논의되기 시작했다. 추상적인 미래의 이야기가 아니다. Anthropic의 Claude Code는 이미 주간 40만 세션을 기록 중이고, 그 사용자의 상당수는 개발자가 아닌 PM과 기획자다. 코딩 에이전트에 주 20시간을 쓰는 비개발 직군이 늘고 있다. 이 숫자가 말하는 것은 “코딩이 쉬워졌다”가 아니다. 구현 병목이 서서히 사라지고 있다는 신호다.
구현이 공짜에 가까워질 때, 병목은 어디로 가는가
경제학의 기본 원리다. 희소성이 사라진 자원은 경쟁 우위가 되지 않는다. AI가 구현을 맡기 시작하면, 경쟁은 ‘더 빨리 만드는 팀’에서 ‘더 잘 고르는 팀’으로 이동한다.
일본의 메르카리 NFT 팀이 이 전환을 먼저 실험했다. AI-Native 팀을 구성하면서 그들이 내린 첫 번째 결정은 하네스(hooks, 권한, 샌드박스)를 직접 만들지 않는 것이었다. 기존 플랫폼에서 빌려 쓰고, 팀이 직접 구축해야 할 것은 하나뿐이었다.
판단 기준 문서.
“어떤 결과가 좋은 결과인가.” “어떤 경우에 AI의 판단을 수용하고, 어떤 경우에 사람이 개입해야 하는가.”
이 기준이 없으면 팀은 AI 출력물을 검토 없이 통과시킨다. 검증이 생략된 자동화는 빠른 실수의 공장이 된다.
”2026년은 Eval의 해다”
LangChain의 Harrison Chase는 올해 초부터 같은 메시지를 반복하고 있다.
“2026 is the year of evals.”
단순한 슬로건이 아니다. LangSmith 운영 데이터에서, eval을 체계적으로 운영하는 팀이 그렇지 않은 팀보다 프로덕션 전환율에서 유의미한 차이를 보인다. Eval이란 결국 “이 AI 출력이 충분히 좋은가”를 판단하는 기준과 반복 루프다. 이 기준을 설계하는 것이 PM의 일이다.
과거 PM은 사용자 스토리를 쓰고 기능 우선순위를 정했다. 이제 PM이 작성해야 하는 문서는 평가 기준서다. “이 응답이 합격인가 불합격인가”를 정하는 문서. PRD의 무게중심이 기능 명세에서 성공 판단 기준으로 이동하고 있다.
OpenAI의 세금 처리 에이전트 케이스가 이를 잘 보여준다. 6주 만에 정확도를 25%에서 86%로 끌어올린 비결은 모델을 교체한 것이 아니었다. 정정 로그 수집, 반복 오류 태깅, eval set 축적이었다. PM이 이 운영 루프를 만들지 않으면 에이전트는 영원히 프로토타입 상태로 머문다.
구현 < 선택 < 검증: 실제로 어떻게 달라지나
Claude Code나 Codex를 도입한 팀들이 공통적으로 빠지는 함정이 있다. AI가 코드를 생성하면 바로 배포한다. 검토를 생략한다. 속도가 너무 빠르니까.
그러나 Anthropic 데이터에 따르면 에이전트 루프에서 고복잡도 작업은 단순 작업 대비 약 2배의 토큰을 사용한다. 토큰은 곧 비용이다. 검증 없이 넘어간 배포는 나중에 더 큰 수정 비용을 만든다.
AI 시대 PM이 해야 할 일은 세 단계로 정리된다.
1단계: 선택 기준을 먼저 쓴다
프로토타입 90개 중 어느 것을 고를 것인가의 기준. 이것 없이 AI에게 “만들어달라”고 하면 팀은 모든 결과를 하나씩 검토하게 된다. 그게 새로운 병목이다. 기준이 명확한 팀은 AI 출력의 70%를 자동으로 걸러낼 수 있다.
2단계: 검증 경계를 설계한다
AI가 배포하기 전에 어디서 사람이 개입하는가. 메르카리가 선택한 원칙처럼 “근거가 없으면 멈추는” 가드레일이 에이전트 성능 지표보다 더 중요한 설계 요소다. 이 경계를 정하는 사람이 PM이다.
3단계: 실패를 자산으로 수집한다
AI가 틀린 결과를 낸 경우, 그 패턴을 문서화하고 eval set에 추가한다. 이 루프가 없으면 팀은 같은 실수를 반복한다. 에이전트의 성능이 정체된 것처럼 느껴지는 원인의 상당수는 이 루프가 빠진 데 있다.
GTM AI가 성과를 내지 못하는 진짜 이유
최근 AI 도구를 도입한 팀들의 성과가 기대에 미치지 못한다는 분석이 반복되고 있다. 진단은 일치한다. 도구는 바꿨는데 워크플로우와 책임 구조가 그대로다.
AI가 구현 속도를 높인다고 해서 팀의 성과가 자동으로 오르지 않는다. 판단의 질이 성과를 결정한다. 판단 기준이 없는 팀에서 빠른 AI는 빠른 오류를 만들 뿐이다.
AI 시대 PM에게 가장 먼저 물어야 할 질문이 있다.
“우리 팀에서 ‘좋은 AI 출력’의 기준을 가장 잘 문서화한 사람은 누구인가?”
그 답이 당신이라면, 역할 전환은 이미 시작됐다. 그 답이 아무도 아니라면, 지금이 그 문서를 쓸 때다.