OpenClaw가 하루에 2150만 토큰을 소각? 세 가지 최적화 전략으로 비용 급감

원문 제목: Why My OpenClaw Sessions Burned 21.5M Tokens in a Day (And What Actually Fixed It)

원문 저자: MOSHIII

원문 번역: Peggy, BlockBeats

편집자 주: 에이전트 애플리케이션이 빠르게 보급되는 현재, 많은 팀이 겉보기에는 비정상적으로 보이는 현상을 발견했습니다: 시스템은 정상적으로 작동하지만, 토큰 비용은 눈에 띄지 않게 계속해서 상승하고 있습니다. 본문은 실제 OpenClaw 작업 부하를 분석하여 비용 폭발의 원인이 종종 사용자 입력이나 모델 출력에서 오는 것이 아니라, 간과된 컨텍스트 캐시 재생(cached prefix replay)에서 비롯된다는 것을 발견했습니다. 모델은 각 호출 라운드에서 방대한 역사적 컨텍스트를 반복적으로 읽어들여 엄청난 양의 토큰 소비를 발생시킵니다.

기사는 구체적인 세션 데이터를 결합하여 도구 출력, 브라우저 스냅샷, JSON 로그와 같은 대형 중간 산출물이 어떻게 지속적으로 역사적 컨텍스트에 기록되고, 에이전트 루프에서 반복적으로 읽히는지 보여줍니다.

이 사례를 통해, 저자는 명확한 최적화 접근법을 제안합니다: 컨텍스트 구조 설계, 도구 출력 관리부터 compaction 메커니즘 설정까지. 에이전트 시스템을 구축 중인 개발자들에게, 이것은 단순한 기술 문제 해결 기록이 아니라, 실제 돈을 절약하는 가이드입니다.

다음은 원문입니다:

저는 실제 OpenClaw 작업 부하를 분석했고, 많은 에이전트 사용자들이 알아볼 수 있을 것이라고 생각하는 패턴을 발견했습니다:

토큰 사용량이 '활발'해 보입니다

응답도 정상적으로 보입니다

그러나 토큰 소비는 갑자기 폭발적으로 증가합니다

다음은 이번 분석의 구조 분해, 근본 원인, 그리고 실제 실행 가능한 해결 경로입니다.

TL;DR

가장 큰 비용 동인은 사용자 메시지가 너무 길기 때문이 아닙니다. 엄청난 양의 캐시 프리픽스(cached prefix)가 반복적으로 재생되기 때문입니다.

세션 데이터에서:

총 토큰: 21,543,714

cacheRead: 17,105,970 (79.40%)

input: 4,345,264 (20.17%)

output: 92,480 (0.43%)

다시 말해: 대부분의 호출 비용은 실제로 새로운 사용자 의도를 처리하는 데 쓰이는 것이 아니라, 거대한 역사적 컨텍스트를 반복적으로 읽는 데 쓰입니다.

"잠깐, 어떻게 이런 일이?"라는 순간

저는 높은 토큰 사용량이 매우 긴 사용자 프롬프트, 대량의 출력 생성, 또는 비싼 도구 호출에서 비롯된다고 생각했습니다.

그러나 실제로 지배적인 패턴은:

input: 수백에서 수천 토큰

cacheRead: 호출당 17만에서 18만 토큰

즉, 모델은 매 라운드마다 동일한 거대하고 안정적인 프리픽스를 반복적으로 읽습니다.

데이터 범위

저는 두 가지 수준의 데이터를 분석했습니다:

1. 런타임 로그(runtime logs)

2. 세션 기록(session transcripts)

명확히 할 점:

런타임 로그는 주로 행동 신호(재시작, 오류, 설정 문제 등) 관찰에 사용됩니다

정확한 토큰 통계는 세션 JSONL의 usage 필드에서 가져옵니다

사용된 스크립트:

scripts/session_token_breakdown.py

scripts/session_duplicate_waste_analysis.py

생성된 분석 파일:

tmp/session_token_stats_v2.txt

tmp/session_token_stats_v2.json

tmp/session_duplicate_waste.txt

tmp/session_duplicate_waste.json

tmp/session_duplicate_waste.png

토큰은 실제로 어디에 소비되나요?

1) 세션 집중

한 세션의 소비가 다른 것들보다 훨씬 높습니다:

570587c3-dc42-47e4-9dd4-985c2a50af86: 19,204,645 토큰

그 다음은 명확한 절벽식 하락:

ef42abbb-d8a1-48d8-9924-2f869dea6d4a: 1,505,038

ea880b13-f97f-4d45-ba8c-a236cf6f2bb5: 649,584

2) 행동 집중

토큰은 주로 다음에서 옵니다:

toolUse: 16,372,294

stop: 5,171,420

이는 문제가 일반적인 채팅이 아니라 도구 호출 체인 루프에 있음을 나타냅니다.

3) 시간 집중

토큰 피크는 무작위적이지 않고 몇 시간 동안 집중됩니다:

2026-03-08 16:00: 4,105,105

2026-03-08 09:00: 4,036,070

2026-03-08 07:00: 2,793,648

거대한 캐시 프리픽스 안에는 실제로 무엇이 있나요?

대화 내용이 아니라 주로 대형 중간 산출물입니다:

거대한 toolResult 데이터 블록

긴 reasoning / thinking traces

대형 JSON 스냅샷

파일 목록

브라우저 스크랩 데이터

하위 에이전트의 대화 기록

가장 큰 세션에서 문자량은 대략:

toolResult:text: 366,469 문자

assistant:thinking: 331,494 문자

assistant:toolCall: 53,039 문자

