AI를 도입하면 팀은 정말 빨라질까

최근 많은 조직에서 마치 경쟁하듯이 AI를 도입하고 있다. 구글은 2026년 4월 클라우드 넥스트에서 새로 작성되는 코드의 75%가 AI로 생성되고 엔지니어의 승인을 거친다고 발표했는데, 불과 1년 반 전인 2024년 10월 실적 발표에서는 그 숫자가 4분의 1을 조금 넘는 수준이었다.

아무래도 이런 숫자가 매 분기 뉴스에 나오다 보니 다른 조직들도 가만히 있을 수가 없고, 사내 AI 코딩 도구 도입률이나 주간 활성 사용자 비율 같은 숫자가 분기 목표에 올라가는 풍경도 이제는 꽤 익숙해졌다.

그런데 정작 이런 조직들 중에서 AI 도입으로 인해 팀이 실제로 빨라졌는지 계측하는 곳은 그렇게 많지 않은 것 같다. 실제로 개발 리더 커뮤니티 LeadDev가 2025년에 낸 보고서에서도 82%의 조직이 AI 코딩 도구의 효과를 측정하지 않고 있다고 답했다.

필자가 일하는 토스에서는 생산성과 애플리케이션 안정성을 재는 지표를 만들어 AI를 도입했을 때 이 지표들이 좋은 방향으로 움직이는지를 관측하려는 시도를 하고 있는데, 이 또한 AI를 도입한 뒤에 나아졌는지 오히려 퇴보했는지 계측도 하지 않은 채로 무작정 도입할 수는 없다는 이유에서다.

사실 필자는 얼마 전 애매한 문제를 제대로 정의한다는 것이라는 포스팅에서 이 문제를 한 번 건드린 적이 있다. 기능 요청이 들어와서 배포되기까지 3주가 걸리는데 그중 코드를 작성하는 시간이 4일뿐이라면 AI로 작성 시간을 절반으로 줄여도 21일은 19일 정도로밖에 줄지 않는다는 이야기였다. 같은 계산을 끝까지 밀어보면 AI가 코드 작성 시간을 아예 0으로 만들어도 21일짜리 리드 타임은 17일, 꼴랑 19% 정도밖에 줄지 않는다.

많은 개발자들은 AI를 도입하면서 자신의 생산성이 올라갔거나 팀이 더 빠르게 일하게 되었다고 말하지만, 정말로 그럴까?

이번 포스팅에서는 먼저 AI를 쓰는 개발자와 팀이 실제로 얼마나 빨라졌는지에 대한 연구들을 보고, 사슬은 가장 약한 고리만큼만 강하다는 오래된 말을 제약 이론과 리틀의 법칙으로 옮겨서 왜 그런 결과가 나오는지 따져보려고 한다.

그리고 조직들이 왜 이걸 재보지 않는지를 본 뒤, 무엇을 바꿔야 하는지를 정리해볼 생각이다. 마지막으로는 AI를 도입한 팀이 처음 재볼 만한 지표 세 개까지 함께 살펴보자.

빨라졌다는 느낌과 빨라졌다는 사실

AI를 써본 개발자라면 대부분 자신의 업무 속도가 빨라졌다고 느낀다. 실제로 DORA의 2025년 조사에서도 응답자의 80% 이상이 AI 덕분에 생산성이 올랐다고 답했다.

그런데 빨라졌다고 느끼는 것과 실제로 빨라진 것은 다른 이야기이다. 그래서 이 섹션에서는 이 두 가지를 떼어놓고 보려고 한다. 먼저 개발자 개인이 스스로 느끼는 속도와 실제로 잰 속도를 비교한 실험을 보고, 이어서 개인이 빨라졌을 때 팀 전체에는 무슨 일이 일어났는지를 대규모 조사들로 확인해보자.

개발자들은 스스로 빨라졌다고 믿었다

AI 연구 기관 METR은 2025년 7월, 꽤 의외의 실험 결과를 내놓았다. 대형 오픈소스 프로젝트에서 평균 5년 넘게 기여해온 숙련된 개발자 16명에게 실제 이슈 246개를 맡기고, 이슈마다 AI를 쓸 수 있는 조건과 쓸 수 없는 조건을 무작위로 배정한 뒤 걸린 시간을 쟀다.

개발자들은 실험 전에 AI를 쓰면 작업 시간이 24% 줄어들 거라고 예상했고, 실험이 끝난 뒤에도 20% 정도 줄었다고 느꼈다. 그런데 실제로 시간을 재보니 AI를 쓴 쪽이 19% 더 오래 걸렸다는 사실이 밝혀졌다. 경제학자와 머신러닝 전문가들은 각각 39%, 38% 정도 더 빨라질 거라고 예측했는데, 실제 결과와는 방향부터 반대였던 셈이다.

물론 이 실험 하나로 AI가 개발자를 느리게 만든다고 결론 내리기는 어렵다. 참가자가 16명뿐이라 모수가 너무 적고, 개발자들이 오랫동안 손에 익은 대형 저장소라는 특수한 조건이었고, 쓰인 모델도 2025년 초 기준이다.

실제로 METR이 참가자를 57명으로 늘려 진행하고 2026년 2월에 공개한 후속 실험에서는 AI를 쓴 쪽이 오히려 빨라지는 방향의 결과가 나왔는데, 오차 범위가 넓어서 느려졌을 가능성도 배제할 수 없었고 METR 스스로도 매우 약한 근거라고 밝혔다. AI 없이 하기 싫은 작업은 아예 실험에서 빼버린 참가자들이 꽤 있었기 때문이다.

다만 이 실험에서 필자가 주목한 건 빨라졌는지 느려졌는지가 아니라, 개발자들의 체감과 실제 사이에 꽤 큰 갭이 있었다는 점이다. 느려졌는데도 빨라졌다고 느꼈다면 개발자들에게 AI 덕분에 얼마나 생산성이 좋아졌는지 물어보는 설문은 생각보다 믿을 만한 데이터가 아니라는 뜻이 된다. 하지만 많은 조직이 AI 도입의 효과를 확인하는 방법이 바로 이런 설문이라는 점이 아쉬운 포인트이다.

그렇다면 왜 이런 착각이 생기는 걸까? 필자는 AI와 일할 때 시간을 쓰는 패턴이 바뀐다는 데서 그 이유를 찾을 수 있다고 생각한다.

혼자 코드를 짤 때는 머리를 싸매고 고민하는 시간이 길고, 그 시간이 고스란히 고생한 시간으로 기억된다. 반면 AI와 함께 일하면 코드는 몇 초 만에 화면을 채우고, 나머지 시간은 그 코드를 읽고 고치고 다시 시키는 데 쓰인다. 고민하는 시간은 줄었는데 그 대신 검토하고 수정하는 시간이 늘어난 것이다.

문제는 이 검토하고 수정하는 시간이 짧은 것도 아니라는 데 있다. 스택오버플로의 2025년 개발자 설문을 보면 응답자의 66%가 AI의 답이 거의 맞지만 완전히 맞지는 않는다는 점을 가장 큰 불만으로 꼽았고, 45%는 AI가 만든 코드를 디버깅하는 데 시간이 더 걸린다고 답했다.

심지어 AI가 작성한 코드는 “그럴싸한” 경우가 많은데, 이렇게 그럴싸한 코드에서 어디가 틀렸는지 찾으려면 결국 전체 코드를 다 읽어야 하니, 완전히 틀린 코드를 보는 것보다 더 삽질을 하게 될 가능성이 높다.

그런데 재미있는 점은 사람이 이 시간을 일한 시간으로 잘 기억하지 못한다는 것이다. 빈 화면 앞에서 고민한 한 시간은 길게 느껴지지만, AI가 만든 코드를 조금씩 고치며 보낸 한 시간은 무언가 계속 진행되고 있었다는 느낌 때문에 짧게 느껴질 수 있는 것이다. 이건 필자의 해석이지 METR 연구의 결론은 아니지만, 체감과 실제가 반대로 갈 수 있는 이유로는 꽤 그럴듯한 설명이라고 생각한다.

