Kubernetes vs Docker Compose 2026: 언제 무엇을 쓸까?

컨테이너 오케스트레이션, 어떤 것을 선택할까?

컨테이너 기술은 2026년 현재 모든 규모의 소프트웨어 개발에서 사실상 표준이 되었습니다. 그런데 컨테이너를 어떻게 관리하고 오케스트레이션할 것인가에 대한 선택은 여전히 많은 개발자와 팀을 고민하게 만듭니다.

Docker Compose는 간단하고 직관적인 로컬 개발 및 소규모 배포 도구이고, **Kubernetes(K8s)**는 대규모 프로덕션 워크로드를 위한 강력한 오케스트레이션 플랫폼입니다. 하지만 "Kubernetes가 무조건 좋다"는 것은 위험한 일반화입니다.

이 글에서는 두 도구를 모든 측면에서 비교하고, 프로젝트 상황에 맞는 올바른 선택을 할 수 있는 결정 프레임워크를 제공합니다.

기본 개념 정리

Docker Compose란?

Docker Compose는 멀티 컨테이너 Docker 애플리케이션을 정의하고 실행하기 위한 도구입니다. YAML 파일 하나로 여러 서비스를 정의하고, 한 번의 명령으로 모두 실행할 수 있습니다.

# docker-compose.yml - 전형적인 웹 애플리케이션
version: "3.9"

services:
  web:
    build: ./frontend
    ports:
      - "3000:3000"
    environment:
      - API_URL=http://api:8080
    depends_on:
      - api

  api:
    build: ./backend
    ports:
      - "8080:8080"
    environment:
      - DATABASE_URL=postgres://user:pass@db:5432/myapp
    depends_on:
      - db
      - redis

  db:
    image: postgres:16
    volumes:
      - postgres_data:/var/lib/postgresql/data
    environment:
      - POSTGRES_USER=user
      - POSTGRES_PASSWORD=pass
      - POSTGRES_DB=myapp

  redis:
    image: redis:7-alpine
    volumes:
      - redis_data:/data

volumes:
  postgres_data:
  redis_data:

# 실행은 이 한 줄이면 충분
docker compose up -d

Kubernetes란?

Kubernetes는 Google이 내부에서 사용하던 Borg 시스템을 기반으로 만든 컨테이너 오케스트레이션 플랫폼입니다. 자동 스케일링, 자가 치유, 롤링 업데이트 등 프로덕션 레벨의 기능을 제공합니다.

# deployment.yaml - Kubernetes 배포 매니페스트
apiVersion: apps/v1
kind: Deployment
metadata:
  name: api
  labels:
    app: api
spec:
  replicas: 3
  selector:
    matchLabels:
      app: api
  template:
    metadata:
      labels:
        app: api
    spec:
      containers:
        - name: api
          image: myapp/api:v1.2.0
          ports:
            - containerPort: 8080
          resources:
            requests:
              memory: "256Mi"
              cpu: "250m"
            limits:
              memory: "512Mi"
              cpu: "500m"
          livenessProbe:
            httpGet:
              path: /health
              port: 8080
            initialDelaySeconds: 10
            periodSeconds: 30
          readinessProbe:
            httpGet:
              path: /ready
              port: 8080
            initialDelaySeconds: 5
            periodSeconds: 10
---
apiVersion: v1
kind: Service
metadata:
  name: api-service
spec:
  selector:
    app: api
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080
  type: ClusterIP
---
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: api-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: api
  minReplicas: 3
  maxReplicas: 20
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 70

Modern data server room with network racks and cables

핵심 비교표

항목	Docker Compose	Kubernetes
학습 곡선	낮음 (수 시간)	높음 (수 주~수 개월)
설정 복잡도	YAML 1개	다수의 매니페스트
스케일링	수동 (`scale` 명령)	자동 (HPA, VPA)
자가 치유	기본 (`restart` 정책)	고급 (Pod 재생성, 노드 이동)
로드 밸런싱	기본 (포트 매핑)	내장 (Service, Ingress)
서비스 디스커버리	DNS 기반 (서비스명)	DNS + 환경변수 + API
비밀 관리	환경변수, .env 파일	Secrets, ConfigMap, External Secrets
롤링 업데이트	제한적	내장 (카나리, 블루-그린)
모니터링	외부 도구 필요	Prometheus, Grafana 생태계
멀티 호스트	Docker Swarm 필요	네이티브 지원
CI/CD 통합	간단	GitOps (ArgoCD, Flux)
비용	서버 비용만	관리 비용 + 클러스터 비용

