지난 화요일, 나의 AI 에이전트가 활성 고객들에게 47통의 잘못된 가격 안내 이메일을 보냈습니다. 사람이 이를 인지하고 문제를 제기하기까지 3시간이 걸렸습니다. 그때는 이미 피해가 발생한 후였습니다. 세 명의 고객이 혼란스러워하며 답장을 보냈고, 한 명은 고객 지원팀(Support)에 문제를 제기했습니다.

에이전트는 자신의 작업을 완료했습니다. 로그에는 "Done(완료)"이라고 기록되었습니다. 그리고 다음 작업으로 넘어갔습니다. 실패는 로그가 전혀 확인하지 않는 곳에서 조용히 발생했습니다.

이것이 바로 데모에서는 아무도 이야기하지 않는 프로덕션 관측성(Production Observability)의 격차입니다. 우리는 에이전트가 더 많은 일을 하도록 만드는 데 엄청난 노력을 기울입니다. 하지만 에이전트가 실패했을 때 이를 인지할 수 있도록 만드는 데에는 거의 아무런 노력도 기울이지 않습니다.

로그(Logs)와 관측성(Observability)의 차이

대부분의 에이전트 프레임워크(Agent Frameworks)는 로그를 제공합니다. 하지만 당신에게 필요한 것은 관측성(Observability)입니다. 즉, "에이전트가 실제로 내가 요청한 것을 완수했는가? 그리고 그것을 어떻게 알 수 있는가?"라고 물을 수 있는 능력입니다.

이것이 어려운 데에는 구조적인 이유가 있습니다. 전통적인 서비스가 실패할 때는 예외(Exception), 스택 트레이스(Stack Trace), 500 에러가 발생합니다. 하지만 AI 에이전트가 실패할 때는 대개 조용히 실패합니다. 그럴듯하지만 틀린 결과물을 생성하거나, 잘못된 도구(Tool)를 사용하거나, 혹은 오래된 데이터(Stale Data)를 기반으로 작업을 완료해 버립니다. 오류는 실행 과정이 아니라 결과물(Output)에 있습니다.

제가 반복적으로 목격하는 패턴은 다음과 같습니다:

# 대부분의 사람들이 배포하는 방식
result = agent.run(task)
logger.info(f"Agent completed: {result}")

이 방식은 에이전트가 실행되었다는 것만 알려줍니다. 결과가 정확한지, 에이전트가 당신이 기대한 대로 행동했는지, 혹은 올바른 문제에 대해 작업했는지에 대해서는 아무것도 알려주지 않습니다.

15분 정도의 관측성 계층(Observability Layer)만 있었어도 3시간의 낭비를 피할 수 있었을 것입니다.

실제로 작동하는 관측성 스택(Observability Stack)

프로덕션 환경에서 6개 정도의 에이전트 시스템을 배포한 후, 저는 실제로 마주치는 실패 모드들을 커버할 수 있는 최소한의 관측성 스택을 결정했습니다. 여기에는 네 가지 구성 요소가 있습니다.

1. 구조화된 트레이스 컨텍스트 (Structured Trace Context)

모든 에이전트 세션은 시작되는 즉시 UUID를 할당받습니다. 모든 로그 라인, 모든 도구 호출 (tool call), 모든 모델 응답에는 해당 ID가 포함됩니다. 이것이 없다면 다단계 에이전트 실행 (multi-step agent run) 과정에서 발생한 일들을 서로 연관 지을 수 없습니다.

import contextvars
import uuid
from datetime import datetime
...

이 세션 객체를 모든 도구 호출을 통해 전달하세요. 무언가 문제가 발생하면, 트레이스 ID (trace ID)를 grep으로 검색하여 전체 실행 이력을 확보할 수 있습니다.

2. 도구 호출 섀도우 검증 (Tool Call Shadow Validation)

가장 흔한 실패 모드는 "에이전트가 충돌(crash)하는 것"이 아닙니다. 바로 "에이전트가 잘못된 파라미터 (parameters)로 올바른 도구를 호출하는 것" 또는 "에이전트가 합리적인 도구를 호출했지만 출력값이 쓰레기(garbage)인 것"입니다.

에이전트의 속도를 늦추지 않으면서, 호출 자체와 응답에 대한 구조적 검증 (structural validation)을 모두 캡처하세요:

def tracked_tool_call(session: AgentSession, tool_name: str, params: dict, result):
    session.tool_calls.append({
        "tool": tool_name,
...

이를 통해 도구는 실행되지만 쓸모없는 값을 반환하는 유형의 실패를 에이전트의 실행을 차단하지 않고도 잡아낼 수 있습니다.

3. 완료 기준 단언 (Completion Criteria Assertions)

에이전트가 작업을 완료했다고 표시하기 전에, 출력값에 대해 일련의 단언 (assertions)을 실행하세요. 이것은 유닛 테스트 (unit tests)가 아니라, 실제 결과에 대한 런타임 체크 (runtime checks)입니다.

def validate_completion(session: AgentSession, task: str, result) -> bool:
    checks = [
        ("result_is_string", lambda: isinstance(result, str) and len(result) > 10),
...

이러한 체크가 모든 실패를 잡아낼 수는 없습니다. 하지만 침묵하는 실패 (silent failures), 즉 에이전트가 읽어보기 전까지는 정당해 보이는 자신만만한 헛소리를 생성하는 경우를 잡아낼 수 있습니다.

4. 시간 및 비용 예산 책정 (Time and Cost Budgeting)

모든 에이전트 실행에는 시간 예산과 토큰 (token) 예산이 할당됩니다. 둘 중 하나라도 초과하면 에이전트는 결론에 도달하지 못했더라도 중단됩니다. 이는 "에이전트가 20분 동안 실행되었지만 아무런 유용한 결과도 내놓지 못하는" 실패 모드를 방지합니다.

MAX_DURATION_SECONDS = 120
MAX_TOKENS = 8000

...

내가 고생하며 배운 것들

이 이메일 사고는 제가 이제 모든 에이전트를 구축할 때 첫날부터 적용하는 세 가지 교훈을 가르쳐 주었습니다.

의사 결정 지점에서 크게 실패를 알리세요 (Fail loudly at decision points). 이 이메일 에이전트에는 신뢰도 임계값 (confidence threshold)이 있었습니다. 이 임계값보다 낮으면 사람에게 에스컬레이션 (escalate)하도록 되어 있었습니다. 임계값은 프롬프트 (prompt)에 존재했습니다. 하지만 모델은 화요일 아침에 이를 무시했는데, 아마도 쿼리 (query)의 문구 표현이 '자신감은 있지만 틀린' 경로를 유도했기 때문일 것입니다. 프롬프트는 계약 (contract)이 아닙니다. 중요한 비즈니스 로직은 모델의 통제 범위를 벗어난 곳에 하드코딩 (hard-code) 하세요.

도구 호출 (tool calls)과 결과 (outcomes)를 상관관계로 연결하세요. 이메일 도구는 47개의 이메일을 보냈다고 기록했습니다. 하지만 왜 하필 그 47개의 이메일을 선택했는지는 기록하지 않았습니다. 조사 결과, 에이전트가 오래된 데이터 (stale data)를 반환하는 쿼리를 사용하여 고객 리스트를 선택했다는 것을 발견했습니다. 도구 자체는 완벽하게 작동했습니다. 도구에 데이터를 공급하는 데이터 파이프라인 (data pipeline)이 고장 나 있었던 것입니다. 도구 호출을 그 직전의 쿼리와 연결하는 추적 컨텍스트 (trace context)가 없었다면, 저는 이메일 도구의 탓으로 돌렸을 것입니다.

당신의 평가 스위트 (eval suite)는 이를 잡아내지 못할 것입니다. 제 에이전트는 배포 전에 모든 평가 테스트를 통과했습니다. 평가 스위트는 모든 것이 제대로 작동할 때 에이전트가 작업을 올바르게 완료할 수 있는지 확인했습니다. 하지만 상류 (upstream) 데이터가 오래되었을 때, 모델의 신뢰도 보정 (confidence calibration)이 어긋났을 때, 또는 에이전트가 모호한 지시 사항을 만났을 때 어떤 일이 발생하는지는 확인하지 않았습니다. 운영 환경의 실패 모드 (failure modes)는 당신의 평가 스위트에 들어있지 않습니다. 그것은 관측성 (observability)을 통해 찾아내는 것입니다.

그 이메일 사고로 인해 허비한 3시간은 관측성 계층 (observability layer)을 추가하는 데 걸렸을 15분보다 더 많은 비용을 치르게 했습니다. 이것이 제가 계속해서 다시 배우고 있는 계산법입니다.

만약 당신이 AI 에이전트를 운영 환경 (production)에 출시하고 있으면서 추적 ID (trace IDs)를 로깅하고, 도구 호출 출력값을 검증하며, 완료 기준을 확인하고, 실행 시간 예산 (budgeting execution time)을 설정하고 있지 않다면 — 당신은 제가 했던 것과 똑같은 실험을 하고 있는 것이며, 제가 배운 것과 똑같은 교훈을 얻게 될 것입니다. 에이전트는 완료했다고 말할 것입니다. 하지만 실패했다고는 말해주지 않을 것입니다.

당신이 겪은 가장 고통스러운 운영 환경의 에이전트 실패 사례는 무엇인가요? 당신이 무엇을 배웠는지 듣고 싶습니다 — DEV.to에서 저를 찾거나 아래에 댓글을 남겨주세요.