학습된 모델은 파일 상태로는 비즈니스 가치를 만들지 못합니다. 사용자의 요청을 받고, 제한된 시간 안에 응답하고, 장애가 나도 복구되며, 새 모델로 안전하게 교체될 때 비로소 서비스가 됩니다. Kubernetes에서 모델 추론을 운영한다는 것은 모델을 컨테이너로 띄우는 일을 넘어 API 계약, 확장 방식, 배포 전략, 품질 모니터링을 함께 설계하는 일입니다.
이 장의 핵심은 단순합니다. 추론 서비스는 데모 서버가 아니라 운영 API로 다뤄야 합니다. 그러려면 먼저 요청의 성격을 나누고, 그에 맞는 서빙 도구와 확장 방식을 선택해야 합니다.
AI 생성 이미지
먼저 추론 방식을 구분합니다
모든 추론을 하나의 API 패턴으로 처리하려고 하면 운영이 복잡해집니다. 서비스 요구사항에 따라 크게 세 가지로 나누는 것이 좋습니다.
실시간 추론은 사용자의 요청에 즉시 응답해야 하는 방식입니다. 추천, 검색 랭킹, 챗봇 응답, 문서 분류 API가 여기에 해당합니다. 중요한 지표는 지연 시간과 오류율입니다. 100ms, 500ms, 3초처럼 서비스가 허용할 수 있는 응답 시간을 먼저 정해야 합니다. GPU가 필요하더라도 무조건 큰 모델을 쓰기보다, 지연 시간 목표를 만족하는 모델 크기와 런타임을 선택해야 합니다.
배치 추론은 대량 데이터를 모아 한 번에 처리하는 방식입니다. 매일 새벽 전체 고객군에 대한 이탈 가능성을 계산하거나, 상품 이미지 전체를 재분류하는 작업이 예입니다. 요청별 즉시 응답보다 처리량, 재시도, 완료 시간이 중요합니다. Kubernetes에서는 Job, CronJob 또는 워크플로 파이프라인으로 운영하는 편이 자연스럽습니다.
비동기 추론은 요청을 큐에 넣고 나중에 결과를 받는 방식입니다. 이미지 생성, 긴 문서 요약, 대규모 임베딩 생성처럼 처리 시간이 길거나 트래픽 변동이 큰 작업에 적합합니다. 사용자는 요청 ID를 먼저 받고, 결과는 콜백·폴링·알림으로 확인합니다. 이 경우 API 서버, 메시지 큐, 워커 Pod, 결과 저장소를 분리해야 합니다.
간단한 기준은 다음과 같습니다.
| 구분 | 적합한 상황 | Kubernetes 운영 단위 | 주요 지표 |
|---|---|---|---|
| 실시간 추론 | 사용자 요청에 즉시 응답 | Deployment, InferenceService | p95 지연 시간, 오류율, 동시 요청 수 |
| 배치 추론 | 대량 데이터를 정해진 시간에 처리 | Job, CronJob, Workflow | 처리량, 완료 시간, 실패 재시도 |
| 비동기 추론 | 오래 걸리거나 트래픽 변동이 큰 요청 | Deployment + Queue + Worker | 큐 길이, 대기 시간, 처리 성공률 |
모델 서빙 선택지는 역할이 다릅니다
모델 서빙 도구를 고를 때 "어느 것이 더 좋은가"보다 "우리 문제가 무엇인가"를 먼저 봐야 합니다. Kubernetes 위에서 자주 검토되는 선택지는 KServe, Seldon, NVIDIA Triton Inference Server, Ray Serve입니다.
KServe는 Kubernetes 네이티브 모델 서빙 계층에 가깝습니다. InferenceService라는 Custom Resource를 통해 모델 배포, 네트워킹, 헬스 체크, 오토스케일링, 카나리 배포 같은 운영 요소를 추상화합니다. 여러 프레임워크의 예측 모델과 생성형 AI 추론을 하나의 방식으로 다루고 싶을 때 유리합니다.1
Seldon Core는 모델, 파이프라인, 실험 같은 리소스 모델을 제공하며, 단일 모델뿐 아니라 여러 단계로 이어지는 추론 파이프라인을 운영하기 좋습니다. 여러 모델을 적은 수의 서버에 올려 비용을 줄이거나, MLServer와 Triton 같은 V2 프로토콜 기반 런타임을 함께 쓰는 구조도 고려할 수 있습니다.2
NVIDIA Triton Inference Server는 고성능 추론 런타임입니다. Kubernetes 플랫폼 전체를 대신한다기보다, GPU를 효율적으로 쓰고 다양한 프레임워크 모델을 빠르게 제공하는 모델 서버에 가깝습니다. 동적 배칭, 동시 모델 실행, Prometheus 메트릭 등을 활용해 지연 시간과 처리량을 세밀하게 튜닝할 수 있습니다. 또한 Kubernetes의 NVIDIA device plugin, GPU Operator, MIG 구성과 함께 쓰면 GPU 자원을 더 잘게 나누어 운영하는 배포 패턴도 만들 수 있습니다.3
Ray Serve는 Ray 생태계 위에서 동작하는 서빙 방식입니다. Python 기반 모델 로직, 여러 모델의 조합, 분산 처리, 동적인 워커 확장이 필요한 경우 검토할 만합니다. Kubernetes에서는 KubeRay Operator가 Ray 클러스터의 head Pod와 worker Pod를 관리하고, 필요에 따라 Ray Pod를 늘리거나 줄이는 구조를 제공합니다.4
선택 기준을 실무적으로 정리하면 다음과 같습니다.
| 선택지 | 먼저 검토할 상황 | 주의할 점 |
|---|---|---|
| KServe | 표준화된 Kubernetes 모델 서빙 플랫폼이 필요할 때 | Knative, Istio 등 주변 구성 요소 복잡도를 확인해야 함 |
| Seldon | 모델 파이프라인, 실험, 다중 모델 운영이 중요할 때 | 조직의 기존 MLOps 도구와 API 모델이 맞는지 봐야 함 |
| Triton | GPU 효율, 낮은 지연 시간, 높은 처리량이 중요할 때 | 모델 저장소 구조와 런타임 튜닝 역량이 필요함 |
| Ray Serve | Python 중심의 복합 추론 로직과 분산 처리가 필요할 때 | Ray 클러스터 운영 경험이 필요함 |
초기에는 하나의 도구로 모든 문제를 해결하려 하기보다, "플랫폼 계층"과 "런타임 계층"을 나눠 생각하는 편이 안전합니다. 예를 들어 KServe로 배포와 트래픽 관리를 맡기고, 실제 predictor runtime으로 Triton을 사용하는 조합도 가능합니다.
운영 API의 기본 구조
실시간 모델 API는 보통 다음 흐름을 가집니다.
클라이언트가 API Gateway 또는 Ingress로 요청을 보냅니다.
인증, 사용량 제한, 요청 크기 제한을 적용합니다.
전처리 단계에서 입력을 모델이 이해하는 형태로 바꿉니다.
모델 서버가 추론을 수행합니다.
후처리 단계에서 점수, 라벨, 설명, 정책 필터를 적용합니다.
응답과 메트릭, 로그를 남깁니다.
작은 서비스라면 전처리와 후처리를 하나의 컨테이너에 넣을 수 있습니다. 하지만 여러 모델이 같은 전처리를 공유하거나, 모델 교체와 API 계약을 분리해야 한다면 별도 컴포넌트로 나누는 편이 낫습니다. 반대로 처음부터 모든 단계를 마이크로서비스로 쪼개면 네트워크 지연과 장애 지점이 늘어납니다. 처음에는 단순하게 시작하되, 재사용성과 배포 독립성이 필요해지는 지점에서 분리하는 것이 현실적입니다.
운영 배포 전에는 최소한 다음 항목을 확인해야 합니다.
모델 파일 위치와 버전이 명확한가?
컨테이너 이미지 태그가 재현 가능한가?
요청·응답 스키마가 문서화되어 있는가?
readiness probe가 모델 로딩 완료 이후에만 성공하는가?
GPU 메모리 사용량을 사전에 측정했고, 동시에 처리할 요청 수와 배칭 크기에 상한이 있는가?
모델 서버가 실패했을 때 Pod가 무한 재시작만 반복하지 않도록 로그와 원인 확인 경로가 있는가?
이전 모델로 되돌릴 수 있는 배포 단위가 있는가?
특히 대형 모델은 Pod가 떠도 모델 로딩이 끝나기 전까지 요청을 받을 수 없습니다. 이때 readiness probe가 부정확하면 사용자는 500 오류를 만나고, 오토스케일링은 정상 Pod가 늘었다고 착각할 수 있습니다. 반대로 readiness probe가 너무 엄격하면 정상 Pod도 계속 서비스에서 제외될 수 있으므로, 모델 로딩 상태와 실제 추론 가능 상태를 기준으로 잡아야 합니다.
오토스케일링은 CPU만 보면 부족합니다
일반 웹 API는 CPU 사용률 기반 HPA로도 어느 정도 확장이 가능합니다. 하지만 모델 추론은 다릅니다. 병목이 CPU가 아니라 GPU 메모리, 요청 큐, 배칭 대기 시간, 외부 벡터 DB 호출일 수 있습니다.
HPA는 기본 출발점입니다. CPU, 메모리 또는 Prometheus Adapter를 통한 커스텀 메트릭으로 Pod 수를 늘릴 수 있습니다. 예를 들어 Triton은 Prometheus로 추론 메트릭을 노출하므로, 이를 수집해 Kubernetes HPA 또는 별도 오토스케일러의 판단 근거로 활용할 수 있습니다.3
KEDA는 이벤트 기반 확장에 적합합니다. 메시지 큐, Kafka 토픽, 외부 메트릭처럼 "처리해야 할 일이 얼마나 쌓였는가"를 기준으로 Pod를 늘릴 수 있습니다. KEDA는 Kubernetes HPA와 함께 동작하며, 구성에 따라 scale-to-zero도 지원합니다.5
큐 기반 오토스케일링은 비동기 추론에서 특히 중요합니다. 예를 들어 문서 요약 요청이 Kafka나 Redis Queue에 쌓인다면, 큐 길이 또는 대기 시간을 기준으로 worker Pod를 늘립니다. 이 방식은 사용자가 API 응답을 끝까지 기다리지 않아도 되므로, 긴 작업을 안정적으로 처리하는 데 유리합니다.
생성형 AI나 LLM 추론에서는 동시 실행 요청 수, 대기 중 요청 수, KV cache 사용량 같은 모델 서버 내부 지표가 더 유용할 수 있습니다. KServe는 KEDA와 연계해 Prometheus 또는 OpenTelemetry 기반 메트릭으로 추론 워크로드를 확장하는 방식을 제공합니다.6
오토스케일링 목표는 "가능한 한 많이 늘리기"가 아닙니다. 비싼 GPU Pod를 너무 빠르게 늘리면 비용이 급증하고, 너무 늦게 늘리면 지연 시간이 악화됩니다. 따라서 다음 세 가지를 함께 정해야 합니다.
최소 replica: 콜드 스타트를 피하기 위해 항상 유지할 Pod 수
최대 replica: 비용과 GPU 가용량을 고려한 상한
확장 지표: CPU, 동시 요청 수, 큐 길이, p95 지연 시간 중 무엇을 볼지
여기에 한 가지를 더 보태면, 축소 정책도 중요합니다. 트래픽이 잠깐 줄었다고 GPU Pod를 바로 줄이면 곧바로 다시 콜드 스타트가 발생할 수 있습니다. scale down 안정화 시간, 요청 drain, 모델 로딩 시간까지 함께 봐야 실제 사용자 경험이 흔들리지 않습니다.
새 모델은 한 번에 바꾸지 않습니다
모델 배포에서 가장 위험한 순간은 새 모델을 운영 트래픽에 처음 연결할 때입니다. 코드 배포와 달리 모델은 오류가 없어도 비즈니스 결과가 나빠질 수 있습니다. 정확도는 좋아졌지만 특정 고객군에서 응답 품질이 떨어질 수 있고, 평균 지연 시간은 비슷하지만 p99 지연 시간이 크게 늘어날 수 있습니다.
안전한 출시에는 두 가지 패턴이 자주 쓰입니다.
카나리 배포는 새 모델에 일부 트래픽만 보내는 방식입니다. 예를 들어 처음에는 5%만 v2 모델로 보내고, 오류율·지연 시간·응답 품질을 본 뒤 20%, 50%, 100%로 확대합니다. KServe는 카나리 롤아웃과 A/B 테스트를 지원하는 모델 서빙 기능을 제공합니다.1
블루그린 배포는 기존 모델 환경과 새 모델 환경을 동시에 준비한 뒤, 라우팅을 한 번에 전환하는 방식입니다. 전환 전 새 환경에서 헬스 체크, 샘플 요청, 부하 테스트를 수행합니다. 문제가 생기면 라우팅을 다시 기존 환경으로 되돌립니다.
실무 절차는 다음처럼 단순하게 시작할 수 있습니다.
모델 레지스트리에 새 모델 버전과 평가 결과를 등록합니다.
staging 네임스페이스에서 동일한 컨테이너와 설정으로 검증합니다.
운영 환경에 새 predictor를 배포하되 트래픽은 보내지 않습니다.
내부 테스트 요청과 리플레이 트래픽으로 응답을 확인합니다.
5~10% 카나리 트래픽을 연결합니다.
지연 시간, 오류율, 비용, 품질 지표를 비교합니다.
기준을 만족하면 점진적으로 확대하고, 아니면 즉시 롤백합니다.
중요한 점은 "승인 기준"을 배포 전에 정하는 것입니다. 배포 후에 기준을 정하면 대부분 판단이 느려집니다. 예를 들어 "p95 지연 시간은 기존 모델 대비 20% 이상 나빠지면 안 된다", "5xx 오류율은 1%를 넘으면 안 된다", "핵심 고객군의 품질 지표는 기존보다 낮아지면 안 된다"처럼 숫자와 조건을 미리 정해두는 편이 좋습니다.
모니터링은 인프라와 모델 품질을 함께 봅니다
추론 서비스의 관측 가능성은 두 층으로 나눠야 합니다.
첫 번째는 서비스 지표입니다. API가 안정적으로 동작하는지 확인합니다.
p50, p95, p99 지연 시간
초당 요청 수와 처리량
4xx, 5xx 오류율
Pod 재시작 횟수
GPU 사용률과 GPU 메모리 사용량
큐 길이와 평균 대기 시간
두 번째는 모델 품질 지표입니다. 응답이 비즈니스 목적에 맞는지 확인합니다.
예측 분포 변화
입력 데이터 분포 변화
빈 응답, 정책 위반 응답, 낮은 신뢰도 응답 비율
사용자 피드백 또는 후행 정답 기준의 성능
모델 버전별 전환율, 클릭률, 상담 처리율 같은 비즈니스 지표
서비스 지표만 보면 "API는 정상"인데 실제 모델 품질은 나빠지는 상황을 놓칠 수 있습니다. 반대로 모델 품질만 보면 지연 시간 증가나 GPU 비용 급증을 늦게 발견합니다. 운영 추론은 두 지표를 함께 봐야 합니다.
다만 모든 품질 지표를 첫날부터 완벽하게 만들 필요는 없습니다. 처음에는 입력 분포, 응답 분포, 오류 샘플, 사용자 피드백처럼 수집 가능한 것부터 시작하면 됩니다. 이후 후행 정답 데이터가 쌓이면 모델 버전별 성능과 비즈니스 지표를 더 정교하게 비교할 수 있습니다.
도입 판단 체크리스트
모델 추론 서비스를 Kubernetes에 올리기 전, 다음 질문에 답해보면 설계 방향이 명확해집니다.
이 모델은 실시간, 배치, 비동기 중 어디에 속하는가?
허용 가능한 p95 지연 시간은 얼마인가?
CPU 추론으로 충분한가, GPU가 필요한가?
콜드 스타트를 허용할 수 있는가?
새 모델을 카나리로 검증할 기준이 있는가?
모델 응답 품질을 운영 중에 측정할 방법이 있는가?
장애가 나면 이전 모델로 몇 분 안에 되돌릴 수 있는가?
Kubernetes의 장점은 모델을 하나의 Pod로 실행하는 데 있지 않습니다. 배포, 확장, 관측, 롤백을 같은 운영 언어로 묶을 수 있다는 데 있습니다. 추론 서비스가 비즈니스 API가 되는 순간, 모델 성능만큼 중요한 것은 운영 기준입니다.
참고
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.