비용, 안정성, 관측 가능성 설계하기

비용 관리는 클러스터 운영의 일부다

AI 플랫폼의 비용은 월말 청구서에서 처음 발견되면 늦습니다. 특히 GPU를 쓰는 조직에서는 작은 설정 실수도 큰 비용으로 이어집니다. GPU 노드가 켜져 있지만 실제 작업이 없거나, 학습 Job이 대기열에 오래 머물거나, 추론 서비스가 피크 트래픽에 맞춰 과도하게 고정되어 있으면 비용은 빠르게 늘어납니다.

이 장의 목표는 비용을 무조건 줄이는 것이 아닙니다. 중요한 것은 어떤 팀, 어떤 모델, 어떤 워크로드가 비용을 만들고 있는지 설명할 수 있는 상태를 만드는 것입니다. 그래야 비용 절감과 안정성 사이에서 균형 있는 결정을 할 수 있습니다.

초기부터 모든 것을 정교하게 만들 필요는 없습니다. 대신 다음 세 가지 질문에 답할 수 있어야 합니다.

• 어떤 GPU가 얼마나 놀고 있는가?

• 어떤 워크로드가 비용을 만들고 있는가?

• 비용을 줄이면 어떤 안정성 위험이 생기는가?

AI 생성 이미지

AI 인프라 비용을 읽는 세 가지 지표

AI 플랫폼 비용은 단순히 노드 개수로만 보면 부족합니다. 같은 GPU 노드 10대를 운영해도 어떤 조직은 학습 처리량을 높이고, 어떤 조직은 대부분 유휴 상태로 둡니다. 비용을 해석하려면 GPU 유휴 시간, 노드별 비용, 작업 대기 시간을 함께 봐야 합니다.

첫째, GPU 유휴 시간입니다. GPU는 요청되었지만 실제 사용률이 낮을 때 가장 비싼 낭비가 됩니다. 예를 들어 한 학습 Pod가 GPU 1개를 8시간 요청했지만 평균 사용률이 20%라면, 남은 80%는 다른 작업에 쓰이지 못했을 가능성이 큽니다. AWS의 GPU 비용 귀속 예시에서도 Kubernetes 리소스 요청량과 실제 GPU 사용량을 함께 보며 할당 비용, 유효 비용, 낭비 비용을 구분하는 방식을 제시합니다¹. 실제 공식은 조직의 과금 모델에 따라 달라질 수 있지만, 관점은 동일합니다.

할당 비용 = 요청한 GPU 수 × 실행 시간 × 시간당 단가
유효 비용 = 실제 GPU 사용률을 반영한 비용
낭비 비용 = 할당 비용 - 유효 비용

둘째, 노드별 비용입니다. GPU가 비싸다고 해서 GPU 지표만 보면 안 됩니다. GPU 노드에 CPU 중심 전처리 작업이 올라가거나, 특정 팀의 실험 Pod가 고가 노드를 장시간 점유할 수 있습니다. 그래서 모든 워크로드에는 최소한 team, env, workload_type, model_name, cost_center 같은 라벨이 있어야 합니다. 라벨이 없으면 비용은 클러스터 전체 비용으로만 보이고, 누가 무엇을 개선해야 하는지 알 수 없습니다.

셋째, 작업 대기 시간입니다. 학습 Job이 오래 Pending 상태에 머무른다면 두 가지 가능성이 있습니다. 하나는 실제로 GPU가 부족한 것입니다. 다른 하나는 스케줄링 조건이 너무 좁거나, 쿼터와 노드 라벨이 맞지 않는 것입니다. 대기 시간이 길면 연구 생산성이 떨어지고, 급한 팀은 별도 VM이나 외부 서비스를 임시로 쓰기 시작합니다. 이때 플랫폼 비용은 줄어든 것처럼 보여도 조직 전체 비용은 오히려 늘어날 수 있습니다.

이 세 지표는 따로 보면 오해하기 쉽습니다. GPU 유휴 시간이 낮다고 해서 항상 좋은 것은 아닙니다. 모든 GPU가 바쁘게 돌아가지만 Job 대기 시간이 계속 늘어난다면, 플랫폼은 이미 병목 상태일 수 있습니다. 반대로 Pending 시간은 짧지만 GPU 사용률이 낮다면, 요청량이 과하게 잡혔거나 작업이 GPU를 충분히 활용하지 못하고 있을 가능성이 큽니다.

