에이전틱 코드 리뷰

코딩 에이전트의 급격한 성능 향상으로 엔지니어링의 어려운 지점이 코드 작성에서 그 코드를 신뢰할지 판단하는 일로 이동, 리뷰가 가장 레버리지 높은 작업이 됨

AI는 산출량을 크게 늘리지만 품질과 리뷰 가능성은 떨어뜨려, 4배의 코드 대비 실제 가치는 약 10% 증가에 그치는 격차가 측정됨

필요한 리뷰의 강도는 변경의 blast radius(파급 범위) 에 따라 달라지며, 솔로 개발자와 10년 된 대규모 시스템 유지팀은 전혀 다른 제약을 가짐

에이전트는 추론하지만 그 추론이 PR에 첨부되지 않고 버려져, 리뷰어가 사라진 의도(intent)를 처음부터 재구성해야 하는 부담 발생

작성은 싸졌지만 이해는 여전히 비싸므로, 신뢰할 수 있는 리뷰 시스템을 구축한 팀이 향후 우위를 점함

2026년 데이터가 실제로 보여주는 것

수년간 일화·논쟁이던 주장이 이제 이해관계가 다른(일부는 경쟁 관계인) 조직들에 의해 대규모로 측정, AI가 산출량은 급증시키되 품질과 리뷰 가능성은 떨어뜨린다는 동일한 결론 도출

Faros AI 측정 (2026년 3월 데이터)

4,000개 팀 22,000명 개발자를 대상으로 저(低)AI 도입에서 고(高)AI 도입 전환 추적

긍정적 측면: 개발자가 더 많은 PR을 머지하고 더 많은 작업을 완료, 엔지니어당 처리량 상승

부정적 측면 수치

코드 churn 861% 증가

인시던트 대 PR 비율 242.7% 증가

개발자당 결함률 9% → 54%

중앙값 리뷰 소요 시간 441.5% 증가 (첫 리뷰까지 시간·평균 리뷰 시간 모두 약 2배)

리뷰 없이 머지된 PR 31.3% 증가

리뷰 없는 머지는 누구도 선택한 게 아니라, 리뷰어가 물량을 따라가지 못해 읽히지 않은 코드가 머지되는 것이 일상화된 결과

성숙하고 규율 잡힌 엔지니어링 관행을 가진 팀도 동일하게 타격, 좋은 프로세스가 보호하지 못함 (물량이 프로세스 설계 속도보다 빠르게 도착)

CodeRabbit 연구 (2025년 12월)

오픈소스 PR 470개(AI 공동작성 320, 사람만 150) 분석, AI 변경이 약 1.7배 많은 이슈 동반

로직·정확성 문제 약 75% 증가

보안 이슈 1.5~2배 증가

가독성 문제 3배 이상 증가

AI 디렉터 David Loker "예측 가능하고 측정 가능한 약점이며 조직이 적극적으로 완화해야 함" — 알려지고 위치를 특정할 수 있는 약점이므로 리뷰 프로세스를 정조준 가능

GitClear 생산성 데이터 (2025년까지)

매일 AI를 쓰는 사용자는 비사용자 대비 약 4배 원시 산출량, 그러나 1년 전 자신 대비 실제 생산성 향상은 약 12% 에 불과

4배의 코드를 사람이 전부 리뷰해야 하는 구조

Bill Harding은 그 12%조차 일부는 선택 편향(강한 개발자가 AI 집단에 집중)이라고 명시

GitHub 보고

Copilot 리뷰가 누적 6천만 건 이상 실행, 1년 만에 10배 증가, 플랫폼 리뷰 5건 중 1건 이상이 에이전트 관여

더 이상 틈새 관행이 아니라 코드가 만들어지는 방식 자체

네 개 데이터셋·네 개 방법론이 하나의 결론으로 수렴, 병목은 사라지지 않고 검증(verification) 단계로 이동

모두가 서로 다른 문제를 풀고 있음

위 경고성 데이터 대부분은 엔터프라이즈 텔레메트리와 압도된 오픈소스 메인테이너에게서 나온 것, 소수만 쓰는 것을 만드는 1인 개발자에게는 상당 부분 적용되지 않음

위치를 결정하는 세 변수

blast radius: 망가졌을 때 일어나는 일 — 아무 일도 없거나, 분노한 사용자·금전·PII 노출

