AI 코딩 에이전트는 병목을 어디로 옮기는가?

AI 코딩 에이전트는 병목을 어디로 옮기는가?

고객 지원 팀의 큐가 9분 만에 티켓을 처리했다가, 에이전트가 한 번 손도 대지 않은 채 4시간을 기다리는 상황을 본 적 있을 겁니다. 지금 개발 팀들도 AI 코딩 에이전트를 도입한 후 같은 일이 일어나고 있습니다. 코드는 몇 분 안에 작성되지만, 그 다음은 큐에서 대기합니다. 에이전트를 도입했는데도 팀의 처리량이 거의 움직이지 않았다면, 도구가 형편없다는 뜻이 아닙니다. 진짜 병목을 발견했다는 뜻이고, 그것은 당신이 찾던 곳이 아닙니다.

이것이 2026년 개발 조직 전체를 보는 가장 실용적인 시각입니다. AI 코딩 에이전트(제한된 인간 지시만으로 코드 계획, 작성, 테스트까지 수행하는 소프트웨어로, 자동완성 스타일의 어시스턴트와는 다름)는 코드 작성 단계의 마찰을 줄입니다. 그런데 작성 단계가 소프트웨어 파이프라인의 진정한 병목(poste limitant, 전체 라인의 처리량을 지배하는 병목 단계)이 되는 경우는 거의 드뭅니다. 보통 리뷰, CI, 배포가 병목입니다. 제약이 아닌 단계를 빠르게 하면 처리량이 증가하지 않습니다. 다음 단계 앞의 큐만 길어집니다.

AI 코딩 에이전트 도입 후 병목은 어디로 이동했을까?

2026년 업계 데이터 두 가지가 같은 방향을 가리킵니다. CircleCI의 State of Software Delivery 보고서에 따르면, 중앙값 팀의 피처 브랜치 처리량은 전년 대비 15% 증가했지만, 실제 프로덕션에 도달하는 메인 브랜치 처리량은 같은 기간 7% 감소했습니다(CircleCI, 2026 State of Software Delivery). 파이프라인 앞으로 들어오는 작업은 늘었지만, 뒤로 나가는 작업은 줄었습니다.

별도로, GitLab 개발자 조사를 InfoQ가 인용한 자료에 따르면, 응답자의 85%가 AI가 병목을 코드 작성에서 리뷰와 검증으로 옮겼다고 동의했으며, 79%는 전체 배포 프로세스가 코딩 속도를 따라가지 못한다고 답했습니다(InfoQ, AI coding outpaces governance). 이것은 도구 부족이 아닙니다. 병목이 이동했는데 아무도 라인을 다시 측정하지 않은 것입니다.

Little's Law는 코드 작성 속도를 신경쓰지 않습니다

Little's Law는 왜 이런 일이 발생하는지, 그리고 소프트웨어에만 국한되지 않는 이유를 설명합니다. 이것은 배송 센터의 픽업 큐나 병원의 퇴원 프로세스와 같은 수학입니다:

WIP = 처리량 × 주기 시간

WIP는 진행 중인 작업(작업 중인 PR, 리뷰 대기 중인 티켓)이고, 처리량은 단위 시간당 완료된 단위 수이며, 주기 시간은 한 단위가 시작부터 완료까지 소요되는 시간입니다.

리뷰 용량을 건드리지 않으면서 코드 생성을 가속화하면, 시간당 더 많은 단위가 처리량이 변하지 않은 단계로 푸시됩니다. WIP는 어딘가에 쌓입니다. 미리뷰 PR 백로그, 증가하는 병합 큐, 또는 급하게 diff를 훑어보는 리뷰어들이 나타납니다. 이것들은 모두 비용이 따릅니다. 3일 더 기다리는 PR은 "비용 없음"이 아닙니다. 맥락입니다. 작성자는 이미 다음 작업으로 넘어갔고, 리뷰어는 전체 변경 사항을 다시 로드해야 하며, 수정 작업은 대기 시간이 길어질수록 비용이 많이 듭니다.

"AI 에이전트"는 이제 코딩 단계에서만 나타나지 않습니다

"AI 코딩 에이전트"라고 불리는 두 가지를 구분할 가치가 있습니다. 일부 도구는 리포지토리 내에서 소스 코드 작성 및 수정을 목표로 좁게 구축되었습니다. 다른 도구는 코드 작성 모드와 함께 리서치, 브라우징, 문서 생성을 포함하는 범용 에이전트입니다.

