목차 (Agenda)

blog,Cloud Native,Kubernetes

쿠버네티스(Kubernetes)란 무엇인가 — AI 표준 플랫폼

컨테이너 몇 개를 노트북에서 띄우는 일은 어렵지 않습니다. 문제는 그 컨테이너가 수백, 수천 개로 늘어나 여러 서버에 흩어지는 순간입니다. 누가 어떤 서버에 무엇을 띄울지, 하나가 죽으면 어떻게 되살릴지, 트래픽이 몰리면 어떻게 늘릴지를 사람이 손으로 관리하기 시작하면 운영은 곧 한계에 부딪힙니다. 쿠버네티스(Kubernetes)는 바로 이 지점, 즉 대규모 컨테이너 운영의 자동화를 풀기…

2026년 07월 24일

Kubernetes 도입·운영, 전문가와 상담하세요

프로덕션 Kubernetes 도입부터 안정화까지 — Cloud Native Forum 전문가가 무료 상담으로 함께합니다.

Kubernetes 도입 문의하기 →

쿠버네티스란 무엇인가?

쿠버네티스는 여러 서버에 걸쳐 컨테이너의 배포·확장·복구·연결을 자동으로 관리하는 오픈소스 컨테이너 오케스트레이션 플랫폼입니다.

조금 더 풀어 쓰면 이렇습니다. 쿠버네티스는 애플리케이션을 담은 컨테이너(container, 실행에 필요한 코드와 라이브러리를 한 덩어리로 묶은 격리 실행 단위)들을 여러 대의 서버에 나눠 올리고, 각 컨테이너가 정상인지 계속 감시하며, 죽으면 다시 띄우고, 부하가 커지면 개수를 늘리는 일을 사람 대신 수행합니다. 이 자동화된 관리 작업을 컨테이너 오케스트레이션(container orchestration)이라고 부릅니다. 오케스트라 지휘자가 수십 명의 연주자를 한 곡으로 묶어 내듯, 쿠버네티스는 흩어진 컨테이너들을 하나의 서비스로 묶어 냅니다.

이름이 길다 보니 현장에서는 K8s로 줄여 씁니다. 가운데 ‘ubernete’ 여덟 글자를 숫자 8로 대체한 표기입니다. 발음은 보통 ‘케이-에이츠’ 또는 ‘쿠버네티스’로 읽습니다.

쿠버네티스라는 이름은 어디서 왔는가?

쿠버네티스라는 이름은 ‘키잡이’를 뜻하는 그리스어에서 왔고, 뿌리는 구글이 10여 년간 내부에서 쓰던 클러스터 관리 시스템 보그(Borg)입니다.

쿠버네티스(Kubernetes)는 그리스어 κυβερνήτης에서 온 단어로, 배의 키를 잡는 사람, 즉 조타수(helmsman)를 뜻합니다. 컨테이너라는 화물을 실은 배들을 항구로 이끄는 조타수라는 은유가 담겨 있습니다. 클라우드 네이티브 생태계의 로고와 용어에 ‘헬름(Helm, 키의 손잡이)’, ‘파일럿’ 같은 항해 어휘가 자주 등장하는 것도 같은 맥락입니다.

기술적 뿌리는 구글에 있습니다. 구글은 자사의 검색·지메일 같은 대규모 서비스를 운영하기 위해 보그(Borg)라는 내부 클러스터 관리 시스템을 오래도록 사용해 왔습니다. 파드(Pod), 서비스(Service), 레이블(Label) 같은 쿠버네티스의 핵심 개념 상당수가 이 보그의 운영 경험에서 나왔습니다(Aqua Security, “The History of Kubernetes”). 구글은 이 노하우를 오픈소스로 다시 구현해 2014년 6월 6일 쿠버네티스를 공개했습니다.