코드의 수명: 다음 주 다시 쓸 일회성 프로토타입인지, 수년간 유지할 코드베이스인지

이해해야 하는 사람 수: 머릿속에 전부 담은 본인뿐인지, 시간에 걸쳐 소유권을 공유하는 팀인지

솔로·그린필드·사용자 없음

리뷰의 두 번째 역할인 팀 내 지식 분배가 존재하지 않음 (본인이 곧 팀)

합리적 선택: 테스트와 자동화에 강하게 의존, 정말 중요한 부분만 리뷰, 나머지는 가벼운 터치

단, 테스트가 진짜일 때만 작동, 안전망 없이 리뷰를 건너뛰면 일이 사라지는 게 아니라 더 비싼 값으로 이연(defer) 됨

"사용자 없음"은 리뷰를 이연할 허가이지 검증을 건너뛸 허가가 아님

위험한 중간 지점

프로젝트에 사용자가 생기는 순간, 버그 잡기 역할이 갑자기 중요해지고(버그가 사람에게 피해) 지식 공유 역할도 켜짐

팀이 솔로 시절 습관을 몇 달 더 유지하다 포스트모템을 맞으면 Faros 수치가 자기 대시보드가 됨

대규모 조직·오래된 코드베이스·다수 사용자

모든 경고성 수치가 최대 강도로 적용, 아무도 이해 못한 변경은 comprehension debt(이해 부채) 가 되어 누군가의 온콜 인시던트로 전환

핵심은 "기업은 신중, 솔로는 여유"가 아니라 위치에 따라 리뷰의 목적이 달라지므로 규칙도 달라져야 함

2인 프로토타입에 엔터프라이즈식 다중 에이전트·증거 요구 파이프라인을 붙이면 무의미한 마찰, 결제 시스템에 "테스트 통과하니 배포"를 적용하면 초록 체크 달린 인시던트 생성기

지금 리뷰가 실제로 하는 일

사람이 코드를 쓰면 의도가 공짜로 따라오며, 저울질하고 버린 대안이 작성자 머릿속에 있어 리뷰는 그 추론을 점검하는 일이었음

현대 에이전트도 추론하며 종종 사고 과정(thinking trace)을 가시적으로 보여주지만, 그 추론은 diff가 만들어지는 순간 버려지고 PR에 첨부되지 않음

게다가 그것은 "어떻게 구현할지"에 대한 에이전트의 추론이지 "애초에 맞는 작업인지"에 대한 사람의 판단이 아님

결과적으로 리뷰가 눈앞의 추론 점검에서 기록되지 않은 의도의 재구성으로 바뀌어 더 어렵고 느려짐 (441% 더 걸리는 이유)

AI Slop and the Software Commons (2026 논문)

Reddit·Hacker News 15개 스레드의 게시물 1,154개 분석

한 개발자의 표현: 에이전트 PR 리뷰가 자신을 "이 코드를 처음으로 본 인간"으로 만듦

논문 표현으로 리뷰는 "사라진 의도를 복구하도록 만들어지지 않았음"

해법은 도구 문제

사라진 의도는 복구 가능 — 추론이 존재했고 단지 버려졌을 뿐

에이전트가 무엇을 하려 했고 무엇을 배제했는지 진술하게 하고 그것을 PR의 decision log(결정 로그) 로 캡처하면 재구성 비용 상당 부분 소멸

"AI가 AI를 리뷰" 하나만으로는 완전한 답이 아님, 다른 사전 지식을 가진 두 번째 모델은 실제 버그를 많이 잡지만 "이게 만들 가치가 있는 변경인가"라는 사람의 판단은 제공하지 못함

도구는 좋지만, 광고하는 이유 그대로는 아님

전용 AI 리뷰 도구는 이제 충분히 좋으며, 사이드 프로젝트 포함 모든 것에 최소한 메인 코딩 에이전트(가능하면 전용 리뷰 에이전트)를 돌릴 것을 권장

주요 도구별 특성

CodeRabbit: 가장 널리 배포, 독립 Martian 벤치마크(2026년 1~2월) F1 1위, 정밀도 약 49%에 업계 최고 recall

Greptile: 정밀도를 내주고 recall 확보, 한 벤치마크에서 버그 검출률 약 82%(CodeRabbit 44% 대비)이나 거짓 양성 더 많음