개인은 빨라졌는데 팀은 그대로였다

백번 양보해서 AI를 사용한 개발자 개인의 생산성이 올랐다고 해도 그것이 꼭 팀의 생산성으로 이어지는 것도 아니다. 개발 생산성 분석 회사 Faros AI는 2025년 7월 1,255개 팀, 개발자 1만 명 이상의 실제 작업 데이터를 분석한 보고서를 냈다.

AI를 많이 쓰는 팀의 개발자들은 확실히 더 많은 일을 했다. 완료한 작업은 21%, 머지한 PR은 98% 늘었으니 개인의 아웃풋만 보면 거의 두 배가 된 셈이다.

그런데 같은 팀에서 PR 리뷰에 걸리는 시간은 91% 늘었고, PR 하나의 평균 크기는 154% 커졌으며, 개발자당 버그 수도 9% 늘었다. 심지어 보고서는 회사 단위에서는 AI 도입과 성과 개선 사이에 의미 있는 상관관계가 보이지 않았다고 결론 내렸다.

구글 클라우드의 DORA 연구팀이 2024년에 낸 보고서도 비슷한 결론을 보여줬다. AI 도입률이 25% 늘어날 때마다 문서 품질은 7.5%, 코드 품질은 3.4%, 코드 리뷰 속도는 3.1% 좋아졌지만, 팀이 실제로 변경을 배포하는 처리량은 1.5% 줄었고 배포의 안정성은 7.2% 떨어졌다. 개별 지표는 거의 다 좋아졌는데 팀이 사용자에게 제품을 내보내는 결과는 오히려 나빠진 것이다.

물론 1년 사이에 그림이 조금 바뀌기도 했다. DORA의 2025년 보고서에서는 AI 도입과 배포 처리량의 관계가 양의 방향으로 돌아섰는데, 안정성은 여전히 음의 방향이었다. 그리고 최종적으로 이 보고서는 결과를 이렇게 정리했다.

AI doesn’t fix a team; it amplifies what’s already there. Strong teams use AI to become even better and more efficient. Struggling teams will find that AI only highlights and intensifies their existing problems.

즉, AI는 팀을 고치는 게 아니라 이미 있는 것을 증폭시킨다는 것이다. 필자는 이 문장이 이번 포스팅의 질문에 대한 꽤 정확한 요약이라고 생각한다. AI는 개인을 빠르게 만들 수는 있지만, 그게 팀의 속도로 이어지느냐는 그 팀이 원래 어떻게 일하고 있었느냐에 달려 있다는 것이다.

즉, 같은 AI를 쓰는데도 어떤 팀은 더 좋아지고 어떤 팀은 문제만 커지는 데는 아무래도 팀이 원래 갖고 있던 역량이 어떠했는지가 중요하다고 보인다.

실제로 DORA는 2025년 보고서에서 AI의 효과를 키우는 조직의 역량 7가지를 정리했는데, 그중에는 작은 단위로 일하는 습관, 탄탄한 버전 관리, 잘 갖춰진 내부 플랫폼 같은 것들이 들어 있다. 그리고 이런 내용들은 AI가 나오기 전부터 좋은 팀의 조건으로 꼽히던 것들이다.

필자는 이게 우연이 아니라고 생각한다. 작은 단위로 일하고, 리뷰가 빠르고, 테스트와 배포가 자동화된 팀은 이미 코드 작성 바깥의 단계들이 잘 굴러가고 있는 팀이다.

이런 팀에서는 코드 작성이 실제로 가장 느린 단계였을 가능성이 크고, 그래서 AI가 그 단계를 빠르게 만들면 팀 전체가 빨라질 가능성이 높다. 반대로 리뷰가 밀리고 배포가 불안정한 팀에서는 코드 작성이 가장 느린 단계가 아니었으니, AI가 그 단계를 빠르게 만들어봐야 이미 막혀 있던 곳에 일이 더 몰릴 뿐이다. 이 차이가 왜 생기는지는 다음 섹션에서 조금 더 자세히 보자.

참고로 필자는 리더가 정말 신경 써야 할 것은 생산성이 아니다에서 AI를 잘 쓸수록 개인의 생산성은 폭발적으로 올라간다는 전제 위에서 이야기를 한 적이 있는데, 그때 말한 생산성은 개인이 단위 시간에 내놓는 코드의 양에 가까웠다.

이번 포스팅은 그 전제를 조금 더 자세히 들여다보는 이야기에 가깝다. 앞선 보고서들이 보여준 결론처럼 개인이 내놓는 코드의 양이 늘어나는 것과 팀이 사용자에게 내보내는 결과가 늘어나는 것은 생각보다 상관관계가 낮기 때문이다.

사슬은 가장 약한 고리만큼만 강하다

개인은 빨라졌는데 팀은 빨라지지 않는 이 현상은 사실 AI가 처음 만든 문제가 아니라, 제조업에서는 수십 년 전에 이미 정리된 문제다. 사슬은 가장 약한 고리만큼만 강하다는 오래된 말이 바로 그 답의 핵심이다.

이 섹션에서는 먼저 이 말을 공장의 언어로 옮긴 제약 이론을 보고, 그다음 팀이 빠르다는 말에 사실 2가지 다른 뜻이 섞여 있다는 걸 짚어보려고 한다. 이 구분을 해두면 앞에서 본 연구 결과들이 왜 그렇게 나왔는지가 꽤 자연스럽게 설명된다.

허비가 정하는 대열의 속도

이스라엘의 물리학자 엘리야후 골드랫(Eliyahu Goldratt)은 1984년 ”더 골“이라는 소설 형식의 경영서를 냈는데, 이 책에는 유명한 장면이 하나 나온다.

바로 주인공이 아들의 보이스카우트 하이킹을 따라갔는데, 대열이 자꾸 늘어지고 느려지는 것을 보다가 결국 대열 전체가 가장 느린 아이인 허비의 속도로밖에 걸을 수 없다는 걸 깨닫는 장면이다.

앞에 선 아이들이 아무리 빨리 걸어도 결국 대열이 최종적으로 목적지에 도착하는 시간은 대열에서 가장 느린 허비가 도착하는 시간이다. 이런 상황 속에서 걸음이 빠른 아이들이 앞서갈수록 결국 허비와의 간격만 벌어진다.

그래서 주인공은 허비를 대열 맨 앞에 세우고 허비의 배낭에 든 짐을 다른 아이들에게 나눠 들게 해서 대열 전체의 속도를 높인다. 빠른 아이를 더 빠르게 만든 게 아니라 가장 느린 아이를 덜 느리게 만든 것이다.

골드랫은 이 장면을 공장으로 가져와서 “제약 이론”이라는 이름을 붙였다. 여러 공정이 이어진 공장의 생산량은 가장 느린 공정, 즉 제약이 결정하고, 제약이 아닌 공정을 아무리 개선해봐야 공장 전체의 생산량은 늘지 않는다는 것이다.

이 책에는 이 원리를 압축한 문장도 하나 나오는데, 제약에서 잃은 한 시간은 시스템 전체에서 잃은 한 시간이고, 제약이 아닌 곳에서 아낀 한 시간은 신기루라는 것이다. 제약이 아닌 공정이 한 시간 빨라져도 제약 앞의 공정이라면 한 시간 일찍 일을 끝내고 제약 앞에서 한 시간 더 기다릴 뿐이고, 제약 뒤의 공정이라면 제약이 일을 넘겨주기를 한 시간 더 기다릴 뿐이라, 어느 쪽이든 공장이 하루에 내보내는 양은 그대로이기 때문이다.