전환점은 2015년입니다. 구글은 쿠버네티스 1.0 릴리스와 함께 이 프로젝트를 리눅스 재단 산하 CNCF(Cloud Native Computing Foundation, 클라우드 네이티브 컴퓨팅 재단)에 기증했고, 쿠버네티스는 CNCF의 첫 프로젝트가 됐습니다. 이후 2018년 3월, 쿠버네티스는 CNCF에서 처음으로 ‘졸업(Graduated)’ 등급에 오른 프로젝트가 되며 성숙도를 공인받았습니다. 특정 기업의 제품이 아니라 중립적 재단이 관리하는 공동 자산이 되면서, 레드햇·VMware·IBM 같은 주요 기업들이 함께 참여하는 사실상의 업계 표준으로 자리 잡았습니다.

쿠버네티스는 어떤 문제를 푸는가?

컨테이너 하나를 띄우는 도구는 도커였고, 수천 개의 컨테이너를 여러 서버에서 안정적으로 굴리는 문제를 푼 것이 쿠버네티스입니다.

도커(Docker)의 등장으로 애플리케이션을 컨테이너로 포장해 어디서든 똑같이 실행하는 일은 쉬워졌습니다. 하지만 실제 서비스 규모로 가면 새로운 질문들이 쏟아집니다.

컨테이너 하나가 죽으면 누가 알아채고 되살리는가?
트래픽이 3배로 뛰면 컨테이너 개수를 어떻게 늘리고, 다시 잦아들면 어떻게 줄이는가?
서버 한 대가 통째로 다운되면 그 위의 컨테이너들은 어디로 옮겨지는가?
배포를 새 버전으로 바꾸다 문제가 생기면 어떻게 즉시 되돌리는가?
수십 개의 컨테이너가 서로를 어떤 주소로 찾아 통신하는가?

이 질문들을 사람이 수작업 스크립트로 감당하면 야근과 장애가 함께 늘어납니다. 쿠버네티스는 이 전부를 선언형(declarative) 방식으로 자동화합니다. 운영자는 “이 애플리케이션은 항상 3개가 떠 있어야 한다”처럼 원하는 상태(desired state)만 선언하면 되고, 쿠버네티스가 현재 상태를 그 목표에 맞춰 끊임없이 조정합니다. 하나가 죽어 2개가 되면 스스로 1개를 더 띄워 3개를 맞추는 식입니다. 이 자동 조정을 담당하는 구조를 제어 루프(control loop) 또는 조정 루프(reconciliation loop)라고 부릅니다.

이런 자동화가 주는 실질적 효과는 세 가지로 요약됩니다. 첫째, 자가 치유(self-healing)로 장애 대응이 사람 손을 덜 탑니다. 둘째, 오토스케일링(autoscaling)으로 자원을 트래픽에 맞춰 탄력적으로 쓰므로 과잉 투자와 과부하를 동시에 줄입니다. 셋째, 롤링 업데이트/롤백으로 무중단 배포와 즉시 복구가 표준 절차가 됩니다. 운영팀 입장에서는 “언제 터질지 모르는 수작업”이 “선언한 대로 유지되는 시스템”으로 바뀌는 셈입니다.

쿠버네티스의 핵심 개념

쿠버네티스는 클러스터라는 큰 울타리 안에서, 노드라는 서버 위에, 파드라는 최소 실행 단위를 올려 굴립니다.

처음 배울 때는 용어가 가장 큰 벽입니다. 뼈대가 되는 개념만 지도처럼 잡아 두면 나머지는 여기에 붙는 살입니다.

클러스터(Cluster): 쿠버네티스가 관리하는 전체 서버 묶음입니다. 하나의 클러스터가 하나의 큰 컴퓨터처럼 동작한다고 보면 됩니다.
노드(Node): 클러스터를 구성하는 개별 서버(물리 서버 또는 가상 머신)입니다. 실제로 컨테이너가 실행되는 일꾼입니다.
컨트롤 플레인(Control Plane): 클러스터의 두뇌입니다. 무엇을 어디에 배치할지 결정하고 전체 상태를 관리합니다. API 서버, 스케줄러, etcd(클러스터의 모든 상태를 저장하는 키-값 저장소) 등으로 이뤄집니다.
파드(Pod): 쿠버네티스가 배포하는 최소 단위입니다. 컨테이너 하나 또는 긴밀히 붙어 동작하는 여러 컨테이너를 담는 껍데기입니다. 쿠버네티스는 컨테이너를 직접 다루지 않고 항상 파드 단위로 다룹니다.
디플로이먼트(Deployment): 파드를 몇 개 유지할지, 어떤 버전으로 굴릴지를 선언하는 상위 개념입니다. 롤링 업데이트와 롤백이 여기서 이뤄집니다.
서비스(Service): 수시로 생겼다 사라지는 파드들에 고정된 접속 주소를 부여해, 다른 구성 요소가 안정적으로 찾아오게 하는 네트워크 통로입니다.

