리뷰 단계가 속도를 10배 느리게 만든다

게시 2026/03/21

By BLUEBUG

51 분읽는 시간

AI 시대의 소프트웨어 엔지니어링 품질 문화 완전 가이드

원문: Every layer of review makes you 10x slower — Avery Pennarun (Tailscale CEO), 2026년 3월 16일
한국어 해설 및 가이드 작성일: 2026년 3월 21일

글의 배경과 저자 소개
핵심 법칙: 리뷰 단계 하나 = 10배 지연
왜 AI 코딩 도구는 이 문제를 해결하지 못하는가
AI 개발자의 광기 하강 곡선
그렇다면 왜 우리는 리뷰를 하는가
품질 보증(QA)이 오히려 품질을 낮추는 이유
Toyota Production System과 신뢰의 철학
리뷰어의 진짜 역할: 리뷰를 불필요하게 만들기
모듈화: 구조적 해법
AI 시대의 조직 설계 전략
2026년 현재의 맥락: 산업 동향
실천 가이드: 팀에서 적용하는 법
핵심 요약 및 결론

1. 글의 배경과 저자 소개

이 글은 Tailscale의 공동창업자이자 CEO인 Avery Pennarun이 2026년 3월 16일 자신의 블로그 apenwarr.ca에 게재한 글입니다. Tailscale은 WireGuard 기반의 네트워크 보안 솔루션으로 잘 알려진 회사이며, Pennarun은 수십 년간의 엔지니어링 경험을 바탕으로 소프트웨어 조직 설계와 시스템 철학에 대한 통찰력 있는 글들을 지속적으로 써왔습니다.

이 글은 단순한 코드 리뷰 개선 팁을 넘어서, AI 코딩 도구가 급속히 보편화되는 2026년 현재, 소프트웨어 엔지니어링 조직이 직면한 근본적인 구조적 문제를 해부합니다. Claude Code, Cursor, GitHub Copilot 등의 AI 에이전트가 코드 작성 속도를 극적으로 높이고 있음에도 불구하고, 전체 개발 사이클의 속도가 예상만큼 빨라지지 않는 이유를 날카롭게 분석합니다.

Hacker News와 GeekNews(긱뉴스)에서 큰 반향을 일으켰으며, 많은 시니어 개발자와 엔지니어링 리더들이 “내 직관과 경험을 명확하게 정리해준 글”이라고 평가하고 있습니다.

2. 핵심 법칙: 리뷰 단계 하나 = 10배 지연

법칙의 정의

Pennarun이 소개하는 법칙은 다음과 같습니다.

승인 단계가 하나 추가될 때마다, 프로세스 전체가 10배 느려진다.

이 법칙은 이론적 근거가 명확하지 않음에도 불구하고, 수십 년에 걸쳐 현실에서 반복적으로 관찰되어 온 경험 법칙입니다. 처음 들으면 과장처럼 느껴지지만, 실제 업무 현장을 돌이켜보면 섬뜩할 정도로 정확합니다.

중요한 전제: 노력(Effort)이 아닌 벽시계 시간(Wall Clock Time)

이 법칙에서 측정하는 시간은 실제 작업에 투입되는 노력의 양이 아닙니다. 요청이 시작된 순간부터 완료될 때까지 흘러가는 실제 달력 시간, 즉 벽시계 시간입니다. 추가되는 시간의 대부분은 순수한 대기 시간입니다. 누군가의 일정에 올라가길 기다리고, 회의를 잡고, 피드백을 기다리는 시간입니다.

단계별 실제 수치

아래 표는 동일한 작업이 리뷰 단계가 추가될수록 얼마나 느려지는지를 보여줍니다.

단계	작업 내용	소요 시간
0단계	간단한 버그 수정 코딩	30분
1단계	옆자리 동료의 코드 리뷰	300분 (약 5시간, 반나절)
2단계	아키텍트 팀의 설계 문서 승인	50시간 (약 1주)
3단계	다른 팀 일정에 올리기 (고객 기능 요청 등)	500시간 (12주, 1 회계 분기)
4단계	그 이상	10 분기 (약 2.5년) — 비현실적으로 보이지만 실재함

각 단계마다 정확히 10배씩 증가하는 것이 눈에 띕니다. 저자는 Tailscale처럼 비교적 소규모 회사에서도 제품 방향을 전환하려 할 때 4단계에 해당하는 지연을 실제로 경험한다고 고백합니다.