Anthropic Code Review: 자사 엔지니어가 오류로 표시한 결과 1% 미만, 실질적 리뷰를 받는 PR 비율을 16%에서 54%로 끌어올림

4개 리뷰어 병렬 실험 (벤더 외부 결과)

한 엔지니어가 CodeRabbit·Sentry Seer·Greptile·Cursor BugBot를 3주 반 동안 실제 PR 146개, 발견 679건에 병렬 적용

617개의 고유 플래그 위치 중 93.4%가 정확히 하나의 도구에서만 검출, 6%는 둘, 셋은 거의 없음, 넷 모두는 전무

네 도구가 같은 줄을 단 한 번도 함께 플래그하지 않음

각 도구의 강점이 다름: Greptile은 정확성·아키텍처에서 거짓 양성 거의 제로, CodeRabbit은 가장 넓은 그물과 원클릭 수정, Seer는 운영 장애 심각도에 강함

이질성(heterogeneity)이 핵심 — 한 모델 4벌은 청구서만 커진 단일 리뷰어, 진짜 다른 4개 리뷰어는 누구도 단독으로 못 찾는 버그를 드러냄

실무 지침

단 하나의 최고 도구를 고민하지 말 것 (그런 건 없음)

고위험 영역에서는 의도적으로 성격이 다른 둘을 병행 (위 실험은 일상 정확성용 Greptile + 운영 장애 심각도용 Seer)

솔로라면 좋은 리뷰어 하나에 진짜 테스트면 충분

마케팅과 무관하게 반드시 자신의 코드에서 측정, 모든 결과는 특정 코드베이스에 국한됨

AI에게 더 많이 리뷰를 맡겨야 하는가

1년 전이면 이단이었을 질문이 경험 많은 엔지니어들에게서 나옴 — 기계가 리뷰의 더 많은 부분, 어쩌면 대부분을 해야 하는가

AI 리뷰가 작동한다는 불편한 사실

Anthropic 발견의 1% 미만만 오류 표시, 사람이 지나친 버그를 잡고, 하루 30번째 PR에서도 지치지 않음 (사람이 가장 신뢰도 낮은 시점)

반면 사람은 따라가지 못함 — 무리뷰 머지 31% 증가, 리뷰 시간 세 자릿수 증가

정직한 프레이밍은 "AI에게 더 맡겨야 하나"가 아니라 "AI는 이미 하고 있으며, 이를 의도적으로 할 것인지 아니면 사람이 다 읽는 척하며 방치할 것인지"

Loop engineering의 관점

루프의 전제는 에이전트에 프롬프트를 넣는 사람에서 벗어나 에이전트에 프롬프트를 넣는 시스템을 구축하는 것, 그 중심에 작업 완료 여부를 판정하는 judge(판정자) 에이전트

리뷰어가 의도적으로 내부 루프에서 설계상 제거되는 다음 역할이 됨, 작성 자동화 1년 뒤 검증도 자동화되며 사람은 위로 밀려남

닫힌 루프의 위험

에이전트가 쓰고, 다른 에이전트가 리뷰하고, 세 번째가 판정하면 상관된 맹점(correlated blind spots) 을 가진 모델들의 닫힌 루프 (특히 같은 계열일 때 같은 지점에서 확신을 갖고 동의)

사람이 전혀 없는 자신만만한 "looks good"은 빌려온 확신(borrowed confidence) — 시스템의 확신이 곧 내 확신이 되고 아무도 실제로 이해하지 못함

사람은 떠나지 않고 한 단계 위로 이동

모든 diff를 읽는 것에서, 모델에 전이되지 않는 부분을 소유하는 것으로 전환, 책임(accountability)이 중요

사람이 지켜야 할 영역: 이게 만들 옳은 변경인지의 판단, 틀리면 비싼 고(高)blast-radius 게이트, 그리고 아무도 명세하지 않은 행동 (모델은 존재하는 코드만 리뷰하고 아무도 적지 않은 요구사항은 거의 플래그하지 못함)

human in the loop에서 human on the loop으로 — 모든 PR을 읽는 대신 시스템을 샘플링·스폿체크·감사하고, 틀리면 실제로 아픈 곳에 제한된 주의 집중

Kun Chen 사례 (전 Meta L8 엔지니어, 솔로 빌더)

하루 약 40개 PR을 출하하며 코드 리뷰를 사실상 중단, 20~30개 에이전트를 병렬 실행

