쿠버네티스는 어떻게 왕좌를 차지했나? 도커 몰락과 컨테이너 기술 30년 대격변사

프롤로그: 왕좌를 둘러싼 실리콘밸리의 드라마

2013년, 작은 스타트업 dotCloud의 솔로몬 하익스(Solomon Hykes)가 발표한 오픈소스 프로젝트 하나가 IT 세계를 뒤흔들었습니다. 그 이름은 바로 도커(Docker). 하지만 불과 10년 후인 오늘, 도커는 더 이상 컨테이너 세계의 절대 강자가 아닙니다. 그 자리를 차지한 것은 구글에서 나온 쿠버네티스(Kubernetes)입니다.

어떻게 이런 일이 벌어진 걸까요? 이 글에서는 컨테이너 기술의 30년 역사를 되짚으며, 도커의 급부상과 몰락, 그리고 쿠버네티스의 승리까지 흥미진진한 이야기를 들려드리겠습니다.

1장: 컨테이너 기술의 선사시대 (1995-2012)

가상화의 시작: "한 대의 서버에 여러 개의 서버를?"

1990년대 중반, 서버 하나에 애플리케이션 하나만 돌리던 시대였습니다.

비효율의 극치였죠. 서버 활용률은 고작 5-15%에 불과했습니다. 이때 등장한 것이 가상화 기술입니다.

VMware가 선두주자였고, 하이퍼바이저를 통해 하나의 물리 서버에서 여러 개의 가상 머신을 돌릴 수 있게 되었습니다. 하지만 문제가 있었습니다. 각 가상 머신마다 완전한 운영체제를 설치해야 했고, 이는 엄청난 자원 낭비였습니다.

컨테이너의 조상들: chroot, FreeBSD Jails, Solaris Zones

사실 컨테이너 개념은 도커보다 훨씬 오래됐습니다:

• chroot (1979): 유닉스에서 프로세스의 루트 디렉토리를 격리
• FreeBSD Jails (2000): 프로세스 격리를 한 단계 발전시킴
• Solaris Zones (2004): 운영체제 수준의 가상화 제공

하지만 이들은 모두 특정 운영체제에 종속적이었고, 사용하기도 복잡했습니다.

Linux의 반격: LXC와 cgroups

2008년, 리눅스 진영에서 LXC(Linux Containers)가 등장했습니다.

리눅스 커널의 cgroups와 namespaces 기능을 활용해 프로세스를 격리했죠.

하지만 여전히 일반 개발자들이 사용하기엔 너무 복잡했습니다.

2장: 도커의 등장과 세상을 바꾼 혁신 (2013-2017)

"Build, Ship, Run" - 도커가 제시한 새로운 패러다임

2013년 3월, dotCloud의 솔로몬 하익스가 PyCon에서 도커를 발표했습니다. 도커는 기존 컨테이너 기술과 무엇이 달랐을까요?

도커란 무엇인가?

도커(Docker)는 애플리케이션을 컨테이너라는 표준화된 단위로 패키징하여 어디서든 동일하게 실행할 수 있게 해주는 플랫폼입니다.

쉽게 말해, 도커는 "애플리케이션 배송용 표준 컨테이너"를 만든 것입니다. 마치 물류업계에서 표준 컨테이너가 세상을 바꾼 것처럼 말이죠.

도커의 혁신적 요소들

1. Dockerfile: 코드로 인프라를 정의하는 Infrastructure as Code의 시초
2. Docker Hub: GitHub처럼 컨테이너 이미지를 공유하는 레지스트리
3. 단순한 CLI: docker run, docker build 같은 직관적인 명령어
4. 레이어드 파일시스템: 이미지를 효율적으로 관리하는 방식

도커의 전성시대: "모든 것을 컨테이너로!"

도커는 개발자들의 마음을 사로잡았습니다:

• "내 컴퓨터에서는 되는데..." 문제 해결
• 마이크로서비스 아키텍처의 핵심 인프라
• DevOps 문화 확산의 촉매
• 클라우드 네이티브 애플리케이션의 기반

2014년부터 2017년까지 도커는 승승장구했습니다.

Docker Inc.는 수억 달러의 투자를 받았고, 모든 대기업이 도커 도입을 검토했습니다.

3장: 성장의 그림자 - 도커의 한계가 드러나다 (2015-2018)

문제 1: 프로덕션 환경의 복잡성

도커는 개발 환경에서는 완벽했지만, 프로덕션에서는 문제가 많았습니다:

