• 목록

AI 모델을 만드는 것보다 어려운 일은 안정적으로 서비스하는 것입니다. 실험 환경에서는 모델 파일과 간단한 API만으로도 결과를 확인할 수 있지만, 실제 서비스에서는 GPU 부족, 긴 응답 시간, 동시 요청 증가, 모델 버전 관리, 비용과 보안까지 함께 해결해야 합니다. 이 글에서는 쿠버네티스 기반 GPU 인프라를 준비하고 LLM 추론 서버를 배포한 뒤, 오토스케일링과 관측성까지 연결하는 현실적인 7단계를 정리합니다.

AI 생성 삽화 · 쿠버네티스로 AI 서비스를 운영하는 방법의 내용을 설명하기 위한 이미지입니다.

핵심 정리
AI 모델을 만드는 것보다 어려운 일은 안정적으로 서비스하는 것입니다.

1. AI 서비스 운영에 쿠버네티스가 필요한 이유

모델 서버와 주변 구성 요소 분리하기

쿠버네티스의 핵심 장점은 모델 서버를 컨테이너 단위로 관리하면서 API 게이트웨이, 인증, 캐시, 벡터 데이터베이스, 모니터링 구성 요소를 분리할 수 있다는 점입니다. 예를 들어 사용자 요청을 받는 API와 GPU를 사용하는 추론 서버를 별도 Deployment로 운영하면 각각 다른 방식으로 확장할 수 있습니다.

처음부터 모든 요소를 쿠버네티스에 올릴 필요는 없습니다. 모델 서버, 요청 큐, 로그 수집기처럼 운영 복잡도가 높은 부분부터 컨테이너화하고, 데이터베이스는 관리형 서비스를 사용하는 방식도 합리적입니다. 쿠버네티스로 AI 서비스를 운영하는 방법의 출발점은 기술을 많이 넣는 것이 아니라 책임과 장애 범위를 나누는 데 있습니다.

개발·검증·운영 환경 통일하기

로컬에서 잘 작동하던 모델이 운영 환경에서 실패하는 원인은 CUDA, 드라이버, Python 패키지, 모델 파일 경로가 달라서인 경우가 많습니다. 컨테이너 이미지에 런타임과 애플리케이션 의존성을 고정하면 환경 차이를 줄일 수 있습니다. 다만 GPU 드라이버는 일반적으로 호스트 노드와 NVIDIA 컨테이너 런타임의 호환성까지 함께 확인해야 합니다.

Namespace를 개발·스테이징·운영으로 나누고, Helm이나 Kustomize로 설정을 관리하면 배포 이력도 추적하기 쉽습니다. 비밀값은 이미지나 Git 저장소에 넣지 말고 Secret, 외부 비밀 관리 시스템 등으로 분리해야 합니다. 운영 전에 동일한 이미지로 부하 테스트를 수행하는 것도 중요합니다.

---

2. GPU와 노드 스케줄링 설계

GPU 노드와 일반 노드 구분하기

AI 클러스터는 CPU 작업과 GPU 작업을 같은 노드 풀에 섞지 않는 편이 관리하기 쉽습니다. GPU 노드에는 적절한 드라이버와 디바이스 플러그인을 설치하고, 노드 라벨과 taint를 적용해 GPU를 요청한 워크로드만 배치합니다. Pod에는 resources.requests와 resources.limits를 명시해야 스케줄러가 자원 요구량을 판단할 수 있습니다.

GPU 전체를 독점하는 추론 서버와 여러 작업이 한 장치를 나누는 개발 환경은 요구사항이 다릅니다. MIG를 지원하는 GPU라면 하드웨어 분할을 고려할 수 있지만, 모델 메모리와 통신 패턴에 따라 성능이 달라집니다. 따라서 문서의 지원 여부만 보지 말고 실제 모델의 메모리 사용량과 동시성으로 검증해야 합니다.

스케줄링 실패 원인 점검하기

Pod가 Pending 상태라면 GPU 수량 부족만 의심해서는 안 됩니다. nodeSelector, affinity, taint와 toleration, 가용 영역, PVC 연결 조건이 동시에 배치 가능성을 제한할 수 있습니다. kubectl describe pod의 이벤트와 kubectl describe node의 할당 자원을 먼저 확인하면 원인을 좁히기 좋습니다.

노드에 GPU가 여러 개 있어도 컨테이너가 올바른 장치를 보지 못할 수 있습니다. 장치 플러그인 상태, 컨테이너 내부의 GPU 조회 결과, CUDA와 드라이버 호환성을 순서대로 확인하세요. GPU 사용률이 낮다는 사실만으로 GPU를 줄이면 안 됩니다. 메모리 사용량, 요청 대기 시간, 토큰 처리량을 함께 봐야 합니다.

