Addy Osmani의 2026년 6월 15일 글 **“Agentic Code Review”**는 AI 코딩 에이전트가 보편화된 뒤 코드 리뷰의 의미가 어떻게 바뀌었는지 다룹니다. 글의 핵심은 단순합니다. 코드 작성은 기계 속도로 빨라졌지만, 사람이 변경을 이해하고 신뢰하는 속도는 거의 그대로이기 때문에 병목은 리뷰와 검증으로 이동했다는 것입니다.

원문: Agentic Code Review — Addy Osmani

1) 코드 작성은 싸졌고, 이해는 그대로 비싸다

과거 코드 리뷰는 속도의 균형 위에 있었습니다. 주니어가 코드를 작성하는 속도보다 시니어가 읽는 속도가 빨랐기 때문에, 리뷰는 자연스럽게 병목이 되지 않았습니다. 하지만 에이전트는 이 균형을 깨뜨립니다.

에이전트는 짧은 시간에 잘 포맷된 대량의 코드를 생성합니다. 반면 사람의 읽기 속도와 시스템 이해 속도는 거의 변하지 않았습니다. 따라서 엔지니어링의 중심 질문은 “얼마나 빨리 만들 수 있는가"에서 **“얼마나 빨리 신뢰할 수 있는가”**로 바뀝니다.

Addy가 강조하는 낙관적 지점은 여기에 있습니다. AI가 만든 코드가 문제라는 뜻이 아니라, AI가 만든 산출물을 신뢰 가능한 방식으로 검증하는 능력이 가장 큰 레버리지가 되었다는 뜻입니다.

2) 2026년 데이터가 보여주는 리뷰 압박

글은 여러 데이터 포인트를 통해 같은 결론을 제시합니다. AI는 산출량을 늘리지만, 그만큼 리뷰 가능성과 품질 압박도 키웁니다.

  • Faros AI 데이터: AI 채택이 높은 팀에서 code churn 861% 증가
  • incidents-to-PR ratio: 242.7% 증가
  • per-developer defect rate: 9%에서 54%로 증가
  • median review duration: 441.5% 증가
  • zero-review merge: 31.3% 증가
  • GitClear: 매일 AI를 쓰는 개발자는 raw output이 약 4배지만, 실제 생산성 증가는 약 12% 수준
  • GitHub: Copilot review는 6천만 건 이상 실행되었고, 플랫폼 리뷰 5건 중 1건 이상에 에이전트가 관여

여기서 중요한 수치는 단순히 “AI 코드가 나쁘다"가 아닙니다. 4배의 코드가 약 12%의 전달 가치로 이어진다면, 그 차액은 리뷰·검증·이해 비용으로 돌아온다는 점입니다.

특히 zero-review merge 증가는 위험합니다. 조직이 명시적으로 리뷰를 포기한 것이 아니라, 리뷰어가 산출량을 따라가지 못하면서 읽히지 않은 코드가 정상처럼 병합되기 시작했다는 신호이기 때문입니다.

3) 모든 팀이 같은 문제를 풀고 있지는 않다

Addy는 리뷰 강도를 하나의 정답으로 정하지 말라고 말합니다. 리뷰의 적정 수준은 세 변수에 따라 달라집니다.

  1. Blast radius — 깨졌을 때 아무도 다치지 않는가, 아니면 사용자·돈·개인정보가 걸려 있는가
  2. 코드 수명 — 다음 주에 버릴 프로토타입인가, 몇 년 동안 유지할 시스템인가
  3. 공유 이해 필요성 — 혼자 머릿속에 담아도 되는가, 팀이 장기적으로 공동 소유해야 하는가

솔로 개발자가 사용자 없는 greenfield 프로젝트를 만들고 있다면, 모든 diff를 깊게 읽는 것은 과할 수 있습니다. 대신 테스트와 자동화에 강하게 기대고, 중요한 부분만 리뷰하는 방식이 합리적입니다.

반대로 오래된 엔터프라이즈 시스템에서는 같은 접근이 위험합니다. 중복 helper 하나도 미래의 버그 표면이 되고, 아무도 이해하지 못한 변경은 온콜 사고로 이어지는 comprehension debt가 됩니다.

