6분이 5분이 됐다, 그 사이 테스트는 4배가 됐다

CI 대기 시간이 6분에서 5분이 됐다. 이걸 성과로 읽으면 몇 달의 작업이 1분짜리로 보인다.

같은 기간에 테스트 스위트가 4배로 늘었다. 아무것도 안 했으면 지금 11분이다. 그러니까 이 작업의 성과는 1분 단축이 아니라 4배 증가분을 흡수한 것이다.

에이전트를 붙여 코드 생산량이 느는 팀이라면, CI 개선의 성과 지표를 어디에 두어야 하는지가 여기서 갈린다.

출처: linear.app/now/ci-bottleneck-reworked

확인된 것

원문에서 확인한 것만 적는다.

• 재설계를 시작한 이유를 한 문장으로 적어뒀다.

  Agents have made it exponentially faster to ship code, but validating those changes hasn't quite kept up at the same rate.

• PR 대기 시간 6분 이상 → 약 5분. 같은 기간 테스트 스위트는 2026년 1월 이후 4배. 최적화를 안 했다면 현재 스위트로 약 11분이 걸렸을 것이라고 적는다. 테스트당 러너 시간은 대략 절반으로 줄였다.

• 인프라·도구: GitHub Actions에서 서드파티 러너로 이전해 평균 34% 개선. TypeScript 컴파일러를 tsgo로 바꿔 타입 체크 73% 감소. 린터는 Oxlint로 이전.

• 게이팅 작업: 변경 감지 작업 26초 → 8초(중앙값). 크리티컬 패스에서 불필요한 캐시 쓰기 제거로 API PR당 42초 절약.

• 셋업 오버헤드: CI 베이스 이미지에 의존성 사전 설치. 모노레포 설치를 필요한 패키지로 제한해 44~73초 → 16~18초. 그리고 node_modules 캐싱을 포기했다 — 재빌드 7.5초가 복원 28초보다 빨랐기 때문이다.

• 짧은 검사 7개를 2개 작업으로 묶어 월 약 87,000 러너분을 아꼈다. 전체 CI 사용량의 **11.8%**다.

• 테스트 실행: 샤드를 4개에서 8개로 늘려 19% 빠르고 19% 저렴. 선택적 모듈 상태 공유로 월 17% 절감, 가장 느린 샤드가 300~379초에서 약 195초로. 샤드당 셋업 110~140초 → 67~73초(44% 감소). API 샤드 전체 러너 시간은 실행당 32.8분 → 22분.

판단

1. 성과 지표를 "단축"에 두면 잘한 일이 정체로 기록된다

6분이 5분이 된 것만 보고하면, 이 팀은 몇 달 동안 1분을 벌었다고 평가받는다. 실제로 한 일은 4배로 불어난 작업량을 같은 시간 안에 밀어 넣은 것이다.

에이전트를 도입한 팀에서 이 구분은 곧 현실이 된다. 코드 생산량이 늘면 테스트도, PR 수도, CI 실행 횟수도 같이 는다. 그 상태에서 대기 시간이 그대로면 아무 일도 안 일어난 것처럼 보이지만 실은 계속 달리고 있는 것이다.

→ 그래서 지표를 바꾸는 게 맞다. "대기 시간 X분 단축"이 아니라 "작업량 X배 증가를 흡수했다" 또는 "최적화 없이 오늘 얼마나 걸렸을까" 를 같이 기록한다. 반사실을 기록해두지 않으면 나중에 아무도 그 일의 값어치를 복원하지 못한다.

2. 캐시를 버린 결정이 가장 이전 가능한 교훈이다

node_modules 캐싱을 포기했다. 이유가 명확하다 — 재빌드 7.5초가 캐시 복원 28초보다 빨랐다.

