컨테이너가 열 개를 넘어가면 Docker 만으로 부족해지는 순간

여기까지 왔다면 Docker로 이미지를 만들고, 데이터를 지키고, 여러 컨테이너를 compose로 묶고, 레지스트리를 거쳐 서버에 배포하는 전체 흐름을 알게 된 겁니다. 실제로 개인 프로젝트나 트래픽이 크지 않은 서비스라면 이 정도로 충분히 오래 버틸 수 있습니다. 그런데 어느 시점부터는 지금까지 배운 방식이 삐걱대기 시작합니다. 그 신호들을 짚고 이 책을 마무리하겠습니다.

서버 한 대로는 감당이 안 될 때

docker compose up 은 기본적으로 한 대의 서버 안에서 여러 컨테이너를 관리하는 도구입니다. 서버 한 대가 감당할 수 있는 트래픽을 넘어서면 서버를 여러 대로 늘려야 하는데, compose는 "이 서버 안에서" 라는 전제를 벗어나지 못합니다. 서버 3대에 컨테이너를 어떻게 나눠 배치할지, 한 대가 죽으면 그 위에 있던 컨테이너를 다른 서버로 어떻게 옮길지는 compose가 해줄 수 있는 일이 아닙니다.

배포 중 서비스가 끊기는 게 신경 쓰이기 시작할 때

지금까지 설명한 배포 방식(기존 컨테이너를 멈추고 새 컨테이너를 띄우는)은 그 사이에 짧은 공백이 생깁니다. 사용자가 몇 명 안 될 때는 티가 안 나지만, 트래픽이 꾸준히 들어오는 서비스라면 이 공백 동안 요청이 실패합니다. "새 버전을 올리는 동안 헌 버전이 계속 트래픽을 받다가, 새 버전이 준비된 다음에야 트래픽을 넘긴다"는 무중단 배포는 docker run 만으로는 직접 구현하기 번거롭습니다.

컨테이너가 죽었을 때 자동으로 되살리고 싶을 때

docker run --restart=always 로 같은 서버 안에서 재시작되게 할 수는 있습니다. 하지만 "몇 개의 인스턴스가 항상 떠 있어야 하는지", "그중 하나가 응답을 안 하면 트래픽에서 빼고 새 걸로 교체하는지"까지 관리하려면 지금 배운 도구 밖의 것이 필요합니다.

이럴 때 등장하는 게 오케스트레이션 도구입니다

Kubernetes, Nomad, Docker Swarm 같은 도구들이 이 문제를 다룹니다. 이름은 다양하지만 공통적으로 하려는 일은 비슷합니다.

flowchart TD
  D["Docker: 이미지 빌드, 컨테이너 하나를 어떻게 실행할지"] --> K["오케스트레이션: 컨테이너 여러 개를 여러 서버에 어떻게 배치·유지할지"]

• 여러 서버(노드)를 하나의 클러스터로 묶어서, "이 컨테이너를 3개 띄워라"고 선언하면 어느 서버에 배치할지는 알아서 정합니다.
• 컨테이너가 죽으면 감지해서 자동으로 다시 띄웁니다.
• 새 버전을 배포할 때 기존 인스턴스를 하나씩 순서대로 교체해서(rolling update) 트래픽 끊김을 최소화합니다.
• 트래픽 양에 따라 인스턴스 수를 자동으로 늘리거나 줄입니다(오토스케일링).

여기서 강조하고 싶은 건, 이 도구들이 Docker를 대체하는 게 아니라는 점입니다. Kubernetes 안에서도 결국 실행되는 단위는(containerd 등을 통한) 컨테이너이고, 그 컨테이너는 지금까지 배운 것과 같은 방식으로 만든 이미지에서 나옵니다. Dockerfile을 잘 쓰고, 이미지를 작게 만들고, 데이터를 볼륨으로 분리하는 이 책의 내용은 오케스트레이션 도구를 쓰더라도 그대로 필요합니다. 달라지는 건 "그 컨테이너를 누가, 어떻게 여러 서버에 걸쳐 관리하느냐"뿐입니다.

그래서 언제 넘어가야 하는가

정답은 없지만, 다음 신호들이 여러 개 겹치기 시작하면 고려해볼 시점입니다.

• 서버 한 대로는 트래픽을 감당하지 못해서, 이미 여러 대에 같은 서비스를 수동으로 복사해 돌리고 있다
• 배포할 때마다 몇 초에서 몇 분씩 서비스가 끊기는 게 실제로 사용자 불만으로 이어진다
• 서버가 몇 대인지, 뭐가 어디서 도는지 손으로 추적하기 버거워졌다
• 팀 규모가 커져서 "누가 뭘 배포했는지" 표준화된 방식이 필요해졌다

반대로 말하면, 개인 프로젝트나 사내 소규모 도구, 트래픽이 안정적으로 낮은 서비스라면 오케스트레이션 없이 이 책에서 다룬 Docker + compose 조합만으로 몇 년을 버티는 경우도 흔합니다. 오케스트레이션 도구는 그 자체로 배워야 할 게 상당히 많은 별도의 영역이고, 필요하지 않은데 미리 들여놓으면 복잡성만 얹는 꼴입니다. 필요해지면 그때 배우세요. 그리고 그때가 되어도, 지금 이 책에서 다진 Docker 기초는 그대로 쓸모가 있습니다.