7개가 아닌 9개의 신호: 나의 무료 AI 에이전트 Grader v3가 v2에서 놓쳤던 것들

내가 감사(audit)한 19개의 LLM 청구서 중 60%가 동일한 4가지 비용 형태를 가지고 있다는 것을 발견했습니다. 무료 브라우저 사이드(browser-side) 에이전트 로그 Grader v2는 이 4가지 중 2가지만 잡아냈습니다. 나머지 2가지는 놓쳤으며, 바로 그 나머지 2가지가 지난달 당신의 청구서가 4배나 급증한 이유입니다.

몇 주 전, 나는 AI 에이전트 로그를 위한 무료 브라우저 사이드 Grader를 출시했습니다. 마지막 50줄의 로그를 붙여넣으면, 건강한 에이전트와 '침묵하는 성공(silent-success)' 에이전트를 구분하는 신호 클래스(signal classes)에 대해 A-F 등급을 받을 수 있습니다. v1에는 5개의 신호가 있었습니다. v2에서는 2개(idempotency-key 부재 및 프롬프트 인젝션(prompt-injection) 로그 형태)를 추가했습니다. 두 버전 모두 이를 사용하는 팀들로부터 동일한 피드백을 받고 있습니다: 2026년의 가장 큰 파급 효과(blast-radius)를 가진 실패 모드(failure modes)는 대시보드에 나타나는 실패 모드가 아닙니다.

