1. AI 에이전트와 LLM이 들어온 쿠버네티스
지난 한 해 동안 IT 운영 환경에서 또렷하게 보이는 변화가 하나 있습니다. 단순 사내 챗봇을 넘어 사용자 응대 에이전트, 사내 RAG 시스템, 임베딩·벡터 DB 같은 AI 워크로드를 쿠버네티스(이하 K8s)에서 운영하는 사례가 빠르게 늘고 있다는 점입니다.
CNCF가 2026년 1월 발표한 2025년 연례 조사는 이 추세를 잘 보여 줍니다. 컨테이너 사용 응답자의 82%가 K8s를 프로덕션에서 운영하고 있고, 생성형 AI 모델을 호스팅하는 조직의 66%가 추론 워크로드 일부 또는 전부를 K8s에서 운영하고 있다는 결과입니다. CNCF가 보고서 제목을 "Kubernetes Established as the De Facto 'Operating System' for AI"로 붙였을 만큼, K8s가 AI 운영의 기본 인프라로 자리 잡았다는 메시지가 강합니다.
이러한 변화는 표준화 작업으로도 빠르게 이어지고 있습니다. CNCF는 Certified Kubernetes AI Conformance Program을 발표해, K8s 환경에서 동작하는 AI 워크로드의 호환성·재현성 표준을 마련하는 작업을 시작했습니다. 한편 추론 서버 영역에서도 NVIDIA Triton·vLLM 같은 도구가 K8s 환경에서 널리 활용되면서, 운영팀이 GPU 자원과 추론 워크로드를 직접 관리해야 하는 사례도 빠르게 늘고 있습니다.
이런 추세로 인해 운영팀에는 새로운 의문이 생기고 있습니다. GPU 자원, 모델 응답 품질, 토큰 사용량, 추론 호출 흐름까지. 지금까지 K8s 환경에서 충분히 다뤄 본 적 없는 데이터도 운영 데이터로 함께 봐야 하는가 하는 질문입니다.
앞서 AI 에이전트가 IT 운영을 어디까지 자동화하고 있나에서는 AI 에이전트가 운영 업무에 들어오는 흐름을 다뤘습니다. 이번 글은 그 기반이 되는 인프라 관점에서 운영팀이 AI 워크로드를 K8s 환경에서 직접 운영하게 됐을 때 옵저버빌리티가 어떻게 달라지는지를 정리합니다.
2. K8s 옵저버빌리티 영역이 넓어지는 이유
K8s 운영의 옵저버빌리티는 그동안 인프라·플랫폼·애플리케이션·네트워크 4가지 영역을 중심으로 정리되어 왔습니다. 그런데 최근 AI 워크로드가 클러스터에서 운영되기 시작하면서, 이 기존 데이터 영역에 더해 새로 챙겨야 할 데이터가 늘고 있습니다.
일반 워크로드와 AI 워크로드의 옵저버빌리티 데이터를 비교해 보면, 차이가 또렷하게 드러납니다.
구분 | 일반 워크로드 | AI 워크로드 |
핵심 자원 | CPU·메모리·디스크 | GPU 사용률·VRAM·텐서 코어 |
요청 단위 지표 | 응답 시간·에러율 | 응답 시간 + 토큰 사용량 + 응답 품질 |
호출 흐름 | 서비스 간 분산 트레이스 | 서비스 트레이스 + 추론 단계·툴 호출·RAG 검색 |
비용 구조 | CPU 시간·트래픽 단가 | GPU 시간 + 모델 토큰 단가 + 외부 API 호출 |
품질 정의 | 응답 코드 200/500 | 응답 정확도·환각률·사용자 피드백 |
한 사용자 요청에 대해 인프라 데이터와 AI 워크로드 데이터를 같은 시간 축으로 따라가지 못하면, 사고가 났을 때 원인이 GPU 지원에 있는지, 모델 자체에 있는지, 호출한 외부 API에 있는지를 좁히기 어렵습니다.
운영 비용 측면에서도 두 데이터를 함께 봐야 할 이유가 분명합니다. Gartner는 2025년 9월 발표에서 전 세계 AI 지출이 2025년 1.5조 달러 규모에 이르고, 이 가운데 AI 서버 지출의 90% 이상이 GPU에 들어간다고 분석했습니다. 학습이든 추론이든 AI 인프라 비용에서 GPU가 차지하는 비중이 큰 만큼, 운영팀이 GPU 자원과 모델 응답을 함께 보지 못하면 비용 통제부터 어려워질 수 있습니다.
AI 옵저버빌리티와 K8s 옵저버빌리티를 별도로 도입하면, 장애 상황에서 두 데이터를 시간 축에 맞춰 해석하는 일이 운영팀의 추가 부담으로 남을 수 있습니다. 도입 단계에서 두 데이터를 같은 분석 흐름 안에서 볼 수 있는 구조인지 미리 확인해야 합니다.
3. AI 워크로드를 K8s에서 운영할 때 함께 챙겨야 할 4가지 데이터 영역
AI 워크로드를 K8s에서 운영하기 시작하면, 기존 인프라·플랫폼·애플리케이션·네트워크 중심의 옵저버빌리티만으로는 운영 상태를 충분히 설명하기 어려워집니다. 완전히 새로운 영역이 따로 생긴다기보다, 기존 메트릭·로그·트레이스에 더해 AI 추론 환경에서 함께 봐야 할 관측 항목이 확장된다고 보는 편이 더 정확합니다.
운영 단계에서 특히 중요해지는 항목은 GPU 자원과 추론 인프라, 모델 응답 품질, 추론 트레이스와 토큰 흐름, 그리고 RAG를 포함한 데이터 파이프라인입니다.
3-1. GPU 자원과 추론 인프라
GPU는 AI 워크로드 환경에서 비용 부담이 크고, 병목이 발생했을 때 서비스 영향도 큰 자원입니다. 운영 단계에서는 GPU 사용률뿐 아니라 메모리 사용량(VRAM), 모델별 점유 패턴, 노드 간 부하 편차, 요청 큐 적체 여부를 함께 봐야 실제 병목 지점을 파악할 수 있습니다. NVIDIA Triton Inference Server는 Prometheus 호환 메트릭 엔드포인트를 제공하므로, 기존 K8s 메트릭 수집 체계와 연결하기에 유리합니다.
다만 GPU는 일반 CPU와 같은 방식으로 해석하면 안 됩니다. CPU는 평균 사용률 중심으로 상태를 판단하는 경우가 많지만, GPU 추론 환경에서는 순간적인 메모리 압박이나 모델 로딩 상태 변화가 곧바로 지연 증가나 요청 실패로 이어질 수 있습니다. 따라서 평균 사용률보다 피크 구간의 메모리 압박, 모델별 자원 점유, 배치 설정 변화 이후의 응답 패턴을 함께 보는 것이 더 중요합니다.
3-2. 모델 응답 품질
기존 애플리케이션 모니터링에서는 응답 코드와 지연 시간만으로 서비스 상태를 어느 정도 판단할 수 있었습니다. 하지만 AI 워크로드에서는 요청이 정상적으로 처리되더라도 답변 품질까지 보장되는 것은 아닙니다. 시스템 지표상으로는 문제가 없어 보여도, 실제 응답의 정확성·일관성·적절성은 기대 수준에 미치지 못할 수 있기 때문입니다.
운영 단계에서 참고할 수 있는 품질 지표로는 응답 길이 이상치, 환각 의심 응답 비율, 사용자 피드백 등이 있습니다. 여기에 가드레일 우회 시도나 민감정보 패턴 탐지는 보안·컴플라이언스 관점에서 함께 챙겨야 할 항목입니다. 다만 환각률처럼 응답 내용을 직접 평가해야 하는 지표는 실시간 자동 측정이 어렵기 때문에, 별도 평가 모델이나 샘플링 검수, 평가셋 기반 점검과 함께 다뤄지는 경우가 많습니다.
이런 데이터는 CPU 사용률이나 응답 시간처럼 바로 해석할 수 있는 인프라 메트릭과는 성격이 다릅니다. 그럼에도 운영팀이 이상 시점을 조기에 포착하려면, 모델 응답 품질 데이터도 인프라·애플리케이션 데이터와 같은 시간 축에서 함께 볼 수 있어야 합니다.
3-3. 추론 트레이스와 토큰 흐름
LLM이 기반 서비스의 응답 과정은 단순한 단일 API 호출로 끝나지 않는 경우가 많습니다. 사용자 요청이 들어오면 모델 호출 전에 RAG가 벡터 DB에서 관련 문서를 검색하고, 필요에 따라 외부 도구나 API를 호출한 뒤, 그 결과를 다시 프롬프트에 반영해 최종 응답을 생성합니다. 이 흐름을 추적 가능한 트레이스로 남기지 않으면, 지연이 어느 구간에서 발생했는지 사후에 분석하기 어렵습니다.
OpenTelemetry GenAI Semantic Conventions는 이러한 추론 데이터를 공통 형식으로 정리하기 위한 유력한 기준입니다. 예를 들어 어떤 모델이 호출됐는지, 입력·출력 토큰이 얼마나 사용됐는지, 어느 시스템이나 도구를 거쳤는지를 표준 속성 형태로 남길 수 있습니다.
gen_ai.system, gen_ai.request.model, gen_ai.usage.input_tokens, gen_ai.usage.output_tokens 같은 속성이 여기에 해당합니다.운영 환경에서는 추론 지연, 토큰 사용량, 외부 도구 호출 시간, 검색 단계 지연을 하나의 트레이스 안에서 연결해 볼 수 있어야 합니다. 그래야 응답 지연이 모델 자체의 문제인지, 검색 단계의 병목인지, 외부 API 호출 지연인지 구분할 수 있습니다. 도구를 새로 도입하거나 교체할 때도, 데이터가 특정 벤더 형식에 과도하게 묶이는 문제를 줄이는 데 도움이 됩니다.
3-4. 데이터 파이프라인 (RAG와 벡터 DB)
검색증강생성(RAG) 구조에서는 모델 자체만이 아니라, 모델 바깥의 데이터 경로도 핵심 운영 대상이 됩니다. 벡터 데이터베이스 검색 시간, 검색 결과 관련성, 재순위화 지연, 임베딩 호출 비율, 캐시 적중률, 외부 API 의존도 같은 지표가 여기에 포함됩니다. 사용자에게는 단순한 응답 지연이나 품질 저하처럼 보이더라도, 실제 원인은 모델이 아니라 검색 단계나 외부 데이터 경로에 있을 수 있습니다.
특히 이 영역은 기존 운영팀이 가장 놓치기 쉬운 부분입니다. 모델 응답 시간만 보면 정상처럼 보여도, 벡터 DB 검색 지연이나 캐시 미스 증가로 인해 외부 임베딩 호출 비용이 늘어날 수 있기 때문입니다. 따라서 AI 워크로드 운영에서는 모델 자체의 상태뿐 아니라, 답변 생성에 동원되는 데이터 파이프라인 전체를 함께 관측 대상으로 잡아야 합니다.
4. 인프라 옵저버빌리티와 AI 옵저버빌리티가 만나는 지점
AI 워크로드 데이터만 따로 봐서는 운영 가치가 절반에 그칩니다. 실제 운영에서 중요한 것은 K8s 옵저버빌리티의 기존 데이터 영역과 AI 워크로드의 관측 데이터를 같은 시간 축과 같은 서비스 맥락에서 연결해 해석하는 일입니다. 장애 원인 분석, 성능 최적화, 비용 통제 모두 이 연결이 이뤄질 때 비로소 실무적인 의미를 갖습니다.
4-1. GPU 자원 압박이 추론 품질과 지연에 미치는 영향
GPU 자원 압박은 단순히 사용률 상승으로 끝나지 않고, 추론 지연 증가나 요청 실패, 응답 품질 저하 신호로 이어질 수 있습니다. 예를 들어 VRAM 여유가 줄어드는 시점에는 큰 컨텍스트 요청 처리 비율이 낮아지거나, 배치 전략이 바뀌면서 응답 지연이 길어지고 일부 요청의 출력 길이 분포가 달라질 수 있습니다.
이때 인프라 메트릭만 보면 GPU 사용률이 크게 높지 않아 보여도, 응답 길이 분포나 요청 실패율, 토큰 처리량을 함께 보면 같은 시점의 이상 징후가 더 분명하게 드러납니다. 핵심은 특정 지표 하나로 상태를 단정하지 않는 것입니다. GPU 사용률, VRAM 압박, 큐 적체, 토큰 처리량, 출력 길이 분포를 함께 봐야 합니다. 그래야 원인이 자원 문제인지, 모델 설정 변화인지, 프롬프트 특성 변화인지 구분할 수 있습니다.
4-2. K8s 이벤트가 추론 지연으로 이어지는 흐름
K8s 환경에서는 추론 성능 저하가 애플리케이션 코드 변경 없이도 발생할 수 있습니다. GPU Pod가 롤링 업데이트, 노드 장애 복구, 축출, 오토스케일링 같은 이벤트로 재생성되면 모델 가중치 로딩, 런타임 초기화, 캐시 재형성 과정 때문에 초기 지연이 커질 수 있습니다. 사용자에게는 단순한 응답 지연으로 보이지만, 실제 원인은 애플리케이션 내부가 아니라 K8s 운영 이벤트일 수 있습니다.
이 패턴은 K8s 이벤트와 추론 지연 데이터를 같은 시간 축에서 맞춰 봐야 드러납니다. 두 데이터가 서로 다른 도구에 흩어져 있으면, 운영팀은 지연 급증 시점을 발견하고도 그 직전에 어떤 인프라 이벤트가 있었는지 바로 연결하지 못합니다. AI 워크로드 환경에서는 분산 트레이스만으로 충분하지 않고, 클러스터 이벤트·배포 이력·노드 상태 변화까지 함께 봐야 실제 원인을 좁힐 수 있습니다.
4-3. GPU 비용과 토큰 비용의 서비스 단위 통합
AI 워크로드 운영 비용은 인프라 비용과 모델 사용 비용이 동시에 발생하는 구조입니다. GPU 시간, 스토리지, 네트워크 같은 인프라 비용은 K8s 운영 데이터에 가깝고, 입력·출력 토큰 사용량이나 외부 API 호출 비용은 AI 워크로드 데이터에 가깝습니다. 두 비용을 따로 보면 총액은 알 수 있어도, 어떤 서비스나 어떤 모델 경로가 비용을 키우는지는 파악하기 어렵습니다.
5. 도입할 때 자주 놓치는 부분
AI 워크로드 옵저버빌리티를 실제로 도입하려 할 때, 현장에서 반복적으로 마주치는 문제들이 있습니다. 도구 선택과 데이터 구조 설계 단계에서 미리 짚어두면 시행착오를 줄일 수 있는 항목들을 정리해 보겠습니다.
1) 도구를 분리 도입할 때의 비용
AI 옵저버빌리티 도구와 인프라 옵저버빌리티 도구를 따로 도입하면, 두 데이터를 같은 시간 축에서 연결하는 작업이 운영팀의 별도 과제로 남습니다. 도구 도입 비용보다 데이터 통합 비용이 더 커지는 경우도 있습니다. 도입 초기부터 두 데이터를 같은 분석 엔진으로 흘려보낼 수 있는 구조인지 검토해 두는 것이 이후 작업량을 줄이는 데 도움이 됩니다.
2) 응답 품질 지표의 책임 소재
응답 품질 문제를 AI팀이나 데이터팀의 영역으로만 보는 경우가 있습니다. 그러나 사용자 입장에서 품질 저하는 응답 지연이나 오류와 구분되지 않는 경우가 많습니다. 운영팀이 응답 길이 이상치, 환각 의심 비율, 사용자 피드백 같은 품질 지표를 인프라 대시보드와 같은 화면에서 볼 수 있어야 이상 징후를 조기에 포착하고 원인을 분리할 수 있습니다.
3) 비용 데이터의 소유권과 태그 체계
인프라 비용과 토큰 비용을 각 팀이 별도로 관리하면, 특정 서비스의 전체 비용을 파악하려 할 때 부서 간 확인 과정이 길어질 수 있습니다. 서비스·모델·테넌트 단위의 공통 태그를 도입 초기에 맞춰두면, 이후 비용 귀속과 최적화 논의를 훨씬 빠르게 진행할 수 있습니다.
4) 추론 트레이스의 데이터 보관 정책
추론 트레이스는 요청마다 다단계 흐름이 기록되기 때문에 데이터 양이 빠르게 늘어납니다. 보관 기간과 샘플링 비율을 도입 전에 정해두지 않으면, 정작 장애 분석이 필요한 시점에 데이터가 이미 삭제되어 있는 상황이 발생할 수 있습니다. 전체 트레이스를 저장하기 어렵다면, 오류가 발생했거나 지연 임계치를 초과한 요청은 반드시 보관하는 조건부 샘플링 정책을 먼저 설계하는 것이 현실적입니다.
처음부터 전체 서비스에 적용하려 하면 범위가 커져 도입이 지연되는 경우가 많습니다. 핵심 서비스 한두 개를 대상으로 인프라와 AI 옵저버빌리티를 통합 구성해 효과를 먼저 확인한 뒤, 점진적으로 확장하는 방식이 현실적입니다.
국내 환경에서는 AI 기본법 관련 요건도 함께 검토해야 합니다. 사용자 응대 에이전트나 사내 RAG 시스템이 고영향 인공지능에 해당할 가능성이 있는지 확인하고, 필요한 경우 응답 로그, 민감정보 탐지, 감사 추적 데이터까지 옵저버빌리티 파이프라인과 함께 설계하는 편이 중복 구성을 줄이는 데 도움이 됩니다.
6. 도입 검토를 시작하기 전에
K8s 옵저버빌리티가 다루어 온 인프라·플랫폼·애플리케이션·네트워크 데이터는 AI 워크로드 환경에서도 여전히 기본이 됩니다. 다만 AI 워크로드를 K8s에서 운영하기 시작하면, GPU 자원 상태, 모델 응답 품질 신호, 추론 트레이스, RAG를 포함한 데이터 파이프라인처럼 기존 체계만으로는 충분히 설명하기 어려운 관측 항목을 함께 다뤄야 합니다.
중요한 것은 완전히 새로운 체계를 별도로 만드는 것이 아닙니다. 기존 운영 관측 체계 위에 AI 특화 데이터를 확장해 연결하는 접근이 더 현실적입니다. 이 두 영역을 같은 시간 축과 같은 서비스 맥락에서 보기 시작하면, 장애 원인 추적의 정확도를 높이고 성능과 비용을 함께 판단하는 운영 의사결정도 더 빨라질 수 있습니다.
DB·APM·인프라·로그·GPU·모델 응답 데이터를 하나의 흐름으로 연결해 보는 풀스택 옵저버빌리티 요구는 국내 운영 현장에서도 점차 커지고 있습니다. 엑셈의 exemONE은 이러한 방향에서 검토할 수 있는 통합 옵저버빌리티 플랫폼으로, K8s를 포함한 하이브리드 환경의 운영 데이터를 단일 플랫폼에서 다루는 구조를 제시하고 있습니다.
도입을 검토 중이라면, 먼저 우리 운영 환경이 아래 항목에 해당하는지 점검해 볼 필요가 있습니다.
- AI 추론 워크로드(LLM·임베딩·벡터 DB)를 K8s에서 운영하고 있지만, GPU 메트릭이 기존 인프라 모니터링 체계와 연결되어 있지 않은가
- 모델 응답 품질 데이터(응답 길이·환각률·피드백)가 운영 대시보드에서 함께 보이지 않는가
- GPU 비용과 토큰 비용, 외부 API 비용을 서비스나 모델 단위로 함께 비교할 수 있는 대시보드가 없는가
- 추론 트레이스가 OpenTelemetry GenAI 기준으로 정리되어 있지 않아, 도구 교체 시 데이터 연속성이 약해질 가능성이 있는가
위개별 도구 비교에 앞서 인프라 옵저버빌리티와 AI 옵저버빌리티를 어떤 구조로 연결할지부터 검토 일정에 포함하는 편이 좋습니다. AI 워크로드 운영에서는 어떤 도구를 선택하느냐만큼이나, 서로 다른 운영 데이터를 같은 시간 축과 같은 서비스 맥락으로 연결할 수 있느냐가 실제 운영 효율을 좌우하기 때문입니다.
출처
Kubernetes Established as the De Facto 'Operating System' for AI as Production Use Hits 82% in 2025 CNCF Annual Cloud Native Survey - CNCF (2026.01.20) CNCF Launches Certified Kubernetes AI Conformance Program - CNCF (2025.11.11) Cloud Native AI Whitepaper - CNCF TAG Runtime Semantic conventions for generative AI systems - OpenTelemetry Gartner Says Worldwide AI Spending Will Total $1.5 Trillion in 2025 - Gartner (2025.09.17) NVIDIA Triton Inference Server Documentation - NVIDIA 인공지능 발전과 신뢰 기반 조성 등에 관한 기본법 - 국가법령정보센터
함께 보면 좋은 아티클
