당신의 OTel 트레이스가 거짓말을 하고 있습니다: 추론 계층(Reasoning Layer)을 위한 관측성

3주 전, AWS Builders Slack의 누군가가 올린 글은 저를 얼어붙게 만들었습니다. 그들의 프로덕션 AI 에이전트는 6시간 동안 실행 중이었습니다. CPU는 정상이었고, 메모리는 안정적이었으며, 지연 시간(Latency)은 SLO 범위 내에 있었습니다. CloudWatch의 에러율도 0이었습니다. 하지만 에이전트는 모든 작업마다 재계획(re-planning)을 수행하고 있었습니다. 하나의 도구(tool)가 계속해서 오래된 데이터(stale data)를 반환하고 있었던 것입니다. 에이전트는 이를 인지하고 도구를 전환했지만, 다른 실패를 겪었고, 다시 재계획을 세웠습니다. 에이전트는 작업을 완료하긴 했지만 — 느리고, 비용이 많이 들며, 출력 품질이 저하되는 방식으로 진행되었습니다. 대시보드에서는 아무런 변화도 나타나지 않았습니다. 이것은 예외적인 사례가 아닙니다. 이것은 프로덕션 환경에서 에이전트형 AI(agentic AI)가 겪는 기본 실패 모드이며, 여러분의 현재 관측성(observability) 스택은 이를 포착할 수 없습니다.

왜 OTel이 문제를 놓치는가
OpenTelemetry(OTel)는 지난 10년 동안 관측성 분야에서 일어난 가장 좋은 변화입니다. 트레이스(Traces), 메트릭(metrics), 로그(logs) — 2026년 CNCF 마일스톤 기준으로 이 세 가지 신호 유형 모두에서 안정적입니다. 자동 계측(Auto-instrumentation)은 프로덕션 수준이며, 생태계도 성숙했습니다. 하지만 에이전트의 추론 동작(reasoning behavior)에 있어서는 추상화 수준(level of abstraction)이 잘못되었습니다. OTel 트레이스는 인프라 실행을 추적합니다. 트레이스는 다음과 같은 내용을 보여줍니다: 이 요청이 도착했고, 이 서비스를 호출했으며, 해당 서비스가 이 데이터베이스를 호출했고, 데이터베이스가 42ms 만에 응답했으며, 응답이 다시 돌아갔다는 사실 말입니다. 분산 시스템에는 완벽합니다. 하지만 에이전트는 고정된 호출 그래프(call graph)를 실행하지 않습니다. 에이전트는 추론합니다. 상태를 평가하고, 도구를 선택하고, 결과를 관찰하며, 계속할지 아니면 재계획할지를 결정하고, 또 다른 도구를 선택합니다. 추론 경로는 동적입니다. 동일한 입력이라도 도구가 무엇을 반환하느냐에 따라 실행 시마다 서로 다른 호출 그래프를 생성할 수 있습니다. 핵심적인 변화는 에이전트의 추론이 관측성 스택으로 내보내질 때, 트레이스가 인프라 실행이 아닌 추론 동작을 보여주기 시작한다는 점입니다 — 단, 올바른 데이터를 방출(emitting)하고 있을 때만 가능합니다. 대부분의 팀은 그렇지 못합니다. 그들은 인프라 스팬(infrastructure spans)만을 방출하고 있습니다. 추론 과정은 보이지 않는 상태로 남습니다.

패턴: 재계획 루프(Re-Planning Loops)를 통한 조용한 성능 저하

추론 과정을 캡처하지 않을 때, 트레이스(trace)에서 나타나는 조용한 에이전트 성능 저하(degradation)의 모습은 다음과 같습니다:

스팬(span): agent-task-processor
지속 시간(duration): 4.2s
상태(status): OK

스팬(span): tool-call-cloudwatch
지속 시간(duration): 0.8s
상태(status): OK

스팬(span): tool-call-s3
지속 시간(duration): 0.3s
상태(status): OK

스팬(span): tool-call-cloudwatch
지속 시간(duration): 0.8s
상태(status): OK

스팬(span): tool-call-dynamodb
지속 시간(duration): 0.4s
상태(status): OK

겉보기에는 괜찮아 보입니다. 4개의 도구 호출(tool calls)이 모두 성공했고, 작업이 완료되었습니다. 하지만 실제로 일어나고 있는 일은 다음과 같습니다:

에이전트가 작업을 수신함 → 계획(plans): CloudWatch 메트릭 X 사용 → CloudWatch 호출: 오래된 데이터 반환 (도구 호출은 성공했으나 데이터가 잘못됨) → 에이전트가 결과 평가: 예상 상태와 일치하지 않음 → 재계획(RE-PLANS): 대신 DynamoDB 시도 → DynamoDB 호출: 스키마 불일치 (도구 호출은 성공했으나 데이터 형식이 잘못됨) → 재계획(RE-PLANS): 다시 CloudWatch로 돌아가 다른 메트릭 시도 → CloudWatch 호출: 다시 오래된 데이터 반환 → 재계획(RE-PLANS): 사람에게 에스컬레이션(escalate to human)

