구글 내부에서 탄생한 대규모 인프라 운영 기술의 진화 과정과, 그 기술적 결정체인 쿠버네티스(Kubernetes)가 어떻게 오픈소스로 공개되어 클라우드 네이티브라는 새로운 시대를 열게 되었는가에 관한 이야기입니다.

핵심 메시지는 명확합니다. 쿠버네티스는 단순한 오케스트레이션 도구가 아니라, 구글이 내부에서 수십 년간 축적해온 대규모 시스템 운영의 노하우(Borg, Omega 등)를 바탕으로 만들어진 클라우드 운영 체제의 커널 이라는 점입니다.

그리고 이 커널이 오픈소스로 풀렸을 때, 전 세계 개발자와 기업들이 구글의 수준 높은 운영 기술을 누구나 사용할 수 있게 되면서 Cloud Native 패러다임이 본격적으로 시작되었다 는 것입니다.

단순히 쿠버네티스의 사용법이나 아키텍처를 소개하는 수준을 넘어서, 쿠버네티스가 왜 등장하게 되었고, 어떤 문제를 해결하려 했는지, 그리고 구글 내부 기술이 외부로 공개됨으로써 업계 전체가 어떻게 클라우드 네이티브로 전환하게 되었는지를 설명합니다.

• 특히 IT 의사결정자나 CTO, 플랫폼 엔지니어라면, 쿠버네티스 도입이 단순한 툴 체인지가 아닌, 조직의 운영 문화와 소프트웨어 전달 방식 전체를 바꾸는 패러다임 전환임을 이해하는 데 이 자료가 매우 유용합니다.
• 또한 이 자료는 Borg → Omega → Kubernetes로 이어지는 계보를 구체적으로 설명하기 때문에, 왜 Kubernetes가 단순한 오픈소스 프로젝트가 아닌지, 그 철학과 구조를 이해하는 데 중요한 배경을 제공합니다.

발표 자료는 Kubernetes의 학습 곡선이 매우 가파르다고 언급하며 시작합니다. 이는 단순한 설치의 어려움이 아니라, 기존의 인프라 운영 방식과 완전히 다른 사고방식이 필요하기 때문입니다. 예를 들어, 애플리케이션은 더 이상 “서버 위에 배포”되는 것이 아니라, “스케줄링되고, 선언적으로 관리되는 객체”가 됩니다. 이 개념적 전환이 Kubernetes의 진입 장벽을 높이지만, 동시에 그것이 가진 강력한 추상화가 클라우드 네이티브의 핵심이 됩니다.

쿠버네티스는 단순히 컨테이너를 관리하는 도구가 아니라, 클라우드 네이티브 인프라를 운영하기 위한 운영체제의 커널로 설명됩니다. 프로세스를 스케줄링하고 자원을 관리하듯, 쿠버네티스는 Pod, Node, Volume, Config 등 다양한 리소스를 오케스트레이션합니다. 이는 마치 리눅스 커널이 시스템 리소스를 추상화하고 제어하듯, 쿠버네티스가 클라우드 인프라를 그런 방식으로 통제한다는 의미입니다.

구글은 2000년대 초부터 “Process Container”라는 개념을 내부에서 사용해왔고, 이것이 나중에 리눅스 커널에 병합되어 오늘날 우리가 아는 cgroups로 발전했습니다. 이처럼 구글은 컨테이너 기술을 오랫동안 활용해 왔으며, 전체 워크로드의 100%가 컨테이너 기반으로 운영되고 있었습니다. 쿠버네티스는 이러한 구글의 내부 운영 모델을 외부에 공개한 결과물입니다.

구글 내부의 대규모 워크로드 스케줄링 시스템인 Borg와 그 후속 실험 시스템 Omega는 쿠버네티스의 설계 철학과 아키텍처에 직간접적인 영향을 미쳤습니다.

Borg는 안정성과 확장성에 중점을 두었고, Omega는 더 동적인 스케줄링 구조를 실험했습니다.

