OpenClaw 주간 사용량 효율화 분석
조사 기간: 2026-03-30 ~ 2026-04-05 (7일)
데이터 소스: ~/.openclaw/logs/llm/*.jsonl, cron/jobs.json, ~/.claude/sessions/, ~/.claude/metrics/costs.jsonl
v2: Claude Code 구독($200/월 Max 플랜) 기준 분석 추가
0. Claude Code 구독 사용량 (핵심)
현황
Max 플랜($200/월)은 per-token 과금이 아닌 정액 구독. 로컬에 세부 토큰 데이터가 기록되지 않는다.
~/.claude/metrics/costs.jsonl — 3일간만 기록, 모든 항목이 input_tokens=0, output_tokens=0, cost=0- Claude Code CLI에 사용량 조회 커맨드 없음
- rate limit 히트 기록: 최소 1회 (2026-03-26 18:55 KST)
일일 세션 생성량 — 이게 구독 사용량의 본체
| 구분 |
일일 횟수 |
비고 |
| isolated agentTurn 크론 |
133회 |
각각 새 Claude Code 세션 생성 |
| isolated script 크론 |
145회 |
그 중 144회가 "크론 에러 알림" 단독 |
| main systemEvent 크론 |
217회 |
새 세션은 아님 (메인에 이벤트 전달) |
| 해리 수동 사용 |
~155 프롬프트, ~5 세션 |
history.jsonl 기준 |
| 일일 새 세션 합계 |
~278회 |
|
| 월간 새 세션 추정 |
~8,300회 |
|
시간대별 부하 (KST)
| 시간 |
세션/시 |
비고 |
| 07:00 |
29 |
최대 — 아침 파이프라인 집중 |
| 06:00 |
21 |
|
| 08:00 |
19 |
|
| 09:00 |
17 |
|
| 04:00 |
15 |
새벽 크론 |
| 기타 |
7~13 |
|
모델 사용 비중
모든 크론 잡이 기본 모델(Sonnet)로 실행. Opus를 쓰는 크론 잡은 0개.
| 분류 |
잡 수 |
실행 모델 |
적정성 |
| 순수 스크립트 실행 |
69개 |
Sonnet |
과잉 — Haiku면 충분 |
| 경량 LLM (스크립트 실행+보고) |
29개 |
Sonnet |
대부분 과잉 |
| 중량 LLM (분석/코워크) |
7개 |
Sonnet |
적절 (일부는 Opus 필요) |
Opus가 필요한데 Sonnet으로 돌고 있는 잡: cowork-full(프롬프트에 "Opus급 큐레이션" 명시), analyst-reasoning 5개
Sonnet이 과잉인 잡: 스크립트만 실행하는 69개 — python3 script.py 치고 결과 전달만 하면 되는데 Sonnet 세션을 점유
세션당 구독 영향 추정
Max 플랜의 rate limit 구조(공개 미확인)에서, 하루 278 세션이 각각 최소 수천 토큰을 소비한다고 가정하면:
- 경량 세션(스크립트 실행 + 보고): ~2,000~5,000 토큰/세션
- 중량 세션(분석/코워크): ~20,000~50,000 토큰/세션
- 일일 추정: 경량 240회 × 3K + 중량 38회 × 30K = ~1,860K 토큰/일
- 월간 추정: ~56M 토큰/월 — Max 플랜의 한도에 근접할 가능성
중복 세션 최대 낭비원
| 문제 |
일일 세션 낭비 |
조치 |
| technical-stat-models 17개 중복 |
16개 main × 9회 = 144 이벤트 + 1개 isolated × 12회 |
1개로 통합 |
| 크론 에러 즉시 알림 10분 주기 |
144회/일 |
30분으로 완화 → 48회 |
| 6h-content-summary 중복 |
3개 활성 중 2개 중복 |
1개 삭제 |
| 석유 공급망 모니터 시간 겹침 |
14시에 isolated+main 동시 |
1개 제거 |
1. 게이트웨이 LLM 호출 현황 (파이프라인 내부)
| 항목 |
수치 |
| 7일 총 LLM 호출 |
1,577회 |
| 성공 |
856회 (54.2%) |
| 실패 |
721회 (45.8%) |
| 총 프롬프트 |
~1,234K 토큰 |
| 총 응답 |
~364K 토큰 |
| 총 토큰 |
~1,598K |
| 일평균 |
~228K 토큰/일 |
| 실패에 낭비된 토큰 |
~480K (전체의 30%) |
비용 구조
대부분 무료/구독 모델이라 직접 비용은 극히 낮다.
| 모델 |
호출 |
성공률 |
과금 방식 |
| github-copilot/gpt-5-mini |
596 |
76.3% |
구독 포함 (무제한) |
| anthropic/claude-sonnet-4-6 |
108 |
74.1% |
~$1.16/주 |
| anthropic/claude-opus-4-6 |
132 |
66.7% |
별도 과금 |
| openrouter/minimax-m2.5 |
152 |
6.6% |
저가 (거의 실패) |
| ollama/kimi-k2.5:cloud |
147 |
11.6% |
로컬 (거의 실패) |
| openrouter/nemotron-120b:free |
60 |
13.3% |
무료 (거의 실패) |
핵심: 금전 비용은 주 $2~3 수준으로 낮지만, 실패한 호출이 45.8%로 시간 낭비가 심각하다.
2. 토큰 소비 상위 10 파이프라인
| 순위 |
파이프라인 |
빈도 |
모델 |
주간 추정 토큰 |
비중 |
| 1 |
Cowork (라이트+풀) |
7회/일 |
세션+gpt-5-mini |
623K |
39% |
| 2 |
oil_supply_monitor |
3회/일 |
gpt-5-mini |
462K |
29% |
| 3 |
technical-stat-models (x17) |
204회/일 |
세션 |
측정불가 |
- |
| 4 |
etf_insight_extractor |
5회/일 |
gpt-5-mini |
85K |
5% |
| 5 |
hypothesis_engine+feedback |
15회/일 |
gpt-5-mini |
70K |
4% |
| 6 |
sector_news_scorer |
4회/일 |
gpt-5-mini |
35K |
2% |
| 7 |
discovery_enricher |
1회/일 |
gpt-5-mini |
20K |
1% |
| 8 |
note_atomizer |
1~2회/일 |
gpt-5-mini |
15K |
1% |
| 9 |
deep_enricher |
1회/일 |
gpt-5-mini |
10K |
1% |
| 10 |
bond_daily_report |
1회/일 |
gpt-5-mini |
6K |
<1% |
상위 2개(Cowork + oil_supply_monitor)가 전체의 68%를 차지한다.
technical-stat-models 중복 문제
- 같은 이름의 크론 잡이 17개 활성화되어 있음
- 전부
every 120m = 하루 12회 × 17개 = 204회/일 agentTurn 세션 생성
- Claude Code 세션 토큰(Anthropic 크레딧)을 소비하지만 LLM 로그에는 안 잡힘
3. knowledge_connector 매칭 분석
결론: LLM 토큰 소비 0.
- 40만 건 매칭은 전부 CPU 기반 Jaccard 유사도 계산 (pure 문자열 비교)
- LLM, 임베딩 API 호출 일절 없음
use_embedding=False로 명시적 비활성화- 인덱스도 깨져서(UTF-8 에러) Jaccard 폴백만 실행됨
| 날짜 |
노트 수 |
매칭 건수 |
소요 시간 |
| 3/28 |
5,098 |
114K |
43분 |
| 4/1 |
5,777 |
237K |
3.3시간 |
| 4/4 |
6,108 |
298K |
3.6시간 |
토큰 문제는 아니지만 시간 문제가 심각: O(n²) 비교로 매일 3~5시간 소요, 노트 증가에 따라 가속 악화. 결과 394K 매칭 중 상위 50건만 저장 — 99.99% 계산이 버려짐.
4. 낭비 패턴 5가지
패턴 A: 타임아웃 재시도 폭포 (가장 큰 낭비)
shared/llm.py 230~289줄- 모델 체인 6개 × 모델당 3회 재시도 = 최악 18번 같은 프롬프트 전송
- 7일간 타임아웃 638건 — 타임아웃된 모델에 같은 걸 다시 보내는 구조
- 낭비 규모: ~480K 토큰/주 (전체 실패분)
- 수정: 타임아웃 시 해당 모델 즉시 스킵, 재시도 1회로 제한
패턴 B: 죽은 모델이 체인에 잔류
| 모델 |
3일 성공률 |
평균 대기 |
| minimax-m2.5 |
10% |
69초 |
| kimi-k2.5:cloud |
2% |
64초 |
| qwen3.5:4b |
9% |
88초 |
| nemotron-120b:free |
17% |
96초 |
- 이 4개 모델이 체인에 남아서, gpt-5-mini 실패 시 60~90초씩 대기하며 연쇄 실패
- 수정: 성공률 20% 미만 모델 체인에서 제거 또는 동적 순서 조정
패턴 C: vault_architect 동일 노트 반복 판단
vault_architect.py 881~892줄- 크론 실행마다 같은 노트를 다시 LLM에 판단 요청
- "스마트글래스 에실로룩소티카" 노트: 3일간 24회 같은 질문
- 낭비 규모: ~15K 토큰/주 (완전 중복)
- 수정: 판단 결과 캐시 (노트 해시 기반), 내용 변경 없으면 재사용
패턴 D: oil_supply_monitor 초대형 프롬프트
oil_supply_monitor.py 2140~2500줄- 뉴스 검색 결과 전체를 프롬프트에 덤프 (건당 30,000~35,000자)
- 정규식으로 이미 추출한 수치를 LLM에도 중복 전송
- 낭비 규모: ~462K 토큰/주 (전체의 29%)
- 수정: 정규식 추출 성공 필드 제거, 텍스트 [:4000] → [:1500] 축소
패턴 E: hypothesis_engine 로깅 우회
hypothesis_engine.py 556~580줄shared/llm.py를 안 쓰고 직접 Gateway 호출- JSONL 로그에 안 잡혀서 실사용량 추적 불가
- 수정:
llm_chat_direct() 호출로 교체
5. Evaluator 분리 — Claude Code 구독 관점
현재 상태
- 품질 채점 메커니즘 전무 — "응답이 왔으면 OK"
cheap_verifier.py는 깨진 스켈레톤 (구문 에러, 사용 불가)- 40개 파이프라인이 LLM 출력을 무검증으로 downstream 전파
Evaluator가 Claude Code 세션 수를 줄일 수 있는가?
직접적으로는 아니다. Evaluator는 파이프라인 내부 LLM 호출(게이트웨이 경유, gpt-5-mini)의 품질을 채점하는 것이지, 크론이 생성하는 Claude Code 세션 자체를 줄이지는 않는다.
간접적으로는 줄일 수 있다. 현재 품질 불량으로 재실행이 필요한 파이프라인이 있다면:
- 수동 재실행 = 추가 Claude Code 세션 1개
- Evaluator가 첫 실행에서 품질을 보장하면 재실행 불필요
- 하지만 현재 "파이프라인 품질 불량 → 수동 재실행" 패턴의 빈도가 측정되지 않아 절감 규모는 추정 불가
실질적으로 세션을 줄이는 방법
Claude Code 구독 사용량을 줄이려면 크론 잡 정리가 유일한 방법:
| 조치 |
세션 절감/일 |
월간 절감 |
| technical-stat-models 17→1 통합 |
-12 isolated + -128 main이벤트 |
~360 세션 |
| 크론 에러 알림 10분→30분 |
-96 script |
~2,880 실행 |
| 스크립트 실행 잡 69개 → 배치 통합 |
-40~50 세션 |
~1,200 세션 |
| 중복 잡 정리 (6h-summary, 석유모니터 등) |
-5~10 세션 |
~150 세션 |
| 합계 |
~160 세션/일 |
~4,590 세션/월 (55% 감소) |
게이트웨이 LLM Evaluator 비용 (변경 없음)
| 항목 |
토큰 |
| Evaluator 입력 (출력+루브릭+맥락) |
~1,186 |
| Evaluator 응답 (점수+사유) |
~100 |
| 1회당 합계 |
~1,286 |
gpt-5-mini로 Evaluator를 돌리면 추가 금전 비용 0원. 추가되는 건 레이턴시뿐.
권장 우선순위
| 우선 적용 (해리 직접 노출) |
나중 적용 (내부 운영) |
| morning_briefing |
discovery_filter 번역 |
| daily_report |
github_release_monitor |
| company_insight_tracker |
session_skill_extractor |
| sector_news_scorer |
|
| deep_enricher |
|
상위 5개만 적용 시: 일 5~10건 추가 호출 (~13K 토큰)로 최대 효과.
6. 개선 권장 사항 (우선순위순)
즉시 실행 (난이도 낮음, 효과 큼)
| # |
조치 |
절감 추정 |
소요 |
| 1 |
타임아웃 시 모델 즉시 스킵 (재시도 1회) |
주 ~300K 토큰 + 파이프라인 지연 해소 |
30분 |
| 2 |
성공률 20% 미만 모델 체인에서 제거 |
주 ~120K 토큰 + 대기시간 제거 |
15분 |
| 3 |
technical-stat-models 중복 17개 → 1개로 정리 |
세션 비용 94% 감소 |
15분 |
| 4 |
vault_architect 판단 캐시 추가 |
주 ~15K 토큰 (완전 제거) |
1시간 |
| 5 |
hypothesis_engine → llm_chat_direct 전환 |
로깅 정상화 (추적 가능) |
30분 |
중기 개선 (난이도 중간)
| # |
조치 |
절감 추정 |
소요 |
| 6 |
oil_supply_monitor 프롬프트 축소 |
주 ~200K 토큰 |
2시간 |
| 7 |
해리 노출 파이프라인 5개에 Evaluator 적용 |
품질 보장 (+13K 토큰/일) |
4시간 |
| 8 |
knowledge_connector Jaccard 임계값 0.15→0.25 |
실행시간 3시간→30분 |
1시간 |
장기 구조 개선
| # |
조치 |
효과 |
| 9 |
동적 모델 체인 (24시간 성공률 기반 자동 순서) |
자가 치유 폴백 |
| 10 |
LLM 로그에 토큰 수 직접 기록 (문자수→토큰) |
정밀 비용 추적 |
| 11 |
knowledge_connector 인덱스 복구 + 임베딩 재활성화 |
O(n²)→O(n) 근사 |
7. 총 절감 가능 규모
| 구분 |
현재 주간 |
개선 후 추정 |
절감 |
| 총 토큰 |
1,598K |
~900K |
~700K (44%) |
| 실패율 |
45.8% |
~15% |
30%p 개선 |
| 파이프라인 지연 |
60~90초/실패 |
<5초/실패 |
시간 95% 감소 |
| knowledge_connector |
3~5시간/실행 |
30분/실행 |
85% 단축 |
즉시 실행 가능한 1~5번만 적용해도 주간 ~435K 토큰(27%) 절감 + 파이프라인 안정성 대폭 개선.
8. Claude Code 구독 최적화 종합
현재 구독 압박 요인
| 요인 |
규모 |
위험도 |
| 일 278 세션 (월 ~8,300) |
Max 플랜 한도 불명 |
중 — rate limit 1회 히트 이력 |
| 스크립트 실행 잡 69개가 Sonnet 사용 |
Haiku면 충분한 작업 |
높 — 가장 큰 낭비 |
| technical-stat-models 17중복 |
일 156 불필요 실행 |
높 — 즉시 정리 가능 |
| 모든 크론이 Sonnet (model 필드 미사용) |
Opus 필요 잡도 Sonnet |
중 — 역방향 비효율 |
우선 조치 (구독 기준)
| # |
조치 |
효과 |
난이도 |
| 1 |
technical-stat-models 17→1 통합 |
일 156 실행 제거 |
낮음 |
| 2 |
크론 에러 알림 10분→30분 |
일 96 실행 절감 |
낮음 |
| 3 |
스크립트 실행 잡에 model 필드 추가 |
Sonnet→적정 모델 |
중간 (하네스가 model 필드 지원하는지 확인 필요) |
| 4 |
동일 시간대 중복 잡 정리 |
일 5~10 세션 절감 |
낮음 |
| 5 |
cowork-full/analyst에 Opus 명시 |
품질 향상 (비용 증가 아님, Max 포함) |
낮음 |
모니터링 필요 사항
- Max 플랜 rate limit 구조 확인 — Anthropic에 문의하거나 claude.ai 계정 설정 확인
- 실제 세션당 토큰 소비 — costs.jsonl이 0만 기록하므로 추적 불가. Anthropic 대시보드 필요
- model 필드가 하네스에서 실제 작동하는지 — 가격 이력 수집(e27b3e01) 잡이 gpt-5-mini로 설정되어 있으나 실제 반영 여부 미확인