오케스트레이션 춘추전국시대 — K8s, Docker Swarm, DC/OS 삼국지의 전말

지금은 클라우드 인프라를 논할 때 “쿠버네티스를 쓸까 말까”를 고민할 뿐, 쿠버네티스 외의 다른 오케스트레이터를 진지하게 고려하는 기업은 거의 없습니다.

하지만 불과 7~8년 전인 2015년부터 2018년 사이에는 IT 역사상 가장 치열했던 기술 주도권 싸움 중 하나인 ‘컨테이너 오케스트레이션 전쟁(Container Orchestration Wars)‘ 이 벌어지고 있었습니다.

당시 인프라 진영은 뚜렷한 개성을 가진 3대 세력으로 팽팽하게 갈려 있었습니다:

  1. 컨테이너의 창시자 도커가 이끄는 도커 스웜 (Docker Swarm)
  2. 트위터와 넷플릭스의 대규모 분산 환경에서 이미 검증되었던 거인 메소스 / DC/OS (Apache Mesos & DC/OS)
  3. 구글이 내부 비밀 병기였던 Borg의 철학을 계승해 갓 오픈소스로 내놓은 쿠버네티스 (Kubernetes)

도대체 그 시절에는 무슨 일이 있었고, 각 기술은 어떤 철학으로 무장했으며, 결국 왜 쿠버네티스가 압도적인 승리를 거두게 되었을까요?

1. 세 진영의 출사표와 기술 철학

① Docker Swarm: “우리가 컨테이너를 제일 잘 안다, 단순함이 곧 힘이다”

도커 사(Docker Inc.)의 전략은 명확했습니다. 전 세계 수백만 명의 개발자가 이미 docker run과 docker-compose 문법에 열광하고 있었습니다.

도커 스웜은 이 개발자 경험을 그대로 클러스터로 확장했습니다.

  • 설치의 극단적 단순성: 마스터 노드에서 docker swarm init을 치고, 워커 노드에서 출력된 토큰 명령어를 복사해 docker swarm join을 치면 단 1분 만에 수십 대의 노드가 하나의 클러스터로 묶였습니다.
  • 낮은 러닝 커브: 새로운 YAML 문법이나 개념을 배울 필요 없이, 평소 로컬에서 쓰던 docker-compose.yml 파일을 그대로 docker stack deploy로 배포하면 끝이었습니다.

개발자들에게 스웜은 압도적으로 매력적이었습니다. 복잡한 etcd 클러스터를 구축하고 TLS 인증서를 수동으로 발급해야 했던 초기 쿠버네티스에 비해, 스웜은 마법처럼 쉬웠습니다.

② Apache Mesos & DC/OS: “컨테이너만 돌릴 것인가? 데이터센터 전체를 하나의 컴퓨터로 만들자”

UC 버클리 AMPlab에서 탄생한 아파치 메소스(Apache Mesos)는 2010년대 초반 이미 실리콘밸리 초대형 기업들의 백본이었습니다. 트위터는 장애가 잦았던 고래 그림(“Fail Whale”)을 극복하기 위해 메소스 위로 전체 인프라를 이전했고, 애플은 음성인식 비서 시리(Siri)의 백엔드를 메소스 위에서 돌렸습니다.

메소스피어(Mesosphere)가 이를 상용화한 DC/OS(Data Center Operating System) 의 비전은 오케스트레이터 중 가장 웅장했습니다:

  • 2단계 스케줄링(Two-Level Scheduling): 메소스 마스터가 각 노드의 남은 리소스(CPU, 메모리)를 ‘오퍼(Resource Offer)’ 형태로 프레임워크에 던져주면, 상위 프레임워크가 이를 수락해 작업을 할당합니다.
  • 하이브리드 워크로드: DC/OS는 단순 웹 애플리케이션 컨테이너(Marathon)뿐만 아니라, 하둡(Hadoop), 아파치 스파크(Spark), 카프카(Kafka), 카산드라(Cassandra) 같은 대규모 빅데이터/스테이트풀 워크로드를 동일한 클러스터 풀 안에서 유연하게 공존 시킬 수 있는 유일한 대안이었습니다.

③ Kubernetes: “구글이 15년간 실패하며 배운 분산 시스템의 정수”

2014년 구글이 쿠버네티스를 처음 공개했을 때, 업계의 반응은 반신반의였습니다.

  • 설치는 지옥 같았고(The Hard Way),
  • 도커와 메소스에 비해 배워야 할 객체(Pod, Service, ReplicaSet, Ingress…)가 너무 많았으며,
  • 구글의 Go 언어 신생 프로젝트였기에 안정성에 의문을 제기하는 목소리도 컸습니다.

하지만 쿠버네티스에는 다른 두 진영이 갖지 못한 강력한 무기가 있었습니다. 바로 구글이 주간 수십억 개의 컨테이너를 굴리며 체득한 ‘Borg’의 아키텍처적 완성도 와 선언적 API 모델 이었습니다.

2. 전세가 역전된 3가지 결정적 분기점

초기에는 도커의 대중성을 등에 업은 스웜과, 대규모 검증을 마쳤던 DC/OS가 앞서나가는 듯 보였습니다. 하지만 2016~2017년을 기점으로 판세는 급격하게 쿠버네티스로 기울었습니다.

이유 1: 벤더 종속을 거부한 ‘CNCF’ 오픈 거버넌스의 힘

도커 사(Docker Inc.)는 영리 기업이었습니다. 도커는 스웜을 무기로 엔터프라이즈 오케스트레이션 시장을 독점하고 유료 라이선스를 팔고자 했습니다. 이는 엔터프라이즈 IT의 공룡들(IBM, Red Hat, Microsoft, Cisco 등)에게 큰 위협이었습니다.

