🚀 Node.js Docker 이미지, 1.2GB → 57MB! 크기 95% 절감 성공기

[cloudbro-radar]

[출처] https://medium.com/@prateekjain.dev/a-step-by-step-guide-to-docker-image-optimisation-reduce-size-by-over-95-d90bcab3819d

출처의 내용을 번역해서 공유드립니다.

비대한 이미지의 실제 영향

이미지 크기는 프로덕션 환경에서 애플리케이션 동작에 직접적인 영향을 줍니다. 1GB짜리 이미지와 50MB짜리 이미지의 차이는 시작 속도에서 인프라 비용까지 다양한 요소에 영향을 줍니다.

• 빠른 배포: 작은 이미지는 CI/CD 파이프라인을 더 빠르게 통과합니다. 하루에도 수십 개 서비스를 배포하는 환경에서는, 배포마다 몇 분씩 줄이는 것이 곧 큰 차이가 됩니다.
• 비용 절감: 가벼운 이미지는 저장 공간을 덜 차지합니다. 실제로 팀에서 이미지 크기를 줄인 후 컨테이너 레지스트리 비용을 최대 60%까지 절감한 사례가 있습니다.
• 보안 강화: 패키지가 줄어들면 공격 벡터도 줄어듭니다. 한 사례에서는 불필요한 의존성 때문에 보고된 취약점의 3분의 2 이상이 발생한 것으로 드러났습니다.

Docker 이미지 크기는 애플리케이션 시작 시간에 직접적인 영향을 주며, 이는 오토스케일링 속도, 장애 복구 시간, 그리고 사용자 경험 전반에까지 영향을 줍니다.

---

예제 애플리케이션

이제 실제 프로덕션에서 배포할 수 있는 전형적인 Node.js 마이크로서비스를 표현하는 Express 애플리케이션을 예시로 살펴보겠습니다.

이 애플리케이션은 라우팅을 위한 express, 시간 포맷을 위한 moment, MongoDB 연동을 위한 mongoose, 그리고 cors와 helmet 같은 미들웨어를 포함합니다. 실제 마이크로서비스라면 로깅, 메트릭, 인증 미들웨어도 있을 수 있지만, 여기서는 단순화를 위해 기본적인 요소만 다룹니다.

먼저, 새로운 Node.js 프로젝트를 초기화합니다:

mkdir docker-shrink
cd docker-shrink
npm init -y

dependencies 설치합니다:

npm install express moment mongoose cors helmet
npm install --save-dev nodemon jest supertest

이제 index.js 파일을 생성합니다:

const express = require("express");
const moment = require("moment");
const cors = require("cors");
const helmet = require("helmet");

// Initialize express
const app = express();
const PORT = process.env.PORT || 3000;

// Middleware
app.use(cors());
app.use(helmet());
app.use(express.json());

// Routes
app.get("/", (req, res) => {
  res.json({
    message: "Hello from a slim Docker container!",
    timestamp: moment().format("MMMM Do YYYY, h:mm:ss a"),
    uptime: process.uptime(),
  });
});

app.get("/health", (req, res) => {
  res.json({ status: "UP", memory: process.memoryUsage() });
});

// Error handling middleware
app.use((err, req, res, next) => {
  console.error(err.stack);
  res.status(500).json({ error: "Something went wrong!" });
});

// Start server
if (process.env.NODE_ENV !== "test") {
  app.listen(PORT, () => {
    console.log(`Server running on port ${PORT}`);
  });
}

module.exports = app; // For testing

이제 이 애플리케이션을 Docker로 컨테이너화하기 시작합니다.

1단계: 표준 베이스라인 접근

대부분의 개발자와 마찬가지로, 저는 튜토리얼이나 Stack Overflow 글에서 그대로 가져온 단순한 Dockerfile로 시작했습니다. 아무 생각 없이 node:latest를 베이스 이미지로 사용한 방식이었죠.

FROM node:latest

WORKDIR /app

COPY package*.json ./
RUN npm install

COPY . .

EXPOSE 3000
CMD ["node", "index.js"]

이 이미지를 빌드합니다:

docker build -t node-app:phase1 .
docker images | grep node-app

이미지 크기가 1.22GB에 달해 매우 큽니다. 애플리케이션 코드는 몇 메가바이트에 불과할 수 있지만, 이미지에는 전체 Linux 배포판과 Node.js 런타임, 그리고 불필요한 수많은 의존성이 포함되어 있었습니다.

