빌드 캐시 재사용은 정말 파이프라인을 더 안전하게 만드는가?

아니다. 캐시 재사용은 속도와 비용을 낮추는 도구이지 안전성을 자동으로 보장하는 장치가 아니다. 안전성은 캐시 키가 무엇을 묶고 무엇을 배제하는지에 대한 별도 설계 판단에서 나온다. 2026년 기준으로 공식 문서들이 반복해서 강조하는 지점도 결국 "실제 워크로드로 검증하라"는 한 문장이다.

이번 분석에서는 CI 파이프라인의 빌드 캐시를 대상으로, 캐시 키가 만들어지는 계층(레이어 명령·의존성 락파일)부터 적중률 관측, 워밍업 전략, 실측 수치, 테스트 선별·롤백 안전성과의 상충까지만 뜯는다. 캐시 백엔드 구현 자체나 분산 스토리지 내부 로직은 다루지 않는다.

  • 캐시 키는 문자열 조합 문제가 아니라 레이어 순서 설계 문제다.
  • 적중률은 눈대중이 아니라 수치로 관측해야 판단이 성립한다.
  • 워밍업 방식(사전 채우기/온디맨드/혼합)은 실제 접근 분포를 반영해야 한다.
  • 캐시 재사용을 넓히면 속도는 오르지만 테스트 선별의 정확도·롤백 안전성은 따로 검증해야 한다.

캐시 키는 어디서 만들어지고 무엇이 그것을 깨뜨리는가?

캐시 키는 명령과 입력의 조합에서 만들어지며, 그 조합이 조금이라도 바뀌면 무효화된다. Docker 공식 문서는 COPY/ADD 같은 단계에서 입력 파일이 바뀌면 후속 레이어 전체가 다시 만들어질 수 있다고 설명한다. 즉 캐시 키를 너무 넓게 잡으면 사소한 변경에도 재빌드 범위가 커지고, 너무 좁게 잡으면 서로 다른 상태가 같은 키로 묶여 오염된 재사용이 발생할 위험이 커진다.

AWS CodeBuild 문서도 같은 맥락에서, 도커 레이어 캐시와 사용자 지정 캐시 중 무엇을 캐시 대상으로 묶을지가 빌드 방식에 따라 달라진다고 안내한다(AWS CodeBuild 문서). 캐시를 "켠다/끈다"의 문제가 아니라 "무엇을 재사용 대상으로 볼 것인가"라는 정책 문제로 보는 편이 실무에 가깝다.

캐시가 실제로 얼마나 재사용되는지는 어떻게 확인하는가?

키 설계가 맞는지는 관측 없이는 판단할 수 없다. Bitrise는 빌드 캐시 메트릭을 별도로 제공해 캐시 적중·미스와 크기 변화를 수치로 보게 한다. Depot은 2025년 캐시 통계(cache statistics)를 공개해, 캐시가 "있다/없다"가 아니라 "얼마나 반복 재사용되는가"를 계량화하는 방향으로 이동했다. 캐시 키 설계의 품질은 결국 이 관측 가능성 위에서만 검증된다.

워밍업 전략은 실제 접근 패턴과 얼마나 맞아야 하는가?

맞지 않으면 벤치마크가 실제 성능을 과대평가한다. Azure Cache for Redis Enterprise Flash 문서는 자주 쓰는 키가 DRAM에, 덜 쓰는 키가 NVMe에 배치되는 구조에서 DRAM 키만 측정하면 실제 사용 패턴과 어긋난 결과가 나온다고 지적하며, redis-benchmark의 -r 옵션으로 접근 키를 랜덤화할 것을 권한다. 같은 맥락에서 Azure Architecture Center는 사전 채우기(pre-fill)·온디맨드 로드·혼합 방식 중 무엇을 쓸지를 성능 테스트와 사용량 분석으로 결정하라고 권고한다. 빌드 캐시도 마찬가지로, 워밍업 전략이 실제 트래픽·의존성 변경 빈도와 맞는지 먼저 확인해야 한다.

콜드 캐시와 웜 캐시, 수치는 얼마나 벌어지는가?

