Docker Compose vs Kubernetes — 실무에서 언제 무엇을 쓸까

두 도구는 "컨테이너를 실행한다"는 공통점을 제외하면 설계 철학이 완전히 다르다. Compose는 단일 호스트에서 여러 컨테이너를 정의하고 함께 띄우는 도구다. Kubernetes는 복수의 노드(서버)로 구성된 클러스터 위에서 컨테이너를 스케줄링·자동 복구·스케일링하는 플랫폼이다.

핵심 차이를 한 문장으로 정리하면: Compose는 "이 서비스들을 지금 여기서 함께 실행해 줘"이고, Kubernetes는 "이 서비스들을 언제나, 어디서나, 원하는 수만큼 안정적으로 실행해 줘"다. 선택 기준은 "지금 당장 필요한 복잡도가 어느 수준인가"에서 시작해야 한다.

Docker Compose가 진짜 빛을 발하는 영역은 명확하다. 로컬 개발 환경, 소규모 팀의 스테이징 서버, 단일 서버로 충분한 내부 도구가 그 무대다.

Compose가 적합한 케이스

• 로컬 개발 환경 표준화: 팀 전체가 동일한 docker-compose.yml을 실행해 DB, 캐시, 백엔드, 프론트를 한 번에 띄운다. docker compose up -d 한 줄로 환경 준비가 완료된다.
• CI 파이프라인 내 통합 테스트: GitHub Actions, GitLab CI에서 의존 서비스(PostgreSQL, Redis, Elasticsearch 등)를 Compose로 올리고 테스트를 실행한 뒤 폐기하는 패턴이 일반적이다.
• 단일 서버 소규모 서비스: 트래픽이 월 수만~수십만 요청이고, 다운타임 몇 분이 비즈니스에 치명적이지 않다면 Compose + 단일 VPS로 충분하다. Nginx, API 서버, DB, 모니터링 스택을 Compose 하나로 관리할 수 있다.
• 내부 도구 / 사이드 프로젝트: Grafana, Metabase, n8n, Gitea 같은 내부 도구는 Kubernetes 클러스터 비용을 쓸 이유가 없다.
• 사용 인원 10명 이하 스타트업 초기: 아직 제품-시장 적합성(PMF)을 찾는 단계라면 인프라 복잡도를 최소화하고 기능 개발에 집중하는 것이 맞다.

Compose의 실질적 한계

Kubernetes를 도입하는 시점을 "서비스가 크면"이라고 모호하게 판단하는 팀이 많다. 실무에서는 아래 중 하나라도 해당되면 Kubernetes 전환을 적극 검토해야 한다.

Kubernetes 도입 트리거

• 무중단 배포가 비즈니스 요구사항이 된 시점: SLA(서비스 수준 협약)에 99.9% 이상 가용성이 명시된다면, 롤링 업데이트·자동 롤백·헬스체크 기반 트래픽 전환이 필수다.
• 자동 스케일링이 필요한 트래픽 패턴: 이벤트·할인 시즌 등 트래픽이 수십 배 급등하는 서비스는 HPA(Horizontal Pod Autoscaler)나 KEDA(이벤트 기반 오토스케일링)가 없으면 수동 대응이 불가능하다.
• 마이크로서비스 아키텍처로 전환: 서비스가 5개 이상으로 쪼개지면 서비스 디스커버리, 트래픽 라우팅, 분산 트레이싱, 서킷 브레이커가 필요해지고, 이는 Kubernetes 생태계(Istio, Linkerd 등)와 함께 동작하도록 설계되어 있다.
• 멀티 환경(dev/staging/prod) 격리 필요: Kubernetes Namespace로 환경별 격리, RBAC으로 권한 분리, Helm 차트로 환경별 값 주입이 표준화된다.
• 개발팀 규모 20명 이상: 여러 팀이 동시에 다른 서비스를 배포할 때 충돌 없이 독립적으로 운영하려면 Kubernetes의 네임스페이스 격리와 GitOps(ArgoCD, Flux) 연동이 실질적인 답이다.

Kubernetes 도입 전 확인해야 할 비용

Kubernetes는 운영 비용이 실재한다. 도입 전 현실적으로 계산해야 하는 항목은 다음과 같다.

결론: Kubernetes는 "언젠가 필요할 것 같아서"가 아니라 위 트리거가 실제로 발생했을 때 전환해야 한다. 너무 일찍 도입하면 인프라 관리에 에너지를 빼앗겨 제품 개발 속도가 떨어진다.

