소규모 팀을 위한 도입 체크리스트

쿠버네티스는 목표가 아니라 선택지다

쿠버네티스를 배우다 보면 이상한 착시가 생긴다. Pod, Deployment, Service, Ingress, Gateway API, HPA, KEDA, KServe, Kueue, GPU Operator까지 익히고 나면 모든 문제의 답이 쿠버네티스처럼 보인다. 새 서비스를 만들 때도 "클러스터부터 만들까?"라는 생각이 먼저 든다.

하지만 1인 개발자와 소규모 팀에게 가장 중요한 질문은 다르다.

"쿠버네티스를 쓸 수 있는가?"가 아니라 "지금 쿠버네티스를 운영할 이유가 있는가?"다.

쿠버네티스는 강력한 기술이다. 동시에 비싼 기술이다. 여기서 비싸다는 말은 클라우드 요금만 뜻하지 않는다. 학습 비용, 장애 대응 비용, 보안 설정 비용, 버전 업그레이드 비용, 야간 알림 비용, 그리고 무엇보다 제품 개발에 쓰지 못한 시간까지 포함한다.

특히 AI 서비스를 운영하는 팀은 이 유혹에 더 쉽게 빠진다. GPU, LLM, 벡터 DB, 에이전트, 모델 서빙 같은 단어가 등장하면 곧바로 "이건 쿠버네티스가 필요하겠는데?"라고 생각하기 쉽다. 실제로 일정 규모 이상에서는 쿠버네티스가 좋은 선택이다. 여러 모델을 동시에 운영하고, GPU 노드를 자동으로 늘리고 줄이며, 추론 서버를 안전하게 배포하고, 팀별 비용을 나누어 보려면 쿠버네티스만큼 성숙한 공통 운영 계층을 찾기 어렵다.

문제는 그 "일정 규모"에 도달하기 전이다.

작은 팀이 너무 일찍 쿠버네티스를 도입하면, 인프라가 제품을 돕는 것이 아니라 제품이 인프라를 먹여 살리는 상황이 된다. 사용자는 아직 100명인데 Argo CD, Prometheus, Loki, cert-manager, External Secrets, KEDA, Gateway Controller, GPU Operator를 모두 붙잡고 있는 팀을 종종 본다. 이 경우 기술적으로는 멋져 보이지만 사업적으로는 위험하다.

이 장의 목표는 쿠버네티스를 비판하는 것이 아니다. 오히려 반대다. 쿠버네티스를 오래, 제대로 쓰기 위해 언제 시작해야 하는지 냉정하게 판단하는 방법을 정리하려는 것이다. 좋은 도구는 적절한 시점에 도입할 때 가장 빛난다.

먼저 피해야 할 신호부터 보자

쿠버네티스 도입을 고민할 때는 "써야 하는 이유"보다 "아직 쓰지 말아야 하는 이유"를 먼저 확인하는 편이 안전하다. 소규모 팀에서는 한 번 만든 클러스터가 쉽게 사라지지 않는다. 처음에는 실험용이라고 만들었지만, 어느 날 갑자기 프로덕션 트래픽이 들어오고, 그다음부터는 아무도 지우지 못하는 시스템이 된다.

다음 상황이라면 쿠버네티스는 대체로 이르다.

LLM을 쿠버네티스에서 운영하는 글을 보면 vLLM, Ray Serve, KServe, KEDA, GPU Operator가 자주 등장한다. 하지만 실전 가이드에서도 "모델 하나, GPU 하나, 스케일링 요구가 없다면 독립 실행 vLLM과 Docker로 충분하다"는 식의 경계를 분명히 둔다.¹ 이 말은 소규모 팀에게 특히 중요하다. 지금 필요한 것은 미래의 대규모 플랫폼이 아니라 오늘의 안정적인 제품일 수 있다.

AI 서비스라고 해서 반드시 자체 쿠버네티스 클러스터가 필요한 것도 아니다. 서버리스 LLM 플랫폼이나 AWS SageMaker, Google Vertex AI, Azure Machine Learning 같은 managed AI 서비스는 모델 배포, 버전 관리, 스케일링, 운영 기능을 상당 부분 대신 제공한다.² 직접 제어권은 줄어들지만, 작은 팀에게는 "내가 제어하지 않아도 되는 것"이 곧 속도다.

