Docker이미지와 빌드

multi-stage build 기본

빌드 도구와 런타임 이미지를 분리하는 multi-stage build의 핵심 목적과 패턴을 정리합니다.

마지막 수정 2026년 3월 21일

기본 패턴

dockerfile
FROM node:22-alpine AS build
WORKDIR /app
COPY package.json package-lock.json ./
RUN npm ci
COPY . .
RUN npm run build

FROM nginx:alpine
COPY --from=build /app/dist /usr/share/nginx/html

설명

  • multi-stage build는 "빌드할 때 필요한 도구"와 "실행할 때만 필요한 결과물"을 서로 다른 stage로 분리하는 패턴입니다.
  • 프런트엔드 빌드, Go binary 컴파일, Java artifact 생성처럼 최종 산출물만 컨테이너에 담고 싶을 때 특히 효과가 큽니다.
  • 최종 이미지에 컴파일러, 패키지 매니저, 소스 전체가 남지 않으므로 이미지 크기와 공격 표면을 함께 줄일 수 있습니다.
  • stage 이름을 붙여 두면 COPY --from=build처럼 읽기 쉬운 참조가 가능해 유지보수도 편해집니다.
  • Dockerfile이 길어져 보여도, 실제로는 "무엇이 런타임에 꼭 필요한가"를 분리해 사고하는 습관이라는 점이 더 중요합니다.

짧은 예제

bash
docker build -t my-web .
docker image ls my-web

빠른 정리

항목효과
build stage의존성 설치, 컴파일, 번들링
runtime stage실행에 필요한 최소 파일만 보관
COPY --from앞선 stage 결과 복사
장점이미지 축소, 보안 표면 감소

주의할 점

multi-stage build를 써도 앞 stage에서 복사한 파일 범위가 넓으면 최종 이미지가 다시 커질 수 있습니다. "산출물만 옮긴다"는 원칙을 끝까지 유지하는 편이 좋습니다.

참고 링크

2 sources