이 법칙이 중요한 이유

네트워크 효과 법칙처럼, 팀 규모가 두 배가 된다고 해서 생산성이 두 배가 되지 않습니다. 조정 오버헤드(coordination overhead)가 발생하기 때문입니다. 마찬가지로, 리뷰 단계를 줄이지 않고 첫 번째 단계(코딩)만 빠르게 만들어봤자 전체 파이프라인의 속도는 크게 개선되지 않습니다. 이것이 AI 코딩 도구의 한계를 이해하는 데 있어 핵심입니다.

3. 왜 AI 코딩 도구는 이 문제를 해결하지 못하는가

AI의 실제 기여

Claude, GPT-4o, Gemini와 같은 AI 코딩 어시스턴트, 그리고 Claude Code, Cursor, Cline과 같은 에이전틱 코딩 도구들은 코드 작성 속도를 극적으로 높였습니다. 30분 걸리던 버그 수정을 3분 만에 해내는 것은 분명 인상적입니다. 2026년 기준으로 전체 개발자의 약 85%가 AI 코딩 도구를 정기적으로 사용하고 있으며, 전체 코드의 약 41%가 AI의 도움을 받아 작성되고 있습니다.

그러나 병목은 여전히 존재한다

문제는 AI가 아무리 코딩을 빠르게 해도, 그 이후의 리뷰 파이프라인은 전혀 빨라지지 않는다는 점입니다. 시나리오를 살펴보겠습니다.

시나리오 A: 작은 버그 수정에 AI를 사용한 경우

AI가 3분 만에 코드를 작성해 줌 (27분 절약)
개발자는 두 가지 선택지를 갖게 됨
- 선택지 1: 절약한 27분으로 AI와 직접 코드를 검토하고 반복 개선
- 선택지 2: 검토하지 않은 코드를 그대로 리뷰어에게 넘김
리뷰어는 여전히 5시간이 필요하며, 검토되지 않은 코드를 받은 리뷰어는 불쾌해함
결론: 얻은 것이 거의 없음

시나리오 B: 대규모 프로젝트에 AI 에이전트를 사용한 경우

1주일 걸릴 대형 프로젝트를 Claude와 함께 2시간 만에 완성
결과물이 너무 커서 리뷰어가 한 번에 검토 불가능
작은 단위로 분할 → 각각 5시간의 리뷰 사이클 필요
설계 문서 없이 의도적 아키텍처도 없으므로 → 설계 리뷰 회의 개최 필요
결론: 2시간에 완성한 프로젝트가 다시 1주일로 돌아감

AI는 파이프라인의 첫 단계만 빠르게 한다

AI는 파이프라인 첫 단계인 ‘코딩’ 속도를 극적으로 향상시킵니다. 하지만 그 이후의 검토, 승인, 배포 단계는 전혀 건드리지 못합니다. 이것은 공장의 생산 라인에서 조립 속도만 두 배로 올리고 품질 검사 라인의 속도는 그대로 둔 것과 같습니다. 조립 라인만 빠르면 결국 품질 검사 앞에 재고가 쌓이고, 전체 처리량(throughput)은 거의 나아지지 않습니다.

이것이 리틀의 법칙(Little’s Law) 과 대기행렬 이론(Queueing Theory) 이 말하는 핵심이기도 합니다. 시스템의 전체 처리 속도는 가장 느린 단계에 의해 결정됩니다.

4. AI 개발자의 광기 하강 곡선

저자가 소개하는 가장 흥미로운 관찰 중 하나는 “AI 개발자의 광기 하강 곡선(AI Developer’s Descent Into Madness)” 입니다. 이는 많은 개발자들이 AI 코딩 도구를 무비판적으로 사용하다가 빠지는 함정을 단계별로 묘사합니다.

8단계 하강 패턴

1단계: 흥분 프로토타입을 놀랍도록 빠르게 만들어냄. “나 초능력 생겼다!”

2단계: 버그 발생 프로토타입에 버그가 생기기 시작함. AI에게 수정을 지시함.

3단계: 버그의 순환 고치는 것만큼 새로운 버그가 생겨남. AI가 자신이 만든 맥락을 이해하지 못하기 시작함.

4단계: AI에게 리뷰를 맡기자 “AI 에이전트가 코드를 리뷰하면 자신의 버그를 찾을 것이다!” → 잘못된 기대.

