새소식

300x250
AI/Workflow : 자동화

AI가 코드를 짜는 시대, 코드 리뷰는 어떻게 바뀌어야 하나? - Simon Willison이 말하는 AI 시대 개발자의 책임

  • -
728x90

안녕하세요! 갓대희 입니다.

당신 팀의 PR 리뷰 속도가 코드 생산 속도를 따라가고 있는가? 솔직히 말하면, 이미 따라가지 못하고 있을 가능성이 높다. Claude Code 같은 AI 코딩 도구 덕분에 개발자 1인당 코드 생산량이 200% 증가했지만(출처: Anthropic 공식 블로그), 리뷰어의 인지 용량은 그대로다.

 

이 문제를 풀기 위해 Anthropic은 Claude Code Review라는 자동화 도구를 만들었다. 하지만 도구가 생겼다고 해서 더 근본적인 질문이 사라지진 않는다. AI가 코드의 다수를 생성하는 시대에, 인간 리뷰어는 무엇을 해야 하는가?

 

목차

  1. 문제: 생산성과 리뷰 역량의 불균형
  2. 주장 1 — 인간 리뷰는 여전히 필수다
  3. 주장 2 — 전통적 코드 리뷰 모델은 이미 무너졌다
  4. 해법 — 리뷰의 대상을 바꿔라: Intent Review
  5. 실전 적용: Intent Review 체크리스트 + 역할 분담
  6. 결론: AI 네이티브 엔지니어의 새로운 책임

1. 문제: 생산성과 리뷰 역량의 불균형

SmartBear의 코드 리뷰 연구(Cisco 시스템 2,500건 분석)에 따르면, 400줄을 넘어가면 결함 발견율(defect detection rate)이 급격히 떨어진다. 그런데 AI 코딩 도구를 쓰는 개발자는 한 번에 수백에서 수천 줄짜리 PR을 생성하는 일이 일상이 됐다. 리뷰해야 할 분량은 폭발적으로 늘었지만, 인간 리뷰어의 인지 용량에는 물리적 한계가 있다.

 

이 불균형을 Shannon의 정보 이론으로 처음 설명한 사람은 Dave Farley(Jez Humble과 함께 쓴 'Continuous Delivery' 공저자)다. Nyquist-Shannon 샘플링 정리를 코드 리뷰에 적용해 이렇게 설명한다. "신호를 정확히 재현하려면, 신호의 최고 주파수보다 두 배 이상 빠르게 샘플링해야 한다." AI가 코드를 생성하는 속도가 인간이 리뷰할 수 있는 속도를 초과하면, 리뷰를 해도 신호 재현이 불가능해진다는 것이다. Bryan Finster는 이 아이디어를 자신의 에세이 "AI Broke Your Code Review"에서 소개하며 실전 코드 리뷰에 적용했다. (출처: bryanfinster.substack.com) 쉽게 말하면, 리뷰는 하는 척만 하게 된다는 뜻이다.

 

이 문제에 대해 업계는 두 가지 상반된 입장으로 나뉜다.

 

2. 주장 1 — 인간 리뷰는 여전히 필수다

첫 번째 입장은 명확하다. AI가 코드를 쓰더라도, 그 코드에 대한 책임은 여전히 인간에게 있다는 것이다.

Simon Willison (Django 공동 창시자, Datasette 창시자)
"Your job is to deliver code you have proven to work."
검증 없이 대규모 PR을 제출하는 것은 "This is rude, a waste of other people's time, and is honestly a dereliction of duty as a software developer"라고도 덧붙였다.
(출처: simonwillison.net, 2025-12-18)

 

이 관점에서 코드 리뷰는 품질 게이트가 아니라 책임 이전의 마지막 관문이다. AI가 얼마나 그럴듯한 코드를 만들어도, 그 코드가 시스템에서 어떻게 동작할지, 보안 취약점이 있는지, 비즈니스 규칙과 맞는지는 인간이 판단해야 한다.

Kent Beck (XP 창시자, TDD 선구자)
Kent Beck은 "Thinking About Code Review"에서 코드 리뷰의 목적을 5가지로 정의한다. 결함 감소(behavioral/structural errors)뿐 아니라 팀 이해 향상(Improve team understanding), 학습 가속, 팀 위험 감소가 포함된다. 리뷰는 버그 찾기 도구가 아니라 팀이 코드를 함께 소유하고 이해하는 수단이다.
(참고: tidyfirst.substack.com — Thinking About Code Review — AI 미언급, 일반 코드 리뷰 방법론)

 