즉, 나쁜 조언의 대부분은 한 위치의 사람이 다른 위치의 사람에게 자기 규칙을 강요할 때 생깁니다.

4) 에이전트 PR의 진짜 문제: 사라진 의도

사람이 코드를 작성할 때는 의도가 작성자의 머릿속에 남아 있습니다. 리뷰어는 그 의도를 질문하고 확인할 수 있습니다. 하지만 에이전트가 만든 PR에서는 구현 과정의 추론, 버린 대안, 선택 이유가 diff에 남지 않는 경우가 많습니다.

그래서 리뷰어는 코드만 보고 “왜 이렇게 했는가"를 역추적해야 합니다. Addy는 이것이 리뷰 시간이 크게 늘어나는 핵심 원인 중 하나라고 봅니다.

해법은 의외로 실용적입니다.

  • 에이전트가 무엇을 하려 했는지 명시하게 한다.
  • 어떤 대안을 배제했는지 PR에 남긴다.
  • 테스트 결과와 실행 증거를 첨부한다.
  • 변경 의도를 decision log 형태로 보존한다.

이렇게 하면 리뷰어가 첫 번째 인간 독자가 되어 모든 맥락을 복원하는 부담을 줄일 수 있습니다. 핵심은 AI에게 리뷰를 더 시키는 것만이 아니라, 리뷰 가능한 PR을 만들도록 입구 조건을 높이는 것입니다.

5) AI 리뷰어는 하나의 판정자가 아니라 여러 센서다

글은 AI 리뷰 도구를 긍정적으로 평가합니다. CodeRabbit, Greptile, Anthropic Code Review, Sentry Seer, Cursor BugBot 같은 도구는 실제 버그를 잡고, 사람보다 지치지 않으며, 긴 PR 큐를 triage하는 데 유용합니다.

하지만 중요한 포인트는 “최고의 도구 하나"를 찾는 것이 아닙니다. 서로 다른 도구가 서로 다른 종류의 문제를 잡는다는 점입니다. 한 실험에서는 네 개 리뷰 도구가 617개의 distinct flagged location 중 93.4%를 각자 하나의 도구만 잡았고, 네 도구가 모두 같은 줄을 지적한 경우는 없었습니다.

따라서 high-stakes 변경에는 서로 다른 성격의 AI 리뷰어를 조합하는 편이 낫습니다.

  • 넓게 훑는 도구
  • correctness와 architecture에 강한 도구
  • production failure severity를 잘 보는 도구
  • 보안·프롬프트 인젝션 위험을 보는 도구

같은 모델 네 개를 돌리는 것은 비싼 단일 리뷰어에 가깝습니다. 반대로 다른 blind spot을 가진 도구를 조합하면 더 넓은 버그 표면을 볼 수 있습니다.

6) Human in the loop에서 human on the loop로

Addy는 “사람이 모든 줄을 읽어야 한다"는 전제가 이미 무너졌다고 봅니다. 산출량이 너무 커졌기 때문입니다. 하지만 그 반대편의 “AI가 작성하고 AI가 리뷰하고 AI가 승인하면 된다"도 위험합니다.

모델들이 같은 계열의 blind spot을 공유하면, 닫힌 루프는 매우 확신에 차 있으면서도 틀릴 수 있습니다. 이때 사람은 줄 단위 리뷰어가 아니라 다음을 책임지는 상위 레벨의 owner가 되어야 합니다.

  • 이 변경이 애초에 올바른 변경인지 판단
  • high-blast-radius 경로의 게이트 유지
  • AI 리뷰 결과를 verdict가 아니라 sensor로 취급
  • 샘플링과 spot-checking으로 리뷰 시스템 감사
  • merge 책임을 사람에게 고정

Addy가 자신의 오픈소스 프로젝트에서 Claude Code와 Codex를 쓰는 방식도 여기에 가깝습니다. AI에게 PR 묶음을 먼저 읽히고, 안전해 보이는 것·추가 작업이 필요한 것·위험한 것을 분류하게 합니다. 하지만 자동 병합하지는 않습니다. triage는 AI가 돕고, merge 결정은 사람이 갖는 구조입니다.

7) 실무 적용: 위험도 기반 리뷰 파이프라인

