코딩 에이전트를 도입한 뒤 코드가 더 많이 쌓였다면, 제품도 그만큼 빨리 나왔을까. 하버드대 피오나 첸과 제임스 스트래턴의 연구는 이 둘을 따로 측정했다. 718개 기업의 개발 활동에서 에이전트 도입 후 직원 1인당 월간 추가 코드 줄 수는 약 30% 늘었다. 그러나 완료한 업무와 기능을 나타내는 지표에서는 통계적으로 유의한 증가를 찾지 못했다.
Ars Technica가 10월 10일 소개한 이 연구의 분석 기간은 2021년 1월부터 2026년 3월까지다. 연구진은 개발 조직 분석 서비스 Jellyfish의 익명화된 자료로 72만 5,938명의 활동, 약 3억 건의 업무 이벤트를 살폈다. 개인이 코드를 빨리 쓰는 효과가 기업의 소프트웨어 산출로 얼마나 이어지는지 묻는 연구다.
코드 30% 증가는 무엇을 센 숫자인가
연구는 사람이 쓰는 코드에 다음 내용을 제안하는 ‘코딩 보조 도구’와, 지시를 받아 여러 단계의 작업을 수행하는 ‘코딩 에이전트’를 구분한다. 에이전트 분석은 보조 도구를 쓰던 기업이 에이전트를 추가로 도입했을 때의 효과를 추정한다. 모든 개발자가 같은 도구를 같은 양으로 쓴 실험은 아니다.
기업마다 도입한 시점이 다른 점을 이용해, 도입 전후의 변화와 늦게 도입하거나 도입하지 않은 기업의 변화를 비교했다. 이런 차이의 차이 분석에서 에이전트 도입 후 직원 1인당 월간 추가 코드 줄 수는 약 30%, 변경 내용을 저장한 커밋은 약 20%, 검토를 요청한 풀 리퀘스트(PR)는 약 23% 증가했다. 단순히 코드만 장황해졌다고 보기에는 제출 활동도 함께 늘었다.
PR을 제출하는 것과 기능을 완성하는 것은 다르다
커밋은 작업 중인 변경을 저장하는 단위이고, PR은 그 변경을 동료에게 검토받기 위한 제출 단위다. PR이 승인돼 공용 코드에 합쳐져도 아직 운영 환경에 배포되지 않았을 수 있다. 그래서 연구진은 Jira 같은 업무 관리 도구에서 해결된 이슈와 에픽을 별도로 봤다. 이슈는 개별 업무, 에픽은 여러 업무를 묶은 기능이나 프로젝트에 가깝다.
두 완료 지표의 추정치는 작게 증가했지만 통계적으로 유의하지 않았다. 이는 소프트웨어가 한 건도 더 나오지 않았다는 뜻이 아니다. 작성 단계에서 확인된 증가가 기능 완성 단계에서 비슷한 크기로 나타났다는 근거가 부족하다는 뜻이다. 연구진은 업무 설명으로 예상 소요 시간을 추정해, 완료 건수는 그대로인데 업무가 더 커졌을 가능성도 살폈으나 그런 변화의 증거를 찾지 못했다. 여기서 ‘출시’는 앱스토어 등록 횟수가 아니라 업무 관리 시스템의 완료 기록으로 측정한 산출을 말한다.
늘어난 검토 시간은 사람이 코드를 읽는 시간만일까
에이전트 도입 후 PR 제출에서 병합까지 걸리는 기간은 평균 약 49% 길어졌다. 기준 평균 7.03일에 추정 효과 3.45일이 더해진 결과다. 이 기간에는 리뷰 대기와 수정 왕복도 들어가므로, 검토자가 코드를 읽는 순수 작업 시간이 49% 늘었다고 바꿔 읽으면 안 된다.
수정 요청을 받은 PR의 비율은 기준 약 13%에서 약 12%포인트 높아지는 효과를 보였다. 거의 두 배에 해당한다. PR당 검토 댓글 수도 약 35% 늘었다. 수정 요청은 곧 버그 판정이 아니지만, 제출한 변경이 한 번에 승인되지 않고 다시 손봐야 하는 부담은 커졌다고 읽을 수 있다. PR당 추가 코드 줄 수에는 유의한 변화가 없어서, PR 하나가 단순히 더 커졌다는 설명만으로 이 결과를 풀기는 어렵다.
검토는 새 코드가 기존 제품에서 어떤 일을 하는지 따지는 과정이다. 연구에 실린 GitHub 화면 예시는 사용자가 대상 조직에 접근할 권한이 있는지 먼저 검증해야 하지 않느냐는 댓글을 보여 준다. 함수가 실행되는지와 사용자가 그 행동을 해도 되는지는 다른 질문이다. 이 화면은 리뷰의 역할을 설명하는 예시이며, 조사 대상 기업의 실제 장애 사례를 보여 주는 것은 아니다.
개발 일정과 도구 예산을 어떻게 다시 볼까
기업도 검토에 더 많은 사람을 투입했다. 에이전트 도입 후 코드 리뷰에 참여하는 직원 비율은 기준 대비 약 14% 늘었다. 여기서 14%는 상대 증가율이지 전체 직원의 14%포인트가 새로 검토 업무를 맡았다는 뜻은 아니다. 전체 고용과 개발 인력에서도 도입에 따른 유의한 변화는 확인되지 않았다. 분석 종료 시점이 2026년 3월이므로 이후 도구 성능이나 장기 고용 변화를 이 결과에 포함할 수는 없다.
PM이나 팀장이 이 연구에서 가져갈 실무 질문은 구체적이다. 다음 달 PR을 더 많이 제출할 수 있다는 사실만으로 출시 일정을 앞당길 수 있는가. 그러려면 승인할 사람이 있고, 수정 사항을 되돌려 처리할 여력이 있는지도 봐야 한다. 도구 도입 전후를 비교할 때 제출량 옆에 PR 제출부터 병합까지의 기간과 실제 완료한 기능을 함께 놓는 편이 낫다.
예컨대 PR은 늘었는데 완료 기능은 비슷하고 병합 대기가 길어졌다면, 그 팀에서는 작성 능력보다 검토 처리량을 먼저 점검할 이유가 있다. 작은 단위로 변경을 나누거나, 담당 리뷰어를 정하거나, 제출 전에 권한·실패 경로 테스트를 요구하는 방식은 그때 검토할 운영 선택이다. AI가 쓴 긴 주석처럼 검토자가 읽어야 할 양을 늘리는 요소는 리뷰 팀이 주석을 줄여야 하는 이유에서 따로 볼 수 있다. 이 연구가 그런 대책의 효과까지 시험한 것은 아니다. 도구를 더 사기 전에 우리 팀의 지연이 작성 단계인지, 승인과 수정 단계인지부터 나눠 기록할 수는 있다.
출처: Ars Technica, Fiona Chen·James Stratton, Artificial Intelligence in the Firm: Bottlenecks in Software Production (2026년 8월 4일 판)