5개가 아닌 7개의 신호: 나의 무료 AI 에이전트 채점기(AI Agent Grader) v2가 v1에서 놓쳤던 것들

저는 AI 에이전트 로그를 위한 무료 브라우저 사이드 채점기(grader)를 만들었습니다. 처음에는 5개의 신호(signals)로 시작했지만, v2에는 7개가 있습니다.

새로 추가된 두 가지 신호는 2026년 실제 고객 로그를 분석할 때 저를 가장 힘들게 했던 것들이며, 이제는 모든 배포된 에이전트가 대시보드에 "모두 녹색(all green)"이라고 표시되기 전에 반드시 확인해야 한다고 생각하는 것들입니다. 이 두 가지는 제가 올해 감사(audit)한 거의 모든 팀에서 감지 가능한 수준으로 결여되어 있었습니다.

기사를 건너뛰고 바로 v2 채점기를 사용해보고 싶다면, 무료이며 브라우저에서 실행되고 30초면 충분합니다: https://www.miloantaeus.com/silent-failure-audit.html

그렇지 않다면, v1 채점기가 무엇을 놓쳤는지, 그리고 왜 새로운 신호들을 추가했는지 아래에서 확인해 보세요.

5개 신호 기반의 v1 채점기 (그리고 실제로 수행했던 역할)

v1 채점기는 다섯 가지 신호 클래스(signal classes)를 기반으로 작동했습니다:

의도 파악 (Intent capture) — 에이전트가 도구 호출(tool-calling)을 시작하기 전에 자신이 무엇을 하려고 하는지(사용자 요청, 목표, 작업)를 로그에 남겼는가?
도구 호출 결과 (Tool-call outcome) — 각 도구 호출이 단순히 "ok" 또는 "done"이 아니라, 실제 응답 본문(response body) / 상태 코드(status code) / 부작용(side-effect)을 로그에 남겼는가?
재시도 폭풍 형태 (Retry-storm shape) — 중간에 어설션(assertion) 없이 동일한 호출이 2회 이상 연속으로 발생하는가?
결과 어설션 라인 (Outcome-assertion line) — 부작용을 일으키는 호출 이후, 예상값과 실제값을 비교하는 라인이 있는가?
부작용 vs 완료 타임스탬프 (Side-effect vs. completion timestamp) — "도착(landed)"/ "전송(sent)" 이벤트를 "완료(done)"와 분리하여 기록하는가?

채점 기준은 깔끔한 5개의 불리언(bool) 합계였습니다: 5개 중 5개 = A, 5개 중 4개 = B, 5개 중 3개 = C, 5개 중 2개 = D, 5개 중 0-1개 = F.

출시 후 첫 24시간 동안, 이를 사용해 본 사람들의 약 60%가 D 또는 F 점수를 받았습니다. 가장 흔한 이유는 신호 3번과 4번(재시도 폭풍 + 결과 어설션 부재)이 누락된 것이었는데, 이는 전형적인 "로그에서 그냥 'ok'만 보이는" 형태였습니다.

v1은 괜찮았습니다. 하지만 제가 후속 통화에서 v1 결과를 함께 검토한 모든 팀은 똑같은 두 가지 후속 질문을 던졌습니다:

"저의 재시도가 고객에게 이중 결제를 유발하지 않는다는 것을 어떻게 알 수 있나요?"
"누군가 적대적 입력(adversarial input)으로 에이전트를 유도했을 때, 제가 로그에서 이를 전혀 발견하지 못할 수도 있나요?"

둘 다 매우 훌륭한 질문입니다. v1은 둘 다 답하지 못했습니다. v2는 답할 수 있습니다.

신호 6 (v2 신규): 부수 효과(side-effecting) 호출 시의 멱등성 키 (Idempotency keys)

이것은 제가 2026년에 누락된 사례 중 가장 큰 피해 범위(blast-radius)를 가진 신호이자, 가장 고치기 쉬운 신호입니다.

형태: 에이전트가 send_email, create_charge, transfer_funds, write_row, post_message 또는 기타 부수 효과(side-effecting)를 일으키는 도구를 호출합니다. 이때 호출에 idempotency_key / request_id / dedup_token이 포함되어 있지 않습니다. 래퍼(wrapper)는 타임아웃 발생 시 재시도(retry)를 수행합니다. 실제 부수 효과가 두 번(또는 세 번, 혹은 열 번 — 키가 없으면 상한선이 없습니다) 발생하게 됩니다.