Genspark는 두 번째 유형입니다. 웹 브라우징, 슬라이드 또는 문서 생성, 그리고 단일 프롬프트에서 코드 작성 및 실행까지 할 수 있는 "슈퍼 에이전트"입니다. 이 폭은 일반인에게는 유용하지만, CI 파이프라인 내에 사는 것과 실제 리포지토리에 대해 PR을 여는 목표 도구와는 다른 작업을 수행합니다. 도구의 설계를 파이프라인 단계에 맞추고, 그 반대가 아니라야 합니다.

Manus는 더 나아가서 전체 가상 컴퓨터(브라우저, 터미널, 파일 시스템) 내에서 작동하며 다단계 작업을 계획하고 실행하며 완성된 결과물을 전달합니다. 개발팀에게는 한 가지 의미 있는 직관입니다. 코딩의 가장 빠른 부분 단계만이 아니라 전체 작업 단위를 완료하는 에이전트만이 실제로 처리량을 움직입니다.

PCE: 에이전트가 실제로 도움이 되는지 알려주는 유일한 숫자

Process Cycle Efficiency(PCE)는 부가 가치 시간과 총 주기 시간의 비율이며, AI 코딩 에이전트가 파이프라인을 개선했는지 아니면 병목을 이동시켰는지 확인하는 가장 정직한 방법입니다:

PCE = 부가 가치 시간 / 총 주기 시간

AI 코딩 에이전트를 도입하기 전에 현재 분할을 측정하세요. 일반적인 변경 사항의 라이프사이클 동안(첫 커밋부터 프로덕션에 병합될 때까지) 실제로 코드를 작성하거나 리뷰하는 데 소요되는 시간, 그리고 큐에서 기다리는 시간의 비율입니다. 대부분의 팀은 이 숫자를 계산한 적이 없으며 충격을 받습니다. 소프트웨어 파이프라인에서 PCE 25% 미만은 흔하며, 변경 사항의 총 수명의 3/4가 작업이 아닌 대기임을 의미합니다.

배포 30~60일 후 동일한 측정을 실행하세요. PCE가 올라갔다면, 에이전트가 실제 용량을 해제했으며 팀이 이를 사용하고 있습니다. PCE가 평탄하게 유지되거나 하락했다면, 에이전트는 이미 빠른 단계를 더 빠르게 했으며 추가 출력은 누군가 금요일에 열린 PR을 집계할 때까지 큐에 앉아 있습니다. 이것이 AI 분석 계층이 자리를 잡는 정확한 지점입니다. PCE가 이동했다는 것만으로는 부족하며, 실제로 차이를 흡수한 단계를 알아야 하고, 그것은 칸반 보드를 응시하는 것보다 자동화된 분류에서 더 빠르게 읽힙니다.

리뷰가 에이전트가 아니라 실제 병목인 3가지 신호

팀들이 가정하는 대신 측정하기 시작하면 몇 가지 패턴이 일관되게 나타납니다:

• 미리뷰 PR 수가 증가하는 동안 병합 수는 평탄 유지. 더 많은 단위가 라인으로 들어가고, 같은 수만큼 빠져나옵니다. 변경되지 않은 제약 앞의 전형적인 WIP 축적입니다.

• 평균 PR 크기 증가. 한 번에 전체 피처를 생성하는 AI 코딩 에이전트는 사람이 점진적으로 타이핑하는 것보다 큰 diff를 생성합니다. 더 큰 diff는 PR당 리뷰 시간이 더 오래 걸리므로, 헤드카운트와 라인당 리뷰 속도가 일정하더라도 리뷰어 처리량을 줄입니다.

• 첫 리뷰 대기 시간이 승인 후 병합 시간보다 빠르게 증가. 대기 시간이 누군가가 보기 시작하기 전이라면, 이것은 리뷰 용량 부족 또는 리뷰 우선순위 지정 문제로 인한 큐 문제입니다. 리뷰 품질 문제가 아닙니다.

이러한 사항들은 이국적인 도구를 추적할 필요가 없습니다. git 호스트의 API에서 주당 한 번 요청하고 에이전트를 배포한 주에 대해 플롯하면 이동의 형태를 보기에 충분합니다.

지원 팀이 개발 파이프라인보다 올바르게 수행하는 것

지원 및 이행 운영은 AI 코딩 에이전트가 존재하기 훨씬 전부터 정확히 이 문제와 싸워왔으며, 그 해결책은 깔끔하게 일반화됩니다. 첫 연락 티켓을 9분 안에 응답하지만 전문가 티어에 도달하는 데 4시간이 걸리는 큐는 전문가가 느린 리소싱 이야기가 아닙니다. 빠른 티어가 다운스트림에 있는 것에 비해 과도하게 배치되었다는 신호이며, 프론트엔드로 더 많은 티켓을 끌어오는 것은 백엔드 용량이 변할 때까지 도움이 되지 않습니다.

