AI Agent 모니터링, 알림, 실패 복구: 로그에서 상태 머신까지의 설계 실전

Gartner의 2024년 보고서에 따르면, 엔터프라이즈급 AI Agent 프로젝트의 87%는 배포 후 3개월 안에 작업 실패율이 25%를 넘었습니다. 실패 원인은 대개 여러 겹으로 중첩된 도구 호출 안에 숨어 있고, 로그는 여기저기 흩어져 있어 제대로 추적하기 어렵습니다.

문제의 뿌리는 알림의 개수가 아니라 Agent 자체의 모니터링 아키텍처가 잘못되었다는 데 있습니다. Agent는 일반적인 백엔드 서비스가 아닙니다. 비결정적 특성 때문에 전통적인 모니터링 방식만으로는 부족합니다. 실행 경로가 동적으로 생성되고, 같은 작업도 실행할 때마다 다른 경로를 탈 수 있기 때문입니다. 이 글에서는 로그, 지표, 추적, 그리고 상태 머신 아키텍처까지 이어지는 완전한 설계 관점을 정리합니다. 목표는 Agent를 “통제 불가능한 블랙박스”에서 “모든 실패를 추적하고 복구할 수 있는 투명한 시스템”으로 바꾸는 것입니다.

1장: 전통적인 모니터링은 왜 Agent에서 실패하는가?

이런 상황을 겪어 본 적이 있나요? Agent 작업 하나가 실패했습니다. 로그를 샅샅이 뒤졌지만 보이는 것은 LLM 출력 조각뿐이고, 완전한 실행 궤적은 맞춰지지 않습니다. 결국 한숨을 쉬며 다시 실행하고, 이번에는 성공하길 바랄 수밖에 없습니다.

전통적인 백엔드 서비스의 모니터링 로직은 이렇습니다. 요청이 들어오고 A, B, C 세 개의 마이크로서비스를 지나갑니다. 각 노드는 상태와 타임스탬프를 기록합니다. 문제가 생기면 호출 체인을 따라가며 조사하면 됩니다. 하지만 Agent는 다릅니다.

Agent의 실행 경로는 동적으로 생성됩니다. 같은 작업이라도 첫 번째 실행에서는 도구 A를 호출하고, 두 번째 실행에서는 도구 B를 호출하며, 세 번째 실행에서는 도구 호출을 건너뛸 수도 있습니다. OpenAI의 2024년 보고서에 따르면 Agent의 평균 작업 완료율은 61.8%에 그칩니다. 이 숫자 뒤에는 Agent가 추론 과정에서 스스로 의사결정을 하고, 그 의사결정 자체가 불확실하다는 이유가 있습니다.

더 나쁜 것은 God Prompt입니다. 전체 Agent 로직을 하나의 거대한 프롬프트에 밀어 넣는 방식입니다. ArizenAI의 기술 블로그는 이를 “프로덕션 환경의 가장 큰 위험 요소”라고 부릅니다. 왜일까요? 테스트할 수 없고, 디버깅할 수 없고, 예측할 수 없기 때문입니다.

5000자짜리 프롬프트를 단위 테스트할 수는 없습니다. 어느 추론 단계에서 문제가 생겼는지 정확히 찾을 수도 없습니다. 파라미터 하나를 바꿨을 때 연쇄 붕괴가 일어날지 예측하기도 어렵습니다. 저는 한 프로젝트에서 God Prompt 하나를 본 적이 있습니다. 예시 하나를 바꾼 뒤 성공률이 70%에서 30%로 바로 떨어졌습니다. 일주일을 조사한 끝에야 새 예시가 Agent에게 “도구 A를 우선 호출하라”는 패턴을 학습시켰고, 그 시나리오에서는 도구 A가 애초에 호출되면 안 된다는 사실을 찾았습니다.

