도커 빌드 캐시

도커 빌드 캐시 (Docker build cache)

같은 이미지를 여러 번 빌드하다 보면 '똑같은 빌드를 또 하는데 왜 이렇게 오래 걸리지?'라는 생각이 들 때가 있어요. 도커는 빌드 결과를 캐시에 남겨 바뀐 부분만 새로 빌드하고 나머지는 재사용해요. 이 캐시가 어떤 원리로 동작하는지 이해하면, 빌드를 빠르게 만드는 Dockerfile을 훨씬 잘 설계할 수 있어요.

출처: https://docs.docker.com/build/cache/

본문

같은 도커 이미지를 반복해서 빌드할 때, 빌드 캐시를 최적화하는 방법을 아는 건 빌드를 빠르게 만드는 데 아주 유용한 도구예요. 캐시 원리를 이해하는 것 자체가 더 나은 Dockerfile을 쓰는 출발점이에요.

레이어 단위로 캐시가 동작해요

도커가 이미지를 만들 때는 Dockerfile의 각 지시어가 하나의 레이어를 만들어요. 그리고 캐시는 이 레이어 단위로 저장돼요. 어떤 레이어의 입력이 달라지지 않았다면 그 레이어는 재빌드하지 않고 캐시를 그대로 가져와요.

레이어가 바뀌면 이후 레이어도 함께 재빌드돼요

여기서 핵심 규칙이 하나 있어요. 한 레이어가 바뀌면, 그 뒤에 오는 모든 레이어도 영향을 받아요. 예를 들어 C 프로그램이 담긴 작은 Dockerfile에서 main.c 파일을 수정했다고 생각해 볼게요. 그 변경이 이미지에 반영되려면 COPY 명령이 다시 실행되어야 하고, 도커는 이 레이어의 캐시를 무효화해요. 그리고 캐시가 무효화된 레이어 이후의 모든 레이어도 전부 다시 실행해야 해요. 데이터가 실제로 달라지지 않아도, 순서상 그 뒤에 있는 레이어들은 재빌드해야 하는 거예요.

이렇게 레이어 하나가 바뀌면 아래쪽(뒤쪽) 레이어가 전부 다시 빌드되는 것이 도커 빌드 캐시의 핵심 구조예요. 그래서 자주 바뀌는 내용(예: 소스 코드 복사)을 Dockerfile에서 가능한 뒤쪽에 배치하고, 자주 바뀌지 않는 내용(예: 의존성 설치)을 앞쪽에 두는 게 캐시 효율을 높이는 기본 전략이에요.

캐시를 더 잘 활용하려면

빌드 캐시를 효율적으로 쓰기 위한 세부 주제는 별도 페이지로 정리되어 있어요. 캐시 무효화가 발생하는 구체적인 경우, 캐시를 최적화하는 방법, 캐시 정리(가비지 컬렉션), 그리고 캐시 저장 백엔드에 대한 내용이에요. 이 페이지가 그 주제들로 들어가는 입구 역할을 해요.

도커 빌드 캐시