가장 단순한 파드 하나를 선언하는 명세는 다음과 같습니다. 쿠버네티스의 모든 리소스는 이처럼 YAML(사람이 읽기 쉬운 설정 표기법) 파일로 표현됩니다.

apiVersion: v1
kind: Pod
metadata:
  name: hello-nginx
  labels:
    app: hello
spec:
  containers:
    - name: nginx
      image: nginx:1.27
      ports:
        - containerPort: 80

실무에서는 파드를 직접 만들기보다, 파드를 몇 개 유지할지까지 함께 선언하는 디플로이먼트를 씁니다.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: hello-web
spec:
  replicas: 3            # 항상 3개의 파드를 유지하라(원하는 상태)
  selector:
    matchLabels:
      app: hello
  template:
    metadata:
      labels:
        app: hello
    spec:
      containers:
        - name: nginx
          image: nginx:1.27

이 파일을 클러스터에 적용하면, 쿠버네티스는 파드 3개를 띄우고 그 개수를 계속 지켜 냅니다.

kubectl apply -f hello-web.yaml     # 선언한 상태를 클러스터에 적용
kubectl get pods                    # 현재 떠 있는 파드 확인
kubectl scale deployment hello-web --replicas=5   # 3개에서 5개로 확장

개념 하나하나를 더 깊이 보고 싶다면, 뒤에서 안내하는 클러스터 심화 글(아키텍처·파드·네트워킹)에서 이어 읽으실 수 있습니다.

쿠버네티스는 어떻게 동작하는가?

운영자가 목표 상태를 선언하면, 컨트롤 플레인이 현재 상태와의 차이를 끊임없이 메워 목표에 수렴시킵니다.

쿠버네티스의 동작 원리는 한 문장으로 압축됩니다. “현재 상태를 원하는 상태에 맞춘다.” 이 단순한 원리가 자가 치유와 오토스케일링을 모두 떠받칩니다.

흐름을 따라가 보면 이렇습니다. 운영자가 kubectl apply로 명세를 제출하면, 그 내용은 컨트롤 플레인의 API 서버를 거쳐 상태 저장소인 etcd에 기록됩니다. 스케줄러(Scheduler)는 새 파드를 어떤 노드에 올릴지 자원 여유를 보고 결정합니다. 각 노드의 kubelet은 자기 노드에 배정된 파드를 실제로 실행하고 상태를 보고합니다. 그리고 컨트롤러(Controller)들이 제어 루프를 돌며 “선언은 3개인데 지금 2개뿐”이라는 차이를 감지하는 순간 즉시 1개를 더 띄웁니다.

이 구조 덕분에 쿠버네티스는 명령형(imperative)이 아니라 선언형(declarative)으로 작동합니다. “1번 서버에서 컨테이너를 켜라”가 아니라 “이 서비스는 항상 3개여야 한다”고 말하는 방식입니다. 어떻게 그 상태에 도달할지는 쿠버네티스가 알아서 판단합니다. 운영자는 절차가 아니라 목표만 관리하면 되므로, 클러스터가 커질수록 이 방식의 이점이 커집니다.

도커와 쿠버네티스는 무엇이 다른가?

도커는 컨테이너를 만들고 실행하는 도구이고, 쿠버네티스는 그렇게 만든 컨테이너를 여러 서버에서 대규모로 운영하는 도구입니다. 둘은 경쟁이 아니라 층이 다릅니다.

가장 흔한 오해가 “쿠버네티스 대 도커, 무엇을 쓸까”입니다. 실제로 둘은 역할이 다른 계층입니다. 도커는 애플리케이션을 이미지로 포장하고 컨테이너로 실행하는 런타임/패키징 도구입니다. 쿠버네티스는 그 컨테이너 수백·수천 개를 여러 노드에 배치·확장·복구하는 오케스트레이션 계층입니다. 개발자는 도커로 이미지를 만들고, 운영은 쿠버네티스로 그 이미지를 클러스터에 굴립니다.

