Docker Compose vs Kubernetes — 언제 무엇을 선택할까

Docker Compose와 Kubernetes는 둘 다 컨테이너를 정의하고 실행하는 도구지만, 설계 목표가 근본적으로 다르다. Docker Compose는 단일 호스트(single host) 위에서 여러 컨테이너를 하나의 논리적 애플리케이션으로 묶어 실행하는 도구다. 반면 Kubernetes는 여러 서버(노드)로 구성된 클러스터를 추상화하고, 그 위에서 컨테이너 워크로드를 스케줄링·관리하는 오케스트레이션 플랫폼이다.

Docker Compose는 docker-compose.yml 한 파일로 서비스, 네트워크, 볼륨을 선언하고 docker compose up 한 줄로 전체 스택을 올린다. 노드는 하나뿐이고 스케일링도 해당 머신의 CPU/메모리 한도 안에서만 가능하다. 컨테이너가 죽으면 재시작 정책(restart: always 등)으로 되살릴 수 있지만, 호스트 자체가 죽으면 서비스 전체가 내려간다.

Kubernetes는 Control Plane(kube-apiserver, etcd, scheduler, controller-manager)과 Worker Node(kubelet, kube-proxy, container runtime)로 구성된 분산 시스템이다. Pod, Deployment, Service, Ingress, ConfigMap, Secret 같은 추상 레이어 위에서 애플리케이션을 정의한다. 노드 하나가 죽어도 스케줄러가 다른 노드에 Pod를 재배치하고, HorizontalPodAutoscaler(HPA)가 트래픽에 따라 replica 수를 자동으로 조절한다.

요약하면: Docker Compose는 개발 환경, 소규모 운영, 단일 서버 배포에 최적화돼 있고, Kubernetes는 멀티 노드 고가용성(HA), 자동 스케일링, 대규모 서비스 운영을 위한 플랫폼이다. 이 차이를 이해하지 않고 도구를 선택하면 Kubernetes의 운영 복잡도를 감당하면서도 그 이점을 전혀 얻지 못하는 상황이 생긴다.

※ Kubernetes는 관리형 클러스터(EKS, GKE, AKS)를 사용하면 Control Plane 운영 부담을 대폭 줄일 수 있다.

Docker Compose는 다음 조건 중 하나 이상에 해당하면 충분한 선택이다.

개발 환경 표준화

로컬 개발 환경에서 DB, 캐시, 메시지 큐를 포함한 전체 스택을 재현할 때 Docker Compose는 사실상 표준이다. docker compose up 한 줄로 신규 팀원이 동일한 환경을 구성할 수 있다. Kubernetes로 로컬 개발 환경을 구성하면(minikube, kind 등) 학습 비용과 리소스 소모가 훨씬 크다. 개발 환경에 한해서는 Kubernetes를 도입한 팀도 Docker Compose를 병행 사용하는 경우가 많다.

소규모 팀, 단일 서버 운영

트래픽 피크가 예측 가능하고 단일 서버(예: 8코어 32GB RAM EC2 인스턴스)에서 충분히 처리 가능한 서비스라면 Kubernetes를 도입할 이유가 없다. Kubernetes Control Plane 자체가 최소 2~4코어, 4~8GB RAM을 상시 점유하며, 클러스터 운영을 위한 추가 인력이 필요하다. 서비스 규모가 이를 정당화하지 못한다면 Docker Compose + Nginx + Certbot 조합으로 충분하다.

MVP 및 초기 스타트업

제품-시장 적합성(PMF)을 검증하는 단계에서 인프라에 투자해야 할 엔지니어링 자원은 최소화해야 한다. Docker Compose로 빠르게 배포하고, 실제로 스케일링 문제가 발생하는 시점에 Kubernetes로 전환하는 것이 합리적인 순서다. "나중에 Kubernetes로 바꾸기 어려울까봐"라는 이유로 처음부터 Kubernetes를 선택하는 것은 대부분의 경우 과도한 투자다.

CI/CD 파이프라인 내 테스트 환경

GitHub Actions, GitLab CI 등에서 통합 테스트 환경을 구성할 때 Docker Compose는 가장 빠르게 전체 스택을 띄우고 내리는 방법이다. docker compose up -d로 DB와 의존 서비스를 올리고, 테스트 실행 후 docker compose down -v로 정리하는 패턴은 CI 환경에서 검증된 접근법이다.

