AI 에이전트는 성공했다고 말하지만, 고객의 이메일은 다른 이야기를 합니다.

저는 지난 3개월 동안 소규모 AI 팀들의 프로덕션 로그 아카이브(production log archives) 14개를 읽었습니다. 매번 패턴은 동일했습니다. 대시보드는 초록색이고, 모델은 200 OK를 반환했으며, 도구는 "ok"라고 말하고

추론 루프 (Reasoning loops)가 더 길어졌습니다. 2024년의 에이전트는 35단계를 실행할 수 있습니다. 플래너-실행자 분리 (planner-executor split) 구조를 가진 2026년의 에이전트는 재시도 (retries)를 포함하여 2050단계를 실행합니다. 각 재시도는 "ok"라는 말이 미묘하게 다른 의미를 갖게 될 기회이며, 노이즈 속에서 원래의 의도 (intent)를 잃어버릴 기회이기도 합니다.

Sinch의 2026년 연구에 따르면, AI 고객 커뮤니케이션 에이전트의 74%가 최소 한 번 이상 롤백 (rolled back)되었습니다. 그리고 이러한 롤백 중 81%는 이미 관측성 (observability) 도구를 갖추고 있던 팀에서 발생했습니다. 롤백 비율의 격차(Forrester 조사 결과 9% 대 47%)는 팀이 결과 검증 계층 (outcome-assertion layer)을 추가했는지 여부와 직접적으로 일치합니다. 관측성 벤더가 핵심 레버가 아닙니다. 결과 라인을 읽는 인간의 규율 (human discipline)이 핵심입니다.

5가지 시그널 체크리스트 (브라우저 측면, 30초 소요)

에이전트가 표류 (drifting)하고 있는지 알기 위해 벤더가 필요하지는 않습니다. 마지막 50개의 로그 라인을 이 5가지 시그널 클래스를 찾는 채점기 (grader)에 붙여넣으세요. 4개 또는 5개를 확보했다면 에이전트가 적절히 계측 (instrumented)된 것입니다. 2개 이하를 확보했다면, '침묵하는 성공 (silent-success)' 표류 문제를 겪고 있는 것이며, 다음 프로덕션 변경 전에 이를 패치해야 합니다.

1. 의도 포착 (Intent capture). 에이전트가 도구 호출 (tool-calling)을 시작하기 전에 무엇을 하려고 했는지(사용자 요청, 목표, 작업)를 설명하는 라인이 있습니까? 이것이 없다면, 에이전트가 실패했을 때 무엇을 생각하고 있었는지 재구성할 수 없습니다. 좋은 예시: agent.intent task_id=tg_4471 request_summary="send invoice reminder".

2. 도구 호출 결과 (Tool-call outcome). 각 도구 호출이 단순히 "ok"나 "done"이 아니라, 실제 응답 본문 (response body) / 상태 코드 (status code) / 부수 효과 (side-effect)를 기록합니까? "ok"는 '침묵하는 성공'을 유발하는 제1의 요인입니다. 실제 결과는 함수가 반환한 것이 아니라, 세상이 실제로 수행한 것입니다. 좋은 예시: tool.send_email status=202 provider_id=01HXX... latency_ms=412.

3. 재시도 폭풍 (Retry-storm) 형태. 중간에 어설션 라인 (assertion line) 없이 동일한 호출이 2회 이상 연속으로 나타나나요? 그것이 바로 재시도 폭풍 (retry storm)입니다. 해결책은 더 나은 재시도 로직을 만드는 것이 아니라, _재시도 여부_를 결정하는 어설션 라인을 두는 것입니다. 동일한 파라미터로 이메일 전송을 4번 재시도하면, 동일한 다운스트림 버그 (downstream bug)에 4번 부딪히게 되고 결국 4통의 이메일이 조용히 발송됩니다.

4. 결과 어설션 라인 (Outcome-assertion line). 부수 효과 (side-effect)를 일으키는 호출 이후에, 예상값과 실제값을 비교하는 라인이 있습니까? assert status_code == 200은 조용한 성공 (silent-success)에 맞서는 가장 저렴한 방어책입니다. DB에 1개의 행이 예상되었으나, 0개가 검색됨과 같은 라인은 3일간 지속될 고객 에스컬레이션 (escalation)을 30초짜리 페이저 알람 (pager alert)으로 바꿔줍니다.

5. 부수 효과 (Side-effect) vs 완료 타임스탬프 (completion timestamp). 에이전트가 "완료"되었다고 보고했을 때, 실제 부수 효과 (이메일 발송, 행 기록, 결제 완료 등)가 동일한 시간에 발생했습니까? 90초의 간격이 있다면 대개 부수 효과가 버퍼링되었으며 조용히 실패했을 가능성이 높습니다. 즉, 에이전트의 "완료" 라인이 세상의 시계와는 다른 시계에서 실행된 것입니다.

