코딩이 10배 빨라지면 PM의 일이 줄어들 것 같습니다.

실제로는 반대입니다.

Andrew Ng은 지난 4월 트윗 한 줄로 이 역설을 정리했습니다. “AI가 코딩 속도를 높일수록, 무엇을 만들지 결정하는 역할이 진짜 병목이 된다.” 세계적 AI 교육자가 6주 연속 같은 메시지를 반복한 건 우연이 아닙니다.

그의 다음 발언이 더 구체적이었습니다. AI 네이티브 소프트웨어 팀에서 엔지니어:PM 비율이 8:1에서 1:1로 이동하고 있다고. 코딩을 담당하는 AI가 들어올수록 무엇을 만들지 결정하는 사람의 가치가 올라간다는 뜻입니다.

세 방향에서 수렴하는 신호

전혀 다른 출처에서 같은 결론이 나오고 있습니다.

Karpathy의 두 그룹 구분: Andrej Karpathy는 에이전틱 엔지니어링에 대해 이렇게 말했습니다. “Vibe coding raises the floor. Agentic engineering raises the ceiling.” 바이브 코딩은 누구나 뭔가 만들 수 있게 합니다. 에이전틱 엔지니어링은 진짜 잘하는 사람이 더 높이 올라가게 합니다. 그 “높이”는 코딩 속도가 아닙니다. 무엇을 만들지, 어떻게 검증할지를 설계하는 능력입니다.

같은 발언에서 그는 한 줄을 더 추가했습니다. “You can outsource your thinking, but you cannot outsource your understanding.” 사고는 위임할 수 있습니다. 이해는 위임할 수 없습니다. 이 한 줄이 PM의 새 역할 정의입니다.

GeekNews의 집단 판단: 코딩 에이전트를 실제로 운영해본 사람들의 경험을 모은 글이 GeekNews에서 10포인트를 받았습니다. 제목은 “병목은 결코 코드가 아니었다”였습니다. 기능 속도는 올랐습니다. 그러나 팀의 의사결정 구조, 우선순위 설정, 요구사항 명확화가 더 큰 병목으로 부상했다는 내용입니다. 이것은 1인의 의견이 아니라, 에이전트를 실전에서 써본 사람들의 집단 수렴입니다.

hwchase17의 선언: LangChain CEO Harrison Chase는 “2026 is the year of evals”라고 명시했습니다. 에이전트 자율성을 높이는 것보다 평가, 관측, 피드백 루프 설계가 먼저라는 뜻입니다. 이 평가 설계는 엔지니어가 아니라 PM의 영역입니다.

한국의 현실: 5%

삼성SDS AX센터가 2026년 초 발표한 수치가 있습니다. 기업의 에이전트 실제 도입률: 5%.

도입 시도는 많습니다. 파일럿도 많습니다. 그러나 프로덕션으로 올라간 비율은 여전히 한 자릿수입니다.

왜일까요?

기술이 없어서가 아닙니다. 무엇을 자동화할지, 어디까지 자동화할지, 실패했을 때 누가 책임질지를 결정하는 구조가 없어서입니다.

이것은 엔지니어링 문제가 아닙니다. PM 문제입니다.

넥써쓰의 표현이 이 상황을 잘 정리합니다. “AI는 실행, 사람은 설계.” 에이전트가 실행을 맡으면, 그 실행의 방향과 경계를 설계하는 사람의 역할이 더 커집니다. 에이전트 도입률이 5%에 머무는 것은 에이전트가 부족해서가 아닙니다. 설계자가 부족해서입니다.

근본 원인: PM의 가장 비싼 시간이 이동한다

기존 PM이 하루를 어떻게 씁니까?

회의 조율, 요구사항 정리, PRD 작성, 이해관계자 커뮤니케이션. 이 작업들이 PM 시간의 60~70%를 차지했습니다.

이제 에이전트가 회의를 요약하고, PRD 초안을 만들고, 슬랙 스레드를 정리합니다. 반복적인 문서 작업의 상당 부분이 자동화됩니다.

그러면 남는 것은 무엇입니까?

판단입니다.