이 책에서 주인공이 가장 먼저 부딪히는 문제도 사실 측정이었다. 주인공의 공장은 각 공정의 가동률을 높이는 데 집중하고 있었는데, 모든 기계가 쉬지 않고 돌아가니 숫자로는 아주 효율적인 공장처럼 보였다.

그런데 정작 공장에는 재고가 산더미처럼 쌓여 있고 납기는 계속 밀리고 있었다. 제약이 아닌 기계들이 쉬지 않고 만든 부품들이 제약이 되는 공정에 걸려서 줄을 서 있었던 것이다. 각 공정의 효율을 재는 숫자는 전부 좋았는데 공장이 고객에게 내보내는 양은 그대로였다는 이 장면은 앞에서 본 Faros AI의 개발자 생산성 리포트 결과와 꽤 닮아 있다.

결국 소프트웨어 팀의 구조도 공장과 크게 다르지 않다. 기능 하나가 사용자에게 닿으려면 무엇을 만들지 정하는 기획, 코드를 작성하는 개발, 동료가 코드를 읽는 리뷰, QA, 배포 같은 단계를 차례로 거쳐야 한다.

그리고 AI가 지금 주로 빠르게 만들고 있는 건 이 중에서 개발과 디자인이다. 만약 이 팀의 허비가 코드 작성이나 디자인 작업이 아니었다면 AI는 대열의 그저 앞쪽 아이들을 더 빨리 걷게 만든 것에 가깝다.

처리량은 가장 느린 단계가, 리드 타임은 모든 단계가 정한다

우리가 팀이 빨라졌다고 말할 때는 사실 2가지 다른 것을 섞어서 말하는 경우가 많다.

하나는 팀의 업무 처리량이다. 팀이 일주일에 사용자에게 내보내는 기능이나 변경의 수를 말하는 것으로, 마치 팀의 공정 맨 끝에 서서 일주일 동안 기능 몇 개가 배포되는지 세는 것에 가깝다.

각 단계에도 저마다 처리할 수 있는 양, 즉 처리 능력이 있지만 팀의 처리량은 공정 맨 끝을 기준으로 재기 때문에, 앞의 허비 이야기처럼 그 상한은 가장 느린 단계의 처리 능력이 정한다. 예를 들어 기획이 일주일에 기능 5개를 정리하고 개발이 10개를 만들어도 리뷰가 3개밖에 소화하지 못한다면, 결국 그 팀의 처리량은 일주일에 기능 3개가 되는 것이다.

다른 하나는 리드 타임이다. 기능 요청 하나가 들어와서 사용자에게 닿기까지 걸리는 시간을 말하는 것으로, 일 하나를 처음부터 따라가며 들어와서 나갈 때까지 며칠이 걸리는지 재는 것에 가깝다. 리드 타임은 각 공정에서 걸린 시간과 공정 사이에서 기다린 시간을 전부 더한 값이라 가장 느린 공정 하나가 아니라 모든 공정이 함께 결정하게 된다.

결국 사용자는 자신이 버그를 제보했는데 고쳐지기까지 몇 주가 걸리는지, 요청한 기능이 언제 나오는지를 보기 때문에 처리량보다는 리드 타임을 주로 보게 된다.

반면 조직이 분기마다 얼마나 많은 걸 해냈는지 따질 때 보는 건 처리량에 가깝다. 그리고 AI 도입 대시보드가 보여주는 개인의 출력은 이 둘 중 어느 쪽도 아니라는 게 포인트이다. (일을 얼마나 처리했냐가 아니라 토큰을 얼마나 썼냐를 보는 게 이상한 포인트)

그래서 AI 도입의 효과를 이야기할 때는 무엇이 빨라졌는지를 먼저 정해야 한다. 개인이 PR을 더 많이 만든다는 건 그냥 사슬의 고리 하나가 빨라졌다는 이야기일 뿐이고, 그게 처리량과 리드 타임으로 이어졌는지는 따로 확인해야 하는 것이다.

그렇다고 가장 느린 단계, 즉 병목이 아닌 단계를 빠르게 만드는 게 전부 의미 없는 건 아니다. 만약 리뷰가 병목인 팀에서 리뷰 뒤에 있는 QA를 3일에서 1일로 줄였다고 해보자. 리뷰를 통과하는 양은 그대로이니 팀이 일주일에 내보내는 처리량은 늘지 않지만, 기능 하나가 사용자에게 닿기까지의 리드 타임은 2일 줄어든다. 병목 뒤쪽 단계는 늘 병목이 일을 넘겨주기를 기다리는 상태라 그 앞에 대기열이 없고, 그래서 줄어든 처리 시간이 그대로 리드 타임에서 빠지기 때문이다.

문제는 같은 개선이라도 그게 병목의 앞이냐 뒤냐에 따라 리드 타임이 반대 방향으로 움직일 수 있다는 데 있다. 병목 앞쪽 단계가 빨라지면 늘어난 일이 병목 앞에서 줄을 서게 되고, 그 대기 시간만큼 리드 타임은 오히려 늘어날 수 있다.

그런데 리뷰가 병목인 팀에서 AI가 빠르게 만들고 있는 코드 작성이나 디자인 작업은 하필 병목 앞쪽에 있는 단계라는 것이 포인트이다. 이 이야기는 다음 섹션에서 숫자로 한번 따져보고, 여기서는 먼저 나머지 단계의 처리량이 그대로라고 가정한 가장 낙관적인 경우부터 계산해보자.

필자가 9월 포스팅에서 했던 계산이 바로 이 리드 타임 쪽 이야기였다. 3주, 그러니까 21일 중 코드 작성이 4일이라면 작성 시간이 전체의 약 19%를 차지한다. 이렇게 전체 중 일부만 빨라졌을 때 전체가 얼마나 빨라지는지는 컴퓨터 과학자 진 암달(Gene Amdahl)이 1967년에 정리한 암달의 법칙으로 계산할 수 있다.

위 수식에서 $p$는 빨라지는 부분이 전체에서 차지하는 비율이고 $s$는 그 부분이 몇 배 빨라지는지, $S$는 전체가 몇 배 빨라지는지다. 원래는 프로그램의 일부를 병렬화했을 때 전체가 얼마나 빨라지는지를 따지려고 만든 식인데, 팀의 리드 타임에도 나머지 단계가 그대로라는 가정 아래에서는 그대로 적용할 수 있다.

$p = 0.19$, $s = 2$를 넣으면 $S$는 약 1.1이 나오는데, 3주가 19일 정도로 줄어든다는 뜻이다. 코드 작성이 더 빨라지는 경우도 같은 식에 $s$를 바꿔가며 넣어보면 아래와 같다.

코드 작성이 빨라지는 배수 $s$	코드 작성 시간	전체 리드 타임	전체가 빨라지는 배수 $S$
1배 (AI 도입 전)	4일	21일	1.00
2배	2일	19일	1.11
5배	0.8일	17.8일	1.18
10배	0.4일	17.4일	1.21
무한대	0일	17일	1.24

만약 AI가 코드를 순식간에 작성해서 작성 시간이 아예 0이 된다고 해도 리드 타임은 21일에서 17일로, 약 19%밖에 줄지 않는다는 점을 주목하자.

즉, 코드 작성이 완벽하게 공짜가 되어도 이 팀은 여전히 3주 가까이 걸려서 기능 하나를 내보낸다는 것이다. 그리고 2배에서 10배로 가는 동안 줄어드는 건 고작 1.6일이라, 코드 작성을 더 빠르게 만드는 데 드는 노력 대비 얻는 건 갈수록 줄어든다.

물론 이 계산에는 앞서 언급했듯이 코드 작성을 제외한 나머지 공정 단계의 처리량이 그대로라는 가정이 하나 숨어 있다. 그런데 코드 작성이 빨라졌을 때 나머지 단계의 처리량이 정말 그대로 유지될까?

빨라진 고리가 사슬을 느리게 만든다