Kubernetes 도입을 실제로 정당화하는 조건은 다음과 같다. 이 조건 중 하나라도 해당된다면 Kubernetes 또는 그에 준하는 오케스트레이션 레이어를 진지하게 검토해야 한다.

단일 서버의 수직 확장(Scale-Up) 한계에 도달

트래픽이 늘어 현재 서버의 CPU/메모리로 처리할 수 없는 상황이고, 단순히 더 큰 인스턴스로 업그레이드해도 해결되지 않는다면 수평 확장(Scale-Out)이 필요하다. 수평 확장을 여러 노드에서 자동으로 관리하려면 오케스트레이터가 필요하다. Docker Compose는 이 역할을 수행할 수 없다.

무중단 배포(Zero-Downtime Deployment) 요구사항

SLA 99.9% 이상을 요구하는 서비스는 배포 시 다운타임이 허용되지 않는다. Kubernetes Deployment의 롤링 업데이트는 새 버전의 Pod를 먼저 올리고 구 버전을 내리는 방식으로 다운타임 없이 배포한다. maxSurge와 maxUnavailable 파라미터로 배포 속도와 안정성을 조절할 수 있다. Docker Compose에서 이를 구현하려면 Nginx 설정 변경, 블루-그린 배포 스크립트 등을 직접 관리해야 한다.

트래픽 기반 자동 스케일링

시간대별 트래픽 변동이 크거나 이벤트성 트래픽이 발생하는 서비스라면 HorizontalPodAutoscaler(HPA)가 CPU/메모리 사용률 또는 커스텀 메트릭을 기준으로 replica 수를 자동으로 늘리고 줄인다. 피크 트래픽을 위해 상시 과잉 용량을 유지하지 않아도 되므로 비용 효율이 올라간다.

여러 팀이 같은 인프라를 공유

여러 개발팀이 같은 클러스터에서 서비스를 운영한다면 Kubernetes의 Namespace, RBAC, NetworkPolicy, ResourceQuota가 팀 간 격리와 자원 제한을 제공한다. Docker Compose는 이 수준의 멀티 테넌시 제어를 지원하지 않는다.

서비스 메시(Service Mesh), 고급 네트워킹 요구

마이크로서비스 간 mTLS 암호화, 트래픽 라우팅 제어, 서킷 브레이커, 분산 트레이싱이 필요한 서비스라면 Kubernetes 위에서 Istio, Linkerd 같은 서비스 메시를 운영하는 것이 현실적이다. Docker Compose 환경에서 이 수준의 네트워킹을 구현하는 것은 사실상 불가능하다.

