당신의 AI 에이전트 모니터링이 잘못된 이유 (그리고 해결 방법)

제가 SLO 설계(SLO Design) 기사에서 논의했듯이, 전통적인 신뢰성 지표(reliability metrics)는 에이전트형 AI 시스템(agentic AI systems)에서는 제대로 작동하지 않습니다. 이제 실제 운영 환경에서 시맨틱 모니터링(semantic monitoring)을 어떻게 구현하는지 살펴보겠습니다.

당신의 AI 에이전트가 운영 환경에서 실행 중입니다.
HTTP 200. 가동 시간(Uptime) 99.9%. 모든 대시보드는 초록색입니다.
하지만 에이전트는 30%의 확률로 잘못된 결정을 내리고 있습니다.
당신의 모니터링 시스템은 이를 알려주지 않을 것입니다.

격차 (The Gap)
저는 이 문제를 깨닫기 위해 6개월 동안 고생하며 배웠습니다. 전통적인 SRE 모니터링은 인프라(infrastructure)를 측정합니다. 네트워크 지연 시간(Network latency), 에러율(Error rates), 가동 시간(Uptime) 등이 그것입니다. 이는 고장이 나면 충돌(crash)하는 서비스들을 위해 설계되었습니다. 하지만 에이전트는 충돌하지 않습니다. 대신 성능이 저하(degrade)됩니다. 천천히, 그리고 조용하게 말이죠.

에이전트는 다음과 같은 상태일 수 있습니다:

• 정확도는 94% (여전히 94%)
• 하지만 신뢰도(confidence)는 하락 중 (0.92에서 0.41로)
• 도구(tools) 호출을 3배 더 많이 하며 보완 중 (1.1배에서 3.1배로)
• 그동안 인간은 에이전트의 출력물을 더 많이 거부함 (1%에서 19%로)
• 승인을 기다리는 작업이 쌓임 (8개에서 340개로)

당신의 모니터링은 "모든 것이 정상"이라고 보여줍니다.
당신이 이를 알아차렸을 때는 이미 200만 달러의 손실이 발생한 후입니다.

우리가 실제로 측정해야 할 것: 인프라 지표가 아닌 시맨틱 지표(Semantic metrics)입니다.
네 가지 항목:

1. 결정 품질률 (Decision Quality Rate, DQR)
   에이전트가 올바른 도구를 선택하고 있는가?

• 정상: 92% 이상
• 조치 임계값: 85% 미만

2. 도구 호출 효율성 (Tool Invocation Efficiency, TIE)
   정상 범위를 넘어 도구를 과도하게 호출하며 보완하고 있는가?

• 정상: 기준치(baseline)의 1.0~1.2배
• 조치 임계값: 1.5배 초과

3. 인간 에스컬레이션 비율 (Human Escalation Rate, HER)
   인간이 에이전트의 결정을 거부하고 있는가?

• 정상: 2% 미만
• 조치 임계값: 5% 초과

4. 승인 대기열 깊이 드리프트 (Approval Queue Depth Drift, AQDD)
   승인을 기다리는 작업이 쌓이고 있는가?

• 정상: 대기 항목 20개 미만
• 조치 임계값: 대기 항목 50개 초과

이 중 어느 하나라도 드리프트(drift)가 발생하면, 48시간 이내에 시맨틱 실패(semantic failure)가 발생할 것입니다.

실제 시나리오
화요일 오후 2시: 에이전트의 성능 저하 시작. DQR이 94%에서 88%로 하락. TIE가 1.1배에서 1.4배로 증가. 전통적인 지표로는 아직 경고할 만한 수준이 아님.
당신의 인프라 모니터링은 여전히 초록색을 유지함.
목요일 오전 10시: DQR 62%. TIE 3.1배. 대기열 340개 항목.

첫 번째 알림이 마침내 울립니다. 에러율(error rates)이 서서히 상승하는 것을 감지한 인프라 모니터링 시스템으로부터 온 알림입니다.
당신은 방금 40시간 이상의 잘못된 결정으로 인한 손실을 입었습니다.
의미론적 SLI (Semantic SLIs)를 사용했다면, 화요일 오후 2시 15분에 이미 이 사실을 알았을 것입니다.

구현 방법
다음 기능을 갖춘 의미론적 SLI (Semantic SLI) 모니터링 시스템:

• 중요한 지표 추적 - DQR, TIE, HER, AQDD (가동 시간(uptime)이 아님)
• 조기 성능 저하 감지 - 전통적인 SLI (SLIs)보다 48시간 앞서 감지
• 해결 방법 제안 - 단순히 "무언가 잘못됨"이라고 알려주는 것이 아님
• 대응 자동화 - 점진적인 자율성 제약 (Progressive autonomy constraints)

성능 저하 감지 시:

• 에이전트 자율성 자동 제약 (FULL → GUIDED → SUPERVISED → BLOCKED)
• 컨텍스트(context)를 포함한 Slack 알림 전송
• 해결 단계 제안 (성공률에 따라 우선순위 지정)
• 감사(audit) 및 학습을 위해 모든 사항 추적

코드 예시

from agentsre.orchestration import FintechSREOrchestrator, AgentRole, AlertManager

# 오케스트레이터(orchestrator) 초기화

orch = FintechSREOrchestrator()  
orch.register_agent("payment-1", AgentRole.PAYMENT_PROCESSOR)

# 알림(alerts) 초기화

alerts = AlertManager()

def on_critical_alert(alert_dict):  
    send_to_slack(alert_dict)

alerts.slack_handler = on_critical_alert

# 에이전트 실행에 따른 지표(metrics) 업데이트

orch.update_metrics(  
    agent_id="payment-1",  
    dqr=62.0, # 결정 품질(Decision quality) 저하  
    tie=2.8, # 도구 호출(Tool calls) 증가  
    her=15.0, # 에스컬레이션(Escalations) 증가  
    aqd=180, # 대기열(Queue) 증가  
    confidence=0.42,  
    cost=0.0003  
)

# 해결 제안을 포함한 알림 생성

alert = alerts.create_alert(  
    agent_id="payment-1",  
    reason="Semantic degradation detected",  
    triggered_metrics=["DQR", "TIE", "HER"],  
    current_values={  
        "dqr": 62.0,  
        "tie": 2.8,  
        "her": 15.0,  
        "aqd": 180  
    }  
)

# 해결 단계(remediation steps) 가져오기

for step in alert.suggested_remediations[:3]:  
    print(f"→ {step.action} ({step.estimated_time_minutes}min)")  

출력 결과:
→ 최신 에이전트 결정 사항 10개 검토 - 패턴 식별 (15분)
→ 상위 서비스 (upstream service) 확인 - 잘못된 데이터를 반환할 가능성 높음 (10분)
→ 에이전트의 과잉 보정 (over-compensating) - 신뢰도 점수 (confidence scores) 확인 (10분)

SRE를 위한 의미
당신은 단순히 문제를 감지하는 것이 아니라, 문제를 이해하고 있는 것입니다.
기존의 방식이 다음과 같았다면:

"에러율이 높음"
"지연 시간 (latency)이 증가함"
"무언가 잘못됨"

이제 당신은 다음과 같은 정보를 얻게 됩니다:

"에이전트 결정 품질 15% 하락, 도구 호출 (tool calls) 2.8배 증가, 인간의 출력물 거부율 15%, 180개 항목 승인 대기 중"
권장 수정 사항: 상위 서비스 확인 (데이터 오염 가능성 있음)
심각도: CRITICAL (심각)

이것이 바로 사후 대응적 (reactive) 신뢰성과 선제적 (proactive) 신뢰성의 차이입니다.

Open Source - 이 모든 것은 오픈 소스로 구축되었습니다. MIT 라이선스입니다.
대규모 프로덕션 환경에서 테스트되었습니다. LangChain, CrewAI, Bedrock과 함께 작동합니다.
GitHub: https://github.com/Ajay150313/agentsre

당신의 팀을 위해
만약 프로덕션 환경에서 에이전트를 운영하고 있다면, 당신도 아마 이 문제를 겪고 있을 것입니다. 단지 아직 모르고 있을 뿐입니다.
시맨틱 SLI (semantic SLIs)를 시도해 보세요. 성능이 저하되고 있는지조차 몰랐던 무언가를 포착하게 된다면 (대부분의 팀이 그렇습니다), 그 가치를 알게 될 것입니다.
모르는 것에 대한 비용은? 때로는 200만 달러($2M)에 달할 수도 있습니다.