앞의 계산은 코드 작성이 빨라져도 팀 전체의 리드 타임은 생각보다 덜 빨라진다는 이야기였다. 그런데 현실에서는 여기서 더 나아가 제약이 아닌 단계가 빨라지면 팀 전체가 오히려 느려지는 일이 생길 수도 있다.

이 섹션에서는 그 메커니즘을 2가지로 나눠서 보려고 한다. 먼저 리틀의 법칙으로 리뷰 앞에 대기열이 쌓일 때 리드 타임이 어떻게 늘어나는지를 숫자로 따라가보고, 이어서 AI가 만든 PR의 성격이 이 대기열을 어떻게 더 무겁게 만드는지를 보자.

리뷰 앞에 쌓이는 PR

5명짜리 팀이 하나 있다고 해보자. 이 팀은 일주일에 PR을 40개 정도 만들고, 팀원들이 리뷰할 수 있는 양은 일주일에 50개 정도다. 리뷰할 수 있는 양이 만들어지는 양보다 조금 많으니 PR은 쌓이지 않고 대체로 들어온 주에 리뷰가 끝난다.

그런데 이 팀이 AI를 도입해서 PR을 만드는 속도가 2배가 됐다고 해보자. 이제 일주일에 PR이 80개씩 올라오는데, 리뷰할 수 있는 양은 여전히 50개다. 사람이 코드를 읽고 이해하는 속도는 AI가 코드를 쓰는 속도처럼 빨라지지 않기 때문이다. 그러면 매주 30개씩 리뷰를 기다리는 PR이 쌓인다.

주차	새로 올라온 PR	리뷰 완료	리뷰 대기 중인 PR
0주	40	40	0
1주	80	50	30
2주	80	50	60
3주	80	50	90
4주	80	50	120

이때 PR 하나가 리뷰를 받기까지 얼마나 기다려야 하는지는 리틀의 법칙으로 계산할 수 있다.

위 수식에서 $L$은 시스템 안에 머물러 있는 일의 양, $\lambda$는 시스템이 일을 처리하는 속도, $W$는 일 하나가 시스템 안에 머무는 평균 시간이다. 원래는 은행 창구나 공장 대기열을 분석하는 데 쓰이던 식인데, 대기열이 있는 곳이라면 어디에든 꽤 잘 들어맞는다.

다만 이 식은 들어오는 양과 빠져나가는 양이 같아서 대기열이 일정하게 유지될 때 성립하는 식이라, 지금처럼 대기열이 계속 쌓이는 상황에서는 대기열 앞에 작업이 줄 서 있는 양을 처리 능력으로 나눠서 대략적인 대기 시간을 가늠하는 정도로 쓰면 된다.

그렇게 계산을 해보면 4주 차 마지막쯤에 올라온 PR 앞에는 이미 PR 120개가 리뷰를 받기 위해 줄을 서 있는 상황이다. 이 팀의 처리량을 생각해보면 일주일에 PR이 50개씩 빠지니, 이 PR은 리뷰를 받기까지만 $120 / 50 = 2.4$주를 기다려야 한다. 재미있는 점은 AI 도입 이전에는 이렇게 2.4주나 기다려야 하는 PR이 없었다는 것, 그리고 각 PR이 최종적으로 처리되는 리드 타임이 계속해서 늘어나고 있다는 점이다.

아무리 AI를 돌려서 코드를 빠르게 작성해도 정작 이 팀이 일주일에 실제로 사용자에게 내보내는 양은 리뷰를 통과한 50개뿐이니, AI 도입 전 40개에서 꼴랑 25% 늘어난 정도다.

PR을 만드는 속도는 100% 늘었는데 처리량은 25%만 늘었고, 그 대가로 리드 타임은 매주 계속 늘어나고 있다. 대시보드에는 올라온 PR 수가 두 배로 늘었다고 찍히겠지만, 기능 하나가 사용자에게 닿기까지의 시간은 도입 전보다 오히려 길어진 이상한 상황이 발생하는 것이다.

즉, 이 팀은 처리량으로 보면 25% 빨라졌지만 리드 타임으로 보면 오히려 느려진 팀이다. 병목 앞 큐에 일이 차 있는 한 처리량은 리뷰의 처리 능력인 50개에 고정되고, 큐가 길어지는 만큼 리드 타임만 늘어나기 때문이다.

물론 이건 숫자를 단순하게 잡은 예시다. 실제 현실의 팀은 대기열이 쌓이면 리뷰에 시간을 더 쓰거나, 리뷰를 대충 하거나, 아예 PR을 덜 만드는 식으로 반응한다. 다만 어떤 식으로 반응하든 리뷰가 허비인 팀에서 코드 작성만 빨라지면 대기열이 생긴다는 구조 자체는 바뀌지 않는다.

그리고 이 놈의 대기열은 기다리는 시간만 늘리는 게 아니다. PR을 올리고 2주씩 지나서야 리뷰 코멘트가 달리면 작성자는 이미 다른 작업을 서너 개쯤 진행하고 있는 상태이기 때문에 컨텍스트 스위칭 비용이 또 발생한다.

결국 리뷰 코멘트를 반영하려면 그 PR을 왜 그렇게 짰는지 다시 머릿속에 불러와야 하는데, 그 코드를 AI가 짰다면 다시 불러올 맥락조차 희미한 경우가 많다. 또한 리뷰어 입장에서도 쌓여 있는 PR 사이를 오가며 매번 다른 맥락을 머리에 올려야 하니, 같은 리뷰를 해도 대기열이 없을 때보다 시간이 더 걸리기 쉽다.

문제는 조직이 보통 보는 숫자에서는 이 대기열이 잘 드러나지 않는다는 데 있다. AI 코딩 도구들이 기본으로 제공하는 대시보드에는 대개 활성 사용자 수, AI가 제안한 코드를 수락한 비율, 토큰 수 같은 숫자가 찍힌다.

그리고 앞의 예시 같은 팀에서 이 숫자들은 전부 좋은 방향으로 올라가는 것처럼 보인다는 점이 함정이다.

커지는 PR과 되돌아오는 일

게다가 현실은 이 예시보다 더 빡세다. 앞서 말했듯이 일반적으로 AI가 만든 PR은 크기가 커지고, 코드 작성자의 머릿 속에 맥락이 명확하게 남지 않기 때문에 리뷰하기도 더 어렵기 때문이다.

Faros AI의 조사에서 AI를 많이 쓰는 팀의 PR은 평균 크기가 154% 커졌다. PR 하나가 2.5배로 커지면 리뷰어가 같은 시간에 볼 수 있는 PR의 수는 그만큼 줄어든다. 필자가 6월 포스팅에서 이야기했던 것처럼 코드를 생성하는 비용은 거의 0에 수렴했지만 그 코드를 읽고 이해하는 비용은 조금도 줄지 않았으니, 리뷰라는 허비의 배낭은 오히려 더 무거워진 셈이다.

게다가 AI로 작성된 코드에서 기능 회귀가 예전보다 자주 발생한다는 문제도 있다. DORA 2024 보고서에서 AI 도입이 늘어날수록 배포의 안정성이 떨어졌다는 건 배포된 변경 사항이 장애를 일으키거나 롤백되는 일이 늘어났다는 뜻이다.

그리고 그렇게 회귀된 기능은 다시 팀의 사슬 맨 앞으로 들어간다. 원인을 찾고, 수정 코드를 작성하고, 다시 리뷰를 받고, 다시 배포해야 하니 말이다. 이미 병목 때문에 막혀 있는 리뷰 대기열에 새로운 일이 하나 더 얹히는 것이다.

반대로 말하면 뒤쪽 단계의 품질을 높여 되돌아오는 일을 줄이는 건 병목이 새 일에 쓸 수 있는 시간을 늘려주는 셈이라, 병목 뒤쪽에서 처리량까지 늘릴 수 있는 몇 안 되는 개선이라고 볼 수 있다.