단일 VM, Docker Compose, PaaS, 서버리스의 자리

쿠버네티스의 대안은 수준 낮은 선택지가 아니다. 오히려 작은 팀에게는 더 전문적인 선택일 수 있다. 기술의 성숙도는 복잡한 도구를 쓰는 능력이 아니라, 문제 크기에 맞는 도구를 고르는 능력에서 드러난다.

단일 VM은 여전히 강력하다. Ubuntu 서버 한 대에 Docker를 설치하고, Nginx 또는 Caddy를 앞에 두고, 애플리케이션과 worker를 Docker Compose로 띄우는 구성은 놀라울 만큼 오래 버틴다. DB를 같은 서버에 둘 수도 있지만, 가능하면 managed DB를 쓰는 편이 낫다. 백업, 패치, 복구는 작은 팀에게 부담이 크기 때문이다.

Docker Compose는 "작지만 여러 프로세스가 필요한 서비스"에 잘 맞는다. 웹 서버, background worker, Redis, queue consumer, vector indexer 정도를 한 서버에서 묶어 운영할 수 있다. YAML이 쿠버네티스보다 훨씬 단순하고, 로컬 개발 환경과 프로덕션 환경의 차이도 작다. 단점은 서버가 여러 대로 늘어나기 시작할 때다. 그때부터는 배포, 서비스 디스커버리, 장애 복구, 로그 수집이 급격히 귀찮아진다.

PaaS는 제품 검증 단계에서 특히 좋다. Render, Fly.io, Railway, Heroku 계열 플랫폼이나 클라우드의 managed container 서비스는 git push 또는 이미지 배포만으로 서비스를 띄운다. HTTPS, 로그, 환경변수, 롤백, 간단한 오토스케일링을 제공한다. 세밀한 네트워크 정책이나 GPU 토폴로지 제어는 어렵지만, 많은 초기 서비스에는 그런 기능이 필요하지 않다.

서버리스는 이벤트성 작업에 강하다. 이미지 처리, 문서 변환, webhook 처리, 짧은 API, 비동기 후처리처럼 실행 시간이 짧고 트래픽이 들쭉날쭉한 작업에는 서버리스가 쿠버네티스보다 운영 부담이 작다. 다만 긴 실행 시간, 큰 모델 로딩, GPU 필요, 복잡한 네트워크 연결이 필요한 작업에는 제약이 생길 수 있다.

managed AI 서비스는 AI 스타트업의 초반 속도를 높인다. 모델을 직접 서빙하지 않고 OpenAI, Azure OpenAI, Anthropic, Google, Cohere 같은 API를 쓰거나, 자체 open-weight 모델도 managed inference 플랫폼에 올릴 수 있다. 이 방식은 단가가 비싸 보일 수 있지만, 트래픽이 작을 때는 직접 GPU 노드를 켜 두는 것보다 싸고 안전하다.

쿠버네티스가 필요해지는 순간

그렇다면 언제 쿠버네티스가 필요해질까? 답은 "트래픽이 많아질 때"만은 아니다. 월 방문자가 100만 명이어도 단순한 CRUD 서비스라면 PaaS로 충분할 수 있다. 반대로 트래픽은 작아도 GPU 작업, 배치 처리, 내부 도구, 모델 서빙, 벡터 검색, 비동기 queue가 복잡하게 얽히면 쿠버네티스가 더 나은 선택이 될 수 있다.

쿠버네티스가 빛나는 순간은 다음과 같다.

핵심은 "복잡도를 줄이기 위해 쿠버네티스를 도입하는가, 아니면 쿠버네티스 때문에 복잡도가 늘어나는가"다. 이 질문에 답할 수 있어야 한다.

쿠버네티스는 LLM 자체를 위해 태어난 플랫폼은 아니다. 대형 모델은 거대한 가중치, 긴 콜드스타트, GPU 토폴로지, NVLink, KV 캐시 같은 요구를 가진다. 어떤 글에서는 쿠버네티스를 "GPU 실행 엔진"이 아니라 인증, 배포, 관찰, 라우팅, 보안 정책을 묶는 "시스템 플랫폼"으로 보아야 한다고 지적한다.³ 이 관점이 중요하다. 쿠버네티스가 모든 것을 해결한다고 믿으면 실망하지만, 쿠버네티스를 AI 시스템의 운영 계층으로 보면 훨씬 현실적인 설계를 할 수 있다.

