# 에이전틱 코드 리뷰 > Clean Markdown view of GeekNews topic #30571. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=30571](https://news.hada.io/topic?id=30571) - GeekNews Markdown: [https://news.hada.io/topic/30571.md](https://news.hada.io/topic/30571.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-06-17T12:23:01+09:00 - Updated: 2026-06-17T12:23:01+09:00 - Original source: [addyo.substack.com](https://addyo.substack.com/p/agentic-code-review) - Points: 20 - Comments: 0 ## Topic Body - 코딩 에이전트의 급격한 성능 향상으로 엔지니어링의 어려운 지점이 **코드 작성에서 그 코드를 신뢰할지 판단하는 일**로 이동, **리뷰가 가장 레버리지 높은 작업**이 됨 - 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**의 가치: 커버리지는 줄이 실행됐는지를, 뮤테이션 테스트는 그 줄이 틀렸을 때 테스트가 알아챌지를 알려줌 - ## CI를 움직이지 않는 벽으로 취급 - GitHub이 리뷰어에게 경고하는 패턴 주시: 제거된 테스트, 건너뛴 린트, 낮춰진 커버리지 임계값, 이미 존재하는데 중복된 헬퍼, 프롬프트로 흘러드는 신뢰 불가 입력 - 마지막 항목 특히 강조 — 에이전트가 만든 기능은 **prompt injection**의 새 발생원, 사용자 제어 텍스트를 LLM 호출에 그대로 넘기면 취약점은 diff에 보이지 않고 나중에 도착할 데이터에 잠복 - 에이전트는 통과를 위해 악의 없이도 CI를 약화시킴 (경사 하강이 초록으로 가는 가장 싼 경로를 찾는 것), 결정론적 게이트는 자신만만한 문단으로 판정을 뒤집을 수 없는 유일한 부분이므로 엄격하게 유지 - ## 머지는 사람이 소유 - 모델은 호출(page)될 수도 책임질 수도 없으므로 머지 버튼을 누르는 사람이 소유 - AI 리뷰가 차분하고 자신만만한 목소리로 "looks good"이라 할 때 그것은 반드시 획득되지 않은 확신을 건네는 것 - 모든 AI 리뷰를 판결이 아닌 **센서**로 취급 — 결정이 아니라 데이터 ### 팀을 운영한다면 의미하는 것 - 출하의 구속 제약은 더 이상 코드를 얼마나 빨리 쓰느냐가 아니라 **신뢰받는 사람이 변경의 정확성을 얼마나 빨리 확신하느냐** - 생성을 병목으로 보고 리뷰를 공짜로 취급하는 계획은 속도 대시보드를 초록으로 유지한 채 조용히 정체됨 - Faros 보고서는 산출량이 늘어도 QA·리뷰 작업이 늘어난다고 직접 명시, 리뷰 격차를 닫기 전에 "AI 덕분에 빨라졌다"며 엔지니어링 인원을 줄이는 것은 위험 - 세 자릿수로 늘어난 리뷰 시간이라는 **시니어 엔지니어 세금**은 가장 병목 잡으면 안 되는 사람에게 가장 무겁게 떨어지며, 머지된 PR만 세는 지표에는 보이지 않음 - 오픈소스 메인테이너가 이 벽에 가장 먼저·세게 부딪힘 — 그럴듯하지만 공허한 기여의 꾸준한 흐름이 선의여도 실제 트리아지 시간을 소모하며 이것이 탄광 속 카나리아, 기업이 다음 차례 - 잘 대응하는 곳은 리뷰 용량을 AI가 풀어준 여유가 아니라 **측정·보호·의도적으로 소비해야 할 실제 자원**으로 취급 ### 작성은 싸졌지만 이해는 그렇지 않았음 - 양극단의 일률적 답을 받아들이지 말 것 — 솔로·사용자 없음에게 엔터프라이즈의 churn·중복 공포담은 오늘의 불이 아닌 미래 위험이므로 테스트에 의존하고 중요한 것만 리뷰하되 이연된 일이 여전히 빚으로 남아 있음을 정직하게 인정 - 대규모·다수 사용자라면 여기 모든 경고 수치가 본인 얘기이며, 유일하게 유효한 것은 계층화·증거 요구·의도적으로 이질적인 리뷰 프로세스와 머지를 소유하는 사람 - 스펙트럼 전체에 걸쳐 변하지 않는 것은 근본 경제학 — 작성은 싸게 만들었고 이해는 늘 그래왔던 만큼 비싼 채로 남음 - 향후 잘하는 팀은 가장 많은 코드를 생성하는 팀이 아니라 **실제로 신뢰할 수 있는 리뷰 시스템**을 구축한 팀, "테스트가 통과했다"와 "사람이 이게 무엇을 왜 하는지 이해한다"를 절대 혼동하지 않는 팀 - Simon Willison의 표현처럼 일의 본질은 작동을 입증한 코드를 전달하는 것 — 에이전트는 이를 바꾸지 않았고 입증을 부차적 작업이 아닌 일의 중심으로 만듦 - 시스템을 충분히 이해해 그 뒤에 설 수 있는 능력이 소프트웨어에서 가장 지속적이고 흥미로운 기술이며, 이를 극도로 잘하게 될 더없이 좋은 시기 ## Comments _No public comments on this page._