에이전틱 AI가 만든 CI 병목, 테스트 셀렉션으로 대기시간 90% 이상 줄인 사례

무엇이 바뀌었나

과거 Shopify CI/CD 팀에서 일했던 한 엔지니어가 자신이 혼자 운영하는 약 50만 줄 규모의 TypeScript 프로젝트에서 겪은 CI 병목 문제와 해결 과정을 공개했다[1]. 코딩 에이전트를 붙여 개발 속도를 높이자 코드 변경이 사람이 직접 짤 때보다 훨씬 빠르게 쌓였고, 이 변경분을 검증하는 CI 파이프라인이 병목 구간이 됐다. 기존에는 커밋 한 건을 검증하는 데 약 20분이 걸렸고[1], GitHub Actions 사용량이 늘면서 월 비용도 약 10달러에서 20달러, 다시 50달러로 뛰었다[1]. 그는 전체 테스트를 매번 다시 돌리는 대신 변경된 파일과 실제로 관련된 테스트만 골라 실행하는 테스트 셀렉션 방식을 도입했고, 이 선택 로직 자체를 실행하는 데는 약 15초가 추가로 들었다[1].

무엇이 얼마나 줄었나

도입 결과는 구간별로 확인됐다. 전체 CI 대기시간은 약 21분에서 13분으로 약 40% 줄었고[1], E2E(엔드투엔드) 테스트 레인은 약 12분에서 4분으로 약 65% 단축됐다[1]. 브라우저 테스트 실행 시간은 약 10분에서 3분 미만으로 약 70% 줄었고[1], 여러 작업이 동시에 몰리는 임계경로 경합 시간도 약 14분에서 6분으로 약 60% 감소했다[1]. 특히 눈에 띄는 지표는 p95 값이다. 상위 5% 지연 구간을 뜻하는 p95 E2E 시간은 약 23분에서 6분으로 74% 줄었고[1], 대기시간까지 포함한 p95 전체 CI 시간은 약 7시간35분에서 35분으로 92% 감소했다[1]. 평균값보다 p95가 훨씬 크게 개선됐다는 것은, 문제의 핵심이 평범한 케이스가 아니라 여러 작업이 한꺼번에 몰려 큐가 쌓이는 최악의 상황에 있었다는 뜻으로 읽힌다.

기업 실무에 주는 시사점

이 사례는 한 사람이 운영하는 프로젝트에서 나온 결과이지만, 시사하는 바는 코딩 에이전트를 여러 명이 동시에 쓰는 개발팀에도 적용될 여지가 있다. 에이전트가 사람보다 빠른 속도로 커밋을 만들어내면 CI는 공용 자원이라는 특성상 대기열이 먼저 병목이 되고, 이 병목은 개발자 체감 속도뿐 아니라 클라우드 비용에도 그대로 반영된다. 실제로 이 프로젝트의 GitHub Actions 비용이 짧은 기간에 5배로 뛴 것도 같은 맥락이다[1]. 테스트 인프라나 릴리스 엔지니어링을 맡는 조직이라면, 에이전트 도입 전에 전체 테스트를 매번 재실행하는 구조를 유지할지, 아니면 변경 영향 범위를 계산해 테스트를 선별하는 구조로 전환할지를 미리 검토해볼 필요가 있다. 이는 모델 자체의 성능보다 주변 인프라와 파이프라인 설계가 실제 생산성을 좌우한다는 최근의 다른 관찰들과도 맥락이 닿아 있다. 예를 들어 AI 코드 리뷰 기업 Ito는 모델 선택보다 라우팅·캐싱 같은 인프라 투자가 더 중요하다고 주장했고, Circuit Breaker라는 GitHub Action은 에이전트가 쏟아내는 PR을 구조적 신호만으로 점수화해 리뷰 우선순위를 정하는 접근을 시도한다. 두 사례 모두 이번 CI 개선 사례와 마찬가지로, 에이전트가 만들어내는 작업량 자체를 줄이기보다 그 작업량을 처리하는 주변 도구를 재설계하는 방향에 초점을 맞추고 있다.

확인할 조건과 한계

다만 이 결과를 그대로 다른 조직에 옮겨 적용할 수 있다고 보기는 어렵다. 발표된 수치는 특정 프로젝트의 코드 구조, 테스트 스위트 구성, 의존성 그래프의 복잡도에 크게 좌우되는 값이어서, 프로젝트 규모나 테스트 구조가 다른 조직에서는 개선 폭이 달라질 수 있다. 또한 변경 파일과 관련된 테스트만 골라내는 로직 자체가 잘못 설계되면 실제로 영향을 받는 테스트를 놓치는 위험이 있어, 선택 규칙의 정확도를 검증하는 과정이 도입 전에 선행돼야 한다. 이 사례는 1인 프로젝트에서 나온 것이라 여러 명이 동시에 커밋을 올리는 팀 환경에서 큐잉 패턴이 어떻게 달라지는지, 그리고 어떤 시점에 실험이 이뤄졌는지는 공개된 내용만으로는 확인되지 않는다.