모든 AI SRE 도구를 평가하는 방법 — 15개의 운영 SLI 포스트를 기반으로 구축된 실무자 프레임워크

제목: 모든 AI SRE 도구를 평가하는 방법 — 15개의 운영 SLI 포스트를 기반으로 구축된 실무자 프레임워크

당신의 매니저가 방금 Gartner 보고서를 전달했습니다. AI SRE 카테고리에 대한 분석가의 인정, 지속적인 온콜 (on-call) 압박, 미성숙한 신뢰 및 거버넌스 프레임워크, 그리고 단절된 에이전트 (agent) 실험보다는 오케스트레이션 (orchestration)의 필요성이 2026년에 한꺼번에 몰려왔습니다. 현재 모든 SRE 팀의 백로그 (backlog)에 놓인 질문은 이것입니다: 무언가를 구매해야 할까, 직접 만들어야 할까, 아니면 기다려야 할까? Sherlocks

나는 AI 에이전트 (agent)를 위한 측정 레이어 (measurement layer)를 처음부터 구축하는 데 4개월을 보냈습니다 — DQR, TIE, HER, AQDD, RTD, CUR, Pre-Action Gate, Semantic Gap detection. 15개의 포스트, 오픈 소스 (open-source) 라이브러리, 그리고 계속해서 늘어나고 있는 arXiv 논문이 그 결과물입니다. 이 포스트는 그 작업물이 벤더 (vendor) 평가 프레임워크가 되는 지점입니다.

이 프레임워크의 모든 주장은 내가 이미 정의한 지표 (metric)와 매핑됩니다. 여러분은 상용이든 오픈 소스든 어떤 도구에 대해서도 이를 검증할 수 있습니다.

벤더 벤치마크 (Vendor Benchmarks)의 문제점

Datadog의 Bits AI SRE는 해결 시간 (time to resolution)을 최대 95%까지 단축합니다. New Relic의 사용자들은 AI 기능이 없는 사용자들보다 인시던트 (incident)를 25% 더 빠르게 해결했습니다. 두 수치 모두 발표되었습니다. 두 수치 모두 실제적입니다 — 그들이 측정한 환경 내에서는 말이죠. Nova AI OpsInfoQ

문제는 그 환경이 여러분의 환경과 일치하는지 여부입니다. 깨끗한 텔레메트리 (telemetry), 잘 구조화된 런북 (runbooks), 그리고 좁은 인시던트 카테고리를 가진 시스템에서 측정된 95%의 MTTR 개선은, 파편화된 관측성 (observability), 복잡한 의존성 그래프 (dependency graphs), 그리고 새로운 장애 모드 (failure modes)를 가진 시스템에서 보게 될 수치와는 다릅니다.

벤더 벤치마크는 최적의 조건에서 도구를 측정합니다. 여러분의 평가는 여러분의 조건에서 도구를 측정해야 합니다. 다음 다섯 가지 질문이 여러분에게 프레임워크를 제공할 것입니다.

질문 1: 추론 레이어 (reasoning layer)를 계측(instrument)하는가?

시맨틱 갭 (semantic gap) — 에이전트가 의도한 것과 실제로 실행한 것 사이의 간극 — 은 인프라 APM (infrastructure APM)에서는 보이지 않습니다.

저는 지난주 Sherlocks.ai의 연구를 인용하여 이 점에 대해 글을 썼습니다. 기존 도구들은 상위 수준의 의도(high-level intent)나 하위 수준의 동작(low-level actions)을 관찰할 뿐, 그 사이의 상관관계는 관찰하지 못합니다.

어떤 벤더에게든 물어보십시오. 작업당 재계획 주기(re-planning cycles)를 추적합니까? 에이전트가 작업을 완료하거나 에스컬레이션(escalation)하기 전에 접근 방식을 몇 번이나 변경했는지 볼 수 있습니까? 장애 발생 후 그 이력을 쿼리(query)할 수 있습니까?

만약 답변이 "프롬프트와 도구 호출(tool calls)을 기록합니다"라면, 그것은 레이어 1 관측성(Layer 1 observability)입니다. 유용하고 필요하지만, 불충분합니다. 여러분에게는 에이전트 작업당 하나의 구조화된 기록으로서 전체 결정 시퀀스(decision sequence)를 보여주는 레이어 3(Layer 3)이 필요합니다.

데모에서 확인해야 할 사항: 실패한 작업 트레이스(task trace)를 보여달라고 요청하십시오. 그것이 재계획 결정의 시퀀스를 보여줍니까, 아니면 단순히 최종 결과와 스팬(spans)만을 보여줍니까?

