# 모든 리뷰 단계는 속도를 10배 느리게 만든다 > Clean Markdown view of GeekNews topic #27608. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=27608](https://news.hada.io/topic?id=27608) - GeekNews Markdown: [https://news.hada.io/topic/27608.md](https://news.hada.io/topic/27608.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-03-18T11:33:05+09:00 - Updated: 2026-03-18T11:33:05+09:00 - Original source: [apenwarr.ca](https://apenwarr.ca/log/20260316) - Points: 17 - Comments: 2 ## Summary 리뷰 단계가 늘어날수록 실제 작업보다 **대기 시간**이 폭증해 속도가 10배씩 느려진다는 분석입니다. AI가 코딩 속도를 높여도 이 병목은 그대로 남기 때문에, 진짜 개선은 리뷰를 줄이고 **신뢰 기반의 품질 문화**로 전환하는 데 있습니다. Deming의 제조 철학처럼 QA를 늘리는 대신, 각 팀이 스스로 품질을 책임지는 구조를 만들어야 합니다. ## Topic Body - **조직 내 승인·검토 단계가 늘어날수록 업무 처리 속도가 기하급수적으로 느려지는 구조**를 설명하며, 실제로 각 승인 단계가 약 10배씩 지연을 초래하는 걸 사례로 제시 - AI 코딩 도구가 코드 작성 속도를 극적으로 높여도, 이후 리뷰 파이프라인의 **대기 시간(latency)** 은 줄지 않으므로 전체 속도 개선 효과가 미미 - W. E. Deming의 제조업 품질 철학을 소프트웨어에 적용하여, QA 단계를 추가하는 방식이 오히려 **품질과 속도 모두를 악화**시킨다고 지적 - 리뷰를 줄이되 동시에 **모듈화와 신뢰 기반의 품질 문화**로 대체해야 하며, 리뷰 자체를 불필요하게 만드는 구조적 개선이 핵심 - 소규모 팀이 AI 시대에 유리하며, **작고 아름다운 컴포넌트를 조합**하는 방식으로 조직과 시스템을 재설계할 필요가 있음 --- ### 리뷰 단계가 10배의 지연을 만드는 법칙 - 네트워크 효과 법칙처럼 팀 규모가 커지면 **조정 오버헤드**가 발생하며, 팀을 두 배로 늘려도 속도는 두 배가 되지 않음 - 수십 년 전 접한 경험 법칙: **리뷰 단계가 하나 추가될 때마다 프로세스가 10배 느려짐** - 이론적 근거는 없지만, 현실에서 반복적으로 관찰되는 현상 - 여기서 측정하는 시간은 노력(effort)이 아닌 **벽시계 시간(wall clock time)** 이며, 추가 시간 대부분은 대기 시간 - 구체적 예시: - 간단한 버그 수정 코딩: **30분** - 옆자리 동료의 코드 리뷰: **300분(약 5시간, 반나절)** - 아키텍트 팀의 설계 문서 승인: **50시간(약 1주)** - 다른 팀 일정에 올리기(예: 고객 기능 요청): **500시간(12주, 1 회계 분기)** - 그 다음 단계인 **10분기(약 2.5년)** 도 비현실적이지 않으며, Tailscale 같은 비교적 작은 회사에서도 제품 방향 전환 시 이 수준의 지연이 발생 ### AI는 이 문제를 해결할 수 없음 - Claude가 30분짜리 코딩을 3분에 해도, 27분을 절약해서 **직접 AI와 반복 리뷰**하거나, 검증 안 된 코드를 리뷰어에게 넘기는 것 중 하나 - 리뷰어는 여전히 5시간이 걸리며, 본인이 읽지도 않은 코드를 넘기면 **리뷰어가 불쾌해함** - 에이전틱 코딩의 진정한 가치는 1주짜리 대형 프로젝트를 몇 시간에 완성하는 것이라고 하지만, 결과물이 너무 커서 리뷰어가 한 번에 검토 불가 - 작은 단위로 분할해야 하고 각각 5시간의 리뷰 사이클 발생 - 설계 문서 없이 의도적 아키텍처도 없으므로 결국 설계 리뷰 회의로 귀결 - 결과적으로 **2시간에 완성한 프로젝트가 다시 1주로 돌아감** ### 유일한 방법은 리뷰를 줄이는 것 - 특이점(Singularity) 이론의 전제: 시스템이 점점 더 똑똑한 시스템을 만들고, 개선 단위당 소요 시간이 0에 수렴하면 폭발적 성장 - 이 이론을 믿지 않는 이유: 무언가를 완수하는 데 걸리는 시간 대부분이 실제 작업 시간이 아닌 **벽시계 시간, 즉 대기와 지연** - **지연 시간은 무차별 대입(brute force)으로 극복할 수 없음** ### 리뷰를 안 할 수는 없지 않은가 - 파이프라인 첫 단계(AI 생성 코드)가 빨라졌지만 이후 리뷰 단계가 병목이라는 증상을 많은 사람이 인식 - 직관적 해결책: 리뷰를 멈추자 → 결과물이 조잡해도 **100배 싸면 1%의 가치만 내도 손익분기**라는 논리 - 이 논리의 기저에는 상당히 어리석은 가정이 존재 - **AI 개발자의 광기 하강 곡선(AI Developer's Descent Into Madness)**: 1. 프로토타입을 놀랍게 빨리 만듦 → 초능력 느낌 2. 프로토타입에 버그 발생 → AI에게 수정 지시 3. 변경할 때마다 고치는 만큼 **새 버그 발생** 4. AI 에이전트가 자체 코드 리뷰하면 자기 버그를 찾을 것이라는 착각 5. 에이전트 간 데이터를 직접 전달하는 자신을 발견 6. 에이전트 프레임워크 필요 인식 7. 에이전트로 에이전트 프레임워크를 작성 8. 1단계로 회귀 - Claude Code가 몇 달 전에야 쓸만해졌으므로 이 순환이 최근에야 시작되었고, 많은 동료와 존경받는 사람들이 이 **사이클에 빠져 있음** ### 왜 리뷰를 하는가 - 회사가 성장하면 협업·리뷰·관리 단계가 늘어남 → 실수 방지 목적, 규모가 커질수록 **실수 비용이 증가**하기 때문 - 새 기능의 평균 부가가치가 그로 인한 새 버그의 평균 손실보다 낮아지는 시점이 옴 - 기능의 가치를 높이는 방법이 없으니 **손해를 줄이는 방향**으로 감 - 점검과 통제를 늘리면 속도는 느려지지만 품질은 **단조 증가(monotonically increasing)** → 지속적 개선의 기반처럼 보임 - 그러나 "더 많은 점검과 통제"는 품질 향상의 **유일한 방법이 아니며, 위험한 방법** ### "품질 보증(QA)"이 오히려 품질을 낮춤 - W. E. Deming이 일본 자동차 제조업에서 대중화한 품질 철학 참조 - 공장에서 QA 단계의 문제: 위젯 제작 → 검사/QA → 불합격 제거 → 누락 방지를 위해 **2차 QA 추가** - 단순 수학 모델에서는 합리적(QA 단계마다 90% 결함 포착 시 2단계로 **100배 감소**) - 그러나 **자율적 인간 행위자(agentic humans)** 환경에서는 인센티브가 왜곡됨: - 2차 QA 팀은 1차 QA 팀을 평가하는 역할 → 동료의 해고를 초래할 결과를 열심히 찾을 인센티브 없음 - 1차 QA 팀은 2차 팀이 잡아줄 것이라고 기대하여 **노력을 줄임** - 위젯 제작 팀도 QA 팀이 있으니 자체 검수를 소홀히 함 → 20% 느려지는 것보다 10% 폐기율이 나아 보임 - 품질 향상을 위한 전면 엔지니어링 재설계는 **비용이 너무 높아 기피** - Toyota Production System은 QA 단계를 완전히 제거하고, 모든 사람에게 **"라인 중단" 버튼** 부여 - 미국 자동차 제조사가 같은 버튼을 설치했으나 **아무도 누르지 않음** → 해고 두려움 ### 신뢰(Trust) - 일본 시스템이 성공하고 미국 시스템이 실패한 차이는 **신뢰** - 개인 간 신뢰: 상사가 정말로 모든 결함을 알고 싶어하며, 발견 시 라인을 멈춰야 한다는 확신 - 관리자 간 신뢰: 경영진이 품질에 진지하다는 확신 - 경영진 간 신뢰: 올바른 시스템과 인센티브가 주어지면 개인이 **품질 높은 작업을 하고 자체 결함을 발견**할 것이라는 확신 - 추가 조건: 시스템이 **실제로 작동한다는 신뢰** → 먼저 작동하는 시스템이 필요 ### 오류 가능성(Fallibility) - AI 코더는 자주 나쁜 코드를 작성하며, 이 점에서 **인간 프로그래머와 동일** - Deming의 접근법에는 마법의 해결책이 없음 → 엔지니어가 시스템 전체에 **상향식으로 품질을 설계**해야 함 - 문제 발생 시마다 "어떻게 이런 일이 일어났는가?"를 묻고 **포스트모템과 Five Whys**로 근본 원인을 찾아 수정 - "코더가 잘못했다"는 근본 원인이 아닌 **증상** → 코더가 실수할 수 있었던 구조적 원인을 찾아야 함 - 코드 리뷰어의 진정한 역할은 코드 리뷰가 아니라, **자신의 리뷰 코멘트 자체를 불필요하게 만드는 것** - 해당 유형의 코멘트가 미래에 발생하지 않도록 시스템을 개선 - 리뷰 없이도 되는 상태를 목표로 삼아야 함 - 예시: "go fmt"를 만든 사람들 → **공백 관련 코드 리뷰 코멘트를 영구적으로 제거** → 이것이 진정한 엔지니어링 - 리뷰가 실수를 발견하는 시점에는 이미 실수가 발생한 후 → **근본 원인은 이미 지나간 것** ### 모듈화(Modularity) - 리뷰 파이프라인(QA 단계)은 작동하지 않으며, 속도를 늦추면서 **근본 원인을 숨김** → 원인 해결이 더 어려워짐 - AI 코딩의 매력: 파이프라인 첫 단계가 **압도적으로 빠름** → 초능력 느낌 - 20년간 코드 리뷰 문화에 숨겨진 문제들을 해결하고, **진정한 품질 문화로 대체**할 충분한 동기가 생겼을 가능성 - 낙관론자들의 절반은 맞음: 리뷰 단계 축소가 필요하지만, **대체할 것 없이 축소하면 Ford Pinto나 최근 Boeing 항공기** 사태로 귀결 - Deming이 제조업에 가져온 것처럼 **완전한 패키지의 전환(table flip)** 이 필요 → "전사적 품질" 시스템은 반만 채택할 수 없음 - 리뷰를 제거하면서 **동시에 불필요하게 만들어야** 함 - 작은 단위로 새 시스템을 완전히 채택하는 방식이 가능: - 구식 미국 자동차 제조사가 **일본 공급업체의 고품질 부품**을 구매하는 것에 비유 - 부품이 잘 만들어져 있으면 다른 곳의 QA 단계 제거 가능 → "부품 조립" 작업의 복잡성 대폭 감소 - **작고 아름다운 것들을 조합하여 크고 아름다운 것을 만들 수 있음** - 서로 신뢰하는 소규모 팀이 **자신들에게 품질이 무엇인지** 알고 개별 컴포넌트를 제작 - 고객 팀이 **자신들에게 품질이 무엇인지** 명확히 설명 → 품질이 **상향식으로 확산** ### 소규모 팀과 AI 시대의 조직 설계 - **소규모 스타트업**이 새로운 세계에서 더 유리할 가능성 → 사람이 적어 리뷰 단계가 원래 적음 - 일부 스타트업은 고품질 컴포넌트를 빠르게 생산하는 방법을 찾고, 나머지는 실패 → **자연선택에 의한 품질** - 대기업은 느린 리뷰 시스템이 고착되어 있어 제거 시 **완전한 혼란 발생** 가능성 - 회사 규모와 무관하게, 엔지니어링 팀은 더 작아질 수 있고 팀 간 **인터페이스를 더 명확히 정의** 가능 - 한 회사 내에서 **여러 팀이 동일 컴포넌트를 경쟁적으로 개발**하는 모델 가능 - 각 팀은 소수의 사람과 코딩 봇으로 구성 - 100가지 방법을 시도하여 최선을 선택 → **진화에 의한 품질** - 코드는 저렴하지만 **좋은 아이디어는 여전히 비쌈** → 새 아이디어를 이전보다 빠르게 시도 가능 - **모놀리스-마이크로서비스 연속체**에서 새로운 최적점이 나타날 가능성 - 마이크로서비스는 너무 작아서 나쁜 평판을 얻었지만, 원래 용어에서 "마이크로" 서비스는 **"두 피자 팀"** 이 구축·운영하기에 적합한 크기 - AI 시대에는 **"한 피자와 약간의 토큰"** 수준 - 새로운 빠른 코딩으로 **모듈 경계 자체를 더 빠르게 실험** 가능 - 기능(feature)은 여전히 어렵지만, **리팩토링과 자동화된 통합 테스트**는 AI가 잘하는 영역 - 이전에 분리하기 두려웠던 모듈을 분리해볼 수 있음 → 코드 줄 수는 늘어나지만, 큰 팀이 양쪽을 유지보수하는 **조정 오버헤드에 비하면 저렴** - 모든 팀에는 너무 큰 모놀리스와 너무 많은 리뷰 단계가 존재 - 특이점까지는 못 가더라도, **훨씬 더 나은 세계를 엔지니어링할 수 있음** → 문제는 해결 가능 - 핵심은 **신뢰** ## Comments ### Comment 53346 - Author: bbulbum - Created: 2026-03-19T10:37:45+09:00 - Points: 2 `go fmt` 를 처음 본 나: 아니 왜 포멧을 내 취향대로 못하는데..! 지금: 포멧에 취향이 왜 필요함? ### Comment 53278 - Author: neo - Created: 2026-03-18T11:33:05+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=47408205) - 리뷰를 아예 안 할 수도 있음 리뷰를 **왼쪽으로 당겨서** 코드 디자인 세션으로 바꾸고, 데일리에서 문제를 제기하고, 어려운 부분은 페어 프로그래밍으로 해결하면 대부분의 리뷰 목적이 사라짐 남은 10%의 변수명, 공백, 패턴 같은 건 **linter**로 자동화 가능함 결국 중요한 건 팀이 합의한 코드를 신뢰하고 작성할 수 있는 **신뢰 기반의 팀 문화**를 만드는 것임 - “계획에 몇 시간을 쓰면 코딩 몇 분을 아낀다”는 말처럼, 모든 아키텍처를 화이트보드에서 설계할 수는 없음 실제 구현 중에야 문제를 깨닫게 됨 완벽히 계획대로 되는 경우는 거의 없었음. 결국 **반복적인 아키텍처 미팅**이 필요하지만, 그건 또 주간회의의 늪으로 빠짐 - 존경하던 엔지니어들이 **코딩 에이전트**로 PR을 자동 생성하면서 이 방식을 버리는 걸 봤음 스스로 작성한 코드조차 리뷰하지 않게 되면, 쌓아온 **신뢰가 순식간에 무너짐** - 이 글의 핵심도 결국 **신뢰의 시스템**임 Toyota Production System처럼 QA 단계를 없애려면, 모든 구성원이 결함을 발견했을 때 즉시 멈출 수 있는 신뢰가 필요함 리뷰 파이프라인은 문제를 숨기고 속도를 늦출 뿐임 - “리뷰를 왼쪽으로 당기고, 디자인 세션으로 부르고, 데일리에서 문제를 제기하고, 페어 프로그래밍으로 해결한다” 이 한 문장 자체가 **지옥의 정의** 같음 - “우리는 당신을 신뢰함. 하지만 전화번호는 알고 있음”이라고 새로 합류한 사람들에게 말함 이게 꽤 잘 통함. 사람들은 스스로 테스트를 작성하고, 수동 검증도 병행함 잘못된 배포를 **10분 만에 되돌릴 수 있는 안전망**도 구축함 - 코드 리뷰는 **자원봉사자의 딜레마**임 “PR을 많이 리뷰했다”보다 “기능을 많이 출시했다”가 평가에 반영되기 때문임 결국 리뷰는 자기 일에 직접 영향이 있을 때만 적극적으로 하게 됨 하지만 코드가 유연하다는 점에서, 빠른 머지와 후속 수정이 오히려 **더 빠른 수렴**을 가져올 수 있음 - 리뷰어가 팀 리드처럼 **팀의 산출물에 책임**을 느끼는 경우도 있음 특히 버그를 미리 잡아 **온콜 스트레스**를 줄이려는 동기도 큼 - 주니어에게는 모든 PR을 리뷰하라고 권장함 이해가 안 되더라도 질문을 남기는 게 학습에 큰 도움이 됨 리더가 되고 싶다면 코드와 **디자인 문서 리뷰**를 많이 해야 함 - 흥미롭게도, 대부분의 개발자가 가장 중요하다고 생각하는 두 가지 — **코드 리뷰와 코드 삭제** — 는 보상받지 못함 - 이 글은 내 **직감과 경험**을 명확히 정리해준 글이었음 Tailscale 제품도 좋아했지만, 이제는 CEO의 팬이 될 듯함 글쓴이 Avery에게 감사하며, 이 글을 널리 공유할 예정임 - Valve는 **커뮤니케이션 대역폭**의 한계를 이해하는 몇 안 되는 회사임 조직이 커질수록 커뮤니케이션 부담이 **지수적으로 증가**함 - 이걸 처음 깨달은 사람은 Jeff Bezos였다고 생각함 다른 회사들도 이제는 깨달았을 법한데, 여전히 그렇지 않음 - 리뷰가 5시간 내에 처리된다는 게 놀라움 대부분은 며칠 단위로 진행됨 하지만 모든 개발자가 버그를 발견했을 때 **즉시 멈출 수 있는 문화**가 있다면 리뷰는 필요 없을 수도 있음 현실은 릴리스 목표를 못 맞추면 개인이 불이익을 받는 구조임 - 예전 회사는 리뷰에 며칠이 걸렸지만 코드 품질은 괜찮았음 지금 회사는 리뷰가 몇 분 만에 끝나지만 **기술 부채**가 폭증함 - FAANG 팀에서는 리뷰 SLA가 4시간이었음 일정 시간 지나면 자동으로 “리뷰 대기 중” 메시지가 옴 모든 게 측정되고, **성과 압박**이 심했음 - 어느 순간 리뷰가 병목이라는 걸 깨닫고, 팀 코드 리뷰를 **즉시 처리**하기 시작했음 팀 규모만 적당하면 이 습관은 **학습 가능하고 전파 가능함** - 글쓴이가 Tailscale의 CEO라는 걸 페이지 하단에서 봤음 - 지금까지 리뷰가 진지하게 다뤄지는 프로젝트를 본 적이 없음 비즈니스도, 개발자도 **별로 신경 쓰지 않음** - 리뷰의 **가치 대비 노력 비율**이 종종 무시됨 리뷰가 실제로 품질을 높이지 못한다면, 그 시간은 낭비임 세세한 논쟁보다 “작동하는가”만 확인하고 빠르게 머지하는 게 효율적임 이후 커밋으로 개선하면 됨 리뷰는 **짧고 방향성만 확인하는 체크포인트**여야 함 - “리뷰어의 일은 리뷰를 없애는 것”이라는 말에 전적으로 동의함 - 글이 **직렬화된 프로세스**를 전제로 하지만, 실제로는 병렬로 진행됨 여러 버그를 동시에 처리하면 리뷰 지연이 큰 문제가 아님 핵심은 **동시 작업 수(N)** 를 조절하는 것임 - 이를 위해 **큐잉 이론 계산기**를 만들어봄 [링크](https://joshmoody.org/blog/number-of-agents/#number-of-agents-optimizer) PR 리뷰 속도가 느릴수록 **컨텍스트 스위칭 비용**이 커짐 계산 결과, 리뷰 속도를 높이면 생산성이 크게 향상됨 - “리뷰어의 목표는 리뷰를 불필요하게 만드는 것”이라는 말에 공감하지만, **신뢰의 범위**가 회사 외부까지 확장되면 이야기가 달라짐 예를 들어 `npm update`로 악성 코드가 배포된다면, 사후 대응은 너무 늦음 신뢰 기반이라도, 때로는 **사람의 검증이 필요한 지점**이 존재함 - 매니저들은 생산성을 강조하면서도, 동시에 **속도를 늦추는 프로세스**를 유지함 복잡한 문제라 단순히 좋다 나쁘다 말하기 어려움 - “How complex systems fail”의 **Rule 9**를 떠올림 운영자는 생산성과 안전을 동시에 책임져야 함 사고 전에는 생산성이, 사고 후에는 안전이 강조됨 외부인은 이 **이중 역할의 균형**을 잘 이해하지 못함 [관련 링크](https://news.ycombinator.com/item?id=32895812)