AI 에이전트가 코드를 더 많이 작성했지만, 완료된 작업량은 변하지 않았다. 그 이유는 코드 리뷰 때문이다.

원래 Dromeas blog에 게시됨.

요약: 하버드에서 작성한 새로운 연구 논문은 약 700개 기업을 추적하며 AI 코딩 도구를 도입하는 과정을 분석했다. 기업들이 코딩 에이전트를 채택하자 엔지니어들은 코드 라인을 30% 더 많이 작성하고 풀 리퀘스트(pull requests, PR)를 23% 더 많이 열었다. 하지만 완료된 티켓(finished tickets)의 수는 크게 변하지 않았다. 연구진은 이 격차를 코드 리뷰에서 찾았는데, 리뷰 시간이 49% 증가했고 수정 요청으로 반송되는 PR의 비율은 거의 두 배가 되었다. AI를 커밋 수로 측정한다면 잘못된 지표를 측정하는 것이다.

연구 개요

하버드의 Fiona Chen과 James Stratton은 엔지니어링 분석 플랫폼인 Jellyfish에서 얻은 데이터를 사용했다. 이 데이터는 2021년 1월부터 2026년 3월까지 약 700개 기업과 70만 명의 근로자를 포괄한다. 여기에는 커밋(commits), 풀 리퀘스트, Jira 티켓, 달력 이벤트 등 총 약 3억 개의 업무 이벤트가 포함된다.

그들은 기업들이 AI 코딩 어시스턴트(자동 완성 스타일 도구)와 AI 코딩 에이전트(작업을 받아 스스로 변경 사항을 생성하는 도구)를 도입하기 전과 후를 비교했다. 기업들의 도입 시기는 달랐는데, 이는 일부 회사에서 조달 과정이 다른 회사보다 오래 걸리기 때문이었다. 따라서 그들은 도입한 기업들을 아직 도입하지 않은 기업들과 비교할 수 있었다.

이는 올해 제가 본 AI가 실제 엔지니어링 조직에서 적용된 가장 큰 규모의 연구이며, 설문조사에서 말한 것이 아니라 팀들이 실제로 수행한 작업에 기반하고 있다.

더 많은 코드, 동일한 결과물

기업이 코딩 에이전트를 도입한 후, 엔지니어 한 명당 월별로 다음과 같은 변화가 있었다:

어시스턴트의 경우 더 작은 증가를 보였는데, 커밋은 약 9% 증가했지만, 라인 수나 PR에는 유의미한 변화가 없었다.

마지막 행이 핵심이다. 저자들은 이를 명확히 밝혔다. '생산성 향상이 소프트웨어 산출물이나 고용 변화에 완전히 반영되지는 않는다.' 에이전트의 경우 신뢰 구간(confidence intervals)을 분석한 결과, 이슈-산출물 간의 증가분은 약 12%를 넘지 않는 것으로 나타났으며, 이는 코드 활동량에서 관찰된 20~30% 급증보다 훨씬 낮은 수치다. 에픽(Epics)도 변하지 않았고, 티켓(tickets) 또한 효과를 숨기기 위해 작아지거나 커지지 않았다.

측정 가능한 기간 동안 고용 역시 어느 방향으로 크게 움직이지 않았다. 따라서 이 이야기는 AI가 조용히 엔지니어를 대체한다는 이야기가 아니다. 어딘가에 업무가 쌓이고 있다는 이야기다.

업무가 쌓이는 곳: 코드 리뷰

논문이 제시하는 답은 코드를 작성한 바로 다음 단계이다. 그들이 말했듯이, '코드를 작성하는 것은 다단계 생산 과정 중 단지 한 단계일 뿐'이다.

에이전트 도입 이후:

• PR(Pull Request)에서 병합(merge)까지 걸리는 시간은 기존 7.03일 대비 3.45일 증가했다. 이는 49% 더 긴 시간이다.
• 수정 요청이 포함된 PR의 비율은 13%에서 약 25%로 증가했다. 저자들은 '수정 요청이 있는 풀 리퀘스트의 비율이 거의 두 배가 되었다'고 언급했다.
• PR당 리뷰 코멘트 수는 35% 상승했다.
• PR 크기는 유의미하게 변하지 않았다. 따라서 단순히 더 큰 디프(diffs) 때문에 시간이 오래 걸리는 것은 아니다.
• 코드 리뷰를 수행하는 사람의 비율은 14% 증가한 반면, 코드를 작성하는 비율은 변화가 없었다.

그들이 인터뷰한 주니어 엔지니어 한 명이 어떤 차트보다도 이 상황을 잘 요약했다. '사람들은 엄청난 수의 커밋(commits)을 빠르게 만들 수 있었지만, 코드 리뷰가 여전히 병목 현상이었다.'

저자들의 모델은 두 가지 이유를 제시하며 이를 뒷받침한다. 첫째, 더 많은 초안 코드는 단순히 검토할 양이 많다는 것을 의미한다. 둘째, 각 변경 사항에 문제가 더 많이 포함될수록 모든 리뷰는 더 많은 라운드를 필요로 한다. 그들은 결함을 직접 측정하지는 않지만, 동일한 크기의 PR에서 증가하는 수정 요청과 댓글 수는 이를 시사한다. 이는 내가 AI 코드의 행동적 버그에 대해 작성한 내용과 일치하는데, 에이전트가 작성한 코드는 깨끗해 보이려는 경향이 있어 문제가 처음부터 드러나기보다는 주고받는 과정에서 표면화되기 때문이다.

AI 리뷰는 이미 존재하며, 인간의 개입은 여전히 필요하다

