pile·
프론트엔드·쏘카쏘카·

FE Core팀의 CI 속도전: 캐시 전략을 활용한 병렬 빌드

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 빌드 패턴은 패키지 수가 늘어도 캐시 적중 시 불필요한 실행을 막는 구조적 접근이다.
쏘카
쏘카 블로그
원문은 여기서 이어서 읽을 수 있어요
원문 읽기
읽음 (0)

이 글과 비슷한

  1. 프론트엔드·LINE EngineeringLINE Engineering·

    AI로 웹 엔지니어 없이 LINE 앱 안에서 그룹 영상 통화 서비스 만들기

    LINE Planet 팀의 PM과 Android 엔지니어 두 명이 웹 전문 엔지니어 없이 LINE 앱 내에서 그룹 영상 통화 서비스를 개발한 과정을 다룬다. LIFF(LINE Front-end Framework)와 LINE Planet SDK를 활용해 React/Vite 기반 웹 앱을 구성했고, Firebase Cloud Functions로 별도 서버 인프라 없이 구현을 완료했다.

    #react#webrtc#firebase+2