AI 에이전트가 코드를 대신 짜줍니다. 그렇다면 PM 역할은 줄어들까요?

많은 사람이 그렇게 생각합니다. 엔지니어 생산성이 5배 오르면, PM이 조율해야 할 일도 줄어야 한다고 봅니다.

반대입니다.

Andrew Ng은 몇 주 전 이렇게 말했습니다.

“AI가 코딩 속도를 높일수록, 무엇을 만들지 결정하는 역할이 진짜 병목이 된다.”

한 줄이지만, 이 문장이 PM의 역할 전환을 가장 정확히 정의합니다.

숫자 먼저 보겠습니다

삼성SDS AX센터가 공개한 수치가 있습니다. 에이전트 실제 도입률: 5%. 기술 파일럿은 넘쳤지만, 실제 운영까지 간 경우는 20분의 1에 불과했습니다.

같은 주 GeekNews에서 44점 압도적 1위를 기록한 글 제목이 있습니다: “최고의 직원이 최악의 관리자가 되는 이유”. 기술 기량과 조직 운영 역량은 다른 근육이라는 이야기입니다.

이 두 신호는 같은 것을 가리킵니다. 에이전트가 아무리 잘 실행해도, 무엇을 실행할지 결정하는 구조가 없으면 멈춘다.

그 구조를 설계하는 사람이 PM입니다.

하나 더. Andrew Ng이 말한 엔지니어 대 PM 비율의 변화: 8:1에서 1:1로. AI 네이티브 팀에서는 엔지니어 8명을 조율하던 PM 1명 구조가 사라진다는 이야기입니다. PM 자리가 줄어드는 것이 아닙니다. PM 한 명이 팀 전체 방향을 결정하는 핵심 역할을 맡는 구조로 바뀐다는 것입니다.

20년간 본 패턴

PM으로 20년을 일했습니다. 도구가 발전할 때마다 같은 질문을 들었습니다.

“이제 PM 없이도 되는 거 아닌가요?”

엑셀 매크로가 분석을 자동화했을 때, SaaS가 개발 속도를 단축했을 때, 노코드가 기획자도 앱을 만들게 했을 때. 그리고 이제 에이전트 코딩이 PRD 없이 작동하는 시스템을 만들어낼 때.

매번 반대가 됐습니다. 도구가 빨라질수록 “무엇을 어떤 순서로 만들지”의 판단이 팀 성과를 더 크게 결정했습니다.

에이전트 시대도 구조는 같습니다. 다만 속도가 달라졌습니다. 잘못된 방향을 빠르게 가는 것, 이제 며칠 안에 일어납니다.

기술이 아니라 설계 문제입니다

에이전트 도입이 5%에 머무는 이유가 기술 부족 때문이라고 생각하면, 잘못 보고 있는 겁니다.

GeekNews에서 10점을 받은 글의 제목: “병목은 결코 코드가 아니었다”. 이 글이 말하는 병목은 개인 생산성이 아니라 팀 의사결정 구조입니다.

에이전트가 PR을 올립니다. 누가 검토합니까? 에이전트가 A/B 테스트를 설계합니다. 누가 평가 기준을 잡습니까? 에이전트가 고객 이메일에 답변합니다. 누가 실패 케이스를 정의합니까?

이 결정들 중 어느 하나라도 비어 있으면, 에이전트 팀 전체가 막힙니다.

이것이 PM의 새 역할이 생기는 지점입니다. 기능을 정의하는 것이 아니라, 판단 구조를 설계하는 것.

세 가지 전환

문서 작성자 → 평가 설계자

PRD를 잘 쓰는 것보다, 에이전트가 만든 결과물을 어떻게 평가할지가 더 중요해졌습니다.

실제 학술 데이터로 봐도 그렇습니다. CLAUDE.md를 팀에 도입했을 때 작업 시간이 28% 줄었다는 논문과, 오히려 비용이 20% 늘고 정확도가 떨어졌다는 논문이 같은 시기에 나왔습니다.