아키텍처 차이 심층 분석

Docker Compose 아키텍처

Docker Compose는 단일 호스트에서 동작합니다:

┌─── 단일 호스트 (서버 1대) ──────────────┐
│                                         │
│  ┌─────────┐  ┌─────────┐  ┌────────┐  │
│  │  웹 앱  │  │   API   │  │   DB   │  │
│  │ :3000   │  │ :8080   │  │ :5432  │  │
│  └────┬────┘  └────┬────┘  └────┬───┘  │
│       │            │            │       │
│  ─────┴────────────┴────────────┴─────  │
│              Docker 네트워크             │
│                                         │
│  ┌──────────────────────────────────┐   │
│  │        Docker Engine             │   │
│  └──────────────────────────────────┘   │
└─────────────────────────────────────────┘

특징:

하나의 docker-compose.yml로 모든 서비스 정의
서비스 간 통신은 Docker 내부 네트워크
볼륨으로 데이터 영속성 보장
단일 호스트의 리소스에 제한

Kubernetes 아키텍처

Kubernetes는 멀티 노드 클러스터에서 동작합니다:

┌─── 컨트롤 플레인 ──────────────────┐
│  API Server | Scheduler | etcd     │
│  Controller Manager                │
└────────────────┬───────────────────┘
                 │
    ┌────────────┼────────────┐
    │            │            │
┌───┴──┐    ┌───┴──┐    ┌───┴──┐
│노드 1│    │노드 2│    │노드 3│
│      │    │      │    │      │
│ Pod  │    │ Pod  │    │ Pod  │
│ Pod  │    │ Pod  │    │ Pod  │
│ Pod  │    │ Pod  │    │ Pod  │
└──────┘    └──────┘    └──────┘

특징:

컨트롤 플레인이 클러스터 전체를 관리
Pod가 여러 노드에 분산 배치
노드 장애 시 자동으로 다른 노드로 이동
수평 확장이 네이티브로 지원

Female engineer using a laptop while monitoring data servers

사용 사례별 비교

Docker Compose가 적합한 경우

1. 로컬 개발 환경

# docker-compose.dev.yml
services:
  app:
    build:
      context: .
      target: development
    volumes:
      - .:/app        # 핫 리로드
      - /app/node_modules
    ports:
      - "3000:3000"
    environment:
      - NODE_ENV=development

  db:
    image: postgres:16
    ports:
      - "5432:5432"
    environment:
      - POSTGRES_PASSWORD=devpass

  mailhog:
    image: mailhog/mailhog
    ports:
      - "1025:1025"   # SMTP
      - "8025:8025"   # 웹 UI

모든 개발팀이 Docker Compose를 사용해야 하는 이유:

docker compose up 한 번으로 전체 개발 환경 구축
"내 컴퓨터에서는 되는데..." 문제 해결
새 팀원 온보딩이 5분 안에 완료

2. 소규모 프로덕션 배포

트래픽이 적은 서비스(월 방문자 <10만)라면 Docker Compose로 충분합니다:

# docker-compose.prod.yml
services:
  app:
    image: myapp:latest
    restart: always
    ports:
      - "3000:3000"
    deploy:
      resources:
        limits:
          memory: 512M
          cpus: "0.5"

  nginx:
    image: nginx:alpine
    restart: always
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./nginx.conf:/etc/nginx/nginx.conf
      - ./certs:/etc/nginx/certs

  db:
    image: postgres:16
    restart: always
    volumes:
      - db_data:/var/lib/postgresql/data
    environment:
      - POSTGRES_PASSWORD_FILE=/run/secrets/db_password
    secrets:
      - db_password

secrets:
  db_password:
    file: ./secrets/db_password.txt

volumes:
  db_data:

3. CI/CD 파이프라인의 테스트 환경

# docker-compose.test.yml
services:
  test-runner:
    build:
      context: .
      target: test
    depends_on:
      db:
        condition: service_healthy
    command: npm test

  db:
    image: postgres:16
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U postgres"]
      interval: 5s
      timeout: 5s
      retries: 5

Kubernetes가 적합한 경우

1. 대규모 마이크로서비스

# 마이크로서비스 아키텍처 예시
# 서비스가 10개 이상이고 독립적으로 스케일링 필요
apiVersion: apps/v1
kind: Deployment
metadata:
  name: order-service