도입부에서 이야기한 구글의 발표도 이 관점에서 다시 읽어볼 만하다. 새로 작성되는 코드의 75%가 AI로 생성되고 엔지니어의 승인을 거친다는 건, 거꾸로 말하면 엔지니어가 승인해야 하는 코드가 그만큼 늘어났다는 뜻이기도 하다. 구글처럼 리뷰와 테스트와 배포가 고도로 자동화된 조직이라면 이 승인이 감당할 만한 일일 수 있지만, 같은 숫자를 목표로 삼은 다른 조직에서도 그럴지는 전혀 다른 문제다.

코드베이스 분석 회사 GitClear의 2025년 조사도 비슷한 방향을 가리킨다. 2024년에는 5줄 이상 중복된 코드 블록이 이전보다 8배 늘었고, 기존 코드를 옮기며 정리하는 리팩토링성 변경의 비율은 2021년 약 25%에서 10% 아래로 떨어졌다. 새 코드를 붙여넣는 건 쉬워졌는데 기존 코드를 정리하는 일은 줄었다는 것이고, 이건 당장의 리뷰 대기열이 아니라 몇 달 뒤의 변경 비용으로 돌아온다.

즉, 코드 작성이라는 고리만 빨라진 사슬에서는 리뷰 앞에 대기열이 쌓이고, 커진 PR이 리뷰를 더 느리게 만들고, 불안정해진 배포가 일을 다시 사슬 앞으로 돌려보낸다. 개인의 대시보드에서는 모든 숫자가 좋아지는데 팀이 사용자에게 닿는 속도는 그대로이거나 오히려 느려질 수도 있는 슬픈 상황이 이렇게 만들어진다.

그런데 왜 아무도 재보지 않을까

이 정도로 결과가 엇갈린다면 조직들이 AI 도입의 효과를 열심히 측정해봐야 할 것 같은데, 앞에서 본 것처럼 대부분의 조직은 그 효과를 측정하지 않는다. 아마 대부분은 측정할 줄 몰라서라기보다는 다른 이유가 있는 것 같다.

이 섹션에서는 조직이 측정을 하지 않는 이유를 2가지로 나눠서 보고, 마지막으로 비슷한 일이 100년 전 공장에서 어떻게 벌어졌는지를 보려고 한다.

남들이 다 하니까

만약 구글이 75%라는 숫자를 발표하고 나면 다른 조직의 리더들은 “우리는 몇 %냐”는 질문을 받기 시작한다.

무엇이 정답인지 아무도 모를 때 조직은 성공한 것처럼 보이는 곳을 따라 하기 마련인데, 따라 하는 쪽이 리더 개인에게는 훨씬 안전하기 때문이다. 만약 경쟁사가 다 하는 걸 우리만 안 하고 있다가 뒤처지면 그건 리더의 책임이 되지만, 남들이 다 하는 걸 똑같이 했는데 효과가 없었다면 그건 업계 전체의 문제가 된다.

이런 상황에서 도입률은 효과를 재는 지표가 아니라 우리도 뭔가 하고 있다는 걸 보여주는 신호가 된다. 그리고 신호가 목적이 되면 측정은 굳이 할 이유가 없는 일이 되어버리는데, 이미 도입했다는 사실만으로 목적은 달성됐기 때문이다.

압력은 한 군데서 오는 것도 아니다. 본사나 투자자, 큰 고객사가 AI를 얼마나 쓰고 있는지 묻기 시작하면 조직은 효과와 상관없이 도입률을 올려야 한다. 그리고 AI를 안 쓰는 개발자는 뒤처진 개발자라는 이야기가 컨퍼런스와 링크드인을 매일같이 오가는 지금, 개발자 개인에게도 AI를 쓰는 건 효율의 문제이기 전에 정체성의 문제가 되어가고 있다.

사회학자 폴 디마지오(Paul DiMaggio)와 월터 파월(Walter Powell)은 같은 분야의 조직들이 효율과 상관없이 모방, 강제, 규범을 거쳐 서로 닮아가는 현상을 제도적 동형화라고 불렀다.

그러니 이건 리더 한두 명이 측정을 게을리해서 생기는 문제라고 보기 어렵다. 위에서는 도입률을 묻고, 옆에서는 경쟁사의 숫자가 들려오고, 아래에서는 개발자들이 스스로 빨라졌다고 느끼고 있으니, 굳이 재보자고 나서는 사람이 오히려 대세를 거스르는 사람이 된다. AI 도입의 효과를 측정하지 않는 조직이 그렇게 많은 것도 아무래도 이 구조 때문은 아닐까.

미리 적은 예측은 틀릴 수 있어서

또 하나의 이유는 측정이 가진 위험이다. 필자는 9월 포스팅에서 측정할 숫자는 행동하기 전에 적어둬야 한다고 이야기했다. 일이 끝난 뒤에 숫자를 찾으면 수십 개 지표 중 하나쯤은 우연히라도 좋아지기 마련이니, 사후에 고른 숫자는 설득력이 약하다는 이유였다.

그런데 AI 도입은 이 처방을 지키기가 유독 어려운 경우다. 도입 전에 리드 타임이 3주에서 2주로 줄어들 거라고 적어뒀는데 실제로는 그대로였다면 그건 모두가 효과를 확신하는 분위기에서 그 확신이 틀렸다는 걸 공개적으로 드러내는 일이 된다.

그러니 차라리 예측을 적지 않고, 도입이 끝난 뒤에 올라간 숫자를 골라서 보고하는 쪽이 개인에게는 훨씬 안전한 선택이 된다. 올라온 PR 수나 AI가 작성한 코드의 줄 수 같은 숫자는 거의 항상 올라가 있으니 말이다.

사실 이 문제를 꽤 오래전에 제도로 막아둔 분야가 있는데, 바로 의학이다. 임상시험이 끝난 뒤에 결과가 좋게 나온 지표만 골라서 발표하는 일이 반복되자, 주요 의학 학술지 편집인들이 공동 성명을 내고 2005년부터 무엇을 결과로 볼지를 시험 전에 공개 등록하지 않은 임상시험의 논문은 싣지 않기로 했다. 예측을 미리 적어두는 걸 개인의 양심이 아니라 규칙으로 만든 것이다.

필자는 마찬가지로 조직의 AI 도입도 “무엇이 좋아지면 성공이라고 볼지”를 도입 전에 정해서 모두가 볼 수 있는 곳에 기록해둬야 한다고 생각한다.

전기 모터가 공장을 바꾸기까지 40년

사실 이런 일은 처음이 아니다. 노벨 경제학상 수상자 로버트 솔로(Robert Solow)는 1987년 7월 뉴욕 타임스 북 리뷰에 쓴 서평에서 이런 문장을 남겼다.

You can see the computer age everywhere but in the productivity statistics.

즉, 컴퓨터라는 새로운 도구에 열광하는 것에 비해 생산성이 삐리하다는 이 말은 이후 생산성 역설이라는 이름으로 불리게 됐는데, 경제사학자 폴 데이비드(Paul David)가 이 역설에 내놓은 답은 100년 전 전기 모터도 똑같았다는 것이다.

1880년대 초, 에디슨은 뉴욕과 런던에 첫 발전소를 열었다. 그런데 1899년이 되어도 미국 공장에서 기계를 돌리는 동력 중 전기 모터가 차지하는 비중은 5%가 안 됐고, 이 비중이 절반을 조금 넘은 건 1920년대 초가 되어서였다.

그리고 데이비드에 따르면 공장의 전기화가 제조업 생산성에 눈에 띄는 영향을 주기 시작한 것도 그 1920년대 초부터였다. 에디슨의 첫 발전소가 문을 연 지 40년이 지나서야 효과가 나타나기 시작한 것이다.

