에이전트 도입 후 PR 병합 시간 49% 증가: 첫 초안부터 검토하지 말아야 할 이유

• 도서: Event-Driven Architecture Pocket Guide
• 저자 글: Thinking in Go (2권 시리즈) — Complete Guide to Go Programming + Hexagonal Architecture in Go
• 프로젝트: Hermes IDE | GitHub — Claude Code 및 기타 AI 코딩 도구와 함께 배포하는 개발자를 위한 IDE
• 저자: xgabriel.com | GitHub

에이전트가 11분 만에 작업을 완료했습니다. 당신은 요약본을 훑어보고, 테스트가 녹색(green)인 것을 확인한 후 풀 리퀘스트(pull request, PR)를 열었습니다. 그러자 그것은 일주일 동안 그곳에 머물렀고, “수정 요청”과 함께 돌아왔으며, 한 팀원이 에이전트가 단지 한 번의 추가 턴으로 고칠 수 있었던 댓글을 작성하는 데 오후 시간을 보냈습니다.

그 기다림은 단순한 추측이 아닙니다. 718개 기업을 다룬 하버드 연구 논문에 따르면, AI 코딩 에이전트를 채택한 후 풀 리퀘스트를 제출하는 시점부터 병합되기까지 걸리는 시간이 49% 증가했습니다. 공식적인 수정 요청과 함께 반송되는 PR의 비율은 거의 두 배가 되었습니다. 코드 라인 수는 30% 증가했지만, 해결된 Jira 이슈로 측정된 최종 작업량에서는 통계적으로 유의미한 이득이 나타나지 않았습니다.

제 견해는 다음과 같습니다: 에이전트의 첫 초안은 풀 리퀘스트가 아닙니다. 직접 검토하고, 코드를 작성한 에이전트에게 수정 사항을 다시 보내며, 자신이 서명할 수 있을 때만 PR을 여십시오. 팀원들의 검토 시간이야말로 그 파이프라인에서 가장 부족한 자원입니다. 초안에 시간을 낭비하는 것을 멈추세요.

논문이 실제로 측정한 것

Fiona Chen과 James Stratton은 Jellyfish의 엔지니어링 분석 데이터를 사용했습니다: 2021년 1월부터 2026년 3월까지 GitHub, Jira 및 Google Calendar에서 나온 약 3억 개의 작업 이벤트를 활용한 것입니다(논문, pp. 1–3). 그들은 AI 도구를 더 일찍 채택한 기업과 나중에 채택했거나 전혀 채택하지 않은 기업을 비교하는 단계적 차분-차분(staggered difference-in-differences) 설계를 사용했습니다. 채택률은 개발자별이 아닌 기업별로 측정되었습니다.

AI 에이전트의 경우, 자동 완성(autocomplete) 스타일의 어시스턴트와 달리 다음과 같은 보고가 있습니다 (p. 3):

• 코드 라인 수 30% 증가, 커밋 20% 증가, 풀 리퀘스트(PR) 23% 증가
• 해결된 Jira 이슈 및 에픽에서는 통계적으로 유의미하지 않은 작은 증가가 있었으며, 이는 기준선 대비 12%를 초과하는 출력량 증가는 아니라는 것을 의미합니다.

검토 수치에 대한 내용은 pp. 22–23에서 확인할 수 있습니다. PR 제출부터 병합까지 걸리는 일수는 기준선인 7.03일 대비 3.45일 증가했으며, 이는 49% 상승입니다. 표준 오차(standard error)는 1.60일이므로 실제 효과는 훨씬 작거나 클 수 있습니다. 검토자 중 최소 한 명이 공식적으로 변경을 요청한 PR의 비율은 기준선인 0.13에서 0.12 증가했습니다. PR당 검토 코멘트는 기준선인 1.66개 대비 0.58개 증가하여 35% 상승했습니다. AI 어시스턴트가 이 세 가지 지표 중 어느 것에도 유의미한 영향을 미치지는 않았습니다. 코드 리뷰를 수행하는 작업자 비율은 에이전트를 사용했을 때 14%, 어시스턴트를 사용했을 때 10% 증가했습니다 (p. 24).

PR의 크기가 커진 것은 아닙니다. PR당 추가된 라인 수는 기준선 약 1,168개와 비교하여 유의미한 변화를 보이지 않았습니다 (p. 23). 따라서 추가적인 검토 라운드는 PR 자체가 커져서 발생한 것이 아닙니다.

주의 깊게 읽어주십시오. 이 문서는 동료 심사(peer-reviewed)를 거치지 않은 직장 시장 논문이며, 현재 버전은 2026년 8월 4일자입니다. 이는 관찰적 연구 결과입니다. Jellyfish는 과학적 내용이 아닌 독점 정보가 공개되지 않았는지 여부만을 확인하기 위해 이 원고를 검토했을 뿐입니다 (p. 1). 또한, 특정 PR이 에이전트의 첫 초안에서 비롯되었는지 여부는 기록하지 않습니다. 그 부분은 제 주장이며, 그들의 연구 결과가 아닙니다.