한 가지 자주 나오는 질문은 “쿠버네티스가 도커를 버렸다는데?”입니다. 이는 쿠버네티스가 내부적으로 컨테이너를 실행할 때 쓰던 연결 부품(dockershim)을 걷어 내고 표준 인터페이스(CRI, Container Runtime Interface)를 따르는 런타임(containerd 등)으로 옮겨 간 사건을 가리킵니다. 개발자가 도커로 이미지를 빌드하는 흐름 자체는 그대로 유효합니다. 두 도구의 정확한 경계와 마이그레이션 포인트는 별도의 비교 글에서 더 상세히 다룹니다.

왜 지금 표준이 되었는가?

CNCF 연례 조사 기준 컨테이너 사용 조직의 프로덕션 쿠버네티스 사용률은 2023년 66%에서 2024년 80%로 올랐고, 검토·시범 단계까지 합치면 93%에 이릅니다.

쿠버네티스가 “표준”이라는 말은 분위기가 아니라 수치로 뒷받침됩니다. CNCF가 발표한 2024년 연례 클라우드 네이티브 조사에 따르면, 프로덕션 환경에서 쿠버네티스를 사용하는 비율은 80%로, 전년(2023년) 66%에서 크게 뛰었습니다. 여기에 파일럿·평가 단계 조직까지 더하면 응답자의 93%가 쿠버네티스에 발을 걸치고 있습니다(CNCF Annual Survey 2024). 이어 2026년 1월 공개된 2025년 조사에서는 컨테이너 사용자의 82%가 쿠버네티스를 프로덕션에서 운영한다고 답했습니다(CNCF, 2026-01-20).

이 수치가 인프라팀에 주는 신호는 분명합니다. 채용 시장, 벤더 지원, 오픈소스 생태계, 문서와 커뮤니티가 모두 쿠버네티스를 중심으로 모여 있다는 뜻입니다. 새 플랫폼을 고를 때 “쿠버네티스와 얼마나 잘 붙는가”가 사실상의 평가 기준이 된 이유이기도 합니다. 그래서 새 인프라 도구를 검토할 때는 쿠버네티스와 얼마나 매끄럽게 맞물리는지를 먼저 점검해야 합니다. 표준을 익혀 두는 일이 곧 팀의 이식성과 협상력을 지키는 일이 됐습니다.

AI 시대에 쿠버네티스는 왜 중요한가?

쿠버네티스는 웹 서비스 배포를 넘어, GPU 자원 스케줄링과 대규모 모델 학습·추론을 떠받치는 AI 인프라의 기본 골격으로 확장되고 있습니다.

최근 몇 년간 쿠버네티스의 무게 중심이 이동하고 있습니다. CNCF는 2025년 연례 조사 발표에서 쿠버네티스를 “AI를 위한 사실상의 운영체제(de facto operating system for AI)”로 규정했습니다(CNCF, 2026-01-20). AI 워크로드는 값비싼 GPU를 여러 작업이 나눠 쓰고, 학습 잡을 대량으로 병렬 실행하며, 추론 서비스를 트래픽에 맞춰 늘렸다 줄여야 합니다. 이 요구는 쿠버네티스가 원래 잘하던 자원 스케줄링·오토스케일링·자가 치유와 정확히 맞물립니다.

그래서 모델 학습·추론을 쿠버네티스 위에 올리는 도구(예: Kubeflow, KServe)와 GPU 자원을 정교하게 나누는 스케줄링 기법이 빠르게 자리 잡았습니다. 컴퓨터에 운영체제가 하드웨어를 추상화해 여러 프로그램에 나눠 주듯, 쿠버네티스는 클러스터 전체의 컴퓨팅 자원을 추상화해 AI를 포함한 여러 워크로드에 배분합니다. ‘컨테이너 관리 도구’에서 ‘분산 컴퓨팅의 공통 기반’으로 성격이 넓어진 셈입니다. AI 워크로드를 쿠버네티스에서 어떻게 운영하는지는 별도의 심화 글에서 이어집니다.