그렇다면 왜 이렇게 효과가 나타나기까지 오래 걸렸을까? 데이비드가 주목한 것은 바로 공장들이 전기 모터를 쓰는 방식이었다. 증기기관 시절의 공장은 건물 한가운데 거대한 증기기관을 하나 두고, 천장을 가로지르는 긴 회전축과 벨트로 모든 기계에 동력을 나눠줬다. 그래서 동력을 효율적으로 전달하려면 기계를 회전축 가까이 몰아서 배치해야 했고, 그러다 보니 공장은 여러 층으로 높게 지어졌다.

초기에 전기 모터를 들인 공장들은 대부분 이 증기기관 자리에 큰 모터를 바꿔 끼우고, 예전 방식 그대로 모터 하나가 회전축을 돌려 여러 기계를 한꺼번에 움직이게 했다. 이런 방식을 그룹 드라이브라고 불렀는데, 데이비드에 따르면 1890년대 중반부터 1920년대 직전까지 이 방식이 대세였다. 회전축도 벨트도 기계 배치도 그대로였으니 공장이 빨라질 리가 없었다.

공장이 실제로 빨라진 건 기계마다 작은 모터를 하나씩 다는 유닛 드라이브라는 방식이 퍼지면서부터였다. 이렇게 되니 중앙 모터에 기계들이 종속되지 않아, 기계를 작업 순서대로 자유롭게 배치할 수 있게 됐고, 공장은 단층으로 넓게 지어졌고, 자재가 흐르는 동선도 짧아졌다. 데이비드는 1919년부터 1929년 사이 미국 제조업 생산성 증가율이 그전 10년보다 크게 높아진 것의 약 절반을 이렇게 늘어난 개별 모터로 설명할 수 있다고 봤다.

즉, 생산성을 바꾼 건 전기 모터라는 새로운 도구 자체가 아니라, 그 도구를 중심으로 공장이라는 사슬 전체를 다시 설계한 일이었다. 필자는 지금 많은 조직이 AI를 쓰는 방식이 증기기관 자리에 모터를 바꿔 끼운 1900년대 공장과 꽤 닮았다고 생각한다. 코드를 작성하는 자리에 AI를 끼워 넣었지만 기획, 리뷰, QA, 배포로 이어지는 사슬은 그대로 두고 있으니 말이다.

사슬을 다시 설계한다는 것

무엇을 바꿔야 하는지에 대한 힌트는 다시 골드랫에게서 찾을 수 있다. 골드랫은 제약 이론을 실제로 적용하는 방법을 5단계로 정리했는데, 제약을 찾고, 제약을 최대한 활용하고, 나머지를 제약에 맞추고, 제약 자체를 늘리고, 이걸 반복하는 순서다. 이 섹션에서는 이 순서를 소프트웨어 팀에 옮겨서, AI를 도입한 팀이 실제로 빨라지려면 무엇을 바꿔야 하는지 정리해보려고 한다.

미리 말해두면 여기서 이야기하는 것들은 정답이라기보다 출발점에 가깝다. 팀마다 허비가 다르기도 하고, 만약 같은 팀이라고 해도 허비는 시간에 따라 자리를 옮기기 때문이다.

5번째 단계가 반복인 것도 그래서인데, 골드랫은 제약 하나를 풀고 나면 반드시 다른 곳이 새로운 제약이 되니 예전 제약을 풀던 관성이 새로운 제약이 되지 않게 하라고 강조했다. 그리고 이 섹션에서는 앞의 보이스카우트 이야기를 빌려 팀의 가장 느린 고리를 계속 허비라고 부르려고 한다.

먼저 가장 느린 고리를 찾는다

가장 먼저 할 일은 AI를 어디에 쓸지 정하는 게 아니라, 우리 팀의 허비가 어디에 있는지 찾는 것이다. 그리고 이걸 찾는 가장 확실한 방법은 기능 하나가 요청에서 배포까지 가는 동안 각 단계에서 일한 시간과 기다린 시간을 나눠서 적어보는 것이다. (결국 측정이 제일 중요하다)

9월 포스팅의 예시처럼 3주 중 코드 작성이 4일이라는 게 보이면 나머지 17일이 어디서 흘렀는지를 쫓아가면 된다. 리뷰 대기가 길다면 리뷰가 허비이고, 다른 팀의 API를 기다리는 시간이 길다면 팀 사이의 의존성이 허비이고, 무엇을 만들지 정하는 데 시간이 오래 걸린다면 기획과 의사결정이 허비다. 아마 꽤 많은 팀의 허비는 코드 작성보다 그 앞뒤에 있을 가능성이 높다.

거창한 도구가 있어야 하는 것도 아니다. 사실 꽤 많은 팀은 이미 필요한 데이터를 갖고 있는데, PR이 열린 시각, 첫 리뷰가 달린 시각, 머지된 시각, 배포된 시각만 있으면 된다. 게다가 요즘엔 MCP로 쓱싹하면 데이터 수집 및 분석은 금방 할 수 있으니 그렇게 어려운 일도 아니다.

이렇게 모은 4개의 시각 사이에는 3개의 간격이 생기는데, 각각 리뷰를 기다린 시간, 리뷰를 주고받은 시간, 배포를 기다린 시간이다. 여기에 이슈 트래커에서 요청이 들어온 시각과 개발을 시작한 시각을 붙이면 코드 작성 이전에 흐른 시간까지 볼 수 있다.

이렇게 몇 주치 PR을 모아서 간격별로 중간값을 내보면 우리 팀의 3주가 어디서 흘러가고 있는지 대략 파악할 수 있다. 정밀할 필요는 없다. 9월 포스팅에서 이야기했던 것처럼 측정은 무언가를 증명하는 일이 아니라 모르는 것을 조금 덜 모르게 만드는 일이고, 지금 단계에서 알고 싶은 건 허비가 어느 근처에 있느냐 정도이기 때문이다. (여기서 정밀하게 하겠다고 욕심을 내면 끝없는 노가다가 시작되니 조심하자)

이 작업은 AI를 도입하기 전에 해두는 게 가장 좋은데, 그래야 도입한 뒤에 허비가 어디로 옮겨갔는지도 볼 수 있기 때문이다. 앞의 예시처럼 코드 작성이 빨라지면 허비는 리뷰로 옮겨가기 쉽고, 리뷰를 빠르게 만들면 다시 QA나 배포로 옮겨간다.

가장 느린 고리를 끊어버리고 싶은 유혹

그런데 리뷰가 가장 느린 고리라는 게 드러나면 요즘은 꽤 다른 방향의 이야기도 나온다. 바로 “AI 시대에 사람이 코드를 한 줄씩 읽는 리뷰가 굳이 필요하냐”는 것이다. 코드는 AI가 짜고 테스트도 AI가 붙이는데 사람이 그걸 전부 읽고 있으니 병목이 생긴다는 논리이고, 그러니 리뷰라는 공정 자체를 없애거나 AI 리뷰로 통째로 갈아 끼우자는 이야기가 필자 주변에서도 꽤 들린다.

필자는 이 이야기를 들을 때마다 앞에서 본 허비가 떠오른다. 대열이 허비 때문에 늦어진다고 허비를 숲에 버려두고 가면 대열이 빨라진 것처럼 보이겠지만, 그건 대열이 도착한 게 아니다. 하이킹의 목표는 앞선 아이들이 먼저 도착하는 게 아니라 대열 전체가 목적지에 도착하는 것이기 때문이다. 가장 느린 고리를 없애는 건 사슬을 짧게 만드는 게 아니라 사슬을 끊는 것에 가깝다.

필자가 이 질문에 대해 더 신경쓰이는 것은 바로 이 결정이 내려지는 방식이다.

어차피 AI가 코드를 읽을테니 리뷰를 없애자는 이야기는 많이 들리는데, AI가 짠 코드의 품질이 실제로 얼마나 달라졌는지, 리뷰가 지금 무엇을 얼마나 걸러내고 있는지를 재보고 나서 이런 이야기를 하는 사람은 거의 없는 것 같다. AI 도입의 효과를 재지 않았던 것과 같은 방식으로 리뷰를 없애는 결정까지 내려질 수 있다는 것이다.

