AI 코딩의 30% 증가, 리뷰 병목이 삼킨 생산성

새 코드가 늘었는데 완료된 기능은 왜 그대로인가

AI 코딩 도구를 평가할 때 가장 쉽게 보이는 것은 생성된 코드다. 그러나 회사가 구매하는 것은 코드의 양이 아니라 고객에게 전달되는 기능이다. Ars Technica의 10월 9일 보도가 소개한 연구는 이 둘을 구분해야 하는 이유를 보여준다. 10월 12일 개발자 커뮤니티에서 다시 주목받은 이 기사는 새로운 모델 출시가 아니라 조직 수준의 성과를 살펴본 분석이다.

보도에 따르면 Harvard의 Fiona Chen과 James Stratton은 Jellyfish의 엔지니어링 활동 데이터를 활용했다. 분석 범위는 2021년부터 2026년 3월까지이며, 700개 이상 기업, 70만 명 이상의 직원, 약 3억 건의 작업 이벤트를 포괄한다. 커밋과 풀 리퀘스트뿐 아니라 이슈 관리 도구의 완료 기록도 함께 본 점이 중요하다.

다음 수치는 보도가 인용한 연구 원문의 추정 결과다. 모든 기업에서 같은 비율로 변화했다는 뜻이 아니며, 직원 70만 명 전부를 AI 사용자로 해석해서도 안 된다.

생성 단계의 이득이 리뷰 단계에서 사라졌다

핵심은 49%라는 수치의 정의다. 풀 리퀘스트 제출부터 병합까지 걸리는 구간이 길어진 것이므로, 사람이 화면을 보며 검토한 시간만 49% 늘었다고 바꾸어 말하면 부정확하다. 대기, 수정 요청, 재검토가 모두 들어갈 수 있다.

보도는 변경 요청이 붙는 풀 리퀘스트 비중이 거의 두 배가 되고, 풀 리퀘스트당 댓글은 35% 늘었다고 전한다. 그렇다고 댓글이 많다는 이유만으로 코드 품질이 나빠졌다고 단정할 수도 없다. 팀이 더 적극적으로 검토했을 가능성까지 포함해 해석해야 한다. 관측된 현상은 생성량 증가와 후속 검토 부담이 함께 나타났다는 것이다.

이 연구로 말할 수 있는 것과 없는 것

연구진은 기업별 도입 시점 전후를 비교하는 차분의 차분 분석을 사용했다고 보도는 설명한다. 무작위로 일부 기업에만 도구를 지급한 실험은 아니다. 도입 팀의 특성, 조직 변화, 업무 구성 같은 요소가 결과 해석에 영향을 줄 수 있다.

또한 데이터 종료 시점은 2026년 3월이다. 이후 모델과 작업 방식의 개선을 포함한 영구적인 판정으로 읽으면 안 된다. 측정된 이슈 해결률에 유의한 변화가 없다는 결과를 모든 개발 업무에서 AI가 쓸모없다는 주장으로 확대할 근거도 부족하다.

반대로 최신 모델이 나왔다는 이유만으로 병목이 사라졌다고 가정할 수도 없다. 요구사항 모호성, 시스템 간 의존성, 보안 검토, 운영 책임은 모델의 코드 생성 능력과 다른 문제다. Supabase 노출과 AI 앱의 완성 기준이 보여주는 관점처럼, 실행되는 코드와 배포해도 되는 서비스 사이에는 별도 검증이 필요하다.

한국 개발팀은 무엇을 측정해야 하나

첫째, 생성량 지표와 전달 성과를 나눠야 한다. 코드 줄 수와 커밋 수는 활동 지표로 남기되, 변경이 실제 운영에 도달하는 시간과 배포 이후 수정 부담을 함께 보자. DORA의 소프트웨어 전달 성과 지표는 처리량과 불안정성을 함께 살피는 참고 틀이다. 파일 수정이 많아졌다는 사실만으로 투자 효과를 계산해서는 안 된다.

둘째, 리뷰 대기와 실제 리뷰 노동을 분리하자. 작성자는 10분 만에 작업을 끝냈더라도 담당 리뷰어가 이틀 뒤에야 볼 수 있다면 병목은 생성 속도가 아니다. 팀 전체 풀 리퀘스트 수에 상한을 두고, 변경 범위를 작게 유지하며, 테스트 결과와 설계 의도를 함께 제출하는 운영 실험이 유용하다. 이는 연구가 검증한 처방이 아니라 결과에서 도출할 수 있는 실무 제안이다.

셋째, AI 리뷰를 추가하더라도 동일한 기준으로 평가해야 한다. 잘못된 경고를 정리하느라 사람의 시간이 늘면 자동화가 부담을 다른 형태로 옮겼을 뿐이다. Google 버그바운티와 검증 병목, Anthropic OSS Scanner의 분류 부담도 탐지량과 처리 능력을 구분해야 한다는 문제와 연결된다.

기업용 코딩 도구의 경쟁은 더 많은 코드를 만드는 기능에서, 변경 근거를 설명하고 검증 가능한 작은 단위로 전달하는 기능으로 이동할 여지가 있다. 구매자가 보상하는 지표를 바꿀 때 제품이 최적화하는 목표도 달라진다.

FAQ

AI를 쓰면 생산성이 반드시 떨어진다는 연구인가?

아니다. 보도된 결과는 생성 단계의 증가가 측정된 기업 수준의 소프트웨어 완료 지표 개선으로 이어지지 않았다는 것이다.

리뷰 시간이 49% 늘었다면 개발자 노동도 그만큼 늘었나?

그렇게 단정할 수 없다. 제출부터 병합까지의 경과 시간에는 대기와 수정 과정이 포함된다.

코드량 30% 증가는 좋은 소식 아닌가?

같은 품질의 기능을 더 빨리 전달한다면 좋다. 다만 코드량 자체는 유지보수 부담이나 중복 구현 증가도 포함할 수 있다.

최신 코딩 모델에도 결과를 그대로 적용할 수 있나?

데이터는 2026년 3월까지다. 이후 모델과 팀 운영의 변화는 별도 검증해야 한다.

작은 팀은 무엇부터 시작해야 하나?

풀 리퀘스트 제출·첫 검토·병합·운영 반영 시점을 기록하고, 재작업과 배포 후 결함을 함께 추적하는 것이 현실적인 출발점이다.