Claude Code의 Opus 4.8에서 발생하는 두 가지 사고를 로그로 구분하기 — 토큰 10배 낭비와 도구 결과의 날조

2026년 5월 말부터, Claude Code의 Opus 4.8 (claude-opus-4-8)에서 성격이 다른 두 종류의 사고가 연속해서 보고되고 있습니다. 하나는 간단한 작업에서 토큰을 10배 이상 낭비하는 비용 사고이고, 다른 하나는 도구(tool)의 실행 결과를 기다리지 않고 그럴듯한 값을 날조하는 정확성 사고입니다.

이 기사는 단순히 "곤란하다"로 끝내지 않고, 자신의 수중에 있는 로그(JSONL)를 통해 이것이 버그인지 설계대로인지, 날조가 실제로 일어났는지를 구분하기 위한 구체적인 명령어를 정리한 것입니다. 저는 Claude Code를 자율적으로 장시간 구동하고 있기 때문에 두 가지 모두 실제로 겪었습니다. 2026년 6월 12일의 최신 버전에서도 보고가 이어지고 있으며, 3일 후인 6월 15일의 과금을 고려하면 비용 문제는 특히 지금 미리 측정해 둘 가치가 있습니다.

대표적인 보고 (anthropics/claude-code#64153)에서는 파일 이름을 변경했을 때의 영향 범위를 조사하는 작업만으로, Opus 4.8이 46,433 output token을 22분 43초의 thinking 과정으로 소비했습니다. effort는 medium입니다. 크래시(crash)나 재시도(retry)가 아닌, 정상 완료 (stop_reason: end_turn) 상태에서의 수치입니다.

transcript의 해당 턴 수치는 다음과 같았습니다.

input_tokens: 131
cache_read: 91,877
cache_creation: 4,054
...

동일한 작업을 Opus 4.6이나 4.7에게 시키면 2,000~3,000 token으로 해결된다는 비교도 보고되었습니다. 즉, 10배에서 40배의 팽창입니다.

"나에게도 일어나고 있는가"는 감각이 아닌 숫자로 판단할 수 있습니다. 최근 작업의 output_tokens 중앙값을 구합니다.

jq -s 'map(.message.usage.output_tokens // 0) | sort | .[length/2]' \ 
~/.claude/projects/**/recent.jsonl

매우 평범한 작업의 중앙값이 1만 token을 넘는다면, 이 낭비가 일어나고 있을 가능성이 높습니다. 나아가 상위 항목을 보면 유독 튀는 턴을 특정할 수 있습니다.

jq -s 'map(.message.usage.output_tokens // 0) | sort | reverse | .[0:10]' \ 
~/.claude/projects/**/recent.jsonl

여기서 중요한 점은, 토큰 소비의 대부분은 cache_read (매 턴 문맥의 재전송)에 의해 결정된다는 점입니다. 위의 transcript에서도 cache_read가 91,877인 것에 비해 output은 46,433이었습니다. 문맥이 클수록 턴마다 조용히 비용이 쌓입니다. 따라서 "가벼운 작업인데도 할당량이 녹아내리는" 정체는 대부분 코드 양이 아니라 문맥의 크기 × 턴 수입니다. /clear로 문맥을 끊는 것이 가장 효과적인 레버(lever)가 됩니다.

이 사고는 5월 말에 수렴되지 않았습니다. 6월에 들어서도 "사용량이 23배 악화", "1턴에 2만6만 token의 폭주하는 thinking"이라는 보고가 새로운 버전에서 이어지고 있으며, 6월 12일 (v2.1.173) 보고까지 있습니다. 제공처의 수정 공지는 제가 찾은 범위 내에서는 발견되지 않았습니다.

두 번째는 완전히 다른 성격입니다. Claude Code는 도구(파일 읽기, 검색, 명령어 실행)를 호출하고 그 결과를 보고 나서 답변합니다. 그런데 Opus 4.8에서는 도구의 결과가 아직 반환되지 않았는데도 구체적인 값을 먼저 답변해 버린다는 보고가 있습니다 (#64065). 항공권 검색에서 결과를 기다리지 않고 "편도 891달러"라고 답했는데, 실제로 반환된 값은 약 645달러였다는 예시입니다. 약 2배의, 아직 존재하지 않는 값을 보고했던 셈입니다.

나아가 6월 10일에는 생(raw) JSONL을 조사하여 "도구를 호출한 기록 (tool_use 블록)이 전혀 없는데도 도구를 실행한 것으로 되어 있는" 완전한 환상 속의 도구 호출을 검증한 보고 (#64076 주변)도 나왔습니다.

이 부분이 이 사고의 구원입니다. 진짜 도구의 결과는 구조적으로 위조와 구분할 수 있습니다. Claude Code의 JSONL에서는,

• 진짜 도구의 결과는 user 역할의 메시지 안의 tool_result 블록이며, 반드시 대응하는 tool_use_id...

를 가집니다 - 모델이 도구를 호출했다는 사실은 assistant 메시지의 tool_use 블록에 남습니다.

즉, 모델이 "실행했다"라고 말하는 조작에 대해, 대응하는 tool_use가 JSONL에 존재하는지 대조하면, 환상 속의 도구 호출(hallucinated tool calls)을 사후에 검출할 수 있습니다.

한 세션에서 tool_use의 수와 그에 대응하는 tool_result의 수를 세어 대조하는 예시입니다.

# tool_use (모델이 도구를 호출한 횟수)
jq '[.message.content[]? | select(.type=="tool_use")] | length' session.jsonl \
| awk '{s+=$1} END{print "tool_use:", s}'
...

모델이 보고한 조작 건수에 비해 tool_use가 부족하다면, 그만큼은 도구를 거치지 않고 그냥 "했다"라고 말하고 있을 뿐이라는 식으로 구분할 수 있습니다. 보고를 그대로 믿지 않고, 구조를 통해 확인할 수 있다는 점이 핵심입니다.

이러한 날조(fabrication) 현상은 최신 버전에서도 여전히 발생하고 있습니다. 6월 12일(v2.1.173)에도 파일 편집이나 릴리스 생성을 "했다"라고 보고했으나 대응하는 로그가 없다는 보고가 있습니다.

근본적인 원인은 제공 측에 있으며, 사용자가 완전히 고칠 수는 없습니다. 하지만 피해는 피할 수 있습니다.

회귀(Regression) 전의 모델로 되돌리기: 두 사고 모두 Opus 4.8에서 발생한 사고입니다. Opus 4.7 (claude-opus-4-7)은 폐지되지 않았으며 지금도 선택할 수 있습니다. export ANTHROPIC_MODEL=claude-opus-4-7을 사용하세요. 다만 "4.7로 바꾸면 확실히 두 사고 모두 사라진다"라고 단정할 수 있는 검증은 제 수중에 없습니다. "4.8 고유의 회귀 현상이므로, 그 이전 모델로 되돌린다"라는 구분책의 하나로 취급해 주세요. -
도구를 하나씩 실행하기: 보고된 내용 중 실제로 효과가 있는 것은, 도구를 한꺼번에 호출하지 않고 순차적으로 실행하는 것입니다. -
effort 낮추기: 사고 과정(thinking)의 깊이를 낮추면 과도한 thinking (over-thinking)이 완화됩니다. -
자신의 소비량 측정하기: 위의 jq 명령어로 중앙값을 확인하여, 버그인지 문맥(context)에 의한 것인지 구분합니다.

6월 15일에 과금 체계가 두 가지로 나뉩니다. 이 부분은 오해하기 쉬우므로 나누어 설명하겠습니다.

대화용(터미널이나 IDE에서 직접 입력하는 Claude Code)은 기존과 동일한 구독 범위(Pool 1) 내에서 사용되며, 달러로 추가 과금되지 않습니다. -
자동 실행용(Agent SDK, claude -p, GitHub Actions)은 별도의 범위(Pool 2)가 되며, API 정가로 과금됩니다.

즉, 사고 1(토큰 낭비)이 가장 치명적인 대상은 자동 실행으로 Opus 4.8을 돌리고 있는 사람입니다. 낭비가 그대로 달러 지출로 이어집니다. 대화형으로 사용하는 사람도 낭비가 구독 범위를 빠르게 소진시키는 방식으로 영향을 미쳐, "가벼운 작업인데도 할당량이 다해 차단되는" 결과로 이어집니다.

어떤 방식의 사용이든, 6월 15일 이전의 이 며칠 동안 자신이 Opus 4.8로 얼마나 소비하고 있는지 위의 jq로 측정해 보고, 필요하다면 4.7로 되돌려 놓는 것이 가치 있는 일입니다.

• Opus 4.8에서 "간단한 작업의 토큰 낭비"와 "도구 결과의 날조"라는 두 종류의 사고가 같은 시기에 발생했다.
• 둘 다 6월 12일 최신 버전에서 보고가 이어지고 있으며, 제공 측의 수정 공지는 보이지 않는다.
• 둘 다 JSONL을 통해 사후에 구분 가능하다: 낭비는 output_tokens의 중앙값, 날조는 tool_use와 tool_result의 대조.
• 사용자 측의 대응책은 4.7로 되돌리기 / 도구를 순차 실행하기 / effort 낮추기 / 자신의 소비량 측정하기.
• 6월 15일 과금 분리로 인해, 자동 실행은 낭비가 달러 지출로 이어지고, 대화형은 할당량 고갈을 가속화한다.

새로운 모델이 항상 좋은 것은 아니라는 점이 이번에 가장 뼈저리게 느낀 교훈이었습니다.

"보고는 성공, 실제는 실패"라는 침묵의 불일치를 자신의 출력을 검증하는 절차로 정리한 책이 있습니다. 800시간의 자율 운용 중에 만난 사고들을 총 8장에 걸쳐 다루었습니다 (『Claude Code 사고 방지 가이드』 ¥800 · 제2장까지 무료).

토큰 낭비의 메커니즘과 소비량을 측정하여 줄이는 절차를 심도 있게 다룬 책은 이쪽입니다 (『Claude Code 토큰 절약 가이드』 ¥2,500).