에이전틱 코드 리뷰

핵심 1

코딩 에이전트의 급격한 성능 향상으로 엔지니어링의 어려운 지점이 코드 작성에서 그 코드를 신뢰할지 판단하는 일로 이동, 리뷰가 가장 레버리지 높은 작업이 됨 AI는 산출량을 크게 늘리지만 품질과 리뷰 가능성은 떨어뜨려, 4배의 코드 대비 실제 가치는 약 10% 증가에 그치는 격차가 측… 에이전틱 코드 리뷰 (addyo.substack.com)13P by GN⁺ 18시간전 | ★ favorite | 댓글과 토론 코딩 에이전트의 급격한 성능 향상으로 엔지니어링의 어려운 지점이 코드 작성에서 그 코드를 신뢰할지 판단하는 일로 이동, 리뷰가 가장 레버리지 높은 작업이 됨 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%

핵심 2

증가 리뷰 없는 머지는 누구도 선택한 게 아니라, 리뷰어가 물량을 따라가지 못해 읽히지 않은 코드가 머지되는 것이 일상화된 결과 성숙하고 규율 잡힌 엔지니어링 관행을 가진 팀도 동일하게 타격, 좋은 프로세스가 보호하지 못함 (물량이 프로세스 설계 속도보다 빠르게 도착) 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 집단에 집중)이라고 명시 Copilot 리뷰가 누적 6천만 건 이상 실행, 1년 만에 10배 증가, 플랫폼 리뷰 5건 중 1건 이상이 에이전트 관여 더 이상 틈새 관행이 아니라 코드가 만들어지는 방식 자체 네 개 데이터셋·네 개 방법론이 하나의 결론으로 수렴, 병목은 사라지지 않고 검증(verification) 단계로 이동 모두가 서로 다른 문제를 풀고 있음 위 경고성 데이터 대부분은 엔터프라이즈 텔레메트리와 압도된 오픈소스 메인테이너에게서 나온 것, 소수만 쓰는 것을 만드는 1인 개발자에게는 상당 부분 적용되지 않음 위치를 결정하는 세 변수 blast radius: 망가졌을 때 일어나는 일 — 아무 일도 없거나, 분노한 사용자·금전·PII 노출 코드의 수명: 다음 주 다시 쓸 일회성 프로토타입인지, 수년간 유지할 코드베이스인지 이해해야 하는 사람 수: 머릿속에 전부 담은 본인

핵심 3

뿐인지, 시간에 걸쳐 소유권을 공유하는 팀인지 솔로·그린필드·사용자 없음 리뷰의 두 번째 역할인 팀 내 지식 분배가 존재하지 않음 (본인이 곧 팀) 합리적 선택: 테스트와 자동화에 강하게 의존, 정말 중요한 부분만 리뷰, 나머지는 가벼운 터치 단, 테스트가 진짜일 때만 작동, 안전망 없이 리뷰를 건너뛰면 일이 사라지는 게 아니라 더 비싼 값으로 이연(defer) 됨 "사용자 없음"은 리뷰를 이연할 허가이지 검증을 건너뛸 허가가 아님 프로젝트에 사용자가 생기는 순간, 버그 잡기 역할이 갑자기 중요해지고(버그가 사람에게 피해) 지식 공유 역할도 켜짐 팀이 솔로 시절 습관을 몇 달 더 유지하다 포스트모템을 맞으면 Faros 수치가 자기 대시보드가 됨 대규모 조직·오래된 코드베이스·다수 사용자 모든 경고성 수치가 최대 강도로 적용, 아무도 이해 못한 변경은 comprehension debt(이해 부채) 가 되어 누군가의 온콜 인시던트로 전환 핵심은 "기업은 신중, 솔로는 여유"가 아니라 위치에 따라 리뷰의 목적이 달라지므로 규칙도 달라져야 함 2인 프로토타입에 엔터프라이즈식 다중 에이전트·증거 요구 파이프라인을 붙이면 무의미한 마찰, 결제 시스템에 "테스트 통과하니 배포"를 적용하면 초록 체크 달린 인시던트 생성기 지금 리뷰가 실제로 하는 일 사람이 코드를 쓰면 의도가 공짜로 따라오며, 저울질하고 버린 대안이 작성자 머릿속에 있어 리뷰는 그 추론을 점검하는 일이었음 현대 에이전트도 추론하며 종종 사고 과정(thinking trace)을 가시적으로 보여주지만, 그 추론은 diff가 만들어지는 순간 버려지고 PR에 첨부되지 않음 게다가 그것은 "어떻게 구현할지"에 대한 에이전트의 추론이지 "애초에 맞는 작업인지"에 대한 사람의 판단이 아님 결과적으로 리뷰가 눈앞의 추론 점검에서 기록되지 않은 의도의 재구성으로 바뀌어 더 어렵고 느려짐 (441% 더 걸리는 이유) AI Slop and the Software Commons (2026 논문) Reddit·Hacker News

핵심 4

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는 운영 장애.

원문: https://news.hada.io/topic?id=30571