GitHub Actions에서 도커 캐시를 적용해 이미지 빌드하기

GitHub Actions CI 환경에서는 로컬과 달리 도커 레이어 캐시가 기본적으로 동작하지 않는다는 점에서 출발해, 캐시를 활성화해 이미지 빌드 시간을 단축하는 방법을 Express 앱 예제와 함께 단계별로 설명한다. 카카오웹툰 배포 전환 과정에서 발견한 실전 경험이 담겨 있다.

핵심 포인트 - 핵심 발견: GitHub Actions는 매 워크플로우 실행 시 새로운 러너를 사용하므로 도커 레이어 캐시가 인스턴스 간 공유되지 않아 빌드 시간 절감 효과 없음 - 도커 레이어 캐시 기본 원리: Dockerfile의 각 명령어(RUN, ADD, COPY)가 레이어를 생성하고, 변경되지 않은 레이어는 재사용해 빌드 속도 향상 - RUN 명령어 최적화: 여러 apt-get 명령을 &&로 연결해 레이어 수와 이미지 크기 동시 절감 - 캐시 활용의 핵심: package.json과 package-lock.json을 소스 코드보다 먼저 COPY하고 npm install을 실행해야 의존성 레이어가 캐시되어 소스 변경 시에도 재설치 생략 가능 - GitHub Actions 캐시 전략: docker/build-push-action의 cache-from/cache-to 옵션 또는 GitHub Actions 캐시 레지스트리(ghcr.io)를 활용해 워크플로우 간 레이어 공유 - .dockerignore 활용: node_modules, npm-debug.log 등 불필요한 파일을 빌드 컨텍스트에서 제외해 COPY 시간 단축

상세 정리 - 도커 이미지는 Dockerfile 명령어 순서대로 레이어를 쌓으며, 특정 레이어가 변경되면 그 이후 모든 레이어가 무효화됨 - COPY . . 를 npm install보다 앞에 두면 소스 파일 변경 시 npm install도 항상 재실행 — 잘못된 레이어 순서 - 올바른 Dockerfile 순서: (1) package*.json 복사 → (2) npm install → (3) 소스 파일 전체 복사 → (4) EXPOSE/CMD - GitHub Actions에서 캐시 저장소로 ECR을 활용하면 ECR 데이터 전송 비용 발생 가능. GitHub Container Registry(GHCR)는 public 레포 무료 - buildx + cache-type=gha 조합: GitHub Actions 내장 캐시 스토리지를 도커 레이어 캐시로 직접 활용하는 방식 - 카카오웹툰 배포 전환 맥락: Elastic Beanstalk에서 ECR+ECS 방식으로 전환, 초기 캐시 미적용 시 배포마다 전체 빌드 반복 - 멀티스테이지 빌드 병행 시 각 스테이지별 캐시 전략이 필요해 복잡도 증가

왜 읽나: CI 환경에서 도커 레이어 캐시가 왜 동작하지 않는지 이해하고, Dockerfile 레이어 순서 최적화부터 GitHub Actions 캐시 설정까지 빌드 속도 개선 전략을 실습 예제와 함께 익힐 수 있다.