노력을 계획(plan)으로 이동 — 사전에 상세 계획 작성, 에이전트가 수 시간 실행, 계획 품질이 무인 실행 시간을 좌우

검증을 멈춘 게 아니라 의도를 본인이 미리 적어 "코드를 처음 본 인간" 문제를 절반 해결 (사람이 사후가 아닌 사전에 이유를 이해)

안전망 없이 일하지 않음 — No Mistakes라 부르는 자동 리뷰 게이트가 머지 전 코드 검사, 에이전트가 막히면 에스컬레이션 대기

단, 대규모 팀도 10년 된 지뢰밭 시스템도 없는 솔로 빌더이며, 그의 조건은 대부분 독자에게 없음 — 다수 사용자 대상 팀에 복사하면 Faros 수치를 자기 대시보드에서 재현

스펙트럼 결론: 솔로·사용자 없음은 AI에 거의 전부를 맡기는 것이 방어 가능한 2026년 입장, 대규모·다수 사용자는 첫·두 번째 패스와 지루한 90%는 기계가, 부하를 견디는 경로(load-bearing paths)에는 실제 사람 유지, 사람을 얼마나 둘지는 죄책감이 아니라 blast radius로 설정하는 다이얼

실제로 무엇을 할 것인가

조직 원칙: 리뷰 노력을 틀렸을 때의 비용에 맞추고, 저렴한 결정론적 작업을 최대한 앞으로 당기며, 사람의 주의는 사람만 할 수 있는 일에 예약

작성자가 아닌 위험으로 계층화 (Tier by risk, not by author)

설정 변경은 린터와 한 번 훑기로 충분

핵심 비즈니스 로직 경로 수정은 풀 스택: 타입, 테스트, 서로 다른 두 AI 리뷰어, 해당 시스템 소유자인 사람, 보안 패스

보일러플레이트에 무거운 리뷰를 쓰지 말고, 테스트가 초록이라고 큰 변경을 통과시키지 말 것

비싼 꼬리를 빠르게 차단 (Fast-fail the expensive tail)

Early-Stage Prediction of Review Effort (2026년 1월), 에이전트 작성 PR 33,707개 연구

에이전트는 작고 잘 정의된 변경에 강해 약 28%가 거의 즉시 머지되나, 주관적 피드백을 받는 순간 "잠수(ghost)"하여 리뷰의 핵심인 주고받기를 포기하는 경향

동반 2026 논문에서 리뷰어 이탈이 거부된 에이전트 PR의 38% 차지

연구진은 파일 유형·패치 크기 같은 저렴한 신호로 고유지비 PR을 사람이 보기 전에 예측하는 "회로 차단기(circuit breaker)" 구축, 잘 작동

리뷰할 가치의 기준 자체를 높이기

해법은 저장소를 잠그는 게 아니라 증거 없이 도착한 변경의 리뷰를 거부하는 것

리뷰 전 요구사항: 변경의 목적 진술, 주석 없는 3,500줄짜리가 아닌 diff, 테스트 출력, 실제 실행했다는 증거

의도 재구성 작업을 비싼 자신이 흡수하는 대신 싸게 처리할 수 있는 제출자에게 되돌림

PR을 의도적으로 작게 유지

에이전트 PR은 크게 나옴 (Faros 데이터에서 평균 51% 더 큼), 리뷰어 참여는 PR 머지 여부의 가장 강한 예측 변수 중 하나

크고 리뷰 불가능한 PR은 즉시 거부되거나 더 나쁘게는 고무도장 처리됨

에이전트에 작은 커밋 생성을 지시, 사람이 실제로 읽을 수 있는 diff는 이제 예의가 아니라 설계 제약

코드보다 테스트 변경을 더 주의 깊게 읽기

주시할 에이전트 실패 모드: 동작을 바꾼 뒤 새 깨진 동작에 맞춰 assertion을 다시 써서 테스트를 "고침"

200개 편집된 테스트 위의 초록 체크는 편집이 옳았음을 확인하기 전까지 무의미, 많은 테스트를 다시 쓰는 diff는 플래그로 취급해 먼저 읽기

mutation testing의 가치: 커버리지는 줄이 실행됐는지를, 뮤테이션 테스트는 그 줄이 틀렸을 때 테스트가 알아챌지를 알려줌