OpenAI 보고서는 또 하나의 데이터를 언급합니다. Agent 실패의 82%는 복구 가능한 오류입니다. Agent의 능력이 부족해서가 아니라 설계가 충분히 견고하지 않다는 뜻입니다. 모니터링은 단순히 “문제를 발견하는 것”에 그치면 안 됩니다. “Agent를 개선하는 피드백 루프”가 되어야 합니다. 각 상태의 성공률, 각 도구 호출의 소요 시간, 각 오류 유형의 발생 빈도를 알아야 합니다. 이 데이터가 Agent의 어느 부분을 고쳐야 하는지 알려 줍니다.

전통적인 모니터링 사고방식은 “문제가 생기면 그때 조사한다”입니다. Agent 모니터링의 사고방식은 “모든 단계에 흔적을 남기고, 실패 자체를 학습 기회로 삼는다”입니다. 이 관점 전환이 전체 시스템 설계의 출발점입니다.

2장: AI Agent 관측 가능성의 3계층 아키텍처

Agent 모니터링은 단일 수단에 기대지 않습니다. 로그, 지표, 추적이라는 세 계층을 겹쳐야 합니다. 각 계층은 서로 다른 차원의 문제를 해결합니다.

1계층: 혼돈의 로그에서 구조화 기록으로

Agent의 원시 로그를 본 적이 있나요? LLM이 생성한 텍스트 조각과 오류 스택이 뒤섞이고, 타임스탬프는 여기저기 흩어져 있습니다. 이런 로그는 사후 “발굴”에는 쓸 수 있어도 실시간 모니터링에는 맞지 않습니다.

구조화 로그의 핵심은 모든 로그에 태그를 붙이는 것입니다. Agent ID, 작업 ID, 현재 상태, 입력과 출력 요약. 이런 필드가 있어야 작업별로 묶고, 상태별로 필터링하고, 시간순으로 정렬할 수 있습니다.

# 구조화 로그 예시
import structlog

logger = structlog.get_logger()

def log_agent_step(agent_id: str, task_id: str, state: str, input: dict, output: dict):
    logger.info(
        "agent_step",
        agent_id=agent_id,
        task_id=task_id,
        state=state,
        input_summary=str(input)[:100],  # 로그 팽창을 막기 위해 자르기
        output_summary=str(output)[:100],
        timestamp=time.time()
    )

간단해 보이지만 많은 팀이 이조차 하지 않습니다. LLM의 원시 출력을 그대로 로그에 던져 넣고, grep으로 가치 있는 정보를 건질 수 있기를 기대합니다. 그렇게는 어렵습니다.

2계층: Agent 전용 지표

지표는 “추세 분석” 문제를 해결합니다. 로그가 특정 작업이 실패했다는 사실을 알려 준다면, 지표는 실패율이 상승하고 있다는 사실을 알려 줍니다.

Agent에는 네 가지 핵심 지표가 필요합니다.

지표 유형	구체 지표	권장 알림 임계값
Token 사용량	총 사용량, 단일 작업 사용량, 도구 호출 사용량	단일 작업 > 10000 token
지연 시간	P50, P99, 도구 호출 소요 시간	P99 > 30초
오류율	작업 실패율, 도구 호출 실패율, 재시도 성공률	실패율 > 20%
비용	작업당 비용, 일일 총비용	일일 비용 50% 급증

LangSmith의 Dashboard는 좋은 예입니다. Agent별로 이런 지표를 그룹화해 보여 주고, 구체적인 작업까지 내려가 세부 정보를 볼 수 있습니다. 알림 임계값은 역사적 데이터에 기반해 설정해야 합니다. 감으로 정하면 안 됩니다. 일주일 정도 실행해 정상 범위를 통계로 잡고, 정상 상한의 약 1.5배 지점에 임계값을 둡니다.

3계층: OpenTelemetry 추적 표준

추적은 “호출 체인 복원” 문제를 해결합니다. 하나의 Trace는 사용자 요청에서 시작해 의도 인식, 도구 선택, 실행, 검증을 거쳐 최종 출력에 도달합니다. 각 단계는 하나의 Span이며, 타임스탬프, 상태, 입력과 출력을 포함합니다.