베이스라인 이미지 테스트

최적화를 진행하기 전에 애플리케이션이 정상 동작하는지 먼저 확인해 봅니다:

docker run -d -p 3000:3000 node-app:phase1
curl http://localhost:3000

애플리케이션이 정상적으로 동작하고 있습니다. 이제 최적화를 시작해 보겠습니다.

2단계: 올바른 베이스 이미지 선택

첫 번째 최적화는 더 슬림한 베이스 이미지로 전환하는 것이었고, 이는 즉시 여러 가지 이점을 가져왔습니다:

런타임에 필요하지 않은 불필요한 패키지와 유틸리티를 제거했습니다.
컨테이너의 공격 표면을 줄였습니다.
배포 과정에서 빌드 및 pull 속도를 크게 개선했습니다.

업데이트된 Dockerfile은 다음과 같습니다:

FROM node:slim

WORKDIR /app

COPY package*.json ./
RUN npm install

COPY . .

EXPOSE 3000
CMD ["node", "index.js"]

측정해 보겠습니다:

docker build -t node-app:phase2 . -f Dockerfile.phase2
docker images | grep node-app

이미지가 345MB로 줄어들었으며, 단 한 단어의 변경만으로 무려 71% 크기 감소를 달성했습니다! 베이스 이미지를 선택하는 것은 컨테이너 크기에 있어 가장 큰 영향을 주는 결정입니다.

슬림 이미지 테스트

더 가벼워진 이미지에서도 애플리케이션이 정상적으로 동작하는지 확인해 봅니다:

docker run -d -p 3000:3000 node-app:phase2
curl http://localhost:3000

애플리케이션은 동일하게 잘 동작하지만, 이미지 크기는 눈에 띄게 줄어들었습니다.

3단계: Alpine 베이스 이미지 사용

다음으로는 Alpine을 사용해 한 단계 더 최적화했습니다. Alpine은 초소형 크기와 보안성으로 유명한 미니멀리스트 Linux 배포판입니다. Alpine을 사용하면 이미지 크기를 크게 줄일 수 있을 뿐 아니라, 공격 표면까지 대폭 축소할 수 있습니다.

FROM node:alpine

WORKDIR /app

COPY package*.json ./
RUN npm install

COPY . .

EXPOSE 3000
CMD ["node", "index.js"]

이미지를 빌드하고 크기를 확인해 봅니다:

docker build -t node-app:phase3 . -f Dockerfile.phase3
docker images | grep node-app

이제 이미지 크기가 258MB로 줄어들었으며, 초기 1.22GB 대비 무려 78% 감소를 달성했습니다.

Alpine 기반 이미지 테스트

Alpine 기반 이미지가 정상적으로 동작하는지 확인해 봅니다:

docker run -d -p 3000:3000 node-app:phase3
curl http://localhost:3000

Alpine이 효과적인 이유는 태생적으로 가볍게 설계되었기 때문입니다. glibc 대신 musl libc를 사용하고, GNU Core Utilities 대신 BusyBox를 사용하며, 훨씬 더 작은 패키지 저장소를 제공합니다. 전체 배포판의 크기는 고작 5MB에 불과합니다.

하지만 클라이언트 프로젝트에서 어려운 교훈을 얻었습니다. Alpine으로 마이그레이션했을 때 개발 및 테스트 환경에서는 모든 것이 잘 동작했지만, 프로덕션에서는 무작위로 크래시가 발생하기 시작했습니다. 원인을 추적한 끝에, 네이티브 의존성이 glibc와 달리 musl libc에서 다르게 동작한다는 사실을 발견했습니다.

그 이후로는 특히 컴파일된 네이티브 모듈에 의존하는 애플리케이션을 다룰 때, Alpine 빌드를 철저히 검증하는 것을 최선의 관행으로 삼고 있습니다.

---

4단계: 멀티 스테이지 빌드와 .dockerignore 파일

제가 가장 많이 활용하는 강력한 기법 중 하나는 멀티 스테이지 빌드입니다. 이는 빌드 환경과 런타임 환경을 분리하여 이미지 크기를 줄이는 동시에 개발 시 필요한 툴의 이점을 모두 유지할 수 있는 방법입니다.

