구글이 만든 세계 최강의 컨테이너 관리 시스템 — Borg에서 Kubernetes까지의 15년 여정 🚀

Kubernetes는 어느 날 갑자기 등장한 게 아니다.
구글이 수십억 개의 컨테이너를 굴리며 피땀 흘려 쌓은 15년의 실전 노하우가 녹아 있다.

---

🎯 이 글에서 다루는 것

• 구글 내부 클러스터 관리 시스템 Borg의 탄생 배경과 핵심 철학
• Borg의 한계를 극복하기 위해 설계된 Omega의 실험적 시도
• 오픈소스로 세상에 공개된 Kubernetes가 어떻게 클라우드 표준이 됐는지
• 세 시스템의 핵심 차이점 비교

---

📌 도입 / 배경 — 구글은 왜 이런 걸 만들었나?

지금 우리가 쓰는 Gmail, YouTube, Google Search. 이 서비스들이 동시에 수억 명의 요청을 처리한다는 걸 생각해 본 적 있으신가요?

2000년대 초반 구글은 엄청난 문제에 직면합니다. 서비스가 폭발적으로 늘어나는데, 수천 대의 서버를 손으로 일일이 관리하는 건 물리적으로 불가능해진 거죠. 누군가 실수로 서버 설정을 잘못 건드리면 장애가 터지고, 자원은 낭비되고, 엔지니어들은 밤새 장애 대응에 시달렸습니다.

이 고통에서 탄생한 것이 바로 Borg → Omega → Kubernetes로 이어지는 구글의 클러스터 관리 시스템 삼부작입니다.

💡 클러스터(Cluster)란? 여러 대의 서버(노드)를 하나의 컴퓨팅 자원 풀로 묶어놓은 것. 개별 서버를 관리하는 게 아니라 클러스터 전체를 하나의 거대한 컴퓨터처럼 다루는 개념입니다.

---

🔍 1세대: Borg — "구글의 비밀 병기" (2003년~)

Borg는 무엇인가?

Borg는 구글이 2003년부터 내부적으로 개발해서 운영한 대규모 클러스터 관리 시스템입니다. 무려 수십만 개의 작업(Job) 을 수천 대의 머신에 자동으로 배포하고 관리했습니다.

 

이름의 유래는 스타트렉의 외계 종족 'Borg' 에서 왔습니다. 개별 존재를 집합체(Collective)로 흡수하는 Borg처럼, 수천 대의 개별 서버를 하나의 거대한 집합체로 운영하겠다는 철학이 담겨 있습니다.

 

Borg의 핵심 개념

Borg는 작업을 두 가지 유형으로 분류합니다:

• Prod (Production): 지연에 민감한 서비스. Gmail, Search 같은 실시간 서비스. 항상 우선순위 최상위.
• Non-Prod (Batch): 대용량 데이터 처리 같은 배치 작업. 우선순위 낮음.

이 분류가 핵심이었습니다. Borg는 같은 물리 서버에 Prod와 Non-Prod 작업을 함께 올려서(Bin Packing) 자원 낭비를 최소화했습니다. Prod 작업이 안 쓰는 CPU를 Batch 작업이 몰래 쓰다가, Prod가 필요하면 즉시 자리를 비워주는 방식입니다.

Borg가 해결한 것들

문제	Borg의 해결책
서버 수천 대 수동 관리	중앙 스케줄러가 자동 배치
서비스 장애 시 수동 복구	자동 재시작, 재배치
자원 낭비	Prod/Batch 혼합 배치로 활용률 극대화
배포 자동화 부재	Job 정의 파일로 선언적 배포

Borg의 아키텍처

Borg는 BorgMaster(중앙 컨트롤 플레인)와 Borglet(각 노드의 에이전트) 로 구성됩니다.

[BorgMaster] ─── 스케줄링 결정
     │
     ├── [Borglet] ─ 서버 노드 1
     ├── [Borglet] ─ 서버 노드 2
     └── [Borglet] ─ 서버 노드 N

 

BorgMaster가 "이 작업은 저 서버에서 실행해"라고 지시하면, Borglet이 실제로 실행하고 상태를 보고합니다.

 

Borg의 한계

그런데 Borg에는 구조적인 문제가 있었습니다:

1. 모놀리식 BorgMaster: 모든 결정을 BorgMaster 하나가 내립니다. 시스템이 커질수록 병목이 심해집니다.
2. Job 중심 설계: Borg의 기본 단위는 'Job'이고 그 안에 'Task'가 있습니다. 작업 간 관계를 표현하기가 어색했습니다.
3. IP 주소 공유: 같은 서버의 Task들이 IP를 공유해서 포트 충돌이 잦았습니다.
4. 레거시 누적: 오랫동안 내부에서만 쓰이다 보니 하위 호환성 때문에 구조 개선이 힘들었습니다.

---

🔍 2세대: Omega — "백지에서 다시 설계하기" (2008년~)

Omega의 탄생 목적

Borg의 한계를 느낀 구글 엔지니어들은 2008년경 Omega라는 실험적 프로젝트를 시작합니다. "Borg를 고치는 게 아니라, 처음부터 올바르게 설계하면 어떨까?"라는 질문에서 출발했습니다.

Omega는 실제로 구글 내부에서 운영됐지만, Borg를 완전히 대체하지는 못했습니다. Borg는 너무 깊이 구글 인프라에 뿌리를 내리고 있었기 때문입니다.

 

Omega의 혁신: 공유 상태(Shared State) 아키텍처

Borg의 가장 큰 문제는 중앙화된 스케줄러였습니다. BorgMaster 하나가 모든 결정을 내리니 확장성에 한계가 생겼죠.

Omega는 이를 공유 상태(Shared State) 방식으로 해결했습니다:

기존 Borg:
[BorgMaster] → 모든 결정 → [Borglet들]
(병목 발생)

Omega:
[Scheduler A] ──┐
[Scheduler B] ──┼─→ [공유 상태 저장소] → [노드들]
[Scheduler C] ──┘
(낙관적 동시성 제어)

 

여러 스케줄러가 동시에 클러스터 상태를 보고 독립적으로 스케줄링 결정을 내립니다. 충돌이 생기면 낙관적 동시성 제어(Optimistic Concurrency Control)로 해결합니다.

💡 낙관적 동시성 제어: "충돌이 드물 거라 가정하고 일단 작업을 진행, 나중에 충돌이 확인되면 재시도"하는 방식. 비관적 방식(락을 먼저 걸고 시작)보다 처리량이 높습니다.

 

Omega가 남긴 유산

 

Omega 자체는 Borg를 대체하지 못했지만, 핵심 아이디어들은 이후 Kubernetes에 큰 영향을 줬습니다:

• 리소스를 일급 객체로 취급: CPU, 메모리를 구체적으로 명시하고 추적
• 스케줄러 분리: 단일 스케줄러 의존성 탈피
• 선언적 API 강화: 원하는 상태를 선언하면 시스템이 맞춰가는 방식

---

🔍 3세대: Kubernetes — "세상을 바꾼 오픈소스" (2014년~)

왜 구글은 공개했나?

2013년 Docker가 등장하면서 컨테이너 기술이 대중화되기 시작했습니다. 구글은 깨달았습니다. "우리가 10년 넘게 쌓은 노하우를 오픈소스로 공개하면, 클라우드 생태계 표준을 우리가 만들 수 있다."

 

2014년 6월, 구글은 Kubernetes(쿠버네티스)를 오픈소스로 공개합니다. 그리스어로 '조타수(배를 조종하는 사람)'라는 뜻입니다. 로고가 배의 키(Helm)인 것도 이 때문입니다.

 

Borg에서 배운 교훈을 Kubernetes에 반영하다

구글 엔지니어들은 2016년 발표한 논문 "Borg, Omega, Kubernetes"에서 Borg 운영 경험이 Kubernetes 설계에 어떻게 반영됐는지 상세히 밝혔습니다:

 

🔴 Borg의 실수 → Kubernetes의 해결책

Borg의 문제	Kubernetes의 해결
Job/Task 중심 구조, 관계 표현 어려움	Pod 개념 도입. 컨테이너 묶음으로 단위 재정의
Task들이 IP 공유, 포트 충돌	Pod마다 고유 IP 부여
모놀리식 BorgMaster	분리된 컴포넌트 (API Server, Scheduler, Controller Manager)
내부 전용 설계	오픈 API 중심, 확장 가능한 플러그인 구조

 

Kubernetes의 핵심 아키텍처