도입 판단표: 숫자로 보는 1차 기준

다음 표는 절대 법칙이 아니라 1차 필터다. 서비스의 특성, 매출, 고객 요구, 팀 역량에 따라 달라질 수 있다. 그래도 작은 팀이 감으로만 결정하지 않도록 기준선을 잡는 데 도움이 된다.

이 표에서 "검토" 구간에 들어왔다고 해서 곧바로 클러스터를 만들 필요는 없다. 검토 구간은 실험 구간이다. 이때는 managed Kubernetes를 작은 규모로 만들고, 실제 운영에 필요한 최소 구성만 붙여 보는 것이 좋다. 반대로 "권장" 구간인데도 단일 VM에서 버티고 있다면, 이미 운영 리스크를 기술 부채로 쌓고 있을 가능성이 높다.

AI 서비스는 트래픽보다 GPU 시간이 중요하다

일반 웹 서비스는 요청 수, 응답 시간, CPU 사용량, DB 부하가 핵심 지표다. AI 서비스는 여기에 GPU 시간이 추가된다. 그리고 GPU 시간은 CPU 시간보다 훨씬 비싸다.

클라우드 GPU는 인스턴스 단위로 과금되는 경우가 많다. 실제로 GPU가 10%만 일하고 있어도 인스턴스가 켜져 있으면 전체 비용을 낸다. 주요 클라우드의 GPU 인스턴스 가격표를 비교한 자료를 보면, GPU 모델과 인스턴스 크기에 따라 시간당 비용 차이가 매우 크고, 클러스터 관리 비용까지 별도로 붙을 수 있다.⁴ 작은 팀이 "어차피 나중에 필요할 테니 GPU 클러스터 하나 켜 두자"고 생각하면, 제품 검증 전에 인프라 비용이 먼저 커질 수 있다.

AI 스타트업은 다음 네 가지 GPU 사용 패턴을 구분해야 한다.

실험형과 배치형 초반에는 쿠버네티스가 없어도 된다. 오히려 작업이 끝나면 VM을 끄는 단순한 습관이 더 큰 비용 절감 효과를 낸다. 상시 추론형부터 고민이 시작된다. 사용자가 언제 들어올지 모르기 때문에 GPU를 계속 켜 두고 싶어지지만, 트래픽이 낮은 시간에는 비용이 그대로 새어 나간다.

이때 쿠버네티스의 장점이 생긴다. KEDA로 queue depth나 Prometheus 메트릭을 보고 inference replica를 줄일 수 있고, Karpenter 같은 노드 autoscaler로 필요한 GPU 인스턴스를 그때그때 만들 수 있다. Karpenter는 미리 고정된 node group에만 의존하지 않고 pending pod의 요구 조건에 맞는 인스턴스를 선택해 provision하는 방식으로 GPU 비용 최적화에 자주 언급된다.⁵ 다만 이것도 공짜는 아니다. 잘못 설정하면 콜드스타트가 길어지고, 노드 생성 실패가 곧 장애가 된다.

자체 GPU 클러스터 전에 반드시 물어야 할 질문

"우리도 자체 GPU 클러스터를 가져야 하지 않을까?"라는 질문은 AI 스타트업에서 자연스럽게 나온다. 외부 API 비용이 커지고, 데이터가 민감해지고, latency 요구가 올라가면 직접 운영하고 싶어진다. 하지만 자체 GPU 클러스터는 단순히 GPU를 사거나 GPU 인스턴스를 예약하는 일이 아니다.

먼저 경제성을 확인해야 한다. 다음 질문에 답하지 못하면 아직 이르다.

GPU 공유 기술도 검토해야 한다. 작은 모델 여러 개를 큰 GPU 하나에 올리는 경우, NVIDIA MIG나 time-slicing이 비용 절감에 도움이 될 수 있다. MIG는 지원되는 GPU에서 물리적으로 격리된 여러 GPU slice를 제공해 예측 가능한 성능과 격리를 얻는 방식이고, time-slicing은 여러 workload가 같은 GPU 시간을 나누어 쓰는 방식이다. MIG는 격리가 강하지만 지원 하드웨어와 partition 제약이 있고, time-slicing은 유연하지만 격리와 성능 예측성이 약하다.⁶