• 컨테이너가 죽으면 어떻게 할까? (자동 재시작)
• 여러 서버에 컨테이너를 어떻게 배포할까? (스케줄링)
• 컨테이너들 간의 통신은? (네트워킹)
• 부하가 증가하면 자동으로 확장할 수 있을까? (오토스케일링)

문제 2: 도커 스웜의 한계

도커는 이런 문제들을 해결하기 위해 도커 스웜(Docker Swarm)을 출시했습니다.

하지만 너무 단순했습니다. 기업 환경에서 필요한 고급 기능들이 부족했죠.

문제 3: 생태계 파편화

더 심각한 문제는 도커를 둘러싼 생태계가 파편화되기 시작했다는 것입니다:

• CoreOS는 rkt 컨테이너 런타임을 개발
• 레드햇은 자체 컨테이너 솔루션 추진
• 아마존, 마이크로소프트, 구글은 각자의 컨테이너 서비스 출시

4장: 구글의 비밀병기 - 쿠버네티스의 등장 (2014-2016)

Borg의 후계자

구글은 이미 15년 전부터 컨테이너를 사용하고 있었습니다.

구글의 모든 서비스(검색, Gmail, YouTube 등)는 Borg라는 내부 컨테이너 오케스트레이션 시스템 위에서 돌아갔습니다. 2014년, 구글은 Borg의 경험을 바탕으로 쿠버네티스(Kubernetes)를 오픈소스로 공개했습니다.

쿠버네티스란 무엇인가?

쿠버네티스(K8s)는 컨테이너화된 애플리케이션의 배포, 확장, 관리를 자동화하는 오픈소스 플랫폼입니다.

쉽게 말해, 쿠버네티스는 "컨테이너들의 지휘관"입니다.

수백, 수천 개의 컨테이너를 효율적으로 관리하고 운영할 수 있게 해줍니다.

쿠버네티스의 핵심 철학: 선언적 API

쿠버네티스의 가장 혁신적인 부분은 선언적 API였습니다:

# "3개의 웹서버를 실행하고 싶다"고 선언하면
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-server
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
      - name: web
        image: nginx:1.20

쿠버네티스가 알아서 3개의 컨테이너를 실행하고, 하나가 죽으면 자동으로 새로 만들어줍니다.

5장: 도커 vs 쿠버네티스 - 핵심 차이점 비교

구분	도커 (Docker)	쿠버네티스 (Kubernetes)
주요 역할	컨테이너 생성 및 실행	컨테이너 오케스트레이션
적용 범위	단일 호스트	클러스터 (여러 서버)
자동 복구	수동 개입 필요	자동 재시작, Self-healing
확장성	수동 스케일링	자동 스케일링 지원
네트워킹	기본적인 컨테이너 네트워크	고급 네트워킹 (Service Mesh 등)
설정 관리	환경변수, 볼륨	ConfigMap, Secret
로드밸런싱	별도 구성 필요	내장 Service 기능
학습 곡선	비교적 쉬움	매우 가파름
적합한 환경	개발, 소규모 배포	대규모 프로덕션 환경

6장: 쿠버네티스의 대승리 (2017-2021)

CNCF와 생태계 구축

2015년, 구글은 쿠버네티스를 Cloud Native Computing Foundation(CNCF)에 기부했습니다. 이는 천재적인 전략이었습니다:

• 중립성 확보: 구글만의 프로젝트가 아닌 업계 공통 표준으로 포지셔닝
• 생태계 구축: 수백 개의 관련 프로젝트들이 CNCF 우산 아래 모임
• 기업 지원: 마이크로소프트, 아마존, IBM 등 주요 기업들이 참여

클라우드 벤더들의 선택

주요 클라우드 벤더들이 관리형 쿠버네티스 서비스를 출시했습니다:

• Google GKE (2015)
• Azure AKS (2017)
• AWS EKS (2018)

이는 쿠버네티스를 사실상의 표준으로 만드는 결정적 계기가 되었습니다.

도커의 실수들

반면 도커는 몇 가지 전략적 실수를 범했습니다:

1. 기업용 솔루션에 집중: 개발자 커뮤니티와 거리를 둠
2. Docker EE 유료화: 오픈소스 생태계에서 이탈
3. 늦은 쿠버네티스 지원: 자체 스웜 솔루션 고집

7장: 도커의 몰락과 분할 (2019-2020)

Moby 프로젝트와 혼란

2017년, 도커는 오픈소스 부분을 Moby 프로젝트로 분리했습니다.

하지만 이는 커뮤니티에 혼란만 가중시켰습니다. 개발자들은 "도커가 뭐고 Moby가 뭔지" 이해하기 어려워했습니다.