5단계: 에이전트 간 데이터 전달 자기도 모르게 에이전트들 사이에서 데이터를 직접 넘겨주고 있는 자신을 발견함.

6단계: 프레임워크 필요 인식 에이전트 프레임워크가 필요하다는 것을 깨달음.

7단계: 에이전트로 프레임워크를 만들기 에이전트를 써서 에이전트 프레임워크를 작성하기로 결정.

8단계: 1단계로 귀환 새로운 프레임워크로 다시 프로토타입을 만들기 시작. 사이클 반복.

이 패턴이 위험한 이유

이 순환의 근본 문제는 리뷰와 검증을 AI에게 위임함으로써 품질 책임 소재가 불명확해진다는 것입니다. AI는 자신이 작성한 코드의 품질에 책임을 지지 않습니다. 또한 AI는 자신이 이전에 작성한 코드의 전체 맥락을 유지하는 데 한계가 있기 때문에, 한 버그를 고치면서 다른 부분에 새 버그를 만드는 일이 반복됩니다.

저자는 자신이 존경하는 엔지니어 동료들이 이 사이클에 빠지는 것을 목격하고 있다고 우려합니다. Claude Code가 본격적으로 사용 가능해진 것이 불과 몇 달 전임을 고려하면, 이 현상은 이제 막 시작되었습니다.

5. 그렇다면 왜 우리는 리뷰를 하는가

조직이 커질수록 리뷰가 늘어나는 이유

회사가 성장하면 자연스럽게 협업, 리뷰, 관리 단계가 증가합니다. 이는 의도적인 선택이기도 하고, 조직의 자연스러운 진화이기도 합니다. 그 이유는 다음과 같습니다.

첫째, 실수의 비용이 커진다. 작은 스타트업에서는 코드 버그 하나가 수십 명의 사용자에게 영향을 미칩니다. 수백만 사용자를 가진 기업에서는 동일한 버그가 훨씬 큰 피해를 초래합니다.

둘째, 새로운 기능의 평균 가치가 낮아진다. 성숙한 제품에서 추가 기능이 가져오는 가치는 초기보다 낮고, 그 기능이 도입하는 버그의 잠재적 손해가 더 크게 느껴지기 시작합니다.

셋째, 신기능의 가치를 높이는 것보다 손해를 줄이는 것이 더 쉬워 보인다. 결국 조직은 새로운 가치 창출보다 리스크 관리에 집중하게 됩니다.

통제와 품질의 관계

표면적으로 보면, 검수와 통제를 늘리면 품질이 단조적으로(monotonically) 증가합니다. 이것은 지속적 개선(Continuous Improvement)의 기반처럼 보입니다. 그러나 저자는 이것이 잘못된 방향이라고 주장합니다. “더 많은 통제”는 품질을 높이는 여러 방법 중 하나일 뿐이며, 게다가 매우 위험한 방법입니다.

6. 품질 보증(QA)이 오히려 품질을 낮추는 이유

수학 모델 vs. 현실

단순 수학적 모델에서는 QA 단계를 추가할수록 품질이 올라갑니다. 각 QA 단계가 결함의 90%를 잡아낸다면, 두 단계를 거치면 결함이 100분의 1로 줄어듭니다. 논리적으로 완벽해 보입니다.

그러나 자율적 인간 행위자(agentic humans) 가 개입하는 현실에서는 전혀 다른 일이 벌어집니다. 인센티브가 왜곡됩니다.

인센티브 왜곡의 세 가지 패턴

패턴 1: 2차 QA 팀의 무임승차 2차 QA 팀은 실질적으로 1차 QA 팀을 평가하는 역할을 합니다. 만약 1차 팀이 지속적으로 결함을 놓친다면 해고될 수 있습니다. 그렇다면 2차 팀이 동료의 해고를 초래할 결과를 적극적으로 찾을 인센티브가 있을까요? 없습니다. 오히려 “1차 팀이 놓쳤으니 우리가 놓쳐도 이상하지 않다”는 식으로 느슨하게 검수하게 됩니다.

패턴 2: 1차 QA 팀의 책임 전가 1차 QA 팀은 2차 팀이 있다는 사실을 알고 있습니다. “설마 내가 놓치더라도 2차 팀에서 잡겠지”라는 생각으로 오늘 최선을 다하지 않을 수 있습니다. 2차 팀이 존재하기 때문에 1차 팀의 노력이 오히려 줄어드는 역설이 발생합니다.

