Blog,Kubernetes Blog

“쿠버네티스(Kubernetes)”라는 용어는 그리스어에서 유래된 단어로, “조타수(helmsman)” 또는 “항해사(navigator)”를 의미합니다. 구글이 이 명칭을 선택한 데에는 단순한 기술적 명칭 이상의 철학과 메시지가 담겨 있습니다.

컨테이너 기술은 마치 선박처럼 애플리케이션과 그 실행 환경을 하나의 단위로 패키징하고, 이를 다양한 환경에서 동일하게 실행할 수 있게 해줍니다. 하지만 이러한 수많은 “컨테이너 선박”을 어떻게 조직적이고 안정적으로 운영할 것인가에 대한 문제를 해결해 줄 “조타수”가 필요했죠. 쿠버네티스는 바로 그 역할을 수행하는 오케스트레이션 시스템입니다. 단순히 컨테이너를 배치하는 것을 넘어서, 자동 복구(self-healing), 스케일링, 서비스 디스커버리, 롤링 업데이트 등, 전체적인 항해를 책임지는 기능들을 내포하고 있습니다.

또한 재미있는 점은, 개발자 커뮤니티에서 “Kubernetes”를 줄여서 “K8s”라고 부르는 것도 이 단어의 철자 수(총 10자)에서 첫 글자 “K”와 마지막 글자 “s” 사이의 8자를 생략하는 방식에서 유래한 것입니다. 이 역시 기술적 효율성과 상징성을 모두 담은 표현이라 볼 수 있겠죠.

쿠버네티스(Kubernetes)는 한마디로, “컨테이너를 운영하기 위한 자동화된 통제 센터”라고 이해하시면 좋습니다. 그 기원은 구글 내부에서 수십만 대의 서버를 마치 하나의 거대한 컴퓨터처럼 다루기 위해 개발된 Borg라는 시스템에서 출발합니다. 이 경험을 바탕으로 구글은 오픈소스 커뮤니티에 쿠버네티스를 공개했고, 현재는 클라우드 네이티브 시대의 핵심 인프라로 자리잡게 되었죠.

Kubernetes는 단순한 컨테이너 런타임 위의 오케스트레이터를 넘어서, 현대적인 분산 시스템 운영의 모든 핵심 요소들을 포함하고 있습니다. 예를 들어, 컨테이너의 스케줄링과 오토스케일링은 물론, 헬스 체크(Health Check), 셀프 힐링(Self-Healing), 서비스 디스커버리(Service Discovery), 로드밸런싱, 롤링 업데이트, 롤백, 그리고 RBAC 기반의 접근 제어까지 내장하고 있습니다.

쿠버네티스트는 특히, 마이크로서비스 아키텍처(MSA) 기반의 클라우드 네이티브 애플리케이션에서 쿠버네티스는 없어서는 안 될 존재입니다. 마이크로서비스는 수십, 수백 개의 독립된 서비스로 구성되어 있고, 이 각각을 컨테이너로 운영하는 경우, 사람 손으로 직접 배포하고 상태를 모니터링하고 문제를 해결하는 건 사실상 불가능에 가깝습니다. 쿠버네티스는 이 모든 작업을 선언적 방식으로 정의하고, 클러스터 상태를 항상 원하는 상태(desired state)로 유지하려고 노력합니다.

실제로 공공부문에서도 쿠버네티스 기반의 정보시스템이 활발히 도입되고 있습니다. 예를 들어 클라우드 네이티브 정보시스템 구축 가이드에서는 쿠버네티스를 MSA 기반 시스템에서 컨테이너를 자동화하고 확장하며 안정적으로 운영할 수 있게 하는 핵심 구성요소로 소개하고 있습니다.

결국, 쿠버네티스는 단순히 도구(tool)를 넘어, 변화무쌍한 현대의 비즈니스 요구에 유연하고 탄력적으로 대응할 수 있도록 만들어주는 인프라 운영의 “표준 운영 체제”라고 보셔도 무방합니다.

구글은 2000년대 초반 대규모 분산 시스템을 운영하면서 하드웨어, 소프트웨어, 네트워크, 스토리지 외에도 다양한 문제에 직면하였습니다. 이러한 문제는 하드웨어, 소프트웨어, 네트워크, 스토리지 등 여러 측면에서 발생했으며, 이를 해결하기 위해 구글은 혁신적인 시스템과 기술을 개발하게 되었습니다.

