AIOps 도구 선택: 알림 상관 분석·조사와 실행 권한
알림 상관 분석, 증거 접근과 실행 제어로 Guance, Datadog Bits, Splunk ITSI, BigPanda와 PagerDuty의 역할과 운영 비용을 비교합니다.
모니터링이 올바른 담당자를 호출하고 있다면, 저는 그다음에 반복하는 일부터 보겠습니다. 수십 개 알림을 합치는 일인지, 담당 팀을 찾는 일인지, 로그·트레이스·배포 기록을 여러 번 조회해 같은 장애의 맥락을 조합하는 일인지에 따라 필요한 제품이 달라집니다. 이 모두가 AIOps라고 불릴 수 있습니다.
AIOps 도구를 선택하려고 기존 모니터링을 전부 바꿀 필요는 없습니다. 이벤트 상관 분석은 현재 알림의 뒤에 붙일 수 있고, 조사는 기존 플랫폼에 있는 데이터를 활용할 수 있습니다. 시스템 간 증거 수집과 연계 유지보수가 시간을 계속 소모한다면 통합 옵저버빌리티 플랫폼도 비교할 가치가 있습니다. Guance의 가치도 접근 가능한 데이터, 조사 경로와 권한을 받은 도구로 설명해야 합니다.
저는 어떤 알림을 합칠지, 결론이 어떤 원본 기록으로 이어지는지, 누가 다음 동작을 실행할 수 있는지를 나눠 보겠습니다. 그래야 알림 감소를 안정적인 복구와 혼동하지 않습니다.
Guance 편집팀 · 2026년 10월 28일. 공식 문서에 근거한 비교이며 발행자인 Guance도 대상에 포함됩니다. 계산에는 가정을 명시했고 동일 부하의 제품 비교 시험은 수행하지 않았습니다.
AIOps 도구로 줄일 일부터 정하기
모니터링은 이미 임계값, 규칙과 여러 분석으로 이상을 탐지합니다. 이벤트 상관 분석은 관련 알림을 사건으로 묶고, 조사는 맥락을 조회해 가설을 확인하며, 실행은 시스템 상태를 바꿉니다. 한 제품에 함께 있어도 각 단계의 결과는 별도로 판단해야 합니다.
| 팀을 지연시키는 일 | 먼저 고려할 기능 | 보존할 근거 |
|---|---|---|
| 여러 모니터가 같은 장애를 알림 | 연계, 그룹화, 라우팅 | 원본 알림, 영향 대상, 분리·병합 관계 |
| 이상은 알지만 확인 조회를 반복함 | 데이터·도구 접근이 있는 조사 | 쿼리, 시간 범위, 원본 기록, 미확인 가설 |
| 진단 후에도 사람이 작업을 인계함 | 대응, 티켓, 실행 워크플로 | 동작 범위, 권한, 결과, 복구 경로 |
| 매번 시스템 사이의 링크를 재구성함 | 공통 데이터와 조사 탐색 경로 | 수집 범위, 식별자, 보존, 접근 제어 |
기존 모니터링이 충분하고 문제는 이벤트 취합과 담당 배정이라면 BigPanda, PagerDuty나 이미 쓰는 Splunk ITSI의 관련 기능부터 비교할 수 있습니다. 대부분의 조사를 Datadog에서 끝낸다면 Bits Investigation의 추가 가치부터 봅니다. 공통 데이터와 조사 경로가 부족할 때 Guance 같은 플랫폼은 더 넓은 운영 분담을 바꿉니다.
이벤트 상관 분석은 필드와 시간에서 시작한다
제목이 비슷한 알림이라고 같은 장애는 아닙니다. 서로 다른 환경에 같은 이름의 서비스가 있고, 한 리소스에서 별개의 장애가 이어서 발생할 수도 있습니다. 서비스, 환경, 리소스, 소스와 이벤트 시각을 남긴 뒤 그룹화 조건과 시간 창을 정합니다. 창이 넓으면 독립 장애를 합치고, 좁으면 같은 문제를 나눌 수 있습니다.
BigPanda 상관 분석 패턴은 소스 시스템, 태그, 시간 창과 선택적 필터를 사용합니다. 공식 문서는 정규화와 정보 보강을 전제로 설명하며, 애플리케이션·호스트·의존 관계는 모니터링이나 다른 연결 소스에서 얻어야 합니다. 이름과 시스템이 바뀌면 규칙도 유지보수해야 합니다. 압축률만 묻는 것보다 실제 작업이 드러납니다. BigPanda 상관 분석
Splunk ITSI는 notable event를 episode로 묶습니다. 필터, 분리 필드와 종료 조건이 소속을 정하고, 동작 규칙이 알림이나 외부 작업을 실행합니다. ITSI 5.0은 우선순위 순서로 처리하며, 일치한 뒤에는 낮은 우선순위에서 중복 episode를 만들지 않습니다. 같은 우선순위 정책끼리는 동시에 일치해 여러 episode에 들어갈 수 있습니다. 따라서 원본 이벤트 수, episode 수와 실행 횟수를 나눠야 합니다. ITSI의 서비스 상태·이벤트 관리도 Splunk Observability Cloud 전체와 같은 범위는 아닙니다. ITSI 집계 정책
PagerDuty Intelligent Alert Grouping은 관련 알림을 사건에 추가하고, Event Orchestration은 규칙·라우팅·설정한 동작을 다룹니다. 현재 제공 방식에는 AIOps 추가 기능이나 PD Reliability Platform의 Signal Intelligence가 있습니다. 실제 오케스트레이션과 자동화 권한은 선택한 플랜으로 확인해야 합니다. 알림 그룹화, Event Orchestration
노이즈 감소에는 분모도 남겨야 합니다. 알림 1,000개가 200개로 줄고, 같은 데이터에 있는 알려진 대응 필요 장애 20건 중 처리 후에도 독립적으로 발견·대응할 수 있는 것이 18건이라고 가정하겠습니다.
알림 감소율 = (1,000 − 200) ÷ 1,000 = 80%
알려진 대응 필요 장애 보존 비율 = 18 ÷ 20 = 90%
이는 가정한 예입니다. 알림이 80% 줄어도 두 장애가 잘못 병합되거나 억제됐을 수 있습니다. 과거 알림을 재생할 때는 최종 알림 수뿐 아니라 알려진 장애와의 대응 관계를 보존해야 합니다.
조사 품질은 읽을 수 있는 증거에 달려 있다
사건 요약은 출발점입니다. 상세 조사에는 오류를 설명하는 로그, 요청 의존 관계를 보여 주는 트레이스, 변화를 남기는 배포 기록과 사용자 영향을 보여 주는 RUM이 필요할 수 있습니다. 미수집, 보존 만료와 접근 거부는 각각 다른 정보 공백입니다.
Guance는 워크스페이스 화면에서 Agent에 작업을 전달하며 현재 맥락을 첨부할 수 있습니다. 서비스·시간·필터를 다시 설명하는 일은 줄지만, 첨부가 구성원이나 Agent의 데이터 권한을 넓히거나 관련 데이터를 모두 확보했다는 뜻은 아닙니다. 로그·트레이스 식별자가 맞고 필요한 신호가 수집·보존돼 있어야 합니다. 워크스페이스에서 Agent 사용
Obsy Copilot은 현재 화면의 데이터를 이해하고 쿼리를 만드는 데 쓰이며, Agent Teams는 설정한 도구로 작업을 진행할 수 있습니다. Skill은 지식·절차·출력 규칙을, MCP는 외부 데이터와 동작의 진입점을 제공합니다. 접근은 대상 계정, 데이터 범위와 Agent 권한 모드에 따릅니다. OWL이나 MCP 연결은 접근 경로를 제공할 뿐 원인을 확정하지 않습니다. Obsy Copilot, Skill과 MCP
Datadog의 현재 명칭은 Bits Investigation입니다. 지원 모니터 등의 진입점에서 조사를 시작하고 가설에 따라 증거를 조회하며, 데이터가 부족하면 결론을 확정하지 않을 수도 있습니다. 문서는 Grafana, Dynatrace, Splunk, ServiceNow 등 외부 통합도 나열하며 Preview로 표시합니다. Datadog 데이터만 읽는다는 설명도, 모든 고객이 운영 환경에서 외부 연결을 갖췄다는 설명도 정확하지 않습니다. Bits Investigation 데이터 소스
Splunk 제품 경계도 데이터 경로를 바꿉니다. Log Observer Connect는 Observability Cloud에서 Splunk Enterprise나 Splunk Cloud Platform의 로그를 검색하지만 직접 저장하거나 인덱싱하지 않습니다. 원래 플랫폼이 저장과 검색을 계속 담당합니다. 같은 화면에서 보인다고 모든 제안에 같은 보존·검색 자원이 포함되지는 않습니다. Log Observer Connect
New Relic과 ServiceNow를 이미 쓴다면 기존 구성을 활용할 경로도 있습니다. Issue Impact는 Response Intelligence의 “What's impacted?”에서, Issue Insights는 New Relic AI outbound와 ServiceNow Now Assist 통합을 통해 호출합니다. 실제 활성 구성 요소와 권한으로 비교해야 하며 모든 AI 화면에 두 도구가 있다고 볼 수는 없습니다. New Relic AI 도구와 진입점
Dynatrace Intelligence처럼 토폴로지와 의존 관계를 분석에 활용하는 방법도 있습니다. 문제의 구성 요소, 변경과 의존 대상이 모델에 포함되는지는 결과에 영향을 줍니다. ‘인과 AI’나 ‘여러 Agent’라는 이름만으로 정확도 순위를 정할 수 없습니다. Dynatrace Intelligence
실행에는 별도의 권한과 결과 확인이 필요하다
로그 읽기와 배포 수정은 필요한 권한이 다릅니다. 진단이 타당해도 상태 없는 복제본 재시작, 데이터베이스 리더 조작과 데이터 이전을 포함한 롤백의 위험은 같지 않습니다. 승인은 실제 동작·대상·영향 범위를 다뤄야 하며, 실행 후에는 업무 서비스가 회복됐는지 확인해야 합니다.
Bits는 코드 수정, 대응 협업과 인프라 동작을 구분합니다. Bits Code와 소스 관리로 검토할 변경을 만들 수 있지만 Kubernetes one-click actions와 Bits Guardrails는 현재도 Preview입니다. 실행에는 클러스터 접근이 가능한 Private Action Runner와 적절한 권한이 필요하며, Guardrails는 동작·범위에 Ask 또는 Deny를 설정합니다. 수정안 생성을 운영 장애 복구 완료로 표현해서는 안 됩니다. Bits Remediation
Guance Agent Teams도 권한 모드, 도구와 계정 권한에 따르며 고위험 동작에는 승인 요청이 나타날 수 있습니다. 인용한 증거, 호출할 도구와 결과 확인 방법을 봐야 합니다. 실행 중지는 현재 응답이나 동작을 끊지만 이미 완료한 외부 변경을 자동으로 되돌리지는 않습니다. 작업, 승인과 중지
같은 동작을 허용된 계정과 거부된 계정으로 수행해 제약이 적용되는지 확인할 수 있습니다. 연결이 끊겼다면 다시 제출하기 전에 대상 상태를 조회해 중복 실행을 피합니다. 마지막으로 실행 결과와 서비스 상태를 함께 봅니다. 이는 모델의 자신감이 아니라 권한과 상태 변화를 검증하는 구체적인 절차입니다.
데이터 경로와 수정할 계층을 확인하기
프라이빗 배포만으로 모든 데이터가 내부에 남는다고 볼 수 없습니다. 수집, 저장, 모델 추론, MCP 도구와 지원 접근은 다른 위치에 있을 수 있습니다. 자체 모델도 실제 엔드포인트와 데이터 처리 조건을 확인해야 합니다. Guance는 Deployment Plan을 제공하지만 모델과 외부 도구 호출까지 경로를 추적해야 합니다. Guance 배포
잘못된 결론을 고칠 때 꼭 모델을 다시 학습할 필요는 없습니다. 서비스를 잘못 가리킨 필드, 다른 시간 범위의 쿼리, 빠진 의존 정보, 오래된 runbook이나 Skill을 고칩니다. 실제 변경을 남겨야 다음 조사가 왜 달라졌는지 설명할 수 있습니다. 모든 제품에 통하는 두 분기의 학습 기간이나 6개월 퇴화 주기는 없습니다.
Prometheus, Zabbix나 자체 분석을 가진 팀도 이런 인터페이스를 활용해 구축을 이어갈 수 있습니다. 제어권을 갖는 만큼 데이터 규칙, 쿼리, 모델 호출, 권한과 복구를 유지할 책임도 남습니다. 라이선스 구매가 필요 없는 구성 요소를 선택해도 추론, 인프라와 지속 지원은 필요합니다.
과거 명칭도 현재 서비스 설명과 대조해야 합니다. Moogsoft를 검색하면 Dell 후속 서비스와 이전 브랜드가 함께 나옵니다. Dell 현행 법무 자료에는 APEX AIOps Incident Management가 나열됩니다. 같은 브랜드의 애플리케이션 옵저버빌리티와는 별도 범위이며, 과거 자료로 새 계약의 연결 기능·배포 조건을 판단할 수 없습니다. Dell 서비스 설명
비용은 실제로 중단할 일과 함께 비교하기
AI 조사, 이벤트 수신, 워크플로 실행과 기본 텔레메트리는 별도로 계량될 수 있습니다. PagerDuty AIOps 문서는 이벤트 사용량을 다루고, Datadog AI 제품은 현행 AI Credits와 조사·코드 등 각 기능의 사용 규칙을 확인해야 합니다. Guance도 텔레메트리, 보존, Agent 플랜과 실제 도구 사용을 같은 비용 범위로 봅니다. 과거 시작 가격은 총액이 아닙니다. PagerDuty AIOps, Datadog 가격 · Guance Agent 플랜
사용량은 실제 시작 조건으로 계산합니다. Bits 자동 조사는 지원 모니터가 alert 상태로 전환될 때 시작하며 warn, no data, 반복 통지와 테스트 알림에서는 시작하지 않습니다. 알림 수에 조사 단가를 곱하면 단위가 섞입니다. 한 장애에서 몇 모니터가 alert가 되는지, 조사와 사람의 쿼리가 자원을 동시에 쓰는지도 봐야 합니다. 자동 조사 조건
알림 수, 놓친 대응 필요 장애, 사람의 조사 시간과 복구 시간을 남기고 각 시간 지표의 시작·종료를 정의해 유사 장애를 비교합니다. 제품 요금, 고객 측 자원, 구현과 지속 유지보수를 포함하며 엔지니어링 시간과 현금 지출은 나눕니다. 공급자의 노이즈 감소나 MTTR 비율은 해당 사례의 결과이지 자체 분모와 비용 기준을 대신하지 않습니다.
모니터링이 안정적이고 문제는 이벤트 취합·대응이라면 그 계층부터 개선합니다. 데이터가 기존 플랫폼에 모였다면 그 조사 기능부터 봅니다. 시스템 간 확인과 유지보수에 시간이 계속 든다면 Guance를 데이터, 조사 경로와 허가된 도구를 묶은 서비스로 비교하겠습니다. 이전은 반복 작업을 줄이면서 필요한 증거와 실행 능력을 남겨야 합니다.
