쿠버네티스(Kubernetes), 생각보다 어렵지 않다

왜 지금 쿠버네티스인가

얼마 전 기존 서버 환경을 컨테이너로 옮기는 프로젝트를 하면서 쿠버네티스를 다시 들여다봤습니다. Docker는 이미 손에 익었는데, 왜 이 무거운 도구가 한 겹 더 필요한지 솔직히 의심스러웠습니다. 컨테이너 몇 개 띄우는 거면 docker run으로 끝나는 거 아닌가. 한동안 그렇게 생각하고 버텼습니다.

답은 싱거웠습니다. 컨테이너 한 개를 다루는 일과 수십 개를 다루는 일은 아예 다른 문제였습니다. 한 개일 때는 손으로 띄우고 손으로 죽이면 그만입니다. 수십 개가 되는 순간부터는 어느 컨테이너가 죽었는지, 트래픽을 어디로 보낼지, 부하가 몰리면 몇 개를 더 띄울지를 사람 눈으로 따라갈 수 없게 됩니다. 쿠버네티스는 이 규모의 문제 하나를 풀려고 나온 도구입니다.

쿠버네티스가 대신 감당하는 건 컨테이너가 아니라 운영자의 주의력입니다.

현재 조직의 77%가 컨테이너 사용을 넓히고 있고, 쿠버네티스는 컨테이너 오케스트레이션의 표준 자리를 굳혔습니다. 2026년 기준으로 클라우드 네이티브 환경에서 이걸 빼고 인프라 그림을 그리기가 어렵습니다. 좋든 싫든 한 번은 마주치는 기술이 됐습니다.

쿠버네티스가 정확히 뭘까

쿠버네티스(Kubernetes, 줄여서 K8s)는 컨테이너화된 애플리케이션을 자동으로 배포하고, 확장하고, 관리하는 오픈소스 플랫폼입니다. 그리스어로 조타수 또는 선장을 뜻하는 단어입니다. 배를 목적지까지 안전하게 끌고 가는 역할이라는 뜻이죠.

구글이 2014년에 오픈소스로 공개했는데, 어느 날 갑자기 만든 물건이 아닙니다. 내부에서 수십억 개 단위의 컨테이너를 굴리던 Borg 시스템의 운영 경험이 바탕에 깔려 있습니다. 처음부터 '대규모를 어떻게 굴릴 것인가'를 붙잡고 출발한 도구라는 뜻입니다. 이 출신 배경을 알고 나서야 왜 구조가 이렇게 생겼는지가 조금씩 납득되기 시작했습니다.

쿠버네티스가 대신 해주는 일은 크지 않은 목록입니다. 컨테이너를 어느 자리에 올릴지 정해서 배포하고, 애플리케이션 상태를 지켜보다가 죽으면 다시 세우고, 트래픽에 따라 수를 늘리거나 줄이고, 서비스 사이의 네트워킹과 로드 밸런싱을 처리하고, 설정과 보안 정보를 따로 떼어 관리합니다. 다섯 줄이면 끝납니다. 문제는 이 다섯 줄을 사람이 수십 개 컨테이너에 대고 손으로 하려면 밤을 새워도 안 된다는 데 있습니다.

음식 배달 서비스에 빗대보면 이해가 빠릅니다. 주문량에 따라 배달원을 자동으로 늘리고 줄이고, 배달원이 갑자기 빠지면 즉시 대체 인력을 투입하고, 가장 빠른 경로로 음식을 보내는 관리 시스템. 쿠버네티스가 컨테이너를 상대로 하는 일이 딱 이겁니다. 사람이 일일이 챙기지 않아도 알아서 돌아가게 만든다는 것.

인프라의 진화 과정

쿠버네티스가 왜 이런 모양인지 이해하려면, 인프라가 어떤 흐름으로 발전해왔는지를 같이 봐야 합니다.

시대	특징	장점	단점
물리 서버	서버 1대에 앱 1개	안정성, 성능	자원 낭비, 확장성 제한
가상화	서버 1대에 VM 여러 개	자원 효율성 증대	무거운 OS, 느린 시작
컨테이너	가벼운 애플리케이션 패키징	빠른 시작, 이식성	대규모 관리 복잡성
쿠버네티스	컨테이너 오케스트레이션	자동화, 확장성, 안정성	초기 학습 곡선

각 단계는 앞 단계가 남긴 숙제를 받아서 넘어왔습니다. 물리 서버는 자원을 통째로 놀렸고, 가상화는 그걸 쪼갰지만 OS가 통째로 따라붙어 무거웠습니다. 컨테이너가 패키징과 기동 속도를 해결하자 이번엔 그 컨테이너가 수백 개로 불어났고, 관리라는 새 문제가 튀어나왔습니다. 쿠버네티스는 컨테이너가 흔해진 다음에야 필요해진 위층입니다.