• 하드웨어의 불안정성과 고장

구글은 비용 효율성을 위해 고가의 서버 대신 저렴한 범용 x86 하드웨어를 사용했습니다. 이러한 하드웨어는 고장률이 높았으며, 메모리 오류나 디스크 손상과 같은 문제가 빈번하게 발생했습니다. 예를 들어, 2000년 3월에는 웹 크롤링 시스템이 멈추는 긴급 상황이 발생했으며, 이는 하드웨어 결함과 메모리 손상으로 인한 것이었습니다 . 이러한 문제를 해결하기 위해 구글은 소프트웨어적으로 하드웨어 결함을 감지하고 자동으로 복구하는 시스템을 개발하게 되었습니다.

• 소프트웨어의 복잡성과 유지 관리

초기에는 애플리케이션이 각 서버에 수작업으로 배포되었고, 인프라와 애플리케이션 상태를 관리하는 도구들이 조각조각 흩어져 있었습니다. 장애 복구나 리소스 할당 같은 작업도 수동으로 이루어졌으며, 이는 개발자와 운영자의 부담을 크게 증가시켰습니다. 또한, 당시의 배치 인덱싱 시스템은 체크포인트 기능이 없어 머신 장애 시 복구가 어려웠고, 원시 데이터에 대한 체크섬이 없어 하드웨어 비트 오류로 인한 문제가 발생했습니다.

• 네트워크의 병목 현상과 확장성 문제

당시의 네트워크 인프라는 급증하는 트래픽을 처리하기에 충분하지 않았습니다. 특히, 서버가 10,000개 이상의 동시 연결을 처리하는 데 어려움을 겪는 ‘C10K 문제’가 존재했으며, 이는 실시간 상호작용을 필요로 하는 애플리케이션의 구축을 어렵게 만들었습니다 . 또한, 구글은 자체적으로 네트워크 하드웨어와 소프트웨어를 설계하여 기존의 복잡하고 비싼 스위치를 대체하고, 데이터 센터 간의 디지털 데이터를 보다 효율적이고 경제적으로 이동시킬 수 있는 시스템을 구축했습니다.

• 스토리지의 확장성과 신뢰성 문제

구글은 방대한 양의 데이터를 저장하고 처리하기 위해 자체적인 분산 파일 시스템인 Google File System(GFS)을 개발했습니다. GFS는 데이터를 64MB의 청크로 나누어 저장하고, 각 청크를 여러 서버에 복제하여 저장함으로써 하드웨어 고장에 대비했습니다 . 또한, 구조화된 데이터를 대규모로 저장하고 처리하기 위해 Bigtable이라는 분산 스토리지 시스템을 개발했으며, 이는 MapReduce와 같은 대규모 병렬 컴퓨팅 프레임워크와 함께 사용되었습니다 .

• 아래 표는 추가적인 문제들을 정리한 것입니다.

구글은 2000년대 초반, 급격히 증가하는 서비스 수요와 이를 뒷받침할 대규모 인프라 환경에서 여러 기술적 난관에 직면했습니다. 당시 구글은 검색, Gmail, YouTube 같은 글로벌 서비스를 수십억 사용자에게 제공하고 있었고, 이를 위해 수십만 대 이상의 서버가 필요했는데, 이를 기존 방식으로는 안정적으로 운영하는 데 한계가 있었습니다. 이로 인해 구글은 다음과 같은 구체적인 기술 과제들을 설정하였습니다.

• 서버 인프라 확장성과 장애 복원력 확보

구글은 값비싼 고가용성 서버 대신 저렴하고 고장이 잦은 범용 서버를 대량으로 도입하여 인프라를 구성했습니다. 그러나 이 경우 개별 장비의 장애는 일상적이므로, 시스템 전체의 안정성을 위해 하드웨어가 아니라 소프트웨어에서 복원력을 보장하는 방식이 필요했습니다. 이로 인해 시스템은 셀프 힐링(self-healing), 자동 재시작, 자동 스케줄링과 같은 기능을 기본으로 갖추어야 했습니다.

• 운영 자동화와 사람 개입 최소화

구글은 수십만 대의 서버를 운영하면서 수작업 개입으로는 효율적인 유지관리가 불가능하다는 결론을 내렸습니다. 이를 해결하기 위해 대규모 클러스터의 자동 운영을 위한 시스템이 필요했고, 이는 나중에 Borg로 구체화됩니다. Borg는 사용자가 아닌 시스템이 스스로 할당, 배포, 복구, 스케일링을 하도록 설계되었습니다.

