Docker 이미지 빌드와 최적화 완벽 가이드

Docker 이미지를 효율적으로 빌드하고 최적화하는 방법을 배웁니다. 빌드 컨텍스트부터 레이어 캐싱, 이미지 크기 최적화까지 실무에서 바로 활용할 수 있는 기법을 다룹니다.

---

목차

1. docker_build_명령어
2. 빌드_컨텍스트_이해
3. dockerignore_활용
4. 레이어_캐싱_최적화
5. 이미지_크기_줄이기
6. Alpine_베이스_이미지

---

1. docker build 명령어

김개발 씨는 처음으로 Docker를 사용해 애플리케이션을 배포하게 되었습니다. Dockerfile은 작성했는데, 이제 이것을 어떻게 이미지로 만들어야 할지 막막합니다.

선배에게 물어보니 "docker build 명령어를 사용하면 돼요"라는 답이 돌아왔습니다.

docker build 명령어는 Dockerfile을 읽어서 Docker 이미지를 생성하는 핵심 명령어입니다. 마치 요리 레시피를 보고 실제 요리를 만들어내는 과정과 같습니다.

이 명령어를 제대로 이해하면 원하는 대로 이미지를 빌드하고 관리할 수 있게 됩니다.

다음 코드를 살펴봅시다.

# 기본 빌드: 현재 디렉토리의 Dockerfile 사용
docker build .

# 이미지에 이름과 태그 지정하기
docker build -t myapp:1.0 .

# 특정 Dockerfile 지정하기
docker build -f Dockerfile.prod -t myapp:prod .

# 빌드 인자 전달하기
docker build --build-arg NODE_ENV=production -t myapp:1.0 .

# 빌드 과정 상세 출력
docker build --progress=plain -t myapp:1.0 .

김개발 씨는 입사 2개월 차 주니어 개발자입니다. 회사에서 처음으로 Docker를 도입하기로 했고, 김개발 씨가 그 임무를 맡게 되었습니다.

열심히 공부해서 Dockerfile은 작성했는데, 이제 이것을 실제 이미지로 만들어야 합니다. 터미널 앞에 앉은 김개발 씨는 잠시 고민합니다.

"Dockerfile은 만들었는데, 이걸 어떻게 이미지로 변환하지?" 선배 개발자 박시니어 씨가 옆을 지나가다 멈춥니다. "docker build 명령어를 써보세요.

Docker의 가장 기본이 되는 명령어예요." docker build가 정확히 무엇일까요? 쉽게 비유하자면, docker build는 마치 3D 프린터와 같습니다.

설계도면인 Dockerfile을 넣으면 실제 사용할 수 있는 제품인 Docker 이미지가 출력됩니다. 설계도면이 아무리 훌륭해도 프린터가 없으면 실제 제품을 만들 수 없듯이, Dockerfile만으로는 컨테이너를 실행할 수 없습니다.

가장 기본적인 사용법은 docker build . 입니다. 여기서 마지막의 점(.)이 중요합니다.

이것은 "현재 디렉토리를 빌드 컨텍스트로 사용하겠다"는 의미입니다. Docker는 이 경로에서 Dockerfile을 찾고, 필요한 파일들을 읽어옵니다.

하지만 이렇게만 빌드하면 이미지에 이름이 없어서 나중에 찾기 어렵습니다. 그래서 -t 옵션을 사용합니다.

-t는 tag의 약자로, 이미지에 이름과 버전을 붙여줍니다. docker build -t myapp:1.0 . 이렇게 실행하면 myapp이라는 이름의 1.0 버전 이미지가 만들어집니다.

실무에서는 여러 개의 Dockerfile을 관리하는 경우가 많습니다. 개발용, 운영용, 테스트용 등 환경별로 다른 설정이 필요하기 때문입니다.

이때 -f 옵션을 사용합니다. docker build -f Dockerfile.prod를 실행하면 Dockerfile.prod라는 이름의 파일을 사용해서 빌드합니다.

--build-arg 옵션도 자주 사용됩니다. Dockerfile 안에서 ARG로 정의한 변수에 값을 전달할 때 씁니다.

