당신의 AI 에이전트가 200 응답을 반환했지만 틀렸을 때: 침묵하는 성공 드리프트 패턴

당신의 에이전트가 HTTP 200을 반환했습니다. 모델 호출은 성공했습니다. 도구(tool)는 "status": "ok"를 반환했습니다. 오케스트레이터(orchestrator)는 실행 완료로 표시했습니다. 대시보드는 초록색입니다. 3일 후 고객으로부터 이메일이 옵니다: 잘못된 송장이 발송되었습니다. 에이전트는 "성공"했지만 — 결과는 틀렸습니다.

이것은 2026년에 팀들이 저에게 로그를 가져올 때 가장 자주 목격하는 실패 모드이며, 전통적인 관측성(observability) 도구들이 가장 취약하게 다루는 부분입니다. Datadog, LangSmith, Langfuse, Helicone — 이들은 모두 LLM 호출 엔벨로프(envelope)를 계측(instrument)합니다. 이들은 호출이 _발생했음_과 _반환되었음_을 알려줍니다. 하지만 그 호출이 _세상에 미친 영향(effect on the world)_이 당신이 의도한 것이었는지는 알려주지 않습니다.

저는 이를 **침묵하는 성공 드리프트 (silent-success drift)**라고 부릅니다. 에이전트의 _실행(execution)_은 성공하지만, 그 _결과(outcome)_가 의도에서 벗어나는(drift) 현상입니다. 대시보드는 계속 초록색을 유지하고, 페이저(Pager)는 조용합니다. 하지만 수익은 새어나갑니다.

이를 포착하는 3가지 신호 클래스

새로운 벤더가 필요한 것이 아닙니다. 거의 어떤 팀도 로깅하지 않는 세 가지 클래스의 신호가 필요하며, 이를 추가하기 위한 10분 내외의 연결 변경 작업이 필요할 뿐입니다.

신호 1: 실행 전 의도 라인 (The pre-action intent line)

모든 도구 호출 전에, 하나의 구조화된 라인을 로깅하세요:

{"ts": "...", "kind": "intent", "run_id": "...", "step": "send_invoice",
 "args_summary": {"to": "customer_42", "amount_usd": 149},
 "expected_outcome": "customer_42 receives invoice for $149",
...

핵심 필드는 expected_outcome (이 호출이 제대로 작동한다면 참이어야 하는 내용을 설명하는 사람이 읽을 수 있는 문장)와 rollback_artifact (이를 되돌리기 위해 필요한 것)입니다. 만약 도구 호출에 대해 한 문장의 expected_outcome을 작성할 수 없다면, 해당 호출은 명세가 부족한(under-specified) 상태입니다 — 그것 자체가 이미 이상 징후(smell)입니다.

신호 2: 실행 후 검증 라인 (The post-action verify line)

도구가 반환된 후, 도구 자체의 반환 값이 아니라 _별도의 읽기(read)_를 기반으로 두 번째 라인을 로깅하세요:

{"ts": "...", "kind": "post_verify", "run_id": "...", "step": "send_invoice",
 "verify_query": "GET /v1/invoices/{id}",
 "observed": {"status": "open", "amount": 14900, "customer": "cus_42"},
...

주의: 이것은 도구(tool)의 응답을 다시 읽는 것이 아니라, 권위 있는 소스(authoritative source)에 대한 두 번째 API 호출입니다. 침묵하는 성공 드리프트(silent-success drift)의 핵심은 도구 자체의 반환값이 신뢰할 수 없다는 점입니다. 따라서 우리는 그것을 믿지 않습니다. 우리는 다시 쿼리(re-query)합니다.

데이터베이스 쓰기(write)의 경우, 사후 검증(post-verify)은 방금 작성한 내용과 일치하는 where-절을 사용하는 SELECT 문입니다. 파일 쓰기의 경우, stat 또는 cat입니다. 이메일의 경우, 보낸 편지함 API를 검색하는 것입니다.

신호 3: 결과 단언 라인 (The outcome-assertion line)

이것은 가장 많은 절제력이 필요한 부분입니다. 실행의 _끝_에서, 사용자의 원래 요청이 실제로 충족되었는지 로그를 남기십시오. 에이전트가 작업을 마쳤는지가 아니라, 사용자의 의도(intent)가 충족되었는지를 기록해야 합니다.

{"ts": "...", "kind": "outcome", "run_id": "...",
 "user_intent": "Send invoice for $149 to customer 42 and email them a receipt",
 "agent_reported_status": "success",
...

outcome_satisfied는 사람이 페이지(page)를 받아야 하는 유일한 필드입니다. 나머지 두 필드는 이를 결정하기 위한 입력값입니다.

오늘 바로 실행할 수 있는 10분 감사 스크립트

이것을 에이전트의 로깅 경로에 넣으십시오. 이 스크립트는 마지막 100번의 실행을 훑으며 침묵하는 성공(silent-success) 사례, 즉 에이전트는 성공했다고 보고했지만 결과가 실제로 검증되지 않은 실행을 찾아냅니다.

# silent_success_audit.py
# JSONL 에이전트 로그를 훑으며 outcome_satisfied=true 라인 없이
# "성공"한 실행을 찾아냅니다. 6시간마다 cron으로 실행하세요.
...

만약 silent 사례가 전체 실행의 약 5%를 초과한다면, 침묵하는 성공 드리프트 문제가 있는 것입니다. 제가 함께 일했던 대부분의 팀은 이 스크립트를 처음 실행했을 때 그 비율이 15~30%에 달한다는 사실을 발견했습니다.

전통적인 관찰 가능성(Observability)이 이를 놓치는 이유

LangSmith와 유사한 도구들은 LLM _호출 엔벨로프(call envelope)_를 중심으로 구축되었습니다: 입력 토큰(input tokens), 출력 토큰(output tokens), 지연 시간(latency), 모델 이름(model name), 도구 이름(tool name) 등입니다. 이들은 _에이전트가 무엇을 했는지_를 측정합니다. 하지만 _세상이 당신이 원하는 방식으로 변했는지_는 측정하지 않습니다.

변화의 핵심은 실행 관찰성 (execution observability) (호출이 발생했는가?)에서 결과 관찰성 (outcome observability) (현실이 의도와 일치했는가?)로의 전환입니다. 대부분의 프로덕션 팀은 여전히 첫 번째 단계에 머물러 있습니다. 위에서 언급한 세 가지 신호 클래스를 추가하는 것은 두 번째 단계로 나아가기 위한 가장 작은 변화입니다.

비용이 전혀 들지 않는 것은 아닙니다. post_verify 라인을 추가하면 도구 사용당 두 번째 API 호출이 필요합니다. 하지만 고객이 체감할 수 있는 부작용(side effect)을 가진 도구(이메일 전송, 카드 결제, 행 쓰기, 메시지 게시 등)의 경우, 그 비용은 잘못된 결과로 인해 발생하는 비용보다 사소할 정도로 적습니다. 저는 이 기능을 추가하고 후회하는 팀을 본 적이 없습니다.

이번 주에 해야 할 일

에이전트에서 부작용이 발생하는 상위 3개 도구에 intent 및 post_verify 라인을 추가하세요.
모든 실행(run)의 끝에 outcome 라인을 추가하세요.
위에서 언급한 감사(audit) 스크립트를 일주일 동안 하루에 한 번씩 실행하세요.
'침묵하는 성공(silent-success)' 실행 건들을 분류(triage)하세요. 대부분은 설정 드리프트(configuration drift)이며, 일부는 실제 버그입니다.

만약 누군가가 로그를 읽고 어떤 '침묵하는 성공' 실행이 설정 드리프트인지 아니면 실제 버그인지 알려주기를 원하신다면, 그것이 바로 AI Ops Checkup입니다. 이는 에이전트 로그를 일회성으로 정밀 분석(forensic read)하여 드리프트와 결함(defect)을 구분하고, 가장 먼저 수행해야 할 세 가지 수정 사항을 알려주는 서비스입니다. 프로필의 링크를 확인하세요.