Google Engineering 리더 Addy Osmani도 "Code Review in the Age of AI"에서 AI 생성 코드의 함정을 경고했다. AI가 코드를 더 빠르게 만들어줄수록, 그것이 실제로 올바른지 검증하고 유지보수 가능한지 판단하는 인간의 능력이 오히려 더 중요해진다는 것이다. (참고: addyo.substack.com — Code Review in the Age of AI)

이 주장의 핵심
  • 코드의 최종 책임은 머지를 승인한 인간에게 있다
  • AI 생성 코드를 이해하는 능력이 더 중요해진다
  • 리뷰는 품질 검증이자 책임 이전의 관문이다

 

3. 주장 2 — 전통적 코드 리뷰 모델은 이미 무너졌다

그러나 현실을 직시하는 두 번째 입장이 있다. 인간 리뷰가 이상적이라는 건 알지만, 현재의 코드 리뷰 방식은 이미 구조적으로 작동하지 않는다는 것이다.

 

데이터 포인트 출처 시사점
400줄 이상 PR에서 결함 발견율(defect detection rate) 급감 SmartBear — Cisco 2,500건 리뷰 분석 AI PR은 대부분 400줄 초과
AI 코딩 도구 도입 후 개발자 코드 생산량 200% 증가 Anthropic 내부 데이터 리뷰 부담 2배 이상 증가
AI 도입 전 리뷰 커버리지 16%에 불과 Anthropic 내부 데이터 AI 도입 전에도 리뷰는 제대로 안 됐다

SmartBear 수치는 업계에서 광범위하게 인용되는 연구 결과이며, Anthropic 데이터는 공식 블로그에서 확인 가능하다.

 

Bryan Finster는 자신의 에세이 "AI Broke Your Code Review"에서 Dave Farley의 Nyquist-Shannon 적용을 이렇게 소개한다. AI가 신호를 생성하는 주파수(코드 생산 속도)가 인간이 샘플링하는 주파수(리뷰 속도)의 두 배를 초과하면, 신호 재현이 불가능해진다. 즉, 인간이 아무리 열심히 리뷰해도 AI 생산 속도를 감당할 수 없는 구조적 한계가 있다는 것이다.

(출처: bryanfinster.substack.com — AI Broke Your Code Review)

 

AI 생성 코드의 또 다른 역설이 있다. 표면적으로 깔끔하고 패턴이 일관돼 보이기 때문에, 오히려 리뷰어가 주의를 덜 기울이게 된다. "그럴듯해 보임"이 "올바름"으로 오해되는 것이다. Stanford Law School CodeX 센터는 "Built by Agents, Tested by Agents, Trusted by Whom?"이라는 글에서 이를 신뢰 귀속 문제로 분석했다. 같은 AI 모델이 코드를 작성하고 테스트까지 수행하면 검증의 독립성이 사라진다. 나아가 "인간이 수년 전부터 코드 읽기를 멈추면, 장애를 이해하는 데 필요한 제도적 지식이 소멸할 것(the institutional knowledge required to understand the failure will have atrophied, because the humans stopped reading code years ago)"이라고 경고한다.

(참고: Stanford CodeX, 2026-02-08)

 

Salesforce의 내부 AI 코드 리뷰 도구 Prizm을 개발한 경험도 시사적이다. AI 코드 생산량이 급증하면서 기존 리뷰 프로세스가 병목이 됐고, Salesforce Engineering 팀은 AI 보조 리뷰 도입 없이는 품질 관리가 불가능해졌다고 공개했다.

(출처: Salesforce Engineering Blog)

반론의 핵심
  • SmartBear 400줄 한계와 AI의 수백~수천 줄 생산 — 전통적 리뷰는 구조적으로 실패한다
  • Nyquist-Shannon: 생산 속도가 리뷰 속도를 초과하면 정보 손실은 필연이다
  • "그럴듯해 보임" 편향 — AI 코드가 오히려 더 얕은 리뷰를 부른다

 

4. 해법 — 리뷰의 대상을 바꿔라: Intent Review

첫 번째 주장은 옳다. 책임은 여전히 인간에게 있다. 그런데 두 번째 주장도 옳다. 기존 방식의 diff 리뷰는 AI 시대에 구조적으로 작동하지 않는다. 그렇다면 어떻게 해야 하는가?

 