여기서 중요한 것은 "기술이 있으니 쓰자"가 아니라 "우리 workload가 공유에 적합한가"다. latency가 민감한 production 추론과 실험용 notebook을 같은 GPU에 time-slicing으로 섞는 것은 위험할 수 있다. 반대로 개발·스테이징 환경에서 가벼운 모델을 테스트하는 용도라면 time-slicing이 좋은 절충안이 된다.

자체 GPU 클러스터를 만들기 전에는 다음 비용도 빠뜨리면 안 된다.

작은 팀에서 엔지니어 한 명이 한 달의 절반을 클러스터 운영에 쓰게 되면, GPU 비용을 조금 줄였더라도 전체 비용은 오히려 증가했을 수 있다. 인프라 최적화는 계산서 숫자만 보는 일이 아니다. 팀의 집중력까지 포함해 계산해야 한다.

"쿠버네티스를 쓰지 않는" 아키텍처 예시

쿠버네티스를 쓰지 않아도 꽤 훌륭한 AI 서비스를 만들 수 있다. 예를 들어 1인 개발자가 문서 요약 SaaS를 만든다고 해보자. 사용자는 문서를 업로드하고, 시스템은 텍스트를 추출한 뒤 외부 LLM API로 요약하고, 결과를 DB에 저장한다.

이 서비스의 첫 구조는 다음 정도면 충분하다.

이 구조는 화려하지 않다. 하지만 제품을 검증하기에는 충분하다. 사용자가 늘어나면 worker를 분리하고, queue를 강화하고, cache를 추가하면 된다. 그래도 아직 쿠버네티스가 필요하지 않을 수 있다.

다른 예로, 작은 RAG 챗봇 서비스를 보자. 웹 앱, API 서버, vector DB, 외부 LLM API, background ingestion worker로 구성된다. 이 경우에도 managed vector DB와 PaaS를 조합하면 꽤 오래 간다. 쿠버네티스가 필요한 시점은 ingestion worker가 많아지고, 고객별 격리가 필요해지고, 자체 embedding 모델이나 reranker를 GPU로 운영하기 시작할 때다.

반대로, 처음부터 여러 고객에게 dedicated inference endpoint를 제공하고, 고객별 모델 버전과 비용을 분리해야 하며, GPU가 상시로 돌아가고, 장애 시 자동 failover가 필요하다면 쿠버네티스 검토가 빨라진다.

작은 팀을 위한 "최소 쿠버네티스" 원칙

쿠버네티스를 도입하기로 했다면 처음부터 완전한 플랫폼을 만들지 말자. 작은 팀의 첫 번째 목표는 "멋진 플랫폼"이 아니라 "망하지 않는 최소 운영 기반"이다.

처음 클러스터를 만들 때는 다음 원칙을 추천한다.

초기 구성은 다음 정도면 충분하다.

AI 워크로드가 있다면 GPU Operator, DCGM exporter, KEDA, KServe/vLLM 같은 구성을 추가할 수 있다. 하지만 한 번에 모두 넣지 말고, 실제 문제를 만났을 때 하나씩 추가하는 편이 좋다.

단계적 도입 로드맵

소규모 팀에게 가장 안전한 쿠버네티스 도입 방식은 "전체 이전"이 아니라 "가장 반복적이고 아픈 부분부터 이전"하는 것이다. 다음 로드맵은 1인 개발자나 2~5명 팀이 현실적으로 따라갈 수 있는 순서다.

0단계: 쿠버네티스 없이 운영 기준 세우기

쿠버네티스를 도입하기 전에 먼저 지금 시스템의 기준선을 잡아야 한다. 현재 응답 시간, 오류율, 월 비용, 배포 빈도, 장애 횟수, 복구 시간, GPU 사용량을 모르면 쿠버네티스 도입 효과도 측정할 수 없다.