패턴 3: 제조 팀의 자체 검수 소홀 위젯을 만드는 팀도 QA 팀이 있다는 것을 알기 때문에 자체 검수를 소홀히 합니다. 100개 중 10개에 결함이 있더라도, 각 위젯을 20% 더 조심스럽게 만드는 것보다 QA에서 10%를 폐기하는 것이 더 효율적으로 느껴집니다. 또한 속도가 20% 느려지면 해고될 수도 있습니다.

결과

이러한 인센티브 구조에서는 QA 단계가 추가될수록 각 단계의 실질적 효과가 줄어들고, 전체 시스템의 품질 문화가 오히려 퇴보합니다. 더 심각한 것은, QA 파이프라인이 근본 원인을 숨기는 역할을 한다는 것입니다. 문제가 중간에 걸러지기 때문에 애초에 왜 그 문제가 발생했는지 추적하기 어려워집니다.

이것은 소프트웨어 업계에서도 동일하게 관찰됩니다. 스테이징 환경, 코드 리뷰, QA 테스터, 베타 테스트 단계가 여러 겹 쌓인 조직일수록, 각 단계에서 “다음 단계에서 잡히겠지”라는 안일함이 퍼져 있는 경우가 많습니다.

7. Toyota Production System과 신뢰의 철학

W. E. Deming과 일본 제조업의 혁신

W. E. Deming은 20세기 중반 일본 자동차 제조업에 품질 혁신을 가져온 미국인 통계학자입니다. 그의 철학은 단순히 검사 단계를 늘리는 것이 아니라, 품질을 프로세스 자체에 설계해 넣는 것(quality by design) 이었습니다.

그 결과물이 바로 Toyota Production System(TPS) 입니다. TPS의 핵심 중 하나는 별도의 QA 단계를 완전히 제거한 것입니다. 대신, 모든 라인 작업자에게 결함을 발견하는 즉시 라인을 멈출 수 있는 버튼(Andon 시스템)을 부여했습니다.

미국 자동차 회사의 실패 사례

흥미롭게도, 미국 자동차 회사들도 동일한 버튼을 설치했습니다. 그러나 아무도 그 버튼을 누르지 않았습니다. 이유는 단 하나, 해고가 두려웠기 때문입니다.

이 에피소드는 시스템보다 문화가 더 중요하다는 것을 보여줍니다. 도구나 프로세스는 복제할 수 있지만, 그 안에 흐르는 신뢰와 인센티브는 복제할 수 없습니다.

신뢰의 세 가지 층위

저자는 Toyota 시스템이 성공하고 미국 시스템이 실패한 근본 이유를 신뢰(Trust) 라고 분석합니다. 이 신뢰는 세 가지 층위에서 작동합니다.

개인 간 신뢰(Individual Trust) 라인 작업자가 “내 상사가 진심으로 모든 결함에 대해 알고 싶어한다”고 믿을 수 있어야 합니다. 문제를 발견했을 때 라인을 멈춰야 한다는 것, 그리고 그 행동이 처벌이 아닌 격려를 받는다는 것을 믿어야 합니다.

관리자 간 신뢰(Managerial Trust) 팀 관리자들이 “우리 경영진이 품질에 대해 진지하다”고 믿어야 합니다. 일시적인 생산량 감소를 감수하면서도 품질 문제를 직면하겠다는 경영진의 의지를 신뢰해야 합니다.

경영진의 시스템 신뢰(Executive Trust in Systems) 경영진이 “올바른 시스템과 인센티브가 주어지면, 개인들은 스스로 품질 높은 작업을 하고 결함을 발견하며 적시에 멈춤 버튼을 누를 것이다”라고 믿어야 합니다.

추가 조건: 실제로 작동하는 시스템 모든 신뢰의 전제 조건은 “이 시스템이 실제로 작동한다”는 신뢰입니다. 따라서 먼저 제대로 작동하는 시스템을 구축하는 것이 선행되어야 합니다.

소프트웨어에 적용

소프트웨어 팀에서 이 원칙을 적용한다면, 코드를 배포하다가 문제를 발견했을 때 “아직 테스트 중이고 버그가 발견되었습니다”라고 즉시 보고할 수 있는 문화가 필요합니다. 그 보고가 처벌이 아닌 정보로 처리되고, 팀 전체가 학습하는 계기가 되어야 합니다.