4개의 성공적인 스팬, 2번의 재계획(re-planning) 사이클, 1번의 HER(Human Escalation Request) 에스컬레이션. 하지만 모니터링 시스템에는 에러가 0건입니다. 이것이 바로 여러분의 RSI(Retry Storm Index)가 작동하는 방식입니다. HTTP 재시도(retry) 수준이 아니라, 추론(reasoning) 수준에서 발생하는 것입니다.

추론 트레이스 깊이(Reasoning Trace Depth) 소개

RSI와 함께 사용할 새로운 관측 가능성(observable) 지표로 추론 트레이스 깊이(Reasoning Trace Depth, RTD)를 소개하고자 합니다.

RTD = 에이전트가 작업을 완료하거나 에스컬레이션하기 전까지 거치는 재계획(re-planning) 사이클의 횟수.

일상적인 작업에서 건강한 에이전트의 기준치: 0~1회의 재계획 사이클.
경고 임계값(Warning threshold): 3회 이상의 재계획 사이클.
심각 임계값(Critical threshold): 5회 이상의 재계획 사이클 (에이전트가 사실상 갇힌 상태).

RTD는 가장 빠른 신호입니다. RTD는 HER이 발생하기 전(에이전트가 에스컬레이션하기 전에 여전히 시도 중이므로), 지연 시간(latency)이 사용자에게 눈에 보이기 전, 그리고 비용 메트릭에서 비정상적인 지출이 나타나기 전에 상승합니다.

from dataclasses import dataclass, field
from typing import List, Optional
import time

@dataclass
class AgentDecisionTrace:
    """
    단일 에이전트 작업 실행을 위한 구조화된 추론 트레이스(reasoning trace).
    도구 호출(tool call)마다 한 번씩이 아니라, 작업당 한 번씩 방출됩니다.
    이것이 여러분의 추론 관측성 계층(reasoning observability layer)입니다.
    """

agent_id: str session_id: str task_id: str timestamp: str # 추론 동작 (Reasoning behavior) initial_plan: str tools_called: List[str] = field(default_factory=list) replan_count: int = 0 # RTD — 추론 트레이스 깊이(Reasoning Trace Depth) replan_reasons: List[str] = field(default_factory=list) # 결과 (Outcome) task_completed: bool = False human_escalated: bool = False # HER 신호 # 비용 신호 (Cost signals) total_tool_calls: int = 0 latency_ms: int = 0 # 품질 프록시 (Quality proxy) (사용 가능한 경우) confidence_proxy: Optional[float] = None def emit_decision_trace(trace: AgentDecisionTrace) -> dict: """ 구조화된 의사 결정 트레이스(structured decision trace)를 로그 집계기(log aggregator)로 방출합니다. 이것은 여러분의 OTel 인프라 스팬(spans)보다 상위에 위치합니다. 에이전트 작업당 하나의 항목 — 즉, 여러분의 추론 관측성 계층입니다.""" record = { "trace_type": "agent_decision", "agent_id": trace.agent_id, "session_id": trace.session_id, "task_id": trace.task_id, "timestamp": trace.timestamp, "reasoning": { "initial_plan": trace.initial_plan, "replan_count": trace.replan_count, # RTD "replan_reasons": trace.replan_reasons, "tools_sequence": trace.tools_called }, "outcome": { "completed": trace.task_completed, "human_escalated": trace.human_escalated, # HER }, "cost": { "tool_calls_total": trace.total_tool_calls, "latency_ms": trace.latency_ms } } # 트레이스.replan_count가 3 이상일 때 즉각적인 주의를 위한 플래그: record["alert"] = "RTD_WARNING" if trace.replan_count >= 3: record["alert"] = "RTD_WARNING" if trace.replan_count >= 5: record["alert"] = "RTD_CRITICAL" return record 에이전트를 위한 세 가지 계층의 관측성 모델 (The Three-Layer Observability Model for Agents) 현재 스택은 두 개의 계층을 가지고 있습니다. 여러분에게는 세 개가 필요합니다. 계층 1 — 인프라(Infrastructure) (이미 갖추고 있음): OTel 트레이스, Prometheus 메트릭, 구조화된 로그. 도구 호출 지연 시간, 오류율, 리소스 활용률. 이것이 Datadog, Grafana, 그리고 CloudWatch가 보여주는 것입니다. 정확하고 필수적입니다. 단지 추론(reasoning)을 보지 못할 뿐입니다. 계층 2 — 제어 평면(Control Plane) (Post 7에서 가져옴 — RAR, RSI, DCS): 오케스트레이션 수준에서의 라우팅 정확도, 재시도 패턴, 분해 품질. 이것은 워크플로우 수준에서의 에이전트 동작입니다 — 작업들이 올바르게 라우팅되고 있습니까?