해법은 단순하다. 리뷰의 대상을 코드 diff에서 의도(Intent)로 바꿔라.

 

Aviator 창립자 Ankit Jain이 latent.space에 쓴 에세이 "How to Kill the Code Review"는 이 방향을 명확히 제시한다. "인간은 스펙, 계획, 제약 조건, 수용 기준을 리뷰해야 한다. 500줄짜리 diff가 아니라(Humans should review specs, plans, constraints, and acceptance criteria—not 500-line diffs)." 리뷰의 질문이 '이 코드를 올바르게 작성했는가?'에서 '우리가 올바른 문제를 올바른 제약 조건으로 풀고 있는가?'로 바뀐다는 것이다.

(출처: latent.space — How to Kill the Code Review)

Swiss Cheese Model — 5가지 방어 레이어

비행기 사고 분석에서 차용한 Swiss Cheese 모델을 코드 리뷰에 적용하면, 각 레이어의 구멍이 일치할 때만 버그가 통과한다. 어떤 단일 리뷰도 완벽할 수 없으므로, 레이어를 겹쳐 방어한다.

  1. 스펙 리뷰 — "이 요구사항이 올바른가?" (코드 작성 전)
  2. AI 자동 리뷰 — 패턴, 보안, 스타일 자동 검사 (Claude Code Review 등)
  3. Intent 리뷰 — "이 코드가 스펙을 실현하는가?" (인간 리뷰어)
  4. 통합 테스트 — "시스템 전체에서 기대대로 동작하는가?"
  5. 모니터링 — "프로덕션에서 실제로 문제없는가?"

 

Finster와 여러 업계 논의를 종합하면, 인간 리뷰어가 코드 머지를 블로킹해야 하는 조건은 두 가지로 좁힐 수 있다. 코드 품질이나 스타일이 아니라:

  • 조건 1: 이 변경이 의도한 비즈니스 결과를 달성하지 못한다
  • 조건 2: 이 변경이 알려진 위험(보안, 데이터, 가용성)을 도입한다

나머지(스타일, 컨벤션, 간단한 버그 패턴)는 자동화에 맡기고 인간은 의도와 위험 판단에 집중한다.

 

Qodo(구 CodiumAI)의 "State of AI Code Quality 2025" 리포트(609명 개발자 대상)에서도 관련 패턴이 확인됐다. AI 자동 리뷰와 인간 리뷰를 결합한 개발자 중 81%가 코드 품질 개선을 체감했으며, 미활용 팀은 55%에 그쳤다(개발자 체감 기준). 이는 AI가 기계적 검사를 처리하고 인간이 더 높은 수준의 판단에 집중하는 분업 구조가 효과적임을 시사한다.

(출처: Qodo — State of AI Code Quality 2025)

 

5. 실전 적용: Intent Review 체크리스트 + 역할 분담

이론은 충분하다. 내일 스탠드업에서 팀에게 공유할 수 있는 실전 프레임워크를 제시한다.

 

5-1. Intent Review 체크리스트

PR을 열었을 때, diff를 읽기 전에 먼저 이 질문들에 답하라:

PR 리뷰 시작 전 — Intent 확인 (2분)
  • PR 제목/설명에서 "왜" 이 변경이 필요한지 명확히 설명했는가?
  • 이 PR이 해결하려는 비즈니스 문제/유저 시나리오가 무엇인가?
  • 해당 기능의 스펙(티켓, 요구사항 문서)을 확인했는가?
  • 이 변경이 의도하지 않은 사이드 이펙트를 일으킬 수 있는 영역은?
블로킹 여부 판단 — 업계 논의 종합 기준 (3분)
  • 이 변경이 의도한 비즈니스 결과를 달성하지 못하는가? → Yes → 블로킹
  • 이 변경이 보안/데이터/가용성 리스크를 새로 도입하는가? → Yes → 블로킹
  • 위 두 조건이 모두 No → 나머지는 자동화(AI 리뷰)에 맡기고 승인 고려

 

5-2. AI 도구 vs 인간 리뷰어 역할 분담

AI 리뷰 도구(Claude Code Review 등)와 인간 리뷰어가 각각 잘하는 것이 다르다. 역할을 명확히 나누면 효율이 올라간다.

