FE Core팀의 CI 속도전: 캐시 전략으로 병렬 빌드 최적화

FE Core팀은 turborepo 기반 monorepo에서 30여 개 Next.js 앱을 운영하며, 잦은 main 병합과 pnpm-lock.yaml 변경 때문에 모든 프로젝트의 빌드와 안정성 검증이 필요한 환경을 다뤘다. 원격 캐시 서버와 dorny/paths-filter@v3로 불필요한 빌드를 줄였지만, 캐시 미적중 시 전체 CI가 20분 이상, 여러 워크플로우가 겹치면 30분 이상까지 늘어나며 중단 오류까지 발생했다.

먼저 Ubuntu Runner의 메모리와 코어 수를 올려 전체 실행 시간을 20분대에서 10분대로 줄였다. 하지만 단일 프로세스로 30개 프로젝트를 순차 빌드하는 구조 자체는 여전히 병목이었기 때문에, GitHub Actions Matrix를 도입해 프로젝트별 빌드를 병렬로 돌리는 방향으로 바꿨다.

Matrix 적용 효과는 상황에 따라 달랐다.

• 캐시 미적중 시: 10m27s → 8m6s로 개선
• 캐시 적중 시: 1m14s → 6m57s로 악화

즉, 병렬화는 캐시가 없을 때는 도움이 됐지만, 캐시가 잘 맞는 경우에는 오히려 오버헤드가 커지는 문제가 드러났다.

이 문제를 해결하기 위해 turborepo dry-run을 활용해 사전에 캐시 상태를 점검했다. turbo run build --dry-run으로 모든 패키지의 캐시 여부를 확인한 뒤, 모든 패키지가 캐시되면 빌드를 건너뛰고, 캐시 미적중 패키지만 Matrix 대상으로 실행하는 분기 구조로 바꿨다.

그 결과는 더 안정적이었다.

• 캐시 미적중 시: 10m27s → 5m29s로 추가 단축
• 캐시 적중 시: 1m14s → 1m11s로 오버헤드 최소화

마지막으로, Matrix로 분산된 개별 빌드 결과를 브랜치 보호 정책에서 단일 status로 관리하기 위해 빌드 검증 단계를 분리했다. 최종적으로 Runner 사양 개선, Matrix 병렬 빌드, 캐시 사전 점검, 검증 단계 분리를 조합해 전체 CI 파이프라인 시간을 **최대 84%**까지 줄였고, 빌드 미적중 시에는 30분대에서 5분대로 낮추는 성과를 얻었다.