Image Layer & Cache

코드 한 줄 바뀔 때마다 운영체제 패키지 설치부터 전체 빌드를 다시 하면 개발과 CI가 모두 느려집니다. 이미지 전송도 매번 통째로 다시 해야 한다면 레지스트리 저장 공간과 네트워크 비용이 빠르게 커집니다. 빌드 결과를 단계별로 쪼개어 재사용하지 않으면 컨테이너의 빠른 반복이라는 장점이 사라집니다.

이미지를 레이어로 나누기 전에는 애플리케이션 환경을 산출물 하나처럼 통째로 다시 만드는 일이 흔했습니다. 코드가 조금만 바뀌어도 운영체제 패키지 설치와 의존성 다운로드를 반복하고, 이미 가지고 있는 기반 파일까지 매번 다시 저장하고 전송해야 했습니다. 이런 반복 마찰이 커지자 Docker는 파일시스템 변화를 레이어로 나누고, 바뀌지 않은 부분은 재사용하는 방식으로 빌드와 배포를 다루기 시작했습니다.

예를 들어 `COPY package.json` 다음 `RUN npm ci`를 두면, 의존성 파일이 바뀌지 않는 한 이 설치 레이어는 다시 실행되지 않습니다. 반면 `COPY . .` 뒤쪽에 있는 소스코드 레이어는 변경이 자주 생기므로 그 아래 단계부터만 재빌드됩니다. 레이어는 단지 저장 구조가 아니라, 어떤 단계가 얼마나 자주 무효화되는지를 설계하는 도구이기도 합니다.

Layer와 Multi-stage Build는 모두 이미지 최적화에 쓰이지만 초점이 다릅니다. Layer는 한 스테이지 안에서 결과를 누적하고 캐시하는 기본 단위이고, Multi-stage Build는 여러 스테이지를 나눠 최종 이미지에 남길 산출물만 고르는 패턴입니다. 캐시를 어떻게 살릴지와 무엇을 최종 산출물에 남길지는 별도의 질문입니다.

실무에서는 변경이 드문 의존성 설치를 앞쪽에, 변경이 잦은 애플리케이션 복사를 뒤쪽에 두는 방식이 거의 기본 규칙처럼 쓰입니다. CI가 느려졌을 때도 단순히 머신 성능을 키우기보다, 어느 레이어가 자주 무효화되는지부터 보는 편이 더 본질적인 해결로 이어집니다.