Turbo Cache 와 Github actions/cache 로 CI 시간 -94% 단축시키기

발단: 문서 한 줄짜리 PR도 CI가 3분

판단과 보관 — cache라는 단어를 둘로 쪼개기

여기서 태스크란 하나의 패키지에서 실행되는 하나의 명령 단위입니다. button#build, core#test처럼 패키지#스크립트 꼴로 적으며, package.json의 scripts에 정의된 build, test, lint 같은 명령 하나가 패키지 하나에 묶인 것이 곧 태스크 하나입니다. 그래프의 노드도, 해시가 매겨지는 단위도, cache 적중/미스가 판정되는 단위도 전부 이 태스크입니다. 이 글에서 "전 패키지 무효화", "60개 태스크 중 58개 적중" 같은 표현은 모두 이 단위를 센 것입니다.

[잡 시작]
   │
   ▼
actions/cache: .turbo/cache 디렉토리를 통째로 복원 (내용은 모름)
   │
   ▼
turbo run build test
   ├─ 태스크별 해시 계산
   ├─ 같은 키가 디렉토리에 있음 → 실행 생략, outputs 복원 + 로그 재생
   └─ 없음 → 실제 실행 후 해시를 키로 저장
   │
   ▼
actions/cache: 잡 종료 시 .turbo/cache 저장
   (같은 키가 이미 있으면 조용히 스킵 ← 뒤에서 볼 고장의 근원)

Turborepo는 어떻게 판단하는가 — 그래프와 해시

1. "의존관계 파악부터 먼저"라는 실행 순서가 존재한다. 순환 의존을 에러로 잡아내는 이유도 이것입니다.

2. 서로 의존이 없는 노드들은 동시에 실행해도 안전하다고 판단합니다.

// 패키지 그래프 — 각 package.json의 워크스페이스 의존 선언
{ "dependencies": { "@scope/core": "workspace:*" } }
// → "button은 core에 의존한다"

// 태스크 그래프 — turbo.json의 dependsOn
{ "test": { "dependsOn": ["^build"] } }
// → ^는 "내 의존 '패키지들'의"라는 뜻.
//    button#test는 core#build가 끝나야 시작할 수 있다

[core 한 줄 수정 — 무효화 전파 경로]

core#build ──→ button#build ──→ button#test  (연쇄 캐시 미스) -> 캐시 미스로 인해 태스크 다시 실행

---------------------------  (변경) ---------------------------

[core를 안 쓰는 경로 — 그대로 적중]

icons#build (HIT)    modal#build ──→ modal#test (HIT)

무효화 범위는 어떻게 결정되는가 — 시나리오로 보기

packages/
├── tokens/        색상·간격 등 디자인 토큰 (아무것에도 의존 안 함)
├── icons/         tokens에 의존
├── core/          tokens에 의존 — 대부분의 component가 의존하는 상위 패키지
├── button/        core, icons에 의존
├── modal/         core에 의존
└── calendar/      core에 의존 — 아무도 calendar에는 의존 안 함

button ──→ icons ──→ tokens
   └─────→ core ───↗
modal ────→ core
calendar ─→ core

잠깐, 이런 관리 체계가 없었다면 어떻게 해야 했을까

무엇이 죽어 있었는가 — 레포별 진단

얼마나 빨라졌는가 — 실측

마무리

참고 자료

• Turborepo — Caching

• Turborepo — Configuring tasks (dependsOn, inputs, outputs)

• GitHub Docs — Caching dependencies to speed up workflows