요약: AI 에이전트가 프로덕션에 들어가면 기존 APM만으로는 원인을 찾기 어렵습니다. HTTP 200이 떠도 에이전트가 잘못된 도구를 골랐거나, 같은 루프를 반복했거나, 오래된 메모리를 근거로 답했을 수 있습니다. 2026년형 에이전트 운영의 핵심은 LLM 호출 로그가 아니라 tool call, state transition, memory operation, evaluation score를 한 trace 안에 묶는 것입니다.
일반 백엔드 서비스에서는 요청 수, latency, error rate, CPU, memory를 보면 많은 문제가 잡힙니다. 하지만 에이전트는 성공 응답 안에 실패가 숨어 있습니다. 모델이 틀린 도구를 호출해도 API는 200을 반환할 수 있습니다. 고객에게 그럴듯한 답변을 줬지만 실제 정책과 맞지 않을 수도 있습니다. 장기 세션에서는 초반 목표가 요약 과정에서 사라지는 일도 생깁니다.
Braintrust의 agent observability 글은 에이전트 관측성을 “도구 선택, 도구 인자, 모델 응답, 메모리 읽기와 쓰기, 상태 전환, 의사결정 분기를 캡처하는 것”으로 설명합니다. 이 정의가 중요한 이유는 명확합니다. 에이전트 실패는 한 줄 로그가 아니라 실행 경로 전체에서 발생합니다. 따라서 실행 경로를 span 단위로 재구성할 수 있어야 합니다.
처음부터 복잡한 플랫폼을 붙일 필요는 없습니다. 먼저 schema를 정하면 됩니다. 한 user request는 하나의 root trace가 됩니다. 그 아래에 LLM call span, tool call span, state transition span, memory operation span을 둡니다. 각 span에는 시작 시간, 종료 시간, 입력 요약, 출력 요약, error, retry count, parent span id를 넣습니다.
LLM call span에는 model, prompt version, input tokens, output tokens, reasoning 설정, temperature, structured output validation 결과를 남깁니다. tool call span에는 tool name, arguments, result status, latency, external side effect 여부를 남깁니다. state transition span에는 작업 상태가 어떻게 바뀌었는지 기록합니다. memory operation span에는 retrieval query, hit id, score, freshness, write 여부를 남깁니다.
첫 번째 실패는 wrong tool입니다. 사용자는 환불 정책을 물었는데 에이전트가 주문 취소 API를 호출하는 식입니다. 이 경우 tool call span을 보면 의도와 도구 선택이 어긋난 지점이 보입니다. 해결은 프롬프트 수정이 아니라 tool description, 권한 분리, 라우터 개선일 수 있습니다.
두 번째 실패는 bad argument입니다. 도구는 맞지만 인자가 틀립니다. 날짜 포맷, user id, currency, locale, 권한 범위가 흔한 원인입니다. structured output schema를 통과해도 업무 규칙에는 틀릴 수 있으므로 인자 검증기를 별도로 둬야 합니다.
세 번째 실패는 loop입니다. 에이전트가 같은 검색을 반복하거나 같은 오류를 고치지 못한 채 재시도합니다. trace에서 같은 tool name과 비슷한 arguments가 반복되면 바로 보입니다. 반복 횟수 제한과 “같은 실패 2회 발생 시 전략 변경” 같은 정책이 필요합니다.
네 번째 실패는 memory drift입니다. 오래된 메모리나 낮은 점수의 검색 결과를 근거로 답하는 문제입니다. memory operation span에 freshness와 score를 남기면 “모델이 왜 이 근거를 봤는지”를 추적할 수 있습니다. 일정 기간이 지난 메모리는 감점하거나, 중요한 정책 문서는 별도 authoritative source로 분리하는 편이 좋습니다.
에이전트 평가는 오프라인 데이터셋만으로는 부족합니다. 프로덕션 trace에서 실패 후보를 뽑아 eval suite로 되돌려야 합니다. 예를 들어 사용자가 thumbs down을 누른 trace, 도구 호출이 10회를 넘은 trace, validation이 실패한 trace, 상담원이 수동 개입한 trace를 자동으로 수집합니다. 이 샘플을 매주 50~100개씩 검토해 평가 세트에 추가하면 회귀 테스트가 점점 강해집니다.
평가 점수는 하나로 합치지 않는 편이 좋습니다. task success, faithfulness, tool correctness, argument validity, safety, latency, cost를 분리합니다. 평균 90점이라는 숫자는 현장에서 쓸모가 적습니다. “tool correctness는 98%인데 argument validity가 82%”처럼 나와야 개선 방향이 보입니다.
관측성을 강화하면 로그에 민감정보가 들어갈 위험도 커집니다. 프롬프트, 도구 인자, 메모리 검색 결과에는 이메일, 결제 정보, 내부 문서가 포함될 수 있습니다. 따라서 로그 저장 전 마스킹 규칙을 넣어야 합니다. 주민번호, 카드번호, access token, API key, 세션 쿠키는 저장하지 않는 것이 원칙입니다.
또한 외부 도구 호출은 side effect flag를 남겨야 합니다. 읽기 전용 검색과 실제 이메일 발송은 같은 tool call이 아닙니다. side effect가 있는 span은 별도 보존 기간, 승인자, 사용자 요청 근거를 함께 남겨야 감사가 가능합니다.
출처: Braintrust Agent observability guide, Coralogix Agentic AI observability article, Pydantic Logfire AI observability docs.
