코딩 에이전트 도입 후 코드는 30% 늘었지만 이슈 해결률은 그대로

AI가 일을 빨리 만들어 줄수록 팀이 더 많이 내보내게 될까. 하버드 연구진 Fiona Chen과 James Stratton이 Jellyfish의 엔지니어링 데이터로 확인했다. 700개 넘는 소프트웨어 기업, 직원 70만 명 이상, 작업 기록 약 3억 건을 2021년부터 2026년 3월까지 훑었다. 코딩 에이전트를 도입한 뒤 코드 줄 수는 평균 30%, 커밋은 20%, 풀 리퀘스트는 23% 늘었다. 이슈와 에픽의 해결률에는 통계적으로 의미 있는 변화가 없었다.

한 줄 정리

코딩 에이전트는 만들어지는 코드의 양을 약 30% 늘렸지만 팀이 끝내는 일의 양은 늘리지 못했고, 늘어난 부담은 사람의 검토 단계에 쌓였다.

한눈에 보기

방법은 도입 전후를 기업별로 비교하는 차이의 차이 회귀다. 도입 시점은 실제 사용량과 GitHub 활동으로 잡았고 코딩 어시스턴트와 코딩 에이전트를 구분했다.

병목은 만드는 쪽이 아니라 받는 쪽

연구진의 결론은 코딩 단계의 효율이 하류 공정에 흡수된다는 것이다. 풀 리퀘스트는 많아졌는데 검토 시간은 "크게 늘었고" 수정을 요구받는 비율과 리뷰어 코멘트도 늘었다. 만드는 속도는 올랐고 승인하는 속도는 그대로였다.

비슷한 결과가 다른 연구에도 있다. MIT와 Wharton의 5월 NBER 워킹페이퍼는 대화형 어시스턴트 단계에서 작성된 코드가 741% 늘 때 완성된 릴리스는 20% 늘었다고 보고했다. 도구 세대가 바뀔수록 쓴 코드와 내보낸 소프트웨어 사이의 간격이 벌어졌다. 단 이 데이터는 공개 저장소 위주고 초기 도입 기업이 많아서, 시차 때문에 간격이 일부 부풀었을 가능성도 열려 있다.

코드가 아닌 팀에도 같은 모양이 있다

이 구조는 개발팀만의 이야기가 아니다. 콘텐츠 팀이 에이전트로 블로그 초안을 하루 열 편 뽑고 광고 대행사가 소재 변형을 하루 오십 개 만들어도, 편집 승인과 클라이언트 검수가 한 사람이면 출고량은 그 사람의 하루 안에 갇힌다. 초안이 늘수록 쌓이는 건 성과가 아니라 대기열이다.

그래서 도입 효과를 재는 단위를 바꿔야 한다. 생성된 양이 아니라 승인되어 나간 양, 그리고 승인까지 걸린 시간이다. 에이전트 도입 한 달 뒤에 이 두 숫자가 안 움직였다면 병목은 도구 바깥에 있다.

위시클레이 관점

30%는 만드는 속도이고 0%는 끝내는 속도다. 두 숫자 사이의 빈칸을 사람이 메우고 있다. 에이전트 비용이 내려갈수록 이 빈칸이 팀의 진짜 예산이 된다. 월 $200짜리 에이전트를 붙이고 검수자 한 명을 그대로 두면 월 $200으로 대기열을 사는 셈이다.

가진 도구를 늘리기 전에 검수 쪽 일을 줄이는 게 먼저다. 기준이 명확한 작업(맞춤법, 금칙어, 가격 표기 일치)은 검수 목록에서 아예 빼서 기계 검사로 돌리고, 사람은 톤과 사실관계만 본다. 승인 권한을 대표 한 명에서 담당자 둘로 나누는 것도 모델을 바꾸는 것보다 효과가 크다.

15명 팀이 에이전트 세 개를 도입하고도 출고량이 그대로라면 에이전트가 부족한 게 아니다. 승인 줄이 한 줄이라는 뜻이다. 다음 도구를 사기 전에 지난달 승인 대기 건수를 먼저 세어 보는 게 좋다.

참고

• Chen & Stratton: Jellyfish 데이터 기반 코딩 에이전트 연구 원문
• Ars Technica: AI coding agents generate more code, but not more software
• Quartz: MIT·Wharton NBER 연구가 보여 준 코드 작성량과 릴리스의 간격