AI 코딩 에이전트 생산성, 90%가 쓰는데 왜 일정은 그대로인가

밍글링글링 2026. 9. 11.

728x90

전문 개발자의 90% 가 AI 코딩 에이전트를 매주 쓰고 68% 는 매일 쓴다. 그런데 팀의 배포 일정은 1년 전과 별로 다르지 않다. 도구는 분명히 좋아졌고 개발자는 빨라졌다고 느끼는데 조직 성과는 왜 그대로인가. 이 글의 답은 하나다. 코드 작성은 애초에 병목이 아니었고, 빨라진 코드 작성이 병목을 리뷰와 검증으로 옮겨놨을 뿐이다. 숫자로 그 과정을 따라간다.

도입률은 이미 포화 상태다

젯브레인스가 2026년 8월 낸 개발자 생태계 조사(2026년 5~7월, 전문 개발자 1만 5천 명)에서 AI 코딩 에이전트의 주간 사용률은 90%, 일간 사용률은 68% 였다. 도구별로는 Claude Code 가 39%(미국 47%)로 가장 많이 쓰였고, 깃허브 코파일럿은 1년 사이 29% 에서 21% 로, 커서는 18% 에서 12% 로 줄었다. 어느 도구가 이기느냐는 이제 부차적인 문제다. 안 쓰는 개발자를 찾는 게 더 어렵다.

이 수치가 뜻하는 건 "도입하면 얼마나 빨라지나"라는 질문이 시효를 다했다는 것이다. 이미 다 도입했다. 그런데도 일정이 안 당겨진다면 원인은 도구 밖에 있다.

개인은 빨라졌지만 조직은 버그와 리뷰에 잡혀 있다

파로스 AI 가 2025년 11월 25일 공개한 엔지니어링 보고서는 4천 개 팀, 개발자 2만 2천 명의 2년치 데이터를 봤다. 결과가 흥미롭다. AI 를 많이 쓰는 팀은 코드 작업량이 210% 늘었고 에픽 완료도 66% 늘었다. 여기까지는 기대대로다. 그런데 같은 팀에서 버그율이 54% 늘었고, PR 리뷰 시간은 91% 길어졌으며, 리뷰 없이 배포된 코드는 31% 늘었다. 배포 전 인시던트 확률은 3배가 넘었다. 보고서는 이렇게 요약한다. "개발자는 더 빠르다고 느끼고 만족도도 높다. 하지만 처리량, 품질, 전달 속도를 보면 숫자는 다른 이야기를 한다."

구글 DORA 가 2026년 7월 낸 AI 지원 개발 ROI 보고서도 같은 방향이다. 단순 작업에서는 35~40% 의 생산성 향상이 있었지만, 레거시 코드에서는 순이득이 10% 를 밑돌았다. 결정적인 수치는 이것이다. AI 가 만든 코드는 사람이 쓴 코드보다 첫 리뷰까지 4.6배 오래 기다린다. 코드는 빨리 나오는데 그 코드를 봐줄 사람의 시간은 늘지 않았다.

DORA 는 이 현상을 "AI 는 증폭기"라고 부른다. 리뷰가 느리고 테스트가 약한 팀에 AI 를 넣으면 기술 부채가 더 빨리 쌓인다. 리뷰가 빠르고 테스트가 튼튼한 팀은 그 반대다. 도구가 팀을 바꾸는 게 아니라 팀의 습관을 키운다.

반론: 개발자는 정말 빨라졌다

가장 강한 반론은 METR 의 연구에서 나온다. METR 은 2025년 7월 10일 경험 많은 오픈소스 개발자 16명에게 실제 작업 246개를 무작위로 배정해 AI 사용 여부에 따른 소요 시간을 쟀다. 결과는 AI 를 쓴 쪽이 19% 느렸다. 개발자들은 사전에 24% 빨라질 거라 예상했고, 끝난 뒤에도 빨라졌다고 믿었다. 체감과 실측이 40포인트 넘게 벌어진 것이다.

그런데 METR 은 2026년 2월 24일 후속 글에서 2025년 하반기 재측정 결과를 공개했다. 원래 참가자들은 이번엔 18% 빨라진 것으로 나왔다. 에이전트형 도구가 퍼지면서 문맥 전환 비용이 줄었다는 게 유력한 설명이다. 나도 이 방향이 맞다고 본다. 2025년 초의 도구와 2026년의 도구는 다르고, 개인 수준에서 속도가 붙은 건 사실일 것이다.

하지만 그 18% 의 신뢰구간은 -38% 에서 +9% 까지 걸쳐 있고, 새로 참여한 개발자 57명, 800여 개 작업에서는 -15% 에서 +9% 로 유의미한 차이가 없었다. METR 스스로 이 후속 데이터를 개선 규모에 대한 약한 증거라고 썼다. 그리고 개인이 빨라진 것과 팀이 빨라진 것은 다른 문제다. 파로스의 4천 개 팀 데이터가 보여주는 건 개인의 속도가 조직의 속도로 번역되지 않는다는 사실이다. 번역 과정에서 리뷰라는 환율이 걸린다.

코드 작성은 개발 시간의 3분의 1이었다

수학으로 정리하면 이렇다. 개발 라이프사이클에서 코드를 실제로 치는 시간은 25~35% 다. 나머지는 요구사항 정리, 설계, 리뷰, 테스트, 배포, 운영이다. 코드 작성 속도를 두 배로 올려도 전체는 15~25% 밖에 빨라지지 않는다. 암달의 법칙이다. 여기에 리뷰 시간이 91% 늘어나면 그 15% 마저 상당 부분 상쇄된다. 90% 가 쓰는데 일정이 그대로인 이유가 이것이다. 마법이 없는 게 아니라 산수가 맞는 것이다.

프래그매틱 엔지니어의 게르겔리 오로스는 "코드 타이핑 속도는 소프트웨어 개발의 병목이었던 적이 없다"고 했다. 커서 CEO 마이클 트루엘조차 "프로덕션 코드 작성은 빨라졌지만 대부분의 팀은 리뷰 방식이 3년 전과 같다"고 인정했다. 도구를 파는 쪽이 이렇게 말하면 그건 사실이다.

그래서 팀이 할 일은 도구 하나를 더 사는 게 아니다. DORA 가 AI 배포 전에 손보라고 한 세 가지가 답이다. 리뷰 파이프라인을 짧게 만들고, CI 테스트를 믿을 수 있게 만들고, 배포를 자동화하는 것. 이 셋이 없는 팀에서 AI 코딩 에이전트는 PR 을 더 많이 쌓는 기계다. 이 셋이 있는 팀에서만 도입률 90% 가 일정 단축으로 바뀐다.

참고 자료