오히려 앞에서 본 DORA의 배포 안정성 하락이나 Faros AI 조사의 개발자당 버그 9% 증가, GitClear가 본 중복 코드 8배 같은 신호는 리뷰가 걸러내야 할 일이 늘고 있다는 것을 나타낸다. 그리고 리뷰를 없애고 나면 리뷰가 막아주던 것들은 리뷰 단계가 아니라 장애와 롤백, 몇 달 뒤의 변경 비용으로 드러날 확률이 높다.

게다가 리뷰가 하는 일은 버그를 찾는 것만도 아니다. 마이크로소프트 개발자들을 조사한 연구에서 결함을 찾는 건 리뷰의 가장 큰 동기였지만 실제 리뷰는 기대보다 결함과 덜 관련되어 있었고, 대신 지식 전달과 팀이 서로의 작업을 아는 효과를 냈다.

구글의 코드 리뷰를 분석한 연구에서도 개발자들이 리뷰에 기대하는 것의 중심은 결함 발견보다 서로 가르치고 배우는 교육과 코드를 읽고 이해할 수 있게 만드는 쪽에 있었다. 9월 포스팅에서 이야기했던 맥나마라 오류처럼 재기 어려운 효과를 없는 것처럼 다루기 시작하면 리뷰는 비용만 남은 공정으로 보이기 쉽다.

물론 리뷰가 힘들어진 건 사실이다. PR은 커졌고, 코드를 올린 사람조차 그 코드를 왜 그렇게 짰는지 설명하기 어려운 경우가 늘었으니 리뷰어가 읽어야 할 양도, 읽어내는 데 필요한 맥락도 예전보다 훨씬 무거워졌다. 다만 공정 자체를 없애는 건 문제를 푸는 것이라기보다 그 힘듦을 피하기 위한 합리화에 더 가깝지 않을까 하는 생각이 든다.

6월 포스팅에서 이야기했던 것처럼 검토마저 AI에게 넘기는 순간 그 코드의 인과는 팀의 어느 머릿속에도 남지 않는다. 리뷰를 빠르게 만드는 것과 리뷰를 건너뛰는 것은 다른 일이고, 이어지는 단계들은 전부 리뷰를 빠르게 만드는 쪽에 해당하는 이야기다.

가장 느린 고리의 짐을 덜어준다

허비를 찾았다면 AI를 허비 쪽에 쓰는 방법을 고민해야 한다. 보이스카우트 이야기에서 대열을 빠르게 만든 건 빠른 아이들을 더 빨리 걷게 하는 게 아니라 허비의 배낭을 덜어주는 일이었다.

리뷰가 허비인 팀이라면 AI를 코드를 더 많이 쓰는 데 쓰기보다 리뷰할 코드를 더 작고 읽기 쉽게 만드는 데 쓰는 편이 낫다. 큰 변경을 리뷰 가능한 작은 단위로 나누고, 변경의 의도를 PR 설명에 명확하게 남기고, 테스트를 붙여서 리뷰어가 동작을 하나하나 머릿속으로 돌려보지 않아도 되게 하는 것이다. DORA 2025 보고서가 AI의 효과를 키우는 조직의 역량으로 작은 단위로 일하는 습관을 꼽은 것도 같은 맥락이라고 생각한다.

허비가 리뷰가 아니라 그 앞에 있는 팀도 많다. 무엇을 만들지 정하는 데 몇 주씩 걸리는 팀이라면 AI는 코드를 더 빨리 쓰는 것보다 결정을 더 빨리 내리는 데 쓰일 때 효과가 크다. 기획 문서를 놓고 몇 번씩 회의를 반복하는 대신 AI로 간단한 프로토타입을 몇 개 만들어서 직접 만져보고 고르는 식이다.

말로 하는 논쟁은 끝이 잘 안 나지만, 돌아가는 화면 2개를 나란히 놓으면 의외로 빨리 결론이 나는 경우가 많다. 프로토타입을 만드는 비용이 거의 0이 된 지금은, 결정을 미루는 비용이 상대적으로 훨씬 비싸진 셈이다.

QA가 가장 느린 고리인 팀도 있다. 개발이 끝난 기능이 수동 QA 일정을 기다리며 며칠씩 줄을 서는 팀이라면 코드를 더 빨리 쓰는 건 QA 앞의 대기열만 늘릴 뿐이다.

이런 팀에서는 AI를 반복되는 회귀 테스트를 자동화하는 데 쓰거나, 기획 문서와 변경 내용을 바탕으로 QA 시나리오 초안을 뽑아서 QA 담당자가 빈 문서가 아니라 초안을 검토하고 보완하는 데서 시작하게 만드는 편이 낫다. 어떤 시나리오가 중요한지 판단하는 건 여전히 사람의 일이지만, 시작점이 달라지는 것만으로도 짐은 꽤 가벼워질 수 있다.

나머지 고리를 가장 느린 고리에 맞춘다

세 번째는 조금 직관에 반하는데, 허비가 아닌 단계의 속도를 허비에 맞추는 것이다. 앞의 예시에서 팀이 일주일에 리뷰할 수 있는 PR이 50개라면 PR을 80개씩 만들어봐야 30개는 대기열에 쌓일 뿐이다. 차라리 PR을 만드는 속도를 리뷰할 수 있는 양에 맞추고, 남는 시간을 리뷰를 돕거나 리뷰가 필요 없는 일에 쓰는 편이 팀 전체로는 더 빠를 수 있다.

이걸 실제로 하는 방법 중 하나가 진행 중인 일의 양을 제한하는 것이다. 리뷰 대기 중인 PR이 일정 개수를 넘으면 새 PR을 올리는 대신 다른 사람의 PR을 먼저 리뷰하는 식의 규칙이다. 리틀의 법칙으로 보면 처리 능력이 같을 때 쌓여 있는 일의 양을 줄이면 리드 타임은 그만큼 줄어든다.

물론 큐가 완전히 비어버리면 이번에는 병목이 할 일 없이 놀게 되면서 처리량이 떨어진다. 그래서 목표는 큐를 아예 없애는 게 아니라 병목이 놀지 않을 만큼의 작은 큐만 남기는 것이다. 골드랫은 이걸 북, 버퍼, 로프로 정리했는데, 북은 병목의 속도, 버퍼는 병목 앞에 남겨두는 작은 큐, 로프는 앞 공정이 그 이상 일을 밀어넣지 못하게 묶어두는 끈이다. 앞에서 말한 리뷰 대기 PR 개수 규칙이 바로 이 로프 역할을 하는 셈이다.

말이 쉽지 이건 꽤 어려운 일인데, 개인의 지표가 나빠 보이기 때문이다. PR을 덜 만들고 남의 PR을 리뷰하는 개발자는 자기가 올린 PR 수만 보는 대시보드 위에서 가장 느린 사람으로 보인다. 그래서 이 단계는 개인의 결심보다 리더가 무엇을 지표로 보느냐가 더 중요하다.

가장 느린 고리 자체를 키운다

앞의 세 단계가 지금 있는 허비를 최대한 잘 쓰는 방법이었다면 그다음은 허비 자체의 처리 능력을 늘리는 것이다. 앞의 예시로 말하면 팀이 일주일에 리뷰할 수 있는 PR을 50개에서 75개로 늘리는 일이다.

리뷰가 허비인 팀을 들여다보면 리뷰가 몇몇 사람에게 몰려 있는 경우가 많다. 특정 모듈을 제대로 아는 사람이 한두 명뿐이라 그 모듈을 건드리는 PR은 전부 그 사람 앞에 줄을 서는 식이다.