8. 리뷰어의 진짜 역할: 리뷰를 불필요하게 만들기

패러다임 전환

저자는 코드 리뷰에 대한 근본적인 패러다임 전환을 제안합니다.

코드 리뷰어의 역할은 코드를 리뷰하는 것이 아니다.
자신의 리뷰 코멘트 자체를 미래에 불필요하게 만드는 것이 역할이다.

이 말은 처음에 역설처럼 들리지만, 깊이 생각해보면 매우 합리적입니다. 리뷰어가 “이 변수명이 명확하지 않다”는 코멘트를 달았다면, 진짜 할 일은 그 코멘트를 다는 것이 아니라 왜 그런 변수명이 나왔는지를 분석하고, 다시는 그런 코멘트가 필요 없도록 시스템을 개선하는 것입니다.

`go fmt`의 사례

Go 프로그래밍 언어의 go fmt 도구를 만든 사람들은 코드 리뷰에서 반복적으로 등장하는 “공백 스타일”에 관한 코멘트를 영구적으로 없애버렸습니다. 포매팅 도구를 만들어서, 그 종류의 리뷰 코멘트가 다시는 나타나지 않도록 한 것입니다. 저자는 이것이 진정한 엔지니어링이라고 말합니다.

리뷰가 실수를 발견하는 시점은 이미 실수가 일어난 이후입니다. 근본 원인은 이미 발생한 것입니다. 리뷰는 항상 사후적입니다. 그렇다면 리뷰보다 근본 원인을 제거하는 데 집중해야 하지 않을까요?

Five Whys와 포스트모템

조직에서 문제가 발생할 때마다 “어떻게 이런 일이 일어났는가?”를 묻고, Five Whys(5번의 왜) 기법으로 근본 원인을 파고 들어야 합니다.

예를 들어 “코더가 버그를 만들었다”는 근본 원인이 아닙니다. 이것은 증상입니다. 진짜 질문은 이것입니다.

왜 코더가 그 실수를 할 수 있었는가?
왜 그 API가 잘못 사용하기 쉽게 설계되었는가?
왜 타입 시스템이 그 실수를 컴파일 타임에 잡지 못했는가?
왜 자동화된 테스트가 그 케이스를 커버하지 못했는가?
왜 코드 구조가 그런 실수를 쉽게 만드는가?

이 과정을 통해 도출된 개선점을 시스템에 반영하면, 동일한 종류의 실수가 반복되지 않습니다. 이것이 진정한 품질 문화입니다.

9. 모듈화: 구조적 해법

리뷰 단계 제거의 딜레마

리뷰 단계를 단순히 제거하면 어떻게 될까요? 저자는 이것을 Ford Pinto 사례나 최근 Boeing 항공기 사태에 비유합니다. 품질 통제 없이 속도만 추구했을 때 어떤 결과가 나타나는지를 보여주는 실제 사례들입니다.

결국 리뷰 단계를 줄이되, 그것을 대체할 무언가가 반드시 있어야 합니다. 저자가 제안하는 것은 모듈화(Modularity) 와 소규모 팀 기반의 품질 내재화입니다.

일본 부품 공급사 비유

Pennarun은 아름다운 비유를 사용합니다. 구식 미국 자동차 회사가 일본의 고품질 부품 공급업체로부터 부품을 구매하는 상황을 상상해보세요. 그 부품들이 너무 잘 만들어져 있기 때문에, 조립 공장에서 그 부품에 대한 별도의 QA 단계를 없앨 수 있습니다.

소프트웨어에서도 마찬가지입니다. 어떤 컴포넌트가 충분히 잘 설계되고, 충분히 작고, 충분히 테스트되어 있다면, 그 컴포넌트를 사용하는 상위 시스템에서 별도의 검증 단계가 필요 없어집니다.

작은 아름다운 것들의 조합

저자는 개인적인 미학적 선호를 솔직하게 드러냅니다.

“나는 항상 작고 아름다운 것들을 좋아했습니다. 하지만 작고 아름다운 것들을 조합해서 크고 아름다운 것도 만들 수 있습니다.”