Docker Compose에서 Kubernetes로 전환할 때 가장 먼저 고려할 도구는 Kompose다. Kompose는 docker-compose.yml을 Kubernetes 매니페스트(Deployment, Service, PersistentVolumeClaim 등)로 자동 변환해주는 CNCF 프로젝트다(https://kompose.io). 변환 결과가 그대로 프로덕션에서 쓸 수 있는 수준은 아니지만, 시작점을 빠르게 만들어준다는 점에서 유용하다.

Kompose 변환 후 반드시 검토해야 할 부분

• 볼륨 처리: Compose의 named volume은 PersistentVolumeClaim으로 변환되지만 스토리지 클래스(StorageClass) 설정은 클러스터 환경에 맞게 직접 수정해야 한다.
• 환경변수 / 시크릿: Compose의 environment는 그대로 Deployment의 env 필드로 변환된다. 민감한 값은 Kubernetes Secret으로 분리하고 secretKeyRef로 참조하도록 수정해야 한다.
• 네트워크: Compose의 service 이름으로 통신하던 구조는 Kubernetes Service 오브젝트와 DNS로 대체된다. 서비스 이름이 그대로 유지되면 애플리케이션 코드 변경 없이 작동하는 경우가 많다.
• depends_on: Kubernetes는 depends_on을 지원하지 않는다. Init Container 또는 readinessProbe로 서비스 준비 상태를 확인하는 방식으로 대체해야 한다.

Helm Chart로 패키징

변환된 매니페스트가 안정화되면 Helm Chart로 패키징하는 것을 권장한다. Helm은 환경별(dev/staging/production) 값을 values.yaml로 분리하고, 릴리스 히스토리와 롤백을 관리하는 Kubernetes 패키지 매니저다(https://helm.sh). 오픈소스 차트를 수정해서 쓰는 것보다 내부 애플리케이션은 직접 차트를 작성하는 것이 장기적으로 관리하기 쉽다.

단계적 전환 전략

프로덕션을 한 번에 전환하는 것은 리스크가 크다. 다음 순서를 권장한다: (1) 스테이징 환경을 Kubernetes로 전환해 2~4주 운영, (2) 트래픽 일부를 Kubernetes 환경으로 라우팅해 비교, (3) 문제 없으면 프로덕션 전환 후 Docker Compose 환경을 일정 기간 유지해 롤백 경로 확보. 데이터베이스는 Kubernetes 밖 관리형 서비스(RDS, Cloud SQL 등)를 사용하는 것이 마이그레이션 리스크를 낮추는 가장 실용적인 방법이다.

Docker Compose와 Kubernetes 사이에는 여러 대안이 있다. 각 도구의 현황과 적합한 케이스를 정리한다.

Docker Swarm — 사실상 유지보수 모드

Docker Swarm은 Docker 내장 오케스트레이터로, Compose 파일 형식을 그대로 사용해 멀티 노드 클러스터를 구성할 수 있다. 학습 곡선이 낮고 Docker CLI만으로 클러스터를 관리할 수 있다는 장점이 있었다. 그러나 Docker Inc.가 Kubernetes 지원에 집중하면서 Swarm의 신규 기능 개발은 사실상 중단된 상태다. 2026년 기준으로 신규 프로젝트에 Swarm을 선택하는 것은 권장하지 않는다. 기존 Swarm 운영 환경은 Kubernetes 또는 아래 대안으로 전환을 검토해야 한다.

HashiCorp Nomad — 심플한 멀티 워크로드 오케스트레이터

Nomad(https://www.nomadproject.io)는 Kubernetes보다 훨씬 단순한 아키텍처로 컨테이너뿐 아니라 가상머신, 독립 바이너리, Java JAR 등 다양한 워크로드를 오케스트레이션한다. 클러스터 구성이 간단하고 단일 바이너리로 배포된다. Consul(서비스 디스커버리)과 Vault(시크릿 관리)와 함께 HashiCorp 스택을 이미 사용하는 팀에게 자연스러운 선택이다. 다만 생태계와 커뮤니티 규모는 Kubernetes에 비해 작다.

AWS ECS / Fargate — 서버리스 컨테이너

AWS ECS(Elastic Container Service)는 AWS 관리형 컨테이너 오케스트레이터다. EC2 기반(ECS on EC2)과 서버리스(AWS Fargate) 두 가지 실행 모드를 지원한다. Fargate를 사용하면 노드 관리 없이 컨테이너를 실행할 수 있어 운영 부담이 크게 줄어든다. AWS 인프라에 이미 깊이 투자된 팀이라면 ECS는 Kubernetes보다 낮은 운영 비용으로 프로덕션급 컨테이너 오케스트레이션을 제공한다. 단, AWS 종속성(vendor lock-in)이 생긴다.

Google Cloud Run — 이벤트 기반 서버리스

Cloud Run(https://cloud.run)은 컨테이너 이미지를 직접 배포하면 요청이 올 때 자동으로 인스턴스를 올리고 요청이 없으면 0으로 스케일 다운하는 완전관리형 서비스다. 상시 실행이 필요 없는 API, 배치 작업, 백엔드 서비스에 적합하다. 클러스터 관리가 전혀 필요 없고 초당 과금이라 유휴 비용이 없다. Kubernetes 수준의 세밀한 제어는 불가능하지만, 그 복잡도가 필요 없는 서비스라면 Cloud Run이 가장 낮은 운영 비용으로 컨테이너를 프로덕션에 올리는 방법이다.

도구 선택은 팀의 현재 상황과 실제 요구사항을 기준으로 해야 한다. 아래 매트릭스로 판단해라.

핵심 원칙은 하나다: 현재 가진 문제를 해결하는 도구를 선택해라. Kubernetes는 강력하지만 그 복잡도는 실제 규모 문제가 생겼을 때 비로소 정당화된다. Docker Compose로 시작하고 실제로 한계에 부딪히면 전환해라. 그 시점에 팀도 더 성숙해 있고, 전환 비용을 감당할 여력도 생겨 있을 것이다.