쿠버네티스 아키텍처

클러스터는 크게 두 부분으로 나뉩니다. 머리에 해당하는 부분과, 실제로 일하는 부분입니다.

Control Plane (제어 평면)

클러스터의 두뇌입니다. 모든 요청은 API Server라는 하나의 문으로 들어오고, 클러스터의 상태 데이터는 etcd라는 데이터베이스에 전부 쌓입니다. Scheduler는 새로 뜰 Pod를 어느 노드에 올릴지 판단하고, Controller Manager는 원하는 상태가 유지되는지 끊임없이 감시하다가 어긋나면 보정합니다.

여기서 Controller Manager가 하는 '원하는 상태를 유지한다'는 개념이 쿠버네티스의 철학 그 자체입니다. 사람은 "이렇게 돼 있어야 해"라고 선언만 해둡니다. 그러면 시스템이 현재 상태와 비교해서 차이를 줄입니다. 컨트롤 루프라고 부르는 이 구조가 자동 복구의 뿌리입니다.

Worker Node (워커 노드)

애플리케이션이 실제로 돌아가는 자리입니다. kubelet이 컨테이너 실행을 책임지는 에이전트로 노드마다 앉아 있고, kube-proxy가 네트워킹을 처리하고, 그 아래에서 Container Runtime(주로 containerd)이 컨테이너를 실제로 띄웁니다.

Pod: 쿠버네티스의 최소 단위

Pod는 쿠버네티스에서 가장 먼저 이해해야 할 개념입니다. 그리고 입문할 때 제일 많이 걸려 넘어지는 지점이기도 합니다. 쿠버네티스는 컨테이너를 직접 배포하지 않습니다. 컨테이너를 Pod라는 껍데기로 한 번 감싸서 배포합니다.

Pod는 보통 컨테이너 1개를 담습니다. 이게 가장 흔한 모양입니다. 같은 Pod 안의 컨테이너들은 네트워크와 스토리지를 공유하고, Pod 자체는 고유한 IP 주소를 하나 받습니다. 그러면서도 일시적인 존재입니다. 언제든 삭제되고 재생성됩니다.

왜 컨테이너를 직접 안 쓰고 한 겹 더 감쌀까요. 밀접하게 붙어 다녀야 하는 컨테이너들을 한 묶음으로 다루기 위해서입니다. 웹 애플리케이션과 그 로그를 긁어가는 수집기가 항상 같은 자리에 있어야 한다면, 같은 Pod에 넣어 한 몸으로 관리합니다. Pod가 언제든 죽고 다시 태어난다는 성질은 뒤에 나올 Service와 확장 얘기에 계속 따라붙으니 여기서 기억해두는 편이 낫습니다.

구성 요소들

가장 많이 쓰는 워크로드 타입은 Deployment입니다. 무상태(stateless) 애플리케이션을 관리할 때 쓰고, Pod를 자동으로 만들고 교체합니다. Pod가 죽어도 Deployment가 알아서 새로 띄우기 때문에, 실무에서 앱을 올린다고 하면 대부분 Deployment를 거칩니다.

Service: 네트워크 접근점

Pod는 일시적이라 IP가 계속 바뀝니다. 방금 통신하던 Pod가 다음 순간엔 다른 IP로 떠 있기도 합니다. Pod IP를 직접 물고 가면 안 되는 이유입니다. Service는 이 변덕스러운 Pod들 앞에 고정된 접근점을 세워줍니다. 클러스터 안에서만 닿게 할 거면 ClusterIP, 노드의 특정 포트를 열어 밖에서 들어오게 하려면 NodePort, 클라우드의 로드밸런서와 붙이려면 LoadBalancer를 씁니다.

설정과 데이터

애플리케이션 설정은 코드에서 떼어내 따로 둡니다. 평범한 설정값은 ConfigMap에, 비밀번호나 API 키 같은 민감한 정보는 Secret에 넣습니다. 깔끔해서 그렇게 하는 게 아닙니다. 같은 이미지를 개발·스테이징·운영에 그대로 올리되 환경별 값만 갈아끼우려는 겁니다. 환경마다 이미지를 다시 빌드하지 않아도 된다는 것, 여기가 실무에서 체감되는 지점입니다.

컨테이너는 기본적으로 무상태입니다. 죽으면 안에 있던 데이터도 같이 사라집니다. 그런데 데이터베이스처럼 상태를 지켜야 하는 경우가 있습니다. 이때 PV(Persistent Volume)를 붙여 컨테이너 생명주기와 데이터를 떼어놓습니다.

