이번 주 서로 다른 세 곳에서 같은 결론을 봤습니다.

첫째, GeekNews에서 ‘AI로 더 천천히, 더 좋은 코드 짜기’라는 글이 29점으로 TOP 1에 올랐습니다. 핵심 주장은 단순했습니다. LLM은 빠르게 대충 짜는 도구가 아니라, PR 리뷰·버그 탐지·검증에서 가치가 폭발하는 도구라는 것.

둘째, Sam Altman이 인정했습니다. “AI가 예상만큼 일자리를 대체하지 못했다”고. 대체 서사가 흔들리면 남는 질문은 하나입니다. 그러면 AI는 정확히 무엇을 바꿨는가.

셋째, HuggingFace에 공개된 ITBench-AA 결과에서 GPT-5.5, Claude 4.7을 포함한 프론티어 모델 전부가 엔터프라이즈 IT 에이전트 과제에서 50%를 넘지 못했습니다. 데모는 통과해도 운영은 막히는 패턴이 이번엔 수치로 나왔습니다.

세 신호가 가리키는 방향은 같습니다.

PM의 KPI를 ‘속도’로 잡으면 틀린다.

기존 KPI의 한계

기존 PM이 성과를 재는 방법은 단순했습니다. 스프린트 속도(velocity), 기능 출시 빈도, time-to-market. 더 빠르게 더 많이 만들면 잘 한 것이었습니다.

AI 에이전트가 코딩을 대신 맡으면 이 공식은 빠르게 무너집니다.

에이전트는 처음 며칠 안에 인간 팀의 수 배에 달하는 코드를 쏟아낼 수 있습니다. 그러나 삼성SDS AX센터의 실태 조사에 따르면, 국내 기업에서 에이전트가 실제 운영에 투입된 비율은 5%에 불과합니다. 속도는 올랐는데 도입률은 5% — 이 95% 갭이 말해주는 것은 분명합니다. “더 빠르게”는 에이전트 시대 PM의 1차 변수가 아닙니다.

여기서 실수가 시작됩니다. 에이전트를 도입하고 나서도 기존 KPI 체계를 그대로 쓰면, 팀은 에이전트가 만드는 속도를 성과로 착각하게 됩니다. 검증되지 않은 코드가 쌓이고, 운영 장애가 늘고, PM은 정작 무엇이 잘못됐는지 지표에서 보이지 않는 상황에 빠집니다.

병목이 이동했다

AI 에이전트가 실행을 맡은 이후, 병목의 위치가 바뀌었습니다.

  • 이전: 코드를 만드는 속도가 병목
  • 지금: 만든 것이 제대로 작동하는지 검증하는 구조가 병목

OpenAI의 세금 신고 에이전트(Tax Agents) 사례가 이 이동을 정확히 보여줍니다. 에이전트 투입 초기 정확도는 75%였습니다. 모델 자체는 바꾸지 않았습니다. 대신 6주 동안 운영 로그를 수집하고, 오류 유형을 태깅하고, eval set을 반복 개선했습니다. 6주 후 정확도는 86%가 됐습니다. 이 11%포인트 개선을 만든 것은 모델 업그레이드가 아니었습니다. PM이 설계한 반복 검증 루프였습니다.

nolanlawson의 글이 GeekNews에서 29점을 받은 이유가 여기 있습니다.

“LLM을 더 빠른 코딩 도구로 쓰면 빠르게 틀린 코드를 만든다. 반면 PR 리뷰와 버그 탐지에 쓰면 검증 가치가 폭발한다.”

속도의 활용이 아니라 검증의 활용이라는 것.

TechCrunch도 이 주에 같은 방향의 경고를 내놨습니다. 코딩 에이전트에 의존하는 개발자들이 AI 없이는 기본 작업을 못 하는 단계에 이르고 있으며, 코드 품질 관리가 속도에 자동으로 따라오지는 않는다고. 속도 KPI를 유일한 기준으로 삼는 팀이 빠질 수 있는 함정입니다.

PM의 새 KPI 3축

그러면 AI 에이전트 시대의 PM은 무엇을 측정해야 할까요. 세 가지 축을 제안합니다.

1. 제거한 반복 업무량

에이전트가 반복 업무를 처리했다면, PM의 성과 지표는 출시 속도보다 “얼마나 많은 반복이 사라졌는가”로 이동해야 합니다.

이번 주 GeekNews에서 ‘하루 쉬어도 될까요’라는 글이 11점을 받았습니다. 핵심 주장은 단순합니다. AI가 생산성을 높여도 노동 시간이 줄지 않는다면, 효율이 팀원 개인의 부담으로 전가될 뿐이라는 것. 에이전트를 도입했는데 팀원이 더 바빠졌다면, KPI를 잘못 잡은 것입니다.