기본 관측 가능성 스택

관측 가능성은 문제가 생겼을 때 원인을 찾는 능력입니다. Kubernetes 기반 AI 플랫폼에서는 로그만으로 충분하지 않습니다. 최소한 메트릭, 로그, 이벤트, 트레이스를 함께 수집해야 합니다.

기본 구성은 다음처럼 시작할 수 있습니다.

• Prometheus: CPU, 메모리, GPU, Pod 상태, 요청 수, 지연 시간 같은 메트릭 수집

• Grafana: 팀과 서비스가 함께 보는 대시보드 구성

• OpenTelemetry Collector: 애플리케이션의 트레이스, 메트릭, 로그를 표준 방식으로 수집하고 전달

• kube-state-metrics: Deployment, Pod, Job, PVC 같은 Kubernetes 리소스 상태 수집

• node-exporter: 노드의 CPU, 메모리, 디스크, 네트워크 지표 수집

• DCGM Exporter: NVIDIA GPU 사용률, GPU 메모리, 온도, 전력 같은 지표 수집

Prometheus Operator 기반 구성은 ServiceMonitor와 PodMonitor를 통해 수집 대상을 선언적으로 관리할 수 있어 운영 부담을 줄입니다². AI 플랫폼에서는 여기에 GPU 지표와 모델 서비스 지표를 추가해야 합니다.

대시보드는 처음부터 많을 필요가 없습니다. 최소한 세 종류면 충분합니다.

주의할 점은 메트릭을 많이 모으는 것이 좋은 관측 가능성은 아니라는 것입니다. Prometheus 계열 시스템에서는 라벨 조합이 많아질수록 시계열 수가 증가하고 저장·조회 비용이 커집니다. user_id, request_id, 이메일, 세션 토큰처럼 값이 거의 매번 바뀌는 항목은 메트릭 라벨로 넣지 않는 것이 좋습니다. 이런 값은 로그나 트레이스에 남기고, 메트릭 라벨은 팀, 환경, 서비스, 모델 버전처럼 집계 가능한 값으로 제한합니다.

이 기준을 정하지 않으면 관측 가능성 도구 자체가 또 하나의 비용 원인이 됩니다. 특히 모델명, 프롬프트 템플릿, 실험 ID를 모두 라벨로 넣기 시작하면 대시보드는 풍부해 보이지만 Prometheus 저장소는 빠르게 커집니다. 자주 집계할 값은 메트릭 라벨로, 개별 요청을 추적할 값은 로그와 트레이스로 보내는 식으로 역할을 나누는 것이 안전합니다.

학습 Job과 추론 Deployment의 SLO는 달라야 한다

SLO는 서비스 수준 목표입니다. 예를 들어 월간 가용성 99.9%, p95 응답 시간 500ms 이하 같은 목표를 말합니다. AI 플랫폼에서는 모든 워크로드에 같은 SLO를 적용하면 오히려 판단이 흐려집니다.

학습 Job은 완료형 작업입니다. 사용자가 매초 요청을 보내는 서비스가 아니므로 응답 시간보다 완료 시간과 재시도 가능성이 중요합니다. 반면 추론 Deployment는 상시 서비스입니다. 사용자가 기다리고 있으므로 지연 시간, 오류율, 가용성이 핵심입니다.

예를 들어 학습 Job의 SLO는 다음처럼 잡을 수 있습니다.

• 중요 학습 Job의 95%는 제출 후 12시간 안에 완료된다.

• GPU Job의 평균 Pending 시간은 30분 이하로 유지한다.

• 실패한 학습 Job의 90%는 체크포인트에서 재시작할 수 있다.

추론 서비스의 SLO는 다르게 잡아야 합니다. 아래 숫자는 예시이며, 실제 목표는 모델 크기, 사용자가 기다릴 수 있는 시간, 비즈니스 중요도에 맞춰 정해야 합니다.

• 월간 가용성은 99.5% 이상으로 유지한다.

• p95 응답 시간은 800ms 이하로 유지한다.

• 5xx 오류율은 1% 이하로 유지한다.

• 새 모델 배포 후 오류율이 기준선보다 2배 이상 증가하면 자동 또는 수동 롤백한다.

