에이전틱 코드 리뷰

• 코딩 에이전트의 급격한 성능 향상으로 엔지니어링의 어려운 지점이 코드 작성에서 그 코드를 신뢰할지 판단하는 일로 이동, 리뷰가 가장 레버리지 높은 작업이 됨
• 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의 표현처럼 일의 본질은 작동을 입증한 코드를 전달하는 것 — 에이전트는 이를 바꾸지 않았고 입증을 부차적 작업이 아닌 일의 중심으로 만듦
• 시스템을 충분히 이해해 그 뒤에 설 수 있는 능력이 소프트웨어에서 가장 지속적이고 흥미로운 기술이며, 이를 극도로 잘하게 될 더없이 좋은 시기