1. 장애 한 건에 알림이 수십 개씩 쌓이는 환경
운영팀이 매일 다루는 알림의 양은 시스템 규모와 함께 빠르게 늘어왔습니다. 마이크로서비스가 보편화되고 하이브리드 클라우드와 SaaS가 함께 쓰이면서, 외부 의존 서비스 한 곳이 느려졌을 뿐인데 APM·인프라·응답 시간·사용자 피드백 알림이 동시에 울리는 상황이 흔해졌습니다. 글로벌 SRE 산업 보고서인 Catchpoint 2025 SRE Report에 따르면 온콜 엔지니어의 62%가 알림이 너무 많아 정작 중요한 알림을 놓친 경험이 있다고 답했습니다. 상황이 이렇다 보니, Google SRE Workbook도 시프트당 감당 가능한 인시던트 수를 최대 2~3건으로 권고할 정도입니다.
이제는 알림 자체를 줄이는 것보단, 알림이 울리기 전 신호를 먼저 잡아내는 방식으로 운영 방향이 바뀌고 있습니다. 사전 신호를 잡는 기술 영역이 바로 예측 기반 AIOps입니다.
2. 사후 대응에서 사전 예방으로 바뀌는 운영 흐름
지난 몇 년간 AIOps는 장애가 난 뒤 얼마나 빨리 원인을 찾느냐에 초점이 맞춰져 있었습니다. 알림이 울리면 운영팀이 화면을 열고 RCA(Root Cause Analysis)를 거쳐 복구한 다음 사후 보고서를 작성하는 흐름이 표준이었습니다. 최근에는 사전 이상 감지가 운영 표준의 일부로 자리 잡는 흐름이 뚜렷해지고 있습니다. Google SRE Workbook의 알림 설계 가이드는 사용자가 인지하기 전에 잡아내는 신호를 알림 우선순위 가장 위에 두라고 권고합니다.
글로벌 트렌드만이 아닙니다. 한국에서는 이런 흐름이 정책 단계에서도 확인됩니다. 행정안전부가 2025년 7월 시행한 전자정부법 개정을 통해 1만 6,000여 개 행정정보시스템에 24시간 관제 체계와 장애 예방을 위한 구체적인 점검 기준을 법제화했습니다. 인시던트 대응이 사회재난 수준의 관리 영역으로 올라온 만큼, IT 운영팀의 역할도 장애 후 복구에서 장애 전 차단으로 옮겨가고 있습니다.
3. 30분 전 알림, 어디까지 가능한가
결론부터 말하면 가능한 영역도 있고, 그렇지 않은 영역도 있습니다. 정확한 답을 위해서는 두 가지 다른 기능을 먼저 구분해야 합니다.
미래 시점의 부하·이상을 예측해 그래프로 보여주는 부하 예측(Forecasting)과, 그 예측 결과가 임계치나 학습된 정상 범위를 벗어날 때 사전에 알림을 보내는 사전 알람(Predictive alerting)은 다른 기능입니다. 부하 예측만 있는 환경에서는 운영팀이 그래프를 직접 봐야 신호를 잡을 수 있습니다. 두 기능이 결합되어야 알림을 통해 행동할 시간을 확보할 수 있습니다.
다만 모든 장애가 예측 영역인 것은 아닙니다. 아래는 예측 가능한 장애 유형과 그렇지 않은 유형을 정리한 분류입니다.
예측 가능한 장애: 시계열 데이터에 누적되는 사전 신호를 이상 감지(Anomaly Detection)로 포착해, 30분 안팎의 사전 대응 시간이 확보됩니다.
- 메모리 누수, 디스크 사용량처럼 자원이 점진적으로 차오르는 장애 • DB 락 대기·WAS 응답 시간이 조금씩 길어지는 장애 • 시간대별 트래픽 패턴이 반복되는 장애
예측 불가 장애: 즉발적으로 일어나는 장애는 예측 영역 밖입니다.
- 외부 API 다운, 네트워크 단절 • 코드 배포 직후 발생하는 회귀 버그 • DDoS·보안 사고
도입을 검토할 때 우리 환경에서 자주 발생하는 장애 유형을 이 두 그룹으로 나눠 보면, 예측 기능이 어떤 영역에서 가장 큰 효과를 낼지 미리 가늠할 수 있습니다.
4. 예측을 가능하게 하는 운영 환경
예측 기반 AIOps가 운영 환경에서 실제 효과를 내려면 몇 가지 조건이 함께 갖춰져야 합니다. 도구를 도입한다고 장애 발생 30분 전 신호가 자동으로 잡히는 것은 아닙니다. 학습 데이터·통합 수집·상관 분석·표준 대응 네 영역에서 운영 환경 자체가 함께 준비되어 있어야 합니다.
4-1. 평소 패턴을 학습할 정상 운영 데이터
예측의 출발점은 지금이 평소와 다른가를 판단할 기준선입니다. 학습 기반 모델은 일정 기간의 운영 데이터를 학습해 시스템마다, 시간대마다 다른 정상 범위를 자동으로 잡습니다. 데이터가 충분히 쌓이지 않은 시점에 예측 결과를 신뢰하면 위험하기 때문에, 도입 직후에는 학습 기간을 명시적으로 잡아두는 것이 안전합니다. 일반적으로 4~12주 범위에서 잡고, 정확한 기간은 서비스 특성과 데이터 주기성에 따라 솔루션 제공사와 협의해 정합니다.
데이터 양뿐 아니라 다양성도 중요합니다. 평소 트래픽만 학습한 모델은 분기 마감, 프로모션, 점검 후 재기동 같은 비정상 상황에서 오탐을 내기 쉽습니다. 운영 이벤트 캘린더와 학습 데이터 기간을 매칭해, 가능하면 한 분기 이상의 다양한 운영 상황이 포함되도록 하는 것이 좋습니다.
임계치 기반 알림과 학습 기반 알림은 모두 운영팀에 알림을 보내지만, 기준선을 잡는 방식이 전혀 다릅니다.
구분 | 임계치 기반 알림 | 학습 기반 알림 |
기준선 | 운영자가 고정값으로 직접 설정 | 시간대·요일·시즌별 정상 범위를 자동 학습 |
오탐 | 정상 변동까지 알림으로 분류되는 경우 많음 | 학습된 정상 범위를 벗어날 때만 알림 |
정확도 변화 | 고정 (운영자가 수동 조정) | 데이터가 쌓일수록 점진적으로 개선 |
운영 부담 | 임계치 재설정·알림 정리에 인력 소모 | 의미 있는 신호만 남아 운영팀 부담 감소 |
학습 기반 모델의 정확도는 데이터 양보다 라벨 정확도에 더 민감합니다. 과거에 발생한 이상 시점을 운영팀이 명확히 표시해 두면, 같은 학습 데이터로도 모델 정확도가 눈에 띄게 올라갑니다. 알림 이력을 단순 로그가 아니라 정상·오탐·진짜 이상 라벨로 관리하는 운영 습관이 예측 기반 AIOps의 핵심 자산이 됩니다.
4-2. 정형 지표와 비정형 로그를 함께 보는 통합 수집
CPU·메모리·응답 시간 같은 정형 지표만 학습한 모델은 한계가 명확합니다. 같은 응답 시간 1초라도 어느 API에서, 어떤 호출 흐름에서 발생했는지에 따라 의미가 다른데, 정형 지표만으로는 이 맥락이 빠져버립니다. 예측 정확도를 끌어올리는 건 정형과 비정형 데이터를 함께 보는 통합 수집 구조입니다. 실시간 지표 수집기와 Kafka·Fluentd 같은 스트리밍 파이프라인이 함께 동작하는 구성이 일반적입니다.
통합 수집을 처음부터 한 번에 구축하기는 어렵습니다. 부서별로 흩어진 모니터링 도구가 있고, 데이터 형식과 보관 정책도 제각각인 경우가 많습니다. 단계적으로 가장 자주 장애가 나는 서비스 한두 개를 먼저 통합 수집 대상으로 잡고, 예측 정확도 개선이 확인되면 범위를 넓히는 방식이 안전합니다.
이때 함께 살펴야 할 것이 데이터 보관 기간입니다. 학습 기반 모델은 일정 기간 이상의 데이터가 쌓여야 안정적으로 동작하기 때문에, 비용 절감을 이유로 지표 보관 기간이 짧게 설정된 환경에서는 통합 수집을 해도 학습할 데이터가 부족할 수 있습니다. 보관 정책을 먼저 정리하지 않으면 통합 수집의 효과가 줄어듭니다.
4-3. 영역 간 상관 관계를 잡아내는 멀티 도메인 분석
장애가 발생하기 30분 전 신호는 한 영역에서만 나타나지 않습니다. DB 쪽 락 대기가 늘어나면서 WAS 응답 시간이 조금씩 길어지고, 네트워크 지연이 함께 변동하기 시작하는 식으로 여러 영역에서 미세한 변화가 동시에 일어납니다. 한 영역의 모니터링만 보면 정상 변동 범위 안이라 신호로 잡히지 않지만, 영역 간 상관을 보면 분명한 이상 패턴이 됩니다.
멀티 도메인 상관 분석은 최근 AIOps 도구들이 가장 주목하는 기능 중 하나입니다. 영역별 모니터링 도구를 따로 쓰는 환경에서는 이 상관 분석 자체가 기술적으로 불가능하기 때문에, 데이터를 한 분석 엔진으로 모으는 통합이 전제 조건입니다.
기술 통합 못지않게 중요한 것이 부서 간 협업 구조입니다. WAS·DB·네트워크 운영 부서가 따로 있는 환경에서는 데이터를 한 플랫폼으로 모으는 것보다, 부서 간에 어느 영역의 누구 책임인가를 따지는 데 시간이 더 걸리는 경우가 많습니다. 통합 RCA가 가능한 환경을 만들려면 도구 통합과 함께, 부서 간 분석 권한과 책임을 사전에 합의해 두는 것이 필요합니다.
4-4. 예측 신호 다음에 정해진 표준 대응
마지막 조건은 예측이 실제 대응으로 연결되어야 한다는 것입니다. 30분 전에 신호를 받아도 그 신호로 무엇을 해야 하는지가 정해져 있지 않으면 의미가 없습니다. 표준 대응 절차(런북·플레이북 - 장애 유형별로 취해야 할 행동을 미리 정리한 문서)와 예측 신호를 사전에 연결해 두면, 운영팀이 추가 의사 결정 없이 다음 행동으로 옮길 수 있습니다.
다만 표준 대응을 자동화로 연결할 때는 범위를 신중하게 설정해야 합니다. 도입 초기에는 자동 조치 범위를 좁게 두고 사람이 검증하는 단계를 유지하다가, 예측 정확도가 안정되면 점진적으로 자동화 범위를 넓히는 방식이 일반적입니다. 런북·플레이북을 새로 작성할 때는 최근 1년간 발생한 장애의 사후 보고서를 모아 공통 대응 패턴을 추출하는 작업이 효과적입니다. 운영팀이 실제로 거쳐 온 절차를 정리하면 검증된 대응 시나리오가 자연스럽게 나오고, 처음부터 이상적인 절차를 설계하려고 하면 현장과 동떨어진 문서가 되기 쉽습니다.
5. 한 플랫폼에서 다루는 XAIOps의 접근
이 4가지 영역을 각각 다른 도구로 운영하기 시작하면, 도구마다 수집 주기와 데이터 형식이 달라 정합성을 맞추는 작업에 시간이 더 들어갑니다. 한 플랫폼에서 함께 다룰 때 운영 효율이 좋아지는 이유입니다. 엑셈의 XAIOps는 학습 데이터·통합 수집·멀티 도메인 분석·표준 대응까지 앞서 살펴본 4가지 운영 조건을 한 환경에서 다루는 AIOps 솔루션으로, 제1금융권을 포함한 국내 대규모 환경에 적용된 사례를 보유하고 있습니다.
구분 | 전통 모니터링 | 예측 기반 AIOps |
기준선 설정 | 운영자가 시스템마다 직접 설정 | 딥/머신러닝 기반 신뢰 구간 자동 생성 |
알림 시점 | 임계치 초과 시점 (사후) | 30분~1시간 후 부하 예측 + Smart Alert 결합으로 사전 신호 |
데이터 범위 | 영역별 단일 지표 중심 | WAS·DB·네트워크·로그 통합 분석 |
RCA 흐름 | 여러 도구를 전환하며 수동 분석 | 한 화면 상관 분석 + 토폴로지 자동 추출 |
대응 연결 | 알림 → 사람 판단 → 도구 실행 | 이벤트 상관분석 + 런북·플레이북 기반 표준 대응 절차 |
각 조건이 XAIOps에서 어떻게 구현되는지 살펴봅니다.
- 학습 데이터 → 학습 기반 베이스라인 + Smart Alert 시스템마다 정상 운영 데이터를 학습해 신뢰 구간을 자동으로 설정합니다. 학습된 정상 범위를 기준으로 이상 징후를 자동 감지해 알림을 보내는 Smart Alert와 결합되어, 운영팀이 그래프를 직접 확인하지 않아도 사전 신호를 받을 수 있습니다.
- 통합 수집 → 단일 분석 엔진 WAS·DB·네트워크 같은 정형 지표와 비정형 로그가 같은 분석 엔진으로 흘러가는 통합 수집 구조입니다. 30분~1시간 후 부하 상황을 사전 예측하는 부하 예측 기능도 이 데이터를 기반으로 동작합니다.
- 멀티 도메인 분석 → 3D 노드 맵 토폴로지 호출 경로와 이상 시점을 한 화면에서 파악할 수 있습니다. 영역 간 상관 패턴을 수동으로 조합하지 않아도, 이상 징후가 어느 경로에서 시작됐는지 한눈에 확인됩니다.
- 표준 대응 → 런북·플레이북 연동 이벤트 상관분석 결과와 표준 대응 절차(런북·플레이북)가 한 플랫폼 안에서 함께 다뤄집니다. 운영팀이 매번 처음부터 분석하지 않고, 검증된 절차로 빠르게 다음 행동으로 옮길 수 있습니다.
6. 30분의 의미와 도입 검토 시 점검할 것
앞에서 30분이라는 숫자를 자주 언급했지만, 정확한 사전 대응 시간은 시스템 환경마다 다릅니다. 어떤 시스템에서는 5분 앞까지, 어떤 시스템에서는 한 시간 앞까지 신호가 잡힙니다. 중요한 것은 정확한 분 단위가 아니라 운영팀이 알림을 받은 다음 대응할 여유 시간이 확보된다는 점입니다. 5분이라도 미리 받으면 담당자가 화면을 열어두고 대기할 수 있고, 30분이 확보되면 부하를 점진적으로 분산하는 것까지 가능합니다.
예측 기반 AIOps의 가치는 운영 효율 개선을 넘어 비즈니스 리스크를 줄이는 데 있습니다. 장애로 인한 서비스 중단을 사전에 방지하면 매출 손실과 고객 신뢰 저하, 컴플라이언스 이슈도 함께 막아냅니다. 특히 금융·공공처럼 장애 한 건이 사회재난 수준으로 다뤄지는 영역에서는 사전 예방의 가치가 매년 커지는 추세입니다.
도입을 검토 중이라면, 우리 운영 환경이 아래 상황에 해당하는지 먼저 살펴보는 것이 좋습니다.
- 임계치 알림이 너무 많아 정상 변동까지 알림으로 분류되는 환경
- WAS·DB·네트워크 모니터링이 부서별로 흩어져 RCA에 시간이 걸리는 환경
- 한 장애가 여러 시스템으로 번지면서 같은 사건이 수십 건의 알림으로 발생하는 환경
- 예측 결과를 받아도 운영팀이 다음 행동으로 옮길 표준 절차가 없는 환경
이와 같은 고민이 있다면 엑셈의 XAIOps에서 운영 환경 개선에 대한 방법을 확인해 볼 수 있습니다.
출처
Alerting on SLOs - Google SRE Workbook - Google SRE The SRE Report 2025 - Catchpoint (2025) 디지털 서비스 신뢰도 높인다…행안부, 정보시스템 장애 대응 전면 개편 - ZDNet Korea (2025.03.20) 7월 전자정부법 시행…공공 IT 자동화 시장 열린다 - 뉴시스 (2025.05.28)
함께 보면 좋은 아티클