LLM이나 RAG 서비스라면 여기에 토큰 생성 속도, 첫 토큰까지 걸리는 시간, 검색 단계 지연 시간, 도구 호출 실패율도 추가할 수 있습니다. AI 관측 가능성에서는 인프라 상태, 모델·애플리케이션 동작, 사용자 관점의 서비스 신뢰성을 나누어 보는 것이 중요합니다³.

비용 최적화는 세 가지 용량을 섞는 일이다

AI 인프라 비용 최적화는 하나의 기술로 해결되지 않습니다. 보통 예약 용량, 온디맨드 용량, 스팟 또는 선점형 용량을 조합합니다.

예약 인스턴스 또는 약정 용량은 예측 가능한 운영 추론 서비스에 적합합니다. 매일 일정 수준 이상 트래픽이 있는 모델 API, 항상 켜져 있어야 하는 임베딩 서비스, 내부 검색 서비스는 기본 용량을 예약해 단가를 낮출 수 있습니다. 단점은 약정한 만큼 사용하지 못하면 비용이 고정된다는 점입니다.

온디맨드 용량은 피크 대응과 예측이 어려운 실험에 적합합니다. 새 모델을 검증하거나 일시적으로 트래픽이 증가하는 경우에는 고정 약정보다 유연성이 중요합니다. 단가는 높지만 과도한 사전 약정을 피할 수 있습니다.

스팟 또는 선점형 인스턴스는 중단을 견딜 수 있는 작업에 적합합니다. 전처리, 배치 추론, 실험 학습, 체크포인트가 잘 설계된 파인튜닝 작업은 스팟을 활용할 수 있습니다. 다만 실시간 추론의 주 경로에 스팟만 사용하는 것은 위험합니다. 스팟 인스턴스는 클라우드 사업자의 여유 용량을 활용하는 방식이므로 언제든 중단될 수 있습니다. AWS 공식 문서에서도 스팟 중단에 대비해 작업을 작은 단위로 나누거나 체크포인트를 남기고, 중요한 데이터를 영속 저장소에 보관하며, 중단 알림에 대응하도록 권장합니다⁴.

오토스케일링은 이 세 가지 용량을 연결합니다. HPA는 Pod replica 수를 조정하고, KEDA는 큐 길이 같은 이벤트 기반 지표로 확장할 수 있으며, Cluster Autoscaler나 Karpenter는 필요한 노드를 늘리거나 줄입니다. 하지만 GPU 워크로드에서는 스케일아웃이 즉시 일어나지 않을 수 있습니다. GPU 노드 프로비저닝, 드라이버 준비, 이미지 다운로드, 모델 로딩 시간이 모두 걸리기 때문입니다. 따라서 추론 서비스에는 최소 replica와 준비된 기본 용량이 필요합니다.

실무적으로는 다음 원칙이 안전합니다.

• 운영 추론의 기본 트래픽은 예약 용량으로 감당한다.

• 피크 트래픽은 온디맨드와 오토스케일링으로 흡수한다.

• 중단 가능한 학습·배치 작업은 스팟 노드 풀로 보낸다.

• 중요한 학습은 체크포인트를 남기고, 재시작 가능한 구조로 만든다.

• GPU 노드에는 GPU가 필요한 Pod만 올라가도록 taint, toleration, nodeSelector를 유지한다.

여기서 중요한 것은 가장 싼 용량을 찾는 것이 아니라, 워크로드의 실패 비용에 맞는 용량을 고르는 것입니다. 실패해도 다시 실행하면 되는 배치 작업과, 장애가 곧 고객 불만으로 이어지는 실시간 추론 서비스는 같은 기준으로 배치하면 안 됩니다.

장애 대응은 모델 버전까지 함께 본다

AI 서비스 장애는 일반 웹 서비스 장애보다 원인이 넓습니다. Pod가 죽었을 수도 있고, GPU 메모리가 부족할 수도 있고, 새 모델의 응답 시간이 길어졌을 수도 있습니다. RAG 서비스라면 벡터 데이터베이스나 검색 품질 변화가 원인일 수 있습니다. 그래서 장애 대응 절차에는 로그, 메트릭, 이벤트, 모델 버전이 함께 들어가야 합니다.

장애가 발생하면 다음 순서로 확인합니다.

