알람을 확인하는 운영에서, 판단하는 운영으로
IT 시스템을 운영하면서 알람이 부족해서 문제인 경우는 많지 않습니다. CPU 사용률부터 메모리, 응답시간, 네트워크, 데이터베이스, 애플리케이션 상태까지 수많은 지표를 모니터링하고 설정된 기준을 벗어나면 실시간으로 알람을 받을 수 있기 때문입니다.
그러나 하루에도 수많은 알람이 발생하다 보면 어떤 알람이 실제 장애로 이어질 수 있는지 판단하는 것이 오히려 더 큰 고민으로 다가옵니다. 정상적인 변동에도 알람이 발생하는 오탐이 반복되면 운영팀은 알람 하나하나를 확인하는 데 많은 시간을 쓰게 됩니다. 반대로 실제 이상 징후가 발생했는데도 설정된 기준을 넘지 않아 알람이 발생하지 않는 미탐도 존재합니다. 결국 중요한 것은 알람의 개수가 아니라 수많은 데이터 속에서 평소와 다른 패턴을 얼마나 정확하게 찾아내고, 그 이상이 어디에서 시작되었는지 빠르게 파악하는 것입니다.
AIOps의 이상탐지도 이런 운영 부담을 줄이는 방향으로 발전하고 있습니다. 정해진 기준을 넘었는지만 확인하는 방식에서 벗어나, 변화하는 데이터를 반영해 이상을 탐지하고 여러 지표 사이의 관계를 분석해 문제의 시작점을 좁히는 방식입니다.
XAIOps(싸이옵스) 역시 이상을 더 많이 탐지하는 것보다 실제로 확인해야 할 이상을 선별하고, 운영팀이 더 빠르게 판단할 수 있도록 지원하는 방향으로 분석 체계를 고도화하고 있습니다.
1. 알림은 많은데 왜 진짜 이상은 놓칠까
전통적인 모니터링에서는 특정 지표에 임계치를 설정하고 이를 초과하면 알람을 발생시키는 방식을 많이 사용했습니다. 예를 들어 CPU 사용률이 80%를 넘으면 Warning, 90%를 넘으면 Critical 알람을 발생시키는 식입니다.
하지만 실제 IT 환경의 상태는 하나의 숫자로 정의하기 어렵습니다.
평소 CPU 사용률이 20% 수준인 서버가 갑자기 70%까지 상승했다면 어떨까요?
- 80%라는 임계치를 넘지는 않았지만 평소 패턴과 비교한다면 충분히 확인해볼 만한 변화입니다.
- 반대로 특정 시간마다 배치 작업이 수행되어 CPU 사용률이 90%까지 상승하는 서버라면 해당 수치가 반드시 장애를 의미하지는 않습니다.
이처럼 같은 90%라도 어떤 시스템에서는 이상치지만 다른 시스템에서는 정상일 수 있습니다.
기존 XAIOps의 이상탐지는 약 3개월간 축적된 데이터를 바탕으로 요일·분 단위 평균과 표준편차를 계산하고, 해당 범위를 벗어나는 값을 이상으로 탐지하는 방식이었습니다. 과거 데이터를 기준으로 정상 범위를 정의할 수 있다는 장점이 있지만, 실제 시스템의 움직임은 과거의 패턴과 항상 같지는 않습니다.
특히, 실제 운영 환경은 트래픽이 점차 늘어나거나 새로운 서비스가 추가될 수 있고, 업무 패턴 자체가 달라질 수도 있습니다. 이런 변화가 누적되면 과거 데이터를 기준으로 설정한 정상 범위와 현재 시스템의 상태 사이에 차이가 생길 수 있습니다. 기준을 민감하게 잡으면 정상적인 변화까지 이상으로 판단하는 오탐이 늘어날 수 있고, 반대로 알람을 줄이기 위해 기준을 완화하면 중요한 이상 징후를 놓칠 가능성이 커집니다. 이처럼 관리 대상과 지표가 많아질수록 운영팀이 각 지표의 정상 범위를 확인하고 기준을 반복적으로 조정하는 방식에도 한계가 생깁니다.
💡 결국 필요한 것은 고정된 기준을 계속 튜닝하는 것이 아니라, 변화하는 데이터에 맞춰 이상을 판단하는 기준도 함께 움직이는 것입니다.
2. 스스로 기준을 조정하는 실시간 이상탐지
XAIOps는 이러한 한계를 보완하기 위해 이상탐지 체계를 dSPOT(Streaming Peak Over Threshold with Drift) 알고리즘 기반으로 고도화하고 있습니다. 핵심은 스트리밍 데이터에서 발생하는 추세 변화, 즉 Drift를 탐지 과정에 지속적으로 반영한다는 점입니다.
기존처럼 일정 기간의 데이터를 기준으로 정상 범위를 미리 계산하여 적용하는 것이 아니라, 새롭게 유입되는 데이터의 변화에 따라 탐지 기준을 갱신하고 현재 시점에서 이례적인 값인지 판단하는 것입니다. 예를 들어 특정 지표가 장기간에 걸쳐 완만하게 상승하고 있다고 가정해보겠습니다. 과거 데이터를 기준으로 고정된 정상 범위를 사용한다면 이전 기준으로 이상 여부를 판단하게 됩니다. 반면 실시간 데이터 추세를 반영하면 변화한 환경을 고려하면서도, 현재 시스템의 상태를 기준으로 예상 범위를 벗어난 움직임을 구분할 수 있습니다.
XAIOps의 목표 또한 정상적인 변화에 반복적으로 반응하는 불필요한 오탐을 줄이고, 기존 기준에서는 구분하기 어려웠던 이상 징후를 보다 정교하게 선별하는 탐지 체계를 만드는 것입니다.
3. 상관관계를 넘어, 이상이 시작된 지점까지
이상을 정확하게 발견했다고 해서 장애 분석이 끝나는 것은 아닙니다. 실제 장애가 발생하면 하나의 지표로만 움직이는 경우는 드뭅니다. 특정 영역에서 시작된 문제가 다른 시스템으로 영향을 미치며 여러 지표에서 연쇄적으로 이상이 나타날 수 있기 때문입니다.
기존 XAIOps의 RCA(Root Cause Analysis)는 이상이 탐지된 지표와 상관관계가 높은 지표를 함께 보여주는 방식이었습니다. 어떤 지표들이 함께 움직였는지 파악하는 데에는 도움이 되지만, 이것만으로는 어느 지표의 변화가 먼저 시작되었고 어떻게 다른 지표로 이어졌는지는 판단하기 어렵습니다.
XAIOps의 고도화된 RCA는 Granger 인과관계(Granger Causality)를 활용하여 단순히 A와 B가 함께 변했다는 관계를 보여주는 것에 그치지 않고 시간에 따른 지표의 변화를 분석하여 어떤 지표의 변화가 다른 지표의 변화에 선행했는지 파악합니다. 이를 통해 장애가 발생할 때마다 수많은 지표를 하나씩 대조하기보다 시작점과 확산 경로를 중심으로 분석할 수 있기 때문에 원인 후보를 좁히는 과정도 단축할 수 있습니다.
원인의 시작점을 파악하는 것과 함께 중요한 것은 분석 대상의 관계를 한눈에 확인하는 것입니다. XAIOps는 토폴로지 뷰에도 Auto-Layout을 적용해 전체 노드를 자동으로 배치하고, 추가되거나 제거된 노드가 화면에 자동 반영되도록 개선합니다. 그룹과 노드 단위 필터를 활용하면 장애 분석 과정에서 필요한 영역에 집중할 수 있습니다.
인과관계 분석이 ‘어디에서 이상이 시작됐는가’를 좁혀준다면, 토폴로지는 운영자가 시스템의 연결 관계와 분석 대상을 보다 직관적으로 확인할 수 있도록 돕는 역할을 합니다.
4. 오탐과 미탐을 줄이는 것이 MTTR과 연결되는 이유
오탐과 미탐은 서로 반대되는 문제처럼 보이지만 운영 과정에서는 결국 같은 비용을 만듭니다. 오탐이 많으면 운영팀은 실제 문제가 아닌 알람을 확인하는 데 시간을 사용하며, 반대로 미탐이 발생하면 문제를 인지하는 시점 자체가 늦어집니다.
장애를 인지한 이후에도 시간이 필요합니다. 어떤 지표에서 문제가 시작됐는지 확인하고, 같은 시간대에 발생한 다른 이상을 비교하고, 시스템 사이의 관계를 따라가며 원인 후보를 좁혀야 하기 때문입니다. 실제 장애 대응에서는 복구 작업 자체뿐 아니라 어떤 알람을 먼저 봐야 하는지 판단하고, 어디에서 문제가 시작됐는지 찾는 과정에도 적지 않은 시간이 소요됩니다.
그래서 평균 복구 시간인 MTTR을 줄이려면 조치 속도뿐 아니라 탐지와 분석에 걸리는 시간도 함께 줄여야 합니다. XAIOps의 고도화 방향도 이 과정과 연결됩니다.
- 실시간 추세를 반영한 이상탐지로 확인해야 할 이상을 선별합니다.
- 인과관계 기반 RCA로 이상이 시작된 지점과 확산 방향을 좁힙니다.
- 토폴로지에서 관련 시스템과 분석 범위를 직관적으로 확인합니다.
이를 통해 운영팀은 알람을 일일이 선별하고 여러 지표를 직접 대조하는 데 쓰던 시간을 줄이고, 실제 원인을 판단하고 조치하는 단계로 더 빠르게 넘어갈 수 있습니다.
결국 AIOps의 가치는 AI가 장애를 찾아주는데서 나아가, 탐지 → 분석 → 판단으로 이어지는 전체 운영 과정에서 사람이 소비하는 시간을 얼마나 줄일 수 있는지에 달려있습니다.
5. LLM, 데이터와 대화하며 문제를 푸는 운영
여기에 LLM이 더해지면서 운영팀이 데이터에 접근하는 방식도 달라지고 있습니다. XAIOps는 향후 LLM과 RAG를 활용해 질의응답, 요약, 보고서 작성, 조치 가이드 등을 제공하는 운영 어시스턴트로 확장할 예정입니다.
예를 들어 “어제 알람 요약해서 알려줘.”, “A 타겟의 이상은 어디에서 시작됐어?” 등의 질문을 통해 문제를 해결할 수 있게 됩니다. 여기서 LLM의 역할은 단순히 모니터링 솔루션에 챗봇을 추가하는 것이 아닙니다.
이상탐지가 무엇이 평소와 다른지를 찾고, RCA가 어디에서 문제가 시작됐는지를 좁힌다면, LLM은 이렇게 분석된 정보를 운영팀이 자연어로 조회하고 이해할 수 있도록 연결하는 인터페이스에 가깝습니다.
운영팀은 여러 화면을 이동하며 필요한 데이터를 직접 찾는 대신 질문을 통해 관련 정보를 조회하고, 분석 결과를 요약하거나 보고서 형태로 정리할 수 있습니다. 향후에는 분석된 상황을 바탕으로 필요한 조치 가이드를 확인하는 방식으로도 확장될 수 있습니다.
더 많은 알람보다, 더 빠른 판단이 필요한 시점
이상탐지 기술의 목적은 모든 변화를 찾아내는 것이 아니라, 운영팀이 실제로 확인해야 할 변화를 구분하고 장애 발생 시 원인을 빠르게 좁힐 수 있도록 만드는 데 있습니다.
이를 위해 XAIOps는 실시간 데이터의 추세를 반영하는 dSPOT 기반 이상탐지와 Granger 인과관계를 활용한 RCA로 분석 체계를 고도화하고 있습니다. 여기에 토폴로지 개선을 더해 분석 대상과 시스템 관계를 보다 직관적으로 확인할 수 있도록 하고, 향후에는 LLM 기반 운영 어시스턴트를 통해 질의, 요약, 보고서 작성, 조치 가이드까지 운영 과정의 연결 범위를 넓힐 계획입니다.
하지만 XAIOps의 변화는 AI 모델의 정확도를 높이는 데만 머물지 않습니다.
제품 운영 기반에서도 Config 표준화, 백엔드 성능 개선, 전체 서비스 Docker화, 핵심 모듈 이중화 등 안정성과 관리 효율을 높이기 위한 개선이 함께 진행되고 있습니다. 구축 과정에서는 ETL 연동 작업의 반자동화를 통해 제품 도입과 연동에 필요한 작업 부담을 줄이는 방향도 추진하고 있습니다.
결국 XAIOps의 고도화 방향은 ‘이상을 더 잘 찾는 AI’ 하나로 설명하기 어렵습니다.
탐지 기준을 일일이 조정하고, 쏟아지는 알람을 선별하고, 여러 지표를 대조하며 원인을 찾는 데 쓰였던 시간을 줄이는 것. 그리고 탐지부터 원인 분석, 운영자의 판단과 조치, 이를 뒷받침하는 운영 기반까지 하나의 흐름으로 연결하는 것에 가깝습니다.
이상탐지부터 원인 분석까지, 운영 판단의 시간을 줄이는 AIOps
함께 보면 좋은 아티클
