단일 서버에서 Docker Compose로 운영하다가 트래픽이 늘면서 컨테이너를 여러 대에 분산해야 하는 상황을 맞은 적이 있습니다. 그때 Compose만으로는 더 이상 감당이 안 된다는 걸 체감하게 됩니다. 이 글에서는 Compose의 한계점을 실무 기준으로 정리하고, 언제 Kubernetes 전환을 고려해야 하는지 다뤄보겠습니다.
Docker Compose는 단일 호스트 기반 도구로, 다중 노드 오토스케일링, 자동 장애 복구, 롤링 업데이트 같은 기능을 기본 제공하지 않습니다. 트래픽 증가로 다중 서버 분산이 필요해지는 시점이 Kubernetes 전환을 검토할 신호입니다. 소규모 서비스라면 Compose를 유지하는 편이 오히려 관리 비용 측면에서 유리할 수 있습니다.
단일 호스트 구조의 한계
Docker Compose는 애초에 하나의 Docker 엔진 위에서 여러 컨테이너를 묶어 실행하는 도구로 설계됐습니다. 서버 한 대 안에서 컨테이너 여러 개를 관리하는 데는 최적화돼 있지만, 그 서버 자체가 죽으면 서비스 전체가 함께 내려갑니다.
실무에서 보면 이 구조적 한계가 처음에는 잘 안 보입니다. 트래픽이 적을 때는 서버 한 대로도 충분히 버티기 때문입니다. 문제는 서비스가 커지면서 서버 한 대의 CPU나 메모리로는 감당이 안 되는 시점이 반드시 온다는 겁니다. 그때 Compose는 “서버를 더 큰 사양으로 바꾸는” 수직 확장 외에는 뾰족한 답이 없습니다.
오토스케일링과 부하 분산 문제
docker compose up --scale web=3 명령어로 같은 서비스를 여러 개 띄우는 건 가능합니다. 하지만 이건 어디까지나 같은 서버 안에서의 컨테이너 개수 조정일 뿐, 트래픽에 따라 자동으로 늘고 줄어드는 오토스케일링은 아닙니다.
많이들 여기서 막히더라고요. scale 옵션만 보고 “이거면 오토스케일링 되는 거 아니냐”고 생각하시는 분들이 꽤 있습니다. 실제로는 트래픽 지표를 보고 스케일 명령을 사람이 직접 실행하거나, 별도 스크립트로 자동화해야 합니다. Kubernetes의 HPA(Horizontal Pod Autoscaler)처럼 CPU 사용률 기준으로 자동 확장되는 기능은 Compose 자체에는 없습니다.
docker compose up --scale web=3 -d부하 분산도 마찬가지입니다. 여러 컨테이너를 띄워도 앞단에 로드밸런서를 별도로 구성해야 트래픽이 고르게 분배됩니다. Nginx나 HAProxy를 직접 붙이는 방식이 일반적인데, 이 구성 자체를 관리자가 수동으로 유지보수해야 합니다.
장애 복구와 헬스체크 한계
Compose에도 restart: always나 healthcheck 설정이 있어서 컨테이너가 죽으면 재시작은 됩니다. 하지만 이건 “같은 서버 안에서 컨테이너를 다시 띄우는” 수준이고, 서버 자체에 문제가 생기면 그걸 감지해서 다른 서버로 옮겨주는 기능은 없습니다.
이건 직접 겪어보면 체감되는데, 새벽에 서버 하드웨어 이슈로 전체
서비스가 내려간 적이 있습니다. Compose 환경에서는 사람이 직접 들어가서 서버를 살리거나 다른 서버에 재배포하는 수밖에 없었습니다. Kubernetes였다면 노드 장애를 감지하고 다른 노드로 파드를 자동으로 옮겨주는 처리가 가능했을 상황입니다.
배포 전략과 무중단 업데이트
이 부분이 핵심입니다. 서비스 업데이트를 할 때 Compose는 기본적으로 컨테이너를 내렸다가 새 이미지로 다시 올리는 방식이라, 그 사이 짧게나마 서비스가 끊깁니다.
물론 블루-그린 배포나 롤링 업데이트를 Compose에서 아예 못 하는 건 아닙니다. 포트를 바꿔가며 새 컨테이너를 띄우고 로드밸런서 설정을 스크립트로 전환하는 방식으로 흉내는 낼 수 있습니다. 하지만 이 과정을 전부 수동 스크립트로 관리해야 하고, 실패했을 때 자동 롤백도 직접 구현해야 합니다. 초보자는 여기서 대부분 재시작 중단 없이 배포하는 걸 포기하고 새벽 시간대에 몰아서 배포하는 방식을 택하는데, 실무자는 결국 이 지점에서 Kubernetes나 별도 오케스트레이션 도구로 넘어가는 경우가 많습니다.
Compose와 Kubernetes 비교
| 항목 | Docker Compose | Kubernetes |
|---|---|---|
| 운영 범위 | 단일 호스트 | 다중 노드 클러스터 |
| 오토스케일링 | 미지원 (수동/스크립트) | HPA 등 자동 지원 |
| 장애 복구 | 컨테이너 단위 재시작만 가능 | 노드 장애 시 파드 자동 재배치 |
| 롤링 업데이트 | 수동 구현 필요 | 기본 기능으로 제공 |
| 학습 난이도 | 낮음 | 높음 |
| 적합한 규모 | 소규모, 단일 서버 서비스 | 중대규모, 다중 서버 서비스 |
전환을 고려해야 하는 시점!
초보자는 “Kubernetes가 더 좋다니까” 하는 이유만으로 전환을 검토하는 경우가 많은데, 실무자는 구체적인 신호가 나타났을 때 전환을 판단합니다.
- 서버 한 대의 CPU/메모리로 감당이 안 되는 트래픽이 지속적으로 발생할 때
- 서비스별로 독립적인 스케일 조정이 자주 필요할 때
- 무중단 배포가 비즈니스 요구사항으로 명확해졌을 때
- 다중 서버 간 장애 대응을 자동화해야 할 때
- 운영 조직 내 전담 인프라 인력을 확보할 수 있을 때
반대로 이 조건에 해당하지 않는다면, Kubernetes 도입이 오히려 관리 복잡도만 늘리는 결과로 이어지는 경우도 많습니다. 이 부분은 실제로 도구 자체보다 조직 규모와 운영 인력 문제인 경우가 대부분입니다.
실무 팁 — Kubernetes로 전환하기 전에 Docker Swarm처럼 상대적으로 진입장벽이 낮은 오케스트레이션 도구를 먼저 검토해보는 것도 방법입니다. Compose 파일을 거의 그대로 활용할 수 있어서 전환 부담이 적습니다.
전환 전 체크리스트
- 현재 서버 리소스 사용률이 지속적으로 임계치를 넘는지 확인
- 무중단 배포가 실제 비즈니스 요구사항인지 검토
- 클러스터 운영을 담당할 인력 또는 관리형 서비스(EKS, GKE 등) 활용 여부 결정
- 기존 compose.yaml을 Kubernetes 매니페스트로 변환하는 작업량 산정
- 모니터링, 로깅 체계를 클러스터 환경에 맞게 재구성할 계획 수립
지금 운영 중인 서비스의 서버 리소스 사용률을 한 번 확인해보세요. 지속적으로 70% 이상을 넘나든다면 전환을 진지하게 검토해볼 시점입니다.
Compose에서 Kubernetes로 전환하면서 가장 어려웠던 부분은 무엇이었나요? 댓글로 공유해주시면 다음 글에서 다뤄보겠습니다.
지금 서비스 규모에서 Compose와 Kubernetes 중 어느 쪽이 더 맞다고 생각하시나요?
다음 글 추천
- Docker Compose 설치 및 사용법, 실무 운영 기준으로 정리
- Kubernetes 클러스터 처음 구축할 때 알아야 할 개념 정리