AIOps는 모니터링을 대체하지 않는다: 운영자가 알아야 할 진짜 역할

AIOps는 모니터링 엔지니어의 일을 없애지 않는다. 오히려 더 많은 판단을 요구한다. "AI가 알아서 고쳐 주는 시스템"을 기대했다가 오탐(False Positive) 폭탄을 맞은 팀이 적지 않다. 기본 지표와 로그가 부실한 상태에서 AIOps를 얹으면 잘못된 판단이 더 빠르게 확산될 뿐이다. 이 글은 AIOps를 어떤 맥락에서 받아들여야 하는지, 운영자 관점에서 정리한다.

요약

AIOps는 모니터링을 없애는 기술이 아니라, 모니터링과 Observability 데이터를 해석하고 운영 흐름으로 연결하는 계층에 가깝습니다. 장애 징후를 더 빨리 묶고, 원인 후보를 좁히고, 반복 대응을 자동화하는 데는 도움이 되지만 기본적인 지표, 로그, 트레이스, 알림 기준이 부실하면 오히려 잘못된 판단을 빠르게 확산시킬 수 있습니다.

클라우드 운영 관점에서 더 현실적인 질문은 이것입니다. "어떤 모니터링은 그대로 유지하고, 어떤 분석과 대응을 AI에 맡길 것인가?"

이 글이 필요한 사람

AWS, Azure, Kubernetes, DevOps 환경을 운영하면서 AIOps, AI 기반 모니터링, 지능형 장애 대응이라는 표현을 자주 접하는 초중급 인프라 실무자를 위한 글입니다.

특히 CloudWatch, Azure Monitor, Prometheus, Grafana, Datadog, New Relic 같은 도구를 이미 쓰고 있지만 알림이 많고 장애 원인 분석이 오래 걸리는 팀이라면, AIOps를 어떻게 받아들여야 할지 판단하는 데 도움이 됩니다.

왜 지금 AIOps 이야기가 다시 나오는가

운영 환경은 예전보다 훨씬 복잡해졌습니다.

하나의 서비스 장애를 보기 위해 이제는 VM 한두 대의 CPU 사용률만 보면 되지 않습니다. Kubernetes Pod 상태, API Gateway 지연 시간, 데이터베이스 커넥션, 메시지 큐 적체, 배포 이력, Feature Flag 변경, 외부 SaaS 의존성, LLM API 응답 품질까지 함께 봐야 하는 경우가 많습니다.

문제는 데이터가 늘어난 만큼 운영자의 판단이 쉬워진 것은 아니라는 점입니다. 메트릭은 많아졌지만 어떤 메트릭이 정말 중요한지 헷갈리고, 로그는 쌓이지만 장애 순간에 필요한 로그를 찾기 어렵고, 알림은 많지만 실제 고객 영향과 연결되지 않는 경우가 많습니다.

AIOps는 이 지점에서 등장합니다. AWS는 AIOps를 AI, ML, NLP 등을 이용해 성능 모니터링, 워크로드 스케줄링, 백업 같은 운영 작업을 자동화하고 여러 데이터 소스에서 실시간 인사이트를 얻는 접근으로 설명합니다. 중요한 것은 "도구 하나"라기보다 운영 데이터를 모으고, 분석하고, 판단 흐름으로 연결하는 방식이라는 점입니다.

모니터링, Observability, AIOps는 무엇이 다른가

세 용어는 비슷해 보이지만 역할이 다릅니다.

구분	핵심 질문	주된 역할
모니터링	지금 정상인가?	정해진 지표와 임계값으로 상태를 감시하고 알림을 보낸다
Observability	왜 이런 일이 일어났는가?	메트릭, 로그, 트레이스를 통해 시스템 내부 상태를 추론한다
AIOps	무엇을 먼저 보고 어떻게 대응할 것인가?	이상 징후, 이벤트, 변경 이력, 장애 기록을 연결해 원인 후보와 대응 방향을 제안한다