예를 들어 NODE_ENV 같은 환경 변수를 빌드 시점에 주입할 수 있습니다. 빌드 과정이 어떻게 진행되는지 자세히 보고 싶다면 --progress=plain 옵션을 추가하세요.

각 단계에서 무슨 일이 일어나는지 상세하게 출력됩니다. 문제가 생겼을 때 디버깅하기 좋습니다.

김개발 씨가 docker build -t myapp:1.0 .을 실행하자 터미널에 여러 줄의 출력이 나타났습니다. Step 1/5, Step 2/5...

차례대로 Dockerfile의 명령어들이 실행되는 것이 보입니다. 마지막에 Successfully tagged myapp:1.0이라는 메시지가 나타나면 빌드 완료입니다.

"오, 생각보다 간단하네요!" 김개발 씨가 감탄합니다. 박시니어 씨가 웃으며 말합니다.

"기본은 간단하죠. 하지만 효율적인 빌드를 위해서는 알아야 할 것들이 더 있어요."

실전 팁

💡 - 이미지 이름은 소문자와 숫자, 하이픈, 언더스코어만 사용 가능합니다

• 태그를 생략하면 자동으로 latest가 붙지만, 버전 관리를 위해 명시적으로 태그를 지정하는 것이 좋습니다

---

2. 빌드 컨텍스트 이해

김개발 씨가 docker build를 실행했는데 이상하게 오래 걸립니다. 몇 분이 지나도 끝나지 않습니다.

프로젝트 폴더에 큰 파일이 없는데 왜 이렇게 느린 걸까요? 박시니어 씨가 화면을 보더니 "아, 빌드 컨텍스트가 너무 크네요"라고 말합니다.

빌드 컨텍스트는 docker build 명령어를 실행할 때 Docker 데몬에게 전송되는 파일들의 집합입니다. 마치 이사할 때 이삿짐 트럭에 실을 짐을 정하는 것과 같습니다.

필요 없는 짐까지 실으면 이사가 느려지듯이, 불필요한 파일이 빌드 컨텍스트에 포함되면 빌드가 느려집니다.

다음 코드를 살펴봅시다.

# 빌드 컨텍스트 크기 확인하기
docker build . 2>&1 | grep "Sending build context"
# 출력 예: Sending build context to Docker daemon  125.4MB

# 현재 디렉토리 크기 확인
du -sh .

# 서브디렉토리별 크기 확인
du -sh */ | sort -hr | head -10

# 빌드 컨텍스트로 특정 디렉토리 지정
docker build -t myapp:1.0 ./src

# 빌드 컨텍스트와 Dockerfile 위치 분리
docker build -f docker/Dockerfile -t myapp:1.0 .

김개발 씨가 docker build를 실행하자 터미널에 이상한 메시지가 나타났습니다. "Sending build context to Docker daemon 2.5GB" 2.5기가바이트라니, 프로젝트 코드는 몇 메가바이트밖에 안 되는데 왜 이렇게 큰 걸까요?

박시니어 씨가 설명을 시작합니다. "Docker는 클라이언트-서버 구조로 되어 있어요.

우리가 터미널에서 명령어를 치면 Docker 클라이언트가 Docker 데몬에게 작업을 요청하는 거예요." 여기서 핵심이 빌드 컨텍스트입니다. docker build 명령어를 실행하면 Docker 클라이언트는 지정된 경로의 모든 파일을 압축해서 Docker 데몬에게 전송합니다.

이 파일 묶음이 바로 빌드 컨텍스트입니다. 마치 택배를 보낼 때 상자에 물건을 담는 것처럼, 빌드에 필요한 모든 것을 하나로 묶어서 보내는 것입니다.

문제는 Docker가 "필요한 파일"과 "불필요한 파일"을 구분하지 않는다는 점입니다. docker build .을 실행하면 현재 디렉토리의 모든 파일이 전송됩니다.

node_modules 폴더, 로그 파일, 테스트 데이터, 심지어 .git 폴더까지 전부 포함됩니다. 김개발 씨의 프로젝트를 살펴보니 원인이 보였습니다.

node_modules 폴더가 800MB, .git 폴더가 500MB, 테스트용 더미 데이터가 1GB. 정작 빌드에 필요한 소스 코드는 10MB도 안 되는데, 나머지 2.4GB는 전혀 필요 없는 파일들이었습니다.

