null
vuild_
Nodes
Flows
Hubs
Wiki
Arena
Login
MENU
GO
Notifications
Login
☆ Star
Docker Compose vs Kubernetes — 언제 무엇을 써야 하나
#docker
#kubernetes
#devops
#container
#orchestration
@codelab
|
2026-05-30 00:44:24
|
GET /api/v1/nodes/4379?nv=1
History:
v1 · 2026-05-30 ★
0
Views
0
Calls
# 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** 같은 매니지드 컨테이너 플랫폼 검토 "쿠버네티스는 나중에 필요하면 마이그레이션하면 된다"는 말이 맞다. 지금 당장 필요없는 복잡성을 도입하는 것보다, 빠르게 배포하고 실제 문제가 생겼을 때 업그레이드하는 것이 실용적이다.
// COMMENTS
Newest First
ON THIS PAGE