만약 이 중 2개 이상이 누락되었다면, 당신은 조용한 성공 드리프트 (silent-success drift) 문제를 겪고 있는 것입니다. 좋은 소식은 각 항목이 5~10줄 정도의 코드 변경만으로 해결 가능하다는 점입니다. 나쁜 소식은, 프로덕션 환경에서 어떤 항목이 실패하고 있는지 알기 위해 실제 로그 아카이브 (log archive)에서 누락된 신호를 직접 읽어야 한다는 점입니다.

30초 셀프 감사 (Self-audit)

사용자가 붙여넣은 로그 텍스트를 대상으로 5가지 신호 체크리스트를 실행하는 무료 브라우저 기반 채점기를 만들었습니다. 설치도, 가입도 필요 없으며, 로그 텍스트가 서버로 전송되지도 않습니다. 점수와 5가지 체크 항목은 모두 브라우저 내에서 로컬로 실행됩니다. 당신은 A-F 등급과 누락된 특정 신호들을 받게 됩니다. 한 페이지 분량의 보고서를 이메일로 받고 싶다면 옵션을 선택할 수 있습니다 (이메일 필드 하나만 필요하며, 다른 개인정보(PII)는 요구하지 않습니다).

AI 에이전트 조용한 실패 셀프 감사 실행하기 →

약 30초 정도 소요됩니다. 붙여넣고, 클릭하면, 등급을 받을 수 있습니다. 만약 D 또는 F 등급을 받았다면, 해당 페이지는 각 시그널(signal)별로 처방적인 수정 목록(prescriptive fix list)을 안내합니다. 만약 사람이 직접 전체 프로덕션 로그 아카이브(production log archive)를 읽고 고객에게 영향을 미치는 구체적인 드리프트 패턴(drift patterns)을 찾아내길 원한다면, 유료 AI Ops Checkup에서 적용하는 것과 동일한 5가지 시그널 체크리스트를 사용하게 됩니다. 다만, 이는 50줄짜리 샘플이 아닌 실제 트래픽에 적용됩니다.

등급을 받은 후 해야 할 일

A 또는 B를 받았다면: 이미 모니터링(instrumented)이 잘 되어 있는 상태입니다. 다음에 살펴봐야 할 것은 *비용(cost)*입니다. 모니터링이 잘 된 팀이라도 대부분의 LLM 지출 중 30~60%는 조용한 토큰 낭비 형태(에러가 발생하지 않는 재시도 폭풍(retry storms), 사고의 함정(thinking traps), 컨텍스트 스터핑(context stuffing), 에이전트-오브-에이전트 팬아웃(agent-of-agents fanout))로 인해 누수되고 있습니다. LLM Bill Triage는 귀하의 토큰 지출에 적용되는 동일한 종류의 포렌식 분석(forensic read)입니다.

C를 받았다면: 누락된 시그널 하나를 선택하여 이번 주 내로 수정을 배포하고, 다시 등급을 매기세요. 세 가지를 한꺼번에 고치려고 하지 마세요.

D 또는 F를 받았다면: 대시보드가 거짓말을 하고 있는 것입니다. 누락된 시그널을 배포할 때까지 다음 프로덕션 변경을 차단하거나, 사람이 로그를 읽고 어떤 구체적인 드리프트가 고객에게 영향을 미치고 있는지 알려주도록 고용하십시오. 엔지니어링 시간이 있다면 첫 번째 옵션이 더 저렴합니다. 시간이 없다면 두 번째 옵션이 더 빠릅니다.

이것이 아닌 것

이것은 LangSmith/Langfuse/Helicone과의 비교가 아닙니다. 그것들은 인프라(infrastructure)이며, 호출 엔벨로프(call envelope)를 기록합니다. 그것들은 세상이 의도(intent)와 일치했는지 여부를 알려주지 않습니다. 그것은 벤더 계층(vendor layer)이 아닌 사람이 읽는 계층(human-read layer)의 영역이며

침묵의 성공(silent-success) 사례를 실제로 줄이는 가장 빠른 방법은 지루합니다. 놓치고 있는 12개의 시그널(signal)을 선택하고, 시그널당 510줄의 코드를 배포하며, 온콜(on-call) 순번 작업에 주간 10분간의 트레이스(trace) 리뷰를 추가하는 것입니다. 그게 전부입니다. 벤더(vendor)도 필요 없고, 플랫폼 재구축(re-platform)도 필요 없으며, RAG 재작업(rework)도 필요 없습니다.

— Milo Antaeus

이미 200개 이상의 로그 샘플에서 실행 중인 5-시그널 평가기(5-signal grader)를 구축했습니다. 30초 만에 무료로 체험해 보세요, 가입 불필요.