Google SRE에서 말하는 모니터링의 대표 기준은 지연 시간, 트래픽, 오류, 포화도입니다. 이 네 가지 신호는 지금도 유효합니다. AIOps가 나온다고 해서 서비스의 오류율, 응답 시간, 큐 길이, 디스크 사용률 같은 기본 지표가 사라지는 것은 아닙니다.

오히려 AIOps는 이런 기본 신호가 잘 수집되어 있을 때 효과가 커집니다. OpenTelemetry가 메트릭, 로그, 트레이스 수집을 위한 벤더 중립 프레임워크로 쓰이는 것도 같은 흐름입니다. AI가 장애를 설명하려면 먼저 설명할 수 있는 관측 데이터가 있어야 합니다.

AIOps가 잘하는 일

AIOps가 실무에서 가장 먼저 가치를 내는 영역은 "사람이 반복해서 하던 분류와 연결 작업"입니다.

알림을 묶어 줍니다. API 서버 오류율 증가, DB 커넥션 증가, 특정 배포 직후 지연 시간 상승이 각각 다른 알림으로 오면 운영자는 시간 순서와 의존성을 직접 맞춰야 합니다. AIOps는 시간, 서비스 토폴로지, 변경 이력, 과거 장애 기록을 바탕으로 관련 가능성이 높은 이벤트를 하나의 incident 후보로 묶을 수 있습니다.

정적 임계값의 한계를 줄입니다. 모든 시스템에 CPU 80%, 응답 시간 1초 같은 고정 기준을 적용하면 알림이 너무 많아지거나 반대로 중요한 이상 징후를 놓칠 수 있습니다. Amazon CloudWatch Anomaly Detection은 통계와 머신러닝 알고리즘으로 지표의 정상 범위를 만들고, Azure Monitor Dynamic Thresholds도 과거 패턴을 학습해 동적 임계값을 계산합니다. 이런 기능은 특히 주기성이 강한 트래픽이나 서비스별 정상 범위가 다른 환경에서 유용합니다.

장애 조사 시간을 줄여 줍니다. 최근 배포, 설정 변경, 특정 리전의 지표 변화, 의존 서비스 오류를 한 화면 또는 하나의 설명으로 묶어 주면 온콜 담당자는 처음 10분을 "어디서부터 봐야 하지?"에 쓰지 않아도 됩니다.

반복 대응을 자동화할 수 있습니다. 다만 이 부분은 조심해야 합니다. 캐시 재시작, read replica 증설, 특정 배치 중단처럼 영향 범위가 제한적이고 되돌릴 수 있는 작업부터 시작해야 합니다. 데이터 삭제, 보안 정책 변경, 대규모 스케일 조정처럼 위험한 작업은 승인 절차와 감사 로그가 먼저 있어야 합니다.

AIOps가 대체하기 어려운 일

AIOps가 아무리 좋아져도 운영자가 계속 가져가야 할 영역이 있습니다.

무엇이 중요한 서비스인지 정하는 일. 어떤 API가 핵심 고객 여정인지, 어떤 배치 실패가 실제 매출 영향으로 이어지는지, 어떤 장애는 즉시 깨워야 하고 어떤 장애는 근무 시간에 처리해도 되는지는 도구가 단독으로 결정하기 어렵습니다.

SLO와 장애 기준을 정하는 일. CloudWatch Application Signals는 지연 시간과 가용성 같은 지표를 기반으로 SLO를 만들고 대시보드에서 상태를 볼 수 있게 합니다. 하지만 어떤 서비스에 어떤 목표를 둘지는 팀의 비즈니스 맥락이 필요합니다. Azure Monitor나 Application Insights도 마찬가지입니다. 도구는 데이터를 보여 주지만, 운영 기준은 팀이 정해야 합니다.