멀티 스테이지 빌드를 사용하면 기능이 완비된 Node 이미지를 활용해 애플리케이션을 컴파일·테스트·번들링한 후, 필수 아티팩트만 깨끗하고 최소화된 런타임 이미지(종종 Alpine 기반)로 복사할 수 있습니다. 이 접근 방식은 불필요한 파일과 개발 의존성을 제거할 뿐 아니라, 최종 컨테이너를 가볍고 안전하며 프로덕션에 적합한 상태로 유지합니다.

.dockerignore 파일은 Docker 빌드를 위한 .gitignore라고 생각하면 됩니다. 컨테이너에 무엇이 포함될지를 엄격히 관리해주며, 빌드를 더 깔끔하고 안전하게 만드는 가장 쉬운 방법 중 하나입니다.

빌드를 시작하기 전에, 이미지에 복사되면 안 되는 파일과 폴더를 제외하도록 .dockerignore 파일을 추가하는 것이 매우 중요합니다:

node_modules
npm-debug.log
tests
coverage
Dockerfile
.dockerignore
.env
*.md

멀티 스테이지 빌드를 적용한 Dockerfile은 다음과 같습니다:

# Build stage
FROM node:alpine AS builder

WORKDIR /app

COPY package*.json ./
RUN npm ci --only=production

COPY . .

# Runtime stage
FROM node:alpine

WORKDIR /app

