모든 검토 단계가 속도를 10배 늦춘다

- 조직 내 승인·검토 단계가 늘어날수록 업무 처리 속도가 기하급수적으로 느려지는 구조를 설명하며, 실제로 각 승인 단계가 약 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): - 프로토타입을 놀랍게 빨리 만듦 → 초능력 느낌 - 프로토타입에 버그 발생 → AI에게 수정 지시 - 변경할 때마다 고치는 만큼 새 버그 발생 - AI 에이전트가 자체 코드 리뷰하면 자기 버그를 찾을 것이라는 착각 - 에이전트 간 데이터를 직접 전달하는 자신을 발견 - 에이전트 프레임워크 필요 인식 - 에이전트로 에이전트 프레임워크를 작성 - 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가 잘하는 영역 - 이전에 분리하기 두려웠던 모듈을 분리해볼 수 있음 → 코드 줄 수는 늘어나지만, 큰 팀이 양쪽을 유지보수하는 조정 오버헤드에 비하면 저렴 - 모든 팀에는 너무 큰 모놀리스와 너무 많은 리뷰 단계가 존재 - 특이점까지는 못 가더라도, 훨씬 더 나은 세계를 엔지니어링할 수 있음 → 문제는 해결 가능 - 핵심은 신뢰