잘못된 자동화를 막는 일. AIOps는 관측 데이터를 입력으로 삼기 때문에 잘못된 로그, 누락된 태그, 과도한 샘플링, 민감 정보가 섞인 프롬프트, 조작 가능한 telemetry에 영향을 받을 수 있습니다. 특히 LLM 기반 운영 에이전트가 로그를 읽고 대응을 제안하는 구조라면 데이터 경계와 승인 정책이 필수입니다.

장애 이후 학습하는 일. Postmortem, 재발 방지, 알림 기준 조정, 런북 개선은 여전히 사람과 팀의 책임입니다. AIOps가 타임라인 초안을 만들 수는 있어도, 조직의 운영 습관을 바꾸는 일까지 대신해 주지는 않습니다.

AWS와 Azure에서 어떻게 바라볼 수 있을까

AWS 환경에서는 CloudWatch를 중심으로 AIOps에 가까운 기능을 단계적으로 붙일 수 있습니다. 기본 메트릭과 로그 수집에서 시작해 CloudWatch Anomaly Detection으로 동적 기준을 적용하고, Application Signals와 SLO를 통해 서비스 단위 건강 상태를 보며, 필요하면 EventBridge, Systems Manager Automation, Lambda를 이용해 제한적인 자동 대응을 연결할 수 있습니다.

이때 핵심은 "AI 기능을 켜는 것"이 아니라 서비스 단위로 운영 기준을 정리하는 것입니다. 예를 들어 EKS에서 운영하는 결제 API라면 Pod CPU보다 p95 latency, 5xx error rate, availability, dependency failure가 더 중요할 수 있습니다. AIOps가 의미 있는 판단을 하려면 이런 지표가 서비스와 책임 팀 기준으로 정리되어 있어야 합니다.

Azure 환경에서는 Azure Monitor, Application Insights, Log Analytics, Dynamic Thresholds를 조합해 비슷한 접근을 할 수 있습니다. Application Insights는 OpenTelemetry 기반 애플리케이션 계측을 지원하고, AKS나 Azure Functions 같은 워크로드에서도 telemetry 흐름을 만들 수 있습니다. Dynamic Thresholds는 고정 임계값을 줄이고 패턴 기반 알림을 만드는 데 도움이 됩니다.

Azure 쪽에서 특히 볼 만한 점은 Application Insights가 애플리케이션 성능 모니터링뿐 아니라 AI Agent telemetry 시나리오까지 다루기 시작했다는 점입니다. 이는 앞으로 운영 대상이 VM, 컨테이너, API를 넘어 AI Agent와 LLM 호출 흐름까지 확장된다는 신호로 볼 수 있습니다.

실무 도입 순서

AIOps를 바로 전사 운영 자동화로 시작하면 실패하기 쉽습니다. 다음 순서가 더 현실적입니다.

1. 핵심 서비스 1~2개를 고릅니다.
2. 그 서비스의 SLI와 SLO를 먼저 정의합니다.
3. 지표, 로그, 트레이스에 서비스명, 환경, 버전, 팀, 리전 같은 공통 태그를 붙입니다.
4. 최근 3~6개월 incident를 보고 반복되는 알림과 원인 유형을 정리합니다.
5. 정적 임계값으로 시끄러운 알림부터 동적 임계값이나 이상 탐지로 바꿉니다.
6. 알림을 자동 해결하기 전에 관련 이벤트를 묶고 요약하는 것부터 적용합니다.
7. 자동 조치는 되돌릴 수 있고 영향 범위가 작은 작업부터 승인 기반으로 시작합니다.
8. AI가 제안한 원인과 실제 원인을 Postmortem에서 비교해 신뢰도를 계속 평가합니다.

흔한 실수

"AIOps를 도입하면 알림이 줄어들 것"이라고만 기대하는 것. 알림이 많은 이유가 서비스 경계 불명확, 중복 계측, 낮은 품질의 로그, 무분별한 임계값 때문이라면 AIOps는 그 혼란을 더 복잡하게 보여 줄 수 있습니다.

