[DeepDive🤿] Docker Image 얼마나 커야 ‘크다’고 말할까? - 최적화 전략

DeepDive 주제

💡 도커 이미지가 커지면 발생할 수 있는 문제를 설명하고, 이미지 최적화 전략을 서술하시오.

주제를 보고 든 생각

• 크다는게 얼마나 커지면일까?
• 처음에 빌드할때만 관련 문제 발생하고, 이후에는 이미 빌드된 이미지 쓴다고 하면 괜찮은거 아닌가?

🤔 도커 이미지가 “크다”는 무엇일까?

도커관련하여 서칭을 해보면, “이미지 크기가 너무 크다.. 최적화해야겠다”라는 글을 자주 접했었다. 나 역시 이번 프로젝트에서 BE, FE 이미지를 직접 빌드하면서

“이미지가 큰 게 문제일까?” “얼마부터 크다고 보는 거지?”

라는 생각을 많이 했다.

그런데 도커 이미지가 크다는 표현은 상대적인 개념이고, 이걸 최근에 더 확실하게 느꼈던건 아래의 포럼글을 발견하고 나서 부터다 :

👉 https://forums.docker.com/t/is-the-size-of-docker-image-impact-the-time-of-create-new-container/74271

여기서 나온 답변 중 일부를 보면, 아래와 같다.

“The word ‘large’ of course is a relative term, as are ‘fast’ and ‘slow’ when considering performance.

You may be falling into the trap of early optimisation before you really know whether you are actually focusing on the right thing or even if you actually have a performance issue … which you very well may not."

요약하자면, 이미지가 크다고 해서 무조건 문제가 되는 게 아니라
환경, 네트워크 속도, 레지스트리 위치, 레이어 캐시 여부에 따라 다르게 체감된다는 이야기다.

🧐 이미지 크기가 문제인지 아닌지, 어떻게 판단할까?

포럼에서도 강조했듯이, 이미지 크기가 컨테이너 생성 속도에 어느 정도 영향은 있지만

가장 큰 영향을 주는 건 최초 Pull 시간이다.

즉, 이미지가 아무리 커도

• 이미 노드에 캐시되어 있다면 빠르게 올라갈 수 있고
• 반대로 아주 작은 이미지라도 네트워크가 느리면 오래 걸리기도 한다.

그러니 처음부터 “이미지가 크니까 무조건 최적화 해야 한다!”라기보다 실제로 병목이 어디 있는지 파악해서 확인하는 게 우선이라고 생각하게 됐다.

하지만 이 말이 처음부터 아무것도 신경 쓰지 말라는 뜻이 아니라, 처음부터 적용해두면 좋은 기본 원칙들은 지키되, 심화된 최적화는 문제를 계측한 뒤 필요할 때 한다라는 뜻으로 이해하면 좋을 것 같다.

병목이 어디인지 확인도 하기 전에 최적화를 시작하면 오히려 엉뚱한 부분에 시간을 쓰게 될 것 같다.

Docker Image 커지면 발생할 수 있는 문제

그럼 궁금증을 해소했으니, 본론으로 들어가서 Image가 커지면 발생할 수 있는 문제들을 생각해보면 아래와 같다.
이외에도 문제가 많겠지만, 대표적으로 몇개만 작성해봤다.

문제	설명
배포/다운로드 시간 증가	큰 이미지일수록 레지스트리에서 풀(Pull)하거나 노드에 배포할 때 시간이 더 걸리며, 특히 네트워크가 느리거나 CI/CD 환경에서 병목이 됨.
스토리지 및 캐시 비용 증가	이미지 크기가 크면 레지스트리 저장 공간, 캐시된 이미지 레이어, 호스트 노드의 디스크 사용량 등이 증가
보안 리스크 및 공격 표면 확대	컨테이너에 더 많은 구성 요소를 포함할수록 시스템이 더 많이 노출되고 유지 관리가 더 어려워짐. 또한 불필요한 레이어가 많으면 과거 삭제된 파일이라도 레이어 히스토리에 남아 있을 수 있음
시작·스케일링 지연	큰 이미지일 경우 컨테이너 시작 시간이 작은 이미지에 비해 느릴 수 있고, 특히 오토스케일링이나 노드 신규 프로비저닝 시 지연이 생길 수 있음

Docker Image 최적화

1️⃣ base image 최소화

• Alpine 등의 가벼운 Base 이미지를 사용하여 불필요한 패키지들을 사전에 제거
• Docker 공식문서에서는 “가장 작은 base image부터 시작하라” 고 강조하고 있음
• JAVA기반으로 설명을 더 해보자면
  • openjdk 기반의 alpine 이미지 사용하기
  • 자바 런타임용 컨테이너를 만들때, JDK보다는 JRE 사용하기

2️⃣ multi-stage builds

• 여러 단계로 이미지를 빌드하는 방법
• 빌드 단계와 실행 단계를 분리하여 최종 런타임 이미지에서 불필요한 파일을 제거하는 최적화 방식
• 빌드 도구, 디버그 심볼, 컴파일러 등의 개발 도구가 포함되지 않으므로 민감 정보 유출 등의 위험성 감소
• 런타임 단계에는 JAR 파일만 Copy → 이미지가 매우 작아짐

