쿠버네티스란 무엇인가 — 컨테이너 오케스트레이션에서 AI의 OS까지

쿠버네티스(Kubernetes)는 구글이 10여 년간 내부에서 검증한 컨테이너 운영 노하우를 오픈소스로 풀어낸 분산 시스템의 자동 조종장치입니다. 이 글은 이름의 유래에서 출발해 탄생 배경, 오픈소스화, CNCF 표준화, 그리고 오늘날 “AI의 사실상 운영체제”라는 위상까지를 하나의 흐름으로 짚어, 클라우드·컨테이너를 들어는 봤지만 실체가 흐릿한 엔지니어가 “그래서 쿠버네티스구나”를 스스로…

2026년 07월 11일

왜 이름이 하필 “쿠버네티스”일까

쿠버네티스는 그리스어 κυβερνήτης(kubernḗtēs, 키잡이·조타수) 에서 왔습니다. 배를 목적지로 이끄는 사람처럼, 수많은 컨테이너를 원하는 상태로 이끄는 시스템이라는 은유입니다. 흔히 쓰는 약칭 K8s 는 “K + 가운데 8글자 + s”를 줄인 표기이며, 여기서 8은 버전 번호가 아닙니다. 초기 프로젝트명이 스타트렉의 보그 드론에서 딴 “Project Seven of Nine”이었고, 그 흔적이 로고의 7개 꼭짓점(방향키 모양) 으로 남아 있습니다. [R1][R3]

컨테이너 수백 척이 떠 있는 항구에서, 쿠버네티스는 각 배가 어디로 가야 할지 지시하는 관제탑이자 조타수에 가깝습니다.

자료 다운로드 📄

이 글과 함께 제공되는 발표 자료를 아래 버튼에서 내려받으실 수 있습니다.

자료 다운로드

누가·언제·왜 만들었나

쿠버네티스는 구글이 내부 클러스터 관리 시스템 Borg·Omega 를 운영하던 엔지니어들(Joe Beda, Brendan Burns, Craig McLuckie 등)이 그 경험을 담아 2014년 공개하고 2015년 v1.0 을 낸 프로젝트입니다. 목적은 명확했습니다 — 수천 개 컨테이너의 배포·확장·장애 복구를 사람 손 없이 자동화하는 컨테이너 오케스트레이션(container orchestration) 입니다. Borg 는 구글이 오래전부터 검색·광고를 돌려 온 내부 클러스터 매니저였습니다. [R2]

흔한 오해 하나를 짚고 갑니다. “쿠버네티스는 Docker 가 만들었다”는 말은 사실이 아닙니다. Docker 는 컨테이너를 만들고 포장하는 런타임·도구이고, 그 위에서 수많은 컨테이너를 운영하는 오케스트레이션 표준이 구글발 쿠버네티스입니다. 구글이 사내에서만 쓰던 비법 레시피(Borg)를 누구나 쓸 수 있게 다시 쓴 오픈 레시피북이 쿠버네티스인 셈입니다. [R2]

구글은 왜 이걸 공짜로 풀었나

자선이 아니라 전략이었습니다. 당시 판이 Docker 중심으로 짜이던 흐름에서, 구글은 컨테이너 생태계의 표준을 선점하고 벤더 종속 없는 이식성을 확보하며 커뮤니티 확산으로 자사 클라우드의 저변을 넓히려 했습니다. 표준이 되면 “쿠버네티스를 가장 잘 굴리는 클라우드”로서 구글이 유리해집니다. 내 항구 규격을 세계 표준으로 만들면 전 세계 배가 그 설계에 맞춰지는 것과 같습니다. [R2]

함정(Pitfall): “오픈소스니까 구글은 손을 뗐다”는 오해. 구글은 초기 주도자이자 지금도 핵심 기여자이며, 다만 거버넌스는 중립 재단(CNCF) 으로 넘겼습니다.

지금도 구글은 쿠버네티스를 어떻게 쓰나

구글 내부의 핵심 서비스(검색·광고·앱)는 지금도 상당 부분 Borg 가 돌립니다. 쿠버네티스는 그 설계 철학을 오픈소스로 재구현한 “형제”이며, 상용 매니지드 제품은 GKE(Google Kubernetes Engine) 입니다. 원조 맛집(Borg)은 계속 영업하고, 그 비법을 정리해 프랜차이즈로 낸 것이 쿠버네티스/GKE 라고 보면 이해가 쉽습니다. (구글 내부의 정확한 워크로드 비중은 공개 자료 기준으로는 확인이 제한적입니다.) [R1][R2]