모니터링 데이터를 너무 빨리 버리는 것. AI 요약이 편하다는 이유로 원본 로그와 지표를 보지 않게 되면, 장애 분석의 근거가 약해집니다. 운영에서는 항상 "AI가 왜 그렇게 판단했는지" 추적할 수 있어야 합니다.

자동 복구를 너무 넓게 여는 것. 재시작, 스케일 아웃, 배치 중단처럼 단순해 보이는 작업도 타이밍이 잘못되면 장애를 키울 수 있습니다. 자동화에는 실행 조건, 승인 조건, 중단 조건, 감사 로그가 함께 있어야 합니다.

보안과 개인정보를 뒤늦게 보는 것. 로그에는 토큰, 이메일, 사용자 입력, 프롬프트, 검색 결과, 내부 URL이 섞일 수 있습니다. AIOps나 LLM 기반 운영 도구에 telemetry를 넘기기 전에 마스킹, 보존 기간, 접근 권한, 외부 전송 여부를 확인해야 합니다.

실무 체크리스트

• 핵심 서비스별 SLI, SLO, 소유 팀이 정의되어 있는가?
• 지표, 로그, 트레이스가 같은 서비스 이름과 태그 체계를 쓰는가?
• 배포 이력, 설정 변경, 장애 티켓, 온콜 기록이 telemetry와 연결되는가?
• 정적 임계값이 필요한 알림과 동적 임계값이 적합한 알림을 구분했는가?
• AI가 제안한 원인 후보를 사람이 검증할 수 있는 원본 데이터 링크가 있는가?
• 자동 조치는 되돌릴 수 있는 작업부터 제한적으로 시작했는가?
• 로그와 프롬프트에 민감 정보가 들어가지 않도록 필터링하고 있는가?
• AIOps 도입 후 알림 수, 조사 시간, 오탐률, 재발률을 실제로 측정하는가?

마무리

AIOps는 모니터링의 대체재가 아니라 모니터링 위에 올라가는 운영 판단 보조 계층입니다. 기본 지표와 로그가 부실한 상태에서는 AI가 해 줄 수 있는 일이 제한적입니다. 반대로 서비스 기준, telemetry 품질, SLO, 런북, 변경 이력이 잘 정리되어 있다면 AIOps는 장애 대응의 첫 10분을 줄이는 데 꽤 현실적인 도움을 줄 수 있습니다.

지금 운영팀이 해야 할 일은 "AI가 알아서 고쳐 주는 시스템"을 기대하는 것이 아닙니다. 먼저 사람이 신뢰할 수 있는 관측 기반을 만들고, 그 위에서 AI가 잘할 수 있는 분류, 요약, 상관 분석, 제한적 자동화부터 차근차근 맡기는 것입니다.

---

이 글이 유용했다면 다음 편도 확인해보세요.
다음 글: GitOps를 도입하기 전에 알아야 할 운영 리스크

참고자료

• AWS, What is AIOps?: https://aws.amazon.com/what-is/aiops/
• AWS, Amazon CloudWatch Anomaly Detection: https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Anomaly_Detection.html
• AWS, CloudWatch Application Signals SLO: https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-ServiceLevelObjectives.html
• Microsoft Learn, Azure Monitor Dynamic Thresholds: https://learn.microsoft.com/en-us/azure/azure-monitor/alerts/alerts-dynamic-thresholds
• Microsoft Learn, Application Insights OpenTelemetry observability: https://learn.microsoft.com/en-us/azure/azure-monitor/app/app-insights-overview
• OpenTelemetry, What is OpenTelemetry?: https://opentelemetry.io/docs/what-is-opentelemetry/
• Google SRE Book, Monitoring Distributed Systems: https://sre.google/sre-book/monitoring-distributed-systems/