Docker를 공부하다 보면 가장 먼저 헷갈리는 개념이 있습니다. 바로 이미지(Image)와 컨테이너(Container)입니다. 여기에 조금 더 나아가면 Docker Compose와 Kubernetes라는 개념도 등장합니다.
처음에는 모두 비슷해 보이지만, 실제 역할은 서로 다릅니다. 이번 글에서는 Docker 이미지와 컨테이너의 차이, Docker Compose가 유용한 상황, 그리고 Kubernetes가 Docker와 어떤 관계를 가지는지 정리해보겠습니다.
Docker 이미지는 애플리케이션을 실행하기 위해 필요한 파일, 라이브러리, 실행 환경, 설정 등을 하나로 묶어 놓은 실행 템플릿입니다.
반면 Docker 컨테이너는 이 이미지를 바탕으로 실제 실행된 프로세스 환경입니다.
쉽게 비유하면 다음과 같습니다.
| 구분 | 비유 | 설명 |
| 이미지 | 설계도 또는 실행 파일 | 컨테이너를 만들기 위한 읽기 전용 템플릿 |
| 컨테이너 | 실제 실행 중인 프로그램 | 이미지를 기반으로 실행된 독립적인 환경 |
예를 들어 nginx 이미지는 Nginx 서버를 실행하기 위한 파일과 설정을 포함하고 있습니다. 이 이미지를 docker run 명령어로 실행하면 실제 Nginx 서버가 동작하는 컨테이너가 만들어집니다.
docker pull nginx
docker run -d -p 8080:80 nginx
위 명령어에서 nginx는 이미지이고, docker run을 통해 실행된 결과물이 컨테이너입니다.
이미지는 직접 실행되는 것이 아니라, 컨테이너를 만들기 위한 기반입니다. 하나의 이미지로 여러 개의 컨테이너를 만들 수도 있습니다.
예를 들어 같은 nginx 이미지로 3개의 컨테이너를 실행하면, 모두 같은 기본 환경을 가지지만 각각 독립적으로 동작합니다.
이미지는 정적인 파일 묶음이고, 컨테이너는 동적으로 실행 중인 환경입니다.
이미지는 읽기 전용에 가깝고, 컨테이너는 실행 중에 로그, 임시 파일, 프로세스 상태 같은 변경 사항을 가질 수 있습니다. 다만 컨테이너 내부의 변경 사항은 기본적으로 컨테이너가 삭제되면 함께 사라질 수 있기 때문에, 데이터를 유지하려면 볼륨을 사용해야 합니다.

