☸️ 쿠버네티스(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 안의 컨테이너들은 네트워크와 스토리지를 공유
• 고유한 IP 주소를 가짐
• 일시적인 존재 — 언제든 삭제되고 재생성됨

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

핵심 구성 요소들

Deployment: 애플리케이션 관리자

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

Service: 네트워크 접근점

Pod는 일시적이라 IP가 계속 바뀝니다. 방금 통신하던 Pod가 다음 순간엔 다른 IP로 떠 있을 수 있죠. 그래서 Pod IP를 직접 물고 가면 안 됩니다. Service는 이 변덕스러운 Pod들 앞에 고정된 접근점을 세워줍니다.

• ClusterIP: 클러스터 내부에서만 접근
• NodePort: 노드의 특정 포트를 열어 외부에서 접근
• LoadBalancer: 클라우드의 로드밸런서와 연동

ConfigMap과 Secret

애플리케이션 설정을 코드에서 떼어내 따로 관리합니다.

• ConfigMap: 일반적인 설정값
• Secret: 비밀번호, API 키 같은 민감한 정보

설정을 코드와 분리한다는 건 단순히 깔끔해서가 아닙니다. 같은 이미지를 개발·스테이징·운영에 그대로 올리되, 환경별 값만 갈아끼우기 위해서죠. 이미지를 환경마다 다시 빌드하지 않아도 된다는 게 핵심입니다.

Persistent Volume

컨테이너는 기본적으로 무상태입니다. 죽으면 안에 있던 데이터도 같이 사라지죠. 그런데 데이터베이스처럼 상태를 지켜야 하는 경우가 있습니다. 이때 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개를 욱여넣기
• ✅ Pod 3개를 띄우기 (각각 컨테이너 1개)

이걸 **수평 확장(Horizontal Scaling)**이라고 합니다. 쿠버네티스가 높은 확장성을 갖는 핵심이 바로 여기 있습니다. Pod가 일시적이고 동일한 단위로 복제 가능하다는 성질이, 결국 '같은 걸 여러 개 찍어내 부하를 나눈다'는 단순한 전략으로 이어지는 거죠.

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

실무에서의 쿠버네티스

2026년 기준으로 쿠버네티스는 다음 영역에서 중심축 역할을 합니다.

• 마이크로서비스 아키텍처: 서비스 간 통신, 배포, 관리
• CI/CD 파이프라인: GitOps와 결합한 자동화 배포
• 클라우드 네이티브 애플리케이션: 클라우드의 탄력성을 그대로 활용
• 하이브리드/멀티 클라우드: 여러 클라우드 환경을 한 결로 묶기

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

시작하는 방법

로컬에서 직접 만져보고 싶다면 이쪽이 부담이 적습니다.

1. Minikube: 로컬에 단일 노드 클러스터를 띄워 연습
2. K3s: 경량화된 쿠버네티스 배포판
3. Docker Desktop: 내장된 쿠버네티스 기능 켜기

실제 운영으로 가면 직접 클러스터를 구축하기보다 관리형 서비스를 쓰는 게 일반적입니다. Control Plane 운영 자체가 또 하나의 일거리라서요.

• AWS EKS
• Google GKE
• Azure AKS
• Naver Cloud Platform NKS

---

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

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