spec:
  replicas: 5    # 주문 서비스는 5개 인스턴스
  # ...

---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: payment-service
spec:
  replicas: 3    # 결제 서비스는 3개 인스턴스
  # ...

---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: notification-service
spec:
  replicas: 2    # 알림 서비스는 2개 인스턴스
  # ...

2. 고가용성(HA) 요구사항

# Pod Disruption Budget - 최소 가용성 보장
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: api-pdb
spec:
  minAvailable: 2    # 항상 최소 2개 Pod 유지
  selector:
    matchLabels:
      app: api

---
# 여러 가용 영역에 분산 배치
apiVersion: apps/v1
kind: Deployment
spec:
  template:
    spec:
      topologySpreadConstraints:
        - maxSkew: 1
          topologyKey: topology.kubernetes.io/zone
          whenUnsatisfiable: DoNotSchedule
          labelSelector:
            matchLabels:
              app: api

3. 자동 스케일링이 필요한 경우

# 이벤트 기반 자동 스케일링 (KEDA)
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: api-scaler
spec:
  scaleTargetRef:
    name: api
  pollingInterval: 15
  cooldownPeriod: 60
  minReplicaCount: 2
  maxReplicaCount: 100
  triggers:
    - type: prometheus
      metadata:
        serverAddress: http://prometheus:9090
        metricName: http_requests_per_second
        threshold: "100"
        query: sum(rate(http_requests_total[1m]))

비용 비교

Docker Compose 비용 구조