Docker Compose는 여러 개의 컨테이너로 구성된 애플리케이션을 쉽게 정의하고 실행할 수 있게 해주는 도구입니다.
일반적으로 실제 서비스는 컨테이너 하나만으로 구성되지 않습니다. 예를 들어 웹 애플리케이션을 만든다고 하면 다음과 같은 구성 요소가 필요할 수 있습니다.
이런 구성 요소를 각각 docker run 명령어로 실행할 수도 있지만, 컨테이너가 많아질수록 명령어가 길어지고 관리가 어려워집니다.
이때 Docker Compose를 사용하면 여러 컨테이너의 실행 설정을 compose.yaml 파일 하나에 정리할 수 있습니다.
예를 들어 다음과 같은 구성을 생각해볼 수 있습니다.
services:
app:
build: .
ports:
- "8000:8000"
depends_on:
- db
db:
image: mysql:8.3.0
environment:
MYSQL_ROOT_PASSWORD: pw_root
MYSQL_DATABASE: app_db
이렇게 작성한 뒤 아래 명령어 하나로 여러 컨테이너를 한 번에 실행할 수 있습니다.
docker compose up -d
종료할 때도 다음 명령어 하나면 됩니다.
docker compose down
Docker Compose는 특히 다음과 같은 상황에서 유용합니다.
첫째, 여러 컨테이너를 함께 실행해야 할 때 유용합니다. 예를 들어 FastAPI 서버와 MySQL 데이터베이스를 함께 실행해야 한다면 Compose 파일에 두 서비스를 함께 정의할 수 있습니다.
둘째, 개발 환경을 팀원들과 동일하게 맞추고 싶을 때 유용합니다. compose.yaml 파일을 프로젝트에 포함하면, 다른 팀원도 같은 설정으로 컨테이너를 실행할 수 있습니다.
셋째, 컨테이너 실행 명령어를 반복해서 입력하지 않아도 됩니다. 포트, 볼륨, 환경 변수, 네트워크 설정 등을 파일에 정리해두면 명령어가 훨씬 단순해집니다.
Dockerfile과 Docker Compose는 둘 다 Docker에서 자주 사용되지만, 목적이 다릅니다.
Dockerfile은 이미지를 만드는 파일입니다. 즉, 애플리케이션을 어떤 환경에서 실행할지 정의합니다.
예를 들어 Python 애플리케이션 이미지를 만들기 위한 Dockerfile은 다음과 같이 작성할 수 있습니다.
FROM python:3.11
WORKDIR /app
COPY requirements.txt .
RUN pip install -r requirements.txt
COPY . .
CMD ["python", "app.py"]
이 Dockerfile은 Python 환경을 준비하고, 필요한 패키지를 설치한 뒤, 애플리케이션을 실행하는 이미지를 만들기 위한 파일입니다.
반면 Docker Compose는 여러 컨테이너를 어떻게 실행할지 정의하는 파일입니다. 이미지를 직접 만들 수도 있고, 이미 만들어진 이미지를 가져와서 실행할 수도 있습니다.
정리하면 다음과 같습니다.
| 구분 | Dockerfile | Docker Compose |
| 목적 | Docker 이미지 생성 | 여러 컨테이너 실행 및 관리 |
| 파일명 | Dockerfile | compose.yaml 또는 docker-compose.yml |
| 주요 역할 | 실행 환경 정의 | 서비스, 네트워크, 볼륨, 환경 변수 관리 |
| 사용 명령어 | docker build | docker compose up |
| 예시 | Python 앱 이미지 만들기 | Python 앱 + MySQL 함께 실행하기 |
즉, Dockerfile은 “이미지를 어떻게 만들 것인가?”에 대한 답이고, Docker Compose는 “여러 컨테이너를 어떻게 함께 실행할 것인가?”에 대한 답입니다.

Kubernetes는 컨테이너화된 애플리케이션을 자동으로 배포, 확장, 관리하기 위한 컨테이너 오케스트레이션 플랫폼입니다.
Docker가 컨테이너를 만들고 실행하는 데 초점이 있다면, Kubernetes는 여러 서버에 걸쳐 수많은 컨테이너를 안정적으로 운영하는 데 초점이 있습니다.
예를 들어 서비스 사용자가 많아지면 컨테이너를 여러 개로 늘려야 합니다. 특정 컨테이너가 장애로 종료되면 다시 실행해야 합니다. 여러 서버에 컨테이너를 분산 배치해야 할 수도 있습니다.
이런 작업을 사람이 직접 관리하면 복잡하고 실수하기 쉽습니다. Kubernetes는 이런 작업을 자동화하는 역할을 합니다.
Kubernetes에서는 컨테이너를 직접 하나씩 관리하기보다는, 여러 추상화된 리소스를 통해 관리합니다.
가장 기본이 되는 개념은 Pod입니다.
Pod는 Kubernetes에서 배포할 수 있는 가장 작은 실행 단위입니다. 하나의 Pod 안에는 하나 이상의 컨테이너가 들어갈 수 있습니다. 보통은 하나의 Pod에 하나의 애플리케이션 컨테이너를 넣는 방식이 많이 사용됩니다.
Deployment는 Pod를 원하는 개수만큼 유지하고, 업데이트를 관리하는 역할을 합니다. 예를 들어 “내 웹 서버 Pod를 항상 3개 실행해줘”라고 설정하면 Kubernetes는 실제 상태를 계속 확인하면서 Pod 개수를 맞추려고 합니다.
Service는 Pod에 접근할 수 있는 고정된 네트워크 진입점을 제공합니다. Pod는 언제든 새로 생성되거나 삭제될 수 있기 때문에 IP가 바뀔 수 있습니다. Service는 이런 Pod들을 묶어서 안정적으로 접근할 수 있게 해줍니다.
Node는 실제 컨테이너가 실행되는 서버입니다. 여러 Node가 모여 Cluster를 구성합니다.
정리하면 다음과 같습니다.
| 개념 | 설명 |
| Cluster | Kubernetes가 관리하는 전체 서버 묶음 |
| Node | 컨테이너가 실제로 실행되는 서버 |
| Pod | Kubernetes의 가장 작은 실행 단위 |
| Deployment | Pod의 배포, 복제, 업데이트 관리 |
| Service | Pod에 접근하기 위한 네트워크 진입점 |
Docker와 Kubernetes는 경쟁 관계라기보다는 역할이 다른 도구입니다.
Docker는 컨테이너 이미지를 만들고 컨테이너를 실행하는 데 사용됩니다. 개발자는 Dockerfile을 작성해서 이미지를 만들고, 이 이미지를 Docker Hub 같은 이미지 저장소에 올릴 수 있습니다.
Kubernetes는 이렇게 만들어진 컨테이너 이미지를 가져와서 여러 서버에 배포하고 운영합니다.
흐름으로 보면 다음과 같습니다.
즉, Docker는 컨테이너 이미지를 만들고 실행하는 개발 및 실행 도구에 가깝고, Kubernetes는 컨테이너를 대규모 환경에서 운영하기 위한 관리 플랫폼에 가깝습니다.


