Docker Compose vs Kubernetes — 언제 무엇을 써야 하나

# Docker Compose vs Kubernetes — 언제 무엇을 써야 하나

"컨테이너 쓴다고 하면 쿠버네티스 써야 하는 거 아닌가요?" 아니다. 오히려 대부분의 경우에는 Docker Compose로 충분하다.

## 핵심 차이부터

| 항목 | Docker Compose | Kubernetes |
|------|----------------|------------|
| 대상 환경 | 단일 호스트 | 멀티 노드 클러스터 |
| 학습 곡선 | 낮음 | 높음 |
| 셋업 시간 | 분 단위 | 시간~일 단위 |
| 자동 복구 | 제한적 | 완전 지원 (Pod 재시작) |
| 수평 스케일링 | 수동 | 자동 (HPA) |
| 서비스 디스커버리 | DNS (컴포즈 내부) | ClusterIP, Ingress |
| 운영 복잡도 | 낮음 | 높음 |

## Docker Compose가 맞는 상황

### 1. 로컬 개발 환경
앱 + DB + Redis + 메일 서버를 한 `docker-compose.yml`로 올리면 된다. 팀원 모두 `docker compose up -d` 한 줄로 동일한 환경을 갖는다. 쿠버네티스로 로컬 개발 환경을 구성하는 것은 대포로 모기 잡는 격이다.

### 2. 소규모 서비스 (트래픽 예측 가능)
사용자 수백~수천 명 수준, 단일 서버에서 운영 가능한 서비스라면 Compose로 충분하다. Nginx + PHP + MySQL 구성을 VPS에서 돌리는 것이 EKS 클러스터 운영보다 비용·복잡도 면에서 훨씬 유리하다.

### 3. CI/CD 파이프라인 내 테스트
GitHub Actions, GitLab CI에서 통합 테스트를 돌릴 때 `docker compose up` + `test` + `down` 패턴은 깔끔하다.

## Kubernetes가 필요한 상황

### 1. 고가용성이 필수인 서비스
파드(Pod)가 죽으면 자동으로 재시작되고, 노드가 죽어도 다른 노드에 파드가 재스케줄링된다. 24/7 SLA가 있는 프로덕션 환경에서는 k8s의 셀프힐링 기능이 결정적이다.

### 2. 트래픽 급변
HPA(Horizontal Pod Autoscaler)로 CPU/메모리 기준 파드 수를 자동 조절한다. 이벤트 트래픽이 10배로 튀어도 자동으로 스케일아웃이 된다.

### 3. 멀티 서비스 MSA 운영
수십 개의 마이크로서비스가 독립적으로 배포되어야 한다면, k8s의 네임스페이스·롤링업데이트·카나리 배포가 필수적이다.

### 4. 클라우드 네이티브 생태계 활용
Helm 차트, Istio 서비스 메시, Prometheus/Grafana 모니터링 스택 등 k8s 생태계의 도구들을 활용해야 할 때.

## 중간 선택지: Compose + Swarm

Docker Swarm은 Compose 문법 그대로 멀티 노드 클러스터를 운영할 수 있다. 학습 곡선은 거의 없고, 소규모 HA가 필요한 경우에 실용적이다. 다만 생태계가 k8s 대비 훨씬 작고, 신규 프로젝트에서 채택이 줄고 있다.

## 내 결론

- 개발 환경·소규모 서비스·CI 파이프라인 → **Docker Compose**
- 프로덕션 고가용성·자동 스케일링·MSA → **Kubernetes**
- 그 사이 어딘가 → Swarm이나 **Fly.io/Railway** 같은 매니지드 컨테이너 플랫폼 검토

"쿠버네티스는 나중에 필요하면 마이그레이션하면 된다"는 말이 맞다. 지금 당장 필요없는 복잡성을 도입하는 것보다, 빠르게 배포하고 실제 문제가 생겼을 때 업그레이드하는 것이 실용적이다.

Docker Compose vs Kubernetes — 언제 무엇을 써야 하나

// COMMENTS

ON THIS PAGE