turborepo 기반 30개+ Next.js 앱 monorepo의 GitHub Actions CI 빌드 시간을 30분대에서 5분대로 단축한 과정이다. Runner 사양 업그레이드, GitHub Actions Matrix 병렬 빌드, turborepo dry-run 캐시 사전 점검을 단계별로 조합해 최대 84% 단축을 달성했다.
핵심 포인트- GitHub Actions Matrix로 30개+ Next.js 앱을 병렬 빌드, 캐시 미적중 시 10m27s → 8m06s(-22.5%)
- turbo run build --dry-run으로 캐시 상태 사전 점검, 전체 캐시 시 빌드 단계 자체 스킵 → 오버헤드 최소화
- Matrix 도입 직후 캐시 적중 시나리오에서 1m14s → 6m57s(+463%) 역효과 — dry-run으로 해결
- fail-fast: false 설정으로 일부 패키지 빌드 실패해도 나머지 계속 진행, 개별 빌드 결과 독립 확인
- verify-build job으로 여러 Matrix 결과를 단일 branch protection status check로 통합
상세 정리- 문제 배경: 30개 독립 상용 프로젝트 monorepo, main 병합 빈번 + pnpm-lock.yaml 잦은 변경 → 캐시 미적중 빈번
- 기존 구조: Kubernetes 기반 turborepo 원격 캐시 서버 + dorny/paths-filter 적용에도 캐시 미적중 시 20분+, 여러 워크플로우 동시 실행 시 30분+
- 1단계 Runner 업그레이드: Ubuntu Runner 메모리·코어 상향 → 20분대 → 10분대, 중단 오류(The operation was canceled) 해소
- 2단계 Matrix 병렬 빌드: generate-matrix job에서 빌드 대상 패키지 목록 생성 → build job에서 matrix.package별 pnpm build --filter 병렬 실행
- Matrix 트레이드오프: 캐시 미적중 -22.5% 개선, 캐시 적중 +463% 악화 — 병렬화 오버헤드가 캐시 이점을 소멸
- 3단계 dry-run 최적화: check-turborepo-cache.sh로 미적중 패키지 수 확인 → 0개면 빌드 스킵, 0개 이상이면 해당 패키지만 Matrix 실행
- 최종 성과: 캐시 미적중 10m27s → 5m29s(-47.5%), 캐시 적중 1m14s → 1m11s(-4%), 전체 피크 비교 84% 단축
- verify-build: needs: build-matrix로 모든 Matrix 성공 여부 집약 → 단일 status check로 브랜치 보호 정책 단순화
- 확장성: dry-run으로 미적중 패키지만 선별 실행 → 패키지 수 증가해도 불필요한 병렬화 오버헤드 발생 안 함
왜 읽나turborepo + GitHub Actions monorepo CI를 운영하는 팀이 실제 수치와 함께 최적화 단계를 따라갈 수 있다. dry-run 기반 선택적 Matrix 빌드 패턴은 패키지 수가 늘어도 캐시 적중 시 불필요한 실행을 막는 구조적 접근이다.