Docker로 ML 컨테이너화 완벽 가이드

머신러닝 모델을 Docker로 컨테이너화하는 방법을 배웁니다. Dockerfile 작성부터 GPU 지원, 이미지 최적화, Docker Compose 구성까지 실무에 필요한 핵심 기술을 다룹니다.

---

목차

1. ML용 Dockerfile 작성
2. 의존성 관리 전략
3. GPU 지원 컨테이너
4. 이미지 크기 최적화
5. 멀티스테이지 빌드
6. Docker Compose로 구성

---

1. ML용 Dockerfile 작성

김개발 씨는 열심히 만든 머신러닝 모델을 팀원들에게 공유하려고 했습니다. 그런데 "제 컴퓨터에서는 잘 되는데요"라는 말만 반복하게 되었습니다.

Python 버전도 다르고, 라이브러리 버전도 맞지 않아 모델이 제대로 돌아가지 않았던 것입니다.

Dockerfile은 컨테이너 이미지를 만들기 위한 설계도입니다. 마치 요리 레시피처럼 어떤 재료가 필요하고, 어떤 순서로 준비해야 하는지 적어둔 문서입니다.

ML 프로젝트에서는 Python 환경, 라이브러리, 모델 파일까지 모두 포함하여 어디서든 동일하게 실행할 수 있게 만듭니다.

다음 코드를 살펴봅시다.

# Python 3.9 기반 이미지 사용
FROM python:3.9-slim

# 작업 디렉토리 설정
WORKDIR /app