에이전트 KPI의 첫 번째 축은 이겁니다. 우리 팀이 이번 분기에 에이전트를 통해 제거한 반복 업무의 시간·건수·비율.

예를 들어 “월간 코드 리뷰 반복 요청 1,200건 자동 처리”처럼 구체적인 숫자로 잡아야 합니다. 막연한 “생산성 향상 30%“는 에이전트 시대에 너무 넓습니다. 무엇이 제거됐는지 명시해야 PM이 다음 개선 방향을 알 수 있습니다.

2. 검증 루프 완성도

데모를 통과시키는 건 모델이지만, 운영을 통과시키는 건 PM이 설계한 평가 구조입니다.

ITBench-AA에서 프론티어 모델들이 50%를 넘지 못한 이유는 모델 성능 때문이 아닙니다. 엔터프라이즈 IT 워크플로우를 커버하는 eval set이 없었기 때문입니다. 이 분야의 PM이 해야 할 일은 더 좋은 모델을 고르는 것이 아니라, 프로덕션 환경에서 작동하는 평가 구조를 만드는 것입니다.

OpenAI Tax Agents 사례처럼, PM의 1차 산출물이 기능 명세서에서 eval set과 반복 개선 루프로 이동했습니다.

hwchase17(LangChain CEO)는 이를 직접 표현한 바 있습니다. “에이전트가 데모를 못 넘는 이유는 표준 작업 절차와 관측 레이어가 없어서다.” 검증 루프를 설계한 PM이 결국 제품을 프로덕션에 올립니다.

검증 루프 완성도 = eval set 커버리지(%), 오류 유형 태깅률, 반복 개선 사이클 수.

3. 약속 범위 정확도

Lenny가 이번 주 인터뷰에서 말했습니다.

“AI가 뛰어난 PM을 더 강하게 만든다.”

이 말이 실천 가능한 이유는, 뛰어난 PM이 에이전트가 자율적으로 판단해도 되는 범위와 사람이 승인해야 하는 범위를 명확히 구분하기 때문입니다. 이 경계 설계가 틀리면, 에이전트가 자율적으로 잘못된 방향으로 달려가거나 반대로 사람 승인 병목에 막혀 효율이 나오지 않습니다.

arXiv에 올라온 한 실증 연구가 이 점을 잘 보여줍니다. 물리학자 한 명이 Claude Code와 함께 12일간 57세션으로 실제 과학 소프트웨어를 완성했습니다. 핵심은 완전 자동화가 아니었습니다. 어디서 에이전트에게 위임하고 어디서 자신이 판단을 가져올지 — 그 감독 루프 설계가 있었기 때문에 가능했습니다.

약속 범위 정확도 = 에이전트 자율 처리 케이스 중 사람 개입 없이 완결된 비율 + 사람 승인이 실제로 필요한 케이스 감지율.

보고 언어를 다시 써야 한다

속도 KPI 체계에서 PM은 이렇게 보고합니다.

“이번 분기 기능 출시 14건, 스프린트 속도 전분기 대비 23% 향상.”

에이전트 시대 KPI 체계에서는 이렇게 됩니다.

“에이전트가 처리한 반복 리뷰 작업 월 1,200건 제거. eval set 커버리지 68%→87% 개선. 사람 승인 없이 완결된 케이스 비율 72%→85%.”

어느 쪽이 팀과 제품에 실제로 무엇이 일어나고 있는지를 더 정확히 보여줍니까.

PM의 보고 언어가 바뀌어야 조직의 에이전트 투자 방향이 바뀝니다. 경영진이 “에이전트 잘 쓰고 있나?”고 물을 때 “기능 출시 빠릅니다”로 답하는 한, 에이전트는 계속 도구로 남습니다. “반복 업무 제거량과 검증 루프 완성도가 이만큼 올랐습니다”로 답할 때 에이전트는 운영 자산이 됩니다.

마치며

Sam Altman이 인정한 것처럼, AI는 예상보다 느리게 일자리를 대체하고 있습니다. 그러나 그것이 PM의 역할이 변하지 않는다는 뜻은 아닙니다. 오히려 대체가 느릴수록, PM이 설계해야 할 것이 더 많아집니다.

어디서 에이전트가 반복을 제거할 수 있는지. 어떤 평가 루프를 통해 운영 품질을 끌어올릴 수 있는지. 어디까지 자율로 두고 어디서 사람이 판단해야 하는지.

이 세 가지를 측정할 수 있게 되면, PM의 KPI는 속도표에서 가치표로 바뀝니다.

당신 팀의 에이전트 도입 성과는 지금 무엇으로 측정되고 있습니까?