빌드 컨텍스트를 확인하는 방법은 간단합니다. docker build 명령어를 실행하면 맨 처음에 "Sending build context to Docker daemon"이라는 메시지가 나옵니다.

여기에 표시되는 크기가 바로 빌드 컨텍스트의 크기입니다. 어떤 폴더가 용량을 많이 차지하는지 확인하려면 du 명령어를 사용합니다.

du -sh */를 실행하면 각 하위 폴더의 크기를 볼 수 있습니다. 여기서 불필요하게 큰 폴더들을 찾아낼 수 있습니다.

빌드 컨텍스트를 줄이는 방법은 크게 두 가지입니다. 첫째, 빌드에 꼭 필요한 파일만 있는 별도의 디렉토리를 지정하는 것입니다.

docker build ./src처럼 특정 폴더만 컨텍스트로 지정할 수 있습니다. 둘째, .dockerignore 파일을 사용하는 것입니다.

이 방법이 더 일반적이고 효과적입니다. 다음 카드에서 자세히 알아보겠습니다.

박시니어 씨가 덧붙입니다. "빌드 컨텍스트가 크면 네트워크 전송 시간도 오래 걸리고, 디스크 공간도 낭비돼요.

특히 CI/CD 파이프라인에서는 매번 빌드할 때마다 이 비용이 발생하니까 최적화가 중요해요." 김개발 씨가 고개를 끄덕입니다. "그래서 빌드가 그렇게 오래 걸렸군요.

정작 빌드 자체는 금방인데 파일 전송에서 시간을 다 잡아먹은 거네요."

실전 팁

💡 - 빌드 컨텍스트는 가능한 한 작게 유지하세요. 100MB 이하가 이상적입니다

• Dockerfile과 필요한 파일만 있는 별도 디렉토리를 만들어 사용하는 것도 좋은 방법입니다

---

3. dockerignore 활용

김개발 씨가 빌드 컨텍스트 문제를 해결하려고 합니다. 하지만 프로젝트 구조를 바꾸기는 어렵습니다.

다른 방법이 없을까요? 박시니어 씨가 .dockerignore 파일에 대해 알려줍니다.

".gitignore 써본 적 있죠? 비슷한 거예요."

.dockerignore 파일은 빌드 컨텍스트에서 제외할 파일과 폴더를 지정합니다. .gitignore가 Git에서 추적하지 않을 파일을 정하는 것처럼, .dockerignore는 Docker 빌드에서 무시할 파일을 정합니다.

이 파일 하나로 빌드 시간을 획기적으로 줄일 수 있습니다.

다음 코드를 살펴봅시다.

# .dockerignore 파일 예시

# 의존성 폴더 제외
node_modules
vendor
.venv

# 버전 관리 제외
.git
.gitignore
.svn

# IDE 설정 제외
.idea
.vscode
*.swp

# 빌드 결과물 제외
dist
build
*.log

# 테스트 관련 제외
test
tests
coverage
__tests__

# Docker 관련 제외
Dockerfile*
docker-compose*
.dockerignore

.gitignore를 사용해본 개발자라면 .dockerignore도 금방 익숙해질 것입니다. 문법이 거의 동일하기 때문입니다.

프로젝트 루트에 .dockerignore라는 이름의 파일을 만들고, 제외할 패턴을 한 줄에 하나씩 적으면 됩니다. 김개발 씨가 .dockerignore 파일을 만들기 시작합니다.

가장 먼저 적을 것은 역시 node_modules입니다. Node.js 프로젝트에서 이 폴더는 수백 메가바이트에 달하는 경우가 많습니다.

어차피 Docker 이미지 안에서 npm install을 다시 실행하므로 빌드 컨텍스트에 포함시킬 필요가 없습니다. 다음은 .git 폴더입니다.

Git 히스토리가 쌓이면 이 폴더도 상당히 커집니다. Docker 이미지에 버전 관리 정보가 필요한 경우는 거의 없으므로 제외합니다.

IDE 설정 파일들도 제외 대상입니다. .idea, .vscode 같은 폴더는 개발자 개인의 에디터 설정을 담고 있습니다.

이런 파일이 이미지에 들어갈 필요는 없습니다. 와일드카드 패턴도 사용할 수 있습니다.

