$ crontab -l
0 */6 * * *  claude -p "summarize overnight logs" >> digest.md

이 한 줄의 명령어가 이 글 전체에서 가장 비용이 많이 드는 습관입니다.

Pro 또는 Max 구독은 모델을 호출할 수 있는 속도에 제한을 둡니다.

지출(Spend)은 별개의 문제이며, 대부분의 사람들은 이 두 가지를 하나로 간주합니다.

2026년 6월 15일 Anthropic의 과금 분리(billing split) 이후, 이러한 혼란은 더 이상 이론적인 문제에 그치지 않습니다.

저는 매일, 하루 종일 Claude Code를 실행합니다.

과금 변경 사항이 제 편지함에 도착했을 때, 저는 제 사용량이 어디에서 조용히 새어나갈지 파악하는 데 일주일을 보냈습니다.

대시보드에는 여전히 "구독(subscription)"이라고 표시되어 있지만, 비용을 두 배로 만드는 다섯 가지 패턴이 있습니다. 그 내용은 다음과 같습니다.

1. 헤드리스 크론(Headless crons)은 별도의 계량기로 과금됩니다

이 포스트 상단의 명령어를 보십시오.

6시간마다 실행되는 크론(cron), 출력 모드(print mode), 파일에 추가하기. 겉보기에는 무해해 보입니다.

대화형(Interactive) Claude Code와 헤드리스 출력 모드는 항상 동일한 잔액에서 차감되지 않습니다.

과금 분리 이후, 에이전트 방식의 헤드리스 호출(agentic headless invocations)은 고정 구독이 아닌 사용량 기반(metered) 경로를 통해 처리됩니다.

따라서 크론은 영원히 실행되고, 당신은 키보드에 손도 대지 않지만, 계량기는 내내 돌아갑니다.

자동화는 괜찮습니다. 누수(leak)는 모델 호출이 어디에 위치하느냐에 달려 있습니다.

준비 과정과 사고 과정을 분리하십시오.

일반 셸 작업(shell job)이 정해진 일정에 따라 데이터를 수집하게 하고, 대화형 세션이 당신의 의도에 따라 이를 소비하게 하십시오.

모델 호출만 구독 범위 내로 다시 옮기고, 지루한 데이터 이동은 일반적인 스크립트에 맡기십시오.

2. 필요하지 않은 작업에 높은 추론 노력(Reasoning effort) 설정

노력 단계(Effort tier)는 대부분의 사람들이 절대 건드리지 않는 제어 요소입니다.

높은 노력 단계는 더 긴 추론 체인(reasoning chains)을 의미하며, 체인이 길어질수록 턴당 더 많은 출력 토큰(output tokens)이 발생합니다.

돈이 들어가는 곳은 바로 출력 토큰입니다.

변수 이름을 바꾸는 데 최대 단계를 사용하는 것은 혈압을 재기 위해 심장 전문의를 고용하는 것과 같습니다.

저는 일상적인 유지보수는 낮은 단계로 기본 설정하고, 추가적인 추론이 정답을 바꿀 수 있는 두 곳인 디버깅(debugging)과 아키텍처(architecture) 설계에만 높은 단계를 유지합니다.

그날 아침의 기분에 맞추는 것이 아니라, 결정의 영향 범위(blast radius)에 맞춰 티어(tier)를 맞추십시오.

여기서 비대칭성(asymmetry)이 중요합니다.

어려운 문제에 대해 추론(reasoning)을 부족하게 하면, 빌드 오류와 두 번째 시도라는 대가를 치르게 됩니다.

쉬운 문제에 대해 과도하게 추론하면, 하루 종일 조용히 매 턴마다 토큰 비용을 지불하게 됩니다.

3. 5분간의 캐시 절벽 (Five-minute cache cliff)

프롬프트 캐싱(Prompt caching)의 유효 기간은 짧습니다.

대략 5분 정도 유휴 상태(idle)가 지속되면 대화 캐시가 만료됩니다.

그러면 다음 턴에서 캐싱되지 않은 상태로 전체 컨텍스트(context)를 다시 읽게 됩니다.

긴 세션의 경우, 이는 커피를 마시고 돌아올 때마다 매번 수천 개의 토큰이 전체 요율로 청구됨을 의미합니다.