리뷰 영역 AI 자동 리뷰 인간 리뷰어 근거
코드 스타일 / 컨벤션 AI - 패턴 매칭, 린터 연동
보안 취약점 패턴 AI (1차) 인간 (최종) AI 검출 + 인간 맥락 판단
테스트 커버리지 확인 AI - 수치 측정, 미커버 영역 검출
비즈니스 로직 정확성 - 인간 스펙 이해, 도메인 지식 필요
시스템 아키텍처 영향 - 인간 전체 시스템 맥락 파악 필요
UX / 사용자 경험 판단 - 인간 사용자 공감, 직관적 판단
기존 버그 / 회귀 탐지 AI (1차) 인간 (확인) AI 검출 + 인간 우선순위 판단

이 역할 분담 매트릭스는 업계 논의와 필자의 관찰을 종합한 의견이다. 팀의 상황에 따라 조정이 필요하다.

 

5-3. 팀에 적용하기 위한 3단계

  1. 스펙을 PR의 필수 요소로 만들어라 — PR 템플릿에 "해결하려는 비즈니스 문제"와 "예상 동작"을 필수 항목으로 추가한다. 리뷰어가 Intent를 파악할 재료를 PR 작성자가 제공해야 한다.
  2. AI 자동 리뷰를 1차 게이트로 세워라 — Claude Code Review, GitHub Copilot 코드 리뷰 등으로 스타일·보안·테스트 커버리지를 자동 처리한다. 인간이 그 부분에 쓰는 시간을 Intent 검토로 돌린다.
  3. 블로킹 기준을 명확히 선언하라 — "비즈니스 목표 미달" 또는 "알려진 위험 도입" 두 조건만 블로킹 사유로 팀 내 합의한다. 스타일 논쟁은 자동화에 위임하고, 인간은 가치 판단에 집중한다.

 

6. 결론: AI 네이티브 엔지니어의 새로운 책임

Flowkater.io에 게재되어 GeekNews를 통해 주목받은 에세이 "AI 시대에 코드 리뷰, 어떻게 해야할까?"(2026-03-08, Tony Cho)에서, 저자는 글 말미에 솔직하게 고백한다. "나는 지금 내가 AI로 작성한 코드를 직접 리뷰하지 않는다. 대신 QA의 역할을 한다." "이 코드가 어떻게 작동하는가"를 확인하는 것을 멈추고, "이 시스템이 내가 원하는 결과를 내는가"를 검증하기 시작했다는 것이다.

 

이것은 포기가 아니다. 역할의 진화다. AI 네이티브 엔지니어는 점점 더 PM의 사고방식을 내면화해야 한다. 코드를 어떻게 쓰는지보다, 무엇을 왜 만드는지를 더 명확하게 정의하고, 그 정의가 최종 결과물에서 실현됐는지를 검증하는 능력이 핵심이 된다.

"당신은 당신이 머지한 코드에 책임을 질 수 있는가?
AI가 썼다는 건 변명이 되지 않는다.
책임질 수 있는 엔지니어가 AI 네이티브 시대의 진짜 고수다."

핵심 정리
  • 주장 1: AI 코드도 최종 책임은 인간에게 있다 (Simon Willison, Kent Beck)
  • 주장 2: 전통적 diff 리뷰는 AI 생산 속도를 구조적으로 감당할 수 없다 (코드 생산량 vs. 리뷰 용량의 한계)
  • 해법: 리뷰 대상을 코드 diff → Intent(의도)로 전환하라. AI는 "how"를 검사하고, 인간은 "why"와 "what"을 검증한다
  • 블로킹 기준: ① 비즈니스 목표 미달 ② 알려진 위험 도입 — 이 두 가지만 인간이 블로킹한다
  • 실천: PR 템플릿에 Intent 추가, AI 자동 리뷰 1차 게이트화, 블로킹 기준 팀 합의
이 철학을 실천하는 구체적 도구가 궁금하다면

Intent Review를 지원하는 AI 코드 리뷰 도구 중 하나가 Claude Code Review다. Anthropic이 내부에서 수개월 운영하며 검증한 멀티 에이전트 리뷰 시스템으로, 코드 스타일·보안·테스트 커버리지를 자동 처리해 인간 리뷰어가 Intent에 집중할 수 있도록 돕는다. 설정 방법, 비용, 커스터마이징까지 공식 문서 기반으로 정리한 가이드를 참고하라.

 

참고 자료

 

300x250
Contents

포스팅 주소를 복사했습니다

이 글이 도움이 되었다면 공감 부탁드립니다.

💡 AI 관련 질문이 있나요? 눌러보세요!