---

3. LLM 모델 배포와 추론 최적화

추론 서버와 모델 저장소 선택하기

LLM 배포에서는 모델을 직접 로드하는 간단한 웹 서버보다, 연속 배칭과 스트리밍을 지원하는 추론 엔진을 검토하는 것이 일반적입니다. vLLM, Hugging Face TGI, NVIDIA Triton 등은 모델 형식과 하드웨어, API 호환성, 운영 기능에 따라 선택지가 달라집니다. 특정 도구가 항상 최선인 것은 아니므로 모델 구조와 지원 기능을 먼저 확인해야 합니다.

모델 파일을 컨테이너 이미지에 포함하면 배포 시 예측 가능성이 높아지지만 이미지가 커집니다. 반대로 오브젝트 스토리지나 네트워크 볼륨에서 내려받으면 이미지가 작아지는 대신 초기 기동 시간이 길어질 수 있습니다. 운영에서는 모델 캐시, 체크섬 검증, readiness probe를 활용해 모델 로딩이 끝나기 전에 트래픽이 유입되지 않도록 구성해야 합니다.

지연 시간과 처리량 함께 최적화하기

LLM 성능은 단순한 CPU 사용률로 판단하기 어렵습니다. 첫 토큰까지 걸리는 시간인 TTFT, 토큰 생성 속도, 전체 요청 지연 시간, 동시 처리량을 별도로 수집해야 합니다. 스트리밍 응답은 사용자가 빠르게 결과를 받는 느낌을 줄 수 있지만, 네트워크 연결과 중단 요청 처리까지 고려해야 합니다.

배칭은 처리량을 높일 수 있지만 요청 대기 시간이 늘어날 수 있습니다. 최대 입력 토큰, 최대 생성 토큰, 동시 요청 수를 서비스 목적에 맞게 제한하고, 긴 프롬프트를 무제한 허용하지 않는 것이 좋습니다. 양자화와 텐서 병렬화도 선택지지만, 정확도와 메모리 절감 효과를 실제 평가셋으로 확인해야 합니다. LLM 배포는 설정값 하나보다 측정과 비교의 반복이 핵심입니다.

---

4. 오토스케일링·비용·보안 관리

GPU 확장 기준을 다시 설계하기

CPU 기반 HPA만으로 GPU 추론 서버를 확장하면 실제 병목을 놓칠 수 있습니다. GPU 메모리, 요청 큐 길이, 동시 요청 수, 토큰 처리량 같은 지표를 Prometheus로 수집하고 이를 기반으로 확장 정책을 설계해야 합니다. Kubernetes Event-driven Autoscaling(KEDA)을 사용하면 큐 길이 같은 외부 지표를 활용할 수 있습니다.

다만 GPU Pod가 새 노드에 올라오기까지는 시간이 걸립니다. 클러스터 오토스케일러와 노드 프로비저닝 정책을 함께 조정하고, 최소 예비 용량과 scale-down 지연 시간을 운영 특성에 맞춰야 합니다. 급격한 확장은 비용을 키우고, 지나친 축소는 콜드 스타트와 품질 저하를 일으킬 수 있습니다.

비용과 보안의 기본선 세우기

비용 최적화는 비싼 GPU를 무조건 저렴한 GPU로 바꾸는 작업이 아닙니다. 모델 크기, 양자화 수준, 요청 패턴, 허용 가능한 지연 시간을 기준으로 GPU 유형과 복제 수를 비교해야 합니다. 개발 환경에는 스팟 인스턴스를 사용할 수 있지만, 중단에 대비한 체크포인트와 재시작 전략이 필요합니다.

보안 측면에서는 외부 입력을 신뢰하지 않는 것이 출발점입니다. API 인증과 속도 제한을 적용하고, 프롬프트와 모델 응답에 포함될 수 있는 개인정보를 마스킹해야 합니다. Pod 보안 정책, 최소 권한의 서비스 계정, 네트워크 정책, 이미지 취약점 검사도 함께 적용하세요. 특히 모델 서버에 클라우드 권한을 넓게 부여하지 않는 것이 중요합니다.

---

5. 모니터링과 장애 대응 실전

AI 서비스에 필요한 관측성