.log는 모든 로그 파일을 제외합니다. **/.test.js는 모든 하위 폴더의 테스트 파일을 제외합니다.

이런 패턴을 활용하면 일일이 파일명을 적지 않아도 됩니다. 재미있는 점은 Dockerfile 자체도 제외할 수 있다는 것입니다.

Dockerfile은 Docker 클라이언트가 직접 읽어서 데몬에게 명령을 전달하므로, 빌드 컨텍스트에 포함될 필요가 없습니다. 물론 COPY 명령어로 Dockerfile을 이미지에 복사하고 싶다면 제외하면 안 됩니다.

예외 규칙도 지정할 수 있습니다. 느낌표(!)로 시작하는 패턴은 "이건 제외하지 마세요"라는 의미입니다.

예를 들어 *.md를 적어서 모든 마크다운 파일을 제외한 뒤, !README.md를 적으면 README.md만 포함시킬 수 있습니다. 김개발 씨가 .dockerignore를 작성하고 다시 빌드를 실행합니다.

"Sending build context to Docker daemon 15.2MB" 2.5GB에서 15MB로 줄었습니다. 빌드 시작까지 걸리던 시간이 몇 분에서 몇 초로 단축되었습니다.

박시니어 씨가 조언합니다. "새 프로젝트를 시작할 때 .gitignore와 함께 .dockerignore도 같이 만들어두세요.

나중에 따로 만들려면 뭘 제외해야 할지 하나하나 확인해야 해서 번거로워요." 한 가지 주의할 점이 있습니다. .dockerignore에 너무 많은 것을 제외하면 정작 필요한 파일이 빠질 수 있습니다.

빌드가 실패하면 제외 목록을 다시 확인해보세요. 특히 설정 파일이나 환경 변수 파일이 빠지는 경우가 종종 있습니다.

실전 팁

💡 - .dockerignore는 Dockerfile과 같은 디렉토리에 위치해야 합니다

• 정규표현식이 아닌 glob 패턴을 사용합니다. **는 모든 하위 디렉토리를 의미합니다

---

4. 레이어 캐싱 최적화

김개발 씨가 코드를 한 줄 수정하고 다시 빌드했습니다. 그런데 npm install부터 다시 실행됩니다.

패키지는 하나도 안 바꿨는데 왜 처음부터 다시 설치하는 걸까요? 박시니어 씨가 말합니다.

"Dockerfile의 순서를 바꿔봐요. 레이어 캐싱을 활용해야 해요."

Docker는 이미지를 레이어 단위로 관리합니다. Dockerfile의 각 명령어가 하나의 레이어를 만들고, 이전에 빌드한 레이어는 캐시에 저장됩니다.

변경이 없는 레이어는 캐시를 재사용하므로 빌드가 빨라집니다. 하지만 하나의 레이어가 변경되면 그 이후의 모든 레이어가 다시 빌드됩니다.

다음 코드를 살펴봅시다.

# 비효율적인 Dockerfile (캐시를 활용하지 못함)
FROM node:18
WORKDIR /app
COPY . .
RUN npm install
CMD ["node", "server.js"]

# 최적화된 Dockerfile (캐시를 효과적으로 활용)
FROM node:18
WORKDIR /app
# 의존성 파일만 먼저 복사
COPY package.json package-lock.json ./
# 의존성 설치 (package.json이 바뀔 때만 재실행)
RUN npm install
# 소스 코드 복사 (자주 변경됨)
COPY . .
CMD ["node", "server.js"]

Docker 이미지는 마치 양파처럼 여러 겹의 레이어로 구성되어 있습니다. Dockerfile의 FROM, RUN, COPY 같은 명령어가 실행될 때마다 새로운 레이어가 추가됩니다.

이 레이어 시스템이 Docker의 핵심 특징 중 하나입니다. 레이어의 강력한 점은 캐싱입니다.

한 번 빌드한 레이어는 캐시에 저장됩니다. 다음에 같은 명령어를 실행할 때, Docker는 "어, 이건 전에 했던 거네?"라고 인식하고 캐시된 결과를 그대로 사용합니다.

덕분에 빌드 시간이 크게 단축됩니다. 하지만 캐시에는 중요한 규칙이 있습니다.