쿠버네티스는 이 두 시스템의 장점을 통합하면서도 개방형 커뮤니티와의 협업을 전제로 한 설계를 채택하여, 단순히 구글 외부의 Borg 복제물이 아닌, 완전히 새로운 오픈소스 플랫폼으로 태어났습니다.

• 2014년 6월: GitHub에 첫 커밋
• 2015년 7월: v1.0 공개 및 CNCF(Cloud Native Computing Foundation)로 기부
• 2018년 3월: 첫 번째 CNCF 졸업 프로젝트

이러한 역사적 흐름은 Kubernetes가 단순한 구글 프로젝트가 아닌, 업계 전체가 참여하는 글로벌 표준 플랫폼으로 자리 잡았다는 점을 보여줍니다.

Gmail에서 YouTube, 검색, 지도에 이르기까지 우리가 일상적으로 사용하는 Google의 서비스들은 모두 컨테이너 기반 환경에서 운영되고 있습니다. Google은 단순히 컨테이너 기술을 사용하는 수준을 넘어, 이를 통해 자사 인프라 전체를 자동화하고 고도로 확장 가능한 형태로 진화시켜 왔습니다. 이 말은 곧 Google이 클라우드 네이티브 아키텍처를 일찍부터 내재화한 대표적인 기업이라는 뜻이기도 합니다.

컨테이너는 구글 내부의 수많은 개발팀이 더 빠르게 움직이고, 더 효율적으로 소프트웨어를 배포할 수 있도록 만든 핵심 도구였습니다. 특히, 하나의 서버에 여러 개의 애플리케이션을 동시에 격리된 상태로 실행하면서도 리소스를 유연하게 활용할 수 있게 해 주는 구조 덕분에, Google은 수십억 개 단위의 컨테이너를 생성하고 운영해 왔습니다. 실제로 Google 내부에서는 매주 수십억 개 이상의 컨테이너가 생성되며, 이는 그만큼 고도로 자동화된 인프라 환경이 구축되어 있음을 방증합니다.

이처럼 장기간에 걸친 운영 경험은 단순히 Google 내부에 머물지 않았습니다. 지난 10여 년간 Google은 이러한 컨테이너 운영 경험에서 얻은 지식과 노하우를 외부 개발자 및 오픈소스 커뮤니티와 꾸준히 공유해왔습니다. 그 대표적인 결과물이 바로 Kubernetes입니다.

클라우드 네이티브 시대의 문을 연 것은 단지 가상화 기술이나 컨테이너 기술이 아니었습니다. 그보다 훨씬 근본적인 배경에는 물리적 인프라의 대규모 운영 과정에서 마주한 ‘하드웨어의 고장’이라는 현실적인 문제가 있었습니다. 구글은 수십만 대에 이르는 서버를 전 세계적으로 운영하면서 단순한 고장이 아니라, 시스템 전반의 안정성과 효율성에 영향을 주는 구조적인 과제에 직면하게 되었습니다.

2000년대 초반, 구글은 웹 검색 시장을 장악해가고 있었고, 이에 따라 인프라의 규모도 폭발적으로 성장하고 있었습니다. 하지만 서버 수가 늘어날수록 고장률은 단순히 선형적으로 증가하지 않았습니다. 서버 고장, HDD 장애, 전원 분배 장치의 문제 등 물리적 이슈들이 언제 어디서 발생할지 예측하기 어려운 상태였습니다.

이에 대응하기 위해 구글이 선택한 방식은 ‘개별 서버의 안정성을 높이는 것’이 아니었습니다. 오히려 구글은 서버는 고장나는 것이며, 이를 전제로 시스템을 설계하자는 발상의 전환을 시도합니다. 그렇게 2003년부터 Borg라는 대규모 클러스터 관리 시스템이 도입되기 시작합니다.

