검토/승인 단계가 하나 늘 때마다 ‘벽시계 시간’이 10배씩 늘어난다는 경험칙을 바탕으로, AI가 코딩을 빠르게 만들어도 병목은 검토 파이프라인에 남으며, 품질을 높이면서도 속도를 유지하려면 검토를 줄이는 대신 시스템적으로 결함을 줄이는 문화와 신뢰, 모듈성에 투자해야 한다는 주장.
When there's only one
...there's only one choice
여기 있는 내용은 모두 제 의견입니다. 저는 여러분의 고용주를 대변하지 않습니다.
[2026-03-16 » ------------------------------------------------ 모든 검토 단계는 당신을 10배 느리게 만든다
우리는 모두 그런 네트워크 효과 법칙을 들어봤을 겁니다. 네트워크의 가치는 구성원 수의 제곱에 비례해서 올라간다든가. 혹은 의사소통 비용이 구성원 수의 제곱에 비례해서 올라간다든가, 아니면 멤버를 어떻게 배치하느냐에 따라 같은 거였나, 뭐 그런 식으로요.
어쨌든 팀을 두 배로 늘린다고 속도가 두 배가 되지는 않습니다. 조율 오버헤드가 있거든요. 정확히 오버헤드가 얼마나 되느냐는 조직 설계를 얼마나 엉망으로 하느냐에 달려 있습니다.
그런데 수십 년 전에 누군가가 제게 보여준, 그 뒤로 계속 머릿속에 남아 있는 경험칙이 하나 있습니다. 짜증 날 정도로 사실이라서요. 이 규칙이 짜증 나는 이유는, 사실일 것처럼 보이지 않기 때문입니다. 제가 들어본 바로는 이 주장에 대한 이론적 근거도 없습니다.
그런데도, 제가 찾아보면 언제나 그게 거기에 있습니다.
자, 갑니다:
승인 단계가 하나 늘 때마다 프로세스는 10배 느려진다
무슨 생각인지 압니다. 에이, 10배요? 너무 크잖아요. 상상도 안 됩니다. 과장하는 거겠죠.
아뇨.
분명히 해두자면, 여기서는 노력을 세는 게 아니라 “벽시계 시간(wall clock time)”을 셉니다. 늘어나는 시간의 대부분은 가만히 앉아서 기다리는 데 쓰입니다.
보세요:
그 다음 단계 — 10분기, 즉 약 2.5년 — 는 너무 미친 소리라 상상할 필요도 없다고 말하고 싶지만, 아닙니다.
그게 중간 규모 팀 위에 앉아 있는 임원의 삶입니다. Tailscale처럼 비교적 작은 회사에서도 제품 방향을 바꾸고 싶으면 저는 이런 상황을 아주 자주 마주칩니다. (그리고 대규모 팀 위에 앉아 있는 임원들은 사실 자기 일 자체를 전혀 할 수 없습니다. 그건 또 다른 이야기고요.)
AI는 이걸 고칠 수 없다
먼저, 이 글은 AI에 관한 글이 아닙니다. 왜냐하면 이 문제에 대한 AI의 직접적인 영향은 미미하기 때문입니다.
좋아요, Claude가 30분 대신 3분에 코딩해 준다고 해봅시다? 훌륭하네요, Claude, 수고했어요.
이제 당신은 27분을 들여 AI와 주고받는 루프 속에서 직접 코드를 리뷰할 수도 있고(사실 이건 좀 재밌습니다), 아니면 27분을 아끼고 검증되지 않은 코드를 코드 리뷰어에게 넘길 수도 있죠. 그런데 그 리뷰어는 예전처럼 여전히 5시간이 걸릴 겁니다. 다만 이번에는 “니가 읽기 귀찮아서” 생략한 찌꺼기(sloppy)를 자기가 읽게 됐다고 화가 나겠죠.
얻은 게 별로 없습니다.
하지만 당신은 말하겠죠. 아니 아니, 그건 에이전트형 코딩의 가치가 아니라고요. 30분짜리 수정에 에이전트를 쓰는 게 아니라, 원래면 일주일 걸릴 괴물 프로젝트에 쓰는 거라고요. 이제 당신과 Claude가 몇 시간 만에 할 수 있다고요!
이제 좀 말이 되네요.
…라고 하고 싶지만, 또 아닙니다. 그 괴물은 너무 커서 리뷰어는 “니가 직접 읽지도 않았잖아” 하면서 더 화가 날 테고, 한 덩어리로는 리뷰가 안 되니까 5시간 리뷰 사이클을 가진 한입 크기 조각들로 잘게 쪼개야 합니다.
그리고 설계 문서가 없으니 의도된 아키텍처도 없고, 결국 누군가가 거기에 제동을 걸 겁니다. 그러면 설계 문서 리뷰 미팅이 시작되겠죠. 그래서 두 시간 만에 해치운 “원래 일주일짜리” 괴물 프로젝트는… 어.
다시 일주일이 됩니다.
이 글을 Systems Design 4(혹은 5, 아니면 지금 몇 번째인지도 모르겠네요. 와이파이 없는 비행기에서 쓰고 있어서요)라고 불렀어도 됐을 겁니다. 네, 맞습니다.
또 시스템 설계 시간입니다.
지속적으로 더 빨라지는 유일한 방법은 검토를 줄이는 것이다
재밌는 건, 수십 년 동안 모두가 특이점(Singularity)을 예측해 왔다는 점입니다.
전제는 이렇죠. 우리가 너무 똑똑한 시스템을 만들면, 그 시스템이 다음으로 더 똑똑한 시스템을 만들고, 그게 또 다음을 만들고… 이런 식으로 계속 이어진다는 겁니다. 그게 일단 시작되면, 더 똑똑해지는 속도가 충분히 빨라질 때 개선 단위 를 달성하는 데 필요한 증가 시간 가 0으로 수렴하니 는 무한대로 발산하고, “푹(f"oom)” 하고 터진다는 거죠.
어쨌든 저는 위에서 설명한 단순한 이유로 이 이론을 믿어본 적이 없습니다. 어떤 일을 해내는 데 필요한 시간의 대부분은 실제로 ‘하는 시간’이 아니기 때문입니다.
벽시계 시간입니다.
기다림.
지연(latency).
그러고 싶어 하는 건 압니다. 지금 여러분 중 많은 분이 바로 그걸 해야만 성립하는 비즈니스 모델을 가진 회사에서 일한다는 것도 압니다.
미안합니다.
하지만 그냥 리뷰를 안 할 수는 없잖아!
음, 그렇죠, 사실… 네, 진짜로 안 됩니다.
지금은 증상을 본 사람이 많습니다. 파이프라인의 시작(AI 생성 코드)이 너무 빨라졌는데, 그 다음 단계들(검토)이 너무 느리다는 거죠!
그래서 그들은 당연한 해결책을 직감합니다. 그럼 리뷰를 그만하면 되잖아!
결과물이 찌꺼기일 수도 있지만, 그 찌꺼기가 100배 싸다면 단위당 가치가 1%만 나와도 공정한 거래라는 거죠. 그리고 단위당 가치가 예전의 고작 2%만 되어도 수익이 두 배가 됩니다! 대단하네요.
그 이론 밑에는 꽤 멍청한 가정들이 깔려 있는데, 여러분이 직접 상상해도 됩니다.
여기서는 이게 제가 “AI 개발자의 광기로의 추락”이라고 부를 것을 낳는다고만 해두죠:
놀라울 정도로 많은 친구들과 존경하는 동료들이 이미 이 사이클에 빠져버렸습니다.
Claude Code가 제대로 좋아진 건 아마 몇 달 전쯤이라서, 이런 일이 일어난 것도 사실 최근입니다. 그래서 결국은 그들도 이 소용돌이에서 빠져나오리라 가정합니다.
그러니까, 그러길 바랍니다.
우린 알 방법이 없습니다.
우리가 검토하는 이유
어쨌든 증상은 알고 있습니다. 1단계에서 너무 많은 새 코드가 쏟아져 들어오면서 파이프라인이 막히는 거죠.
그런데 막힘의 근본 원인은 뭘까요? 왜 파이프라인은 더 빨라지지 않을까요?
위에서 이건 AI에 관한 글이 아니라고 했죠. 지금까지는 явно 실패하고 있지만, 사람 이야기로 다시 돌려봅시다.
시작할 때 말했던 그 짜증 날 정도로 사실인 관찰로 돌아갑니다. 검토 단계는 하나 늘 때마다 10배 느려집니다.
사회 전체가 이걸 알고 있습니다. 아마 여러분은 지금까지 못 봤을 수도 있겠지만요.
하지만 믿어주세요. 조직 설계를 업으로 하는 사람들은 “레이어”가 비싸다는 걸 압니다… 그런데도 그들은 여전히 그렇게 합니다.
회사가 커질수록, 협업/검토/관리의 층은 점점 더 많아집니다.
왜 그럴까요?
그렇지 않으면 실수가 발생하고, 규모가 커질수록 실수는 점점 더 비싸지기 때문입니다.
새 기능이 추가로 만들어내는 평균 가치가, 그 기능이 유발하는 새 버그들로 인해 잃는 평균 가치보다 결국 더 낮아지는 지점이 옵니다.
그래서 기능이 더 많은 가치를 내도록 만드는 방법(있으면 얼마나 좋겠어요!)이 없는 대신, 적어도 피해를 줄이려 합니다.
체크와 통제를 더 많이 넣을수록 속도는 느려지지만, 품질은 더 단조롭게(꾸준히) 증가합니다.
그게 바로 지속적 개선(continuous improvement) 의 기반 아닌가요?
음, 어느 정도는요.
품질을 꾸준히 높이는 건 방향이 맞습니다.
하지만 “체크와 통제를 더 많이”는 탈선했습니다.
그건 품질을 개선하는 한 가지 방법일 뿐 이고, 위험한 방법이기도 합니다.
“품질 보증(Quality Assurance)”은 품질을 떨어뜨린다
몇 년 전에 저는 일본 자동차 제조에서 그가 대중화한 품질에 관한 “새로운” 철학, W. E. Deming에 대해 쓴 적이 있습니다. (결국 미국 자동차 제조사들도 대략 요지는 이해했습니다. 소프트웨어 산업은 아직입니다.)
그가 강조한 효과 중 하나는 공장에서 “QA” 단계가 갖는 문제였습니다. 물건을 만들고, 검사/QA 단계를 거치고, QA에서 실패한 물건을 폐기하는 모델이죠.
물론 검사원들이 실패를 일부 놓칠 수 있으니, 의심스러우면 첫 QA 뒤에 두 번째 QA 단계를 추가해서 남은 걸 잡고, 또 잡고… 그렇게 됩니다.
단순한 수학 모델에서는 그럴듯해 보입니다. (예컨대 QA 패스가 결함의 90%를 잡는다면, QA 두 번이면 결함 수를 100배 줄이는 셈이죠. 얼마나 멋집니까?)
하지만 에이전트로 움직이는 인간 현실에서는 그렇게 단순하지 않습니다.
첫째로 인센티브가 이상해집니다.
두 번째 QA 팀은 기본적으로 첫 번째 QA 팀이 일을 얼마나 잘하는지를 평가하는 역할이 됩니다. 첫 번째 QA 팀이 계속 결함을 놓친다면, 그들을 해고해야겠죠.
그런데 두 번째 QA 팀은 자기 친구들에게 그런 결과가 나오도록 만들 동기가 거의 없습니다. 그러니 대충 볼지도 모릅니다. 어차피 첫 번째 QA 팀도 놓친 결함인데, 우리가 놓친다고 해서 unreasonable한 건 아니니까요.
게다가 첫 번째 QA 팀은 두 번째 QA 팀이 결함을 잡아줄 거라는 걸 압니다. 내가 오늘 너무 열심히 안 해도, 두 번째 팀이 메워주겠지. 그게 그들이 존재하는 이유잖아!
또, 처음에 물건을 만드는 팀도 자기 작업을 꼼꼼히 확인하지 않습니다. 그건 QA 팀이 할 일이니까요!
내가 매 물건 생산을 조심해서, 예를 들어 시간 비용이 20% 더 들게 하면서까지 속도를 늦출 이유가 뭘까요? 100개 중 결함이 10개뿐이라면, 다음 단계에서 제거해버려서 10%의 낭비 오버헤드만 내면 되는데요.
그게 더 합리적이죠.
게다가 내가 20% 느려지면 해고할 거잖아요.
품질을 높이기 위한 전체적인 엔지니어링 재설계는 말할 것도 없고요. 그건 엄청 비싸고, 대신 완전히 새 물건들을 설계할 수도 있으니까요.
어디서 많이 본 엔지니어링 부서 같나요?
Deming을 여기서 다시 다 풀어쓸 때는 아니지만, 요지는 이렇습니다. 그는 뭔가를 제대로 짚었습니다.
그리고 그의 기법은 효과가 있었습니다.
유명한 Toyota Production System 같은 것들이 나왔죠. 거기서는 QA 단계를 아예 없애버리는 대신, 모두에게 “아, 젠장, 라인을 멈춰! 결함을 찾았어!” 버튼을 줬습니다.
유명하게도 미국 자동차 제조사들은 같은 “라인 멈춤” 버튼을 설치해서 똑같은 시스템을 도입하려 했습니다.
물론 아무도 버튼을 누르지 않았습니다.
해고당할까 봐 무서웠거든요.
신뢰
일본식으로 성공한 시스템의 기반, 그리고 미국식으로 실패한 시스템에 빠져 있던 요소는 신뢰입니다.
개인들 사이의 신뢰: 상사가 정말로, 진짜로, 실제로 모든 결함을 알고 싶어 하고, 결함을 찾으면 라인을 멈추길 원한다는 신뢰.
관리자들 사이의 신뢰: 임원들이 품질에 대해 진지하다는 신뢰.
임원들의 신뢰: 작동하는 시스템과 올바른 인센티브가 주어지면, 개인이 품질 높은 일을 해내고 자기 결함을 찾아내며, 필요할 때 멈춤 버튼을 누를 것이라는 신뢰.
하지만 한 가지가 더 있습니다.
그 시스템이 정말로 작동한다 는 신뢰.
그러니 먼저, 작동할 시스템이 필요합니다.
오류 가능성
AI 코더는 실수할 수 있습니다. 종종 나쁜 코드를 씁니다.
이 점에서 그들은 인간 프로그래머와 똑같습니다.
Deming의 제조 접근에는 마법의 탄환이 없었습니다. 안타깝게도 그의 10단계 프로세스를 따른다고 즉시 더 높은 품질의 엔지니어링이 생기지는 않습니다.
비밀은 이겁니다. 엔지니어들이 전체 시스템의 위아래 모든 곳에 더 높은 품질을 엔지니어링해 넣도록, 반복해서, 계속해서 만들어야 합니다.
지속적으로요.
뭔가가 잘못될 때마다 “이게 어떻게 일어났지?”라고 묻고, 포스트모템과 Five Whys(요즘 유행하는 Whys가 몇 개인지는 모르겠지만)를 하고, 다시는 일어나지 않도록 근본 원인을 고쳐야 합니다.
“코더가 잘못했다”는 근본 원인이 아니라 증상일 뿐입니다.
코더가 잘못할 수 있었던 이유는 무엇이었을까요?
코드 리뷰어의 일은 코드를 리뷰하는 게 아닙니다.
리뷰 코멘트 자체를, 그리고 그 코멘트의 전체 클래스 전체를, 앞으로 모든 경우에서 쓸모없게 만들 방법을 찾는 겁니다. 그러다 보면 결국 리뷰가 더는 필요 없어집니다.
(처음으로 "go fmt"를 만든 사람들과, 공백 때문에 하던 수많은 멍청한 코드 리뷰 코멘트가 영원히 사라진 걸 생각해 보세요. 저게 엔지니어링입니다.)
리뷰가 실수를 잡아냈을 때는, 실수는 이미 저질러진 뒤입니다. 근본 원인은 이미 발생했습니다.
너무 늦었습니다.
모듈성
제가 모든 답을 가지고 있다고 말하고 싶지만, 사실 별로 없습니다.
있었다면 특이점 줄에 제가 제일 먼저 서 있었을 텐데, 꽤 멋져 보이긴 하니까요.
우리는 이런 시스템 파이프라인 문제에 꽤 오랫동안 발목 잡힐 것 같습니다.
리뷰 파이프라인 — QA 레이어 — 는 작동하지 않습니다. 대신 근본 원인을 숨기면서 우리를 느리게 만듭니다. 원인을 숨기면 고치기 더 어려워집니다.
그런데 AI 코딩의 유혹은 강합니다.
파이프라인의 첫 단계가 너무 빠르거든요!
정말로 초능력이 생긴 느낌이 듭니다.
저는 더 많은 초능력이 갖고 싶습니다.
우린 뭘 해야 할까요?
어쩌면 마침내, 코드 리뷰 문화가 20년 동안 숨겨온 문제들을 고치고, 진짜 품질 문화로 바꿀 만큼 충분히 설득력 있는 핑계가 생긴 건지도 모릅니다.
낙관론자들의 생각은 절반쯤은 맞다고 봅니다.
불편할 정도로까지 검토 단계를 줄이는 건 필요해질 겁니다.
하지만 뭔가로 대체하지 않고 검토 단계만 줄일 수는 없습니다.
그 길의 끝에는 Ford Pinto나 최근의 Boeing 항공기 같은 것들이 있습니다.
완전한 패키지, 판 뒤집기(table flip)는 Deming이 제조업에 가져온 것이었습니다. “전사적 품질(total quality)” 시스템은 반쪽만 도입할 수 없습니다.
리뷰를 없애는 것 그리고 그것들을 쓸모없게 만드는 것, 둘을 한 번에 해야 합니다.
어떻게요?
새 시스템을 작은 단위로, 완전히 채택하면 됩니다.
시스템의 일부 컴포넌트는 새 방식으로 만들 수 있다면 어떨까요?
구식 미국 자동차 제조사가 일본 공급업체로부터 부품을 산다고 상상해 보세요. 와, 이 부품들 진짜 잘 만들었네! 이제 부품이 잘 동작할 거라고 가정할 수 있으니, 다른 곳의 QA 단계들을 줄일 수 있습니다. 그리고 “부품으로 더 큰 물건을 조립한다”는 내 일에서 엄청난 복잡성이 사라집니다.
저는 이 관점이 좋습니다.
저는 원래부터 작고 아름다운 것들을 좋아해 왔는데, 그건 제 편향이죠.
하지만 작고 아름다운 것들로 큰 아름다운 것들을 조립할 수 있습니다.
서로를 신뢰하는 작은 팀에서, 자신들에게 품질이 무엇인지 스스로 아는 상태로 그런 개별적인 아름다운 것들을 만드는 게 훨씬 쉽습니다.
그들은 고객 팀에게 결과물을 전달하고, 고객 팀은 자신들에게 품질이 무엇인지 명확히 설명할 수 있습니다.
그렇게 계속 이어집니다.
품질은 아래에서 위로 시작해서 퍼져나갑니다.
이 새로운 세상에서 작은 스타트업들은 정말 잘 될 거라고 봅니다. 아마 지금까지보다 더요.
스타트업은 사람 수가 적어서 애초에 검토 레이어가 적습니다.
어떤 스타트업은 빠르게 고품질 컴포넌트를 만드는 법을 찾아낼 것이고, 어떤 곳은 못 찾아내서 실패하겠죠.
자연선택에 의한 품질?
큰 회사는 더 어렵습니다. 느린 리뷰 시스템이 뼛속까지 박혀 있어서, 그걸 삭제하면 완전한 혼돈이 올 테니까요.
하지만 이건 회사 규모만의 문제가 아닙니다.
어떤 회사든 엔지니어링 팀은 더 작아질 수 있고, 팀 사이 인터페이스를 더 잘 정의할 수 있다고 봅니다.
어쩌면 회사 내부에 같은 컴포넌트를 제공하려는 여러 팀이 경쟁하도록 할 수도 있겠죠.
각 팀은 몇 명과 몇 개의 코딩 봇으로 구성됩니다.
100가지 방법으로 시도해 보고, 누가 제일 좋은 걸 내놓는지 보세요.
다시 말하지만, 진화에 의한 품질입니다.
코드는 싸지만 좋은 아이디어는 싸지 않습니다.
하지만 이제는 새로운 아이디어를 그 어느 때보다 빠르게 시험해 볼 수 있습니다.
모놀리스-마이크로서비스 연속선에서 새로운 최적점을 보게 될지도 모릅니다.
마이크로서비스는 너무 마이크로해서 나쁜 평판을 얻었습니다. 원래 용어에서 “마이크로” 서비스는 “두 판 피자 팀(two pizza team)”이 스스로 만들고 운영하기에 딱 맞는 크기였습니다.
AI와 함께라면, 피자 한 판과 약간의 토큰이면 될지도요.
재밌는 건, 이런 새롭고 빠른 코딩을 이용해서 모듈의 경계(boundaries) 를 더 빠르게 실험해 볼 수도 있다는 점입니다.
기능 은 여러 이유로 여전히 어렵지만, 리팩터링과 자동화된 통합 테스트는 AI가 특히 잘하는 일입니다.
예전에는 분리하기 무서웠던 모듈을 한번 떼어내 보세요.
코드 몇 줄은 늘 수도 있습니다.
하지만 이제 코드 줄 수는 싸졌습니다. 두 부분을 유지보수하기 위해 더 큰 팀이 필요해지는 조율 오버헤드에 비하면요.
모든 팀에는 조금 너무 큰 모놀리스가 있고, 검토 레이어도 너무 많습니다.
우리가 특이점까지 다 가지는 못할지도 모릅니다.
하지만 훨씬 더 나은 세상은 엔지니어링할 수 있습니다.
우리의 문제는 풀 수 있습니다.
신뢰만 있으면 됩니다.
관련
"quality"에 대한 하이라이트, 그리고 소프트웨어 개발에 적용되는 Deming의 작업(2016)
Systems design 3: LLMs and the semantic revolution(2025)
무관
SimSWE part 2: The perils of multitasking(2017)](https://apenwarr.ca/log/20260316)
저는 Tailscale 의 CEO로, 네트워크 문제를 사라지게 만드는 일을 합니다. 왜 트위터에서 저를 팔로우하나요? RSS를 쓰세요.
apenwarr on gmail.com