하나의 레이어가 변경되면 그 이후의 모든 레이어가 무효화됩니다. 마치 도미노처럼, 앞의 것이 쓰러지면 뒤의 것도 다 쓰러지는 것입니다. 김개발 씨의 원래 Dockerfile을 봅시다.

COPY . .이 먼저 오고 그다음에 RUN npm install이 옵니다.

소스 코드를 한 줄이라도 수정하면 COPY . .

레이어가 변경됩니다. 그러면 그 뒤의 npm install도 캐시를 사용하지 못하고 처음부터 다시 실행됩니다.

패키지 의존성은 거의 바뀌지 않습니다. 하지만 소스 코드는 매번 바뀝니다.

그런데 자주 바뀌는 것을 앞에 두고 안 바뀌는 것을 뒤에 두었으니, 매번 npm install이 다시 실행되는 것입니다. 해결책은 순서를 바꾸는 것입니다. package.json과 package-lock.json만 먼저 복사하고, npm install을 실행합니다.

그 다음에 나머지 소스 코드를 복사합니다. 이렇게 하면 어떻게 될까요?

소스 코드를 수정해도 package.json은 변경되지 않습니다. 따라서 npm install 레이어는 캐시를 그대로 사용합니다.

소스 코드 복사만 다시 실행되므로 빌드가 훨씬 빨라집니다. 이 원칙을 기억하세요.

자주 변경되지 않는 것을 먼저, 자주 변경되는 것을 나중에. 시스템 패키지 설치, 의존성 설치 같은 것은 앞에 두고, 소스 코드 복사는 가능한 한 뒤에 둡니다. 박시니어 씨가 추가로 설명합니다.

"멀티스테이지 빌드를 쓰면 더 좋아요. 빌드에 필요한 도구들은 첫 번째 스테이지에만 두고, 최종 이미지에는 실행에 필요한 것만 넣는 거죠.

이건 이미지 크기 줄이기에서 다시 얘기할게요." 김개발 씨가 Dockerfile을 수정하고 다시 빌드합니다. 코드만 수정했을 때의 빌드 시간이 5분에서 30초로 단축되었습니다.

"이거 진작 알았으면 좋았을 텐데요!"

실전 팁

💡 - COPY 명령어를 여러 번 나눠서 사용하면 캐싱 효율이 높아집니다

• --no-cache 옵션을 사용하면 캐시를 무시하고 처음부터 빌드합니다. 문제 해결 시 유용합니다

---

5. 이미지 크기 줄이기

김개발 씨가 빌드한 이미지를 확인해보니 1.2GB입니다. 간단한 Node.js 애플리케이션인데 왜 이렇게 큰 걸까요?

이미지가 크면 저장 공간도 많이 차지하고, 배포할 때 전송 시간도 오래 걸립니다. 어떻게 하면 이미지 크기를 줄일 수 있을까요?

Docker 이미지 크기를 줄이면 저장 공간 절약, 빠른 배포, 보안 향상 등 여러 이점이 있습니다. 멀티스테이지 빌드를 사용하면 빌드 도구 없이 실행 파일만 담은 가벼운 이미지를 만들 수 있습니다.

또한 불필요한 파일을 제거하고, 레이어 수를 줄이는 것도 효과적입니다.

다음 코드를 살펴봅시다.

# 멀티스테이지 빌드 예시
# 1단계: 빌드 스테이지
FROM node:18 AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build

# 2단계: 실행 스테이지
FROM node:18-slim
WORKDIR /app
# 빌드 결과물만 복사
COPY --from=builder /app/dist ./dist
COPY --from=builder /app/node_modules ./node_modules
COPY package*.json ./
# 프로덕션 의존성만 설치
RUN npm prune --production
CMD ["node", "dist/server.js"]

왜 이미지 크기가 중요할까요? 첫째, 저장 공간입니다.

컨테이너 레지스트리에 이미지를 저장할 때 비용이 발생합니다. 이미지가 작을수록 비용이 줄어듭니다.

둘째, 배포 속도입니다. 새 서버에 이미지를 배포할 때 이미지를 다운로드해야 합니다.

1GB 이미지와 100MB 이미지는 다운로드 시간이 10배 차이납니다. 셋째, 보안입니다.