개발 팀은 코드 리뷰가 대시보드의 티켓 수처럼 큐로 보이지 않기 때문에 이 단계를 건너뜁니다. PR들이 "리뷰 대기 중" 상태에서 조용히 앉아 있고, 누군가 "2주 전 기능이 아직 배포되지 않은 이유"를 물어볼 때까지 알아차리기 쉽습니다. Theory of Constraints(시스템의 전체 출력이 모든 단계의 개별 속도 합계가 아니라 단일 병목 단계로 제한된다는 아이디어)는 해결책이 "빠른 부분을 더 빠르게 하는 것"이 절대 아니라고 말합니다. 실제 병목을 찾고, 용량을 보호하며, 그 다음에만 빠른 부분이 속도를 더 필요로 하는지 결정하세요.

AI 코딩 에이전트가 더 빠르게 코드를 배포한 지 몇 개월 후에 나타나는 더 조용한 제약이 있습니다. 문서 표류입니다. 새 엔지니어의 온보딩이 정보 충전량이 두 배가 될 때까지 아무도 알아차리지 못합니다. 문서는 3스프린트 전에 변경된 시스템을 설명하고 있습니다. GitBook과 같은 docs-as-code 플랫폼은 에이전트가 커밋하는 동일한 리포지토리에 대해 동기화하므로 최소한 종이 흔적이 코드 자체보다 더 빨리 뒤로 떨어지는 것을 방지합니다. 리뷰 병목을 수정하지는 않지만 두 번째 병목이 어둠 속에서 형성되는 것을 막습니다.

AI 코딩 에이전트를 의도적으로 느리게 해야 할까요?

때로는, 예. 그리고 모든 사람이 흥미로워하는 도구에 대해 인기 없는 것을 말하는 것입니다. 리뷰 용량이 앞으로 두 분기 동안 고정되어 있다면(헤드카운트 동결, 리뷰어는 이미 용량 상태), 에이전트가 인입 PR의 속도를 3배로 늘리도록 놔두는 것은 더 완성된 배포 기능을 생성하지 않습니다. 더 긴 큐와 위의 CircleCI 데이터에 따르면 더 낮은 메인 브랜치 성공률을 생성합니다. 리뷰어가 볼륨 압력을 받으면 더 적게 포착합니다.

그 상황에서 정직한 조치는 에이전트가 사이클당 생성하는 양을 제한하거나, 출력을 인간 리뷰어에게 닿기 전에 사전 리뷰 통과(린팅, 자동화된 테스트 커버리지 검사, 더 작은 diff 정책)로 게이팅하는 것입니다. 그것은 반AI 입장이 아닙니다. 그것은 슬로우 스테이션이 흡수할 수 있는 것보다 더 많은 단위를 라인에 예약하지 않는 것과 같은 논리입니다.

실제 제약이 리뷰어 헤드카운트가 아니라 리뷰어 주의력이라면, Lindy AI와 같이 분류 및 라우팅을 위해 구축된 워크플로우 에이전트는 리포지토리에 직접 닿지 않고도 실제 리뷰 시간을 확보할 수 있습니다. "리뷰어를 더 고용해야 하나" 또는 "더 많은 에이전트 시트를 사야 하나"라고 가정하기 전에 테스트할 가치가 있습니다.

다음에 실제로 투자할 곳

PCE 계산을 한 후가 아니라 에이전트 사용을 더 확대하기 전에 실행하세요. 배포 이후 부가 가치 시간의 점유율이 변하지 않았다면 아직 더 많은 에이전트 시트를 구매하지 마세요. 다음 예산 라인을 리뷰 용량, CI 처리량 또는 병합 큐 자동화에 할당하세요. 데이터가 가리키는 곳이 무엇이든, 30일 후에 숫자를 다시 실행하세요.

PCE가 실제로 개선되었고 리뷰가 속도를 유지하고 있다면, 에이전트의 범위를 확장하라는 신호이며, 그 전이 아닙니다. 먼저 측정하세요. AI 코딩 에이전트로부터 실제 처리량 이득을 얻는 팀은 가장 빨리 도입한 팀이 아닙니다. 실제 병목을 찾고 그곳에서 용량을 수정한 다음 빠른 단계를 더 빨리 실행하도록 허용한 팀입니다.