[Control Plane]
├── API Server      ← 모든 요청의 관문
├── Scheduler       ← Pod를 어느 노드에 배치할지 결정
├── Controller Mgr  ← 현재 상태를 원하는 상태로 유지
└── etcd            ← 클러스터 전체 상태 저장 (분산 KV 저장소)

[Worker Nodes]
├── kubelet         ← Borglet과 동일한 역할, 컨테이너 실행·관리
├── kube-proxy      ← 네트워크 규칙 관리
└── Container Runtime (Docker, containerd 등)

 

선언적 API — Kubernetes의 철학

 

Kubernetes의 가장 강력한 철학은 선언적(Declarative) 관리입니다.

# 원하는 상태를 선언한다
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-webserver
spec:
  replicas: 3          # 항상 3개를 실행해줘
  selector:
    matchLabels:
      app: webserver
  template:
    metadata:
      labels:
        app: webserver
    spec:
      containers:
      - name: nginx
        image: nginx:1.25
        resources:
          requests:
            cpu: "250m"      # 0.25 CPU 요청
            memory: "128Mi"  # 128MB 메모리 요청
          limits:
            cpu: "500m"      # 최대 0.5 CPU
            memory: "256Mi"  # 최대 256MB

 

이 YAML을 적용하면 Kubernetes는 알아서 3개의 nginx Pod를 실행하고, 하나가 죽으면 자동으로 복구합니다. 엔지니어가 "어떻게"가 아닌 "무엇을" 원하는지만 선언하면 됩니다.

 

Kubernetes가 만든 생태계

Kubernetes가 진정으로 위대한 이유는 단순히 기술 자체가 아닙니다. 생태계를 만들었습니다.

• 2015년: CNCF(Cloud Native Computing Foundation) 설립. 구글이 Kubernetes를 기부.
• 2016년: Helm(패키지 관리자), 각 클라우드 벤더의 관리형 서비스(GKE, AKS, EKS) 등장
• 2017년: Docker Swarm, Mesos 등 경쟁자들이 Kubernetes를 사실상 표준으로 인정
• 2018년 이후: Service Mesh(Istio), GitOps(ArgoCD), 서버리스(Knative) 등 수백 개의 도구가 Kubernetes 위에서 동작

---

⚠️ 주의사항 / 흔한 실수

1. Kubernetes가 Borg의 오픈소스 버전은 아닙니다 🚫 Kubernetes는 Borg의 교훈을 바탕으로 처음부터 다시 설계한 시스템입니다. Borg의 코드를 그대로 오픈소스화한 게 아닙니다.

2. Omega도 Borg를 대체하지 못했습니다 🚫 구글 내부에서 Borg와 Omega, Kubernetes가 동시에 운영됩니다. Borg는 지금도 구글의 핵심 인프라를 지탱하고 있습니다.

3. Kubernetes = 컨테이너 오케스트레이션 그 이상 ✅ 많은 분들이 "도커 여러 개 관리하는 도구"로만 이해하는데, Kubernetes는 클라우드 네이티브 인프라 전체를 선언적으로 관리하는 플랫폼입니다. 네트워크, 스토리지, 보안 정책, 서비스 디스커버리까지 아우릅니다.

---

✅ 정리 / 마무리

시스템	시기	공개 여부	핵심 혁신	한계
Borg	2003~	내부 전용	대규모 자동화, Prod/Batch 혼합	모놀리식, 확장성 한계
Omega	2008~	내부 전용	공유 상태, 다중 스케줄러	Borg 대체 실패
Kubernetes	2014~	오픈소스	선언적 API, 플러그인 생태계	러닝 커브 높음

 

구글의 15년 여정은 단순한 기술 진화가 아닙니다. 수십억 개의 컨테이너를 운영하며 배운 고통스러운 교훈이 Kubernetes라는 형태로 세상에 공개된 것입니다.

 

지금 여러분이 kubectl apply -f deployment.yaml 한 줄을 실행할 때, 그 뒤에는 구글 엔지니어들이 20년에 걸쳐 쌓아온 지혜가 작동하고 있습니다. 🚀

 

다음 단계로는 Kubernetes의 스케줄링 메커니즘, etcd의 Raft 합의 알고리즘, 그리고 Service Mesh(Istio) 를 공부하시면 이 생태계의 깊이를 더 잘 이해하실 수 있습니다.