kubectl: 쿠버네티스와 대화하는 방법

kubectl은 클러스터에 명령을 던지는 CLI 도구입니다. 쿠버네티스와 대화하는 입이라고 보면 됩니다. 자주 쓰는 명령어만 추려보면:

# 리소스 조회
kubectl get pods
kubectl get services
kubectl get deployments

# 자세한 정보 확인
kubectl describe pod my-pod
kubectl logs my-pod

# 리소스 생성/수정
kubectl apply -f app.yaml
kubectl create deployment nginx --image=nginx

# 스케일링
kubectl scale deployment my-app --replicas=5

# 디버깅
kubectl exec -it my-pod -- bash

처음에는 get, describe, logs 이 셋만 손에 붙어도 절반은 합니다. 장애가 났을 때 사람이 하는 일이라는 게 상태 보고, 자세히 들여다보고, 로그 까는 것의 반복이거든요.

확장의 비밀

확장할 때 짚고 넘어가야 할 원칙이 하나 있습니다. Pod 안에 컨테이너를 더 채워 넣는 게 아니라, Pod 자체를 여러 개로 늘린다는 겁니다.

트래픽이 몰렸다고 해봅시다. Pod 1개에 컨테이너 3개를 욱여넣는 방향은 틀렸고, 컨테이너 1개씩 담은 Pod 3개를 띄우는 방향이 맞습니다. 이걸 수평 확장(Horizontal Scaling)이라고 부릅니다. 쿠버네티스가 확장성을 갖는 지점이 여기입니다. Pod가 일시적이고 똑같은 단위로 복제된다는 성질이, 같은 걸 여러 개 찍어내 부하를 나눈다는 단순한 전략으로 이어집니다.

HPA(Horizontal Pod Autoscaler)를 걸어두면 CPU나 메모리 사용률을 보고 Pod 수를 알아서 조절합니다. 새벽에 트래픽이 빠지면 줄이고, 낮에 몰리면 늘리고. 사람이 지켜보지 않아도 규모가 따라 움직이게 만드는 게 이 도구가 노리는 바입니다.

실무에서의 쿠버네티스

2026년 기준으로 쿠버네티스가 중심에 앉은 자리는 대충 정해져 있습니다. 마이크로서비스 아키텍처에서 서비스 간 통신과 배포·관리를 받치고, CI/CD 파이프라인에서는 GitOps와 붙어 배포를 자동화합니다. 클라우드 네이티브 애플리케이션은 클라우드의 탄력성을 그대로 받아쓰고, 하이브리드나 멀티 클라우드 환경에서는 여러 클라우드를 한 결로 묶는 층 역할을 합니다.

ChatGPT 같은 대규모 AI 서비스도 내부적으로 쿠버네티스 위에서 트래픽을 처리하고 있죠. 예측하기 어려운 부하를 자동으로 받아내야 하는 서비스일수록 이 구조로 수렴하는 흐름이 보입니다.

시작하는 방법

로컬에서 직접 만져보고 싶다면 부담 적은 길이 있습니다. Minikube로 단일 노드 클러스터를 띄워 연습하거나, 경량화된 배포판인 K3s를 쓰거나, 이미 Docker Desktop을 깔아뒀다면 내장된 쿠버네티스 기능을 켜면 됩니다. 저는 세 번째가 제일 게으르면서 제일 빨랐습니다.

실제 운영으로 가면 얘기가 다릅니다. 직접 클러스터를 구축하기보다 관리형 서비스를 쓰는 쪽이 일반적입니다. Control Plane 운영 자체가 또 하나의 일거리라서요. AWS EKS, Google GKE, Azure AKS, Naver Cloud Platform NKS 중에서 이미 쓰고 있는 클라우드를 따라가면 됩니다.

---

쿠버네티스는 처음 마주하면 용어부터 쏟아져서 복잡해 보입니다. 개념을 하나씩 끊어 따라가다 보면 의외로 일관된 논리 위에 서 있다는 게 보입니다. 선언하면 알아서 맞춰준다는 원칙 하나가 Pod부터 확장, 자동 복구까지 전부 관통하고 있거든요.

입문 단계에서 모든 컴포넌트를 외울 필요는 없다고 봅니다. 규모가 커질 때 사람이 못 따라가는 부분을 기계가 대신 받아준다는 큰 그림만 잡아두면, 나머지는 필요할 때 하나씩 채워 넣게 됩니다.

그런데 제목에 '어렵지 않다'고 적어놓고 이만큼 쓴 걸 보면, 그 말이 맞는지 저도 잘 모르겠습니다.