View
출처: Business Insider
쿠버네티스를 사용하면서 이것을 도대체 누가 왜 만들었는지 생각해본 적 있는가? 그저 구글이 만들었다는 정도만 알고 넘어가는 경우가 대부분이다. 다만 쿠버네티스 개발자가 정확히 누구인지, 왜 하필 2014년에 등장했는지 알고 나면 k8s가 왜 이렇게 복잡하고 추상적인지 납득이 된다.
결론부터 말하면 쿠버네티스는 구글이 10년 넘게 내부에서 운영해온 Borg(보그)라는 시스템의 오픈소스 버전이다. Docker 열풍이 터진 직후 구글 엔지니어 3명 — Joe Beda, Brendan Burns, Craig McLuckie — 이 회사를 설득하여 2014년 6월에 공개한 것이다. 이 글에서는 이 3인방이 누구이며 어떤 배경에서 k8s가 세상에 나왔는지 살펴본다. Borg 계보부터 이름의 유래, 그리고 개발자들의 현재 근황까지 정리한다.
쿠버네티스를 만든 개발자 3인방은 누구인가
쿠버네티스 창시자로 공식적으로 거론되는 사람은 Joe Beda, Brendan Burns, Craig McLuckie 3명이다. 이 3인방이 구글 내부에서 의기투합하여 프로젝트를 시작했고, 그 뒤로 Brian Grant, Tim Hockin 같은 핵심 엔지니어들이 합류하면서 지금의 k8s가 되었다.
Joe Beda — Google Compute Engine 공동 창립 엔지니어
Joe Beda는 원래 마이크로소프트에서 Internet Explorer와 Windows Presentation Foundation(WPF)을 개발하던 엔지니어이다. 이후 2008년경 구글로 이직하여 Google Compute Engine(GCE)을 공동 창립했다. GCE는 구글판 AWS EC2라고 보면 된다.
구글 내부에서 Borg를 직접 다뤄본 경험이 있었고, 외부 고객에게 클라우드 인프라를 판매하려다 보니 "우리 내부에서 쓰는 수준은 돼야 하는데"라는 갭을 체감하게 된다. 이것이 k8s 시작의 결정적 모티브 중 하나이다.
Brendan Burns — 박사 후 구글에서 검색 인프라 담당
Brendan Burns는 매사추세츠 대학에서 컴퓨터 과학 박사를 받고 2011년경 구글에 합류했다. 구글에서는 검색 인프라를 맡았으며, 대규모 분산 시스템을 운영한 경험이 풍부한 엔지니어이다.
Brendan은 3명 중 가장 "엔지니어다운 엔지니어" 포지션이었으며, 초기 설계에서 기술적 디테일을 책임진 인물이다. 파드(Pod), 레플리카셋, 컨트롤러 같은 핵심 추상화를 설계하는 데 큰 역할을 했다.
Craig McLuckie — 오픈소스화를 실제로 밀어붙인 제품 매니저
Craig McLuckie는 구글 Cloud Platform의 제품 매니저(PM)였다. 엔지니어가 아니라 PM이다. 다만 이것이 중요하다. 엔지니어 두 명이 아무리 "Borg 오픈소스 버전을 만들자"고 해도 구글 경영진을 설득하는 것은 다른 문제이다.
Craig가 한 일은 "Borg는 구글의 경쟁력인데 왜 이것을 밖에 공개하느냐"는 내부 반대를 비즈니스 논리로 돌파한 것이다. "AWS가 이미 클라우드 시장을 장악하고 있는데 지금 움직이지 않으면 영원히 2등이다"가 그의 핵심 주장이었다. 결국 이 설득이 통하여 프로젝트가 세상에 나올 수 있었다.
숨은 MVP — Brian Grant와 Tim Hockin
공식 창시자 3인방 외에도 반드시 언급해야 하는 인물들이 있다.
Brian Grant는 Borg 팀 출신으로, k8s 초기 API 설계와 아키텍처 패턴 상당 부분을 책임진 인물이다. 지금 사용되고 있는 apiVersion, kind, spec, status 같은 선언형 스키마가 이 사람의 작품이다.
Tim Hockin은 구글에서 리눅스 커널의 cgroups에 직접 기여한 인물이다. cgroups란 무엇인가? 도커든 k8s든 컨테이너 격리에 사용되는 바로 그 리눅스 기능이다. 쿠버네티스 초기에 네트워킹(CNI 스펙 영향)과 노드 레벨 런타임을 설계했다. 지금도 쿠버네티스 프로젝트 공식 스티어링 커미티 멤버로 활동 중이다.
쿠버네티스가 탄생한 배경 — 왜 구글이 갑자기 움직였나
개발자 3인방만 있었다고 프로젝트가 시작된 것은 아니다. 타이밍이 맞아떨어진 것이다. 2013년 도커의 등장이 결정적 트리거였다.
출처: blog.siner.io
2013년 도커 열풍이 판을 뒤집다
2013년 3월 dotCloud라는 회사가 내부 도구였던 Docker를 오픈소스로 공개한다. 그 뒤로 개발자 생태계가 뒤집어진다. 컨테이너라는 개념 자체는 원래 존재했지만(LXC, cgroups 등), Docker가 이를 정말 쉽게 사용할 수 있게 포장하여 내놓은 것이다.
문제는 Docker 하나만으로는 여러 서버에 수백 개의 컨테이너를 운영하는 것을 관리할 수 없다는 점이다. 이것을 해주는 것이 바로 "컨테이너 오케스트레이션"이다. 이 빈 자리를 누가 차지할지가 2013~2014년 테크 업계의 핵심 관전 포인트였다.
구글은 이미 10년 전부터 컨테이너를 운영하고 있었다
사실 구글 내부에서는 2003~2004년부터 Borg라는 클러스터 매니저를 만들어 검색, Gmail, 유튜브 같은 서비스 전부를 컨테이너로 운영하고 있었다. 도커가 세상에 등장했을 때 구글 엔지니어들의 반응이 "아 이거 우리 10년 전부터 쓰던 건데?"였다는 말이 괜히 나온 것이 아니다.
이것이 무슨 뜻인가? 경쟁사들이 도커를 두고 허둥댈 때 구글은 이미 프로덕션에서 10년간 검증된 오케스트레이션 노하우를 보유하고 있었다는 의미이다. 다만 이것을 Borg 그대로 공개할 수는 없었다. Borg는 구글 인프라에 너무 밀착되어 있었고, 코드 또한 회사 기밀이었다.
"AWS한테 다 뺏기기 전에" — 비즈니스 동기
솔직하게 말하면 구글이 k8s를 오픈소스로 공개한 것은 AWS가 두려웠기 때문이다. 2013년 당시 AWS는 이미 클라우드 시장을 압도적으로 장악하고 있었고, Azure가 바짝 쫓아오고 있었다. 구글 클라우드는 한참 3등이었다.
이 상황에서 "업계 표준 오케스트레이션 도구"를 구글이 무료로 공개하면 어떻게 되는가? 개발자들이 k8s 위에서 앱을 작성하면, 그 앱은 AWS, Azure, GCP 어디서든 실행할 수 있게 된다. 즉 클라우드 종속(vendor lock-in)이 깨진다. AWS 입장에서는 자사 독자 서비스(ECS 같은 것)에 묶어두고 싶었겠지만 k8s가 표준이 되면 그것이 불가능해진다.
구글은 "어차피 클라우드 1등을 못할 거라면 판을 깨자"라는 전략으로 간 것이다. 결과적으로 이 전략은 대성공이었다. 지금 k8s 없이는 클라우드 네이티브 이야기 자체가 성립하지 않는다.
쿠버네티스 역사의 뿌리 — Borg에서 Omega를 거쳐 k8s까지 계보 정리
쿠버네티스 탄생 배경을 제대로 이해하려면 Borg의 가계도를 알아야 한다. Kubernetes는 Borg의 손자 격이다.
Borg란 무엇인가 — 구글 내부 클러스터 매니저
Borg는 구글이 2003~2004년부터 개발한 내부 클러스터 관리 시스템이다. 수천 대의 서버를 하나의 거대한 컴퓨팅 풀로 묶어, 그 위에서 실행되는 모든 작업을 스케줄링하고 관리한다. 검색, 유튜브, Gmail, 지도 전부 Borg 위에서 구동된다.
Borg에 대한 기술적 디테일은 2015년 EuroSys 학회에서 발표된 "Large-scale cluster management at Google with Borg" 논문(research.google/pubs/pub43438)에서 처음 공개되었다. 이 논문이 k8s 설계를 이해하는 데 가장 중요한 레퍼런스이다.
Borg의 핵심 개념은 다음과 같다:
- Task: 실행 단위 (k8s의 Pod에 해당)
- Job: Task 묶음 (k8s의 Deployment/ReplicaSet에 해당)
- Cell: 클러스터 (k8s의 Cluster)
- Allocs: 리소스 예약 (k8s의 Resource Request/Limit)
딱 봐도 k8s와 구조가 거의 동일하다. 실제로 Borg 개념을 정제하고 범용화한 것이 k8s이다.
Omega — Borg의 단점을 보완한 2세대
Borg도 완벽하지는 않았다. 모놀리식한 구조 때문에 확장성에 한계가 왔고, 스케줄러가 하나이기 때문에 병목이 발생했다. 이 문제를 해결하기 위해 구글은 2013년경 Omega라는 2세대 시스템을 실험한다.
Omega의 핵심은 여러 스케줄러가 공유 상태(shared state)를 보면서 동시에 스케줄링 결정을 내리는 옵티미스틱 동시성 모델이다. 쉽게 말하면 스케줄러를 플러그인처럼 여러 개 꽂을 수 있게 만든 것이다.
Omega는 전면 도입은 하지 못했지만, 그로부터 얻은 교훈이 k8s에 녹아들었다. 특히 k8s의 Controller 패턴(원하는 상태 = desired state를 선언하면 컨트롤러가 현재 상태를 맞춰가는 방식)은 Omega의 아이디어와 직결된다.
Kubernetes는 제로부터 다시 작성된 Borg의 오픈소스 자손이다
k8s는 Borg 코드를 그대로 가져온 것이 아니다. Go 언어로 제로부터 다시 작성된 프로젝트이다. 따라서 Borg의 설계 교훈은 계승하면서도, 외부 개발자가 사용할 수 있도록 API가 깔끔하고 외부 확장에 열려 있다.
Borg는 C++로 작성되어 있고 구글 내부 라이브러리에 묶여 있었기 때문에 애초에 오픈소스화가 불가능했다. 따라서 "Borg에서 배운 것을 가져다가 처음부터 새로 작성하자"가 k8s 프로젝트의 출발점이었다.
"Kubernetes"라는 이름의 유래 — 조타수 일화부터 k8s 줄임말까지
출처: GeekWire
이름에도 흥미로운 일화가 몇 가지 있다.
그리스어 "키베르네테스" = 조타수
Kubernetes는 그리스어 κυβερνήτης(kubernḗtēs)에서 따온 이름이다. 뜻은 "조타수(helmsman)" 또는 "항해사(pilot)"이다. 배를 조종하는 사람이다. 컨테이너(영어 container는 화물선 컨테이너를 의미)가 가득한 배를 조종한다는 메타포이다.
로고가 괜히 조타륜(배 핸들) 모양인 것이 아니다.
k8s는 왜 k8s로 줄여 쓰는가
Kubernetes는 10글자로 길기 때문에, 영어권 프로그래머들 사이에서 흔한 줄임법으로 k + 그 사이 8글자 + s = k8s로 쓰기 시작했다. 같은 방식으로 국제화(internationalization)는 i18n으로, 접근성(accessibility)은 a11y로 쓴다. 이것을 numeronym(숫자 단축어)이라고 부른다.
코드네임이 "Seven of Nine"이었던 일화
초기 프로젝트 내부 코드네임이 "Seven of Nine"이었다. 이것이 무엇인가? 스타트렉: 보이저에 등장하는 캐릭터 이름이다. 보그 종족(Borg! 눈치챘는가?) 출신으로, 인간으로 돌아온 캐릭터이다.
즉 "Borg의 후계자"라는 내부 농담이었던 것이다. 그렇다면 왜 정식 명칭은 Kubernetes가 되었는가. Seven of Nine은 파라마운트(스타트렉 저작권자)의 상표이기 때문에 그대로 사용할 수 없었다.
다만 이 흔적이 로고에 남아 있다. 공식 로고 조타륜에 박힌 별이 정확히 7개이다. "Seven of Nine"을 기린 디자인이다. 이 디테일을 알고 보면 로고가 다르게 보인다.
2014년 6월 공개부터 CNCF 기증까지 타임라인
쿠버네티스 역사에서 2014년 6월부터 2015년까지 1년 남짓한 기간이 가장 결정적이다. 구글이 쿠버네티스를 오픈소스로 공개하는 과정은 생각보다 빠르게 진행되었다.
2014년 6월 6일 — GitHub 첫 커밋
2014년 6월 6일 kubernetes/kubernetes 저장소가 GitHub에 올라온다. 이것이 공식 생일이다. 저장소 주소는 github.com/kubernetes/kubernetes이며, 첫 커밋 히스토리는 지금도 조회 가능하다.
그리고 4일 뒤인 6월 10일 DockerCon 2014에서 공식 발표가 이루어진다. 도커 컨퍼런스에서 도커를 더 잘 운영할 수 있는 도구를 발표한 것이다. 이 타이밍이 절묘하다. 도커 열풍을 그대로 흡수한 것이다.
2015년 7월 21일 — 버전 1.0 정식 릴리스
1년 조금 넘는 기간 개발하여 2015년 7월 21일 Kubernetes 1.0을 정식 릴리스한다. 베타 딱지를 떼는 순간이었으며, 이 시점부터 프로덕션에서 사용할 수 있는 제품으로 포지셔닝된다.
같은 날 Linux Foundation 산하에 Cloud Native Computing Foundation(CNCF)이 설립된다. 그리고 구글은 Kubernetes의 소유권을 CNCF에 기증한다.
CNCF 기증이 진정으로 의미하는 것
왜일까? CNCF 기증이 중요한 이유는 "구글 것"에서 "중립 재단 것"으로 바뀌었기 때문이다. 이것이 없었다면 다른 클라우드 업체들(AWS, Azure, Oracle 등)은 k8s를 신뢰하지 못하고 경쟁 프로젝트를 밀었을 것이다.
다만 CNCF 산하로 들어가면서 "구글 독점이 아니다"라는 명분이 생겼고, 마이크로소프트, 아마존, IBM, Red Hat, VMware 같은 경쟁사들도 모두 합류한다. 지금 CNCF 홈페이지(cncf.io)에 들어가면 수백 개의 회사가 멤버로 있다.
이것이 바로 k8s가 "업계 표준"이 된 결정적 분기점이다. 기술적으로 k8s보다 나았을지 모르는 경쟁자들(Apache Mesos, Docker Swarm)이 있었지만, 중립성과 생태계 확장성에서 밀려 결국 사라졌다.
쿠버네티스 개발자 3인방은 지금 무엇을 하고 있는가 — 근황 정리
10년이 지났다. 창시자 3명은 지금 어디서 무엇을 하고 있을까.
Craig McLuckie와 Joe Beda — Heptio 창업 → VMware 매각 → 각자 다음 챕터
Craig와 Joe는 2016년 구글을 나와 Heptio라는 스타트업을 공동 창업한다. Heptio는 k8s 기업용 도구와 컨설팅을 제공하는 회사였다. 인수합병 시장에서 주목받았고, 2018년 VMware가 약 5억 달러에 인수한다.
VMware 인수 후 Joe Beda는 VMware에서 Principal Engineer로 일하며 k8s 생태계에 계속 관여했다. Craig McLuckie는 VMware에서 잠시 있다가 나와 Stacklok이라는 소프트웨어 공급망 보안 회사를 새로 창업하여 CEO로 재직 중이다.
Brendan Burns — 마이크로소프트 Azure로 이적
Brendan은 2016년 마이크로소프트로 이적한다. "k8s를 만든 사람이 경쟁사로 갔다"며 당시 업계가 놀랐다. 이후 Azure Kubernetes Service(AKS)를 이끌었고, 지금은 마이크로소프트에서 Corporate Vice President / Distinguished Engineer 급으로 남아 있다.
이들 덕분에 k8s는 여전히 움직이고 있다
3인방은 구글을 모두 떠났지만, 쿠버네티스 생태계에 대한 영향력은 여전하다. Joe Beda는 TGIK(This Guy Is K8s) 같은 유튜브 방송으로 커뮤니티 교육을 해왔고, Brendan은 k8s 관련 책을 여러 권 집필했다. Craig는 컨퍼런스 단골 연사이다.
k8s가 특정 회사의 소유가 아니라 커뮤니티가 움직이는 프로젝트가 된 것은 이 3인방이 초기부터 오픈소스 문화를 강하게 밀어붙인 덕분이 크다.
핵심 정리 — 이 히스토리를 알면 k8s가 다르게 보인다
쿠버네티스 개발자 배경을 훑어봤는데, 핵심을 정리하면 다음과 같다:
- 쿠버네티스 개발자 3인방은 Joe Beda, Brendan Burns, Craig McLuckie — 2014년 구글에서 출발
- 갑자기 등장한 것이 아니라 10년 묵은 Borg의 교훈을 Go로 다시 작성한 오픈소스 버전이다
- 도커 열풍(2013)이 기회를 만들었고, AWS 대항마로서의 비즈니스 전략이 오픈소스화를 밀어붙였다
- 2014년 6월 GitHub 공개 → 2015년 1.0 → CNCF 기증의 타임라인이 표준화의 결정적 경로였다
- 이름은 그리스어 "조타수"에서 유래했으며, 로고의 별 7개는 "Seven of Nine" 코드네임의 흔적이다
k8s가 왜 이렇게 복잡하고 추상적인지 의문이었다면, 10년 넘게 구글 내부에서 검증된 시스템의 개념을 그대로 물려받았기 때문이라는 답이 된다. 단순히 컨테이너를 운영하는 도구가 아니라 "대규모 분산 시스템의 운영 철학"이 녹아 있는 것이다.
다음 단계로는 이 철학이 실제 아키텍처에 어떻게 구현되었는지 — Master와 Node, etcd, kubelet, kube-proxy가 어떻게 맞물려 작동하는지 — 살펴보는 것이 좋다. 쿠버네티스 개발자들이 왜 그런 선택을 했는지 알고 나면 에러 로그 하나도 다르게 읽힌다.
자주 묻는 질문 (FAQ)
Q1. 쿠버네티스는 누가 만들었는가?
구글 엔지니어 Joe Beda, Brendan Burns, Craig McLuckie 3명이 공식 창시자이다. 이 외에 Brian Grant, Tim Hockin 등 Borg 팀 출신 엔지니어들이 초기 설계에 깊이 관여했다.
Q2. 쿠버네티스는 언제 공개되었는가?
2014년 6월 6일 GitHub에 kubernetes/kubernetes 저장소의 첫 커밋으로 공개되었다. 정식 1.0 버전은 2015년 7월 21일 릴리스되었다.
Q3. k8s는 왜 k8s인가?
Kubernetes의 첫 글자 k와 마지막 s 사이에 글자 8개가 있기 때문에 k8s로 축약한다. 같은 방식으로 internationalization은 i18n, accessibility는 a11y로 쓴다. 이것을 numeronym이라고 부른다.
Q4. 쿠버네티스의 소유권은 지금 누가 가지고 있는가?
2015년 구글이 Linux Foundation 산하 CNCF(Cloud Native Computing Foundation)에 기증했다. 지금은 특정 회사의 소유가 아닌 CNCF가 관리하는 오픈소스 프로젝트이다.
Q5. Borg와 쿠버네티스의 차이는 무엇인가?
Borg는 구글이 2003년부터 내부용으로 만든 클러스터 관리 시스템이며 C++로 작성되었다. Kubernetes는 Borg의 개념과 교훈을 물려받아 Go 언어로 제로부터 다시 작성된 오픈소스 버전이다. 핵심 개념은 거의 같지만 k8s는 외부 개발자가 사용할 수 있도록 API와 확장성을 완전히 새로 설계했다.
'DevOps' 카테고리의 다른 글
| CGI, WSGI, WAS의 차이 정리 — 웹서버 공부할 때 헷갈리는 개념 한 번에 끝내기 (0) | 2026.04.25 |
|---|---|
| 트래픽 Traffic 1000배가 터져도 죽지 않는 서버를 만드는 법 (1) | 2026.04.24 |
| CPU 아키텍처에 따른 Docker Multi Architecture 빌드 구성하기 (0) | 2024.02.22 |
| Prometheus (프로메테우스) 대해 알아보고 설치해보자 (0) | 2024.01.31 |
| Kubernetes::네트워킹 (Networking) (0) | 2023.12.19 |
