▲

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

 (apenwarr.ca)
11P by GN⁺ 3일전 | ★ favorite | 댓글 2개
  • 조직 내 승인·검토 단계가 늘어날수록 업무 처리 속도가 기하급수적으로 느려지는 구조를 설명하며, 실제로 각 승인 단계가 약 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가 잘하는 영역
    • 이전에 분리하기 두려웠던 모듈을 분리해볼 수 있음 → 코드 줄 수는 늘어나지만, 큰 팀이 양쪽을 유지보수하는 조정 오버헤드에 비하면 저렴
  • 모든 팀에는 너무 큰 모놀리스와 너무 많은 리뷰 단계가 존재
  • 특이점까지는 못 가더라도, 훨씬 더 나은 세계를 엔지니어링할 수 있음 → 문제는 해결 가능
  • 핵심은 신뢰
▲
bbulbum 2일전  [-]

go fmt 를 처음 본 나: 아니 왜 포멧을 내 취향대로 못하는데..!

지금: 포멧에 취향이 왜 필요함?

답변달기
▲
GN⁺ 3일전  [-]
Hacker News 의견들

  • 리뷰를 아예 안 할 수도 있음
    리뷰를 왼쪽으로 당겨서 코드 디자인 세션으로 바꾸고, 데일리에서 문제를 제기하고, 어려운 부분은 페어 프로그래밍으로 해결하면 대부분의 리뷰 목적이 사라짐
    남은 10%의 변수명, 공백, 패턴 같은 건 linter로 자동화 가능함
    결국 중요한 건 팀이 합의한 코드를 신뢰하고 작성할 수 있는 신뢰 기반의 팀 문화를 만드는 것임

    • “계획에 몇 시간을 쓰면 코딩 몇 분을 아낀다”는 말처럼, 모든 아키텍처를 화이트보드에서 설계할 수는 없음
      실제 구현 중에야 문제를 깨닫게 됨
      완벽히 계획대로 되는 경우는 거의 없었음. 결국 반복적인 아키텍처 미팅이 필요하지만, 그건 또 주간회의의 늪으로 빠짐
    • 존경하던 엔지니어들이 코딩 에이전트로 PR을 자동 생성하면서 이 방식을 버리는 걸 봤음
      스스로 작성한 코드조차 리뷰하지 않게 되면, 쌓아온 신뢰가 순식간에 무너짐
    • 이 글의 핵심도 결국 신뢰의 시스템임
      Toyota Production System처럼 QA 단계를 없애려면, 모든 구성원이 결함을 발견했을 때 즉시 멈출 수 있는 신뢰가 필요함
      리뷰 파이프라인은 문제를 숨기고 속도를 늦출 뿐임
    • “리뷰를 왼쪽으로 당기고, 디자인 세션으로 부르고, 데일리에서 문제를 제기하고, 페어 프로그래밍으로 해결한다”
      이 한 문장 자체가 지옥의 정의 같음
    • “우리는 당신을 신뢰함. 하지만 전화번호는 알고 있음”이라고 새로 합류한 사람들에게 말함
      이게 꽤 잘 통함. 사람들은 스스로 테스트를 작성하고, 수동 검증도 병행함
      잘못된 배포를 10분 만에 되돌릴 수 있는 안전망도 구축함

  • 코드 리뷰는 자원봉사자의 딜레마임
    “PR을 많이 리뷰했다”보다 “기능을 많이 출시했다”가 평가에 반영되기 때문임
    결국 리뷰는 자기 일에 직접 영향이 있을 때만 적극적으로 하게 됨
    하지만 코드가 유연하다는 점에서, 빠른 머지와 후속 수정이 오히려 더 빠른 수렴을 가져올 수 있음

    • 리뷰어가 팀 리드처럼 팀의 산출물에 책임을 느끼는 경우도 있음
      특히 버그를 미리 잡아 온콜 스트레스를 줄이려는 동기도 큼
    • 주니어에게는 모든 PR을 리뷰하라고 권장함
      이해가 안 되더라도 질문을 남기는 게 학습에 큰 도움이 됨
      리더가 되고 싶다면 코드와 디자인 문서 리뷰를 많이 해야 함
    • 흥미롭게도, 대부분의 개발자가 가장 중요하다고 생각하는 두 가지 — 코드 리뷰와 코드 삭제 — 는 보상받지 못함

  • 이 글은 내 직감과 경험을 명확히 정리해준 글이었음
    Tailscale 제품도 좋아했지만, 이제는 CEO의 팬이 될 듯함
    글쓴이 Avery에게 감사하며, 이 글을 널리 공유할 예정임

  • Valve는 커뮤니케이션 대역폭의 한계를 이해하는 몇 안 되는 회사임
    조직이 커질수록 커뮤니케이션 부담이 지수적으로 증가함

    • 이걸 처음 깨달은 사람은 Jeff Bezos였다고 생각함
      다른 회사들도 이제는 깨달았을 법한데, 여전히 그렇지 않음

  • 리뷰가 5시간 내에 처리된다는 게 놀라움
    대부분은 며칠 단위로 진행됨
    하지만 모든 개발자가 버그를 발견했을 때 즉시 멈출 수 있는 문화가 있다면 리뷰는 필요 없을 수도 있음
    현실은 릴리스 목표를 못 맞추면 개인이 불이익을 받는 구조임

    • 예전 회사는 리뷰에 며칠이 걸렸지만 코드 품질은 괜찮았음
      지금 회사는 리뷰가 몇 분 만에 끝나지만 기술 부채가 폭증함
    • FAANG 팀에서는 리뷰 SLA가 4시간이었음
      일정 시간 지나면 자동으로 “리뷰 대기 중” 메시지가 옴
      모든 게 측정되고, 성과 압박이 심했음
    • 어느 순간 리뷰가 병목이라는 걸 깨닫고, 팀 코드 리뷰를 즉시 처리하기 시작했음
      팀 규모만 적당하면 이 습관은 학습 가능하고 전파 가능함
    • 글쓴이가 Tailscale의 CEO라는 걸 페이지 하단에서 봤음
    • 지금까지 리뷰가 진지하게 다뤄지는 프로젝트를 본 적이 없음
      비즈니스도, 개발자도 별로 신경 쓰지 않음

  • 리뷰의 가치 대비 노력 비율이 종종 무시됨
    리뷰가 실제로 품질을 높이지 못한다면, 그 시간은 낭비임
    세세한 논쟁보다 “작동하는가”만 확인하고 빠르게 머지하는 게 효율적임
    이후 커밋으로 개선하면 됨
    리뷰는 짧고 방향성만 확인하는 체크포인트여야 함

  • “리뷰어의 일은 리뷰를 없애는 것”이라는 말에 전적으로 동의함

  • 글이 직렬화된 프로세스를 전제로 하지만, 실제로는 병렬로 진행됨
    여러 버그를 동시에 처리하면 리뷰 지연이 큰 문제가 아님
    핵심은 동시 작업 수(N) 를 조절하는 것임

    • 이를 위해 큐잉 이론 계산기를 만들어봄
      링크
      PR 리뷰 속도가 느릴수록 컨텍스트 스위칭 비용이 커짐
      계산 결과, 리뷰 속도를 높이면 생산성이 크게 향상됨

  • “리뷰어의 목표는 리뷰를 불필요하게 만드는 것”이라는 말에 공감하지만,
    신뢰의 범위가 회사 외부까지 확장되면 이야기가 달라짐
    예를 들어 npm update로 악성 코드가 배포된다면, 사후 대응은 너무 늦음
    신뢰 기반이라도, 때로는 사람의 검증이 필요한 지점이 존재함

  • 매니저들은 생산성을 강조하면서도, 동시에 속도를 늦추는 프로세스를 유지함
    복잡한 문제라 단순히 좋다 나쁘다 말하기 어려움

    • “How complex systems fail”의 Rule 9를 떠올림
      운영자는 생산성과 안전을 동시에 책임져야 함
      사고 전에는 생산성이, 사고 후에는 안전이 강조됨
      외부인은 이 이중 역할의 균형을 잘 이해하지 못함
      관련 링크
답변달기