프롬프트 사이의 간격이 긴 느린 세션을 주의하십시오.

캐시 윈도우(cache window) 내에서 흐름을 유지하거나, 아니면 압축하여 새로 시작하십시오.

신선하고 가벼운 컨텍스트가 캐시를 계속 놓치는 오래되고 비대한 컨텍스트보다 저렴합니다.

사람들은 자신이 선택한 모델에 집착하느라 그 주변을 둘러싼 대화의 형태(shape)는 무시합니다.

그 형태가 비용의 절반을 차지합니다.

4. 실행당 확산되는 자동화 (Automation that fans out per run)

매 푸시(push), 매 이슈(issue), 매 풀 리퀘스트(pull request)마다 모델을 호출하도록 CI에 연결된 모든 것은 확산(fan-out) 요인이 됩니다.

개발자 한 명이라면 괜찮습니다.

하지만 하루에 40번씩 코드를 푸시하는 개발자 10명은 완전히 다른 청구서를 만들어냅니다.

이벤트당 발생하는 모델 호출을 무료 린트(lint) 단계처럼 취급하는 것이 실수입니다.

이벤트당 호출은 실제 비용이 발생하며, 사용자의 의도가 아니라 팀의 활동량에 따라 규모가 커집니다.

모델을 핫 패스(hot path)에 연결하기 전에, 설정 시 상상했던 해피 패스(happy path)가 아니라 바쁜 한 주 동안 발생할 수 있는 최악의 이벤트 볼륨(event volume)을 산정하십시오.

대부분의 놀라운 청구서는 완벽하게 작동하는 자동화에서 발생합니다.

그것이 핵심입니다. 그것은 완벽하게, 정해진 일정에 따라, 영원히 작동했습니다.

5. 항상 로드되어 있는 도구들 (Always-loaded tools)

연결된 모든 도구 서버(tool server)는 그 정의(definitions)를 컨텍스트로 전송합니다.

연결된 도구 세트가 풍부하면 단 한 단어를 입력하기도 전에 수만 개의 토큰을 실어 나를 수 있습니다.

그 무게는 세션 내의 모든 요청에 함께 실려 갑니다.

저는 의존성(dependencies)을 감사(audit)하는 것과 같은 방식으로 연결된 서버들을 감사합니다.

만약 도구 세트(tool set)가 컨텍스트(context) 내에서 제 역할을 다하지 못하고 있다면, 나중에 유용할지도 모른다는 막연한 추측으로 계속 실행해 두는 대신 연결을 해제합니다.

유휴 도구(Idle tools)는 공짜가 아닙니다.

그것들은 해당 세션이 끝날 때까지 당신이 보내는 모든 프롬프트(prompt)에 부과되는 상시 세금과 같습니다.

이 다섯 가지를 하나로 묶는 것

이 중 그 어느 것도 버그가 아닙니다.

모두 시스템이 당신이 지시한 대로 정확하게 수행하고 있는 결과입니다.

대시보드에는 여전히 구독 상태가 표시되고 작업은 여전히 완료되기 때문에, 비용이 두 배로 늘어나는 현상은 눈에 보이지 않은 채 유지됩니다.

비용은 당신이 직접 소비하는 것을 인지하지 못했던 토큰(tokens)이라는 한 단계 아래의 영역에서 나타납니다.

이러한 누수(leaks)는 2026년 6월 15일의 분할(split) 이전부터 존재해 왔습니다.

구독이라는 완충 장치를 제거함으로써 그것들이 눈에 보이게 된 것입니다.

이제 저의 규칙은 간단합니다.

구독을 지출 한도(spend cap)가 아닌 속도 제한(rate cap)으로 취급하십시오.

비싼 영역(expensive surface), 즉 모델 호출(model call), 노력 단계(effort tier), 그리고 로드된 도구들(loaded tools)을 짧은 목줄로 묶어 관리하십시오.

기계적인 모든 작업은 과금되는 호출(metered call)에 절대 닿지 않는 더 저렴한 차선으로 옮기십시오.

이러한 패턴들에 대한 더 긴 목록은 한 포스트에 담을 수 없을 정도로 제 노트에 많이 기록되어 있습니다.

현재 당신의 설정에서는 어떤 것이 누수되고 있으며, 그것을 어떻게 찾아내셨나요?