서로 신뢰하는 소규모 팀들이 각자의 컴포넌트를 높은 품질로 만들고, 그 컴포넌트들이 잘 정의된 인터페이스를 통해 조합되는 구조를 지향해야 합니다. 이러한 구조에서는 각 컴포넌트 팀이 자신들의 ‘품질’이 무엇인지 명확히 알고, 상위 고객 팀 역시 자신들이 원하는 품질을 명확히 설명할 수 있습니다. 품질 문화는 이렇게 상향식(bottom-up)으로 확산됩니다.

10. AI 시대의 조직 설계 전략

소규모 스타트업의 구조적 이점

저자는 소규모 스타트업이 이 새로운 시대에 오히려 유리하다고 봅니다.

사람이 적기 때문에 리뷰 단계가 원래부터 적음
빠른 실험과 빠른 실패가 가능
잘못된 방향으로 고착화되기 전에 전환이 쉬움

일부 스타트업들은 고품질 컴포넌트를 빠르게 생산하는 방법을 발견할 것이고, 그렇지 못한 스타트업들은 자연 도태될 것입니다. 저자는 이것을 “자연 선택에 의한 품질(quality by natural selection)”이라고 표현합니다.

대기업의 도전

반면 대기업들은 훨씬 어려운 상황에 처해 있습니다. 느린 리뷰 시스템이 이미 조직 깊이 내재화되어 있으며, 이것을 갑자기 제거하면 완전한 혼란이 발생할 수 있습니다. 그러나 불가능한 것은 아닙니다. 작은 단위로 새 시스템을 완전히 채택하는 방식이 가능합니다.

경쟁적 내부 팀 모델

저자가 제안하는 흥미로운 조직 설계 중 하나는 동일 컴포넌트를 여러 팀이 경쟁적으로 개발하는 모델입니다. 각 팀은 소수의 사람과 AI 코딩 봇으로 구성됩니다. 100가지 방법을 시도해서 가장 좋은 것을 선택하는 방식, 즉 진화에 의한 품질(quality by evolution) 입니다.

코드는 이제 저렴해졌지만, 좋은 아이디어는 여전히 비쌉니다. 새 아이디어를 이전보다 훨씬 빠르게 시도해볼 수 있다는 것이 AI 시대의 진짜 가치입니다.

마이크로서비스의 재해석

저자는 모놀리스-마이크로서비스 연속체에서 새로운 최적점이 등장할 것이라고 봅니다. 마이크로서비스가 나쁜 평판을 얻은 것은 너무 작게 분리했기 때문입니다. 원래 의미의 “마이크로” 서비스는 “두 피자 팀(two pizza team)” 이 빌드하고 운영하기 적합한 크기였습니다.

AI 시대에는 이것이 “한 피자와 약간의 토큰” 수준으로 줄어들 수 있습니다. 단 한 명의 개발자와 AI 에이전트들이 하나의 서비스를 완전히 소유하고 운영하는 시대가 올 수 있습니다.

모듈 경계 실험의 가속화

AI는 리팩토링과 자동화된 통합 테스트에 매우 뛰어납니다. 이전에는 두려워서 분리하지 못했던 모듈들을 이제 더 쉽게 실험적으로 분리해볼 수 있습니다. 코드 줄 수는 늘어날 수 있지만, 큰 팀이 모놀리스를 유지보수하는 조정 오버헤드에 비하면 훨씬 저렴합니다.

11. 2026년 현재의 맥락: 산업 동향

AI 코딩 도구의 현황

2026년 현재, AI 코딩 도구는 빠르게 성숙하고 있습니다. Claude Code, Cursor, GitHub Copilot, Cline 등이 주요 선택지로 자리잡았으며, 전체 코드의 약 41%가 AI의 도움을 받아 작성되고 있습니다. 월간 코드 push는 8,200만 건을 넘어섰고, 병합된 PR은 4,300만 건에 달합니다. 이에 따라 리뷰 병목 문제가 산업 전반의 공통 과제로 부상했습니다.

AI 코드 리뷰의 등장

이 문제에 대응하기 위해 AI 기반 코드 리뷰 도구들도 등장했습니다. HubSpot은 내부적으로 Claude 기반 코드 리뷰 에이전트 “Sidekick”을 개발하여 PR에 대한 첫 번째 피드백 시간을 약 90% 단축하는 성과를 거뒀습니다. 이 시스템은 생성한 리뷰 코멘트를 다시 “judge agent”가 검토하는 이중 구조를 도입했습니다.