어디서부터 시작할까 — 학습·도입 경로

개념을 잡았다면, 아키텍처 → 파드 → 도커 비교 → 설치 → 네트워킹 → 사례 → AI → 도입 전략 순서로 좁혀 가면 학습 곡선이 완만해집니다.

이 글은 쿠버네티스의 큰 지도입니다. 각 지점을 깊이 파고들 수 있도록, 주제별 심화 글을 읽는 순서대로 묶었습니다. 처음이라면 위에서부터, 도입을 검토 중이라면 뒤쪽 사례·전략부터 보셔도 됩니다. 도입을 앞둔 팀이라면 어떤 서비스부터 컨테이너로 옮길지 우선순위를 결정해야 합니다.

쿠버네티스 아키텍처 완전 해부 — 컨트롤 플레인과 노드 — 클러스터의 두뇌와 일꾼이 어떻게 협력하는지
파드(Pod) 완벽 가이드 — 최소 실행 단위 다루기 — 파드 수명주기·멀티컨테이너·프로브
쿠버네티스 vs 도커 — 무엇이 어떻게 다른가 — 계층 차이와 흔한 오해 정리
k3s로 시작하는 경량 쿠버네티스 — 엣지·개발 환경을 위한 가벼운 배포판
쿠버네티스 설치 가이드 — 첫 클러스터 만들기 — 로컬부터 관리형까지 설치 경로
쿠버네티스 네트워킹과 CNI 이해하기 — 파드가 서로 통신하는 원리
쿠버네티스 프로덕션 도입 사례 — 실제 운영에서 얻은 교훈
쿠버네티스에서 AI 워크로드 운영하기 — GPU 스케줄링과 모델 서빙
쿠버네티스 도입 전략 — 무엇을 어떤 순서로 결정할까 — 조직 관점의 채택 로드맵

자주 묻는 질문 — FAQ 정리

쿠버네티스란 무엇인가요?
여러 서버에 걸쳐 컨테이너의 배포·확장·복구를 자동으로 관리하는 오픈소스 컨테이너 오케스트레이션 플랫폼입니다. 운영자가 원하는 상태를 선언하면, 쿠버네티스가 현재 상태를 그 목표에 맞춰 계속 조정합니다. 2014년 구글이 공개했고 지금은 CNCF가 관리하는 업계 표준입니다.

쿠버네티스와 도커는 무엇이 다른가요?
도커는 컨테이너를 만들고 실행하는 도구이고, 쿠버네티스는 그렇게 만든 컨테이너를 여러 서버에서 대규모로 운영하는 도구입니다. 둘은 경쟁 관계가 아니라 서로 다른 계층입니다. 개발자는 도커로 이미지를 만들고, 운영은 쿠버네티스로 그 이미지를 클러스터에 굴립니다.

쿠버네티스는 왜 K8s라고 부르나요?
Kubernetes의 첫 글자 K와 마지막 글자 s 사이에 있는 ‘ubernete’ 여덟 글자를 숫자 8로 줄인 표기입니다. 긴 이름을 짧게 쓰기 위한 관용 표기이며, 발음은 그대로 ‘쿠버네티스’입니다.

작은 조직도 쿠버네티스가 필요한가요?
서비스가 컨테이너 몇 개 규모라면 굳이 도입할 필요가 없을 수 있습니다. 다만 서비스 개수와 트래픽이 늘고 무중단 배포·자동 복구가 중요해지는 시점부터 이점이 커집니다. 규모가 작다면 k3s 같은 경량 배포판으로 부담을 줄여 시작할 수 있습니다.

쿠버네티스를 배우려면 무엇부터 봐야 하나요?
먼저 컨테이너와 도커의 기본을 익힌 뒤, 이 글로 전체 지도를 잡고, 아키텍처와 파드 개념으로 내려가는 순서를 권합니다. 로컬에 작은 클러스터를 띄워 kubectl로 파드와 디플로이먼트를 직접 만들어 보는 실습이 이해를 가장 빠르게 앞당깁니다.