반송된 PR은 재시도(retry)이다

코드 리뷰를 대기열(queue)로 간주해 보십시오. 저자가 PR을 생산하고, 검토자가 이를 소비하며, 검토자의 수는 느리게 움직입니다. 이 논문은 기업들이 검토에 더 많은 인력을 투입했지만, 작성 속도가 그보다 빠르게 빨라졌다는 것을 발견했습니다.

변경 요청 비율(changes-requested rate)을 추가해야 합니다. 반송된 모든 PR은 다시 순환합니다: 작성자가 수정하고, 대기열에 재진입하며, 검토자는 두 번째로 읽습니다. 이것이 '재시도(retry)'이며, 재시도는 이미 병목 현상인 단계에 부하를 더합니다. 약 8개 중 1개의 PR이 반송되던 것에서 4개 중 1개가 되면서, 이미 바쁜 검토자들에게 훨씬 더 많은 두 번째 읽기 작업이 몰리게 됩니다.

저자들은 추가적인 검토 작업에 대한 두 가지 가능한 이유를 제시합니다(p. 23): 코드 품질이 떨어졌거나, 검토 기준이 변경되었기 때문일 수 있습니다. 그들이 인터뷰한 한 주니어 엔지니어는 "오직 한 명의 시니어 엔지니어만이 변경 사항을 승인할 수 있었고," "매주 한 번만 제 코드를 검토할 수 있었으며," 그리고 장애 발생 후에는 "AI가 생성한 코드에 대해 시니어 엔지니어의 승인이 필요하다는 새로운 규칙이 생겨나면서, 더욱 많은 검토 병목 현상을 초래했다"고 묘사했습니다.

이 문제를 해결하기 위해 충분한 수의 검토자를 고용할 수는 없습니다. 대기열에 더 적은 초안을 보낼 수 있습니다.

첫 번째 초안은 당신과 에이전트의 것입니다

인간 팀원이 코드를 작성할 때, 첫 초안은 이미 한 명의 독자(코드를 입력한 사람)를 거칩니다. 그들은 타이핑하는 동안 각 줄을 생각합니다. 에이전트의 첫 초안은 이 단계를 건너뜁니다. 빠르고 자신감 있게 도착하며, 그것을 자세히 읽는 최초의 인간은 종종 당신의 검토자입니다.

따라서 수정 반복(revision loop)이 움직입니다. 예전에는 작성자의 머릿속에서 일어나던 수정 사항들이 이제는 두 인간 사이, 즉 PR 댓글을 통해 대기열의 속도에 맞춰 발생합니다. 변경 요청은 누군가의 하루를 거치는 왕복 과정(round trip)을 의미합니다.

그 루프를 비용이 적게 드는 곳으로 되돌리세요. 코드를 작성한 에이전트는 컨텍스트가 로드된 상태로 바로 옆에 있습니다. 당신이 보내는 수정 사항은 한 번의 턴(turn)만 소모합니다. PR 댓글로 남기는 같은 수정 사항은 검토자의 읽기 시간, 당신의 컨텍스트 스위치, 새로운 푸시, 그리고 두 번째 검토를 비용으로 요구합니다.

제가 사용할 규칙은 이렇습니다. 다른 누구에게도 요청하기 전에 모든 변경 사항을 당신이 먼저 읽어야 합니다. 다른 사람의 PR에서 플래그를 지정할 것이라면, 가장 먼저 에이전트에게 되돌려 보내세요.

PR 생성 전 리비전 루프 수행하기

이를 위해 새로운 도구가 필요하지 않습니다. 에이전트가 자체 브랜치에서 작업하도록 한 다음, 다음을 수행하세요:

# what the agent changed since the branch split off
git diff --stat main...HEAD

...

npm test를 자신만의 테스트 명령어로 교체하세요. main...HEAD의 세 점은 해당 브랜치가 main에서 분리된 이후 변경한 내용만을 보여줍니다. GitHub에서는 초안 풀 리퀘스트(draft pull request)는 "병합할 수 없으며, 코드 소유자에게 자동으로 검토 요청이 이루어지지 않습니다"라는 상태가 되는데, 이는 당신과 에이전트 사이에 여전히 의견 불일치가 있을 때 원하는 상태입니다. --draft와 --fill은 gh 매뉴얼에 문서화되어 있습니다.

무언가를 발견하면, 마치 검토 댓글을 작성하듯이 작성하고 같은 세션에서 에이전트에게 보냅니다:

In src/orders.ts, refund() no longer checks that the order is paid. Put the check back and add a test for an unpaid order.