쿠버네티스의 Docker 의존성 제거

결정타는 2020년 쿠버네티스 1.20 버전에서 나왔습니다.

쿠버네티스는 "dockershim 지원 중단"을 발표했습니다.

즉, 쿠버네티스에서 도커 런타임을 직접 지원하지 않겠다는 뜻이었습니다.

대신 containerd와 CRI-O 같은 경량화된 컨테이너 런타임을 사용하기 시작했습니다.

Docker Inc.의 매각

2019년, Docker Inc.는 엔터프라이즈 사업부를 마이크로포커스에 매각했습니다.

2021년에는 다시 개발자 도구에 집중하기 위해 사업을 재편했습니다.

8장: 쿠버네티스 시대의 개막 (2021-현재)

새로운 표준의 등장

오늘날 쿠버네티스는 컨테이너 오케스트레이션의 사실상 표준이 되었습니다:

• Fortune 500 기업의 90% 이상이 쿠버네티스 사용
• 모든 주요 클라우드 제공업체가 관리형 쿠버네티스 서비스 제공
• CNCF 생태계에 800개 이상의 프로젝트 참여

클라우드 네이티브의 새로운 패러다임

쿠버네티스는 단순한 컨테이너 오케스트레이션을 넘어 클라우드 네이티브 플랫폼이 되었습니다:

• Service Mesh (Istio, Linkerd)
• Serverless (Knative)
• CI/CD (Tekton, Argo)
• Monitoring (Prometheus, Grafana)
• Security (Falco, OPA)

도커의 새로운 정체성

도커는 이제 개발자 도구로 정체성을 바꿨습니다:

• Docker Desktop: 로컬 개발 환경
• Docker Hub: 컨테이너 이미지 레지스트리
• Docker Compose: 멀티 컨테이너 애플리케이션 정의

9장: 미래 전망 - 다음 10년은?

쿠버네티스의 도전과제

쿠버네티스가 승리했지만, 여전히 해결해야 할 문제들이 있습니다:

1. 복잡성: 여전히 학습 곡선이 가파름
2. 보안: 기본 설정으로는 보안이 취약
3. 비용: 클라우드 비용 최적화의 어려움
4. 인재 부족: 쿠버네티스 전문가 부족

새로운 경쟁자들

• Serverless: AWS Lambda, Google Cloud Functions
• WebAssembly: 브라우저를 넘어 서버 환경으로 확장
• Edge Computing: IoT와 5G 시대의 새로운 요구사항

Platform Engineering의 부상

최근에는 Platform Engineering이라는 새로운 트렌드가 나타나고 있습니다.

복잡한 쿠버네티스를 개발자들이 쉽게 사용할 수 있도록 내부 플랫폼을 구축하는 것입니다.

에필로그: 기술 패권의 교훈

왜 쿠버네티스가 승리했나?

1. 올바른 문제 해결: 단순한 컨테이너 실행이 아닌 대규모 운영 문제
2. 강력한 후원자: 구글의 15년 경험과 투자
3. 오픈소스 전략: 벤더 록인 없는 중립적 플랫폼
4. 생태계 구축: CNCF를 통한 협업과 표준화
5. 클라우드 시대: 클라우드 네이티브 시대의 요구사항과 완벽 매치

도커가 몰락한 이유

1. 단일 기업 의존: 생태계보다 회사 이익 우선
2. 기업화 실패: 오픈소스와 상업화의 균형 실패
3. 시장 오판: 개발자 도구에서 플랫폼으로의 전환 시기 놓침
4. 생태계 분열: 경쟁자들과의 협력 부족

우리가 배운 교훈

기술의 세계에서 영원한 승자는 없습니다. 오늘의 강자가 내일의 몰락자가 될 수 있고, 작은 혁신이 거대한 변화를 만들 수 있습니다.

중요한 것은:

• 올바른 문제를 해결하는가?
• 생태계를 구축할 수 있는가?
• 변화하는 시장의 요구를 읽을 수 있는가?
• 커뮤니티와 함께 성장할 수 있는가?

---

30년의 컨테이너 기술 역사를 통해 우리는 하나의 진리를 확인했습니다.

기술의 가치는 그 자체가 아니라, 실제 문제를 얼마나 잘 해결하느냐에 달려 있다는 것입니다.

도커는 개발자의 문제를 해결했고, 쿠버네티스는 운영자의 문제를 해결했습니다. 그리고 시장은 더 큰 문제를 해결하는 쪽을 선택했습니다.

다음 10년, 또 어떤 혁신이 우리를 기다리고 있을까요? 🚀