이 부분이 놀라웠습니다. 2026년 3월까지 샘플에 포함된 기업의 거의 80%가 AI 코드 리뷰 도구를 사용했습니다. 하지만 리뷰 코멘트 중 AI가 작성한 것은 단지 23.3%였고, 풀 리퀘스트(PR) 전체에서 AI가 생성한 코멘트를 받은 경우는 고작 10.8%에 불과했습니다.

즉, AI 리뷰는 존재하지만 파편화되어 있고, 대기열을 해소하지 못하고 있습니다. 인터뷰를 진행한 한 선임 엔지니어는 이렇게 말했습니다. “AI 도구가 있어도 리뷰 과정에는 절대적으로 인간이 개입해야 합니다.”

저도 동의합니다. 문제는 인간이냐 AI냐가 아닙니다. 리뷰 단계가 코드를 작성하는 단계만큼 많은 투자를 받느냐 하는 것입니다.

여기서 얻을 점

커밋(commits)을 AI 성과 지표로 사용하지 마세요. 논문은 “많은 관리자들이 코드 라인 수나 커밋 같은 중간 생산성 지표에 의존한다”고 언급합니다. 그 숫자는 증가했지만, 완성된 작업량은 그렇지 않았습니다. 만약 귀사의 AI 도입 대시보드가 라인 수와 PR로 구성되어 있다면, 그것은 결코 제약 요인이 아니었던 단계를 측정하고 있는 것입니다.

리뷰 대기열을 측정하세요. PR이 열린 시점부터 병합(merge)되기까지의 시간, 변경 요청이 포함된 PR의 비율, 그리고 PR당 리뷰 라운드 횟수입니다. 이 수치들이 이번 연구에서 이야기를 들려주었고, 대부분의 팀은 이미 Git 호스팅 서비스에 가지고 있습니다.

에이전트를 위해 예산 책정하듯이 리뷰를 위한 예산을 책정하세요. 저자들의 논의 중 가장 실용적인 내용은 다음과 같습니다. “AI 도입의 이점을 실현하려면 다운스트림(downstream) 리뷰 역량에 대한 보완적 투자가 필요합니다.” 이는 사람, 프로세스 또는 도구링(tooling)을 의미할 수 있지만, 반드시 무언가를 의미해야 합니다. 에이전트를 배포하고 리뷰는 현 상태로 두는 것은 그저 쌓인 문제를 옮기는 것일 뿐입니다.

리뷰어의 첫 번째 검토를 더 저렴하게 만드세요. 추가 시간 대부분이 “이것을 변경해 주세요”와 같은 라운드로 소모된다면, 인간이 PR을 열기 전에 이러한 문제를 포착하고 그 증거를 제시하는 곳에 시간이 돌아옵니다. 어느 지점에 이 검사를 배치해야 할지 결정 중이라면 PR 대 트렁크에서 리뷰가 어떻게 다른지에 대해 작성한 적이 있습니다.

사람들이 신뢰할 수 있는 방식으로 AI 검토를 만드세요. 연구에 참여한 거의 모든 기업이 AI 검토를 시도했지만, 실제로 적용된 비율은 10개 중 약 1건에 불과했습니다. 제 추측으로는 이는 도구(tooling)의 문제가 아니라 신뢰의 문제입니다. 엔지니어들은 단순히 봇이 댓글을 남겼다는 이유로 자신들의 검토 단계를 건너뛰지 않으며, 그럴 필요도 없습니다. 신뢰를 구축하는 것은 좋은 동료처럼 작동하는 검토입니다. 이는 하나의 일반적인 검토가 아닌, 전문화된 체크(보안, 품질, 규정 준수 등)를 사용해야 합니다. 무언가를 플래그 지정하기 전에 여러 독립 모델이 동의해야 하므로, 한 모델의 사각지대가 여러분의 문제가 되지 않습니다. 또한 학습합니다: 팀이 "여기서는 관련성이 없다"고 말하면, 그 의견은 유지되어야 하며, 그래야 같은 노이즈가 다음 주에 다시 발생하지 않습니다. 시간이 지남에 따라 더 조용하고 정확해지는 검토란 사람들이 더 이상 이중으로 확인(double-checking)할 필요를 느끼지 못하는 검토입니다.

릴리스도 살펴보세요. 검토는 첫 번째 병목 구간입니다. 릴리스는 모든 검토된 변경 사항이 한데 모이는 곳이며, 다음 병목 구간이기도 합니다.

Dromeas가 적합한 이유

이것이 Dromeas가 구축된 배경 문제입니다. 모든 PR과 트렁크 커밋은 보안, 코드 품질 및 규정 준수 측면에서 전문 에이전트의 검토를 받으며, 그 결과는 여러 제공업체의 모델들로 구성된 위원회에 전달되어 플래그 지정되기 전에 상호 교차 확인됩니다. 각 판결에는 그 근거가 제시되므로, 인간 검토자는 빈 diff(변경 사항)가 아니라 발견된 내용을 바탕으로 시작할 수 있습니다. 팀이 특정 발견 사항을 무시하면, Dromeas는 이를 규칙으로 전환하여 동일한 노이즈를 발생시키는 것을 중단시키고, 따라서 검토 과정은 더 큰 소리가 아닌 시간이 지남에 따라 조용해집니다. 모든 태그가 지정된 릴리스에서 Dromeas는 전체 릴리스 범위에 대해 준비 상태 확인(readiness checks)을 실행하고, 블로커와 승인 사항이 포함된 판결을 내립니다. 릴리스 관리에 대한 더 많은 정보가 있습니다.

— Manos

출처: Fiona Chen과 James Stratton, "Artificial Intelligence in the Firm: Bottlenecks in Software Production," Harvard University working paper (아직 동료 검토를 거치지 않음), 2026년 8월 4일 버전. PDF