어느 쪽이 맞냐고요? 둘 다 맞습니다. 작업 유형에 따라 다릅니다. 이것이 PM이 설계해야 하는 것입니다. 어떤 작업에 에이전트를 쓰고, 어떤 기준으로 성과를 판단할지. 평가를 설계하지 않으면, 도구 도입 자체가 도박이 됩니다.

기능 관리자 → 에이전트 오케스트레이터

“최고의 직원이 최악의 관리자가 된다”는 GeekNews 1위 글의 핵심은 개별 기량과 조직 운영 역량이 다른 근육이라는 것입니다.

에이전트도 같습니다. 잘 학습된 에이전트 하나가 있다고 해서, 그 에이전트들이 팀으로 잘 동작하는 건 아닙니다. 역할 정의, 실패 처리, 결재 구조. 이것을 설계하는 것이 PM의 일입니다.

Karpathy의 말을 빌리면: “사고는 위임할 수 있어도, 이해는 위임할 수 없습니다.” 에이전트에게 실행을 넘길 수 있어도, 무엇을 실행할지의 이해는 PM이 가지고 있어야 합니다.

기술 지표 → 비즈니스 성과 측정

SAS가 글로벌 기업들을 대상으로 확인한 결과: 기술 지표만으로는 AI 예산을 확보하지 못합니다.

정확도, 벤치마크, 응답 속도. 이것으로는 안 됩니다. 경영진이 보는 것은 시간 절감, 비용 감소, 매출 기여입니다. PM이 이 번역을 직접 해야 합니다. 번역 능력이 없으면, 아무리 좋은 에이전트를 만들어도 예산을 계속 받을 수 없습니다.

PM이 지금 해야 할 세 가지

첫째, 평가 기준을 먼저 설계하십시오. Spec을 쓰기 전에 Eval을 먼저 잡으십시오. “이 에이전트가 성공한 상태는 어떤 상태인가?”를 정의하지 않으면, 나중에 아무것도 판단할 수 없습니다. Andrew Ng이 JetBrains와 함께 진행하는 Spec-Driven Development 강의에서 반복하는 것도 이것입니다. PRD가 에이전트의 인터페이스가 되려면, 의도의 정확한 명세가 선행되어야 합니다.

둘째, 에이전트 팀의 의사결정 구조를 설계하십시오. 어떤 결정을 에이전트가 하고, 어떤 결정은 사람이 하는지 명확히 정의하십시오. 이것이 비어 있으면, 에이전트가 아무리 많아도 병목은 사라지지 않습니다. 잘하는 에이전트를 좋은 오케스트레이터로 착각하는 순간, 조직이 무너집니다.

셋째, ROI를 작업 단위로 측정하십시오. 전체 생산성 향상이 아니라, 어떤 작업에서 얼마나 줄었는지 분해해서 봐야 합니다. CLAUDE.md 논문 모순이 보여주는 것처럼, 도구의 효과는 작업 유형에 따라 정반대일 수 있습니다. 분해하지 않으면 잘못된 도구를 옳은 곳에 쓰고 있다고 착각합니다.

정리

“에이전트가 코드를 짜주면 PM 역할은 줄어든다”는 생각은 직관적입니다. 그러나 틀렸습니다.

코딩이 자동화될수록, 무엇을 만들지의 결정이 성과를 더 크게 결정합니다. 빠른 엔진이 생기면, 방향이 더 중요해집니다.

Andrew Ng이 확인한 것은 이것입니다. 8:1이 1:1이 되는 것은 PM이 사라지는 것이 아닙니다. PM 한 명이 팀 전체 방향의 핵심 결정자가 되는 구조로 바뀌는 것입니다.

병목은 코드가 아닙니다. 무엇을 만들지 결정하는 구조입니다.

당신의 팀에서 지금 병목은 어디에 있습니까? 코드인가요, 아니면 무엇을 만들지 결정하는 과정인가요?