COPY --from=builder /app/node_modules ./node_modules
COPY --from=builder /app/package.json ./
COPY --from=builder /app/*.js ./

EXPOSE 3000
CMD ["node", "index.js"]

이미지를 빌드하고 크기를 확인해 봅니다:

docker build -t node-app:phase4 . -f Do4kerfile.phase4
docker images | grep node-app

멀티 스테이지 빌드를 테스트합니다.

애플리케이션이 여전히 정상적으로 동작하는지 확인해 봅니다:

모든 것이 여전히 기대한 대로 잘 동작합니다!

이제 이미지는 178MB로 줄었으며, 이는 처음 크기에서 거의 85% 감소한 수치입니다. 멀티 스테이지 빌드는 빌드 도구와 중간 파일들을 최종 이미지에서 제외시켜 줍니다. 이 접근 방식은 하나의 컨테이너로 애플리케이션을 빌드하고, 다른 더 작은 컨테이너로 실행할 수 있게 해줍니다.

이 패턴은 특히 TypeScript 프로젝트에서 매우 효과적입니다. 실제 헬스케어 프로젝트에서는 TypeScript 컴파일과 테스트 단계에서 300MB가 넘는 아티팩트가 생성되었는데, 단일 스테이지 빌드를 사용했다면 최종 이미지에 포함되었을 것입니다. 멀티 스테이지 빌드는 최종 이미지에 컴파일된 JavaScript만 남겨둠으로써 이를 방지했습니다.

---

5단계: Distroless 사용하기

Google의 Distroless 이미지는 미니멀리즘을 한 단계 더 끌어올린 것으로, 운영체제의 패키지 관리자와 쉘까지 제거합니다. 이 이미지에는 애플리케이션 실행에 필요한 런타임 의존성만 포함됩니다.

Distroless의 특징은 다음과 같습니다:

• 패키지 관리자 없음 (apk, apt 등) → 공격자가 침입 후 악성 소프트웨어를 설치할 수 없습니다.
• 쉘 없음 (/bin/sh 없음) → 공격 표면이 줄어듭니다.
• 불변(Immutable)하고 최소화됨 → 보통 Alpine 기반 이미지보다 더 작습니다.
• 프로덕션 환경에 최적 → 재현성, 크기, 보안을 우선시하는 환경에 완벽합니다.

아래는 Distroless 이미지를 사용하는 Dockerfile 예시입니다:

FROM node:22-alpine AS builder

WORKDIR /app

COPY package*.json ./
RUN npm install --only=production

COPY . .

# Step 2: Use distroless image
FROM gcr.io/distroless/nodejs22

WORKDIR /app

COPY --from=builder /app /app

CMD ["index.js"]

이미지를 빌드하고 크기를 확인해 봅니다:

docker build -t node-app:phase5 . -f Dockerfile.phase5
docker images | grep node-app

Distroless 이미지를 테스트합니다.

애플리케이션이 Distroless 이미지에서도 정상적으로 동작하는지 확인해 봅니다:

컨테이너의 쉘에 접근을 시도해 보면, 존재하지 않는다는 것을 알게 됩니다:

docker exec -it <CONTAINER_ID> sh

이것은 Distroless 이미지의 보안 기능입니다. 쉘이나 악용될 수 있는 유틸리티가 전혀 포함되어 있지 않습니다.

Distroless 이미지는 애플리케이션과 그 실행에 필요한 런타임 의존성만을 담고 있습니다. 패키지 관리자도, 쉘도, 그 외의 것들도 없습니다. 이는 단순히 공간을 절약하는 것을 넘어, 보안을 극적으로 강화합니다.

Distroless를 적용한 후 최종 이미지는 143MB가 되었으며, 이는 원래 1.22GB 대비 88.2% 감소한 수치입니다. 기능이나 보안을 희생하지 않고 이 정도의 성과를 얻은 것은 놀라운 성취입니다.

---

6단계: 정적 바이너리 (Static Binaries)

궁극적인 크기 최적화를 위해 Node.js 애플리케이션을 독립 실행형 바이너리로 컴파일합니다. pkg나 nexe 같은 도구를 사용해 Node.js 런타임을 포함한 전체 애플리케이션을 단일 실행 파일로 묶을 수 있습니다.

이 방식은 공격 표면과 의존성 복잡성을 줄여줄 뿐 아니라, scratch나 distroless 같은 최소 베이스 이미지 위에서 실행할 수 있어 최종 이미지 크기를 20MB 이하로 줄이는 것도 가능합니다. 또한 Node.js 런타임이 필요 없어져, 훨씬 더 작은 이미지와 빠른 콜드 스타트를 보장합니다.

아래는 이를 위한 Dockerfile 예시입니다:

FROM node:alpine AS builder

WORKDIR /app

COPY package*.json ./
RUN npm ci --only=production
RUN npm install -g pkg

COPY . .
RUN pkg --targets node16-alpine-x64 index.js -o app

# Minimal runtime
FROM alpine:latest

WORKDIR /app
COPY --from=builder /app/app .

EXPOSE 3000
CMD ["./app"]

이미지를 빌드하고 크기를 확인해 봅니다:

docker build --platform=linux/amd64 -t node-app:phase6 . -f Dockerfile.phase6
docker run --platform=linux/amd64 -d -p 3000:3000 node-app:phase6

최종 이미지는 57MB로 크게 줄었으며, 이는 원래 크기의 단 4.7%에 불과합니다! 불필요한 레이어, 패키지, 의존성을 모두 제거하면서 엄청난 개선을 이뤄낸 것입니다.

실행 바이너리가 x86_64 아키텍처에서 문제없이 동작하도록, --platform=linux/amd64 옵션을 추가해 ARM 기반 Mac에서의 호환성 문제를 피했습니다.

정적 바이너리 이미지 테스트

컴파일된 애플리케이션이 정상적으로 동작하는지 확인해 봅니다:

docker run --platform=linux/amd64 -d -p 3000:3000 node-app:phase6
curl http://localhost:3000

이 접근 방식이 모든 경우에 적합한 것은 아닙니다. 정적 컴파일은 단순한 애플리케이션에서는 잘 동작하지만, 복잡한 의존성이 있는 경우 문제가 생길 수 있습니다. 실제로 개발 환경에서는 정상적으로 동작했지만, 동적 모듈 로딩 패턴 때문에 프로덕션에서는 실패한 경험도 있었습니다.

Node.js 애플리케이션을 다양한 기법으로 컨테이너화한 결과, 기본 베이스 이미지에서 시작해 scratch, distroless, 그리고 정적 바이너리까지 거쳐 최종적으로 57MB라는 놀라울 정도로 슬림한 이미지를 얻을 수 있었습니다.

---

Slim 사용하기 (이전 이름: Dockerslim)

최적화 워크플로우를 간소화할 방법을 찾던 중, Slim이라는 강력한 오픈소스 도구를 발견했습니다. 이 툴은 컨테이너 이미지 최소화를 자동화합니다. 이미지를 검사하고 런타임에 실제로 사용되는 것만 식별한 뒤, 나머지는 모두 제거합니다.

이 방식은 이미지 크기를 최대 30배 이상 줄여줄 뿐 아니라, 불필요한 패키지를 제거해 공격 표면을 줄여 보안을 강화합니다. 더욱 인상적인 점은 Dockerfile을 다시 작성하거나 애플리케이션 코드를 재구성할 필요 없이 이를 달성한다는 것입니다.

---

동작 방식

Slim은 컨테이너를 샌드박스 환경에서 실행시키고, 시스템 호출을 추적하여 최적화된 이미지를 새로 빌드합니다. 이 과정에서 런타임에 꼭 필요한 구성 요소만 포함하며, 다음과 같은 아티팩트를 생성합니다:

• 최소화된 이미지 (slim.<original-image-name>)
• 컨테이너 보안을 강화하는 Seccomp 프로필
• 파일, 패키지, 네트워크 사용 내역을 담은 리포트 디렉터리

---

설치 및 사용하기

Slim을 로컬에 설치하고, 1단계에서 만든 Docker 이미지(최초의 최적화되지 않은 Node.js 앱)를 대상으로 최적화를 진행해 보겠습니다.

macOS에서는 Homebrew를 통해 가장 쉽게 설치할 수 있습니다:

brew install docker-slim
slim --version

이제 node-app:phase1 이미지에 대해 최적화 명령을 실행합니다:

slim build node-app:phase1
docker images | grep slim

Slim을 사용하니 단 한 번의 명령으로 1.22GB였던 이미지가 불과 123MB로 줄어들었습니다!

Slim으로 최적화한 컨테이너가 정상적으로 동작하는지 확인해 봅니다:

docker run -d -p 3000:3000 node-app.slim
curl http://localhost:3000

Slim은 분명 인상적인 결과를 보여주지만, 신중하게 사용할 필요가 있습니다. 실제로 한 프로젝트에서는 Slim이 드물게만 사용되는 오류 처리 경로에서 필요한 파일까지 제거해 버려, 특정 조건에서만 나타나는 프로덕션 장애가 발생한 적이 있습니다.

즉, Slim은 만능 해결책이 아닙니다. 애플리케이션의 런타임 동작을 충분히 이해하고 그에 맞게 최적화 과정을 조율할 수 있을 때 가장 효과적입니다.

---

왜 Slim만으로 시작하지 않을까?

Slim의 놀라운 결과를 보면, 처음부터 수동 최적화를 할 필요가 있나 하는 의문이 생길 수 있습니다. 저 역시 이 접근 방식을 팀에 소개하면서 같은 질문을 던졌습니다.

자동화된 도구는 최적화에 훌륭하지만, 기본 원리를 이해하는 과정을 대체할 수는 없습니다. 수동 최적화를 먼저 배워야 하는 몇 가지 설득력 있는 이유는 다음과 같습니다:

• 문제 해결 능력: Slim이 중요한 파일을 제거했을 때, Docker 최적화 원리를 이해하고 있어야 문제를 빠르게 진단하고 수정할 수 있습니다. 자동화 도구만으로는 항상 불가능합니다.
• 제어와 예측 가능성: 수동 최적화는 이미지의 내용을 정밀하게 제어할 수 있어, 꼭 필요한 구성 요소만 남기고 더 예측 가능한 빌드를 만들 수 있습니다.
• 보안 검증: 보안 팀은 컨테이너 내용에 대한 완전한 가시성을 요구합니다. 수동 최적화 이미지는 이를 문서화하고 검증하기 쉽게 만들어 보안 정책 준수를 돕습니다.
• 지식 전이: 컨테이너 최적화 원리는 언어와 프레임워크를 가리지 않고 적용되므로, 수동 최적화는 다양한 프로젝트에 활용할 수 있는 유용한 기술입니다.
• 맞춤화와 유연성: 특정 요구에 맞춰 이미지를 조정할 수 있습니다. 예를 들어 빌드 파이프라인을 수정하거나 저장소 제약 조건에 대응할 수 있습니다.
• 빌드 프로세스 이해: 수동 최적화는 Docker 레이어가 어떻게 상호작용하는지, Dockerfile을 어떻게 구성해야 효율적인지 더 깊이 이해하게 합니다.

---

최적화의 잠재적 문제

최적화는 큰 개선을 가져오지만, 동시에 해결해야 할 몇 가지 과제를 동반합니다:

• Alpine 호환성 문제: 네이티브 의존성이 Alpine에서 다르게 동작할 수 있어 호환성 문제가 발생할 수 있습니다. 일부 라이브러리나 툴이 기대대로 작동하지 않아 추가적인 수정이나 우회 방법이 필요합니다.
• 디버깅 어려움: Distroless 컨테이너는 최소화되어 효율적이지만, 디버깅 도구가 거의 없어 문제 식별과 해결이 더 복잡하고 시간이 많이 걸릴 수 있습니다.
• 빌드 복잡성 증가: 멀티 스테이지 빌드를 관리하면서 Dockerfile이 복잡해졌습니다. 특정 팀원들에게는 빌드 단계를 이해하고 올바른 레이어를 포함·제외하는 것이 어려움으로 다가왔습니다.
• 팀 도입: 팀 전체가 최적화 모범 사례를 도입하도록 장려하는 데 시간과 교육이 필요했습니다. 모든 팀원이 처음부터 익숙하지 않았기 때문에, 훈련과 지속적인 학습을 통해 합의를 이끌어내야 했습니다.

핵심 교훈은 최적화가 모두에게 똑같이 적용되는 해법이 아니라는 것입니다. 크기, 기능, 보안 간의 적절한 균형은 애플리케이션의 특성에 따라 달라집니다.

---

추가 최적화 기법

저에게 효과적이었던 다른 기법도 있습니다:

1. 레이어 최적화

Docker 이미지는 여러 개의 레이어로 구성되며, Dockerfile의 각 명령어가 새로운 레이어를 만듭니다. 관련된 명령을 결합하면 레이어 수를 줄일 수 있고, 이미지 크기를 크게 줄일 수 있습니다.

잘못된 접근 방식:

RUN apt-get update
RUN apt-get install -y package1
RUN apt-get install -y package2

올바른 접근 방식:

RUN apt-get update && \
    apt-get install -y package1 package2 && \
    rm -rf /var/lib/apt/lists/*

2. BuildKit Cache Mounts 활용

Node.js 애플리케이션에서는 npm 캐싱을 활용하면 빌드 속도를 크게 높일 수 있습니다:

# syntax=docker/dockerfile:1.4
FROM node:alpine

WORKDIR /app

COPY package*.json ./
RUN --mount=type=cache,target=/root/.npm \
    npm ci --only=production

COPY . .

EXPOSE 3000
CMD ["node", "index.js"]

3. 대체 도구 고려하기

수동 최적화와 Slim 같은 자동화 외에도, 컨테이너 이미지를 점검·분석·추가 최적화하는 데 도움을 줄 수 있는 강력한 도구들이 있습니다:

• dive: Docker 이미지 레이어를 시각적으로 탐색할 수 있는 CLI 도구입니다. 이미지 크기에 어떤 요소가 기여하고 있는지, 불필요한 파일이나 비효율적인 레이어 구성으로 인한 비대화를 식별할 수 있습니다.
• Docker Scout: Docker의 공식 이미지 분석 및 보안 도구입니다. 이미지 메타데이터와 SBOM(Software Bill of Materials)을 기반으로 취약점, 오래된 의존성, 크기 최적화 기회를 알려줍니다.
• Buildpacks: CNCF 프로젝트로, Dockerfile 없이 소스 코드에서 바로 컨테이너 이미지를 빌드할 수 있습니다. 베스트 프랙티스를 강제하며, 애플리케이션 런타임에 맞춘 최소화된 프로덕션 준비 이미지를 생성합니다.

이러한 도구들은 기본적인 Dockerfile 최적화를 넘어, 컨테이너 내부를 깊이 이해하고 효율성을 극대화하는 데 좋은 조력자가 됩니다.

---

마무리 생각

1.22GB에서 57MB로 줄여온 과정은 단순히 디스크 공간 절약을 넘어, 효율성·보안·엔지니어링 품질에 대한 철학을 보여줍니다.

이러한 기법들을 도입하면 시간이 지날수록 복합적인 이점을 얻게 됩니다. 작은 컨테이너는 곧:

• 더 빠른 배포
• 낮은 인프라 비용
• 강화된 보안 태세
• 향상된 리소스 활용
• 더 빠른 수평 확장

최적화는 이분법적 목표가 아니라 스펙트럼임을 기억해야 합니다. 모든 기법을 다 적용하지 못하더라도, 한 단계씩 적용할 때마다 충분한 효과가 있습니다. 예를 들어 1GB에서 200MB로만 줄여도 큰 성과입니다.

자신의 프로젝트에 맞는 기법부터 시작해, 점차 더 고급 최적화를 익히며 적용해 보세요. 컨테이너 효율성으로 가는 여정은 반복적이지만, 노력한 만큼 보상이 따릅니다.

이 가이드에서 사용한 모든 Dockerfile은 공개 GitHub 저장소에서 확인할 수 있습니다:

https://github.com/prateekjaindev/docker-shrink