그러나 이것은 저자가 경고한 “QA 단계 추가”의 패턴을 AI로 반복하는 것일 수 있습니다. 핵심은 리뷰 속도를 높이는 것이 아니라, 리뷰 자체의 필요성을 줄이는 것입니다.

AI 코딩의 생산성 패러독스

2025년의 METR 연구(무작위 대조 시험)에 따르면, 복잡한 작업을 수행하는 숙련된 개발자들 사이에서 AI 코딩 도구가 오히려 속도를 약 19% 저하시키는 결과가 나타났습니다. 반면 주니어 개발자나 단순 반복 작업에서는 21~40%의 생산성 향상이 확인되었습니다.

이러한 “AI 생산성 역설”은 Pennarun의 분석과 일치합니다. AI는 타이핑을 빠르게 만들 뿐, 소프트웨어 엔지니어링의 핵심인 ‘생각’을 빠르게 만들지는 못합니다. 그리고 복잡한 작업에서는 AI가 생성한 코드를 검증하고 디버깅하는 과정에서 오히려 더 많은 시간이 소요됩니다.

공식 통계: 리뷰가 여전히 핵심 병목

Anthropic의 2026 Agentic Coding Trends Report에 따르면, 2025년 아직 에이전틱 AI가 개발 사이클을 재구성하고 있는 가운데, 여러 팀에 걸친 조율을 요구하던 작업들이 이제 집중적인 워킹 세션으로 대체되고 있습니다. 그러나 리뷰와 검증이라는 병목은 여전히 해결되지 않은 숙제로 남아 있습니다.

12. 실천 가이드: 팀에서 적용하는 법

이 섹션은 원문의 철학을 실제 팀에서 적용하기 위한 실천적 가이드라인입니다.

12.1 현재 리뷰 파이프라인 감사하기

먼저 현재 팀의 리뷰 단계를 명확하게 파악해야 합니다. 다음 질문들로 시작할 수 있습니다.

코드 한 줄이 아이디어에서 프로덕션까지 가는 데 평균 얼마나 걸리는가?
그 시간 중 실제 작업 시간은 얼마이고, 대기 시간은 얼마인가?
리뷰 단계가 몇 개나 있는가?
각 리뷰 단계에서 실제로 발견되는 문제의 비율은 얼마인가?

12.2 리뷰의 목적을 재정의하기

리뷰를 하는 목적을 “버그 찾기”에서 “버그가 발생하는 구조 제거하기”로 전환해야 합니다. 모든 리뷰 코멘트에 대해 다음을 물어야 합니다.

왜 이런 코드가 작성될 수 있었는가?
이 종류의 코멘트가 다시 나오지 않으려면 무엇을 자동화하거나 구조화해야 하는가?

린터, 정적 분석 도구, 타입 시스템, 테스트 자동화를 통해 코멘트 자체를 불필요하게 만들 수 있는 것은 즉시 자동화하세요.

12.3 리뷰를 왼쪽으로 당기기(Shift Left)

코드가 완성된 이후에 리뷰하는 것이 아니라, 코딩 시작 전에 설계를 함께 논의하는 방식으로 전환합니다.

디자인 세션(Design Session): 코드를 작성하기 전에 화이트보드에서 구조를 논의합니다.
페어 프로그래밍(Pair Programming): 어렵고 위험한 부분은 함께 코딩합니다.
데일리에서 조기 문제 제기: 매일 짧은 싱크를 통해 방향이 틀어지기 전에 피드백을 받습니다.

이렇게 하면 완성된 코드에 대한 리뷰의 필요성이 자연스럽게 줄어듭니다.

12.4 신뢰 기반 문화 구축

기술적 해법 못지않게 중요한 것은 문화입니다.

팀원이 버그를 발견하고 보고할 때 처벌이 아닌 감사를 받아야 합니다.
배포 후 문제를 발견했을 때 빠르게 롤백할 수 있는 안전망을 구축해야 합니다.
실수를 한 사람을 비난하는 것이 아니라, 실수가 가능했던 구조를 개선하는 데 집중해야 합니다.
경영진이 단기 속도보다 장기 품질을 중요시한다는 것을 행동으로 보여주어야 합니다.

12.5 컴포넌트 경계를 명확히 하기

각 팀이 소유하는 컴포넌트의 인터페이스와 책임 범위를 명확히 합니다.