OpenTelemetry는 업계 표준이 되어 가고 있습니다. PredictionGuard의 블로그에 따르면, 이 표준은 프레임워크와 도구를 가로질러 추적 형식을 통일할 수 있게 합니다. 주요 Agent 프레임워크도 이미 지원을 시작했습니다. Pydantic AI, smolagents, Strands Agents, LangGraph가 그 예입니다.

# OpenTelemetry 추적 예시
from opentelemetry import trace
from opentelemetry.sdk.trace.export import ConsoleSpanExporter

tracer = trace.get_tracer("agent_tracer")

async def run_agent_with_trace(task: str):
    with tracer.start_as_current_span("agent_task") as span:
        span.set_attribute("task_input", task)
        
        # 의도 인식
        with tracer.start_as_current_span("intent_detection") as intent_span:
            intent = await detect_intent(task)
            intent_span.set_attribute("intent_result", intent)
        
        # 도구 호출
        with tracer.start_as_current_span("tool_call") as tool_span:
            result = await call_tool(intent)
            tool_span.set_attribute("tool_result", str(result)[:200])
        
        span.set_attribute("final_output", result)
        return result

Langfuse와 LangSmith는 모두 OpenTelemetry 가져오기를 지원합니다. 오픈소스 솔루션으로 추적 데이터를 수집한 뒤, 상용 플랫폼으로 가져와 시각화 분석을 할 수 있다는 뜻입니다. 단일 공급업체에 묶이는 일을 피할 수 있습니다.

세 계층을 겹치면 장점이 분명합니다. 로그는 세부 사항을 보고, 지표는 추세를 보고, 추적은 전체 모습을 봅니다. 어떤 차원도 놓치지 않게 됩니다.

3장: 상태 머신 설계: 실패를 관측 가능하게 만드는 핵심 패턴

God Prompt의 본질적인 문제는 “한 냄비에 모두 끓이는” 방식이라는 점입니다. 모든 로직이 섞여 있으니 문제가 생겨도 어느 단계가 무너졌는지 알 수 없습니다. 상태 머신은 이 큰 냄비를 작은 단계들의 흐름으로 나눕니다.

ArizenAI의 기술 블로그는 하나의 숫자를 제시합니다. 상태 머신은 추론 비용을 80% 낮출 수 있습니다. 어떻게 가능할까요? 각 상태가 하나의 일만 하기 때문에 LLM이 매번 처음부터 전체를 추론할 필요가 없기 때문입니다.

상태 머신 vs God Prompt: 근본적인 차이

차원	God Prompt	상태 머신
테스트 가능성	단위 테스트 불가	각 상태를 독립적으로 테스트
디버깅 가능성	실패 위치가 모호함	상태 경계가 명확함
비용 제어	매번 전체 프롬프트를 추론	현재 상태에 필요한 부분만 추론
오류 처리	프롬프트 안에 숨겨짐	Typed transitions로 명시적으로 정의

전형적인 Agent 상태 머신 구조는 다음과 같습니다.

[초기화] -> [의도 인식] -> [도구 선택] -> [실행] -> [검증] -> [완료]
         ↘            ↗
           [오류 처리]

ArizenAI는 5-12개의 상태를 권장합니다. 너무 적으면 God Prompt로 퇴화하고, 너무 많으면 상태 전이가 지나치게 복잡해집니다. 각 상태에는 명확한 입력과 출력 타입 정의가 있어야 합니다. 이것이 Typed transitions입니다.

# 상태 정의 예시(의사 코드)
from typing import TypedDict, Literal

class IntentState(TypedDict):
    task_input: str
    intent_type: Literal["query", "action", "clarify"]

class ToolState(TypedDict):
    intent: IntentState
    selected_tool: str
    tool_params: dict

