LLM 애플리케이션은 인프라 상태가 멀쩡해도 출력 품질이 흔들리거나 비용이 갑자기 튀는 일이 자주 발생한다. AIOps는 이런 문제를 해결하기 위해 애플리케이션과 모델 사이에 운영 계층을 두고, 각 요청의 라우팅·정책·추적(trace)·예산을 한곳에서 통제하는 접근 방식이다. 단순 모니터링보다 한 단계 앞선 개념으로, AI를 프로토타입에서 프로덕션으로 옮기는 팀에 특히 중요하다.
왜 필요한가
기존 모니터링은 서버가 살아 있는지, 응답이 200인지, 지연 시간이 기준치를 넘는지만 잘 보여준다. 하지만 LLM 시스템에서 실제로 문제가 되는 것은 다음과 같다.
- 출력 품질 저하: 환각(hallucination), 관련성 저하, 톤 변화
- 추적 불가: 한 요청이 여러 모델 호출·도구 호출·검증 단계를 거쳐도 하나의 실행 흐름으로 보이지 않음
- 비용 드리프트(cost drift): 캐시 미스, 잘못된 라우팅, 과도한 재시도 때문에 비용이 조용히 증가
- 정책 불일치: 팀마다 다른 프롬프트, 모델, 가드레일을 사용해 운영 기준이 무너짐
AIOps의 핵심 구성 요소
1. 요청 단위 추적(traceability)
사용자 요청 하나가 어떤 프롬프트 버전, 어떤 모델, 어떤 툴 호출, 어떤 검증 단계를 거쳤는지 하나의 실행 컨텍스트로 묶어 본다. 디버깅이 “여러 로그를 손으로 맞춰보는 일”에서 “한 트레이스를 따라가는 일”로 바뀐다.
2. 라우팅과 정책
작업 유형이나 민감도에 따라 모델을 다르게 선택하고, 비용 상한·지연 시간 상한·리전 제한·허용 도구를 정책으로 강제한다.
3. 품질 관측
정답률, 근거 포함 여부, 포맷 준수, 거부율 같은 품질 지표를 인프라 지표와 분리해 관찰한다. “API는 정상인데 답변은 망가진 상태”를 감지하는 데 필요하다.
4. 비용 제어
청구서가 나온 뒤 비용을 보는 것이 아니라, 요청 실행 중에 토큰 사용량·캐시 활용 여부·재시도 횟수를 보고 제어한다.
MLOps·LLMOps와 무엇이 다른가
| 관점 | MLOps | LLMOps | AIOps |
|---|---|---|---|
| 초점 | 모델 학습·배포 | 프롬프트·모델 호출 운영 | 요청 실행 전체의 통제 |
| 대표 지표 | 정확도, 재현율, 드리프트 | 토큰, 레이턴시, 프롬프트 버전 | 품질, 정책 준수, 비용, 트레이스 |
| 문제 해결 방식 | 모델 재학습·배포 파이프라인 | 프롬프트/모델 조정 | 라우팅·정책·가드레일·관측 계층 |
| 적합한 팀 | ML 플랫폼 팀 | AI 앱 팀 | 프로덕션 플랫폼·플랫폼 엔지니어링 팀 |
언제 쓰면 좋은가
- 여러 모델 프로바이더를 섞어 쓰는 팀
- 툴 호출과 워크플로우가 복잡한 에이전트형 제품
- 비용 예측 가능성과 감사를 중요하게 보는 조직
- “문제는 있는데 어디서 생겼는지 모른다”가 반복되는 서비스
시작 방법
처음부터 거대한 플랫폼을 만들 필요는 없다. 가장 중요한 워크플로우 하나를 골라서 아래 순서로 시작하는 편이 현실적이다.
- 요청 ID 기준으로 모델 호출·툴 호출·검증 단계를 한 트레이스로 묶는다.
- 프롬프트 버전, 모델명, 토큰 수, 응답 품질 메타데이터를 함께 남긴다.
- 비용 한도와 허용 모델 정책을 강제한다.
- 품질 저하와 비용 급등을 같은 대시보드에서 본다.
라이선스 및 참고
AIOps는 특정 오픈소스 프로젝트명이 아니라 운영 개념이다. 상용 게이트웨이, 자체 플랫폼, 관측 스택을 조합해 구현할 수 있다.
관련 문서
- agent-governance — 에이전트 실행 흐름의 권한·비용·정책을 런타임에 통제
- portkey-models — 다중 프로바이더 가격 정보를 무료 API로 조회
- codeburn — AI 코딩 에이전트 사용량·비용 시각화
- rag — 외부 지식을 주입하는 대표적인 LLM 애플리케이션 패턴
참고 자료
- What is AIOps? — Portkey Blog (2026-04-16)