이 단계에서 할 일은 단순하다. 애플리케이션 로그를 중앙에서 보고, 기본 metric을 수집하고, 배포 스크립트를 정리하고, 백업과 복구 절차를 문서화한다. 이 작업은 쿠버네티스를 쓰든 안 쓰든 필요하다.

1단계: 컨테이너 이미지와 CI/CD 정리

쿠버네티스 이전의 첫걸음은 클러스터가 아니라 이미지다. Dockerfile을 재현 가능하게 만들고, 이미지 태그 규칙을 정하고, GitHub Actions 같은 CI에서 build와 push를 자동화한다. 이 단계만 해도 배포 품질이 크게 좋아진다.

AI 서비스라면 모델 가중치를 이미지에 넣을지, volume에서 읽을지, 시작 시 다운로드할지 결정해야 한다. 작은 모델과 빠른 배포가 중요하면 이미지에 포함할 수 있지만, 수십 GB 모델은 이미지 크기를 키워 콜드스타트를 악화시킬 수 있다. 이 결정은 나중에 쿠버네티스에서 readinessProbe, PVC, 모델 캐시 전략으로 이어진다.

2단계: 관찰 가능성 먼저 도입

많은 팀이 쿠버네티스를 먼저 만들고 모니터링을 나중에 붙인다. 순서가 반대여야 한다. 최소한 서비스별 오류율, latency, CPU/memory, queue depth, 외부 LLM API 오류율, DB connection 수는 봐야 한다. GPU를 쓴다면 GPU utilization과 GPU memory 사용량도 필요하다.

이 단계의 목표는 "장애가 났을 때 어디가 아픈지 10분 안에 짐작할 수 있는 상태"다. 완벽한 tracing보다 기본 dashboard와 알림이 먼저다.

3단계: stateless API부터 쿠버네티스로 이동

처음부터 DB, queue, vector DB, 모델 서버를 모두 옮기지 말자. 가장 안전한 첫 대상은 stateless API다. Deployment, Service, ConfigMap, Secret, readinessProbe, livenessProbe를 적용하고, rolling update와 rollback을 연습한다.

이 단계에서 운영자는 쿠버네티스의 기본 감각을 익힌다. Pod가 Pending이 되는 이유, ImagePullBackOff가 나는 이유, readinessProbe가 실패하면 트래픽이 어떻게 빠지는지, resource request가 스케줄링에 어떤 영향을 주는지 몸으로 배운다.

4단계: worker와 batch job 이동

다음은 background worker와 batch job이다. queue consumer, ingestion worker, embedding job, report generator 같은 작업이 여기에 속한다. 이 단계에서 Job, CronJob, KEDA를 검토할 수 있다.

AI 팀이라면 embedding 생성이나 평가 작업을 Kubernetes Job으로 옮기는 것이 좋은 연습이 된다. 실패 시 재시도, timeout, backoffLimit, 로그 보존, 결과 저장 위치를 명확히 할 수 있기 때문이다.

5단계: 추론 서빙 도입

모델 서빙은 가장 조심스럽게 옮겨야 한다. 작은 모델이라면 vLLM 또는 TGI를 단일 Deployment로 시작할 수 있다. 첫 목표는 고급 오토스케일링이 아니라 안정적인 한 replica다. 모델이 뜨는 시간, readinessProbe가 통과하는 시점, GPU memory 사용량, 요청당 latency, graceful shutdown을 확인한다.

그다음 KEDA나 custom metric 기반 scaling을 붙인다. CPU 사용률만으로 LLM 추론을 scale하는 것은 부정확할 수 있다. queue depth, 동시 요청 수, TTFT, token throughput, GPU memory pressure 같은 지표가 더 유용하다.

6단계: GPU 스케줄링과 비용 최적화

상시 GPU 사용량이 늘어나면 GPU node pool, taint/toleration, node affinity, MIG, time-slicing, Kueue, Karpenter를 검토한다. 이 단계부터는 비용 추적이 필수다. "어느 namespace가 GPU를 얼마나 예약했는가", "어느 모델이 가장 비싼가", "idle GPU가 몇 시간 발생했는가"를 볼 수 있어야 한다.