class ErrorState(TypedDict):
    failed_state: str
    error_type: str
    retry_count: int

# 상태 전이: 명시적인 오류 경로
def transition_from_intent(intent: IntentState) -> ToolState | ErrorState:
    try:
        tool = select_tool(intent)
        return {"intent": intent, "selected_tool": tool, "tool_params": {}}
    except IntentError as e:
        return {"failed_state": "intent", "error_type": "ambiguous", "retry_count": 0}

각 상태에서 모니터링해야 할 것

상태 머신의 장점은 각 상태가 자연스럽게 하나의 모니터링 단위가 된다는 점입니다. 혼돈의 로그에서 정보를 건질 필요가 없습니다. 상태별로 바로 지표를 보면 됩니다.

• 초기화 상태: 작업 시작 시간, 입력 완전성 검사 결과를 기록합니다.
• 의도 인식 상태: 의도 유형 분포, 인식 소요 시간, 모호성 비율을 기록합니다.
• 도구 선택 상태: 도구 호출 빈도, 선택 소요 시간, 매칭되는 도구가 없는 비율을 기록합니다.
• 실행 상태: 도구 실행 소요 시간, 성공률, 실패 유형 분포를 기록합니다.
• 검증 상태: 검증 통과율, 수정 시도 횟수를 기록합니다.
• 오류 처리 상태: 오류 유형 분포, 재시도 성공률, 다운그레이드 트리거 횟수를 기록합니다.

이 지표들은 Agent의 어느 단계에 문제가 있는지 한눈에 보여 줍니다. 의도 인식 시간이 갑자기 2초에서 10초로 늘었나요? 프롬프트가 너무 길어진 것일 수 있습니다. 도구 호출 실패율이 5%에서 30%로 올랐나요? 어떤 API 서비스가 장애 상태일 수 있습니다.

상태 머신은 모니터링의 입도를 “전체 작업”에서 “각 단계”로 세분화합니다. 이는 어떤 알림 규칙보다 효과적입니다. 문제 위치를 찾는 것 자체가 모니터링의 일부이기 때문입니다.

4장: 실패 복구의 엔지니어링 실전

모니터링은 문제를 발견하고, 복구 메커니즘은 문제를 해결합니다. 하지만 복구는 단순히 “재시도”가 아닙니다. 무작정 재시도하면 상황이 더 나빠질 수 있습니다.

오류 분류: 모든 실패가 같지는 않다

제가 접한 프로젝트에서 오류는 대체로 세 가지로 나뉩니다.

유형	비중	특징	처리 방식
일시적 오류	~60%	API 타임아웃, 서비스 흔들림, rate limit	지수 백오프 재시도(최대 5회)
논리 오류	~30%	파라미터 형식 오류, 도구 없음, 의도 모호성	자기 성찰 + 전략 조정
연쇄 오류	~10%	핵심 서비스 붕괴, 설정 오류	차단 + 다운그레이드 처리

Alibaba Cloud의 데이터에 따르면 합리적인 재시도 메커니즘은 API 성공률을 85%에서 99.5%로 높일 수 있습니다. 다만 전제는 “합리적”이어야 한다는 것입니다.

재시도의 함정: Context Contamination

2026년 5월의 한 Arxiv 논문은 직관에 반하는 현상을 지적했습니다. 단순 재시도는 오히려 성공률을 낮추는 경우가 많다는 것입니다.

왜 그럴까요? 실패 정보가 이후 추론을 “오염”시키기 때문입니다.

이런 장면을 떠올려 보세요. Agent가 도구 A 호출에 실패했고, 오류 정보가 대화 기록에 추가되었습니다. Agent는 그 오류 정보를 본 뒤 “도구 A에 문제가 있으니 도구 B를 시도해 보자”고 추론할 수 있습니다. 그런데 도구 B도 실패했습니다. 이제 대화 기록에는 실패 기록이 두 개 있습니다. Agent는 “이 작업은 너무 복잡하니 포기하자”고 추론할 수 있습니다.