에이전트가 초안을 만들어도, 그것이 옳은지 판단하는 건 사람입니다. 에이전트가 빠르게 코드를 짜도, 그것이 맞는 문제를 풀고 있는지 확인하는 건 사람입니다. 에이전트가 A/B 테스트 결과를 정리해도, 어느 방향으로 갈지 결정하는 건 사람입니다.

그 판단, 그 이해, 그 검증이 PM의 새로운 핵심 업무입니다.

Andrew Ng이 코딩 에이전트의 가속 효과를 영역별로 분석한 결과도 같은 방향을 가리킵니다. 프론트엔드 → 백엔드 → 인프라 → 리서치 순서로 가속 효과가 줄어듭니다. 프론트엔드 개발은 빠르게 대체되지만, 요구사항을 정의하고 검증하는 리서치 영역은 거의 가속이 되지 않습니다.

가장 가속이 안 되는 영역에 PM의 핵심 가치가 있습니다.

해결 방향: Spec 작성자에서 Evaluation 설계자로

PM의 1차 산출물이 바뀌어야 합니다.

기존 PM의 1차 산출물은 PRD였습니다. 기능을 정의하고, 요구사항을 나열하고, 에지 케이스를 정리하는 문서. 에이전트가 이 초안을 훨씬 빠르게 만들 수 있습니다. PRD 작성 자체가 PM의 차별화 포인트가 되기 어려운 시대가 됐습니다.

대신 PM이 직접 설계해야 하는 것이 있습니다.

평가 기준: 이 기능이 올바르게 동작하는지 어떻게 측정할 것인가. 정확도 몇 퍼센트를 기준으로 볼 것인가. 어떤 케이스를 실패로 정의할 것인가.

검증 프레임: 에이전트 출력을 누가, 어떻게, 언제 검수할 것인가. 자동 검수와 인간 검수의 경계를 어디에 그을 것인가.

의사결정 구조: 에이전트가 틀렸을 때 누가 되돌릴 수 있는가. 어떤 결정은 에이전트에게 위임하고, 어떤 결정은 반드시 인간이 승인해야 하는가.

실제 수치로 확인된 사례가 있습니다. OpenAI 내부에서 세금 신고 에이전트를 6주 동안 자기 개선했습니다. 시작 정확도 25%, 6주 후 86%. 무엇이 이 차이를 만들었습니까? 모델 교체가 아니었습니다. Production trace 분석, practitioner feedback 수집, eval set 설계와 반복 개선이었습니다. 이 과정을 설계하고 운영하는 것이 PM 역할입니다.

메르카리 NFT 팀의 경험도 같은 방향입니다. 팀은 하네스(hooks, 권한, 샌드박스)를 플랫폼에서 빌려왔습니다. 그러나 “무엇이 정답인지, 무엇이 위험한지” 판단 기준은 팀이 직접 수집하고 문서화했습니다. PM의 1차 산출물이 기능 명세에서 평가·위험 기준 문서화로 이동한 사례입니다.

이 전환을 GeekNews에서 “AI 서비스 PM, 이제 ‘평가’를 설계하라”라는 제목의 글로 정리한 바 있습니다. Spec 작성 능력이 아니라 Evaluation 설계 능력이 2026년 PM의 첫 번째 경쟁력입니다.

어느 쪽 병목을 먼저 풀 것인가

코딩 에이전트가 팀에 들어오면 두 가지 중 하나가 됩니다.

PM이 더 좋은 판단을 더 빠르게 내리기 시작하거나. 혹은 더 많은 코드가 더 빠르게 쌓이는데 방향이 맞는지 아무도 확인하지 못하거나.

차이는 PM이 자신의 역할을 어디에 두느냐에서 납니다. 문서 작성을 빠르게 돕는 사람으로 남을 것인가, 아니면 에이전트가 옳은 방향으로 가고 있는지 판단하는 설계자로 이동할 것인가.

Andrew Ng은 이미 방향을 명시했습니다. 코딩이 빨라질수록 무엇을 만들지 결정하는 역할이 병목이 됩니다. 그 병목을 풀 수 있는 사람이 AI 시대 PM의 자리를 갖게 됩니다.

당신 팀에서, 무엇을 만들지 결정하는 속도와 코드를 만드는 속도 — 어느 쪽이 더 빠릅니까?