파일 이름을 지정하고, 무엇이 잘못되었는지, 그리고 완료된 상태가 어떻게 보이는지 설명하세요. 그런 다음 새로운 diff를 읽고, 검사를 다시 실행하며, 스스로 승인할 때까지 반복합니다. 그 후에야 gh pr ready를 실행하여 PR이 검토 준비가 되었음을 표시합니다. 설명을 직접 작성하세요. 만약 당신이 변경 사항을 두 문장으로 설명할 수 없다면, 검토자도 할 수 없습니다.

Hermes IDE의 구현 방식

저는 Hermes IDE를 구축했으니, 이 섹션을 염두에 두고 읽어보세요.

Hermes는 모든 에이전트 턴(turn)을 저장하여, 사용자가 단일 턴의 변경 사항을 diff하거나 복원하고 undo할 수 있게 합니다. Review Desk (Windows 및 Linux에서는 ⌘G, Ctrl+Shift+G)는 작업의 변경 사항을 턴별 또는 파일별로 보여주며, 위험 플래그(risk flags)와 함께 사용자가 남긴 라인 코멘트가 해당 라인을 작성한 에이전트에게 되돌아갑니다. 이것은 마지막 섹션에서 설명된 pre-PR 루프이며, 수동으로 파일 이름과 라인 번호를 터미널에 복사할 필요가 없습니다.

턴들이 올바르게 보이면, Land는 한 단계로 커밋하거나(commits), 풀 리퀘스트(pull request)를 열거나 로컬에서 병합할 수 있으며, 작업이 시작된 브랜치에 적용되고 되돌릴 수 있습니다. 사용자의 자체 검사만으로도 작업 완료 여부를 결정할 수 있습니다. Hermes는 무료이며 BSL 1.1 하에 소스 코드가 공개되어 있고, macOS, Windows 및 Linux에서 실행됩니다. 현재 릴리스 버전은 2026년 10월 15일 기준 2.3.4입니다. 이는 Nous Research, Anthropic, OpenAI 또는 다른 에이전트 공급업체와 제휴하지 않습니다.

저는 턴별 읽기 자체에 대해서는 Stop Reviewing Your Coding Agent's Final Diff에서 작성했습니다. 그 글은 건너뛰고 비용을 검토자에게 지우세요.

이것이 도움되지 않는 경우

자체 검토(Self-review)는 두 번째 독자를 대체할 수 없습니다. 왜냐하면 프롬프트(prompt)를 작성한 것은 사용자 자신과 에이전트이기 때문에, 여러분은 작업에 대해 동일한 사각지대(blind spots)를 공유하기 때문입니다. 세션에 참여하지 않은 검토자는 여전히 사용자가 놓칠 수 있는 것들을 포착해냅니다.

이것은 시간 비용도 발생시킵니다. 만약 하루에 수십 개의 작은 에이전트 PR(Pull Request)을 배포한다면, 각각을 완전히 검토하는 것은 상당한 작업입니다. 제 생각에는 어느 쪽이든 누군가가 그 코드를 면밀히 읽게 될 것이고, 문제는 누구의 오후 시간을 차지할지일 뿐입니다.

AI 검토 봇(review bots) 역시 대기열을 비워주지 못합니다. 2026년 3월까지 거의 80%의 기업이 코드 리뷰에 AI 도구를 사용했지만, 실제로 AI가 작성한 검토 코멘트는 23.3%에 불과했고, PR 중 AI 코멘트를 받은 비율은 10.8%였습니다 (p. 25). 사람들은 여전히 대부분의 읽기 작업을 수행했으며, 저자들은 기업들이 AI 검토 도구를 채택한 후에도 병목 현상(bottleneck)이 지속된다고 보고합니다 (pp. 4–5).

귀하의 팀은 오늘날 에이전트 PR을 어떻게 처리하고 있습니까? 검토로 바로 보내나요, 아니면 작성자가 먼저 확인하는 단계를 거치나요? 댓글로 알려주세요.

이 글이 도움이 되었다면

검토 대기열은 모든 대기열과 같은 이유로 막힙니다. 즉, 생산자는 속도를 높이지만 소비자가 따라가지 못하고, 재시도(retry)할 때마다 다시 줄에 합류하기 때문입니다. Event-Driven Architecture Pocket Guide는 사가(sagas), CQRS, 아웃박스(outbox) 및 아무도 경고해주지 않는 함정들을 다루는 큐와 메시지를 중심으로 구축된 시스템에 대한 저의 짧은 책입니다. 복사-붙여넣기 없이 PR 전 루프를 원한다면, Hermes IDE를 다운로드하고 도움이 된다면 GitHub에서 별표(star) 표시해 주세요 (https://github.com/hermes-hq/hermes-ide).