Borg는 애플리케이션을 추상화된 유닛(현재 우리가 말하는 Pod나 컨테이너와 유사한 개념)으로 실행하며, 이 유닛들을 하드웨어와 분리된 논리적 스케줄링 대상으로 다루었습니다. 즉, 서버가 죽어도 애플리케이션은 살아있게 만드는 구조를 설계한 것이죠.

2008년 기준으로 구글은 약 20만 대 이상의 서버를 운영하고 있었고, 일부 보고서에 따르면 2016년에는 무려 250만 대에 달하는 서버를 보유하고 있었다고 추정됩니다(Gartner, 2016년 7월). 이 규모는 단순히 데이터 센터 하나나 둘로는 상상할 수 없는 크기이며, 매일매일 어떤 형태로든 하드웨어 고장이 발생할 수밖에 없는 환경입니다.

실제로 연간 서버 고장은 수천 건에 달했고, HDD 고장도 빈번했으며, 전원 분배 장치가 고장 날 경우 한 번에 수백 대의 서버가 동시에 정지되는 일도 있었습니다. 이처럼 예측 불가능하고 지속적인 장애를 견뎌내기 위해서는 사람의 수작업으로는 불가능한 수준의 자동화가 필요했습니다. Borg는 바로 이러한 대규모 인프라 운영을 자동화하고 추상화하여, 장애를 시스템적으로 감내하는 구조를 제공했습니다.

1997년의 초기 서버 구성, 1999년의 자작 클러스터, 2000년대 초반의 초기 데이터 센터, 그리고 2008년의 실제 구글 데이터 센터 ― 는 이러한 기술적 진화를 매우 상징적으로 보여줍니다.

초기에는 가정용 PC에 가까운 장비들이었지만, 시간이 갈수록 하드웨어는 거대해지고, 복잡해졌으며, 결국에는 수백만 대 규모의 서버 운영 환경으로 진화합니다.

이 시점에서 구글이 선택한 전략은 ‘좋은 하드웨어’가 아니라 ‘신뢰할 수 없는 하드웨어 위에, 신뢰 가능한 소프트웨어 계층을 만들자‘는 것이었습니다. 이 전략은 오늘날 우리가 말하는 쿠버네티스의 설계 철학 ― ‘불안정한 환경에서도 안정적인 서비스를 제공한다‘ ― 로 자연스럽게 이어지게 됩니다.

2000년대 초반, 구글은 검색 서비스를 중심으로 폭발적으로 증가하는 사용자 트래픽을 처리해야 했습니다. 이 시점에서 구글이 직면했던 문제들은 단순한 서버 과부하가 아니라, 시스템 전체 구조의 근본적인 한계에 닿아 있었습니다.

당시에는 저렴한 x86 서버 수백, 수천 대를 사용하는 구조였기 때문에 개별 서버의 메모리 오류, 디스크 장애 같은 하드웨어 문제들이 빈번하게 발생했습니다. 또한 고가의 네트워크 장비를 통해 복잡한 네트워크 구성이 이루어지다 보니 오류 발생 시 원인 파악과 복구가 매우 어려웠습니다.

더 큰 문제는 인력 부족이었습니다. 급격히 증가하는 시스템 규모에 비해 개발자와 운영 인력은 턱없이 부족했고, 이로 인해 수작업 운영에 의존할 수밖에 없었습니다. 시스템이 분산되면서 각 서버의 모니터링과 관리가 어려워졌고, 장애가 발생하면 전체 서비스에 영향을 미치는 구조적 취약성도 그대로 노출되었습니다.

즉, 구글은 단순한 서버의 장애를 넘어서, 확장이 어려운 물리적 인프라, 관리가 어려운 네트워크, 무중단 배포가 불가능한 소프트웨어 운영, 보안과 데이터 보호의 어려움까지 포괄적인 문제들을 한꺼번에 마주하게 되었던 것입니다.

이러한 문제들을 구글은 “전통적인 시스템 설계” 방식으로는 해결할 수 없다고 판단했습니다. 따라서 아예 시스템 구조의 철학을 바꾸는 방향으로 접근했습니다.