이미지에 포함된 패키지가 많을수록 잠재적인 보안 취약점도 많아집니다. 꼭 필요한 것만 포함시키면 공격 표면이 줄어듭니다.

이미지 크기를 줄이는 가장 효과적인 방법은 멀티스테이지 빌드입니다. 일반적인 빌드 과정을 생각해봅시다.

TypeScript를 JavaScript로 컴파일하고, 번들링하고, 최적화합니다. 이 과정에는 컴파일러, 번들러, 각종 개발 의존성이 필요합니다.

하지만 실제 실행할 때는 이런 도구들이 필요 없습니다. 컴파일된 결과물만 있으면 됩니다.

멀티스테이지 빌드는 이 문제를 해결합니다. 첫 번째 스테이지에서 모든 빌드 도구를 사용해서 애플리케이션을 빌드합니다.

두 번째 스테이지에서는 빌드 결과물만 복사해옵니다. 최종 이미지에는 빌드 도구가 포함되지 않으므로 크기가 훨씬 작아집니다.

위 코드를 자세히 봅시다. FROM node:18 AS builder로 첫 번째 스테이지를 시작합니다.

AS builder는 이 스테이지에 이름을 붙이는 것입니다. 여기서 npm install과 npm run build를 실행합니다.

두 번째 스테이지는 FROM node:18-slim으로 시작합니다. slim 이미지는 일반 이미지보다 훨씬 작습니다.

불필요한 패키지들이 제거되어 있기 때문입니다. COPY --from=builder가 핵심입니다.

첫 번째 스테이지에서 빌드한 결과물을 두 번째 스테이지로 복사합니다. 빌드 도구들은 복사하지 않고 결과물만 가져옵니다.

npm prune --production도 중요합니다. 개발 의존성(devDependencies)을 제거하고 프로덕션 의존성만 남깁니다.

테스트 프레임워크, 린터 같은 것들이 제거됩니다. 김개발 씨가 멀티스테이지 빌드를 적용했습니다.

이미지 크기가 1.2GB에서 250MB로 줄었습니다. 거의 5분의 1로 줄어든 것입니다.

추가로 할 수 있는 최적화도 있습니다. RUN 명령어를 하나로 합치면 레이어 수가 줄어들어 이미지가 약간 더 작아집니다.