오케스트레이터(Orchestrator)가 안정적인가요? 레이어 3 — 추론 (Reasoning) (누락된 것들): RTD (Reasoning Trace Depth, 추론 트레이스 깊이), 재계획 이유 (re-plan reasons), 계획 대비 실행 차이 (plan-to-execution delta), 결정 신뢰도 프록시 (decision confidence proxies). 에이전트 작업당 하나의 구조화된 로그 엔트리(structured log entry). 이것은 여러분의 대시보드에는 없는 레이어입니다. 무언가 잘못된 것 같지만 대시보드는 초록색(정상)일 때의 진단 흐름:

레이어 1 확인: 인프라가 건강한가? → 예 → 레이어 2로 이동
레이어 2 확인: RSI가 상승했는가? RAR이 저하되었는가? → RSI 상승 → 레이어 3으로 이동
레이어 3 확인: RTD가 기준치(baseline)보다 높은가? → RTD > 3 → 에이전트가 재계획(re-planning) 중임, 이를 유발하는 도구/데이터 소스를 찾으세요 → RTD 정상, HER 상승 → 에이전트가 깔끔하게 에스컬레이션(escalating) 중임, 결정 범위(decision envelope)를 확인하세요

CloudWatch에서의 구현 모습

import boto3

cw = boto3.client('cloudwatch', region_name='us-east-1')

def publish_rtd_metric(agent_id: str, rtd_value: int) -> None:
    """
    CloudWatch에 Reasoning Trace Depth를 게시합니다.
    RTD가 3을 초과하면 경고를 보냅니다 — 에이전트가 과도하게 재계획하고 있습니다.
    """
    cw.put_metric_data(
        Namespace='AgentSRE/Reasoning',
        MetricData=[{
            'MetricName': 'ReasoningTraceDepth',
            'Dimensions': [{'Name': 'AgentId', 'Value': agent_id}],
            'Value': float(rtd_value),
            'Unit': 'Count'
        }]
    )

RTD > 3이 5분 동안 지속될 때 알람을 설정하세요. 이것은 HER이 급증하기 전, 사용자가 지연 시간(latency)을 느끼기 전, 그리고 결제 대시보드에 비용 이상(cost anomalies)이 나타나기 전의 조기 경보입니다.

기존 SLI 프레임워크와의 연결

이 시리즈를 계속 따라오고 계셨다면:
포스트 4에서는 여러분의 인간 에스컬레이션 신호인 HER을 소개했습니다. HER은 에이전트가 재계획을 포기한 후에 발생하는 현상입니다.
포스트 7에서는 제어 평면(control plane) 수준에서의 재시도 폭풍(retry storm) 신호인 RSI를 소개했습니다.
이 포스트에서는 RSI와 HER이 임계치를 넘기 전에 이를 예측할 수 있는, 더 앞선 단계인 추론 수준의 신호 RTD를 소개합니다.

RTD → feeds → RSI → feeds → HER

이 세 가지는 인과 관계의 사슬(causal chain)을 형성합니다. 만약 여러분이 HER만 지켜보고 있다면, 여러분은 사슬의 끝을 보고 있는 것입니다. RTD는 여러분에게 사슬의 앞부분을 제공합니다.

실무 체크리스트

다음 에이전트(agent)를 배포하기 전에, 운영 준비성(production-readiness) 체크리스트에 다음 항목을 추가하세요:

☐ 결정 트레이스(Decision trace) 구조화된 로깅(structured logging) 설정 완료 (스팬(span) 단위가 아닌 작업(task)당 하나의 JSON 엔트리 생성)
☐ CloudWatch / Prometheus로 RTD 메트릭(metric) 전송 설정
☐ RTD 기준선(baseline) 수립 (30일간의 섀도 모드(shadow mode) 운영 — HER 기준선 프로토콜과 동일)
☐ 임계값 > 3에서 RTD 알람 설정
☐ 대시보드에서 RTD와 HER의 상관관계 확인 — HER의 상승 없이 RTD만 상승한다면 에이전트가 어려움을 겪고 있지만 아직 에스컬레이션(escalating) 단계는 아님을 의미함

여러분의 OTel 트레이스는 정확합니다. 단지 잘못된 질문에 답하고 있을 뿐입니다.

https://www.linkedin.com/posts/ajay-devineni_sre-agenticai-observability-activity-7462294037518159872-iF29?utm_source=share&utm_medium=member_desktop&rcm=ACoAACIp55QBRGVmAcEbf0D-1PaR5vEbm2yMcJU Ajay Devineni | AWS Community Builder | Senior SRE/Platform Engineer | github.com/Ajay150313/agentsre