소규모 프로덕션 (단일 VPS):
├── VPS 서버: $20~50/월 (4GB RAM, 2 vCPU)
├── 도메인: $12/년
├── SSL: 무료 (Let's Encrypt)
├── 백업: $5/월
└── 총: ~$30~60/월

중규모 프로덕션 (강력한 VPS):
├── VPS 서버: $80~160/월 (16GB RAM, 4 vCPU)
├── 관리형 DB: $15~50/월
├── CDN: $10/월
├── 모니터링: $10/월
└── 총: ~$115~230/월

Kubernetes 비용 구조

관리형 K8s (소규모):
├── EKS/GKE/AKS 클러스터: $70~75/월
├── 워커 노드 (3개): $150~300/월
├── 로드 밸런서: $15~25/월
├── 관리형 DB: $50~100/월
├── 모니터링: $20~50/월
└── 총: ~$305~550/월

관리형 K8s (중규모):
├── 클러스터: $70~75/월
├── 워커 노드 (10개): $500~1000/월
├── 로드 밸런서: $15~25/월
├── 관리형 DB: $100~300/월
├── 모니터링 스택: $50~100/월
├── DevOps 인건비: $8000~15000/월
└── 총: ~$8700~16500/월

비용 효율성 분석

규모	Docker Compose	Kubernetes	추천
월 트래픽 <10만	$30~60	$305~550	Docker Compose
월 트래픽 10만~100만	$115~230	$305~550	상황에 따라
월 트래픽 100만+	한계 도달	$500~2000+	Kubernetes
마이크로서비스 5개+	관리 어려움	$500+	Kubernetes

개발자 경험 (DX) 비교

Docker Compose의 DX

# 시작
docker compose up -d

# 로그 확인
docker compose logs -f api

# 서비스 재시작
docker compose restart api

# 스케일
docker compose up -d --scale api=3

# 종료
docker compose down

# 전체 초기화 (볼륨 포함)
docker compose down -v

학습 곡선: 1-2일이면 숙달 가능

Kubernetes의 DX

# 배포
kubectl apply -f deployment.yaml

# 상태 확인
kubectl get pods
kubectl describe pod api-7d8f5b6c9-x2k4l

# 로그 확인
kubectl logs -f deployment/api

# 스케일
kubectl scale deployment api --replicas=5

# 롤링 업데이트
kubectl set image deployment/api api=myapp/api:v1.3.0

# 롤백
kubectl rollout undo deployment/api

# 포트 포워딩 (디버깅)
kubectl port-forward svc/api 8080:80

# 셸 접속
kubectl exec -it pod/api-7d8f5b6c9-x2k4l -- /bin/sh

학습 곡선: 수 주~수 개월 (CKA 자격증 취득 수준이면 충분)

필요한 추가 도구들

도구	Docker Compose	Kubernetes
패키지 관리	불필요	Helm
시크릿 관리	.env 파일	External Secrets, Vault
모니터링	Portainer (선택)	Prometheus + Grafana
로깅	Docker logs	EFK/Loki 스택
CI/CD	GitHub Actions	ArgoCD, Flux
서비스 메시	불필요	Istio, Linkerd (선택)
인그레스	Nginx (직접)	Nginx Ingress, Traefik

마이그레이션 경로

Docker Compose에서 Kubernetes로

단계적 마이그레이션 전략:

Phase 1: Kompose로 자동 변환
  $ kompose convert -f docker-compose.yml
  → Kubernetes 매니페스트 자동 생성

Phase 2: 매니페스트 최적화
  → 리소스 제한 추가
  → 헬스 체크 추가
  → 시크릿 분리

Phase 3: 개발 환경에서 테스트
  → Minikube 또는 kind로 로컬 테스트

Phase 4: 스테이징 배포
  → 관리형 K8s에 스테이징 환경 구축

Phase 5: 프로덕션 전환
  → 점진적 트래픽 이전

# Kompose를 이용한 자동 변환
kompose convert -f docker-compose.yml

# 결과 파일들
# api-deployment.yaml
# api-service.yaml
# db-deployment.yaml
# db-service.yaml
# redis-deployment.yaml
# redis-service.yaml

중간 단계: Docker Swarm

Kubernetes가 과도하지만 Docker Compose만으로는 부족한 경우:

# docker-compose.swarm.yml
services:
  api:
    image: myapp/api:latest
    deploy:
      replicas: 3
      update_config:
        parallelism: 1
        delay: 10s
      rollback_config:
        parallelism: 1
      restart_policy:
        condition: on-failure
      placement:
        constraints:
          - node.role == worker
    networks:
      - app-network

networks:
  app-network:
    driver: overlay

# Swarm 모드 초기화
docker swarm init

# 스택 배포
docker stack deploy -c docker-compose.swarm.yml myapp

2026년 대안: 경량 Kubernetes

k3s - 경량 Kubernetes

# k3s 설치 (단일 명령)
curl -sfL https://get.k3s.io | sh -

# 바로 kubectl 사용 가능
k3s kubectl get nodes

Docker Compose의 간편함과 Kubernetes의 기능을 절충한 선택지입니다.

Coolify / CapRover - PaaS 대안

# Coolify: 오픈소스 Heroku 대안
# Docker Compose 기반이지만 웹 UI 제공
curl -fsSL https://cdn.coollabs.io/coolify/install.sh | bash

결정 프레임워크

아래 질문에 답해보세요:

1. 팀 규모가 5명 이하인가?
   → Yes: Docker Compose 유력
   → No: 다음 질문

2. 마이크로서비스가 5개 이상인가?
   → Yes: Kubernetes 유력
   → No: 다음 질문

3. 자동 스케일링이 필요한가?
   → Yes: Kubernetes
   → No: 다음 질문

4. 99.9% 이상 가용성이 필요한가?
   → Yes: Kubernetes
   → No: 다음 질문

5. DevOps 전담 인력이 있는가?
   → Yes: Kubernetes 가능
   → No: Docker Compose 또는 k3s

6. 월 인프라 예산이 $500 이상인가?
   → Yes: Kubernetes 고려
   → No: Docker Compose

한눈에 보는 추천

시나리오	추천
사이드 프로젝트	Docker Compose
스타트업 MVP	Docker Compose
소규모 팀 (1~5명)	Docker Compose 또는 k3s
중규모 팀 (5~20명)	k3s 또는 관리형 K8s
대규모 서비스	관리형 Kubernetes
로컬 개발 환경	Docker Compose (무조건)
CI/CD 테스트	Docker Compose
엔터프라이즈	Kubernetes

결론

Docker Compose와 Kubernetes는 경쟁이 아닌 보완 관계입니다. 대부분의 팀에서 가장 좋은 전략은 다음과 같습니다:

로컬 개발: Docker Compose (모든 경우)
초기 프로덕션: Docker Compose + VPS
성장기: k3s 또는 관리형 Kubernetes로 전환
확장기: 완전한 Kubernetes 생태계 도입

"Kubernetes를 써야 할 이유를 설명할 수 없다면, 아직 Docker Compose로 충분합니다."

이것이 2026년에도 여전히 유효한 가장 실용적인 조언입니다. 단순함에서 시작하고, 필요에 따라 복잡성을 추가하세요.

DevOps 작업에서 해시 생성기로 체크섬을 확인하거나, Base64 인코더로 설정 값을 인코딩해보세요.