10년 전의 쿠버네티스와 지금의 쿠버네티스
2014년 쿠버네티스가 세상에 나왔을 때, 많은 사람은 그것을 "컨테이너를 여러 대의 서버에 잘 배치해 주는 도구" 정도로 이해했다. 당시의 문제는 비교적 분명했다. 애플리케이션은 점점 작게 쪼개지고 있었고, 서버는 점점 많아지고 있었으며, 배포는 점점 자주 일어났다. 사람 손으로 어디에 어떤 컨테이너를 띄울지 정하는 방식은 오래 버틸 수 없었다.
그래서 쿠버네티스는 웹 서비스 시대의 운영체제처럼 자리 잡았다. API 서버, 프런트엔드, 백엔드, 큐 워커, 크론 잡이 쿠버네티스 위에서 돌아갔다. Deployment로 무중단 배포를 하고, Service로 내부 통신을 연결하고, Ingress로 외부 트래픽을 받아들이고, HPA로 CPU 사용률에 따라 파드를 늘렸다. 많은 쿠버네티스 입문서가 이 세계를 기준으로 쓰였다. 그것은 틀린 설명이 아니었다. 그 시대에는 그것이 쿠버네티스의 중심이었다.
그런데 2026년의 클러스터에 들어가 보면 풍경이 다르다. 이제 클러스터에는 단순한 웹 서버만 있는 것이 아니다. GPU 노드가 있고, 수십 기가바이트짜리 모델 가중치를 메모리에 올리는 추론 서버가 있고, 벡터 데이터베이스와 연결된 RAG 파이프라인이 있고, 사용자의 요청이 없을 때는 GPU 워크로드를 0개까지 줄이려는 오토스케일러가 있다. 어떤 파드는 몇 초 만에 응답을 끝내지만, 어떤 에이전트 파드는 외부 도구를 호출하고 상태를 유지하면서 몇 분 또는 몇 시간 동안 실행된다.
이 변화는 단순히 "쿠버네티스에서 AI도 돌릴 수 있다"는 정도의 이야기가 아니다. 무게중심이 이동했다. 쿠버네티스는 웹 서비스를 배포하는 플랫폼에서, 데이터 처리와 모델 학습, LLM 추론, AI 에이전트 실행이 함께 올라가는 공통 실행 환경으로 바뀌고 있다.
CNCF의 연례 클라우드 네이티브 조사도 이 흐름을 분명하게 보여준다. 2026년 1월 발표된 조사에서 컨테이너 사용자의 82%가 프로덕션 환경에서 쿠버네티스를 운영한다고 답했다. 쿠버네티스는 더 이상 실험용 기술이 아니라 운영 인프라의 기본값이 되었다.1 더 중요한 변화는 그다음이다. 생성형 AI 모델을 호스팅하는 조직의 상당수가 추론 워크로드의 일부 또는 전체를 쿠버네티스 위에서 운영하고 있으며, 관련 프로젝트와 표준화 논의도 쿠버네티스를 전제로 빠르게 움직이고 있다. 이제 AI 인프라 전략을 말하면서 쿠버네티스를 빼고 이야기하기 어려운 단계에 들어선 것이다.
마이크로서비스 플랫폼에서 AI 플랫폼으로
웹 서비스 시대의 쿠버네티스는 주로 "짧게 실행되고, 수평 확장하기 쉬우며, 상태를 바깥에 두는" 워크로드에 최적화되어 있었다. 예를 들어 쇼핑몰 API 서버를 생각해 보자. 트래픽이 늘면 같은 컨테이너를 여러 개 띄우면 된다. 하나가 죽어도 다른 파드가 요청을 받으면 된다. 대부분의 상태는 데이터베이스나 캐시에 있다.
AI 워크로드는 이보다 까다롭다. 데이터 전처리 작업은 수백 개의 CPU 코어를 한꺼번에 쓰고 끝나는 배치 작업일 수 있다. 모델 학습은 여러 GPU가 동시에 준비되어야 시작할 수 있다. LLM 추론은 사용자의 요청에 즉시 반응해야 하면서도, GPU 메모리와 KV 캐시를 세심하게 다뤄야 한다. 에이전트는 한 번의 요청으로 끝나지 않고, 대화 상태와 도구 호출 결과를 기억해야 한다.
이 네 가지 흐름은 서로 다른 성격을 가진다.
데이터 처리는 대량의 입력을 빠르게 가공하는 파이프라인이다.
학습은 비싼 GPU를 오래 점유하는 배치 작업이다.
추론은 지연 시간과 비용이 직접 사용자 경험으로 연결되는 온라인 서비스다.
에이전트는 상태와 권한, 외부 연결을 함께 다루는 장기 실행 워크로드다.
과거에는 이들이 서로 다른 시스템에서 돌아갔다. 데이터 처리는 Spark 클러스터에서, 학습은 별도의 HPC나 GPU 서버에서, 추론은 전용 모델 서버에서, 웹 애플리케이션은 쿠버네티스에서 운영하는 식이었다. 작은 팀에서는 처음에 이 구조가 편해 보인다. 각 도구가 자기 영역에서는 잘 작동하기 때문이다.
하지만 운영이 시작되면 문제가 달라진다. 인증 체계가 갈라지고, 모니터링 도구가 나뉘고, 배포 방식이 달라지고, 장애 대응 절차가 제각각이 된다. 모델은 학습 환경에서는 잘 동작했지만 추론 환경에서는 다른 드라이버와 라이브러리 때문에 실패한다. 데이터 파이프라인은 성공했지만 모델 서버 배포가 늦어져 출시가 밀린다. 비용을 줄이려고 GPU 서버를 껐다 켰더니 누가 어떤 작업을 돌리고 있었는지 추적하기 어렵다.
쿠버네티스가 AI 인프라의 중심으로 올라온 이유는 바로 이 지점에 있다. 쿠버네티스는 모든 문제를 자동으로 해결해 주는 마법 상자가 아니다. 그러나 서로 다른 워크로드를 하나의 운영 언어로 다룰 수 있게 해준다. 파드는 실행 단위가 되고, Job은 배치 작업의 단위가 되고, Service와 Gateway는 네트워크 진입점이 되고, RBAC는 권한의 기준이 되고, 네임스페이스는 팀과 환경을 나누는 경계가 된다.
CNCF는 AI 플랫폼이 쿠버네티스로 수렴하는 흐름을 설명하면서, 쿠버네티스 위에서 데이터 처리, 분산 학습, LLM 추론, 자율형 에이전트가 공존하는 현상을 플랫폼 컨버전스로 정리했다. 핵심은 단순하다. 각각의 워크로드를 별도 인프라에 흩어 놓을수록 운영 복잡도는 더해지는 것이 아니라 곱해진다. 반대로 쿠버네티스를 공통 기반으로 삼으면 배포, 관찰, 권한, 비용 관리의 언어를 통일할 수 있다.2
AI가 쿠버네티스를 필요로 하게 된 세 가지 압력
AI 인프라가 쿠버네티스로 모이는 배경에는 기술 유행만 있는 것이 아니다. 더 현실적인 압력이 있다. 비용, 복잡도, 확장성이다.
첫 번째 압력은 GPU 비용이다. 웹 서비스에서 CPU 몇 개를 낭비하는 것은 아깝지만, 회사의 존폐를 흔들 정도는 아닐 수 있다. 그러나 GPU는 다르다. 고성능 GPU 인스턴스가 시간 단위로 과금되는 환경에서 유휴 시간이 길어지면 비용은 빠르게 불어난다. 더 무서운 점은 GPU가 "있다"는 사실만으로는 충분하지 않다는 것이다. 적절한 모델이 적절한 GPU에 배치되어야 하고, 작은 모델은 한 장의 GPU를 나눠 써야 하며, 트래픽이 없을 때는 워크로드와 노드가 함께 줄어야 한다.
웹 서비스 시대의 오토스케일링은 주로 CPU 사용률이나 요청 수를 봤다. AI 추론에서는 그것만으로 부족하다. 큐에 쌓인 요청 수, 초당 토큰 처리량, Time To First Token, GPU 메모리 사용률, KV 캐시 적중률 같은 지표가 중요해진다. 사용자는 "응답이 왔다"보다 "첫 토큰이 얼마나 빨리 나오느냐"에 민감하다. 운영자는 "파드가 살아 있다"보다 "토큰당 비용이 얼마냐"를 봐야 한다.
두 번째 압력은 운영 복잡도다. AI 서비스는 모델 하나를 띄우는 순간부터 여러 종류의 운영 문제를 만든다. 모델 가중치는 컨테이너 이미지보다 훨씬 클 수 있고, 콜드 스타트는 몇 초가 아니라 수십 초 이상 걸릴 수 있다. GPU 드라이버와 CUDA 버전이 맞지 않으면 파드는 떠도 추론은 실패한다. 모델을 새 버전으로 바꿀 때는 일반적인 코드 배포처럼 롤백이 쉬워야 하지만, 동시에 품질 저하나 응답 지연 같은 모델 특유의 위험도 감시해야 한다.
세 번째 압력은 멀티클러스터 확장성이다. AI 워크로드는 한 클러스터 안에서만 끝나지 않는다. 어떤 팀은 온프레미스 GPU를 쓰고, 어떤 팀은 클라우드의 H100 노드를 빌리며, 어떤 서비스는 지연 시간을 줄이기 위해 특정 리전에 가까이 배치된다. 규제나 데이터 주권 때문에 특정 데이터는 특정 지역 밖으로 나가면 안 될 수도 있다. 이때 필요한 것은 단일 벤더에 묶인 전용 플랫폼이 아니라, 여러 환경을 같은 방식으로 다룰 수 있는 공통 제어면이다.
쿠버네티스가 선택받는 이유는 여기서 분명해진다. 쿠버네티스는 이미 멀티클라우드와 하이브리드 환경에서 검증된 추상화를 갖고 있다. 이제 그 추상화가 GPU, 모델, 추론 라우팅, 에이전트 실행 쪽으로 확장되고 있다.
추론이 인프라의 중심으로 온다
AI를 처음 접할 때 사람들은 보통 학습을 떠올린다. 거대한 데이터셋, 수천 장의 GPU, 몇 주에 걸친 훈련, 새로운 모델 발표. 물론 학습은 여전히 중요하다. 하지만 많은 기업의 현실은 조금 다르다. 모든 회사가 자체 파운데이션 모델을 처음부터 학습하는 것은 아니다. 오히려 대부분의 팀은 이미 만들어진 모델을 가져와 제품에 붙이고, 필요하면 파인튜닝하거나 RAG로 보강하고, 안정적으로 사용자에게 제공하는 문제와 씨름한다.
다시 말해 많은 조직에서 핵심 병목은 "모델을 만들 수 있느냐"보다 "모델을 잘 운영할 수 있느냐"로 이동하고 있다. 추론은 반복적으로 발생한다. 사용자가 질문할 때마다, 문서를 요약할 때마다, 코드를 생성할 때마다, 고객 상담을 자동화할 때마다 추론 비용이 발생한다. 학습은 가끔 큰 비용을 쓰지만, 추론은 매일 비용을 만든다.
그래서 2026년의 AI 인프라 논의는 점점 추론 중심으로 바뀐다. vLLM과 SGLang 같은 런타임은 continuous batching과 PagedAttention 같은 기법으로 GPU 처리량을 높인다. KServe는 모델 서빙을 쿠버네티스 네이티브 방식으로 추상화한다. KEDA는 큐나 이벤트를 기준으로 워크로드를 늘리고 줄인다. Kueue는 여러 팀이 제한된 GPU를 공정하게 나눠 쓰도록 돕는다. Dynamic Resource Allocation, MIG, time-slicing 같은 기술은 GPU를 더 세밀하게 나누고 배치하는 방향으로 발전하고 있다.
여기서 중요한 점은 이 도구들이 쿠버네티스 바깥의 별도 세계로 발전하는 것이 아니라는 사실이다. 오히려 쿠버네티스의 API, 컨트롤러, 스케줄러, Gateway, 네임스페이스, RBAC 위에 올라오고 있다. AI 인프라 생태계가 쿠버네티스를 전제로 설계되기 시작한 것이다.
네트워킹도 AI를 이해해야 한다
웹 서비스에서 게이트웨이는 주로 HTTP 요청을 적절한 서비스로 전달했다. 경로가 /api/users이면 사용자 서비스로 보내고, /api/orders이면 주문 서비스로 보내는 식이다. AI 시대의 게이트웨이는 더 많은 것을 알아야 한다.
예를 들어 같은 /v1/chat/completions 엔드포인트로 들어온 요청이라도, 어떤 요청은 짧은 질의이고 어떤 요청은 긴 문서를 포함한다. 어떤 요청은 무료 사용자에게서 왔고, 어떤 요청은 높은 우선순위를 가진 기업 고객의 요청이다. 어떤 요청은 내부 모델로 처리해도 되지만, 어떤 요청은 특정 지역의 외부 모델 API로 보내야 한다. 어떤 요청은 프롬프트 인젝션 공격 가능성이 있어 본문 검사가 필요하다.
이런 이유로 쿠버네티스 커뮤니티에서는 AI Gateway에 대한 논의가 활발해지고 있다. Kubernetes AI Gateway Working Group은 Gateway API를 기반으로 AI 트래픽에 특화된 정책, 라우팅, 보안, 페이로드 처리 표준을 만들기 위해 출범했다. 여기에는 토큰 기반 rate limiting, 추론 API 접근 제어, 요청 본문 검사, 의미 기반 라우팅, 외부 AI 서비스로의 안전한 egress 같은 주제가 포함된다.3
이 변화는 앞으로 우리가 네트워킹을 바라보는 방식을 바꾼다. AI 요청은 단순한 HTTP 패킷이 아니다. 그 안에는 비용이 있고, 권한이 있고, 데이터 보안 위험이 있고, 모델 선택의 의사결정이 있다. 쿠버네티스의 Gateway는 점점 "어디로 보낼 것인가"뿐 아니라 "어떤 모델로, 어떤 정책 아래, 어떤 비용 한도 안에서 처리할 것인가"를 결정하는 지점이 된다.
Disaggregated 추론: 쿠버네티스가 더 어려운 일을 맡기 시작했다
LLM 추론은 겉으로 보면 하나의 요청과 하나의 응답처럼 보인다. 하지만 내부에서는 크게 두 단계가 일어난다. 먼저 사용자의 입력 프롬프트를 읽고 문맥을 만드는 prefill 단계가 있다. 그다음 한 토큰씩 답변을 생성하는 decode 단계가 이어진다.
이 두 단계는 GPU를 쓰는 방식이 다르다. prefill은 많은 입력 토큰을 한꺼번에 처리하므로 계산 성능이 중요하다. decode는 이전 토큰과 KV 캐시를 계속 참조하면서 다음 토큰을 생성하므로 메모리 대역폭과 캐시 관리가 중요하다. 하나의 서버에서 두 단계를 모두 처리하면 단순하다는 장점은 있지만, GPU를 항상 최적으로 쓰기는 어렵다.
그래서 대규모 추론에서는 prefill과 decode를 분리하는 disaggregated 추론 아키텍처가 등장했다. prefill worker, decode worker, router를 나누고, 각 단계에 맞는 GPU와 스케일링 정책을 적용하는 방식이다. NVIDIA는 disaggregated serving을 설명하면서 prefill과 decode가 서로 다른 자원 특성을 가지므로, 이를 독립 서비스로 분리하면 각 단계에 맞는 최적화와 독립 확장이 가능하다고 설명한다.4
이 구조는 쿠버네티스에 새로운 숙제를 던진다. 단순히 파드를 여러 개 띄우는 것으로는 부족하다. 서로 관련된 파드들이 같은 고속 네트워크 안에 배치되어야 하고, 텐서 병렬 그룹은 일부만 스케줄되면 안 되며, prefill과 decode 사이의 KV 캐시 이동도 고려해야 한다. 즉 스케줄러는 "빈 노드에 파드를 넣는" 수준을 넘어, AI 워크로드의 구조를 이해해야 한다.
이 책의 뒷부분에서 다룰 LeaderWorkerSet, Kueue, JobSet, GPU DRA, llm-d, NVIDIA Dynamo/Grove 같은 도구들은 바로 이 문제를 해결하기 위해 등장한 흐름이다. 지금은 이름이 낯설어도 괜찮다. 중요한 것은 방향이다. 쿠버네티스는 웹 서버를 배치하는 시스템에서, 여러 GPU와 여러 단계의 추론 파이프라인을 조율하는 시스템으로 확장되고 있다.
에이전트는 또 다른 종류의 워크로드다
LLM 추론 서버를 운영할 수 있게 되면 다음 질문이 찾아온다. "그럼 에이전트는 어떻게 운영하지?"
에이전트는 단순한 챗봇과 다르다. 하나의 요청을 받아 한 번 답하고 끝나는 구조가 아니다. 목표를 세우고, 필요한 정보를 찾고, 외부 도구를 호출하고, 결과를 검토하고, 다시 다음 행동을 결정한다. 이 과정에서 여러 번의 LLM 호출이 일어나며, 중간 상태를 기억해야 하고, 실패했을 때 재시도해야 한다.
웹 API 서버는 보통 요청 하나가 짧다. 반면 에이전트는 오래 실행될 수 있다. 웹 API 서버는 상태를 데이터베이스에 넘기고 스스로는 가벼워지는 방향으로 설계되었다. 반면 에이전트는 실행 중인 계획, 도구 호출 이력, 대화 상태, 임시 파일, 권한 토큰 같은 것을 다뤄야 한다. 웹 API 서버가 외부 API 하나를 호출하는 정도라면, 에이전트는 검색 API, 코드 실행 환경, 사내 문서, 결제 시스템, 이메일 발송 도구까지 연결할 수 있다.
이것은 쿠버네티스에 새로운 운영 질문을 만든다. 에이전트의 상태는 어디에 저장할 것인가? 사용자가 업로드한 파일은 어떤 볼륨에 둘 것인가? 외부 도구 호출 권한은 어떻게 제한할 것인가? 잘못된 프롬프트나 악의적인 명령이 들어왔을 때 에이전트가 내부 시스템을 함부로 건드리지 못하게 하려면 어떻게 해야 하는가? 에이전트가 생성한 코드를 실행해야 한다면, 그 코드는 어떤 샌드박스 안에서 실행해야 하는가?
이 책이 AI 에이전트를 별도 파트로 다루는 이유가 여기에 있다. 에이전트는 "추론 서버를 조금 더 복잡하게 만든 것"이 아니다. 긴 실행, 상태 유지, 외부 도구 호출, 보안 경계가 한꺼번에 들어오는 새로운 워크로드다. 그리고 이 워크로드를 안전하게 운영하려면 쿠버네티스의 StatefulSet, PersistentVolume, NetworkPolicy, Workload Identity, gVisor, Kata Containers 같은 도구를 AI 관점에서 다시 보아야 한다.
왜 지금 다시 쿠버네티스를 배워야 하는가
이미 쿠버네티스를 배운 적이 있는 독자라면 이런 생각이 들 수 있다. "Pod, Deployment, Service는 예전에 공부했는데, 다시 배워야 하나?"
답은 "기초는 그대로지만, 질문이 바뀌었다"이다.
Pod는 여전히 Pod다. Deployment는 여전히 Deployment다. Service는 여전히 Service다. 그러나 2026년에 우리가 그것들을 쓰는 방식은 달라졌다. 예전에는 Deployment로 웹 서버를 몇 개 띄우는 것이 핵심이었다. 이제는 vLLM 서버를 어떤 GPU 노드에 배치할지, 모델 가중치를 어떻게 캐시할지, readiness probe를 얼마나 길게 잡을지, 종료 중인 파드가 진행 중인 토큰 생성을 끝낼 시간을 어떻게 줄지 고민해야 한다.
예전에는 HPA가 CPU 70%를 넘으면 파드를 늘리면 됐다. 이제는 큐 길이, TTFT, GPU 메모리, 토큰 처리량, KV 캐시 사용률을 봐야 한다. 예전에는 노드가 부족하면 일반 인스턴스를 몇 대 더 붙이면 됐다. 이제는 GPU 종류, VRAM 용량, NVLink나 RDMA 같은 연결 구조, 스팟 인스턴스 중단 가능성까지 고려해야 한다.
예전에는 장애 대응이 ImagePullBackOff, CrashLoopBackOff, OOMKilled를 찾는 일이었다. 이제도 그것은 중요하다. 그러나 거기에 "GPU가 노드에서 보이지 않는다", "모델 로딩이 너무 오래 걸린다", "첫 토큰 지연이 갑자기 늘었다", "큐는 비었는데 사용자는 느리다고 한다", "GPU 사용률은 높은데 처리량은 낮다" 같은 문제가 추가된다.
그래서 지금 다시 쿠버네티스를 배워야 한다. 처음부터 모든 것을 새로 배운다는 뜻은 아니다. 이미 알고 있는 쿠버네티스의 기본기를 AI 워크로드라는 새로운 현실 위에 다시 배치해야 한다는 뜻이다.
이 책이 다루는 것
이 책은 쿠버네티스 입문서이면서 동시에 입문서가 아니다. Pod와 Deployment 같은 기본 개념을 빠르게 복습하겠지만, 이 책의 중심은 거기에 머물지 않는다. 목표는 독자가 "웹 서비스용 쿠버네티스"에서 "AI 인프라용 쿠버네티스"로 넘어가도록 돕는 것이다.
앞부분에서는 쿠버네티스의 기본기를 AI 관점에서 다시 정리한다. 클러스터를 어떻게 선택할지, 네임스페이스와 RBAC를 어떻게 설계할지, Job과 Deployment를 어떤 기준으로 나눌지, Gateway API와 스토리지 전략이 AI 워크로드에서 왜 중요한지 살펴본다. 이미 쿠버네티스를 써본 독자는 빠르게 지나갈 수 있고, 처음 접하는 독자는 뒤의 AI 장을 읽기 위한 최소한의 바닥을 만들 수 있다.
중반부에서는 이 책의 핵심인 AI 워크로드 운영을 다룬다. GPU 스케줄링, NVIDIA GPU Operator, Dynamic Resource Allocation, MIG, time-slicing, Kueue, JobSet, vLLM, SGLang, KServe, LLMInferenceService, disaggregated 추론, KEDA 기반 오토스케일링을 실제 운영 관점에서 설명한다. 여기서는 단순히 YAML을 붙여 넣는 것이 아니라, 왜 그런 구조가 필요한지부터 풀어갈 것이다.
후반부에서는 AI 에이전트와 프로덕션 운영으로 넘어간다. 에이전트의 상태 관리, 벡터 DB 통합, 외부 도구 호출 통제, Workload Identity, 샌드박스 격리, 비용 최적화, 보안, GitOps, 장애 대응 플레이북을 다룬다. 운영자는 결국 장애와 비용 앞에서 실력을 검증받는다. 이 책은 멋진 데모에서 끝나지 않고, 장애가 났을 때 어디를 봐야 하는지까지 함께 다룬다.
이 책이 다루지 않는 것
반대로 이 책이 다루지 않는 것도 분명히 해두자. 이 책은 트랜스포머 구조를 설명하는 책이 아니다. 어텐션 메커니즘을 수식으로 유도하거나, 모델 학습 알고리즘을 깊게 다루지 않는다. PyTorch나 TensorFlow로 모델을 만드는 법도 중심 주제가 아니다. 파인튜닝 기법, 데이터셋 구축, 프롬프트 엔지니어링도 필요한 만큼만 언급할 뿐, 그 자체를 깊게 파고들지는 않는다.
이런 주제는 이미 좋은 자료와 책이 많다. 이 책이 집중하는 질문은 다르다.
"이미 모델이 있다. 이것을 어떻게 안정적으로, 비용 효율적으로, 확장 가능하게 운영할 것인가?"
이 질문에 답하기 위해 우리는 쿠버네티스를 다시 본다. 모델의 성능을 1% 올리는 방법보다, 모델 서버가 죽었을 때 자동으로 복구되는 방법을 본다. 벤치마크 점수보다, 토큰당 비용과 p99 지연 시간을 본다. 노트북에서 한 번 성공한 코드보다, 팀이 반복해서 배포하고 롤백할 수 있는 플랫폼을 본다.
쿠버네티스는 AI의 목적지가 아니라 출발점이다
쿠버네티스를 배운다고 해서 AI 인프라 문제가 모두 해결되지는 않는다. 오히려 쿠버네티스를 제대로 쓰기 시작하면 더 많은 문제가 선명하게 보인다. GPU가 왜 비어 있는데도 파드가 Pending인지, 모델을 왜 매번 다시 다운로드하는지, 오토스케일링을 했는데 왜 지연 시간이 줄지 않는지, 에이전트가 왜 외부 도구 호출에서 병목이 생기는지 알게 된다.
하지만 그것이 출발점이다. 보이지 않던 문제가 보이기 시작해야 고칠 수 있다. 쿠버네티스는 AI 인프라의 모든 답이 아니라, 문제를 표현하고 자동화하고 반복해서 개선할 수 있는 공통 언어다.
웹 서비스 시대의 쿠버네티스는 "컨테이너를 어디에서 실행할 것인가"에 답했다. AI 시대의 쿠버네티스는 더 넓은 질문을 받는다. "비싼 GPU를 어떻게 나눠 쓸 것인가?" "모델을 어떻게 배포하고 롤백할 것인가?" "추론 요청을 어떤 모델과 어떤 캐시로 보낼 것인가?" "에이전트가 외부 세계와 상호작용할 때 어떤 경계를 둘 것인가?" "장애와 비용을 어떻게 운영 가능한 수준으로 낮출 것인가?"
이 책은 그 질문들에 대한 긴 답이다. 이제부터 우리는 쿠버네티스를 다시 배울 것이다. 단, 이번에는 nginx를 띄우기 위해서가 아니다. LLM 추론과 AI 에이전트가 표준 워크로드가 된 시대의 인프라를 운영하기 위해서다.
참고
1The CNCF Annual Cloud Native Survey: The Infrastructure of AI's Future
2The great migration: Why every AI platform is converging on Kubernetes
3Announcing the AI Gateway Working Group
4Deploying Disaggregated LLM Inference Workloads on Kubernetes
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.