• 자원 효율성의 극대화

다양한 팀이 하나의 대규모 클러스터를 공유하는 환경을 운영하기 위해, 구글은 멀티 테넌시(Multi-Tenancy) 환경에서의 자원 격리 및 할당 효율성을 극대화해야 했습니다. CPU, 메모리, 디스크 등 리소스를 세밀하게 나누고, 할당 정책 및 우선순위 기반 스케줄링을 구현해야 했습니다.

• 서비스 배포 속도와 안정성 확보

구글은 자주 변경되는 코드와 서비스를 빠르고 안전하게 배포할 수 있는 체계를 갖춰야 했습니다. 이를 위해 컨테이너 개념을 적용하여 배포 단위를 격리시키고, 불변 인프라(Immutable Infrastructure) 원칙에 기반한 배포 자동화를 구축했습니다. 이후 Borg는 이러한 환경을 지원하는 플랫폼으로 진화했습니다.

• 서비스 간 통신 및 보안 통제

대규모 분산 시스템 환경에서는 서비스 간 통신의 신뢰성과 보안이 핵심 과제가 됩니다. 구글은 서비스 간 통신에 대해 인증, 암호화, 정책 기반 접근 제어를 수행할 수 있는 서비스 메시(Service Mesh) 개념을 내부적으로 구현하며, 내부 트래픽에 대해서도 종단 간 TLS 적용 같은 전략을 채택했습니다.

• 개발자의 생산성 보장

운영환경의 복잡도가 증가함에 따라, 개발자들이 인프라 관리에 신경쓰지 않고 애플리케이션 로직에 집중할 수 있는 환경이 필요했습니다. 그래서 구글은 개발자가 코드만 작성하면 나머지는 플랫폼이 자동으로 처리해주는 개발자 추상화 모델을 구현했습니다. 이 모델은 훗날 Kubernetes의 추상화된 API 기반 리소스 모델로 발전하게 됩니다.

이러한 과제들은 단순한 서버 확장이나 스크립트 자동화 수준의 문제가 아니라, 인프라 전체를 하나의 분산 시스템으로 설계하고 운영할 수 있는 능력을 요구하는 것이었습니다. 구글은 이를 해결하기 위해 Borg라는 내부 오케스트레이션 시스템을 만들었고, 그 경험은 Kubernetes로 이어졌습니다.

이러한 다양한 문제를 해결하기 위해 구글은 Borg라는 내부 시스템을 개발하여 컨테이너 기반의 애플리케이션을 효율적으로 스케줄링하고 배포할 수 있는 환경을 구축했습니다. Borg는 노드의 상태나 자원 사용량을 실시간으로 감지하여 자동 복구와 스케일링이 가능하며, 개발자가 운영의 복잡성을 신경 쓰지 않아도 되도록 추상화된 배포 환경을 제공합니다. 이러한 시스템은 이후 Kubernetes의 기반이 되었으며, 현대의 클라우드 네이티브 환경에서 필수적인 요소로 자리 잡았습니다.

Google은 수십만 대에 달하는 서버를 단일 거대한 컴퓨터처럼 활용해야 했고, 이 복잡한 자원 관리 문제를 해결하기 위해 컨테이너 오케스트레이션 시스템(Borg, 이후 Kubernetes의 기반이 됨)을 개발하고 발전시켰습니다.

Google의 데이터센터 원칙, 특히 효율성, 안정성, 확장성은 대규모 분산 시스템 환경에서 애플리케이션을 어떻게 실행하고 관리할 것인가에 대한 고민에서 출발했습니다. 컨테이너 기술과 이를 관리하는 오케스트레이션 시스템(Borg -> Kubernetes)은 이러한 고민에 대한 Google의 답변이며, 하드웨어 인프라 위에 소프트웨어적으로 이러한 원칙들을 구현하고 자동화하는 핵심 도구 역할을 합니다. 컨테이너는 데이터센터의 물리적 자원을 추상화하고, 애플리케이션 배포 및 관리를 표준화하며, 자동화된 운영을 가능하게 함으로써 Google이 대규모 서비스를 최소한의 비용과 최고의 안정성, 성능으로 제공하는 근간이 되었습니다. 컨테이너는 단순한 기술을 넘어, Google의 데이터센터 운영 철학을 실현하는 핵심 방법론이라고 할 수 있습니다.