이런 팀에서 리뷰할 수 있는 양을 늘리는 방법은 리뷰어를 더 빨리 일하게 만드는 게 아니라, 그 코드를 리뷰할 수 있는 사람을 늘리는 것이다. 도메인 지식을 문서로 남기고, 경험이 적은 팀원을 리뷰에 같이 참여시키고, 모듈의 경계를 정리해서 한 사람이 다 알지 않아도 되게 만드는 일들이 여기에 해당한다.

이건 당장의 속도를 위한 일이라기보다 투자에 가깝고, 효과가 나타나기까지 시간도 꽤 걸린다. 그런데 필자는 6월 포스팅에서 이야기했던 도제의 문제도 사실 같은 문제와 연결되어 있다고 생각한다. 경험이 적은 개발자가 리뷰에 참여하는 건 리뷰 역량을 늘리는 일이면서, 동시에 AI가 코드 작성을 대신하는 시대에 그 개발자가 코드를 판단하는 감각을 기를 수 있는 몇 안 되는 자리이기도 하기 때문이다.

AI가 이 과정을 도울 수도 있다. 리뷰어가 처음 보는 모듈의 변경을 리뷰할 때 그 변경이 어디에 영향을 주는지 찾아보거나, 관련된 과거 변경 이력을 정리하는 일은 AI가 꽤 잘한다. 다만 앞에서 이야기한 것처럼 판단은 여전히 사람이 해야 하고, AI는 리뷰어가 판단할 수 있는 상태에 더 빨리 도달하게 돕는 쪽에 머물러야 한다.

한편 작은 팀이라면 리뷰를 하는 사람이 QA나 배포까지 함께 맡는 경우도 많다. 이런 팀에서는 뒤쪽 단계를 자동화해서 줄어든 시간이 그대로 리뷰에 쓸 수 있는 시간이 되니, 뒤쪽 단계를 개선하는 일이 곧 병목 자체를 키우는 일이 되기도 한다.

그리고 리뷰가 충분히 빨라지면 허비는 또 다른 곳으로 옮겨간다. 이번에는 QA일 수도 있고 배포일 수도 있고, 다시 처음으로 돌아가 무엇을 만들지 정하는 단계일 수도 있다. 골드랫이 5번째 단계를 반복으로 둔 것처럼, 허비를 찾는 일은 한 번 하고 끝나는 게 아니라 계속 돌려야 하는 루프에 가깝다.

비교할 대상을 남겨둔다

마지막은 측정이다. 앞에서 본 것처럼 조직이 측정을 피하는 이유는 측정할 줄 몰라서보다 측정이 불편해서에 더 가까운 것 같다. 그래서 필자는 측정을 의지의 문제로 두기보다 처음부터 구조로 만들어두는 편이 낫다고 생각한다.

하나는 도입하기 전에 예측을 적어두는 것이다. 리드 타임이 얼마나 줄어들 것인지, 배포 안정성은 어떻게 될 것인지를 대략이라도 적어두고 분기마다 실제와 맞춰본다. 예측이 틀렸다면 그건 실패가 아니라 우리 팀의 허비가 어디에 있는지 잘못 알고 있었다는 신호다.

다른 하나는 비교할 대상을 남겨두는 것이다. 한 팀이나 일부 업무에서 먼저 도입하고, 도입하지 않은 쪽과 리드 타임과 안정성을 나란히 놓고 본다. 9월 포스팅에서 이야기한 DORA 지표처럼 배포 빈도나 리드 타임 같은 속도 지표와 변경 실패율이나 복구 시간 같은 안정성 지표를 함께 봐야 하는데, 앞에서 본 것처럼 AI가 가장 먼저 흔드는 게 바로 안정성이기 때문이다.

도입부에서 이야기했던 토스의 지표가 생산성만이 아니라 애플리케이션 안정성까지 함께 재려는 것도 같은 맥락이다. 아무래도 빨라졌다는 숫자만 보고 있으면 퇴보한 쪽은 눈에 잘 들어오지 않기 마련이다.

필자라면 처음에는 세 개 정도만 보겠다. 요청에서 배포까지 걸린 리드 타임의 중간값, PR이 리뷰를 기다린 시간의 중간값, 그리고 배포한 변경 중 롤백이나 긴급 수정으로 이어진 비율이다.

셋 다 AI 말고도 다른 요인에 흔들리는 거친 숫자지만, 9월 포스팅에서 이야기했던 것처럼 불완전한 지표 몇 개가 같은 방향을 가리키는지를 보는 편이 완벽한 지표 하나를 찾느라 아무것도 재지 않는 것보다 낫다. 그리고 이 셋이 도입한 쪽에서만 좋아지고 있다면 그때 비로소 AI가 팀을 빠르게 만들고 있다고 말할 수 있을 것이다.

물론 이렇게 해도 AI의 효과를 깔끔하게 증명할 수는 없고, 결국 어찌어찌 거친 숫자 몇 개를 들고 판단해야 한다. 다만 적어도 올라온 PR 수가 늘었다는 이유로 팀이 빨라졌다고 믿는 일은 막을 수 있다.

마치며

이번 포스팅은 “AI를 도입하기만 하면 정말 팀이 빨라지는 걸까”라는 의문에서 시작했다. 그리고 리서치를 계속 하다 보니 결국 현재까지의 AI는 팀이 가진 사슬의 고리 중 하나를 빠르게 만들 뿐이고 팀의 속도는 그 고리가 아니라 사슬 전체가 정한다는 결론에 이르게 됐다. 코드 작성이 허비가 아니었던 팀에서 코드 작성만 빨라져봤자 팀은 덜 빨라지거나, 대기열이 쌓이는 만큼 오히려 느려질 수도 있다는 것이다.

그런데 필자에게 더 크게 남은 건 그다음 질문이었다. 왜 이 정도로 결과가 엇갈리는데도 많은 조직은 그걸 확인해보지 않는 걸까. 남들이 다 하는 걸 우리도 하고 있다는 사실이 이미 목적이 되어버렸고, 미리 적어둔 예측이 틀리는 건 개인에게 너무 불편한 일이기 때문이다. 결국 AI 도입이 팀을 빠르게 만드느냐는 질문은 AI보다 우리 팀이 자기 사슬의 어디가 가장 약한지 알고 있느냐는 질문에 더 가깝다. 그리고 그 질문에 답하지 않은 조직일수록 막힌 고리를 들여다보는 대신 아예 끊어버리자는 쪽으로 기울기 쉽다.

100년 전 공장들이 전기 모터에서 실제로 효과를 보기까지 40년이 걸린 건 모터가 부족해서가 아니라, 증기기관 자리에 모터를 바꿔 끼운 채로 공장을 그대로 두었기 때문이었다. 그리고 솔로와 데이비드가 이 역설을 짚어낼 수 있었던 것도 결국 누군가 공장 문을 나서는 생산량을 꾸준히 재고 있었던 덕분이라고 볼 수 있다. 아무도 재지 않았다면 모터를 바꿔 끼운 공장이 그대로라는 사실조차 몰랐을 것이다.

소프트웨어 팀도 마찬가지다. 올라온 PR 수나 AI가 작성한 코드의 줄 수는 기계가 얼마나 바쁘게 돌았는지를 보여줄 뿐이고, 팀이 실제로 빨라졌는지는 출구에서 재야 비로소 알 수 있다. 사용자에게 실제로 배포된 기능이 얼마나 되는지, 그리고 그 기능 하나가 닿기까지 얼마나 걸렸는지를 재야 하는 것이다. 그래서 필자는 AI를 어디에 끼워 넣을지보다 먼저 정해야 하는 게 우리 팀의 출구가 어디이고 거기서 무엇을 잴 것인지라고 생각한다. 그걸 재기 시작해야 비로소 우리 팀의 허비가 어디에 있는지도 보이기 때문이다.

이상으로 AI를 도입하면 팀은 정말 빨라질까 포스팅을 마친다.