GPU 비용 귀속은 단순한 회계 문제가 아니다. CloudZero가 GPU request 기반 비용 귀속을 강조하는 이유도 GPU 비용이 idle pool에 묻히면 실제 workload 비용을 판단하기 어려워지기 때문이다.⁷ 작은 팀도 최소한 namespace, app, model, environment, owner label은 일관되게 붙여야 한다.

7단계: 플랫폼화는 마지막에 한다

마지막 단계가 Internal Developer Platform이다. Backstage, self-service portal, golden path, policy-as-code, multi-cluster 같은 단어는 매력적이지만, 작은 팀이 너무 빨리 만들면 배보다 배꼽이 커진다.

플랫폼화는 반복이 충분히 쌓였을 때 시작한다. 같은 유형의 서비스가 5번 이상 만들어졌고, 같은 Helm chart를 여러 팀이 쓰고, 같은 보안 정책을 매번 수동으로 리뷰하고 있다면 그때 추상화하자. 반복이 없는 자동화는 대부분 과설계다.

도입 전 체크리스트

아래 체크리스트에서 "아니오"가 많다면 쿠버네티스 도입을 미루는 편이 좋다.

AI 워크로드가 있다면 추가 질문이 필요하다.

운영 역량 체크리스트

쿠버네티스는 설치보다 운영이 어렵다. 다음 항목은 실제로 운영자가 할 수 있어야 한다.

여기서 중요한 것은 모든 사람이 전문가일 필요는 없다는 점이다. 하지만 팀 안에 "클러스터가 이상할 때 첫 30분을 버틸 사람"은 있어야 한다. 그 사람이 없다면 managed platform을 더 오래 쓰는 것이 낫다.

도입 후 30일 운영 계획

쿠버네티스를 도입했다면 첫 30일이 중요하다. 이 기간에는 기능을 많이 올리는 것보다 운영 습관을 만드는 데 집중해야 한다.

첫 주에는 배포와 롤백을 반복한다. 일부러 작은 변경을 여러 번 배포하고, rollout history와 rollback을 확인한다. readinessProbe를 잘못 설정했을 때 트래픽이 어떻게 막히는지, image tag가 틀렸을 때 어떤 이벤트가 나오는지 본다.

둘째 주에는 장애 연습을 한다. Pod를 삭제하고, node를 cordon/drain하고, DB connection 정보를 잘못 넣어 보고, Secret 누락을 만들어 본다. 프로덕션에서 처음 겪으면 사고지만, staging에서 겪으면 훈련이다.

셋째 주에는 비용을 본다. node가 예상보다 많이 떠 있는지, request가 과한지, idle 시간이 긴지 확인한다. GPU가 있다면 특히 "할당된 시간"과 "실제 계산한 시간"을 나누어 보아야 한다.

넷째 주에는 보안을 정리한다. 불필요한 cluster-admin 권한을 제거하고, namespace별 RoleBinding을 확인하고, 외부로 열려 있는 Service를 점검한다. AI 도구를 써서 manifest를 생성하더라도 그대로 적용하지 말고 dry-run, 정책 검사, PR 리뷰를 거쳐야 한다. AI 기반 Kubernetes 도구를 소개하는 자료들도 AI가 YAML과 디버깅을 도울 수는 있지만, production 적용 전 검증과 버전 관리를 반드시 권장한다.⁸

흔한 실패 패턴

작은 팀이 쿠버네티스를 도입할 때 자주 겪는 실패는 비슷하다.

첫 번째는 "클러스터는 있는데 운영 기준이 없는" 경우다. namespace 이름도 제각각이고, label도 없고, resource request도 없고, 누구 소유의 workload인지 모른다. 이 상태에서는 쿠버네티스가 질서를 만드는 것이 아니라 무질서를 더 빠르게 확산시킨다.

두 번째는 "모든 것을 self-hosting하려는" 경우다. Prometheus도 직접, Grafana도 직접, Loki도 직접, DB도 직접, vector DB도 직접, object storage도 직접 운영한다. 학습에는 좋지만 작은 팀의 production에는 위험하다. 특히 DB와 메시지 큐는 가능하면 managed 서비스를 우선 검토하자.

