Docker image 크기와 빌드 성능을 어떻게 최적화합니까?

Question

Accepted Answer

Docker image를 최적화하는 것은 **크기**를 줄이고(더 작고, 더 빠르고, 더 안전함) **빌드 성능**을 개선하는 것(캐싱을 통한 더 빠른 빌드)을 수반합니다. 기법에는 최소한의 base image, multi-stage build, layer 최적화, BuildKit, 신중한 Dockerfile 설계가 포함됩니다.

## image 크기 줄이기

```text
✓ 최소한의 base image:
  - alpine(작음, ~5MB) — 그러나 musl libc가 일부 앱에 호환성 문제를 야기할 수 있음
  - slim 변형(예: python:3.12-slim) — full보다 작고, 호환성 문제 적음
  - DISTROLESS — 앱 + 런타임만, 셸/패키지 매니저 없음(가장 작고, 가장 안전함)
  - scratch — 빈 base(정적 바이너리용, 예: Go) → 최소한의 image
✓ MULTI-STAGE build — 도구로 빌드하고, 산출물만 출하(큰 크기 절약)
✓ RUN layer 결합 + 같은 layer에서 정리:
  RUN apt-get update && apt-get install -y x && rm -rf /var/lib/apt/lists/*
  (별도 layer에서 정리는 image를 줄이지 않음 — 파일이 이전 layer에 있음)
✓ .dockerignore — 쓸데없는 것을 컨텍스트/image 밖에 유지
✓ 프로덕션 image에서 캐시, 임시 파일, 개발 의존성 제거
```

## 빌드 성능 개선

```text
✓ layer 캐싱 — 안정적인 layer(의존성)가 변동성 있는 것(코드)보다 먼저 오도록 Dockerfile 순서 지정
✓ BUILDKIT(DOCKER_BUILDKIT=1 / 현대 Docker에서 기본) — 더 빠른 병렬 빌드,
  더 나은 캐싱, build secret, cache mount
✓ CACHE MOUNT — RUN --mount=type=cache,target=/root/.npm npm install
  → 빌드 간에 패키지 매니저 캐시 영속화(매번 재다운로드하지 않음)
✓ registry 캐시 / --cache-from — CI에서 캐시된 layer 재사용(캐시가 차가운 곳)
```

## multi-stage + distroless 예시

```dockerfile
FROM golang:1.22 AS build
WORKDIR /app
COPY . .
RUN CGO_ENABLED=0 go build -o app .

FROM gcr.io/distroless/static     # 셸 없음, OS 없음 — 작고 안전함
COPY --from=build /app/app /app
ENTRYPOINT ["/app"]
# → 최종 image는 몇 MB: 정적 바이너리만(full golang image의 ~800MB 대비)
```

## 왜 중요한가

Docker image 크기와 빌드 성능을 최적화하는 것은 가치 있는 시니어 수준 지식입니다. 그것이 **배포 속도, 저장 비용, 보안, 개발자 생산성**에 직접 영향을 미치기 때문입니다. 따라서 프로덕션 품질의 컨테이너화에 실질적으로 중요합니다. **image 크기 줄이기**가 중요한 이유는 더 작은 image가 더 빨리 배포되고 pull되며, 저장 비용이 더 적고, **더 안전하기**(더 적은 패키지 = 더 작은 공격 표면) 때문입니다. **최소한의 base image** 사용(alpine, slim, 특히 **distroless** — 셸이나 패키지 매니저 없이 앱과 런타임만 포함, 가장 작고 가장 안전함 — 또는 정적 바이너리용 `scratch`), **multi-stage build**(산출물만 출하), 신중한 **layer 최적화**(RUN 명령을 *같은* layer에서 정리와 함께 결합, 별도 layer에서의 정리는 실제로 image를 줄이지 않으므로 — 흔한 오해)는 image를 극적으로 줄일 수 있습니다(예: ~800MB에서 몇 MB로). **빌드 성능 개선**이 중요한 이유는 느린 빌드가 개발자 생산성과 CI 처리량을 해치기 때문입니다. **layer 캐싱**(안정적인 것을 변동성 있는 것보다 먼저 순서 지정), **BuildKit**(더 나은 캐싱을 갖춘 더 빠른 병렬 빌드), 특히 **cache mount**(빌드 간에 패키지 매니저 캐시를 영속화하여 의존성이 매번 재다운로드되지 않음 — 상당한 속도 향상), CI용 registry 캐시를 활용하는 것 모두 빌드를 더 빠르게 만듭니다.

이러한 기법 — 그리고 같은 layer 정리가 왜 중요한지, distroless가 크기와 보안을 모두 어떻게 개선하는지 같은 미묘한 점 — 을 이해하는 것은 진정으로 최적화된 image를 생성하는 데 필요한 깊이를 반영합니다.

image 크기와 빌드 속도는 배포, 비용, 보안, 생산성에 실제적이고 지속적인 영향을 미치고, 이러한 최적화 기법(최소한의/distroless base, multi-stage build, 올바른 layer 정리, BuildKit cache mount)이 가볍고, 빠르고, 안전한 image를 달성하는 것이므로, Docker image와 빌드 최적화를 이해하는 것은 프로덕션 컨테이너화를 위한 가치 있는 시니어 수준 지식이며, 전문적이고 최적화된 Docker 사용을 구분하는 핵심 기술이자 규모에 맞게 효율적이고 안전한 컨테이너 image를 빌드하는 데 기대되는 전문성을 반영합니다.