쿠버네티스와 CNCF의 관계

2015년, 구글은 쿠버네티스를 Linux Foundation 산하 CNCF(Cloud Native Computing Foundation) 에 최초 프로젝트로 기증했습니다. 현재 상표권도 CNCF 가 보유합니다. 특정 벤더가 아니라 중립 재단이 소유·운영을 맡으면서 “구글 것”이 아닌 “모두의 것”이 되었고, 이 신뢰가 폭발적 채택의 기반이 되었습니다. [R4]

여기서도 오해가 하나 있습니다. CNCF 가 쿠버네티스를 “만든” 것이 아닙니다. CNCF 는 기증받아 운영·보호하는 중립 재단이고, 쿠버네티스는 그 최초이자 상징적인 졸업(Graduated) 프로젝트입니다. 창업자가 회사를 공익 재단에 기부해 누구도 독점하지 못하게 만든 구조에 가깝습니다.

왜 “AI의 OS”라고 부르나

2026년 1월, CNCF 는 연례 설문을 근거로 쿠버네티스를 “AI 의 사실상(de facto) 운영체제” 로 규정했습니다. 여기서 ‘OS’는 리눅스 같은 전통 OS 가 아니라, AI 인프라가 그 위에서 구동·확장되는 기반 플랫폼이라는 은유입니다. 실제 수치가 이를 뒷받침합니다 — 컨테이너 사용자의 82% 가 프로덕션에서 쿠버네티스를 사용하고, 생성형 AI 모델을 다루는 조직의 66% 가 추론(inference) 워크로드 관리에 쿠버네티스를 사용합니다. [R5][R6]

주의할 오해: “쿠버네티스가 리눅스를 대체하는 OS 다”는 말은 틀립니다. 노드 안에서는 여전히 리눅스가 돌고, 쿠버네티스는 여러 노드를 하나처럼 다루는 상위 계층입니다. 스마트폰의 안드로이드처럼, 그 위에서 앱(=AI 모델)이 설치·실행·확장되는 공통 실행 기반이라고 보면 됩니다.

가상화를 넘어 무엇을 푸는가

VM(가상머신)은 무겁고(하이퍼바이저·OS 중복·느린 부팅) 밀도가 낮습니다. 컨테이너는 가볍고 빠르지만 혼자서는 대규모 운영을 감당하지 못합니다. 바로 그 운영을 쿠버네티스가 자동화합니다. 핵심은 네 가지입니다 — 오케스트레이션(어디에 몇 개를 띄울지), 자가치유(죽으면 다시 띄움), 선언적 상태 관리(원하는 상태만 선언하면 알아서 맞춤), 수평 확장(부하에 따라 자동 증감). [R7]

선언적 상태 관리가 잘 와닿지 않는다면, 아래처럼 “원하는 상태”만 적어 두는 방식을 떠올리면 됩니다. 명령의 나열이 아니라 목표 상태의 선언이라는 점이 핵심입니다.

# 개념 예시: "nginx 파드를 항상 3개 유지하라"는 목표 상태 선언
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
spec:
  replicas: 3          # 원하는 상태: 3개
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
        - name: nginx
          image: nginx:1.27

이렇게 선언해 두면 파드 하나가 죽어도 쿠버네티스가 스스로 3개를 다시 맞춥니다. 컨테이너가 규격화된 택배 상자라면, 쿠버네티스는 상자를 싣고·재배치하고·분실 시 재발송하는 자동 물류 센터입니다. 다만 “컨테이너가 VM 을 완전히 대체한다”는 것은 오해이며, 실제로 많은 쿠버네티스 노드가 VM 위에서 돕니다. [R7]

IT에 남긴 영향의 규모

쿠버네티스는 데브옵스·플랫폼 엔지니어링·마이크로서비스·GitOps 확산의 중심축이 되었고, 멀티·하이브리드 클라우드의 공통 언어로 자리 잡았습니다. CNCF 생태계는 수백 개 프로젝트로 성장했고, 프로덕션 컨테이너 사용자의 82% 가 쿠버네티스를 사용합니다. 채용 시장에서도 사실상 표준 역량이 되었습니다. [R5][R6]

한때 회사마다 제각각이던 전기 플러그가 표준 규격으로 통일되며 모든 기기가 호환된 것처럼, 쿠버네티스는 인프라의 “플러그 규격” 이 되었습니다. “쿠버네티스는 대기업만 쓴다”는 인식도 옛말입니다 — GKE·EKS·AKS 같은 매니지드 서비스로 소규모 팀의 진입 장벽이 크게 낮아졌습니다.