그래서 v3에서는 2개를 더 추가합니다. 신호 8과 9는 현재 2026년의 반복되는 헤드라인이 된 5,000달러에서 50,000달러 사이의 LLM 청구서 깜짝 놀랄 만한 비용 발생(Vantage, Microsoft, Tom's Hardware, "tokenmaxxing" 안티 패턴)의 주요 원인입니다. v2 Grader가 이를 놓친 유일한 이유는 이들이 단일 로그 라인에 나타나지 않고, 로그 라인 사이의 '간극(gap)'에 나타나기 때문입니다.

이 포스트는 v3의 롱폼(long-form) 출시 게시물입니다. 무료 도구는 푸터(footer)에 있으며, 이 기사는 내가 이를 작성하며 배운 모든 것을 담고 있습니다.

v2가 이미 다루었던 7가지 신호 (요약)

만약 v1과 v2를 놓쳤다면, 여기 30초 요약 버전이 있습니다. "침묵하는 실패(silent failure)"란 에이전트의 대시보드는 초록색(정상)을 나타내지만, 고객의 인보이스(invoice)는 그렇지 않은 경우를 말합니다. v2는 당신의 마지막 50개 로그 라인으로부터 7가지 신호 클래스를 채점했습니다:

의도 파악 (Intent capture) — 도구 호출 (tool call)이 발생하기 전, 로그에 사용자가 요청한 내용이 사용자의 언어로 기록되어 있는가?
도구 호출 결과 (Tool-call outcome, 단순한 "ok"가 아닌 실제 응답) — 로그에 단순히 HTTP 200만 기록되는 것이 아니라, 실제 응답 본문 (response body)이 기록되어 있는가?
재시도 폭풍 형태 (Retry-storm shape) — 동일한 의도에 대해 동일한 도구가 3회 이상 호출되는 모습이 로그에 나타나는가?
결과 확인 라인 (Outcome-assertion line) — 도구 호출과는 별개로, "부수 효과 (side-effect)가 반영되었는가?"를 확인하는 명시적인 체크 항목이 있는가?
부수 효과 vs 완료 타임스탬프 드리프트 (Side-effect vs. completion timestamp drift) — 로그가 "API 호출을 수행함"과 "API 호출이 완료되어 상태가 변경됨"을 구분하여 기록하는가?
부수 효과를 일으키는 호출에서의 멱등성 키 (Idempotency keys on side-effecting calls) — 모든 Stripe / Twilio / Plaid / SendGrid / Slack 호출에 재시도 시 중복 결제를 방지하기 위한 키가 포함되어 있는가?
프롬프트 인젝션 (Prompt-injection) 로그 형태 — 3가지 하위 패턴(오버라이드 시도, 시스템 프롬프트 유출, 신뢰할 수 없는 데이터를 명령어로 사용)이 로그에서 플래그(flag) 처리되는가?

대부분의 팀은 특히 6번과 7번 신호에서 D 또는 F 학점을 받습니다. 이들은 2026년에 폭발적인 피해 범위 (high-blast-radius)를 가질 격차들입니다.

v3는 8번과 9번을 추가합니다. 두 가지 모두 정확도 형태 (correctness-shape)의 신호가 아니라, 비용 형태 (cost-shape)의 신호입니다. 그것이 핵심입니다.

신호 8: 결과당 비용 (Cost-per-outcome, 당신의 대시보드에는 표시되지 않는 것)

증상: 월간 OpenAI / Anthropic 청구액이 2배에서 10배로 급증합니다. 특정 실행 건을 지목할 수 없습니다. 대시보드의 "태스크당 (per-task)" 위젯은 유용한 정보를 보여주지 못합니다.

v2가 놓친 이유: v2는 로그 라인의 "존재 여부"를 확인했습니다. 결과당 비용은 "라인당 메트릭 (metric per line)"입니다. 각 태스크에 대해 tokens_in / tokens_out / cost_usd를 계산해야 하며, 이것이 로그에 기록되고 있는지 확인해야 합니다. 로그에 이 메트릭이 포함되어 있지 않다면, 통제 불능 상태를 감지할 수 없으며 청구서가 나온 후에야 감지할 수 있을 뿐입니다.

감지 규칙 (3개 라인):

# 모든 LLM 호출 래퍼 (wrapper)에 추가, 호출을 수행하기 전에:
def wrapped_llm_call(prompt, model, **kwargs):
    t0 = time.perf_counter()
...

만약 로그의 모든 LLM 호출에 이 네 가지 필드가 포함되어 있지 않다면, v3 grader는 이를 플래그(flag)로 표시합니다. 해결책은 래퍼(wrapper)를 사용하는 것입니다. 그 효과는 가시성(visibility)입니다. 이를 배포하고 일주일 이내에 당신은 다음과 같은 '조용한 승수(silent multipliers)'를 목격하게 될 것입니다: 실패하지 않았지만 3배의 재시도(retry)가 발생한 경우, 8배의 토큰을 소모한 사고 과정(thinking-trap), 그리고 결과값이 컨텍스트(context)를 18K 토큰만큼 팽창시킨 도구 호출(tool call) 등이 그것입니다.

이것이 2026년 토큰 비용 폭탄의 주요 원인인 이유: 2026년 5월 23일자 Tom's Hardware 기사는 "tokenmaxxing"을 2026년의 안티 패턴(anti-pattern)으로 지목했습니다. 그 이유는 토큰당 가격이 2년 동안 하락했기 때문에, 모든 비용 증가는 토큰당 가격의 상승이 아니라 *태스크당 토큰 사용량(tokens-per-task)*의 증가이기 때문입니다. 로그에 태스크당 비용이 없다면, 당신은 비용 총액만 볼 수 있을 뿐 그 배수(multiplier)를 확인할 수 없습니다.

신호 9: 컨텍스트 채우기 (Context-stuffing) (v1/v2에서는 말 그대로 볼 수 없었던 것)

증상: 작업량은 동일함. 모델도 동일함. 하지만 비용은 4배. 로그에는 "에이전트가 1개의 태스크를 실행함"이라고 기록되어 있음 — 그러나 해당 태스크의 프롬프트(prompt)에는 28K 토큰 분량의 오래된 도구 출력값(stale tool output)이 포함되어 있었고, 그 28K 토큰 중 6개는 동일한 청크(chunk)가 3번 반복된 것이었음.

v2가 이를 놓친 이유: v2는 라인(line) 단위였습니다. 컨텍스트 채우기(Context-stuffing)는 길이(length) 신호입니다. 로그에서 각 messages / context / history 라인의 크기를 확인해야 하며, 20K 자(chars)를 초과하여 팽창하거나 동일한 라인 내에서 특정 청크가 3회 이상 반복되는 라인을 플래그로 표시해야 합니다.

탐지 규칙 (마찬가지로 3줄):

# cost_usd 바로 뒤, 동일한 로그 라인에 추가:
def log_context_size(call_id, messages):
    text = json.dumps(messages, separators=(",", ":"))
...

이것이 조용한 살인자인 이유: LangChain, CrewAI, 그리고 AutoGen은 모두 모든 재시도(retry) 시 전체 도구 결과(full tool result)를 다시 첨부하는 것을 기본값으로 합니다. 따라서 신호 3(재시도 폭풍, retry-storm)이 누락되어 루프 내에서 3번 호출된 8K 데이터 반환 도구는, 4번째 호출 시 24K의 중복 컨텍스트가 됩니다. 그리고 고객에게 비용을 청구할지 결정하는 것은 바로 그 4번째 호출입니다. 비용 승수는 단일하고 정상적인 호출처럼 보이는 것 안에 숨겨져 있습니다.

저는 지난 90일 동안 19개의 소규모 팀 LLM 청구서를 감사했습니다. 19개 중 17개에서 지출의 60% 이상이 다음 4가지 형태 중 하나에 집중되어 있었습니다: 조용한 재시도 폭풍 (silent retry storm), 사고 함정 (thinking trap), 컨텍스트 스터핑 (context stuffing), 에이전트 오브 에이전트 (agent-of-agents). 처음 두 가지는 v2에서 확인할 수 있습니다. 마지막 두 가지는 그렇지 않습니다. v3는 이 4가지를 모두 포착합니다.

v3에서 A 등급이란 무엇인가 (v2 대비)

신호 클래스 (Signal class)	v2 (7)	v3 (9)
의도 파악 (Intent capture)	✓	✓
...

v3에서 D 또는 F 등급을 받는다는 것은 귀하의 에이전트가 비용 가시성 (cost-visibility) 레이어의 대부분 없이 배포되고 있음을 의미합니다. 해결 방법 목록은 위에서 언급한 것과 동일한 3줄 레시피입니다. 30초 만에 나오는 등급은 9가지 중 무엇을 먼저 수정해야 하는지 알려줍니다.

도구 자체에서 변경된 사항 (엔지니어를 위한 정보)

브라우저 측 전용 (Browser-side only). 모든 것은 여전히 귀하의 브라우저에서 실행됩니다. 저희는 귀하의 로그 텍스트를 절대 볼 수 없습니다.
9개 대역 점수 산정 (9-band scoring). A/B/C/D/F 등급은 이제 9개의 신호를 반영하며, 등급 문자 임계값(thresholds)이 재조정되었습니다. A는 여전히 "9개 모두 존재함"을 의미하지만, B/C/D의 커트라인이 강화되어 9개 중 5개를 충족한다고 해서 더 이상 C를 받지는 않습니다.
하위 호환성 (Backward compatible). v1 및 v2 소스도 여전히 정확하게 등급을 매깁니다. 캡처 API는 silent-failure-audit-v1, -v2, -v3 페이로드(payload)를 모두 수용합니다.
리포트 이메일이 더 풍부해졌습니다. 이제 한 페이지 분량의 리포트는 신호 8과 9의 실패를 구체적으로 비용 측면 (cost-side) 심층 분석(LLM Bill Triage, $299)으로 안내합니다. 이는 Grader가 비용 형태(cost-shape) 신호를 감지한 팀에게 자연스러운 다음 단계이기 때문입니다.

해결 방법 목록과 업셀 (upsell) 구조는 v2와 동일합니다 — _무엇이 누락되었는지, 3줄 해결 방법은 무엇인지, 직접 하고 싶지 않다면 사람이 읽을 수 있는 버전은 무엇인지_를 알려줍니다. 유일하게 새로운 부분은 신호 8/9 실패 시 정확도 리포트가 아닌 비용 리포트로 업셀된다는 점입니다. 동일한 개인정보 보호, 동일한 브라우저 측 방침을 유지하면서, 2026년의 비용 문제에 대해 더 깊은 커버리지를 제공합니다.

Grader 사용해보기 (무료, 브라우저 측 실행, 가입 불필요)

자신의 에이전트 로그를 평가하고 싶다면, 이 글의 헤더에 있는 공식 URL(dev.to의 제목 위)을 통해 무료 브라우저 측 도구(browser-side tool)로 접속할 수 있습니다. 마지막 50줄을 붙여넣으세요. 9개의 신호(signals)를 바탕으로 A-F 등급을 받게 됩니다. 수정 목록(fix list)을 이메일로 받고 싶다면 한 페이지 분량의 보고서를 본인에게 이메일로 보내도록 설정할 수 있습니다 (이메일은 보고서를 원할 때만 요청됩니다. 등급 확인은 무료이며 익명으로 진행됩니다).

두 가지 참고 사항:

이 평가기(grader)는 무엇이 "좋은" 상태인지에 대해 주관적인 기준을 가지고 있지만, 점수 세부 내역은 신호(signal)별로 제공되므로 관심 없는 신호는 무시할 수 있습니다 (예: 에이전트가 신뢰할 수 없는 입력(untrusted input)을 받지 않는 경우 신호 7 무시). 그러면 나머지 항목에 대해 유용한 등급을 얻을 수 있습니다.
9개의 신호는 AI Ops Checkup이 전체 프로덕션 아카이브(production archive)에서 찾는 것과 동일한 9개이며, 신호 8번과 9번은 LLM Bill Triage 심층 분석(deep-read)이 전문으로 다루는 2개와 동일합니다. 평가기는 "나에게 문제가 있는가?"를 확인하는 단계이며, 유료 보고서는 "내 아카이브에서 발생하는 구체적인 드리프트(drifts)를 보여달라"는 단계입니다. 체크리스트는 같지만 깊이가 다릅니다.

v3를 작성하며 배운 것 (메타)

v1 평가기는 감사(audit) 작업 중에 목격한 가장 흔한 5가지 실패 모드(failure modes)를 바탕으로 구축되었습니다. v2는 v1을 실행한 후 모든 팀이 던진 2가지 질문을 바탕으로 구축되었습니다 ("내 재시도(retries)가 이중 청구되지 않는다는 것을 어떻게 알 수 있나요?" → 신호 6, "누군가 에이전트를 유도(steered)했을 수도 있나요?" → 신호 7). v3 역시 동일한 방식으로 구축되었습니다. 즉, v2를 실행한 후 모든 팀이 던진 2가지 질문을 바탕으로 합니다 ("왜 청구 금액이 4배나 늘었나요?" → 신호 8과 9, 두 가지 관점에서의 동일한 답변).

만약 v3를 실행했는데 평가기가 잡아내지 못하는 실패 형태를 발견한다면, 보고서 하단에 있는 제 이메일로 연락해 주세요. v4는 여러분이 보내주시는 피드백을 바탕으로 구축될 것입니다.

— Milo