가장 중요한 변화 중 하나는 “서비스 중단 없이 배포와 복구가 가능해야 한다”는 원칙이었습니다. 이를 위해 구글은 서비스 단위로 애플리케이션을 나누고, 소프트웨어 중심의 자동화된 배포 시스템을 개발했습니다. 서버 장애가 발생하더라도 전체 서비스에 영향을 미치지 않도록 자동 복구와 장애 격리 시스템을 도입했습니다.

또한 하드웨어 고장에 대비하여, 특정 서버나 스토리지 장치가 고장나더라도 소프트웨어적으로 데이터를 복구할 수 있도록 설계했습니다. 서버 자체가 아닌 서비스 중심의 모니터링 체계를 구축함으로써, 장애를 사용자에게 투명하게 처리하는 것이 가능해졌습니다.

IP 기반이 아닌 서비스 명 기반의 연결 구조, 즉 이름으로 서비스에 접근하는 방식은 이후 쿠버네티스의 Service, Ingress 개념으로 발전하게 됩니다. 구글은 이처럼 소프트웨어가 하드웨어, 네트워크, 운영체제를 추상화하고 제어하는 구조를 만들었고, 이를 통해 배포의 자동화, 장애 회피, 효율적인 리소스 사용이 가능해졌습니다.

구글이 구현한 이 새로운 시스템 운영 패러다임은 이후 ‘클라우드 네이티브’라는 이름으로 정형화되었습니다. 여기서 클라우드 네이티브란 단순히 클라우드에서 동작하는 시스템이 아니라, 서비스의 민첩성, 확장성, 안정성을 극대화하기 위해 클라우드 환경에 최적화된 아키텍처 철학과 기술 스택을 말합니다.

이러한 구조의 핵심 효과는 다음과 같습니다.

• IT 시스템의 자동화된 자율 운영: 장애가 발생해도 사람이 개입하지 않고 시스템이 자동으로 복구하며, 스케일링 또한 수요에 따라 자동으로 이루어집니다.
• PaaS(Platform as a Service) 환경 구현: 개발자는 인프라를 신경 쓰지 않고 오직 코드와 비즈니스 로직에만 집중할 수 있습니다.
• 24시간 365일 무중단 서비스 제공: 서비스 업데이트나 장애 복구가 실시간으로 이루어져 사용자 경험을 해치지 않습니다.
• 멀티/하이브리드 클라우드 환경 구축: 위치에 구애받지 않고 서비스가 운영될 수 있으며, 동일한 구조를 온프레미스와 클라우드 모두에 적용할 수 있습니다.
• 애플리케이션 중심 운영: 쿠버네티스와 같은 오케스트레이션 도구를 통해 MSA(마이크로서비스 아키텍처), DevOps, CI/CD 등 최신 소프트웨어 개발·운영 기법이 가능해졌습니다.
• 서비스 기반 모니터링: 개별 인스턴스가 아닌 전체 서비스의 품질을 중심으로 모니터링하여, 실시간으로 SLA를 관리할 수 있게 됩니다.

Borg는 2003년부터 구글 내부에서 사용되기 시작한 컨테이너 오케스트레이션 시스템입니다. 당시 구글은 전 세계 수많은 서버에 걸쳐 동작하는 대규모 서비스를 운영하면서, 인프라 관리를 자동화할 수 있는 도구가 절실히 필요했습니다. Borg는 이러한 필요에서 출발하여, 컨테이너 기반의 워크로드를 자동으로 배치(scheduling)하고, 자원을 효율적으로 분배하며, 장애를 자동으로 감지하고 복구하는 기능을 제공했습니다.