기본 인프라 지표만으로는 LLM 장애를 설명하기 어렵습니다. 요청 수와 오류율 외에 TTFT, 전체 지연 시간, 입력·출력 토큰 수, 큐 대기 시간, GPU 메모리, 캐시 적중률을 수집해야 합니다. 로그에는 요청 ID와 모델 버전을 넣되 원문 프롬프트나 개인정보가 그대로 남지 않도록 필터링합니다.

분산 추적을 적용하면 API 게이트웨이부터 검색, 프롬프트 조합, 추론 서버까지 한 요청의 흐름을 확인할 수 있습니다. 비용 추정을 위해 토큰 사용량과 사용자·팀별 호출량을 집계하는 것도 유용합니다. 대시보드는 평균값만 보여주지 말고 p95, p99 지연 시간과 오류 유형을 분리해 표시해야 합니다.

장애 대응 절차와 배포 전략

모델 서버가 응답하지 않을 때는 먼저 애플리케이션 오류인지, GPU 메모리 부족인지, 노드 장애인지, 외부 모델 저장소 문제인지 구분해야 합니다. Pod 이벤트, 애플리케이션 로그, GPU 상태, 최근 배포 변경 사항을 시간순으로 확인하면 불필요한 재시작을 줄일 수 있습니다. 재시작만 반복하면 원인과 로그를 잃을 수 있으므로 크래시 덤프와 보존 정책도 준비해야 합니다.

모델 변경은 무중단을 목표로 하되, 새 버전이 항상 안전하다고 가정하지 않아야 합니다. 새 Deployment에 일부 트래픽만 보내는 카나리 배포와 자동 롤백 기준을 사용하고, 품질 평가와 시스템 지표를 함께 확인하세요. 쿠버네티스로 AI 서비스를 운영하는 방법은 배포 성공이 끝이 아니라, 문제가 생겼을 때 빠르게 원인을 찾고 되돌리는 과정까지 포함합니다.

---

6. 자주 묻는 질문 (FAQ)

Q1. GPU가 하나뿐이어도 쿠버네티스가 필요한가요?

반드시 필요한 것은 아닙니다. 단일 GPU에서 소규모 서비스를 운영한다면 Docker와 systemd가 더 단순할 수 있습니다. 다만 여러 환경을 통일하거나 향후 노드 확장, 롤링 배포, 표준화된 모니터링이 필요하다면 작은 클러스터부터 쿠버네티스를 도입할 이유가 생깁니다.

Q2. LLM 모델마다 별도 GPU를 배정해야 하나요?

모델 크기와 동시 요청량에 따라 다릅니다. 메모리에 모델이 들어가고 간섭이 허용된다면 한 GPU에서 여러 서버를 운영할 수 있지만, 메모리 부족과 지연 시간 변동 위험이 커집니다. 모델별 자원 요구량을 측정한 뒤 독립 배정, GPU 분할, 요청 라우팅을 비교하는 방식이 안전합니다.

Q3. 모델 파일은 어디에 저장하는 것이 좋나요?

오브젝트 스토리지는 버전 관리와 내구성 측면에서 편리하고, 영구 볼륨은 반복 로딩을 줄이는 데 유리합니다. 어느 한 방식이 정답은 아닙니다. 모델 버전과 체크섬을 관리하고, 장애 시 재다운로드 가능한지, 초기 기동 시간이 서비스 수준 목표를 만족하는지 확인해 선택하세요.

Q4. 오토스케일링이 응답 지연을 항상 줄여 주나요?

그렇지 않습니다. 새 GPU 노드와 Pod가 준비되는 시간이 길면 트래픽 급증이 이미 지나간 뒤 확장될 수 있습니다. 최소 상시 용량, 큐 기반 선행 확장, 적절한 scale-down 지연, 요청 제한을 함께 설계해야 합니다. 확장 전후의 p95 지연과 비용을 실제 부하 테스트로 비교해야 합니다.

---

7. 마무리

쿠버네티스로 AI 서비스를 운영하는 방법은 GPU를 연결하고 모델을 띄우는 데서 끝나지 않습니다. 노드와 자원 스케줄링, 추론 엔진, 성능 지표, 확장 정책, 비용과 보안, 장애 대응을 하나의 운영 체계로 묶어야 합니다. 먼저 작은 모델과 제한된 트래픽으로 배포 파이프라인을 만들고, TTFT·토큰 처리량·GPU 메모리·오류율을 측정해 보세요. 그 결과를 바탕으로 모델 최적화와 자동화를 단계적으로 늘리는 접근이 가장 현실적입니다.

태그: #쿠버네티스 #AI서비스 #LLM배포 #GPU인프라 #MLOps

---

참고 자료

• Kubernetes GPU 스케줄링 공식 문서
• vLLM 최적화 공식 문서