Compose로 운영 중인 서비스를 Kubernetes로 전환할 때 가장 많이 쓰는 경로는 두 가지다. Kompose를 이용한 자동 변환과, 처음부터 Helm 차트로 재작성하는 방법이다.

방법 1: Kompose 자동 변환

Kompose는 docker-compose.yml을 Kubernetes 매니페스트로 변환하는 공식 도구다. 완전한 변환은 아니지만 시작점으로 유용하다.

# Kompose 설치 (macOS)
brew install kompose

# 변환 실행
kompose convert -f docker-compose.yml

# 생성된 매니페스트 확인
ls -la
# web-deployment.yaml
# web-service.yaml
# db-deployment.yaml
# db-persistentvolumeclaim.yaml

# 클러스터에 적용
kubectl apply -f .

Kompose 변환의 한계: depends_on은 initContainer로 부분 변환되고, 볼륨 마운트 설정은 수동 검토가 필요하다. 네트워크 설정과 환경 변수는 대부분 올바르게 변환된다.

방법 2: 단계적 마이그레이션 전략

프로덕션 서비스라면 한 번에 모든 것을 전환하는 빅뱅 방식보다 단계적 전환이 안전하다.

1. 스테이트리스 서비스 먼저: 데이터베이스 없이 실행되는 API 서버, 프론트엔드 서버를 먼저 Kubernetes로 옮긴다. DB는 당분간 Compose 또는 관리형 DB 서비스(RDS, Cloud SQL)로 유지한다.
2. CI/CD 파이프라인 통합: GitHub Actions → ECR/GCR 이미지 빌드 → kubectl apply 또는 ArgoCD 동기화로 배포 파이프라인을 구성한다.
3. ConfigMap/Secret 전환: Compose의 .env 파일을 Kubernetes Secret과 ConfigMap으로 이전한다. 외부 시크릿 관리자(AWS Secrets Manager, HashiCorp Vault)와의 연동도 이 단계에서 구성한다.
4. Ingress 설정: Nginx Ingress Controller 또는 클라우드 로드밸런서를 통해 트래픽 라우팅을 설정한다. 도메인 기반 라우팅, TLS 인증서(cert-manager) 자동화를 여기서 구성한다.
5. 스테이트풀 서비스 전환: PostgreSQL, Redis 등 상태를 가진 서비스는 StatefulSet + PersistentVolume으로 전환하거나, 관리형 서비스로 외부화한다. 후자가 운영 부담이 훨씬 적다.

전환 시 자주 발생하는 문제

Kubernetes를 직접 구축(kubeadm, k3s)하는 팀은 줄고, 클라우드 관리형 서비스를 사용하는 팀이 늘었다. EKS(AWS), GKE(Google Cloud), AKS(Azure) 세 가지 주요 선택지를 실무 기준으로 비교한다.

소규모 팀을 위한 대안: k3s와 Lightweight Kubernetes

관리형 Kubernetes의 비용이 부담스러운 팀에게는 k3s가 현실적인 대안이다. Rancher Labs(SUSE)가 개발한 경량 Kubernetes 배포판으로, 단일 서버(1GB RAM)에서도 동작한다. 소규모 프로덕션, 엣지 컴퓨팅, 온프레미스 환경에서 활발히 사용된다.

• 설치: curl -sfL https://get.k3s.io | sh - 한 줄로 완료
• 기본 포함: Traefik Ingress, Flannel CNI, SQLite(소규모) 또는 etcd
• 주의: 고가용성(HA) 구성은 별도 etcd 클러스터 필요

지금까지 내용을 바탕으로 팀 상황에 맞는 선택 기준을 정리한다. 아래 표를 순서대로 점검하면 된다.

실무 판단 기준 3가지

1. 지금 당장 Kubernetes 없이 해결할 수 없는 문제가 있는가? 없다면 Compose로 시작하고, 명확한 트리거가 생겼을 때 전환하라.
2. Kubernetes를 운영할 인력이 있는가? DevOps/SRE가 없는 팀이라면 GKE Autopilot처럼 운영 부담을 클라우드에 최대한 위임하는 방향을 선택하라.
3. 데이터베이스를 Kubernetes 안에 넣을 것인가? 가능하면 관리형 DB 서비스를 쓰고 애플리케이션 레이어만 Kubernetes로 관리하는 것이 운영 복잡도를 크게 낮춘다.