재현 조건이 다른 세 사례를 나란히 두면 격차의 크기 자체는 참고할 수 있다.

  • Firefox 컴파일러 캐시 사례: Linux에서 ./mach build 실행, ccache/sccache/buildcache 비교 기준으로 웜 캐시가 5분 35초에서 1분 12초까지 내려갔다는 2차 정리 기록이 있다.
  • 인프랩 사례(2023년): 의존성 설치가 88초에서 2.6초로, 약 97% 단축됐다고 보고됐다. 캐시 재사용이 가장 크게 먹히는 지점은 컴파일 자체보다 종종 의존성 복원 쪽이라는 점을 보여준다.
  • Blacksmith CI 관련 경험담(일본어 커뮤니티 글): 캐시 병목 해소 후 CI가 최대 35% 빨라졌다는 보고가 있으나, 공식 벤치마크가 아니라 운영 경험치로만 참고할 수 있다.

세 사례 모두 하드웨어·버전·부하 조건이 서로 달라 직접 비교는 어렵지만, 공통적으로 "웜 상태에서의 재사용"이 콜드 스타트보다 훨씬 크게 벌어진다는 점은 일관된다.

넓은 키와 좁은 키, 무엇을 얻고 무엇을 잃는가?

넓은 키(느슨한 무효화 조건)는 캐시 적중률을 높여 속도와 비용을 개선하지만, 실제로는 바뀌지 않아야 할 산출물까지 재사용해 오염된 빌드를 만들 위험을 키운다. 좁은 키(엄격한 무효화 조건)는 그 반대로 안전하지만 캐시 히트가 줄어 속도·비용 이득이 작아진다.

여기에 테스트 선별과의 상충이 겹친다. 의존성이나 설정 파일 하나만 바뀌어도 캐시 무효화 범위가 넓게 잡혀 있으면 광범위한 재빌드가 발생하고, 이는 테스트 선별로 줄여둔 실행 비용을 다시 늘린다. Docker의 최적화 가이드는 변경 빈도가 낮은 단계를 앞에, 자주 바뀌는 단계를 뒤에 배치하라고 권하는데, 이는 결국 캐시 무효화 범위를 좁히는 레이어 순서 설계와 같은 이야기다. 롤백 안전성 관점에서도, 무효화 단위가 거칠면 과거 배포 시점과 다른 산출물이 재생성될 가능성이 남는다.

캐시 재사용을 밀어붙여도 되는 파이프라인은 어떤 것인가?

의존성 변경 빈도가 낮고, 빌드 산출물이 결정적(deterministic)이며, 캐시 적중률을 관측할 도구가 이미 갖춰진 파이프라인에서는 캐시 재사용 범위를 넓혀 속도·비용 이득을 추구할 수 있다. 반대로 배포 직전 검증 단계, 롤백 대상이 되는 릴리스 빌드, 의존성 변경이 잦은 저장소에서는 캐시 키를 좁게 잡고 무효화 조건을 엄격하게 유지하는 편이 안전하다. 이 판단은 캐시 히트율과 재빌드 비용을 함께 관측한 뒤에만 내려질 수 있다.

핵심 정리

  • 캐시 키 설계는 문자열 조합이 아니라 레이어 순서와 무효화 범위를 정하는 정책이다.
  • 벤치마크는 DRAM/NVMe 혼합, 랜덤 접근처럼 실제 사용 패턴을 반영해야 신뢰할 수 있다.
  • 캐시 재사용이 가장 크게 먹히는 지점은 컴파일보다 의존성 설치·복원인 경우가 많다.
  • 캐시 적중률·미스율은 Bitrise 메트릭, Depot 통계처럼 수치로 관측돼야 설계 판단의 근거가 된다.
  • 넓은 캐시 키는 속도를 얻지만 테스트 선별 효율과 롤백 안전성은 별도로 검증해야 잃지 않는다.

참고 자료

더 알아보기

CI/CD 파이프라인 신뢰성: 캐시·테스트·배포의 균형 — 이 주제의 종합 가이드