코딩 에이전트가 일주일에 수백 개의 커밋을 생산하는 팀에서, 커밋 수는 무엇을 의미하나요?

OpenAI의 Akshay Nathan이 Latent Space 팟캐스트에서 이 질문을 던졌습니다. 그의 답은 단순했습니다. “아무것도요.” 코딩 에이전트가 빠르게 확산되면서 커밋·PR·토큰 소비량 같은 기존 생산성 지표가 동시에 무효화됐다는 진단입니다. 그리고 그는 새로운 병목을 지목했습니다. 아이디어입니다.

이 변화는 지표 교체 문제가 아닙니다. 팀 구조와 PM 역할 전반에 걸친 재편입니다.

무엇이 무너졌나

과거에 “팀이 얼마나 일했나”를 측정하는 방법은 비교적 명확했습니다. 커밋 수, PR 리뷰 속도, 스프린트 완료율. 이 숫자들이 생산성을 대리(proxy)했습니다.

코딩 에이전트가 들어오면서 이 대리 관계가 끊겼습니다.

Claude Code, Codex, Cursor 같은 도구들은 엔지니어 한 명이 하루에 수십 개의 PR을 열고 닫을 수 있게 만들었습니다. 토큰 소비량은 더 말할 것도 없습니다. 에이전트 하나가 복잡한 리팩토링을 수행하면 단숨에 수십만 토큰이 나갑니다.

문제는 이 숫자들이 더 이상 “좋은 일을 했느냐”와 상관없다는 점입니다.

SVPG(Silicon Valley Product Group)는 같은 시점에 다른 관점에서 같은 결론에 닿았습니다. “PM 역할의 새로운 정의는 무엇이 존재해야 하는지를 결정하는 것이다.” 실행 속도가 탈병목화되자, 무엇을 실행할지가 남은 유일한 진짜 병목이 됐습니다.

Stripe의 Staff Engineer는 한발 더 나아갔습니다. “병렬 에이전트를 조율할 수 있느냐”가 시니어 엔지니어의 새로운 기대치 기준선으로 제시됩니다. 코딩 에이전트 시대는 엔지니어 직급 기대치조차 재정의하고 있습니다.

같은 날, 독립적인 세 출처가 동일한 결론에 도달했습니다. 병목이 이동했다는 것.

아이디어가 병목이 되는 세 가지 구조

첫째, 실행 비용이 거의 0에 수렴했습니다.

좋은 아이디어와 나쁜 아이디어를 둘 다 에이전트에게 주면, 둘 다 그럴듯한 코드로 나옵니다. 실행 속도가 높아질수록 나쁜 아이디어를 “빨리 만들어버리는” 리스크도 함께 높아집니다. 이 상황에서 “무엇을 만드느냐”의 품질이 팀의 결과를 결정합니다.

둘째, 검증 비용은 줄지 않았습니다.

임상 시험, 법적 검토, 사용자 테스트 — 이 검증 레이어들은 에이전트가 빨라진다고 함께 빨라지지 않습니다. 에이전트가 임상 데이터를 분석하고 논문 초안을 작성할 수 있어도, FDA 승인 프로세스는 그대로입니다. “데모가 곧 제품”이라는 착각은 바로 이 지점에서 발생합니다. 만드는 속도와 검증 속도의 간극이 넓어질수록, 올바른 것을 만드는 판단력의 가치가 높아집니다.

셋째, 방향 실수의 수정 비용이 올라갔습니다.

에이전트가 빠르게 구현하기 때문에, 방향이 잘못됐다는 걸 늦게 발견하면 수정 비용도 함께 커집니다. 더 많이 만들어버렸으니까요. 초기에 “이게 정말 만들어야 할 것인가”를 따지는 판단의 가치가 이전보다 훨씬 높아졌습니다.

PM이 지금 측정해야 할 것

커밋, PR, 토큰이 빠진 자리에 무엇을 놓아야 할까요.

**아이디어의 전환율(idea-to-shipped-value rate)**입니다.

팀이 제안한 아이디어 중 몇 %가 실제 사용자 가치로 전환됐나. 이 숫자를 올리는 것이 코딩 에이전트 시대 PM의 핵심 역할입니다.

여기서 PM이 설계해야 할 두 가지 레이어가 있습니다.

아이디어 필터 레이어

아이디어를 평가하는 기준을 명문화하고, 에이전트에게 넘기기 전에 통과해야 할 체크포인트를 설정하는 것입니다. AndrewYNg는 이 스킬맵을 반복해 강조합니다. “코딩을 빠르게 하는 것보다, 무엇을 코딩할지 결정하는 역량이 더 중요해졌다.”

실행 파이프라인을 이렇게 재구성해야 합니다.

아이디어 → [PM 판단 체크포인트] → 에이전트 실행 → 검증 루프 → 배포

중간의 “PM 판단 체크포인트”가 없으면, 에이전트는 빠른 속도로 잘못된 방향을 향해 달립니다.

검증 루프 설계

에이전트가 만든 결과를 어떤 기준으로 검증하느냐입니다. 에이전트 도입의 상당수가 PoC에서 운영 단계로 넘어가지 못하는 건 이 검증 루프가 없기 때문입니다. 에이전트는 실행했지만, 무엇이 성공인지 정의되지 않았습니다.

메르카리의 AI-Native 팀 사례가 이 점을 잘 보여줍니다. 그들의 결론은 “정답과 위험의 판단 기준 문서화”가 PM 산출물의 새 핵심이라는 것입니다. 기능 명세서보다 평가 기준서를 먼저 씁니다.

지표보다 먼저 바뀌어야 할 질문

지표를 바꾸기 전에, 팀이 공유하는 질문을 바꿔야 합니다.

“이번 스프린트에 몇 개의 PR을 처리했나?” 대신,

“이번 분기에 만든 기능 중 실제로 사용되고 있는 것은 몇 개인가?”

이 질문의 전환이 생각보다 어렵습니다. 측정하기 불편하기 때문입니다. 커밋 수는 CI/CD 파이프라인이 자동으로 집계하지만, 아이디어의 전환율은 사람이 직접 설계하고 추적해야 합니다. 대시보드에 자동으로 뜨지 않습니다.

그 불편함을 감수하는 것이 지금 PM의 일입니다.

Stripe의 Staff Engineer가 언급한 “에이전트 병렬 조율”도 결국 같은 맥락입니다. 병렬로 실행되는 에이전트들에게 공통된 방향과 기준을 부여하는 것, 그것이 조율입니다. 아이디어와 기준이 없는 조율은 존재하지 않습니다.

코딩 에이전트가 실행 속도 문제를 해결했습니다. 남은 문제는 방향입니다.

지금 여러분의 팀은 무엇으로 “잘하고 있다”고 판단하나요?