AIOps는 AI와 머신러닝이 로그·메트릭·이벤트를 먼저 걸러 이상 감지, 장애 원인 분석, 자동 복구를 돕는 IT 운영 방식이다. 고정 임계값 대신 평소 패턴을 학습한 기준으로 경고하고 관련 알림을 하나로 묶어 주기 때문에, 서비스가 많아 사람이 알림을 다 볼 수 없을 때 쓴다.
| 항목 | 기존 모니터링 | AIOps |
|---|---|---|
| 경고 기준 | 사람이 정한 고정 임계값 | 평소 패턴을 학습한 기준 |
| 알림 | 증상마다 따로 울림 | 같은 장애끼리 묶음 |
| 원인 찾기 | 사람이 대시보드를 뒤짐 | 연관 데이터로 후보 제시 |
| 대응 | 수동 | 반복 장애는 자동 복구 |
하는 일은 크게 네 단계로 나뉜다. 앞 단계일수록 도입이 쉽고 위험이 적다.
| 단계 | 하는 일 |
|---|---|
| 이상 감지 | 시간대·요일 패턴을 배워 평소와 다른 값을 찾는다 |
| 알림 묶기 | 한 장애에서 터진 수십 개 알림을 한 건으로 합친다 |
| 원인 분석 | 배포·설정 변경·연관 로그를 엮어 원인 후보를 보여준다 |
| 자동 복구 | 재시작·확장처럼 정해진 절차를 실행한다 |
Datadog, Dynatrace, New Relic, Azure Monitor 같은 모니터링 플랫폼에는 AIOps 기능이 이미 들어 있다. 따로 모델을 만들 필요 없이, 고정 임계값 경고를 학습 기반 경고로 바꾸는 것부터 시작하면 된다.
순서는 이상 감지로 알림 피로를 줄이고, 알림 묶기로 장애 한 건을 한 번만 받게 한 뒤, 원인이 확실히 반복되는 장애에만 자동 복구를 붙이는 식이다. 디스크 정리나 파드 재시작처럼 되돌리기 쉬운 조치부터 자동화하는 게 안전하다.
최근에는 LLM을 붙여, 장애가 나면 관련 로그와 이슈를 모아 "지금 무슨 일이 일어나는지"를 자연어로 요약하고 복구 방법을 제안하는 방식이 늘었다. 당직자가 새벽에 처음 상황을 파악하는 시간을 줄이는 데 특히 쓸모 있다. 다만 제안은 참고용으로 보고, 실행은 사람이 확인한 뒤에 하는 게 좋다.
로그 형식이 제각각이거나 메트릭이 빠져 있으면 감지와 원인 분석이 엉뚱하게 나온다. 패턴을 배우려면 일정 기간의 데이터가 쌓여야 해서, 새 서비스나 트래픽이 크게 바뀐 직후에는 오탐이 늘 수 있다. 서버 몇 대 규모라면 고정 임계값 경고만으로 충분해 AIOps가 오히려 과할 수 있다.
가장 흔한 건 당직자가 받는 알림을 줄이고 장애 초기 파악을 빠르게 하는 용도다. 감지와 묶기로 시끄러운 알림을 정리하고, 원인 후보와 요약을 보고 첫 판단을 내린 뒤, 확실히 반복되는 장애만 자동 복구로 넘긴다.
| 어디서 | 어떻게 쓰나 |
|---|---|
| 클라우드 서비스 당직 | 학습 기반 경고로 오탐을 줄이고, 한 장애에서 터진 알림을 한 건으로 묶어 받는다 |
| 장애 대응 초기 | 배포·설정 변경과 로그를 엮은 원인 후보, LLM 상황 요약을 보고 어디부터 볼지 정한다 |
| 반복 장애 처리 | 디스크 정리·파드 재시작처럼 되돌리기 쉬운 조치를 정해진 조건에서 자동 실행한다 |
| 배포 직후 점검 | 새 버전을 내보낸 뒤 평소와 다른 지표 변화를 감지해 문제를 일찍 알아챈다 |