인터페이스가 명확한 컴포넌트는 외부에서의 검증 필요성이 줄어듭니다.
충분히 잘 테스트된 컴포넌트는 그것을 사용하는 상위 시스템에서 별도 QA가 필요 없습니다.
모든 팀이 자신의 컴포넌트에 대한 품질 기준을 명확히 갖고 있어야 합니다.

12.6 AI 도구를 올바르게 활용하기

AI 코딩 도구를 활용할 때는 다음 원칙을 지켜야 합니다.

AI가 생성한 코드를 리뷰어에게 넘기기 전에 반드시 직접 검토하세요.
AI는 단순하고 명확한 작업에 가장 효과적입니다. 복잡한 아키텍처 결정은 여전히 인간이 주도해야 합니다.
AI가 빠르게 생성한 코드는 빠르게 검토할 수 있는 단위로 분할해서 제출하세요.
AI가 자신의 버그를 모두 찾아줄 것이라는 환상은 버려야 합니다.

12.7 작게 시작하기

전체 조직을 한 번에 바꾸려 하지 마세요. 한 팀, 하나의 컴포넌트부터 새로운 방식을 완전히 채택해 보세요. 그 결과가 충분히 고품질이라면, 주변 팀들이 그 컴포넌트에 대한 QA 단계를 자연스럽게 줄이게 됩니다. 품질은 상향식으로 전파됩니다.

13. 핵심 요약 및 결론

핵심 명제들

이 글에서 도출되는 핵심 명제들을 정리하면 다음과 같습니다.

명제 1: 리뷰 단계 하나는 10배의 지연을 만든다. 이것은 노력의 양이 아니라 벽시계 시간 기준이며, 대부분의 시간은 순수한 대기 시간입니다.

명제 2: AI는 코딩 속도를 높이지만, 파이프라인 전체 속도를 높이지는 못한다. 병목이 리뷰에 있는 한, 코딩이 아무리 빨라도 전체 속도는 크게 개선되지 않습니다.

명제 3: QA 단계 추가는 품질을 높이지 않는다. 인센티브 왜곡으로 인해 더 많은 QA 단계는 오히려 각 단계의 주의를 분산시키고, 근본 원인을 숨깁니다.

명제 4: 신뢰 기반의 문화가 없으면 어떤 시스템도 작동하지 않는다. Toyota의 Andon 버튼이 작동한 것은 시스템이 아니라 문화 때문이었습니다.

명제 5: 리뷰어의 진짜 목표는 리뷰 자체를 불필요하게 만드는 것이다. 자동화, 구조 개선, 타입 시스템, 도구를 통해 리뷰 코멘트가 발생하는 근본 원인을 제거해야 합니다.

명제 6: 작고 잘 만들어진 컴포넌트의 조합이 해법이다. 모듈화와 명확한 인터페이스를 통해, 각 컴포넌트의 신뢰성이 전체 시스템의 검증 필요성을 줄여줍니다.

저자의 낙관론

저자는 비관하지 않습니다. AI 시대는 오히려 지난 20년 동안 코드 리뷰 문화 뒤에 숨어 있던 구조적 문제들을 직면하고 해결할 충분한 동기를 제공한다고 봅니다.

특이점(Singularity)까지는 도달하지 못하더라도, 우리는 훨씬 더 나은 세계를 엔지니어링할 수 있습니다. 그 핵심은 기술이나 도구가 아니라 신뢰(Trust) 입니다.

“It just takes trust.” — Avery Pennarun

참고 자료

Avery Pennarun, “Every layer of review makes you 10x slower” (2026)
Avery Pennarun, “Highlights on quality and Deming’s work” (2016)
Avery Pennarun, “Systems design 3: LLMs and the semantic revolution” (2025)
GeekNews, 리뷰 단계가 10배의 지연을 만드는 법칙 (2026)
HubSpot Engineering, “Sidekick: AI Code Review Agent” (2026)
Anthropic, 2026 Agentic Coding Trends Report (2026)
METR, Randomized Controlled Trial on AI-Assisted Software Development (2025)
Wikipedia, Toyota Production System
W. Edwards Deming Institute, Reflections on the Fabric of the Toyota Production System

이 문서는 Avery Pennarun의 원문을 상세히 해설하고, 2026년 3월 현재의 최신 산업 동향을 반영하여 작성된 가이드입니다.

AI, Vibe Coding