쿠버네티스는 구글이 대규모 데이터센터 운영을 위해 자체적으로 개발한 컨테이너 오케스트레이션 시스템 ‘Borg’에서 출발하여, 이를 외부에 오픈소스로 공개하며 시작된 프로젝트입니다. 구글은 수십만 대 이상의 서버를 효율적으로 활용하고, 애플리케이션을 빠르게 배포하고 자동으로 복구할 수 있도록 하기 위해 컨테이너 기술을 표준으로 도입했고, 그 핵심 기술이 바로 쿠버네티스입니다.

쿠버네티스의 필요성은 단순히 컨테이너를 관리하는 기술 그 이상입니다. 오늘날과 같이 다양한 환경(Public, Private, Hybrid Cloud)에 분산된 수많은 마이크로서비스 기반의 애플리케이션을 안정적으로 운영하기 위해서는, 서비스의 배포, 확장, 복구, 모니터링을 자동으로 수행할 수 있는 플랫폼이 필수적이며, 이 역할을 쿠버네티스가 수행합니다. 예컨대 애플리케이션의 트래픽이 갑자기 증가할 때 자동으로 인스턴스를 늘려주는 오토스케일링 기능이나, 문제가 있는 컨테이너를 감지하고 자동으로 재기동하는 셀프힐링(self-healing) 기능은 쿠버네티스 없이는 구현이 매우 복잡합니다.

2025년 현재, 퍼블릭 클라우드(AWS, Azure, GCP)는 물론, 프라이빗 클라우드(OpenShift, Rancher, K-PaaS 등), 그리고 하이브리드 클라우드 환경에서도 쿠버네티스는 사실상 표준 오케스트레이션 플랫폼으로 자리 잡았습니다. 이는 특정 벤더에 종속되지 않으면서도 클라우드 간 이식성과 확장성을 확보할 수 있는 유일한 기반이기 때문입니다.

더불어, 공공 부문에서도 클라우드 네이티브 기반 시스템 구축 시 컨테이너와 쿠버네티스의 도입이 필수요소로 자리 잡고 있으며, 이로 인해 시스템의 민첩성과 안정성을 동시에 확보하고 있습니다. 즉, 쿠버네티스는 단순한 선택이 아닌, 클라우드 시대의 기본 인프라 기술이 되었다고 할 수 있습니다.

• 쿠버네티스 – https://kubernetes.io
• 표준프레임워크를 활용한 MSA 구현 (1) – https://www.egovframe.go.kr/wiki/lib/exe/fetch.php?media=egovframework:dev4.0:msadev4.0.pdf
• MSA컨설팅방법론_NIA.pdf – https://www.nia.or.kr/main/contents.do?menuNo=200247
• 클라우드네이티브 정보시스템 구축 발주자 안내서 – https://www.nia.or.kr/site/nia_kor/ex/bbs/View.do?cbIdx=99865&bcIdx=24821
• The Friendship That Made Google Huge – https://www.newyorker.com/magazine/2018/12/10/the-friendship-that-made-google-huge
• Large-scale cluster management at Google with Borg – https://research.google.com/pubs/archive/43438.pdf
• How Kubernetes came to be: A co-founder shares the story – https://cloud.google.com/blog/products/containers-kubernetes/from-google-to-the-world-the-kubernetes-origin-story
• High-Availability at Massive Scale: Building Google’s Data – https://research.google.com/pubs/archive/44686.pdf
• Kubernetes 공식 문서 – https://kubernetes.io
• Borg, Omega, and Kubernetes: Lessons learned from three container-management systems over a decade – https://research.google/pubs/pub43438/
• Inside Google’s Infrastructure for Machine Learning: The Cloud TPU and Kubernetes – https://cloud.google.com/blog/products/ai-machine-learning/
• Building Software Systems at Google and Lessons Learned – https://research.google.com/people/jeff/Stanford-DL-Nov-2010.pdf
• Google File System – https://en.wikipedia.org/wiki/Google_File_System
• Bigtable – https://zh.wikipedia.org/wiki/Bigtable
• In the early 2000s, the internet was experiencing explosive growth… – https://www.linkedin.com/posts/sukhad007_in-the-early-2000s-the-internet-was-experiencing-activity-7222921638747521024-lbT0
• Revealed: The Secret Gear Connecting Google’s Online Empire – https://www.wired.com/2015/06/google-reveals-secret-gear-connects-online-empire