세 번째는 "GPU를 켜 두고 잊는" 경우다. 추론 서버 하나를 위해 GPU 노드를 상시로 켜 두었지만 실제 요청은 하루 몇 시간뿐인 상황이 흔하다. 이때는 scale-to-zero, queue 기반 batch 처리, 외부 API fallback, 작은 모델과 큰 모델의 tiering을 검토해야 한다.

네 번째는 "도구를 문제보다 먼저 도입하는" 경우다. 서비스 mesh, multi-cluster, policy engine, custom operator, internal platform은 모두 좋은 기술이다. 하지만 팀이 아직 Deployment와 Service 장애도 빠르게 못 보는 상태라면, 고급 도구는 문제를 해결하기보다 디버깅 표면적을 늘린다.

다섯 번째는 "AI가 운영을 대신해 줄 것이라고 믿는" 경우다. kubectl-ai, K8sGPT 같은 도구는 명령어 생성과 원인 분석을 도와줄 수 있다. 하지만 production cluster에 대한 쓰기 권한을 아무 제약 없이 주는 것은 위험하다. AI는 조수로 두고, 최종 적용은 GitOps와 사람의 리뷰를 통과하게 해야 한다.

최종 의사결정 매트릭스

마지막으로, 실제 의사결정에 사용할 수 있는 간단한 매트릭스를 보자. 각 항목에 0~2점을 준다. 0점은 필요 낮음, 1점은 애매함, 2점은 필요 높음이다.

점수 해석은 다음과 같다.

이 매트릭스의 목적은 결정을 자동화하는 것이 아니다. 팀 안에서 같은 언어로 토론하게 만드는 것이다. "쿠버네티스가 멋지니까"가 아니라 "우리의 GPU 사용량이 상시화되었고, 배포 빈도가 높고, 장애 허용도가 낮고, 비용 귀속이 필요하므로 도입한다"라고 말할 수 있어야 한다.

작게 시작하고, 되돌릴 수 있게 만들자

소규모 팀에게 좋은 인프라는 미래를 막지 않으면서 현재를 압도하지 않는 인프라다. 쿠버네티스는 미래 확장성을 주지만, 현재의 복잡도도 함께 가져온다. 그래서 도입은 항상 작게 시작해야 한다.

처음에는 stateless API 하나만 올려도 된다. 그다음 worker를 올리고, 그다음 추론 서버를 올리고, 마지막에 GPU 스케줄링과 비용 최적화를 붙이면 된다. 모든 것을 한 번에 옮기지 않으면 실패해도 되돌릴 수 있다. 되돌릴 수 있는 도입은 실험이고, 되돌릴 수 없는 도입은 도박이다.

AI 시대의 쿠버네티스는 분명 중요하다. GPU와 LLM이 표준 workload가 되면서 쿠버네티스는 웹 서비스 배포 도구를 넘어 AI 인프라의 운영 계층으로 자리 잡고 있다. 하지만 모든 팀이 같은 시점에 그 세계로 들어가야 하는 것은 아니다.

당신의 팀이 아직 제품을 찾는 중이라면 단순함이 최고의 전략이다. 사용자가 늘고, 모델이 늘고, GPU 비용이 커지고, 장애 대응이 반복되고, 배포가 잦아졌을 때 쿠버네티스는 그때 훨씬 좋은 친구가 된다.

쿠버네티스는 유행이라서 선택하는 기술이 아니다. 비용, 복잡도, 운영 역량을 계산한 뒤 선택하는 기술이다. 그 계산을 할 수 있게 되었다면, 이미 절반은 준비된 것이다.

참고

¹Deploying LLMs on Kubernetes: vLLM, Ray Serve & GPU Scheduling Guide (2026)

²Unsure About Kubernetes for LLMs? Here's How to Make the Right Choice

³Kubernetes Was Never Meant for LLMs - So Why Are We Doing It Anyway?

⁴GPU Cost Efficiency in Kubernetes: Selection, Sharing, and Savings Strategies

⁵GPU orchestration guide: How to auto-scale Kubernetes clusters and slash AI infrastructure costs

⁶GPU Sharing in Kubernetes: How to Cut Costs and Boost GPU Utilization with Cast AI

⁷Your Most Expensive Kubernetes Costs Have Been Hiding In The Wrong Bucket

⁸AI for Kubernetes: Automate K8s with AI Tools in 2026