Docker 빌드 캐시 미스가 반복될 때 비용과 시간을 줄이는 운영 플레이북

1. 문제 정의: 성공하는 배포인데도 CI 시간이 매일 흔들리는 상황

릴리스는 정상인데 배포 대기열이 계속 길어지는 팀은 대개 Docker 빌드 캐시를 “가끔 운이 좋으면 먹는 것”처럼 다룹니다. 지난달 저희도 같은 문제를 겪었습니다. 오전 9시 배포는 6분에 끝났는데 오후 핫픽스는 같은 코드 양인데 22분이 걸렸고, 러너 사용량 경고가 바로 올라왔습니다. 처음에는 네트워크 이슈로 봤지만 로그를 펼쳐 보니 npm ci와 시스템 패키지 설치 레이어가 매번 새로 실행되고 있었습니다. 원인은 단순했습니다. COPY . .가 너무 앞에 있어 문서 파일 하나 바뀌어도 의존성 레이어가 무효화됐고, 브랜치별로 캐시 키를 과도하게 분리해 재사용률이 낮았습니다. 이 단계에서 중요한 건 “빌드가 느리다”가 아니라 “어떤 레이어가 왜 깨졌는가”를 타임라인으로 보는 것입니다. 원인을 레이어 단위로 분해하지 않으면 도커파일을 여러 번 고쳐도 체감 개선이 거의 남지 않습니다.

2. 판단 기준: 캐시 적중률보다 변동폭과 재현성을 먼저 본다

실무에서 속도 최적화만 좇으면 의외로 더 위험해집니다. 저희는 개선 기준을 세 가지로 고정했습니다. 첫째, 평균 빌드 시간보다 p95 빌드 시간을 우선 관리합니다. 평균이 빨라도 특정 시간대에 3배 느려지면 온콜 부담은 그대로입니다. 둘째, 캐시 적중률 수치만 보지 않고 “어떤 변경에서 깨지는지”를 커밋 타입으로 묶어 봅니다. 예를 들어 코드 변경과 의존성 변경, 인프라 파일 변경을 분리하면 깨지는 패턴이 명확해집니다. 셋째, 빠른 빌드라도 결과 이미지 해시가 비정상적으로 흔들리면 실패로 간주합니다. 한 번은 속도 개선 후에도 타임존 패키지 버전이 환경마다 달라져 장애 직전까지 갔고, 그때부터 재현성 검증을 릴리스 게이트에 넣었습니다. 즉 기준은 “얼마나 빨라졌는가”가 아니라 “느린 날에도 예측 가능하고, 같은 입력에 같은 산출이 나오는가”여야 운영 비용이 내려갑니다.

3. 실행 절차: 도커파일 구조, 원격 캐시, 파이프라인 순서까지 함께 조정

실행은 작은 수정 한 번보다 묶음 변경이 효과적입니다. 먼저 도커파일에서 의존성 설치 전용 레이어를 분리합니다. package.json, 락 파일만 먼저 복사해 설치하고, 앱 소스는 그다음에 복사해야 문서나 테스트 코드 수정이 의존성 레이어를 깨지 않습니다. 다음으로 BuildKit 원격 캐시를 레지스트리에 저장하고 브랜치 공용 캐시를 기본값으로 둡니다. 기능 브랜치마다 캐시를 따로 두면 격리는 되지만 재사용률이 급격히 떨어지므로, 기본 캐시에 쓰고 충돌 가능성이 큰 실험성 브랜치만 분리하는 방식이 현실적이었습니다. 파이프라인 순서도 바꿨습니다. 린트와 유닛 테스트를 빌드 전에 병렬 처리해 실패를 빨리 끊고, 빌드는 성공 가능성이 높은 커밋에서만 돌리도록 조건을 걸었습니다. 마지막으로 주 1회 캐시 정리 작업을 두되 전량 삭제는 금지했습니다. 전량 삭제는 다음 날 전체 팀의 대기시간을 폭증시켜 절감한 비용을 하루 만에 되돌리는 경우가 많기 때문입니다.

4. 운영 체크리스트: 개선 후에 반드시 남겨야 하는 관측 항목과 롤백 규칙

개선 적용 후 일주일은 “빨라졌다”는 체감보다 지표를 먼저 봐야 합니다. 저희 팀 체크리스트는 단순합니다. 배포당 총 빌드 시간, 레이어별 캐시 히트/미스, 러너 분당 비용, 이미지 해시 안정성, 실패 재시도 횟수를 매일 같은 시간에 기록합니다. 그리고 변경 PR에는 반드시 롤백 조건을 숫자로 씁니다. 예를 들어 p95 빌드 시간이 15분을 넘거나 이미지 해시 불일치가 하루 2회 이상이면 즉시 이전 캐시 전략으로 되돌립니다. 실제로 한 번은 캐시 범위를 넓히는 과정에서 오래된 베이스 이미지가 재사용돼 보안 스캔 경고가 급증했고, 미리 정해 둔 조건 덕분에 30분 안에 원복했습니다. 결론은 분명합니다. Docker 캐시 최적화는 도커파일 트릭이 아니라 운영 정책입니다. 원인 분해, 기준 수립, 실행 절차, 롤백 규칙을 한 세트로 관리해야 CI 시간과 클라우드 비용이 함께 안정됩니다.