1. 영향 범위 확인: 전체 서비스인지, 특정 모델인지, 특정 tenant인지 확인합니다.

2. 시간대 고정: 오류가 시작된 시점을 Grafana와 배포 이력에서 맞춥니다.

3. 모델 버전 확인: 최근 배포된 모델, 프롬프트, 데이터, 피처, 설정 변경을 확인합니다.

4. Kubernetes 이벤트 확인: Pod 재시작, OOMKilled, ImagePullBackOff, FailedScheduling 여부를 봅니다.

5. 서비스 메트릭 확인: 요청 수, 오류율, p95/p99 지연 시간, 큐 길이, 타임아웃을 봅니다.

6. GPU 메트릭 확인: GPU 사용률, GPU 메모리, 전력, 노드별 병목을 확인합니다.

7. 로그와 트레이스 확인: 특정 요청이 API, 검색, 모델 서버, 외부 API 중 어디에서 지연되는지 추적합니다.

8. 대응 선택: 롤백, replica 확장, 트래픽 제한, 큐 비우기, 노드 격리, 이전 모델 전환 중 하나를 선택합니다.

이 절차가 작동하려면 배포 시점부터 메타데이터가 남아야 합니다. 모든 추론 Deployment와 학습 Job에는 다음 라벨 또는 annotation을 붙이는 것이 좋습니다.

team: recommendation
env: prod
workload_type: inference
model_name: ranker
model_version: v2026-07-20
pipeline_run_id: run-1842
cost_center: growth-ai

이 정보가 있으면 장애 분석과 비용 분석이 같은 언어로 연결됩니다. 예를 들어 특정 모델 버전 배포 후 p95 지연 시간이 증가하고 GPU 메모리 사용량도 상승했다면, 단순히 replica를 늘리는 것보다 모델 최적화나 배치 크기 조정이 먼저일 수 있습니다. 반대로 오류율은 그대로인데 Pending 시간이 늘었다면 GPU 노드 용량이나 스케줄링 정책을 봐야 합니다.

장애 회고에서도 같은 원칙이 필요합니다. "GPU가 부족했다"로 끝내기보다, 어떤 모델 버전이 어떤 트래픽에서 어떤 자원을 더 사용했는지까지 남겨야 다음 결정을 할 수 있습니다. 그래야 같은 장애를 줄이는 동시에, 불필요한 고정 용량도 피할 수 있습니다.

운영 습관 체크리스트

마지막으로, 비용과 안정성은 도구보다 습관에 가깝습니다. 다음 항목을 정기적으로 확인하면 플랫폼이 커져도 통제력을 잃지 않을 가능성이 높아집니다.

• 팀, 환경, 모델, 비용 센터 라벨이 모든 워크로드에 붙어 있는가?

• GPU 유휴 시간과 팀별 GPU 사용 시간이 주간 단위로 공유되는가?

• 학습 Job의 Pending 시간과 실패 후 재시작 가능성을 측정하는가?

• 추론 서비스의 p95 지연 시간, 오류율, 모델 버전을 같은 화면에서 보는가?

• Prometheus 메트릭 라벨에 고유 ID를 넣어 비용을 키우고 있지 않은가?

• 스팟 노드에 올라가는 작업은 중단과 재시도를 견딜 수 있는가?

• 운영 추론 서비스의 기본 용량과 피크 대응 용량이 분리되어 있는가?

• 장애 회고에 인프라 원인뿐 아니라 모델 버전, 데이터 변경, 프롬프트 변경이 포함되는가?

AI 플랫폼은 실험 속도와 운영 안정성을 동시에 요구합니다. 비용을 줄이기 위해 안정성을 희생하면 신뢰를 잃고, 안정성만 위해 과도하게 고정 용량을 잡으면 플랫폼 확장이 어려워집니다. 좋은 운영 설계는 이 둘을 분리해서 보지 않습니다. 비용, 안정성, 관측 가능성을 같은 대시보드와 같은 의사결정 과정 안에 두는 것이 출발점입니다.

참고

¹GPU Cost Attribution in Amazon EKS Using Amazon Managed Service for Prometheus, Amazon Managed Grafana, and OpenTelemetry

²Getting Started - Prometheus Operator

³AI Observability: Tools and Best Practices

⁴Prepare for Spot Instance interruptions - Amazon EC2 User Guide