Claude Code 구독 사용량 분석과 토큰 절감 판단 - Claude 대화
DanzzaN이 DC 「AI 활용」 갤러리의 토큰 절감 글을 공유하며 반영할 만한 것을 묻자, Claude가 글의 분석 방식을 DanzzaN의 Claude Code 기록에 적용해 습관별 효과를 추정했다. 이어서 서브에이전트·Ultracode 사용, /compact 방법, 자동 압축 창 설정, Vault 조회 구조를 검토했다. Codex에서도 사용량 분석을 진행하고 있어, 이 노트가 Claude Code 기록을 Claude가 분석한 결과임을 밝혀 구분한다.
출처와 확인 범위
- 대화: 2026-09-25, DanzzaN과 Claude. Claude 데스크톱 앱 Code 탭(Claude Code 2.1.281), 모델
claude-opus-5-5, effortmax. 세션 식별자는source_task에 있다. - 공유된 글: 토큰 절감 습관을 위한 나의 사용 패턴 분석하기. DC AI 활용 마이너 갤러리, 작성자 grapefruit, 2026-09-24 게시, 2026-09-25 확인. 작성자의 13일 기록 분석을 담은 본문 이미지 11장과 댓글을 읽었다. 분석 방법과 비교 기준으로만 쓰므로 별도 Source로 만들지 않았다.
- 공식 문서(2026-09-25 확인): Prompt caching, Model configuration, Workflows, Subagents, Skills, Costs. 캐시·압축·자동 압축 창·스킬 재첨부는 Claude가 원문을 직접 읽었다. Ultracode·워크플로의 비용 문구와 서브에이전트의 시작 구성은 같은 세션의 독립 검증 에이전트가 원문과 다시 대조했다.
- 로컬 기록:
~/.claude/projects의 Claude Code 대화 기록(2026-08-12~09-25). 분석 스크립트는 세션 임시 폴더에서 실행해 보존하지 않았다. 다시 계산할 수 있도록 방법을 아래에 적는다. verified: true는 대화·공유 글·공식 문서·로그 계산 결과에 대한 이 요약의 충실도를 뜻한다. 비공식 사용량 가중치의 정확성이나 절감 추정의 실제 효과를 뜻하지 않는다.
구독 사용량을 좌우하는 것
공유 글이 인용한 외부 측정(she-llac.com/claude-limits, alldonesites.com/claude-usage-tracker)은 구독 사용량이 API 요금과 다르게 계산된다고 본다. 캐시 읽기는 거의 0(입력 단가의 약 0.2%), 캐시 쓰기는 1시간 캐시를 포함해 입력 단가, 출력은 입력의 5배로 세며, Fable 5.1은 같은 토큰에 Opus 5의 약 2.11배다. Anthropic이 발표한 수치가 아니므로 이 노트의 비중과 절감률은 모두 이 가정 위의 추정이다.
공식 문서로 확인한 캐시 동작은 다음과 같다.
- 모델마다 캐시가 따로다.
/model전환, 모델을 지정한 스킬·명령 호출, 안전 분류에 따른 자동 모델 전환은 다음 요청에서 대화 전체를 캐시 없이 다시 처리한다. - effort 변경은 대부분의 모델에서 캐시를 깨지만, Opus 5.5와 Fable 5.1은 API 키나 구독에서 캐시가 유지된다. Fable 5.1은 2.1.260부터 그렇다.
- 구독의 플랜 포함 사용량 안에서 메인 대화의 캐시는 1시간, 서브에이전트·워크플로·포크·압축 요청은 5분 유지된다. 한도를 넘어 추가 사용량을 쓰면 메인 대화도 5분이 된다.
- 캐시가 살아 있을 때의
/compact는 요약 요청이 캐시를 읽어 저렴하다. 캐시가 만료된 뒤에는 대화 전체를 캐시 없이 다시 처리한다. - 압축 뒤에는 CLAUDE.md, 경로 조건이 없는 rules, auto memory를 디스크에서 다시 읽는다. 호출했던 스킬 본문은 스킬당 5천 토큰, 합계 2.5만 토큰까지 요약 뒤에 다시 붙는다.
- 포크의 첫 요청은 부모 대화의 캐시를 읽는다. 일반 서브에이전트는 자체 시스템 프롬프트·CLAUDE.md·git status로 새 대화를 시작하며 부모 캐시를 읽지 않는다.
이 전제에서 사용량을 키우는 것은 긴 대화 자체가 아니라 캐시가 깨져 대화 전체를 다시 쓰는 재작성과 출력이다.
Claude Code 기록 분석
요청은 requestId 기준으로 한 번만 셌고, 재개·포크한 세션 파일에 복사된 요청도 전역으로 한 번만 셌다. 한 번에 5만 토큰 이상이면서 컨텍스트의 절반 이상을 새로 쓴 요청을 재작성으로 보고, 직전 요청과의 모델·effort·공백 시간·압축 여부로 원인을 나눴다. 위의 비공식 가중치에 Fable 모델 2.11배를 적용했다.
최근 2주(2026-09-11~24, 메인 세션 31개, 요청 2,941건):
- 사용량은 출력 57.6%, 캐시 쓰기 38.4%, 캐시 읽기 3.9%로 구성된다. 출력 토큰의 약 2/3가 thinking이고 거의 전부 max effort였다. 모델별로는 Fable 5.1 52.0%, Opus 5.5 42.7%, Opus 5 5.3%다.
- 재작성 38회가 사용량의 13.9%다(공유 글 작성자는 37%). 1
3시간 공백 10회·6.2%(회당 중앙값 약 25.5만 토큰), 312시간 공백 4회·3.5%(약 51.6만), 세션 시작 11회·1.4%, 압축 직후 11회·1.2%, 12시간 초과 공백 1회·1.0%, 원인 불명 1회·0.6%다. 모델 전환으로 생긴 재작성은 없었다. - 압축은 모두 수동 26회였고 압축 시점의 중앙값은 약 72.2만 토큰이다. 자동 압축은 걸리지 않았다. 세션 최대 컨텍스트의 중앙값은 약 34.3만이며 70만을 넘은 세션이 6개다.
6주(2026-08-12~09-24, 메인 세션 112개):
- 재작성 189회가 사용량의 30.6%다. 모델 전환 49회·7.9%(캐시가 살아 있던 43회의 회당 중앙값 약 24.5만), 12시간 초과 공백 34회·6.4%, 1
3시간 공백 37회·6.2%, 원인 불명 21회·4.6%, 312시간 공백 13회·3.0%다. - 원인 불명 재작성 21회는 모두 2.1.227~2.1.260 버전에서 나왔고 이후 버전에서는 없었다.
- 서브에이전트 체인 24개가 사용량의 1.4%이고, 첫 요청에서 새로 쓴 토큰의 중앙값은 약 2.05만이다. 공유 글 작성자의 측정치는 4~5천이다.
최근 2주 기준의 단순 시뮬레이션:
- 1시간 넘게 비운 15만 토큰 이상 세션을 떠나기 전에 압축했다면 15회, 순절감 약 8%다. 떠날 것을 미리 안다는 가정의 상한이다.
- 1~3시간 공백을 keep-alive로 막았다면 10회, 약 6%다.
- 자동 압축 창은 40만 −0.2%, 50만 +2.2%, 60만 −1.3%로 나왔다. 기존 수동 압축 비용을 이중으로 세는 한계를 보정하면 각각 약 +1%, +3%, 0%다. 6주 전체로는 40만이 약 7
8%, 60만이 약 23%다. 최근에는 이미 수동으로 압축하고 큰 컨텍스트의 재작성이 줄어 창 설정의 효과가 작다.
대화에서 정한 것과 권고
자리 비우기 전 압축. 15만 토큰이 넘는 세션을 1시간 넘게 두고 나중에 이어갈 때는 마지막 응답 뒤 1시간 안에 /compact를 실행한다. DanzzaN이 인자 없이 해도 되는지 물었고, 인자 없이도 요약되며 인자는 요약에서 우선 남길 내용을 지정하는 선택 사항이라고 답했다. 채팅으로만 준 지시는 요약에서 빠질 수 있으므로 계속 지킬 규칙은 CLAUDE.md나 프로젝트 문서에 두거나 압축할 때 덧붙인다. 캐시가 식은 뒤에는 압축하지 않고 그대로 이어가거나 인계 뒤 새 세션을 연다.
모델은 세션 단위. 최근 2주에는 모델 전환 재작성이 없어 이미 지켜지고 있다. 잠깐 다른 모델이 필요하면 /model 대신 모델을 지정한 서브에이전트를 쓴다. 서브에이전트 시작 비용은 모델 전환 재작성 1회의 약 1/12이다.
effort. 공유 글의 “effort는 세션 초반에 정하라”는 조언은 Opus 5.5·Fable 5.1에는 맞지 않으며, DanzzaN은 이를 좋은 소식으로 받아들였다. 출력이 가장 큰 비중이라 합의된 수정 적용·테스트 실행 같은 기계적 구간의 effort를 낮출 여지가 있지만 품질 영향은 측정하지 않았다. Opus 5는 effort를 바꾸면 여전히 캐시가 깨진다.
keep-alive는 도입하지 않는다. DanzzaN도 원하지 않는다고 했다. 공식 기능이 없어 외부 플러그인이나 별도 자동화가 필요하고, 병렬 세션마다 핑을 보내야 하며, 자리 비우기 전 압축이 대부분의 경우를 덮는다.
자동 압축 창 60만. DanzzaN이 600k를 선택했고, Claude가 ~/.claude/settings.json에 "autoCompactWindow": 600000을 추가했다. JSON 유효성, 정수형과 허용 범위(10만100만), 이 값을 덮어쓰는 환경변수·프로젝트 설정이 없음을 확인했다. 1M 창 모델의 기본 압축 지점은 약 96.7만이다. 사용량 절감보다 70만90만대까지 커지는 세션의 상한과 수동 압축 누락 방지가 목적이다. 작업 도중 자동 압축이 걸릴 수 있으므로 큰 작업 전에는 직접 압축하는 편이 낫다. 이미 열린 세션에 반영되는지와 실제 효과는 확인하지 않았다.
서브에이전트와 Ultracode. Claude는 “서브에이전트 적극 활용”을 전역 지시로 두지 말자고 권했고, DanzzaN의 채택 여부는 이 대화에서 확인되지 않았다. 서브에이전트는 시작할 때마다 자체 시스템 프롬프트·CLAUDE.md·git status를 새로 쓰고 메인 대화가 읽은 파일을 다시 읽는다. 공식 문서도 반복 작업이나 단계 사이에 맥락을 공유하는 작업은 메인 대화를 권한다. 이득이 확실한 경우는 모델 전환 대체, 테스트·로그·대량 검색처럼 출력이 큰 작업의 분리, 메인 맥락과 독립된 검토다.
Ultracode는 xhigh effort와 자동 워크플로 오케스트레이션을 묶은 설정이며, 공식 문서는 워크플로 한 번이 같은 일을 대화로 할 때보다 토큰을 눈에 띄게 더 쓸 수 있다고 적는다. Claude는 틀리면 비싼 작업에만 턴 단위로 쓰기를 권했다. 메시지에 ultracode라는 단어가 들어가기만 해도 그 턴이 워크플로로 처리되며, 설정 workflowKeywordTriggerEnabled: false로 이 키워드 동작을 끌 수 있다. 이 대화에서도 질문 속 단어 때문에 에이전트 8개 워크플로가 실행되어 최근 2주 사용량의 약 1%에 해당하는 양을 썼고, 그 교차 검증에서 Claude의 첫 로그 분석이 복사된 요청을 중복 집계한 오류가 드러났다.
Vault 조회 구조와 스킬 전환 판단
DanzzaN이 Vault를 읽으러 가는 현재 구조를 유지할지, 스킬로 되돌릴지 물었다. Claude는 현재 구조 유지를 권했다. 이 판단은 원격 Vault 정본과 쓰기 운영 결정 - Codex 대화 > 활성·비활성 스킬의 재평가 — 2026-09-20에서 정한 실사용 확인의 관찰 1건이며, 개편 뒤 행동 개선의 입증은 아니다.
- 조회 비용: 2026-08-12~09-25 메인 세션 119개 중 33개가 Vault를 읽었다. 세션당 호출 중앙값은 3회, 결과는 약 1.3만 자이고, 다음 요청의 새 쓰기로 추정한 상한도 약 1.3만 토큰이다. 가장 많이 읽은 세션은 Vault 운영을 정비한 세션으로, 호출 20회 중 6회가 쓰기 직전마다 다시 읽은 안내 문서 조회였다.
- 캐시: Vault 도구는 필요할 때 불러오는 방식이라 연결 변화가 캐시를 깨지 않고, 읽은 결과는 대화 끝에 붙는다. 스킬 본문도 호출 시점에 대화에 덧붙으므로 비용상 차이가 없다. 스킬로 바꿔도 같은 조회 경로 규칙을 본문에 담아야 하고, 판단 근거인 Source·Atomic은 여전히 Vault에서 읽는다.
- 스킬로 되돌릴 때의 문제: 스킬은 앱마다 따로 두므로 사본이 생긴다. 확인 당시 Claude 스킬 8개와 Codex 스킬 12개 중 공통은 4개였고, verification-before-completion은 이미 Codex판과 Claude판 두 벌이었다. 또한 Vault는 읽을 때마다 최신 commit을 받지만 스킬은 복사 시점에 멈추며, 스킬 자동 호출은 설명 문구가 요청과 맞아야 걸린다. 반면 “언제 Vault를 볼지”는 CLAUDE.md에 있어 매 세션 로드되고 압축 뒤에도 다시 읽힌다.
- 스킬이 나은 점: 압축 뒤 호출했던 스킬 본문이 다시 붙는다. 다만 안내 문서를 다시 읽는 비용이 수천 토큰이라 결정적이지 않다.
- 되돌릴 조건: Vault를 봐야 할 요청에서 보지 않거나 엉뚱한 Map으로 가는 누락이 반복되고, 진입 지침과 안내 문서를 고쳐도 계속될 때 그 부분만 얇은 스킬로 만든다. 원격 Vault 정본과 쓰기 운영 결정 - Codex 대화 > Vault 직접 읽기로 스킬 역할 대체의 기준과 같다.
이번 세션은 [비공개 문서] → 에이전트 문서 작성 → 위 Source의 순서로 필요한 근거에 도달했다.
대화 중 정정
- 공유 글 본문의 “40K”는 이미지의 “40만(400K)“을 잘못 쓴 것이다. 댓글들은 40K로 받아들였지만
/autocompact는 10만~100만만 받는다. - 댓글의 “포크하면 세션 전체를 다시 읽어서 비효율”은 캐시가 살아 있으면 맞지 않는다. 포크의 첫 요청은 부모 캐시를 읽는다. 다만 큰 컨텍스트를 그대로 물려받으므로, 나중에 이어갈 일은 인계 뒤 새 세션이 이후 재작성을 줄인다.
- Claude의 첫 분석은 재개·포크한 세션 파일에 복사된 요청을 두 번 세어 총량이 약 20% 부풀었다. 전역 중복 제거로 다시 계산해도 결론은 같았고, 이 노트의 수치는 정정한 값이다.
적용 경계
- Claude Code 기록만 대상이다. Codex는 캐시·사용량 체계가 달라 이 수치를 옮기지 않는다.
- 비중과 절감률은 비공식 가중치 위의 단순 시뮬레이션이며 품질 영향은 측정하지 않았다.
- 최근 2주 사용량의 거의 전부가 Vigilantis 저장소와 그 워크트리 세션에서 나왔다.