지난 주에 클로드 사용 한도 (usage limit)가 사라졌다는 이메일을 받으며 일어났습니다. 평소와 다름이 없었죠 — 또는 그렇게 생각했습니다.
로컬 세션 로그를 뒤져 보니, 범인은 밤새 전에 설정한 단일 /loop 명령어였습니다. 30 분마다 열린 PR 을 확인하기 위해 설정했는데, 이를 잊어버린 것입니다. 클로드 오퍼스 4-7(claude-opus-4-7) 에서 26 시간 동안 46 회 연속 실행되어, 깨어나기 전에 약 $6,000 의 비용을 발생시켰습니다.
그런데 중요한 점은... Anthropic 대시보드에서 수동으로 확인했을 때 그 비용의 일부만 표시되었습니다. 대시보드는 여러 일간의 보고 지연 (multi-day reporting lag) 을 가지므로, 한도 이메일이 도착하기 전까지 문제가 무엇인지 알지 못했습니다.
왜 이렇게 많은 비용을 발생시켰을까요? 사람들이 모르는 부분입니다.
클로드 API 호출은 최신 메시지뿐만 아니라 전체 대화 기록을 전송합니다. 1 번 턴 (Turn) 은 수백 토큰을, 46 번 턴은 80 만 토큰을 전송합니다. 컨텍스트 윈도우 제한은 단지 천장일 뿐이며, 각 턴마다 전송된 모든 것을 비용으로 지불해야 합니다.
이를 더 저렴하게 만들기 위해 Anthropic 은 프롬프트 캐싱 (prompt caching) 을 사용합니다: 대화 기록이 최근 전송되었던 경우, 12.5 배 할인 (12.5× discount) 으로 캐시에서 제공하는 대신 다시 비용을 청구하지 않습니다.
그런데 함정은... 캐시 항목은 ~5 분의 불활성화 (inactivity) 후에 만료됩니다. (과거에는 1 시간이었음)
따라서 /loop 30m 와는 다음과 같은 일이 발생합니다:
- 루프 실행 → 기록이 캐시됨 → 30 분 경과 → 캐시 만료
- 루프 다시 실행 → 캐시 없음 → 전체 대화 기록을 비싼 쓰기 속도 (write rate) 로 처음부터 재캐싱해야 함
- 각 반복은 또한 자신의 출력을 대화에 추가하므로, 다음 재캐시는 더 큽니다
20 시간 시점까지 대화는 ~80 만 토큰으로 성장했습니다. 모든 밤새 반복은 비싼 쓰기 속도 (write rate) 로 80 만 토큰을 재캐싱하는 비용을 지불했습니다. 실제 PR 확인 응답은 이에 비해 소수점 오류에 불과했습니다.
다른 방식으로 무엇을 할까
- /loop 에 항상 종료 조건 (stop condition) 을 추가하세요. 다음 명령어 대신: /loop 30m check my PRs 를 쓰세요. /loop 30m check my PRs — stop when all are merged or after 3 hour 로 작성하세요. 클라우드는 조건이 충족될 때 루프를 스스로 종료합니다.
- 자동 대기 작업에는 오퍼스 (Opus) 대신 소넛 (Sonnet) 을 사용하세요: 오퍼스는 출력 토큰당 약 5 배 더 비쌉니다. PR 확인과 같은 자동 폴링 작업은 소넛이 충분히 처리합니다. 오퍼스는 실제 존재하고 품질 차이가 중요한 작업에 사용하세요.
- 대시보드를 실시간 예산 지표로 신뢰하지 마세요: Anthropic 의 사용 대시보드는 여러 일간 지연될 수 있습니다. 스파이크가 표시되는 순간까지 돈은 이미 지출됩니다. 한도 알림 이메일이 유일한 실시간 신호일 수 있습니다.
- 긴 세션 유지 비용이 무료는 아닙니다: 자동 작업용에 하나의 큰 세션을 유지하는 것은 캐싱을 통해 비용을 절약하지 않습니다 — 오히려 더 나쁘게 만듭니다. 5 분 이상의 간격 (gap) 을 가진 각 자동 호출은 전체 성장한 컨텍스트를 재캐싱하는 비용을 지불합니다. 새 세션을 시작하는 것이 종종 더 저렴합니다.
- max_turns 은 루프 제한자가 아닙니다: max_turns 은 단일 반복 내의 도구 호출 체인 (tool-call chain) 을 제한합니다. 루프가 몇 번 실행되는지에 영향을 주지 않습니다. /loop 의 유일한 내장 만료는 7 일 자동 삭제입니다.
- 루프는 메인 대화에서 실행되므로, 같은 세션을 계속 사용하고 루프가 실행 시작하면, 각 루프마다 더 많은 토큰이 캐시에서 읽기/쓰기가 필요합니다.