AI 코딩 때문에 병목이 된 CI, Linear는 이렇게 고쳤다

Who Should Read

AI 에이전트로 PR이 쏟아져 CI 대기 시간과 러너 비용이 늘어난 TypeScript 모노레포 백엔드 개발자

Core Mechanics

• 테스트는 4배, 대기는 오히려 줄었다
  • 올해 초 이후 테스트 스위트가 거의 4배로 늘었다.
  • PR 대기 시간은 6분 초과에서 5분 남짓으로 줄고, 테스트당 러너 시간은 약 절반이 됐다.
• 러너와 컴파일러만 바꿔도 크게 빨라졌다
  • GitHub Actions에서 더 빠른 CPU·스토리지·캐시를 가진 서드파티 러너로 옮기자 전후 이틀 비교로 작업이 평균 34% 빨라졌다.
  • tsc 같은 작업은 52% 줄었다.
  • 네이티브 TypeScript 컴파일러 tsgo로 바꾸니 tsc 체크 주간 중앙값이 73% 줄었다.
• 린트에서 타입 정보를 뺐다
  • 타입 정보가 필요한 커스텀 린트 규칙을 AST(코드 구문 트리) 정적 분석으로 다시 짰다.
  • ESLint에서 TypeScript를 빼서 API 린트 시간은 68%, 전체 레포 린트는 55% 줄었다.
  • 문법만 보는 규칙이라 Oxlint로 옮기기도 쉬웠다.
• 다른 작업을 막는 앞단 잡부터 줄였다
  • 변경 감지 잡에서 fetch 깊이를 제한하고 불필요한 checkout을 없앴다.
  • 변경 감지 잡 중앙값은 26초에서 8초, 최악은 138초에서 37초가 됐다.
  • 캐시 마커 쓰기를 머지 필수 체크 밖으로 옮겨 머지 경로에서 42초를 아꼈다.

Community Reactions

• CI보다 사람이 하는 테스트가 병목이라는 의견
  • 동작은 하더라도 고객이 이해하고 좋아할 방식인지 확인하는 단계가 느리다는 경험이 나왔다.
• LLM이 만든 테스트 상당수가 쓸모없다는 의견
  • LLM이 쓴 PR의 테스트 중 내장 기능이나 사소한 동작만 검증하는 것이 많다는 지적이 있었다.
  • 테스트가 4배 늘었다고 가치도 4배냐는 반문이 나왔다.
• 셀프호스팅 러너와 Bazel로 CI를 줄였다는 경험
  • 셀프호스팅 GitHub 러너와 Podman, 도커 이미지 캐시로 린트·단위 테스트 포함 CI를 60초 이내로 줄였다는 경험이 있었다.
  • Bazel을 쓰면 웜 캐시에서 큰 프로젝트도 약 10초라는 의견과, 빌드와 테스트를 함께 스케줄링해야 한다는 의견이 있었다.
• 에이전트에는 작고 격리된 서비스가 낫다는 의견
  • 서비스 간 계약만 지키면 내부는 에이전트가 자유롭게 고칠 수 있어 모놀리스보다 유리하다는 주장이 있었다.

How to Apply

• 변경 감지 잡의 checkout을 얕게 바꾸기
  • 오늘 워크플로의 첫 번째 변경 감지·경로 필터 잡을 열어라.
  • fetch-depth를 제한하고 작업 트리가 필요 없는 잡은 checkout 단계를 지워라.
  • 변경 전후 잡 소요 시간을 비교해라.
• 샤드별 셋업 시간을 측정해 샤드 수 정하기
  • 테스트 잡 로그에서 설치·DB 준비 등 테스트 전 시간을 재라.
  • 샤드를 늘리기 전에 pnpm --filter 설치와 베이스 이미지 사전 설치로 셋업부터 줄여라.
• 큰 테스트 파일 쪼개고 Vitest 격리 풀기
  • 가장 오래 걸리는 샤드의 큰 테스트 파일을 작은 파일로 나눠라.
  • 안전한 파일만 isolate: false 프로젝트에 opt-in 주석으로 넣고, fake timers 쓰는 파일은 제외해라.
• 에이전트 지침에 테스트 규칙 넣기
  • 에이전트가 테스트를 쓰는 레포라면 skill이나 지침 파일에 opt-in 조건과 teardown 규칙을 적어라.

Try It

# Claude Code나 ChatGPT에 붙여넣기 (원문 방법을 프롬프트로 옮긴 것)

아래는 우리 CI 워크플로 파일과 최근 잡 로그 요약이다.

{{워크플로 YAML}}

{{잡별 소요 시간 / 셋업 시간}}

다음 순서로 분석해줘.
1. 다른 잡을 막는 앞단(change detection 등) 잡에서 불필요한 전체 checkout이 있는지 찾아줘.
2. 매 잡마다 반복되는 설치·셋업(apt, pnpm install, DB 마이그레이션)을 찾아줘.
3. 전체 워크스페이스 설치를 필요한 패키지만 설치하도록 바꿀 수 있는지 알려줘.
4. 샤드 수를 늘려도 셋업 비용이 테스트 시간보다 커지지 않는지 계산해줘.
5. 각 개선안을 예상 절감 시간 순으로 정리하고 수정된 YAML을 보여줘.

이어서 해 볼 것: 가장 느린 샤드의 테스트 파일별 소요 시간을 붙여넣고 쪼갤 파일을 추천받아라.

Terminology

관련 논문

• Mercury 3: 규모를 키운 diffusion LLM, 초당 1,000토큰 이상

  Diffusion LLM을 40배 키웠더니 속도 4~8배, 품질은 속도 특화 모델 수준

• Timestral: Mistral의 시계열 파운데이션 모델

  209M 파라미터 시계열 모델이 3대 벤치마크 1위, CPU에서도 돌아간다

• DeepSeek V4.1 Flash 1017 (Max) 성능·속도·가격 분석

  DeepSeek V4.1 Flash 1017 Max는 지능 지수 45에 211 tok/s, 입력 $0.30

• LLM 프록시를 직접 안 돌리면 무슨 일이 벌어지는지 어떻게 아나

  자체 LLM 프록시를 세웠더니 키·모델·캐시 미스를 직접 볼 수 있다

• DeepSeek V4.1 Flash 1017: 싼 가격에 1M 컨텍스트를 주는 에이전트용 모델

  DeepSeek V4.1 Flash 1017은 입력 $0.05/M, 1M 컨텍스트의 에이전트용 모델

• DeepSeek-V4.1-Flash-1017 공개: 더 짧게 생각하고 더 빠르게 일하는 에이전트용 모델

  DeepSeek V4.1 Flash 마이너 업데이트로 코딩·에이전트 벤치 점수↑, 실행 시간·출력 길이↓

• Llmspeed: 로컬 LLM 속도를 하드웨어 구매 전에 체감해 보는 시뮬레이터

  GPU·모델을 고르면 로컬 LLM 속도를 미리 체감하게 해 주는 시뮬레이터

Related Resources

• https://linear.app/now/ci-bottleneck-reworked
• https://dagger.io/blog/the-great-ci-bottleneck-of-2026/
• https://grog.build/
• https://linear.app/now/sharing-growth-with-the-people-buildi...