AI 코딩 시대, Linear는 CI를 다시 설계했다

코드 생성 속도가 검증 시스템을 추월했다

Linear가 공개한 CI 재설계 사례의 출발점은 단순하다. 에이전트가 코드와 테스트를 더 빨리 만들면서 모든 변경이 통과해야 하는 지속적 통합(CI)이 새 병목이 됐다. 연초 이후 테스트 스위트가 거의 4배가 됐지만, 회사는 풀리퀘스트 대기 시간을 6분 이상에서 5분 남짓으로 낮추고 테스트당 머신 시간을 약 절반으로 줄였다고 밝혔다.

핵심은 단일 테스트를 미세 최적화한 것이 아니다. 더 빠른 러너, 임계경로 단축, 반복 설정 제거, 테스트 배치 개선을 하나의 시스템 문제로 다뤘다. AI 코딩 도구의 성과를 ‘생성된 코드’로만 재면 이 비용은 숨는다. 실제 생산 단위는 리뷰와 테스트를 통과해 배포 가능한 변경이며, 검증 대기시간은 사람과 에이전트 모두를 멈춘다.

가장 큰 숫자는 작은 작업에서 나왔다

Linear는 GitHub Actions 기본 환경에서 더 빠른 CPU·스토리지·캐시를 제공하는 제3자 러너로 옮긴 뒤 같은 파이프라인의 작업 시간이 평균 34% 줄었다고 보고했다. 네이티브 TypeScript 컴파일러 tsgo 전환은 타입 검사 주간 중앙값을 73% 낮췄고, 타입 정보가 필요했던 사용자 정의 ESLint 규칙을 AST 정적 분석으로 바꿔 API 린트 68%, 전체 저장소 린트 55%를 줄였다.

더 흥미로운 것은 짧은 선행 작업이다. 변경 파일을 판별하는 작업의 체크아웃 범위를 줄이자 중앙값이 26초에서 8초, p90이 31초에서 12초로 내려갔다. 캐시 마커 기록을 병합 임계경로 밖으로 옮긴 것만으로 42초를 절약했다. GitHub의 sparse checkout 안내와 actions/checkout 문서는 이런 최적화가 화려한 도구 교체보다 의존성 그래프 이해에서 시작함을 보여 준다.

캐시는 항상 정답이 아니다

CI 최적화의 흔한 처방은 캐시지만 Linear의 node_modules 복원은 적중해도 약 28초가 걸렸다. 반면 필터링한 새 설치는 약 7.5초였다. 자주 바뀌는 lockfile 때문에 적중률도 낮았다. 캐시 저장·전송·압축 비용을 포함하면 다시 만드는 편이 더 쌌다. API 컨테이너도 전체 마이그레이션을 반복하는 대신 스키마 스냅샷을 불러와 데이터베이스 준비를 약 12초에서 1~2초로 줄였다.

테스트 샤드는 4개에서 8개로 늘렸다. 일반적으로 샤드를 늘리면 벽시계 시간은 줄고 총 러너 시간은 늘 수 있다. 하지만 사전 설정을 110~140초에서 약 40초로 낮춘 뒤 병렬화를 늘려 가장 느린 샤드를 5.25분에서 4.33분으로 줄였다. Vitest의 sharding 문서처럼 파일 단위 분배에서는 큰 테스트 파일 하나가 꼬리를 만들 수 있어 파일 크기와 실행시간 분포를 함께 봐야 한다.

격리 해제는 성능과 정확성의 교환이다. Linear는 모든 테스트가 아니라 명시적으로 허용한 파일만 모듈 레지스트리를 공유하게 하고, fake timer나 공유 상태를 안전하게 정리하지 못한 파일은 격리된 프로젝트에 남겼다. 에이전트가 테스트 대부분을 작성하게 되자 관련 규칙을 에이전트 스킬에도 넣었다. 이는 Real-SWE, 사내 코드 벤치마크의 반격이 강조한 실제 저장소 문맥의 중요성과 맞닿는다.

한국 개발팀이 바꿔야 할 지표

국내 팀은 먼저 평균 CI 시간이 아니라 ‘변경 제출부터 필수 검사 완료까지’의 p50·p90·p95를 분리해야 한다. 그리고 러너분, 재시도율, 캐시 적중 시 실제 절약시간, 가장 늦은 샤드와 가장 빠른 샤드의 차이를 함께 기록해야 한다. 에이전트가 PR을 병렬로 만들면 평균이 그대로여도 대기열과 동시 실행 비용이 급격히 커질 수 있다.

두 번째는 에이전트에게 테스트 생성 규칙만 주지 말고 비용 규칙도 주는 것이다. 큰 파일 분할, 전역 상태 정리, 변경 경로별 검사 선택, 실패 시 재현 명령을 저장소 지침으로 만든다. 세 번째는 생성과 검증 예산을 묶는 것이다. SWE-2가 말하는 코딩 모델의 비용 전선처럼 모델 비용만 비교하면 러너와 리뷰 비용이 빠진다. i-have-ADHD, 코딩 에이전트 답변도 UX다에서 다룬 피드백 설계도 CI에 그대로 적용된다. 빠르고 구체적인 실패 메시지가 다음 에이전트 시도를 줄인다.

GitHub Actions 사용량 문서는 운영체제와 러너 유형에 따라 비용 단위가 달라질 수 있음을 보여 준다. 따라서 Linear의 절감률을 그대로 예산에 대입하기보다 우리 파이프라인의 임계경로와 고정비를 계측해야 한다.

자주 묻는 질문

Q1: 샤드를 늘리면 무조건 빨라지나요?

A: 아니다. 샤드마다 체크아웃·설치·부팅 고정비가 생기므로 먼저 설정 비용을 충분히 낮춰야 한다.

Q2: 캐시는 왜 더 느릴 수 있나요?

A: 압축 파일 다운로드와 복원, 낮은 적중률, 저장 비용이 새 설치나 재빌드 비용보다 클 수 있다.

Q3: 테스트 격리 해제는 안전한가요?

A: 전역 상태와 타이머를 확실히 정리하는 파일에만 선택적으로 적용하고 누수 검사를 추가해야 한다.

Q4: 가장 먼저 볼 지표는 무엇인가요?

A: 필수 검사의 임계경로 p95와 PR당 총 러너분을 함께 보라. 속도와 비용을 한쪽만 최적화하면 병목이 이동한다.

Q5: AI 에이전트 지침에 무엇을 넣어야 하나요?

A: 테스트 배치 규칙, 허용된 공유 상태, 변경 경로별 실행 명령, 실패 로그 형식과 비용이 큰 검사의 조건을 명시하는 것이 좋다.