질문 2: 그들의 벤치마크에서 인간 에스컬레이션 비율(Human Escalation Rate, HER)은 얼마입니까?

HER — 인간의 판단으로 에스컬레이션된 에이전트 결정의 비율 — 는 도구가 실제로 얼마나 자율적인지를 보여주는 가장 정직한 단일 지표입니다. 낮은 MTTR(Mean Time To Resolution) 수치가 높은 HER과 결합되어 있다면, 이는 에이전트가 인간을 위해 컨텍스트(context)를 수집해 주었기 때문에 인간이 해결 작업의 대부분을 더 빠르게 수행했음을 의미합니다. 그것은 가치 있는 일이지만, 자율적 복구(autonomous remediation)와는 다릅니다.

질문하십시오: 귀사의 벤치마크 환경에서 에이전트가 인간의 개입 없이 해결한 장애의 비율은 얼마입니까? 실행 전 인간의 승인이 필요했던 비율은 얼마입니까? 무엇이 에스컬레이션을 가장 자주 유발했습니까?

이러한 질문들은 해당 도구가 자율적 복구 도구인지, 아니면 매우 뛰어난 어시스턴트(assistant)인지를 드러냅니다. 둘 다 정당한 도구이지만, 벤더의 헤드라인 주장과 일치하는 것은 오직 하나뿐입니다.

질문 3: 동작하기 전에 SLO 상태를 확인합니까?

현재의 에러 예산(error budget)을 확인하지 않고 복구하는 에이전트는 악화된 상황을 더욱 심화시킬 수 있습니다. 저는 이를 사전 동작 SRE 게이트(Pre-Action SRE Gate, 포스트 13)에서 공식화했습니다. 모든 자율 동작 전에는 세 가지 확인 사항이 필요합니다. 남은 에러 예산, AQDD 상태, 그리고 에이전트 자체의 HER 추세입니다.

어떤 벤더에게든 물어보십시오: 귀사의 에이전트는 복구를 실행하기 전에 SLO 에러 예산을 확인합니까?

에러 예산 (error budget)이 심각하게 낮은 경우 어떻게 됩니까? 에이전트가 그대로 실행합니까, 아니면 에스컬레이션 (escalation)을 수행합니까? 사전 조치 게이트 (pre-action gate) 임계값을 설정할 수 있습니까?

에러 예산이 이미 소진되고 있는 운영 시스템에서 이 질문에 답하지 못하는 도구는 안전하지 않습니다.

질문 4: 에이전트당 정의된 폭발 반경 (blast radius)은 무엇입니까?

Komodor의 Klaudia는 Kubernetes 환경에서의 Pod 충돌, 롤아웃 (rollout) 실패, 오토스케일러 (autoscaler) 마찰, 설정 오류 (misconfiguration), 그리고 연쇄 장애 (cascading failures)에 특화되어 학습되었습니다. 그 특수성이 바로 폭발 반경입니다. 해당 도메인에서의 95% 정확도가 그 외의 영역에서도 95%의 정확도를 의미하지는 않습니다. Yisusvii

모든 AI SRE 도구는 암묵적인 폭발 반경을 가지고 있습니다. 즉, 해당 도구가 학습되고 테스트된 시스템과 장애 모드 (failure modes)의 집합입니다. 좋은 도구는 이를 명시적으로 드러냅니다. 다음과 같이 질문하십시오: 이 에이전트가 자율적으로 수정할 수 있는 시스템은 무엇입니까? 쓰기 잠금 (write-locked)이 설정된 시스템은 무엇입니까? 정확도 주장은 어떤 장애 범주를 기반으로 합니까?

벤더가 구체적인 폭발 반경 정의를 제공하지 못한다면, 그 정확도 수치는 마케팅용 주장일 뿐입니다. 만약 제공할 수 있다면, 그 폭발 반경이 귀사의 실제 장애 분포 (failure distribution)를 커버하는지 평가할 수 있습니다.

질문 5: 잘못되었을 때의 책임 모델 (ownership model)은 무엇입니까?

이것은 벤더들이 가장 싫어하는 질문입니다. 에이전트가 잘못된 복구 결정 (remediation decision)을 내려 장애를 악화시켰을 때, 누가 책임을 집니까? 벤더의 SLA (Service Level Agreement)는 서비스 가용성을 보장할 뿐, 에이전트 조치로 인한 운영상의 결과까지 책임지지는 않습니다.