캐시는 늘 이득이라는 가정이 여기서 깨진다. 그리고 이 역전은 조용히 일어난다. 캐시는 "동작"하고 있고 에러도 안 나기 때문이다. 패키지 매니저가 빨라졌거나, 캐시가 커졌거나, 러너의 네트워크가 느려졌으면 어느 시점부터 손해로 바뀌는데 아무도 알려주지 않는다.

→ 규칙: 캐시를 넣기 전에, 그리고 가끔씩, 캐시 없는 경로를 한 번 재봐라. 컨텍스트 압축을 다룬 연구를 읽으면서 "컴팩션 로직을 짜기 전에 실제로 컨텍스트 초과로 죽는 비율부터 세라"고 적었는데, 같은 형태다. 최적화를 넣기 전에 최적화 없는 값을 측정해두는 것.

3. 가장 큰 절감은 병렬화가 아니라 통합에서 나왔다

샤드를 4개에서 8개로 늘린 건 19% 개선이다. 짧은 검사 7개를 2개로 묶은 것은 전체 CI 사용량의 **11.8%**를 아꼈다.

30초짜리 작업 일곱 개가 따로 돌면 체크아웃·설치·부팅도 일곱 번이다. 실제 작업보다 준비가 더 걸린다. 하네스 비용을 다룬 글에서 "턴 수가 같은데 비용이 2배인 이유는 매 호출에 딸려 나가는 고정 짐"이라고 썼는데, CI 작업도 똑같다. 작업을 쪼갤수록 고정 비용이 곱해진다.

→ 내 CI에서 볼 것: 작업 목록을 열고 각 작업의 실제 실행 시간 대비 준비 시간 비율을 봐라. 준비가 더 긴 작업들은 합치는 게 맞다. 병렬로 보기 좋게 쪼개둔 것이 돈을 쓰고 있을 수 있다.

4. CI는 병목이 옮겨간 자리이지 마지막 자리가 아니다

인용한 문장이 정확한 진단이다. 에이전트가 코드를 내보내는 속도는 기하급수적으로 빨라졌고 검증이 못 따라왔다. 그래서 CI가 벽이 됐다.

그런데 CI를 고치면 다음 벽이 나온다. 토론에서 나온 지적이 그 자리를 짚는다 — "올바른 문제를 풀고 있는지 판정하는 일"은 여전히 사람에 달려 있다.

이번 주에 같은 자리에 세 번 도착했다. 병렬 세션을 늘리면 충돌이 머지 시점으로 미뤄지고, 보안 스캐너를 돌리면 504건을 사람이 읽어야 하고, CI를 빠르게 만들면 통과한 PR을 사람이 검토해야 한다. 에이전트를 늘릴 때 실제로 늘어나는 건 코드가 아니라 검토 대상이고, 검토는 병렬화되지 않는다.

→ 그러니 CI 최적화는 필요한 일이지만 최종 목적지가 아니라 통과 지점으로 잡는 게 맞다. 6분을 5분으로 만든 다음 질문은 "3분으로 줄일까"가 아니라 "이 PR들을 누가 읽나" 다.

모르는 것

• 직접 재현하지 않았다. 위 수치는 한 회사의 자체 측정이고 나는 그 글을 읽었다.
• 한국어 요약은 린트 시간이 55~68% 줄었다고 적는데, 내가 읽은 원문 범위에서 그 수치를 확인하지 못했다. Oxlint로 이전했다는 서술까지만 확인했다.
• 서드파티 러너 34%는 어느 벤더인지, 비용이 어떻게 달라졌는지 나와 있지 않다. 속도만으로는 판단할 수 없다.
• 모듈 상태 공유는 테스트 격리를 일부 포기하는 선택으로 보이는데, 그로 인한 플래키 테스트 증가 여부가 글에 없다.
• 이 규모(모노레포, 8샤드, 월 수십만 러너분)의 수치가 1인 프로젝트에 그대로 옮겨가지 않는다. 옮겨가는 건 순서와 측정 방법이지 숫자가 아니다.