# 시스템 의존성 설치
RUN apt-get update && apt-get install -y \
    build-essential \
    && rm -rf /var/lib/apt/lists/*

# 의존성 파일 복사 및 설치
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

# 애플리케이션 코드 복사
COPY . .

# 모델 서빙 포트 노출
EXPOSE 8000

# 실행 명령어
CMD ["python", "serve_model.py"]

김개발 씨는 입사 6개월 차 ML 엔지니어입니다. 몇 주간 고생해서 만든 추천 모델이 드디어 완성되었습니다.

로컬 환경에서 테스트해보니 정확도도 좋고, 응답 속도도 빠릅니다. 이제 팀원들에게 공유할 차례입니다.

그런데 문제가 생겼습니다. 동료 이주니어 씨가 모델을 실행하려고 하자 에러가 터졌습니다.

"ModuleNotFoundError: No module named 'sklearn'"이라는 메시지가 떴습니다. 분명히 requirements.txt도 같이 보냈는데 말입니다.

선배 박시니어 씨가 다가와 상황을 살펴봅니다. "김개발 씨, 아직도 이렇게 공유하고 있었어요?

Docker를 써야죠." Dockerfile이란 정확히 무엇일까요? 쉽게 비유하자면, Dockerfile은 마치 이케아 가구 조립 설명서와 같습니다.

설명서대로만 따라하면 누구나 똑같은 가구를 만들 수 있듯이, Dockerfile대로 이미지를 빌드하면 누구나 똑같은 실행 환경을 갖게 됩니다. ML 프로젝트에서 Dockerfile이 특히 중요한 이유가 있습니다.

머신러닝은 의존성이 복잡합니다. TensorFlow, PyTorch, scikit-learn 등 라이브러리들이 서로 버전 충돌을 일으키기 쉽습니다.

심지어 같은 라이브러리라도 버전이 다르면 모델이 전혀 다른 결과를 내놓기도 합니다. 위의 Dockerfile을 한 줄씩 살펴보겠습니다.

먼저 FROM python:3.9-slim은 기반 이미지를 지정합니다. slim 버전을 사용하면 불필요한 요소를 제외하여 이미지 크기를 줄일 수 있습니다.

WORKDIR /app은 컨테이너 내부의 작업 디렉토리를 설정합니다. 이후의 모든 명령어는 이 디렉토리에서 실행됩니다.

마치 터미널에서 cd 명령어로 폴더를 이동한 것과 같습니다. RUN apt-get update 부분은 시스템 레벨의 의존성을 설치합니다.

일부 Python 패키지는 C 라이브러리가 필요하기 때문입니다. 마지막에 캐시를 삭제하여 이미지 크기를 줄이는 것도 중요한 팁입니다.

**COPY requirements.txt .**을 먼저 실행하고 pip install을 하는 이유가 있습니다. Docker는 레이어 단위로 캐싱하기 때문에, 의존성이 변경되지 않았다면 이 부분을 다시 빌드하지 않습니다.

코드만 수정했을 때 빌드 시간을 크게 줄일 수 있습니다. 실제 현업에서는 이 Dockerfile을 기반으로 이미지를 빌드하고, 컨테이너 레지스트리에 푸시합니다.

그러면 팀원 누구나 docker pull 명령어 하나로 동일한 환경을 받아올 수 있습니다. 다시 김개발 씨의 이야기로 돌아가 봅시다.

박시니어 씨의 조언을 듣고 Dockerfile을 작성한 김개발 씨는 이제 더 이상 "제 컴퓨터에서는 되는데요"라는 말을 하지 않게 되었습니다.

실전 팁

💡 - slim 또는 alpine 기반 이미지를 사용하여 이미지 크기를 줄이세요

• requirements.txt를 먼저 복사하고 설치하면 캐싱 효율이 높아집니다

---

2. 의존성 관리 전략

이주니어 씨가 김개발 씨에게 물었습니다. "선배, 저도 Dockerfile 만들었는데 빌드할 때마다 라이브러리 버전이 달라져요.

어제는 됐는데 오늘은 안 되네요." 재현 가능한 환경을 만들려면 의존성 버전을 정확히 고정해야 합니다.

의존성 관리는 프로젝트에 필요한 라이브러리들의 버전을 명확히 기록하고 관리하는 것입니다. 마치 건물 설계도에 어떤 자재를 사용해야 하는지 정확히 적어두는 것과 같습니다.

ML 프로젝트에서는 특히 버전 호환성이 중요하여 더욱 세심한 관리가 필요합니다.

다음 코드를 살펴봅시다.

# requirements.txt - 버전 고정
numpy==1.24.3
pandas==2.0.2
scikit-learn==1.2.2
tensorflow==2.12.0
flask==2.3.2

# requirements-dev.txt - 개발용 의존성
-r requirements.txt
pytest==7.3.1
black==23.3.0
mypy==1.3.0

# pip-tools를 사용한 의존성 컴파일
# pip install pip-tools
# pip-compile requirements.in --output-file=requirements.txt
# pip-sync requirements.txt

이주니어 씨는 어제 빌드한 이미지로 모델을 배포했습니다. 잘 돌아가는 것을 확인하고 퇴근했습니다.

그런데 다음 날 같은 Dockerfile로 다시 빌드했더니 에러가 발생했습니다. 대체 무슨 일이 벌어진 걸까요?

범인은 바로 느슨한 버전 명시였습니다. requirements.txt에 numpy라고만 적어두면 pip은 그때그때 최신 버전을 설치합니다.

어제와 오늘 사이에 numpy가 업데이트되었고, 새 버전이 기존 코드와 호환되지 않았던 것입니다. 버전 고정의 중요성은 아무리 강조해도 지나치지 않습니다.

마치 요리할 때 "소금 약간"이 아니라 "소금 5g"이라고 정확히 적어두는 것과 같습니다. 정확한 양을 알아야 매번 같은 맛을 낼 수 있습니다.

ML 프로젝트에서 버전 호환성은 더욱 민감한 문제입니다. TensorFlow와 NumPy, CUDA 사이에는 복잡한 의존 관계가 있습니다.

한 라이브러리의 버전이 바뀌면 연쇄적으로 문제가 발생할 수 있습니다. pip-tools를 사용하면 의존성 관리가 훨씬 편해집니다.

requirements.in 파일에는 직접적으로 필요한 패키지만 적고, pip-compile 명령어를 실행하면 모든 하위 의존성까지 포함된 requirements.txt가 생성됩니다. 개발용 의존성과 프로덕션 의존성을 분리하는 것도 좋은 습관입니다.

pytest나 black 같은 도구는 개발할 때만 필요합니다. 프로덕션 이미지에는 포함시킬 필요가 없어 이미지 크기를 줄일 수 있습니다.

또 다른 방법으로 Poetry가 있습니다. Poetry는 pyproject.toml 파일 하나로 의존성, 빌드 설정, 프로젝트 메타데이터까지 관리합니다.

요즘 새로운 Python 프로젝트에서 많이 사용되는 추세입니다. 실무에서 주의할 점이 있습니다.

보안 취약점이 발견된 라이브러리는 업데이트해야 합니다. 버전을 고정한다고 해서 영원히 그 버전만 쓰라는 뜻은 아닙니다.

정기적으로 의존성을 검토하고 필요시 업데이트하는 프로세스가 필요합니다. 이주니어 씨는 이제 모든 패키지에 정확한 버전을 명시합니다.

어제 빌드하든 한 달 후에 빌드하든 똑같은 환경이 만들어집니다. 드디어 재현 가능한 ML 환경을 갖추게 된 것입니다.

실전 팁

💡 - pip freeze > requirements.txt로 현재 환경의 모든 버전을 기록하세요

• pip-tools나 Poetry를 사용하면 의존성 충돌을 미리 감지할 수 있습니다

---

3. GPU 지원 컨테이너

김개발 씨가 딥러닝 모델을 학습시키려고 합니다. 로컬에서는 GPU를 잘 사용하는데, Docker 컨테이너 안에서는 GPU를 인식하지 못합니다.

"컨테이너가 GPU를 어떻게 쓰게 하죠?"라고 물었더니, 박시니어 씨가 NVIDIA Container Toolkit에 대해 설명해주었습니다.

GPU 지원 컨테이너는 Docker 컨테이너 내부에서 호스트의 GPU를 사용할 수 있게 해주는 기술입니다. 마치 아파트 주민이 건물의 공용 헬스장을 이용하는 것처럼, 컨테이너도 호스트의 GPU 자원을 빌려 쓸 수 있습니다.

NVIDIA Container Toolkit을 설치하면 이것이 가능해집니다.

다음 코드를 살펴봅시다.

# NVIDIA CUDA 기반 이미지 사용
FROM nvidia/cuda:11.8-cudnn8-runtime-ubuntu22.04

# Python 설치
RUN apt-get update && apt-get install -y \
    python3.10 \
    python3-pip \
    && rm -rf /var/lib/apt/lists/*

WORKDIR /app

# PyTorch GPU 버전 설치
RUN pip install torch==2.0.1+cu118 \
    --extra-index-url https://download.pytorch.org/whl/cu118

COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

COPY . .

# GPU 사용 가능 여부 확인 스크립트
CMD ["python3", "-c", "import torch; print(f'GPU: {torch.cuda.is_available()}')"]

김개발 씨는 이미지 분류 모델을 학습시키고 있습니다. 로컬 환경에서는 RTX 3080 GPU 덕분에 학습이 금방 끝납니다.

하지만 Docker로 옮기자 갑자기 CPU만 사용하게 되었습니다. 학습 시간이 열 배나 늘어났습니다.

GPU는 컨테이너가 자동으로 접근할 수 없는 자원입니다. 컨테이너는 기본적으로 호스트와 격리되어 있기 때문입니다.

마치 호텔 객실에서 건물의 수영장을 이용하려면 별도의 허가가 필요한 것과 같습니다. NVIDIA Container Toolkit이 바로 이 문제를 해결해줍니다.

이 도구는 Docker 컨테이너가 호스트의 NVIDIA GPU에 접근할 수 있게 해주는 다리 역할을 합니다. 호스트에 NVIDIA 드라이버와 Container Toolkit이 설치되어 있어야 합니다.

Dockerfile에서는 nvidia/cuda 기반 이미지를 사용합니다. 이 이미지에는 CUDA 라이브러리와 cuDNN이 미리 설치되어 있습니다.

버전 선택이 중요한데, 사용하려는 딥러닝 프레임워크와 호환되는 CUDA 버전을 골라야 합니다. 이미지 태그의 의미를 알아두면 좋습니다.

runtime은 추론용으로 가볍고, devel은 개발용으로 컴파일 도구가 포함되어 있어 무겁습니다. 용도에 맞게 선택해야 이미지 크기를 관리할 수 있습니다.

PyTorch나 TensorFlow를 설치할 때도 GPU 버전을 명시해야 합니다. PyTorch의 경우 +cu118처럼 CUDA 버전을 붙여 설치합니다.

일반 pip install torch로 설치하면 CPU 버전이 설치될 수 있습니다. 컨테이너를 실행할 때는 반드시 --gpus all 옵션을 붙여야 합니다.

docker run --gpus all my-ml-image 처럼 사용합니다. 이 옵션이 없으면 컨테이너는 GPU를 인식하지 못합니다.

멀티 GPU 환경에서는 특정 GPU만 할당할 수도 있습니다. --gpus '"device=0,1"' 처럼 지정하면 0번과 1번 GPU만 사용합니다.

여러 사용자가 GPU를 나눠 쓸 때 유용합니다. 김개발 씨는 이제 컨테이너에서도 GPU 학습이 가능해졌습니다.

로컬과 동일한 속도로 모델을 학습시킬 수 있게 되었습니다. 환경 재현성과 GPU 가속, 두 마리 토끼를 모두 잡은 것입니다.

실전 팁

💡 - nvidia-smi 명령어로 호스트의 GPU 상태를 먼저 확인하세요

• CUDA 버전과 딥러닝 프레임워크 버전의 호환성 표를 반드시 확인하세요

---

4. 이미지 크기 최적화

이주니어 씨가 만든 ML 이미지가 15GB나 됩니다. 빌드하는 데만 30분, 푸시하는 데 또 30분이 걸립니다.

박시니어 씨가 한숨을 쉬며 말했습니다. "이미지 다이어트 좀 시켜야겠네요.

이대로는 배포할 때마다 시간이 너무 오래 걸려요."

이미지 크기 최적화는 Docker 이미지에서 불필요한 요소를 제거하여 크기를 줄이는 작업입니다. 마치 여행 가방을 쌀 때 꼭 필요한 것만 챙기는 것과 같습니다.

이미지가 작으면 빌드, 푸시, 풀 시간이 단축되고 저장 비용도 절약됩니다.

다음 코드를 살펴봅시다.

# 최적화 전: 무거운 이미지
# FROM python:3.9  # 약 900MB

# 최적화 후: 가벼운 이미지
FROM python:3.9-slim  # 약 120MB

WORKDIR /app

# 한 번의 RUN으로 설치와 정리를 함께 수행
RUN apt-get update && apt-get install -y --no-install-recommends \
    libgomp1 \
    && rm -rf /var/lib/apt/lists/* \
    && apt-get clean

# 캐시 없이 설치하여 용량 절약
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

# 필요한 파일만 복사
COPY src/ ./src/
COPY models/ ./models/

# 불필요한 파일 제거
RUN find . -type d -name __pycache__ -exec rm -rf {} + 2>/dev/null || true

CMD ["python", "src/serve.py"]

이주니어 씨의 ML 이미지가 왜 15GB나 될까요? 범인을 찾아보니 여러 가지가 있었습니다.

기본 Python 이미지가 무겁고, 빌드 도구가 그대로 남아있고, pip 캐시도 쌓여있었습니다. 첫 번째 최적화는 기반 이미지 교체입니다.

python:3.9 대신 python:3.9-slim을 사용하면 이미지 크기가 900MB에서 120MB로 줄어듭니다. slim 버전은 실행에 필요한 최소한의 요소만 포함합니다.

더 극단적으로 alpine 기반을 쓸 수도 있습니다. 하지만 ML 프로젝트에서는 주의가 필요합니다.

alpine은 musl libc를 사용하는데, 일부 Python 패키지가 호환되지 않을 수 있습니다. 특히 NumPy나 Pandas는 문제가 생기기 쉽습니다.

두 번째 최적화는 레이어 합치기입니다. 여러 개의 RUN 명령어를 하나로 합치면 레이어 수가 줄어듭니다.

특히 설치와 정리를 같은 RUN 명령어에서 하면 중간 레이어에 불필요한 파일이 남지 않습니다. --no-install-recommends 옵션도 중요합니다.

apt-get은 기본적으로 권장 패키지까지 설치하는데, 이 옵션을 쓰면 꼭 필요한 패키지만 설치합니다. 수십 MB를 절약할 수 있습니다.

pip install --no-cache-dir 옵션은 pip의 캐시를 저장하지 않습니다. 컨테이너 안에서 다시 pip install 할 일은 없으니 캐시가 필요 없습니다.

패키지에 따라 수백 MB를 아낄 수 있습니다. COPY 명령어를 선택적으로 사용하는 것도 효과적입니다.

COPY . .로 모든 파일을 복사하는 대신, 필요한 디렉토리만 명시적으로 복사합니다.

테스트 코드, 문서, 개발 설정 파일은 프로덕션 이미지에 필요 없습니다. .dockerignore 파일도 만들어두세요.

.git, pycache, *.pyc, .env 같은 파일들이 이미지에 포함되지 않도록 합니다. .gitignore와 비슷한 문법을 사용합니다.

이주니어 씨는 이런 최적화를 적용하여 15GB 이미지를 2GB로 줄였습니다. 빌드 시간은 10분, 푸시 시간은 5분으로 단축되었습니다.

배포 파이프라인이 훨씬 빨라졌습니다.

실전 팁

💡 - docker images 명령어로 이미지 크기를 확인하고, docker history로 어느 레이어가 큰지 분석하세요

• dive 같은 도구를 사용하면 이미지 레이어를 시각적으로 분석할 수 있습니다

---

5. 멀티스테이지 빌드

김개발 씨가 고민에 빠졌습니다. 모델 학습에는 무거운 개발 도구가 필요한데, 배포할 때는 추론만 하면 됩니다.

"학습 환경과 배포 환경을 분리할 수 없을까요?" 박시니어 씨가 멀티스테이지 빌드를 소개해주었습니다.

멀티스테이지 빌드는 하나의 Dockerfile에서 여러 단계를 거쳐 최종 이미지를 만드는 기법입니다. 마치 자동차 공장에서 부품을 만드는 라인과 조립하는 라인이 따로 있는 것과 같습니다.

빌드에 필요한 도구는 중간 단계에만 두고, 최종 이미지에는 실행에 필요한 것만 담습니다.

다음 코드를 살펴봅시다.

# Stage 1: 빌드 및 학습 환경
FROM python:3.9 AS builder

WORKDIR /app
COPY requirements.txt .

# 빌드 도구와 함께 패키지 설치
RUN pip install --user --no-cache-dir -r requirements.txt

# 모델 학습 (선택적)
COPY train/ ./train/
COPY data/ ./data/
RUN python train/train_model.py --output /app/model.pkl

# Stage 2: 실행 환경 (가벼움)
FROM python:3.9-slim AS runtime

WORKDIR /app

# 빌드 스테이지에서 설치된 패키지만 복사
COPY --from=builder /root/.local /root/.local
ENV PATH=/root/.local/bin:$PATH

# 학습된 모델만 복사
COPY --from=builder /app/model.pkl ./model.pkl

# 서빙 코드 복사
COPY serve/ ./serve/

EXPOSE 8000
CMD ["python", "serve/app.py"]

ML 프로젝트에서는 학습과 추론의 요구사항이 다릅니다. 학습할 때는 데이터 처리 도구, 시각화 라이브러리, 디버깅 도구가 필요합니다.

하지만 추론할 때는 모델 파일과 서빙 프레임워크만 있으면 됩니다. 멀티스테이지 빌드는 이 문제를 우아하게 해결합니다.

하나의 Dockerfile에 여러 FROM 문을 사용하여 단계를 나눕니다. 각 단계는 독립적인 환경을 가지며, 필요한 파일만 다음 단계로 복사할 수 있습니다.

위 코드에서 첫 번째 단계는 builder라는 이름을 붙였습니다. AS 키워드로 단계에 이름을 지정합니다.

이 단계에서는 무거운 python:3.9 이미지를 사용하고 모든 의존성을 설치합니다. --user 옵션으로 pip 패키지를 설치하면 /root/.local 디렉토리에 저장됩니다.

이렇게 하면 나중에 이 디렉토리만 복사하여 패키지를 옮길 수 있습니다. 첫 번째 단계에서 모델 학습까지 수행할 수 있습니다.

데이터와 학습 코드를 복사하고, 학습을 실행하여 모델 파일을 생성합니다. CI/CD 파이프라인에서 이미지 빌드와 동시에 모델 학습을 자동화할 때 유용합니다.

두 번째 단계는 runtime입니다. 가벼운 python:3.9-slim 이미지에서 시작합니다.

COPY --from=builder 문법으로 첫 번째 단계에서 필요한 파일만 가져옵니다. 핵심은 빌드 도구, 학습 데이터, 중간 결과물이 최종 이미지에 포함되지 않는다는 것입니다.

오직 학습된 모델 파일과 서빙에 필요한 코드, 라이브러리만 남습니다. 실제로 이 기법을 적용하면 이미지 크기가 극적으로 줄어듭니다.

학습 환경이 5GB였다면, 실행 환경은 500MB 정도로 만들 수 있습니다. 열 배 차이입니다.

멀티스테이지 빌드는 보안 측면에서도 이점이 있습니다. 소스 코드나 학습 데이터가 프로덕션 이미지에 남지 않아 정보 유출 위험이 줄어듭니다.

김개발 씨는 멀티스테이지 빌드를 적용하여 빌드 파이프라인을 개선했습니다. 이제 학습은 무거운 환경에서, 배포는 가벼운 환경에서 진행됩니다.

효율과 보안 두 가지를 모두 챙겼습니다.

실전 팁

💡 - 스테이지 이름을 의미있게 지으면 Dockerfile 가독성이 높아집니다

• docker build --target builder처럼 특정 스테이지까지만 빌드할 수도 있습니다

---

6. Docker Compose로 구성

프로젝트가 커지면서 ML 서비스 하나로는 부족해졌습니다. 모델 서빙 서버, 전처리 서비스, Redis 캐시, 모니터링 도구까지 여러 컨테이너가 필요합니다.

이주니어 씨가 물었습니다. "이걸 다 따로 실행해야 하나요?" 박시니어 씨가 Docker Compose를 꺼내 들었습니다.

Docker Compose는 여러 컨테이너로 구성된 애플리케이션을 정의하고 실행하는 도구입니다. 마치 오케스트라 지휘자가 여러 악기를 하나로 조율하듯, Compose는 여러 서비스를 하나의 설정 파일로 관리합니다.

docker-compose up 한 번이면 전체 시스템이 실행됩니다.

다음 코드를 살펴봅시다.

version: '3.8'

services:
  # ML 모델 서빙 서비스
  ml-server:
    build: ./ml-server
    ports:
      - "8000:8000"
    volumes:
      - ./models:/app/models
    environment:
      - MODEL_PATH=/app/models/latest.pkl
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: 1
              capabilities: [gpu]
    depends_on:
      - redis

  # 전처리 서비스
  preprocessor:
    build: ./preprocessor
    environment:
      - ML_SERVER_URL=http://ml-server:8000

  # 캐시 서비스
  redis:
    image: redis:7-alpine
    ports:
      - "6379:6379"

  # 모니터링
  prometheus:
    image: prom/prometheus
    volumes:
      - ./prometheus.yml:/etc/prometheus/prometheus.yml
    ports:
      - "9090:9090"

현대 ML 시스템은 단일 모델 서버로 끝나지 않습니다. 요청을 받아 전처리하는 서비스, 실제 추론을 수행하는 서비스, 결과를 캐싱하는 Redis, 메트릭을 수집하는 Prometheus까지.

여러 컴포넌트가 함께 동작합니다. 이 모든 것을 일일이 docker run으로 실행하면 어떻게 될까요?

명령어가 길어지고, 순서도 맞춰야 하고, 네트워크 설정도 복잡해집니다. 실수하기 딱 좋은 환경입니다.

Docker Compose는 이 복잡함을 해결합니다. docker-compose.yml 파일 하나에 모든 서비스를 정의합니다.

그리고 docker-compose up 명령어 하나로 전체 시스템을 실행합니다. 파일 구조를 살펴보겠습니다.

services 아래에 각 컨테이너를 정의합니다. build는 Dockerfile 위치를, image는 사용할 이미지를 지정합니다.

직접 만든 서비스는 build를, Redis처럼 공식 이미지가 있는 것은 image를 씁니다. ports는 포트 매핑입니다.

"8000:8000"은 호스트의 8000번 포트를 컨테이너의 8000번 포트에 연결합니다. 외부에서 이 포트로 접근할 수 있게 됩니다.

volumes는 호스트의 디렉토리를 컨테이너에 마운트합니다. 모델 파일을 컨테이너 외부에 두면 이미지를 다시 빌드하지 않고도 모델을 교체할 수 있습니다.

개발 중에는 코드를 마운트하여 실시간으로 변경사항을 반영할 수도 있습니다. depends_on은 서비스 간 의존성을 정의합니다.

ml-server가 redis에 의존한다고 명시하면, Compose는 redis를 먼저 시작합니다. 단, 컨테이너가 시작되었다는 것이지 서비스가 준비되었다는 보장은 아닙니다.

애플리케이션 레벨에서 재시도 로직이 필요할 수 있습니다. GPU 할당도 Compose에서 가능합니다.

deploy.resources 섹션에서 NVIDIA GPU를 예약할 수 있습니다. docker-compose up 명령어에 --gpus 옵션을 붙일 필요가 없어집니다.

서비스 간 통신도 간편해집니다. 같은 Compose 파일에 정의된 서비스들은 자동으로 같은 네트워크에 속합니다.

서비스 이름을 호스트명으로 사용할 수 있습니다. preprocessor에서 http://ml-server:8000으로 요청하면 ml-server 컨테이너에 도달합니다.

개발 환경과 프로덕션 환경을 분리할 수도 있습니다. docker-compose.override.yml 파일을 만들면 개발용 설정을 덮어씁니다.

볼륨 마운트나 디버그 포트 같은 개발 전용 설정을 여기에 둡니다. 이주니어 씨는 Docker Compose를 도입하여 복잡한 ML 시스템을 손쉽게 관리하게 되었습니다.

새 팀원이 와도 docker-compose up 한 번이면 전체 개발 환경이 준비됩니다. 온보딩 시간이 하루에서 한 시간으로 줄었습니다.

실전 팁

💡 - docker-compose logs -f 서비스명으로 특정 서비스의 로그만 실시간으로 볼 수 있습니다

• docker-compose down -v는 볼륨까지 삭제하니 주의하세요

---

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