Borg의 핵심은 “분산된 대규모 서버 클러스터를 하나의 거대한 컴퓨터처럼 다루는 것”에 있습니다. 이를 위해 중앙의 BorgMaster와 각 서버에 설치된 Borglet이라는 구성 요소들이 협력하여, 수십만 대의 서버 위에서도 안정적으로 애플리케이션을 실행할 수 있도록 했습니다. 슬라이드에 보이는 다이어그램에서도 이 구조가 잘 드러납니다. BorgMaster는 Paxos 알고리즘을 사용한 분산 저장소를 통해 상태를 일관성 있게 유지하고, 각 Borglet은 이를 기반으로 실제 작업을 수행합니다.

이러한 기술적 기반은 훗날 쿠버네티스의 설계 철학에 직접적인 영향을 미쳤습니다.

Borg 이후, 구글은 더욱 유연한 스케줄링 시스템을 실험적으로 개발하게 되는데, 그것이 바로 Omega입니다. Omega는 Borg의 단일 스케줄러 구조에서 벗어나 다중 스케줄러(multi-scheduler) 구조를 도입하면서, 대규모 서버 환경에서 더 동적인 리소스 할당을 가능하게 했습니다.

Omega는 특히 “스케줄러 간의 충돌(conflict)을 어떻게 해결할 것인가” 라는 문제를 중심으로 설계되었습니다. 이 구조는 병렬적인 스케줄링을 가능하게 했지만, 동시에 일관성(conflict resolution) 문제도 함께 발생시켰습니다. 결국, 이 구조적 실험은 쿠버네티스에서 다시 단일 마스터 기반의 스케줄러로 돌아가게 만드는 결정적 단서를 제공했습니다.

Omega는 외부에 공개된 프로젝트는 아니지만, 내부적으로 구글이 어떤 고민을 했는지, 그리고 그것이 어떤 방향으로 진화했는지를 보여주는 매우 중요한 중간 단계였습니다.

2015년 7월, 구글은 내부에서 축적된 Borg와 Omega의 경험을 바탕으로 Kubernetes(쿠버네티스)를 오픈소스로 공개합니다. Kubernetes는 단순한 컨테이너 오케스트레이터가 아니라, 현대적인 클라우드 네이티브 인프라를 구성하는 핵심 플랫폼으로 설계되었습니다.

쿠버네티스는 다음과 같은 철학을 내포하고 있습니다.

• 분산 시스템 운영의 자동화: 워크로드의 배포, 확장, 복구 등을 자동으로 처리합니다.
• API 기반의 선언적 인프라: 사용자는 원하는 상태를 명시하고, 쿠버네티스는 그 상태에 도달하도록 내부에서 조정합니다.
• 플러그형 아키텍처: 네트워크, 스토리지, 인증 등 대부분의 컴포넌트가 플러그인 방식으로 구성되어, 다양한 환경에 유연하게 대응할 수 있습니다.

이러한 설계는 단지 기술적인 도약을 의미하는 것이 아니라, 클라우드 네이티브라는 패러다임 자체를 세상에 공식적으로 선포하는 사건이었습니다. 이제는 전통적인 모놀리식 애플리케이션이 아니라, MSA 기반의 유연하고 분산된 애플리케이션이 주류가 되면서, 쿠버네티스는 그 표준 플랫폼으로 자리잡게 된 것입니다.

애플리케이션이 갑자기 많은 요청을 받게 되면, 수동으로 인스턴스를 늘리는 방식으로는 대응이 어렵습니다. 쿠버네티스는 이 문제를 해결하기 위해 자동 스케일링(Auto Scaling) 기능을 제공합니다. 트래픽이나 시스템의 부하가 증가하면 자동으로 컨테이너 수를 늘리고(Scale Out), 반대로 트래픽이 줄어들면 불필요한 리소스를 줄여줍니다(Scale In).

이 메커니즘은 HPA(Horizontal Pod Autoscaler)나 VPA(Vertical Pod Autoscaler)와 같은 정책을 통해 동작하며, 리소스의 탄력성과 비용 효율성을 동시에 확보할 수 있게 해줍니다.