Docker 이미지와 컨테이너, Docker Compose, Kubernetes는 모두 컨테이너 기반 개발과 배포에서 중요한 개념입니다.
Docker 이미지는 컨테이너 실행을 위한 템플릿이고, 컨테이너는 이미지를 기반으로 실제 실행된 환경입니다.
Dockerfile은 이미지를 만들기 위한 파일이고, Docker Compose는 여러 컨테이너를 한 번에 실행하고 관리하기 위한 도구입니다.
Kubernetes는 여러 서버 환경에서 컨테이너를 자동으로 배포하고, 확장하고, 복구하고, 관리하는 오케스트레이션 플랫폼입니다.
개발 단계에서는 Dockerfile과 Docker Compose를 많이 사용하고, 운영 환경이나 대규모 서비스에서는 Kubernetes를 사용하는 경우가 많습니다.
처음에는 개념이 비슷해 보여 헷갈릴 수 있지만, 다음과 같이 기억하면 이해하기 쉽습니다.
| 도구/개념 | 한 줄 요약 |
| Docker Image | 컨테이너를 만들기 위한 실행 템플릿 |
| Docker Container | 이미지를 기반으로 실행된 독립 환경 |
| Dockerfile | 이미지를 만드는 방법을 적은 파일 |
| Docker Compose | 여러 컨테이너를 한 번에 실행하는 도구 |
| Kubernetes | 여러 컨테이너를 자동으로 배포하고 운영하는 플랫폼 |
결국 Docker는 컨테이너를 만들고 실행하는 기반 기술이고, Docker Compose는 여러 컨테이너를 편리하게 실행하는 도구이며, Kubernetes는 컨테이너를 실제 운영 환경에서 안정적으로 관리하기 위한 플랫폼이라고 볼 수 있습니다.
| 양자화 기법인 Post-Training Quantization과 Quantization-Aware Training의 차이 (0) | 2026.06.29 |
|---|---|
| 딥러닝 모델을 ONNX, TensorRT 등의 포맷으로 변환해야 하는 이유 (0) | 2026.06.29 |
| RAG 시스템 'Agent' 개념 및 구현 방법 (3) | 2026.05.02 |
| RAG 시스템 성능 독립 평가 vs 종단간 평가 (0) | 2026.05.02 |
| LangChain으로 RAG 시스템 구축 시 필요한 주요 구성 요소와 역할 (0) | 2026.05.02 |