코딩 에이전트가 풀 리퀘스트를 더 빨리 만들기 시작해도 개발팀의 속도는 CI 처리 속도에도 달렸다. 변경 사항이 합류하려면 여전히 CI를 통과해야 하고, 그 앞에 실행기 할당, 체크아웃, 의존성 설치, 변경 감지, 테스트가 차례로 놓인다. Linear은 이 대기열을 다시 손봐 풀 리퀘스트 대기 시간을 6분 초과에서 5분 조금 초과로 낮췄다고 2026년 9월 21일 밝혔다.
이 사례의 속도 향상은 테스트 수를 줄인 결과가 아니었다. 원문의 2026년 1월부터 9월까지 차트는 풀 리퀘스트 실행의 테스트 수가 3.7배가 되는 동안 테스트당 실행기 시간이 46% 줄었다고 보여 준다. 코드 생산량이 늘수록 CI는 여러 작업이 합류하는 대기열로 다뤄야 한다.
왜 평균 실행 시간만 보면 병목을 놓치나
CI에서 중요한 시간은 모든 작업의 평균이 아니라, 다음 작업을 열어 주는 선행 작업의 시간이다. Linear의 API 테스트는 여덟 개 조각으로 나뉘어 있지만, 변경 경로 확인과 이전 결과의 캐시 확인이 끝나기 전에는 하나도 시작할 수 없었다. 각 단계가 짧아 보여도 여덟 개 작업 앞에 서 있으면 합류 경로 전체를 멈춘다.
그래서 Linear은 작업 단위에서 건너뛸 수 있는 일을 먼저 판별해, 불필요한 작업이 실행기를 잡지 않게 했다. 동시에 변경 감지 작업은 전체 작업 트리를 가져오는 대신 필요한 이력 깊이만 가져왔다. 가장 느린 선행 작업은 94초에서 20초로 줄었다. 체크아웃이 필요 없는 작업에서는 체크아웃 자체를 없애 27초가 걸리던 구간을 7초로 낮췄다. 이 순서가 맞아야 테스트 자체를 조금 빠르게 만든 효과도 합류 시간에 반영된다.
병렬화는 준비 비용을 낮춘 뒤에 늘린다
테스트 조각을 두 배로 늘리면 느린 테스트를 기다리는 시간은 줄 수 있다. 반면 조각마다 실행기를 부팅하고 저장소를 받고 패키지를 설치한다면 준비 비용도 두 배가 된다. Linear은 API 테스트 조각마다 반복하던 Postgres 클라이언트 설치를 CI 기본 이미지로 옮기고, 모노리포 전체 대신 API 패키지와 그 의존성만 설치했다. 캐시 복원이 약 28초, 필요한 패키지 재설치가 약 7.5초인 경우에는 캐시를 없애기도 했다.
이 조정 뒤 API 테스트 조각의 준비 시간은 110~140초에서 67~73초가 됐다. 그 결과 네 조각일 때 8.3분이던 전체 준비 시간이 여덟 조각으로 늘린 뒤에도 7.5분에 머물렀다. 병렬화의 단위 수보다 먼저 봐야 할 값이 조각당 고정비라는 뜻이다. 짧은 검사 일곱 개도 각각 실행하지 않고 두 작업으로 묶어 내부에서 동시에 돌렸고, Linear은 2026년 6월 사용량 기준 월 8만 7,000 실행기 분을 아꼈다고 적었다.
더 빠른 검사보다 합류 경로의 순서를 바꿨다
Linear은 실행 환경도 바꿨다. GitHub Actions에서 더 빠른 CPU, 저장소, 캐시를 제공하는 외부 실행기로 옮긴 뒤 같은 작업이 평균 34% 빨라졌고, TypeScript 검사에는 네이티브 컴파일러인 tsgo를 써 주간 중앙값을 73% 낮췄다. 타입 정보를 요구하던 ESLint 규칙은 AST 기반 정적 분석으로 다시 써 API 린트 시간을 68%, 전체 저장소 린트 시간을 55% 줄였다.
이 사례는 개별 도구를 교체하는 것과 함께 합류 경로에서 미룰 수 있는 작업을 빼는 방법도 보여 준다. 캐시 마커 기록처럼 테스트가 끝난 뒤에 해도 되는 작업을 병합 전 마지막 검사에서 빼면, API 풀 리퀘스트와 병합 대기열마다 42초가 사라진다. 네트워크가 불안정한 체크아웃에는 재시도와 백오프, 약 30초 제한 시간을 두어 긴 꼬리 지연이 전체를 막지 않게 했다. 합류 경로에서는 빠른 작업을 고르는 일과, 합류를 막지 않아도 되는 일을 경로 밖으로 옮기는 일이 함께 필요하다.
팀의 CI 대기열은 무엇부터 재야 하나
코드 생성 도구를 도입한 팀이라면 전체 CI 시간 하나만 대시보드에 올려두기보다 세 값을 나눠 봐야 한다. 첫째, 테스트 조각을 시작시키는 선행 작업의 상위 지연이다. 둘째, 조각 하나가 실제 검사 전에 쓰는 준비 시간이다. 셋째, 테스트가 끝난 뒤에도 병합을 막는 후속 작업이다. 이 셋을 분리하면 실행기 사양을 높일지, 체크아웃 범위를 줄일지, 작업을 묶을지, 병합 조건에서 빼낼지를 각각 결정할 수 있다.
테스트 격리도 같은 방식으로 다룬다. Linear은 Vitest에서 안전한 파일만 선택해 모듈 상태를 공유하도록 했고, 느린 조각은 약 300~379초에서 약 195초로 낮아졌다고 밝혔다. 다만 가짜 타이머나 공유 상태를 안전하게 분리할 수 없는 파일은 기존 격리를 유지했다. 검사 신뢰성을 유지하면서 대기열을 줄일 수 있다. 합류 경로에서 어떤 비용이 필수이고 어떤 비용이 반복되는지를 구분하는 일이 먼저다.
출처: Linear, AI coding has made CI a bottleneck, so we reworked ours to keep up