주간 한도 이틀 만에 바닥 — Claude Code를 일주일 버티게 만든 워크플로

9월 중순에 한도 정책이 바뀌고 나서 r/claudecode의 풍경이 좀 달아졌다. 주간 사용량이 예전 같지 않다는 불평이 하루에도 몇 개씩 올라온다. 그 와중에 흥미로운 글이 하나 올라왔다. 한도를 이틀 만에 전부 써버렸던 사람이, 세팅을 고쳐서 품질을 유지한 채 리셋 직전까지 버텼다는 이야기다.

불평 대신 최적화를 택했다는 것만으로도 눈에 띄는데, 읽다 보니 이게 단순한 절약 팁 모음이 아니다. 2026년에 코딩 에이전트를 실전으로 굴리는 사람이라면 누구나 부딪히는 문제에 대한 하나의 모범답안에 가깝다. 네 가지 변경점을 순서대로 풀어보려 한다.

비싼 모델은 계획만 세우게 한다

원작자가 가장 먼저 손본 건 모델 분업이다. Opus는 계획 수립에만 쓰고, 실제 구현은 Sonnet 서브에이전트에 맡긴다. 오케스트레이터와 실행자를 나누는 구조다.

사람 팀에 비유하면 이해가 빠르다. 시니어 엔지니어에게 타이핑을 시키지 않는다. 설계와 판단은 시니어가 하고, 코드를 치는 건 주니어에게 맡긴 다음 시니어가 검수하는 식으로. 비싼 모델의 토큰은 판단이 필요한 순간에만 쓰고, 나머지는 싼 모델이 흡수한다.

여기에 컨텍스트 축소가 더해진다. 100만 토큰짜리 컨텍스트를 40만으로 줄였다. 오래 열어둔 대화 창이 은근히 세금처럼 붙는 구조라는 걸, 한도에 쫓겨본 사람은 안다. 필요한 맥락만 남기는 다이어트만으로도 한 명의 여유가 생긴다.

검색과 문서도 아껴야 한다

두 번째 관문은 코드 검색이었다. 매번 에이전트가 코드베이스를 뒤지는 데 쓰는 토큰이 만만치 않았을 테니, 원작자는 Graft Graph(Trail-Code)를 붙여서 검색 관련 사용량을 30~40% 줄였다.

마지막이 개인적으로 가장 인상적인 부분인데, 세션별로 상황을 .md 문서로 남기고 다음 세션을 위한 프롬프트를 자동 생성하게 한 것이다. 새 세션이 시작될 때마다 맥락을 처음부터 설명하던 낭비가 사라진다. 문서가 세션 사이의 다리 역할을 하는 셈이다. 대략 이런 식이다.

## session-notes (10/17)

### 오늘 한 일
- auth 리팩터링: 세션 검증 로직을 미들웨어로 이동

### 현재 상태
- tests/auth.spec.ts 2개 실패 (토큰 만료 케이스)

### 다음 세션에서 할 일
1. 실패 케이스 수정
2. 리팩터링 범위를 router까지 확장할지 결정

### 맥락
- 인증은 쿠키 대신 Authorization 헤더 방식 유지

거창한 기술은 아니다. 그런데 에이전트를 오래 쓸수록 세션 간 연속성이 진짜 병목이 된다는 걸 체감하는 사람이 많아지는 중이라, 이런 소박한 프로세스가 오히려 효과를 본다는 대목이 신뢰가 간다.

왜 주목할까

이 글이 재밌는 건 같은 날 다른 커뮤니티와 나란히 놓으면 더 분명해진다. r/localllm에서는 중고 RTX 3090을 리페이스해서 디코드 속도를 43% 끌어올린 실측담이 올라왔고, r/openclaw에서는 멀티에이전트 파이프라인이 티켓 하나에 한도를 몇 번씩 태우는 사례가 호소됐다. 하드웨어 튜닝부터 토큰 누수까지, 결국 다들 같은 벽을 다른 방향에서 두드리고 있는 것이다. 토큰의 경제학.

댓글 반응도 그래서 진솔하다. Fable 5.1에서 Opus 5.5로 갈아타서 해결했다는 사람부터, 결국 한도에 부딪히는 사람이라면 누구든 자기 세팅을 분석해야 한다는 공감까지. 정답이 하나가 아니라는 뜻이겠지. 사용 패턴마다 새는 지점이 다르니까.

정리

한도는 벽이 아니라 예산이다. 예산이 정해지면 설계가 달라진다. 이 글에서 뽑아낼 수 있는 원칙은 사실 네 문장으로 압축된다. 비싼 모델은 계획에만, 싼 모델은 실행에. 컨텍스트는 얇게. 검색은 도구에게 맡기고. 세션은 문서로 이어라.

에이전트가 똑똑해질수록 쓰는 쪽의 설계가 결과를 가른다는 게 요즘 실전 커뮤니티의 분위기다. 이틀에 바닥났던 한도를 일주일로 늘린 건 마법이 아니라, 돈이 드는 순간이 어디인지 하나하나 들여다본 노력의 결과였다.