이러한 내용이 역사적 컨텍스트에 유지되면, 이후의 각 호출은 캐시 프리픽스를 통해 이를 다시 읽을 가능성이 있습니다.

구체적인 예시 (세션 파일에서)

다음 위치에서 반복적으로 거대한 컨텍스트 블록이 나타났습니다:

sessions/570587c3-dc42-47e4-9dd4-985c2a50af86.jsonl:70

대형 게이트웨이 JSON 로그 (약 3.7만 문자)

sessions/570587c3-dc42-47e4-9dd4-985c2a50af86.jsonl:134

브라우저 스냅샷 + 보안 래핑 (약 2.9만 문자)

sessions/570587c3-dc42-47e4-9dd4-985c2a50af86.jsonl:219

거대한 파일 목록 출력 (약 4.1만 문자)

sessions/570587c3-dc42-47e4-9dd4-985c2a50af86.jsonl:311

session/status 상태 스냅샷 + 대형 프롬프트 구조 (약 3만 문자)

"중복 내용 낭비" vs "캐시 재생 부담"

저는 단일 호출 내부의 중복 내용 비율도 측정했습니다:

중복 비율 약: 1.72%

실제로 존재하지만, 주요 문제는 아닙니다.

진짜 문제는: 캐시 프리픽스의 절대적인 크기가 너무 큽니다

구조는: 거대한 역사적 컨텍스트, 매 라운드 호출 재읽기, 그 위에 소량의 새로운 입력만 추가

따라서 최적화의 초점은 중복 제거가 아니라 컨텍스트 구조 설계입니다.

왜 에이전트 루프는 특히 이 문제가 발생하기 쉬운가요?

세 가지 메커니즘이 서로 중첩됩니다:

1. 대량의 도구 출력이 역사적 컨텍스트에 기록됩니다

2. 도구 루프는 많은 수의 짧은 간격 호출을 생성합니다

3. 프리픽스 변화가 매우 작음 → 캐시가 매번 다시 읽습니다

컨텍스트 compaction이 안정적으로 트리거되지 않으면, 문제는 빠르게 증폭됩니다.

가장 중요한 수정 전략 (영향 순서대로)

P0—거대한 도구 출력을 장기 컨텍스트에 밀어넣지 마세요

초대형 도구 출력의 경우:

• 요약 + 참조 경로 / ID 유지
• 원본 페이로드는 파일 artifact에 기록
• 전체 원문을 채팅 기록에 보관하지 마세요

다음 범주를 우선적으로 제한하세요:

• 대형 JSON
• 긴 디렉토리 목록
• 브라우저 전체 스냅샷
• 하위 에이전트 전체 transcript

P1—compaction 메커니즘이 실제로 작동하는지 확인하세요

이 데이터에서, 설정 호환성 문제가 여러 번 나타났습니다: compaction key가 유효하지 않음

이는 최적화 메커니즘을 조용히 끕니다.

올바른 방법: 버전 호환 설정만 사용하세요

그런 다음 확인:

openclaw doctor --fix

그리고 시작 로그를 확인하여 compaction이 수락되었는지 확인하세요.

P1—reasoning 텍스트 지속성을 줄이세요

긴 추론 텍스트가 반복적으로 재생되는 것을 피하세요

프로덕션 환경에서: 전체 reasoning이 아닌 간단한 요약을 저장하세요

P3—프롬프트 캐싱 설계 개선

목표는 cacheRead를 최대화하는 것이 아닙니다. 목표는, 간결하고 안정적이며 가치가 높은 프리픽스에서 캐시를 사용하는 것입니다.

제안:

• 안정적인 규칙을 system prompt에 넣으세요
• 불안정한 데이터를 안정적인 프리픽스에 넣지 마세요
• 매 라운드마다 대량의 디버그 데이터를 주입하지 마세요

실제 손실 중지 방안 (내일 제가 처리해야 한다면)

1. cacheRead 비율이 가장 높은 세션 찾기

2. runaway 세션에 /compact 실행

3. 도구 출력에 잘림 + artifact화 추가

4. 수정 후마다 토큰 통계 다시 실행

네 가지 KPI를 중점적으로 추적하세요:

cacheRead / totalTokens

toolUse avgTotal/call

>=100k 토큰 호출 횟수

최대 세션 비율

성공 신호

최적화가 효과가 있다면, 다음과 같은 것을 보게 될 것입니다:

100k+ 토큰 호출이 현저히 감소

cacheRead 비율 하락

toolUse 호출 가중치 하락

단일 세션의 지배 정도 감소

이 지표들이 변하지 않는다면, 컨텍스트 전략이 여전히 너무 관대하다는 뜻입니다.

재현 실험 명령어

python3 scripts/session_token_breakdown.py 'sessions' \

--include-deleted \

--top 20 \

--outlier-threshold 120000 \

--json-out tmp/session_token_stats_v2.json \

> tmp/session_token_stats_v2.txt

python3 scripts/session_duplicate_waste_analysis.py 'sessions' \

--include-deleted \

--top 20 \

--png-out tmp/session_duplicate_waste.png \

--json-out tmp/session_duplicate_waste.json \

> tmp/session_duplicate_waste.txt

결론

에이전트 시스템이 모든 것이 정상적으로 보이지만 비용이 계속 상승한다면, 먼저 한 가지 문제를 확인하세요: 당신이 지불하는 것은 새로운 추론인가요, 아니면 대규모로 이전 컨텍스트를 재생하는 것인가요?

제 사례에서는, 대부분의 비용이 실제로 컨텍스트 재생에서 왔습니다.

이것을 깨닫게 되면, 해결책도 명확해집니다: 장기 컨텍스트에 들어가는 데이터를 엄격히 통제하세요.

원문 링크