쿠버네티스는 서비스 객체(Service)를 통해 내부적으로 부하 분산(Load Balancing) 기능을 제공합니다. 클러스터 내에 여러 개의 동일한 Pod가 존재할 때, 쿠버네티스는 이 요청들을 균등하게 분산시켜 성능을 유지하고 병목 현상을 방지합니다.

외부에서 들어오는 트래픽을 노출시키기 위해 Ingress Controller 또는 LoadBalancer 타입의 서비스도 제공하며, 이러한 구조 덕분에 **고가용성(HA)**을 실현할 수 있습니다.

전통적인 시스템에서는 애플리케이션 업데이트 시 다운타임이 발생하거나, 일괄 업데이트로 인해 서비스 장애가 유발되곤 했습니다. 쿠버네티스는 이를 해결하기 위해 롤링 업데이트(Rolling Update) 기능을 지원합니다.

새로운 버전의 컨테이너 이미지를 순차적으로 배포하면서 이전 버전의 인스턴스를 하나씩 종료시키는 방식으로 무중단 배포를 구현할 수 있습니다. 만약 문제가 생기면, 즉시 이전 상태로 되돌리는 롤백 기능도 함께 제공합니다.

애플리케이션이 비정상적인 상태에 빠졌을 때, 이를 자동으로 복구하는 기능이 바로 **자동 복구(Auto Healing)**입니다. 쿠버네티스는 지속적으로 Pod의 상태를 모니터링하고, 문제가 발생한 경우에는 해당 Pod를 자동으로 종료하고 새로운 Pod로 대체합니다.

운영자가 개입하지 않아도 서비스가 정상 상태를 유지할 수 있도록 지원하며, 이는 MSA 환경에서 특히 중요한 셀프 힐링(self-healing) 특성을 구현합니다.

컨테이너는 기본적으로 휘발성 스토리지를 사용하기 때문에, 컨테이너가 재시작되면 데이터가 유실되는 문제가 있습니다. 쿠버네티스는 이를 해결하기 위해 Persistent Volume(PV)와 Persistent Volume Claim(PVC)이라는 메커니즘을 도입했습니다.

이 기능을 통해 상태 정보나 데이터가 필요한 서비스(PostgreSQL, Redis 등)는 안정적인 지속성 스토리지와 연결되어 데이터를 안정적으로 보존할 수 있습니다.

마지막으로, 쿠버네티스의 핵심 개념은 바로 **컨테이너 오케스트레이션(Container Orchestration)**입니다. 다수의 컨테이너가 존재하는 MSA 환경에서, 이들을 자동으로 배포, 확장, 감시, 복구하는 일련의 과정을 인간의 개입 없이 시스템이 자동화할 수 있게 만드는 것이 바로 쿠버네티스의 목적입니다.

이 과정에는 Pod 배치, 스케줄링, 네트워크 연결, 볼륨 마운트 등 복잡한 요소가 모두 포함되며, 이 모든 과정을 쿠버네티스가 통합된 제어 플랫폼으로서 조율합니다.

클라우드 네이티브라는 용어는 2015년 CNCF의 창립과 함께 본격적으로 확산되었지만, 그 기술적 전환점은 구글이 쿠버네티스를 오픈소스로 공개한 그 순간이라고 할 수 있습니다.

이 발표 자료는 단순한 기술 소개를 넘어, 그 이면에 담긴 구글의 전략, 오픈소스 생태계와의 조화, 그리고 클라우드 인프라의 진화를 설득력 있게 보여줍니다.

이 글을 통해 독자 여러분이 쿠버네티스를 단순한 기술 도구로 보지 않고, 클라우드 네이티브 시대를 여는 지속 가능하고 표준화된 인프라 운영 철학으로 이해하셨기를 바랍니다.

• Kubernetes Podcast – Borg, Omega, Kubernetes and Beyond
• CNCF Graduation Criteria
• The Borg Paper – “Large-scale cluster management at Google with Borg” (2015)