이것이 Context Contamination입니다. 실패 정보 자체가 Agent의 추론 경로를 바꾸고, 이후 시도를 포기나 잘못된 전략 쪽으로 기울게 만듭니다.

해결책은 상태 격리입니다. 재시도할 때마다 전체 실패 이력을 상속해서는 안 됩니다. “깨끗한 상태”에서 다시 시작해야 합니다. 또는 재시도 전에 실패 정보를 원시 오류 스택이 아니라 구조화된 오류 요약으로 압축해야 합니다.

# 상태 격리 재시도 예시
async def retry_with_clean_state(task: str, error: AgentError, max_retries: int = 3):
    for attempt in range(max_retries):
        # 전체 실패 이력을 전달하지 않고 구조화된 오류 요약만 전달
        error_summary = {
            "type": error.type,
            "failed_step": error.step,
            "hint": get_recovery_hint(error)
        }
        
        result = await run_agent_state(
            start_state="error_recovery",
            context={"original_task": task, "error_summary": error_summary}
        )
        
        if result.success:
            return result
    
    return {"status": "failed", "reason": "max_retries_exceeded"}

다운그레이드 처리: 실패를 인정하고 우아하게 종료하기

어떤 오류는 자동으로 복구할 수 없습니다. 3-5회 연속 실패하면 다운그레이드를 트리거해야 합니다.

다운그레이드 전략은 상황에 따라 선택합니다.

• 작업 단순화: 복잡한 작업을 단순한 버전으로 나누고 일부 결과를 반환합니다.
• 사람의 개입 요청: 작업을 보류하고 운영 담당자나 사용자에게 알립니다.
• 기본 응답: 미리 준비한 일반 답변을 반환해 사용자 경험이 끊기지 않게 합니다.

NIST SP 800-61 Rev. 3(2025년 업데이트)는 사건 대응의 여섯 가지 기능을 정의합니다. Govern(거버넌스), Identify(식별), Protect(보호), Detect(탐지), Respond(대응), Recover(복구)입니다. 이 프레임워크는 원래 사이버 보안 사건 대응 표준이지만, Agent 시스템 운영에도 완전히 적용할 수 있습니다.

NIST 프레임워크를 Agent에 매핑하면 다음과 같습니다.

• Govern: 실패 임계값, 다운그레이드 전략, 책임 소재를 정의합니다.
• Identify: 오류 유형을 분류하고 실패 체인을 추적합니다.
• Protect: 다운그레이드 전략과 서킷 브레이커를 미리 준비합니다.
• Detect: 실시간 모니터링과 이상 탐지를 수행합니다.
• Respond: 재시도 또는 다운그레이드를 트리거하고 사건을 기록합니다.
• Recover: 정상 서비스를 복구하고 회고를 통해 개선합니다.

이 프레임워크의 장점은 “복구”를 임시 보완이 아니라 완전한 프로세스로 다룬다는 점입니다.

5장: 실전 사례와 도구 추천

이론을 살펴봤다면 이제 중요한 것은 실제 적용입니다. 여기서는 몇 가지 구체적인 통합 방안을 소개합니다.

LangGraph + Langfuse 모니터링 설정

LangGraph는 OpenTelemetry를 네이티브로 지원하며, Langfuse 연동에는 몇 줄의 설정만 필요합니다.

from langfuse import Langfuse
from langfuse.callback import CallbackHandler

langfuse_handler = CallbackHandler(
    public_key="pk-xxx",
    secret_key="sk-xxx",
    host="https://cloud.langfuse.com"
)

# LangGraph 컴파일 시 콜백 주입
agent = graph.compile()
result = agent.invoke(
    {"input": task},
    config={"callbacks": [langfuse_handler]}
)

Langfuse는 각 노드의 추적 데이터를 자동으로 수집합니다. 입력과 출력, 소요 시간, token 사용량이 포함됩니다. Dashboard에서 작업 ID별로 전체 실행 체인을 확인할 수 있습니다.