3️⃣ 불필요한 파일 제외 (.dockerignore 활용)

• 빌드와 관련없는 파일들의 목록을 명시한 .dockerignore를 사용
• 이를 통해 불필요한 파일들을 이미지에서 제외시켜 이미지 크기를 줄일 수 있음
• .gitignore과 비슷하게 동작함

4️⃣ Layer 수 최소화

• Docker Image는 여러 레이어로 이루어져있음
• 레이어가 많으면 build 시간이 증가 + 캐시 복잡도 증가 + 이미지 크기도 증가

# BAD
FROM node:16
WORKDIR /app
COPY package.json ./
COPY package-lock.json ./
...

#Good
FROM node:16
WORKDIR /app
COPY package*.json ./
...

5️⃣ Docker build cache 사용

• 캐시는 Dockerfile의 각 레이어가 변경되었는지 여부에 따라 재사용 여부가 결정됨
• 어떤 레이어가 변경되면(예: COPY로 복사된 소스파일이 바뀜) 그 레이어 이후의 모든 레이어는 캐시가 무효화돼서 다시 빌드됨 → 변경 빈도가 낮은 명령을 위쪽에 배치하라는 이유!
• 캐시 재사용률이 높을수록 빌드 속도가 빨라지고 효율이 높아짐
• 캐시 활용을 위해서는 Dockerfile 구조, COPY 순서, 변경 빈도 분리 등이 중요함
  

✏️ 커뮤니티 도커 배포에서 내가 적용한 Dockerfile 구성 방식

Dockerfile 전체 코드는 이전 포스팅에 정리해두었다.

🔗 이전 포스팅 — Docker Compose 기반 서버 배포 기록

프론트엔드 Dockerfile에서는

node:24-alpine을 선택해 OS 레벨 패키지를 최소화했고
package.json을 먼저 COPY해 npm install 캐시를 활용할 수 있도록 구성했으며
production 모드를 명시해 런타임 환경을 가볍게 유지했다.

백엔드 Dockerfile에서는

빌드를 위한 gradle:8.5-jdk21과
실행을 위한 eclipse-temurin:21-jre를 분리해
멀티스테이지 빌드를 구성했고
Gradle 설정 파일을 먼저 COPY해 dependency 레이어의 캐시가 잘 유지되도록 설계했다.

즉, 나는 이번에 “문제를 해결하기 위해 최적화한 것”이 아니라 초기 설계 단계에서부터 공식문서의 최적화 원칙을 자연스럽게 적용해서 처음부터 가벼운 이미지를 만드는 방향으로 설계했다.

📌 마무리

Docker image 최적화 방법은 공식문서에 더 다양한 기법이 있지만, 이번 글에서는 대표적이고 실전에서 많이 쓰이는 원칙들만 정리해보았다.

도커 이미지 최적화는 ‘처음부터 과하게 하는 것’이 아니라, 기본적인 Best Practice는 초기에 적용해두고, 실제로 병목이나 성능 문제가 드러났을 때 필요한 영역을 추가로 최적화하는 방식이 가장 효율적이라고 느꼈다.

멀티스테이지 빌드, 최소 베이스 이미지 선택, 캐시 전략 같은 요소들은 처음부터 적용해두면 좋은 ‘기본 설계’같은 느낌이고, 이후 서비스가 확장되면서 빌드·배포 속도나 보안 문제가 발생할 때 측정을 기반으로 필요한 부분을 다시 다듬으면 좋을 것 같다.

📝 회고

이번에 도커 기반으로 FE/BE를 직접 빌드하고 배포해보면서,
이미지 최적화 딥다이브에서 정리했던 내용들이 실제 작업에 자연스럽게 연결되었다.
이미지 크기가 “크다/작다”라는 상대적인 개념이나,
최적화는 무조건 처음부터 하는 게 아니라 기본 원칙을 적용해두고
문제가 보일 때 병목을 찾아서 개선하는 것이라는 관점이 실제 Dockerfile 작성 과정에서 계속 떠올랐다.

“이론 → 실전 적용” 흐름을 바로 경험할 수 있었고,
이미지 최적화라는 주제가 단순히 크기를 줄이는 작업이 아니라
배포 속도, 스케일링 대응, 보안 안정성까지 연결되는 중요한 설계 요소라는 걸 확실히 느꼈다.
이번 과제 덕분에 앞으로 Dockerfile을 작성할 때 더 구조적으로, 더 근거 있게 접근할 수 있을 것 같다.

[참고자료]

• https://docs.docker.com/build/building/best-practices
• https://www.sysdig.com/learn-cloud-native/dockerfile-best-practices
• https://semaphore.io/blog/reduce-docker-image-size
• https://velog.io/@alstjr971/%EB%8F%84%EC%BB%A4-%EC%9D%B4%EB%AF%B8%EC%A7%80-%EC%B5%9C%EC%A0%81%ED%99%94-%EB%A9%80%ED%8B%B0-%EC%8A%A4%ED%85%8C%EC%9D%B4%EC%A7%80-%EB%B9%8C%EB%93%9C