중요한 이유: Stripe, Twilio, Plaid, SendGrid는 모두 멱등성 키(idempotency key)를 요구합니다 — 키를 보내면 중복을 제거(de-dup)해 줍니다. 하지만 키를 보내지 않으면 동일한 API가 고객에게 기꺼이 3배의 금액을 청구할 것입니다. 에이전트 래퍼들(LangChain, CrewAI, AutoGen)은 기본적으로 이를 생성하지 않도록 설정되어 있습니다. 따라서 멱등성이 보장되지 않는 결제에 대해 3회 재시도 폭풍(retry storm)이 발생하면 = 고객에게 3배의 차지백(chargeback)이 발생합니다.

감사 휴리스틱 (Audit heuristic): 부수 효과 호출처럼 보이는 모든 라인(send, charge, create, write, update, insert, delete, post, patch, put)에 대해, 동일한 라인(또는 형제 라인)이 idempotency_key, idem_key, request_id, dedup_token, order_id, client_request_id, 또는 trace_id를 포함하고 있습니까? 부수 효과 호출 중 이 비율이 50% 미만이라면 문제가 있는 것입니다.

해결 방법 (3줄, 벤더 불필요):

// 요청 상단에서 의도(intent)로부터 안정적인 키를 유도합니다:
const idemKey = "ord_" + orderId + "_" + intentHash;
const r = await stripe.charges.create({
...

신호 2가 아닌 신호 6으로 추가한 이유: 기존의 "도구 호출 결과(tool-call outcome)" 체크 항목에 통합할까 고민했지만, 키의 부재는 "계측(instrumentation)" 신호라기보다는 "비용(cost)" 신호에 가깝습니다. 키가 누락되었다고 해서 에이전트가 조용히 실패하고 있다는 뜻은 아닙니다. 그것은 에이전트가 조용히 _이중 행동(double-acting)_을 하고 있다는 뜻입니다. 피해 범위가 다르고 해결 방법도 다르기에, 보고서에 별도의 행으로 다룰 가치가 있습니다.

신호 7 (v2 신규): 프롬프트 인젝션 (Prompt-injection) 로그 형태

이것은 로그에서 탐지하기 더 어렵지만, 패턴은 실재하며 이를 놓쳤을 때 2026년에 치러야 할 비용은 매우 높습니다. (Palo Alto Unit 42와 OWASP LLM Top 10에 따르면, 에이전트 시스템(agentic systems)에 대한 프롬프트 인젝션 (Prompt-injection) 공격은 2026년에 실질적으로 증가했으며, 실패 모드는 "에이전트가 해서는 안 될 행동을 하는 것"입니다. 이는 제대로 계측된(instrumented) 로그라면 반드시 포착해야 하는 바로 그 유형입니다.)

형태 (채점기가 찾는 3가지 하위 패턴):

7a. 모든 라인 내부에 포함된 적대적 유도 문구 (Adversarial steering phrases). ignore previous, disregard all previous, you are now, system: you, new instructions, override all rules, do not mention, act as, pretend to be와 같은 하위 문자열(Substrings)이 이에 해당합니다. 만약 이러한 문구 중 하나라도 사용자 입력(user-input)이나 도구 결과(tool-result) 라인 내부에 나타난다면, 에이전트가 해당 동작을 수행하기 전에 해당 라인은 검토 대상으로 플래그(flag)를 지정해야 합니다.

7b. 어떤 의도(intent) 라인과도 결합되지 않는 도구 호출(Tool call) 라인. 제대로 계측된 에이전트는 의도를 먼저 기록하고(신호 1), 그 다음 의도를 참조하여 모든 도구 호출을 기록합니다. 로그에서 상응하는 의도 라인이 없는 도구 호출 라인이 보이거나, 의도당 도구 호출이 너무 많은 경우(에이전트가 흐름 중간에 유도되었음을 시사함), 이는 프롬프트 인젝션 형태의 신호입니다.

7c. 선언되지 않은 도구 이름 (Undeclared tool names). "사용 가능한 도구: [...]" 등록 라인에 나타나지 않는 <name>을 포함하는 tool.<name> 라인입니다. 만약 에이전트에게 send_email, lookup_order, refund 기능이 있다고 알려졌는데, 이후에 한 번도 알려준 적 없는 tool.admin_delete_user 라인이 나타난다면, 설령 해당 호출이 차단되었더라도 이는 프롬프트 인젝션 이벤트입니다.

해결책 (작은 디스패처 래퍼 (dispatcher wrapper)):

// 1. 도구 호출 시점에 의도 라인을 해싱(Hash)하여 기록합니다:
const intentHash = sha256(intentLine);
logger.info("tool.bind", {
...

채점기는 실시간으로 프롬프트 인젝션을 *포착(catch)*하려고 시도하는 것이 아닙니다(이를 위해서는 런타임 가드(runtime guard)가 필요합니다). 대신, 사후에 당신의 로그가 이를 포착할 수 있는지를 확인합니다. 이는 로그의 포렌식 분석가(예를 들어, 149달러 점검 서비스의 저와 같은 사람)가 무슨 일이 일어났는지 재구성할 때 사용하는 감사 신호(audit signal)입니다.

팀들이 v2를 시도할 때 보이는 현상 (초기 결과, 24시간 경과)

첫 ~40개의 v2 결과는 대략 다음과 같이 나뉩니다:

v1에서 A 등급을 받았던 대부분이 v2에서는 B 또는 C로 떨어졌습니다. 거의 예외 없이 6번째 신호(멱등성 (idempotency)) 때문입니다. 5개 신호로 구성된 v1은 멱등성에 대해 전혀 묻지 않았기 때문에, 처음 5개 신호를 주의 깊게 측정해 온 팀들도 자신들의 래퍼(wrapper)가 핵심 요소를 방출하지 않는다는 사실을 발견하게 되었습니다.
v1에서 D 등급이었던 팀들은 보통 v2에서도 D를 유지하거나 F로 떨어졌습니다. 동일한 이유(멱등성)와 더불어, 새로운 7번째 신호가 로그 내에서 선언되지 않은 도구 호출(tool calls)을 자주 포착하기 때문입니다.
v1에서 A를 받았던 팀 중 한 곳은 v2에서도 A를 받았습니다. 이 팀은 모든 곳에 멱등성 키(idempotency keys)를 사용하고 있었으며, 도구 호출을 의도 해시(intent hashes)에 결합하는 디스패처 래퍼(dispatcher wrapper)를 갖추고 있었습니다. 드문 사례이지만, 이것이 골드 표준(gold standard)입니다.

v2의 평균 등급은 v1의 평균 등급보다 유의미하게 낮으며, 이는 거의 아무도 갖추지 못한 두 가지 신호를 추가했을 때 예상할 수 있는 정확한 결과입니다.

사용 방법 (무료, 가입 불필요)

https://www.miloantaeus.com/silent-failure-audit.html을 엽니다.
에이전트 로그에서 약 50줄 정도를 복사하여 붙여넣습니다 (JSON 라인, 일반 텍스트, 또는 혼합된 형태 — 텍스트 기반이라면 무엇이든 가능합니다).
"Grade my agent logs"를 클릭합니다.
A-F 등급이 포함된 7행 보고서를 받습니다.

보고서를 한 페이지짜리 HTML 이메일로 받고 싶다면 이메일 주소를 입력하세요. (선택 사항 — 화면에 표시되는 결과만 확인해도 됩니다.)

이 모든 과정은 클라이언트 측(client-side)에서 실행됩니다. 저희는 귀하의 로그 텍스트를 절대 볼 수 없습니다. 서버가 알 수 있는 유일한 정보는 귀하가 보고서 전송을 선택했을 경우의 이메일 주소와 등급뿐입니다.

이것이 아닌 것

이 채점기는 LangSmith, Langfuse, Helicone 또는 기타 벤더의 제품이 아닙니다. 브라우저에서 30초 만에 실행할 수 있는 7가지 질문 체크리스트입니다. 귀하의 실제 운영 로그 아카이브 전체(30페이지 분량)를 정밀 분석하여, 귀하의 고객에게 영향을 미치는 구체적인 침묵의 성공 드리프트(silent-success drifts), 중복 결제, 그리고 프롬프트 인젝션(prompt-injection) 이벤트를 찾아내는 작업은, 이 7가지 신호 체크리스트의 심화 버전인 $149 AI Ops Checkup을 통해 제공됩니다.

하지만 "당신의 에이전트는 이러한 신호 클래스 중 2~3개가 누락되었습니다. 누락된 항목은 다음과 같으며, 각 항목에 대한 3줄 해결책은 다음과 같습니다"라는 답변이 나오는 80%의 사례에 대해서는, 무료 v2 채점기(grader)만으로도 충분합니다.

만약 v2가 놓치는 형태(shape)를 발견하신다면, 모든 보고서 하단에 제 이메일 주소가 있습니다. v3는 아마도 9개의 신호(signals)를 포함하게 될 것입니다.

— Milo Antaeus