"도커(Docker)만으로 부족할까?" : 컨테이너 오케스트레이션이 왜 필요한지 실무적 배경

 

"내 컴퓨터에서는 잘 되는데, 왜 서버에만 가면 안 되지?"

이 고질적인 문제를 해결하며 개발 패러다임을 바꾼 도커(Docker)는 이제 백엔드/DevOps 엔지니어에게 필수 도구가 되었습니다. 애플리케이션을 컨테이너라는 독립된 상자에 담아 어디서든 똑같이 실행할 수 있게 되었으니까요.

하지만 서비스가 성장하고 사용자가 늘어나면서, 우리는 곧 새로운 벽에 부딪히게 됩니다.

"컨테이너가 3개일 땐 도커로 충분했는데, 30개, 300개가 되니까 감당이 안 되네?"

오늘 글에서는 도커만으로 실무 서비스를 운영할 때 마주하는 한계와, 왜 결국 쿠버네티스(Kubernetes) 같은 '컨테이너 오케스트레이션' 시스템으로 넘어갈 수밖에 없는지 그 배경을 알아보겠습니다.

1. 도커(Docker)의 역할: 훌륭한 '단일 수송선'

이해를 돕기 위해 물류에 비유해 보겠습니다.

도커는 규격화된 최고의 컨테이너 상자이자, 이를 실어 나르는 단일 수송선입니다.

• 내 앱을 가볍고 안전하게 포장해 줍니다.
• 호스트 OS 환경에 구애받지 않고 어디서나 '똑같이' 실행됩니다.
• 개발 환경과 운영 환경의 파편화를 완벽하게 해결해 줍니다.

여기까지는 평화롭습니다. 서비스 규모가 작고, 서버 1~2대로 충분할 때까지는 말이죠.

2. 실무에서 마주하는 4가지 대참사 (도커의 한계)

회사가 대박이 나고 트래픽이 몰리기 시작합니다. 서버를 늘리고 컨테이너를 수십 개로 복제해야 하는 상황이 왔습니다. 이때부터 도커 엔진(Docker Engine) 단독 운영은 시스템 엔지니어에게 악몽으로 변합니다.

① 새벽 3시의 악몽: 컨테이너 다운 (Self-healing의 부재)

• 상황: 잘 구동되던 결제 모듈 컨테이너가 알 수 없는 메모리 누수(Memory Leak)로 새벽에 죽어버렸습니다.
• 도커만 쓸 때: 서버 관리자가 모니터링 경고를 보고 새벽에 깨어나 수동으로 docker run이나 docker restart를 쳐서 살려내야 합니다. 처리하는 동안 서비스는 마비됩니다.

② "저 컨테이너는 어느 서버에 넣지?" (Scheduling의 부재)

• 상황: 트래픽 분산을 위해 물리 서버가 5대로 늘어났고, 컨테이너 20개를 나누어 띄워야 합니다.
• 도커만 쓸 때: 관리자가 각 서버의 CPU와 메모리 잔여량을 일일이 확인한 뒤, "음, 3번 서버가 한산하니까 여기다 띄워야겠다"라며 수동으로 분배해야 합니다. 서버 한 곳에 컨테이너가 몰려 터지거나, 노는 서버가 생기는 비효율이 발생합니다.

③ 갑작스러운 트래픽 폭발 (Auto-scaling의 부재)

• 상황: 마케팅 이벤트나 핫딜 진행으로 갑자기 사용자가 10배로 몰려 컨테이너를 당장 5개에서 50개로 늘려야 합니다.
• 도커만 쓸 때: 사람이 일일이 명령어를 쳐서 컨테이너 인스턴스를 늘리고, 이 늘어난 컨테이너들의 포트를 앞단의 로드 밸런서(L4/L7)에 하나하나 수동으로 연결해 줘야 합니다. 처리가 끝나면 이미 이벤트는 종료되어 있겠죠.

④ 서비스 간 통신과 업데이트의 한계 (Service Discovery & Rolling Update)

• 상황: 수십 개의 컨테이너가 서로 IP를 알고 통신해야 하며, 서비스 중단 없이 새로운 버전으로 업데이트해야 합니다.
• 도커만 쓸 때: 컨테이너가 재시작될 때마다 내부 IP가 바뀌기 때문에 설정 파일을 계속 수정해 주어야 합니다. 또한, 업데이트를 하려면 기존 컨테이너를 죽이고 새 컨테이너를 띄우는 동안 필연적으로 '서비스 다운타임(Downtime)'이 발생합니다.

3. 해결사, 컨테이너 오케스트레이션(Container Orchestration)의 등장

이 모든 고충을 해결하기 위해 등장한 것이 바로 오케스트레이션 도구이며, 그 대장 주주가 바로 쿠버네티스(Kubernetes, K8s)입니다.

오케스트라의 지휘자가 수많은 악기 연주자들을 통솔해 하나의 아름다운 교향곡을 만들어내듯, 쿠버네티스는 수많은 서버(Node)에 분산된 수천 개의 컨테이너를 하나의 거대한 시스템처럼 자동 관리해 줍니다.

쿠버네티스가 도입되면 앞서 말한 악몽들이 다음과 같이 자동화됩니다.

• 자동 복구 (Self-healing): 컨테이너가 죽으면? 사람이 개입하기도 전에 쿠버네티스가 알아서 감지하고 새 컨테이너를 즉시 살려냅니다.
• 자동 스케줄링 (Scheduling): 알아서 서버들의 리소스 상태를 파악해 가장 여유롭고 적합한 서버에 컨테이너를 효율적으로 배치합니다.
• 자동 확장 (Auto-scaling): CPU 사용량이 지정한 임계치를 넘으면 컨테이너 개수를 알아서 늘리고, 트래픽이 줄어들면 다시 줄여 비용을 아낍니다.
• 무중단 배포 (Rolling Update): 구버전 컨테이너를 하나씩 죽이고 신버전을 하나씩 띄우며, 트래픽을 자연스럽게 전환해 사용자에게 중단 없는 서비스를 제공합니다.

요약: 나에게 지금 필요한 것은?

결론적으로 도커와 쿠버네티스는 대체재가 아닌 보완재입니다.

비교 항목	도커 (Docker) 단독 사용	쿠버네티스 (Kubernetes) 도입
적합한 규모	단일 서버, 토이 프로젝트, 소규모 스타트업	멀티 서버(클러스터), 마이크로비스(MSA), 대규모 서비스
관점	어떻게(How) 컨테이너를 만들고 실행할 것인가?	만들어진 컨테이너들을 **어디서, 어떻게 운영(Manage)**할 것인가?
관리 주체	엔지니어의 수동 관리 및 스크립트	쿠버네티스 엔진의 자동화(선언형 인프라)

현재 운영 중인 서비스가 단일 인스턴스로도 충분히 감당 가능한 수준이라면 도커만으로도 차고 넘칩니다. 하지만 "서버를 여러 대 써야 하고, 절대 서비스가 죽으면 안 되며, 확장성에 유연해야 한다"면, 그때가 바로 쿠버네티스라는 거인의 어깨 위로 올라탈 시간입니다.