귀사의 환경에서 이 질문에 대한 답은 귀사의 ARO (Agent Reliability Ownership, 에이전트 신뢰성 소유권) 등록 사항과 일치해야 합니다. 즉, 지정된 인간 소유자, 정의된 에스컬레이션 경로, 그리고 에이전트가 조치를 취하기 전 수행한 모든 게이트 체크 (gate check)에 대한 감사 로그 (audit log)가 있어야 합니다.

어떤 벤더에게든 물어보십시오: 귀사의 도구는 각 조치 전에 에이전트의 의사결정 근거에 대한 감사 로그를 생성합니까? 그 로그는 장애 검토 (incident review) 중에 쿼리 (query)가 가능합니까? 내 환경에서 에이전트의 행동에 대한 책임은 누구에게 있습니까?

감사 로그가 존재하지 않는다면, 에이전트가 개입된 장애 발생 후 완전한 사후 분석 (postmortem)을 작성할 수 없습니다.

그것이 바로 규제가 엄격한 운영 환경(production environments)에서 자율 에이전트(autonomous agents)를 안전하지 않게 만드는 책임의 공백(accountability gap)입니다.

직접 구축할 것인가(Build) vs 구매할 것인가(Buy) 결정 매트릭스

이 다섯 가지 질문을 바탕으로, 제가 직접 구축할 것인지 구매할 것인지에 대한 의사결정을 구성하는 방법은 다음과 같습니다:

구매(Buy)해야 하는 경우: 귀하의 장애 분포(failure distribution)가 도구의 영향 범위(blast radius)와 밀접하게 일치하고, 벤더(vendor)가 제공하는 것 이상의 커스텀 SLI가 필요하지 않으며, 벤더가 다섯 가지 질문 모두에 대해 구체적으로 답변할 수 있는 경우.

직접 구축(Build)해야 하는 경우: 장애 분포가 광범위하거나 새로운 형태이며, 커스텀 SLI(현재 상용 도구에는 DQR, RTD, HER, AQDD가 모두 결여되어 있음)가 필요하거나, 벤더가 생성하지 않는 감사 추적(audit trails)을 의무화하는 규제 요구사항을 충족해야 하는 경우.

하이브리드(Hybrid, 가장 현실적인 방안): 조사 계층(investigation layer)은 구매하십시오. 벤더 도구들은 인간보다 사고 컨텍스트(incident context)를 더 빠르게 수집하는 데 진정으로 뛰어납니다. 거버넌스 계층(governance layer)은 직접 구축하십시오 — 사전 조치 게이트(Pre-Action Gates), ARO 등록, 의미론적 격차(Semantic Gap) 탐지, 확산 레지스트리(Sprawl Registry) 등이 이에 해당합니다. agentsre 라이브러리는 정확히 이러한 하이브리드 방식을 위해 설계되었습니다.

평가 스코어카드 (The Evaluation Scorecard)
python# agentsre/tool_evaluation.py

from dataclasses import dataclass, field
from typing import Dict, List, Optional
import json
from datetime import datetime, timezone

@dataclass
class ToolEvaluationScore:
"""
AI SRE 도구에 대한 다섯 가지 질문 기반 평가 스코어카드.

이 스코어카드를 사용하여 `agentsre` 시리즈의 SLI 프레임워크를 기준으로
상용 도구 또는 내부 구축 도구를 평가하십시오.

...

전체 흐름에서의 위치

포스트 1~14는 측정 프레임워크 (measurement framework)를 구축했습니다: 에이전트 출력 품질 (agent output quality), 제어 평면 신뢰성 (control plane reliability), 추론 관찰 가능성 (reasoning observability), 컨텍스트 관리 (context management), 소유권 거버넌스 (ownership governance), 의미론적 격차 탐지 (semantic gap detection)를 위한 SLI들입니다.

포스트 15는 실질적인 결실입니다. 이제 여러분은 관리자가 평가를 요청하는 그 어떤 AI SRE 도구라도 평가할 수 있도록, 운영 SLI에 기반한 5가지 질문 프레임워크를 갖게 되었습니다. 그 답이 구매 (buy), 자체 구축 (build), 또는 하이브리드 (hybrid) 중 무엇이든, 이 프레임워크는 여러분에게 방어 가능하고 기술적으로 근거 있는 권장 사항을 제공합니다.

ToolEvaluationScore 데이터 클래스 (dataclass)는 agentsre/tool_evaluation.py에 있습니다. 이를 사용하여 평가 내용을 문서화하고 팀과 공유할 수 있는 보고서를 생성하십시오.

Ajay Devineni | AWS Community Builder | Senior SRE/Platform Engineer
gitub.com/Ajay150313/agentsre | dev.to/ajaydevineni