CrewAI 건강 검사 엔드포인트

CrewAI에는 내장 모니터링이 없으므로 직접 건강 검사 엔드포인트를 설계해야 합니다.

from fastapi import FastAPI
from crewai import Crew

app = FastAPI()

@app.get("/health")
async def health_check():
    # 최근 100개 작업의 성공률 확인
    recent_tasks = get_recent_tasks(limit=100)
    success_rate = sum(1 for t in recent_tasks if t.status == "success") / len(recent_tasks)
    
    return {
        "status": "healthy" if success_rate > 0.8 else "degraded",
        "success_rate": success_rate,
        "last_error": recent_tasks[-1].error_summary if recent_tasks[-1].status == "failed" else None
    }

이 엔드포인트는 Kubernetes의 건강 검사 메커니즘에 연결하거나 알림 시스템의 데이터 소스로 사용할 수 있습니다.

도구 추천 매트릭스

시나리오	추천 도구	특징	적합한 팀
추적	Langfuse	OpenTelemetry 네이티브, 오픈소스, 셀프 호스팅 선택 가능	커스텀 배포가 필요한 팀
모니터링	LangSmith	LangChain 공식, 알림 통합이 잘 갖춰짐	LangChain/LangGraph를 사용하는 팀
로그	Loki + Grafana	저비용, K8s 친화적, 기존 인프라 활용 가능	대규모 배포와 예산 민감도가 높은 팀
이상 탐지	Luna-2 소형 모델	Agent 특화 패턴 인식, 알림 소음 감소 효과	알림 소음이 심각한 팀

PredictionGuard의 블로그는 Luna-2 같은 소형 언어 모델이 Agent의 특정 실패 패턴을 이해할 수 있어 전통적인 임계값 알림보다 더 똑똑하다고 말합니다. 알림 패널에 매일 수십 개의 알림이 쌓이고 그중 90%가 소음이라면, 이런 모델은 시도해 볼 만합니다.

결론

완전한 Agent 모니터링 체계가 있느냐 없느냐의 차이는 얼마나 클까요?

차원	모니터링 체계 없음	모니터링 체계 있음
문제 위치 파악	로그를 뒤져야 하며 오래 걸림	상태별로 위치를 잡고 초 단위로 대응
실패 복구	무작정 재시도해 성공률이 낮음	유형별 처리와 목적에 맞는 복구
알림 품질	소음이 폭발하고 근본 원인이 묻힘	소음을 줄이고 집계해 신호가 선명함
Agent 개선	감으로 파라미터 조정	데이터 기반 최적화

God Prompt에서 상태 머신으로, 혼돈의 로그에서 OpenTelemetry 추적으로, 무작정 재시도에서 상태 격리 복구로. 이 전환은 “있으면 좋은 것”이 아니라 Agent를 프로덕션 환경에 올리기 위한 필수 경로입니다.

아직 거대한 프롬프트 하나로 전체 Agent를 지탱하고 있다면, 오늘부터 상태를 나누기 시작하세요. 5-12개의 이산 상태, 각 상태의 단일 책임, 명시적으로 정의된 실패 경로가 필요합니다.

아직 OpenTelemetry를 연동하지 않았다면 지금이 가장 좋은 시점입니다. 주요 프레임워크는 이미 지원하고 있으며, Langfuse와 LangSmith 모두 추적 데이터를 직접 가져올 수 있습니다.

재시도는 만능약이 아닙니다. Context Contamination은 단순 재시도를 더 깊은 실패로 끌고 갈 수 있습니다. 상태 격리를 설계하는 것이 올바른 길입니다.

Agent의 프로덕션화는 결코 “프롬프트를 잘 쓰면 충분하다”로 끝나지 않습니다. 모니터링과 복구야말로 Agent를 진짜로 제어 가능하게 만드는 단계입니다.