글의 실행 조언은 한 문장으로 정리할 수 있습니다. 모든 변경을 같은 깊이로 리뷰하지 말고, 틀렸을 때의 비용에 맞춰 리뷰 깊이를 조정하라.

위험도별 계층화

  • 단순 config 변경: linter, CI, 가벼운 확인
  • UI copy나 boilerplate: 자동 리뷰와 테스트 중심
  • 결제·인증·권한·개인정보 경로: 타입, 테스트, 서로 다른 AI 리뷰어 2개 이상, 시스템 owner 리뷰, 보안 검토

리뷰 입구 조건 강화

리뷰어가 코드를 보기 전에 다음을 요구해야 합니다.

  • 변경 목적
  • 지나치게 크지 않은 diff
  • 테스트 출력
  • 실제 실행했다는 증거
  • 중요한 설계 선택과 버린 대안

이는 리뷰어에게 의도 복원 비용을 떠넘기지 않기 위한 장치입니다.

작은 PR 강제

에이전트 PR은 커지기 쉽습니다. 하지만 큰 PR은 사람이 읽기 어렵고, 결국 거절되거나 rubber-stamp될 가능성이 커집니다. 이제 작은 diff는 예의가 아니라 리뷰 시스템의 설계 제약입니다.

테스트 변경 먼저 읽기

에이전트가 자주 저지르는 실패는 동작을 바꾼 뒤, 깨진 테스트를 고치는 대신 assertion을 새 동작에 맞게 바꿔버리는 것입니다. 테스트가 많이 수정된 PR에서는 구현보다 테스트 diff를 먼저 읽어야 합니다.

CI는 움직이지 않는 벽으로 유지

에이전트는 악의 없이도 green check를 얻기 위해 lint를 끄거나, coverage 기준을 낮추거나, 테스트를 제거할 수 있습니다. 결정론적 gate는 설득당하지 않는 마지막 방어선이므로 엄격하게 유지해야 합니다.

8) 팀을 운영한다면 무엇을 측정해야 하는가

AI 도입 후 관리자가 빠지기 쉬운 함정은 “코드 작성이 빨라졌으니 인력을 줄여도 된다"는 결론입니다. Addy는 이것이 위험하다고 봅니다. 병목이 작성에서 리뷰로 이동했을 뿐이라면, 리뷰 역량을 줄이는 것은 미래 사고를 사는 일입니다.

팀은 다음을 실제 자원처럼 측정해야 합니다.

  • 리뷰 대기 시간
  • time-to-first-review
  • 리뷰어별 병목
  • zero-review merge 비율
  • AI 생성 PR의 크기와 폐기율
  • 테스트 변경을 포함한 PR의 사고율
  • high-blast-radius 변경의 human owner 통과 여부

merged PR 수만 보면 대시보드는 초록색일 수 있습니다. 하지만 이해되지 않은 변경이 누적되면 속도는 나중에 incident, rollback, 온콜 부담으로 청구됩니다.

결론 및 시사점

한 줄 결론: AI 시대의 경쟁력은 코드를 더 많이 생성하는 능력이 아니라, 생성된 코드를 신뢰할 수 있게 만드는 리뷰 시스템을 설계하는 능력이다.

Addy Osmani의 글은 에이전트 코딩을 비관하지 않습니다. 오히려 에이전트가 충분히 좋아졌기 때문에, 이제 엔지니어링의 고급 업무가 코드 작성에서 검증·판단·책임으로 이동했다고 말합니다.

실무적으로는 세 가지를 당장 적용할 수 있습니다.

  1. 모든 PR에 같은 리뷰 강도를 적용하지 말고 blast radius에 따라 계층화한다.
  2. 에이전트 PR에는 변경 의도, 배제한 대안, 테스트 증거를 입구 조건으로 요구한다.
  3. AI 리뷰어는 판정자가 아니라 센서로 쓰고, merge 책임은 사람이 가진다.

결국 “테스트가 통과했다"와 “사람이 무엇이 왜 바뀌었는지 이해하고 책임질 수 있다"는 다릅니다. 에이전트가 바꾼 것은 이 차이를 더 선명하게 만든 것입니다.