구글은 완벽한 정치적·전략적 수를 두었습니다.

  • 구글은 쿠버네티스의 소유권을 독점하지 않고, 리눅스 재단 산하에 CNCF(Cloud Native Computing Foundation) 를 공동 설립하여 지적재산권을 기증했습니다.
  • 구글뿐만 아니라 레드햇(OpenShift의 기반을 K8s로 전면 전환), 마이크로소프트, IBM 등이 평등한 커뮤니티의 일원으로 참여할 수 있는 ‘중립 지대’를 열어준 것입니다.
  • 결과적으로 전 세계 수천 명의 엔지니어와 대기업들이 단일 기업의 제품인 스웜 대신, 공공재가 된 쿠버네티스에 기여하기 시작했습니다.

이유 2: 단순함의 한계 vs 확장성의 승리

도커 스웜의 최대 장점이었던 ‘단순함’은 복잡한 엔터프라이즈 환경에서 ‘한계’로 돌아왔습니다.

  • 실제 엔터프라이즈 서비스는 단순 무상태(Stateless) 웹 서버만 돌리지 않습니다.
  • 정교한 롤링 배포 정책, 세밀한 네트워크 격리(NetworkPolicy), 시크릿 암호화, 스토리지 볼륨 동적 프로비저닝, 가상 IP 기반 로드밸런싱 등 고도화된 기능이 필요했습니다.
  • 스웜은 이러한 복잡한 엔터프라이즈 요구를 감당하기에 구조가 너무 단순했습니다.

반면 쿠버네티스는 CRD(Custom Resource Definition) 와 Operator 패턴 을 도입했습니다:

“쿠버네티스 코어 코드를 수정하지 않고도, 누구나 자신만의 커스텀 리소스와 제어 루프를 API 서버에 플러그인할 수 있다.”

이 확장성 덕분에 프로메테우스(Prometheus), 이스티오(Istio), 아르고CD(ArgoCD) 같은 수많은 서드파티 프로젝트들이 쿠버네티스를 밑바탕 삼아 폭발적으로 쏟아져 나왔습니다.

이유 3: 클라우드 빅3의 백기 투항 (2017년 가을의 결정타)

2017년 10월, 덴마크 코펜하겐에서 열린 DockerCon 유럽에서 충격적인 발표가 있었습니다. 도커 사가 스스로 도커 엔터프라이즈 에디션(EE)에 쿠버네티스를 기본 지원하겠다고 공식 발표 한 것입니다. 사실상 스웜의 패배를 자인한 순간이었습니다.

이어서 마이크로소프트 애저(AKS), 그리고 2017년 11월 AWS가 re:Invent에서 자체 오케스트레이터(ECS)가 있음에도 Amazon EKS(Elastic Kubernetes Service) 를 발표하면서 전쟁은 공식적으로 종식되었습니다.

3. 삼국지 비교 요약

비교 항목KubernetesDocker SwarmApache Mesos / DC/OS
태생Google (Borg 후속작)Docker Inc.UC Berkeley / Mesosphere
운영 주체CNCF (중립적 오픈소스)Docker Inc. (단일 기업)Apache 재단 / Mesosphere
초기 설치 난이도매우 높음 (극악의 러닝 커브)매우 낮음 (swarm init 즉시 구동)높음 (인프라 구성 무거움)
핵심 강점선언적 API, 자가 치유, 무한한 확장성(CRD)친숙한 CLI, Compose 재사용, 단순함대규모 분산 자원 풀링, 빅데이터 워크로드 공존
패배/쇠퇴 원인-엔터프라이즈 복잡도 미지원, 생태계 폐쇄성컨테이너 중심 흐름 적응 실패, 높은 운영 오버헤드
현재 상태클라우드 네이티브의 절대적 표준도커 엔진 내에 유지되나 신규 도입 드묾2021년 프로젝트 은퇴(Attic), D2iQ 피벗 후 인수

4. 오케스트레이션 전쟁이 남긴 교훈

컨테이너 삼국지는 기술 생태계에 몇 가지 중요한 교훈을 남겼습니다:

  1. 개발자 UX의 쉬움만으로는 인프라 전쟁에서 이길 수 없다: 사용하기 쉬운 도구(Swarm)는 초기 채택률을 폭발시킬 수 있지만, 결국 인프라의 최종 선택권은 대규모 장애와 복잡한 비즈니스 요구사항을 감당해야 하는 플랫폼/운영 엔지니어들에게 있습니다.
  2. 독점하려는 자는 생태계에 패배한다: 도커 사는 컨테이너 플랫폼 전체를 수직 통합하여 독점하려다 경쟁자들을 결집시켰고, 구글은 코어 프로젝트를 오픈 재단(CNCF)에 헌납함으로써 전 세계 테크 기업들을 아군으로 만들었습니다.
  3. 확장성(Extensibility)이 제품의 수명을 결정한다: 코어를 가볍게 유지하고 외부 생태계가 자유롭게 확장할 수 있는 인터페이스(CRI, CNI, CSI, CRD)를 제공한 쿠버네티스는 단순한 오케스트레이터를 넘어 ‘클라우드의 운영체제’로 진화할 수 있었습니다.

오케스트레이션 전쟁의 역사는 단순한 기술적 성능 경쟁이 아닌, 개발자 친화성, 엔터프라이즈의 복잡한 요구사항, 그리고 오픈 거버넌스의 신뢰가 어떻게 기술 표준을 만들어내는지를 보여준 대표적인 사례입니다.

컨테이너와 인프라 이야기