예를 들어 **RUN apt-get update && apt-get install -y package && rm -rf /var/lib/apt/lists/***처럼 설치와 정리를 한 줄에서 처리합니다. 박시니어 씨가 마무리합니다.

"멀티스테이지 빌드는 현대 Docker 사용의 필수 테크닉이에요. 처음에는 복잡해 보이지만, 한 번 익숙해지면 항상 이 방식으로 작성하게 될 거예요."

실전 팁

💡 - docker images 명령어로 이미지 크기를 확인할 수 있습니다

• dive라는 도구를 사용하면 각 레이어의 내용과 크기를 시각적으로 분석할 수 있습니다

---

6. Alpine 베이스 이미지

박시니어 씨가 김개발 씨의 Dockerfile을 보더니 말합니다. "node:18-slim 대신 node:18-alpine을 쓰면 이미지가 더 작아질 수 있어요." Alpine이라니, 처음 듣는 이름입니다.

그게 뭐길래 이미지 크기가 더 줄어드는 걸까요?

Alpine Linux는 보안과 경량화에 초점을 맞춘 리눅스 배포판입니다. 일반적인 리눅스 배포판이 수백 MB인 반면, Alpine은 약 5MB에 불과합니다.

Alpine 기반의 Docker 이미지를 사용하면 이미지 크기를 극적으로 줄일 수 있습니다. 다만 일부 호환성 문제가 있을 수 있어 주의가 필요합니다.

다음 코드를 살펴봅시다.

# 일반 Node.js 이미지 (약 900MB)
FROM node:18

# Slim 이미지 (약 200MB)
FROM node:18-slim

# Alpine 이미지 (약 110MB)
FROM node:18-alpine

# Alpine에서 추가 패키지 설치가 필요한 경우
FROM node:18-alpine
# Alpine은 apk 패키지 매니저 사용
RUN apk add --no-cache \
    python3 \
    make \
    g++ \
    && rm -rf /var/cache/apk/*

# 최소 이미지로 Go 바이너리 실행 (약 7MB)
FROM golang:1.21-alpine AS builder
WORKDIR /app
COPY . .
RUN CGO_ENABLED=0 go build -o main .

FROM scratch
COPY --from=builder /app/main /main
CMD ["/main"]

Docker 이미지의 크기는 베이스 이미지에서 시작됩니다. 아무리 최적화를 해도 베이스 이미지 자체가 크면 한계가 있습니다.

그래서 베이스 이미지 선택이 중요합니다. Alpine Linux는 2010년에 시작된 프로젝트입니다.

원래는 라우터 같은 임베디드 시스템을 위해 만들어졌습니다. 극도로 가벼워야 했기 때문에 모든 것을 최소화했습니다.

일반적인 Ubuntu나 Debian 이미지는 100MB에서 수백 MB입니다. 반면 Alpine 이미지는 약 5MB입니다.

어떻게 이렇게 작을 수 있을까요? 비결은 musl libc와 BusyBox입니다.

대부분의 리눅스는 glibc라는 C 라이브러리를 사용합니다. Alpine은 더 가벼운 musl을 사용합니다.

또한 수백 개의 유닉스 유틸리티를 하나의 실행 파일로 합친 BusyBox를 사용합니다. Node.js를 예로 들면, node:18 이미지는 약 900MB입니다.

node:18-slim은 약 200MB입니다. node:18-alpine은 약 110MB입니다.

Alpine을 사용하면 8배 이상 작아집니다. 패키지 관리도 다릅니다.

Debian 계열은 apt를 사용하지만, Alpine은 apk를 사용합니다. 문법은 비슷하지만 명령어가 다릅니다.

apk add로 패키지를 설치하고, apk del로 제거합니다. --no-cache 옵션을 사용하면 캐시 파일을 남기지 않아 이미지 크기를 더 줄일 수 있습니다.

하지만 Alpine에는 주의할 점이 있습니다. musl과 glibc는 완전히 호환되지 않습니다.

특히 네이티브 바이너리를 사용하는 패키지에서 문제가 생길 수 있습니다. 예를 들어 Node.js의 bcrypt, sharp 같은 패키지들은 Alpine에서 설치가 까다롭습니다.

Python 패키지 중에도 C 확장을 사용하는 것들이 있습니다. 이런 패키지들은 Alpine에서 직접 컴파일해야 하는 경우가 많습니다.

컴파일에 필요한 도구들(python3, make, g++)을 설치해야 해서 오히려 이미지가 커질 수 있습니다. 그래서 상황에 따라 선택해야 합니다.

순수 JavaScript나 TypeScript만 사용하는 Node.js 앱이라면 Alpine이 좋은 선택입니다. 하지만 네이티브 의존성이 많다면 slim 이미지가 더 나을 수 있습니다.

극한의 경량화를 원한다면 scratch 이미지도 있습니다. scratch는 완전히 빈 이미지입니다.

아무것도 없습니다. 셸도 없고, 패키지 매니저도 없습니다.

Go 같은 언어로 만든 정적 링크 바이너리를 실행할 때 사용합니다. 위 코드의 마지막 예시처럼, Go 바이너리만 복사하면 7MB짜리 초경량 이미지가 만들어집니다.

김개발 씨가 물어봅니다. "그러면 무조건 Alpine을 쓰는 게 좋은 건가요?" 박시니어 씨가 대답합니다.

"꼭 그렇지는 않아요. 처음에는 호환성이 좋은 slim 이미지로 시작하고, 문제가 없으면 Alpine으로 바꿔보세요.

문제가 생기면 언제든 돌아갈 수 있으니까요. 무조건 작은 게 좋은 건 아니에요.

안정성과 크기 사이에서 적절한 균형을 찾는 게 중요해요."

실전 팁

💡 - Alpine 이미지에서 문제가 생기면 먼저 slim 이미지로 돌아가서 테스트해보세요

• 디버깅을 위해 셸이 필요하다면 scratch 대신 Alpine을 사용하세요

---

이상으로 학습을 마칩니다. 위 내용을 직접 코드로 작성해보면서 익혀보세요!