클로드 코드 토큰 한도 아끼는 방법 7가지

클로드 코드(Claude Code)에 일을 몰아주다 보면 묘하게 마음이 급해질 때가 있습니다. 세션 한도가 얼마 남지 않았다는 알림을 받고 난 이후부터입니다. 아직 고칠 곳이 남았는데, 눈은 자꾸 얼마 남지 않은 토큰 한도 게이지로 갑니다. 페이블(Fable)이 나온 뒤로는 더 심해졌습니다. 그렇다고 계정을 늘리기엔 눈치가 보입니다. 누구는 한도가 펑펑 남는다는데, 대체 어디서 이렇게 차이가 나는 걸까요.

그러다 이 궁금증을 조금 풀어볼 만한 글을 만났습니다. 각각 실제 클로드 코드를 만드는 앤트로픽(Anthropic)의 엔지니어인 애디 오스마니(Addy Osmani), 타리크 시히파(Thariq Shihipar)가 쓴 글들인데요. 실제로 이들이 자기 제품으로 실험하며 알아낸 토큰을 아껴 쓰는 법에 대한 소개였습니다.

읽다 보니 한도를 확인할 때 놓치고 있던 것들이 보였습니다. 대화를 길게 끌고 간 세션, 도중에 내키는 대로 바꾼 설정, 결과가 틀려 다시 시킨 횟수. 막연히 생각은 했는데 귀찮아서 제대로 적용하지 않았던 방법들을 아주 깔끔하게 정리해 주더라고요. 뼈를 맞은 느낌이었지만, 또 당장 해볼 게 정말 많아 꽤 고마웠습니다.

그래서 그 글을 바탕으로 클로드 코드를 쓸 때 챙길 만한 토큰 절약 방법을 7가지로 정리했습니다.

• 애디 오스마니, What a task costs on Opus 5.5
• 타리크 시히파, Spending your effort

본문에서 이탤릭체로 표시한 대화체는 원문을 한국어로 옮긴 직접 인용입니다.

1. 불필요한 재시도와 의미 없는 맥락을 줄인다

클로드 코드는 도구를 실행하고 결과를 읽으며 작업을 이어갑니다. 이때 새 요청에는 앞서 나눈 대화도 함께 들어갑니다. 오스마니의 설명에 따르면, “매 턴 지금까지의 대화를 다시 보내”는 겁니다. 한 번만 더 해달라고 짧게 적어도 이미 읽은 파일과 테스트 결과까지 다시 보냅니다. 모델에 보낸 메시지의 길이만 보고 사용량을 짐작하기 어려운 이유죠.

예시를 볼게요. 대화가 2만 토큰에서 12만 토큰까지 커지는 작업을 40회에 끝내면 누적 입력은 약 280만 토큰입니다. 만약 이를 25회 만에 끝내면 약 175만 토큰만 들어가고요. “턴이 적으면 처리하는 입력도 줄어들”기에 같은 수정을 불필요하게 반복하고 있지는 않은지 볼 만합니다.

만약 무관한 일로 넘어갈 때는 /clear로 대화를 비워 지난 작업의 맥락이 계속 따라오지 않게 합니다.

그렇다고 같은 일을 하던 대화까지 자꾸 끊을 필요는 없습니다. 계속 이어가는 동안 반복되는 내용은 캐시에서 재사용할 수 있습니다. 얼마나 많이 보냈는지와 함께, 그중 얼마나 다시 쓸 수 있었는지도 봐야 하는 거죠. 이 캐시를 유지하려면 세션 도중에 바꾸는 설정에도 신경을 써야 합니다.

2. 캐시 고쳐 쓰기를 줄인다

시스템 프롬프트와 도구 정의, 앞서 나눈 대화처럼 반복되는 내용은 캐시에 저장해뒀다가 다시 읽습니다. 그런데 작업 도중 설정을 바꿔 요청 앞부분이 달라지면 그 뒤는 캐시에 새로 써야 할 수 있습니다. 캐시는 요청의 처음부터 이어지는 부분, 즉 접두어를 기준으로 작동합니다. 직전 요청과 앞에서부터 일치하는 만큼 재사용하는 거죠. 계속 일하면서 대화 끝에 새 내용만 붙이는 동안은 캐시도 잘 유지됩니다.

문제는 요청 앞부분을 바꿨을 때입니다. 바뀐 곳 뒤로는 캐시에 새로 써야 합니다. 캐시에 남아 있는 시간도 정해져 있습니다. 클로드 구독은 1시간, API 키나 클라우드 제공자는 5분입니다. 구독으로 쓰더라도 추가 사용 크레딧을 사용하기 시작한 뒤에는 캐시 수명이 5분으로 줄어듭니다.

그러면 어떤 행동이 캐시를 새로 쓰게 만들까요? 오스마니가 예로 든 경우는 모두 여섯 가지입니다. 1) 캐시 수명보다 오래 쉬었을 때, 2) 아마존 베드록·구글 클라우드 에이전트 플랫폼·게이트웨이에서 추론 강도를 바꿨을 때 그렇습니다. 3) 대화 중 처음 빠른 모드를 켜거나 4) MCP 서버를 연결·해제했을 때도 해당합니다. 5) 모델을 바꾸는 일과 6) 대화를 컴팩트하는 일까지 포함되고요.

그러니 세션을 열 때 미리미리 정리해두면 좋겠습니다. 시작할 때 한 번 불러온 CLAUDE.md는 이후 모든 턴에 다시 전송되기 때문에 200줄 이하로 유지하라고 합니다. /mcp로 연결된 서버를 보고 쓰지 않을 것은 끄고요. 빠른 모드가 필요한 작업이라면 시작할 때 켜두는 편이 낫습니다. 한참 일한 뒤에 속도가 답답하다고 켜면 앞에서 쌓은 캐시를 다시 써야 하니까요.

턴마다 모델이 사고와 출력에 쓸 토큰의 양을 정하는 설정인 추론 강도(effort)는 약간 다르다고 합니다. 클로드 구독자와 API 키 사용자는 이 강도를 바꿔도 캐시가 유지됩니다. 베드록·구글 클라우드 에이전트 플랫폼·게이트웨이에서 바꿀 때 캐시가 지워지는 거죠. 구독으로 쓰는 중이라면 필요할 때 올리고 내리면 됩니다. 작업에 맞춰서요.

3. 검사 수단이 재시도를 줄인다

클로드가 고친 결과를 받아봤는데 영 마음에 들지 않으면 다시 해달라고 시키게 됩니다. 그럴 수밖에요.

그런데 세션을 오래 이어왔다면 이 짧은 부탁, “다시 해봐”에 따라가는 내용도 많아집니다. 앞에서 쌓인 대화까지 전부 보내야 하니까요. 한 시간 전에 본 오류 추적 기록도 여기 들어 있습니다. 다 읽은 파일, 이미 고친 테스트의 실행 출력까지 계속 따라옵니다. 지금 하는 일과 별 상관도 없는 내용을 계속 읽히며 토큰을 태우는 건 좀 아깝습니다.

그래서 오스마니는 세 가지 구체적인 방법을 제시합니다. 우선 1) 모델에 자기 작업을 직접 검사할 수단을 주라고 권합니다. 돌려볼 테스트나 빌드, API 주소를 호출하는 스크립트 같은 것들이요. 사람이 결과를 받아보고 다시 돌려보내기 전에 클로드 스스로 잘못된 부분을 찾을 수 있다면 그만큼 되돌려보낼 일도 줄어듭니다. 필요한 정보를 한 번에 모으고 도구 호출을 묶어서 보내는 것도 재전송을 줄여주고요.

그 맥락에서 건드릴 파일이 여러 개라면 2) 시작부터 계획 모드로 하는 것도 좋은 방법입니다. 어디를 어떻게 바꿀지 먼저 맞춰두면 구현이 한참 진행된 뒤 방향을 되돌릴 일이 줄겠죠.

3) 프롬프트도 한번 고쳐볼 만합니다. 예전 모델을 쓸 때 적어둔 필수 6단계 절차나 무조건 두 번 검증하라는 규칙이 남아 있을 수 있고 지시끼리 서로 부딪히고 있을 수도 있습니다. 꼼꼼하게 시키려고 넣은 규칙이 턴과 출력만 늘리고 있는지 /claude-api prompt-audit로 점검할 수 있습니다.

긴 실행이 끝난 다음, 무엇을 바꿨는지와 더 필요한 일이 무엇인지를 보고하는 Opus 5.5의 습성도 도움이 된다고 합니다. 끝난 작업의 상태를 알 수 있으니 확인을 위해 같은 세션을 다시 돌릴 수고를 덜게 됩니다.

4. 추론 강도는 작업에 맞춰 조절한다

엉뚱한 결과만 내며 맴도는 클로드를 보고 있으면 추론 강도를 올려볼까 싶어집니다. 더 생각하면 문제를 좀 풀겠지 싶은 거죠. 반대로 한도가 걱정되면 작은 모델로 내려가고 싶고요. 어느 쪽이든 추론 강도는 결과를 고치고 싶을 때 쉽게 손대는 설정입니다.

다만, 실제로 그래서 토큰을 덜 쓰고 일을 끝낼 수 있을지는 따져볼 일입니다. 추론 강도를 높이면 매 턴 사고에 쓰는 토큰이 늘어나기 때문입니다.

시히파의 Terminal-Bench 3.0 분석 글을 보면 높은 추론 강도가 어디서 도움이 되는지 좀 더 분명해집니다. 그는 과제마다 Fable 5.1을 5회씩 자체 실행했다고 하는데요, 낮음(low)에서는 370회 시도 중 140회가 통과했고 시도당 토큰 중앙값은 7만 3천이었습니다. 최대(max)로 올리자 통과는 214회, 토큰 중앙값은 22만 2천이 됐습니다. 토큰을 더 쓰고, 그만큼 문제는 더 잘 풀었습니다.

재밌는 건 실패 기록에서 나왔습니다. 예외 상황을 놓친 실패가 59건이었는데, 추론 강도를 높이자 24건까지 줄었습니다. 판단을 잘못 내린 경우도 줄기는 했습니다. 133건에서 107건으로요. 높은 추론 강도의 효과가 특히 크게 나타난 쪽은 예외 상황 누락이었다는 뜻입니다. 접근을 잘못 잡은 문제도 일부 개선됐지만 여전히 많이 남았습니다.

영역별 차이도 큽니다. 검증과 예외 상황 테스트가 중요한 보안의 통과율은 64%에서 87%로 올랐으며 하드웨어에서도 34%에서 75%로 상승했습니다. 절차가 정해진 운영 작업은 12%에서 22%에 그쳤고요.

결국 추론 강도를 높이는 건 실수를 줄이는 데는 도움이 되지만, 아예 못 하던 일을 하게 해주지는 않습니다.

시히파가 “모든 작업에 이 정도의 추론 강도가 필요한 것은 아닙니다.”라고 덧붙인 이유죠. 필요한 정보나 권한이 빠져 있다면 그것부터 줘야 합니다. 기다리는 사람이야 답답해 뭐라도 하고 싶을 테지만, 추론 강도로 해결할 수 있는 범위는 한정되어 있습니다.

그는 기능 개발을 시작하기에 앞서 모델의 인터뷰에 답하는 과정으로 빠진 세부 내용을 채운다고 합니다. 구현 단계에서는 “낮은 추론 강도로 구현합니다.”라고 적습니다. 의도에 맞게 가고 있는지 리뷰하며 반복할 때도 낮음을 쓰고요. 마지막 단계는 “높은 추론 강도로 검증하고 테스트합니다.”라고 적었습니다.

그의 경험칙으로는 낮음이 아이디어 구상과 쉬운 변경, 보통이 일반적인 기능 구현, 높음이 검증이 중요한 버그 수정에 맞습니다. 최대는 완전 자율로 맡길 어려운 문제에 쓰는 쪽이고요. 처음부터 끝까지 한 단계에 고정해둘 필요는 없겠습니다.

오스마니는 추론 강도를 올리기 전에 모델이 자기 작업을 검사할 방법이 있는지 확인하라고 권합니다. 검사 수단이 있는데도 버거워하면 /effort high로 올려볼 수 있습니다. 여러 파일에 이미 아는 패턴을 적용하는 기계적인 편집을 시켰다면 추론 강도만 낮음으로 내려볼 수 있습니다.

5. 목적에 따라 적절한 모델을 활용한다

추론 강도를 매우 높음(xhigh)까지 올렸는데도 같은 문제에서 두 번 이상 막히면 오스마니는 가장 성능이 높은 모델인 Fable 5.1로 바꾸라고 권합니다. “세 번째 실패를 기다리지 마세요.”라는 겁니다. 다만 모델을 바꿀 때는 자연스럽게 일이 끊기는 지점을 잡고 /compact를 먼저 돌리는 편이 좋습니다. 바뀐 모델의 첫 턴에서는 어차피 이전 대화 전체를 캐시에 새로 써야 하니까요.

작은 모델에는 어떤 일을 맡기면 될까요? 작은 모델이 검색 결과를 잘못 읽어 메인 모델을 엉뚱한 파일로 보냈다면 돌아가는 동안 다시 작업해야 합니다. 그러니 파일을 찾거나 로그와 테스트 출력을 읽는 조회처럼 실수가 쉽게 드러나는 일에 작은 모델을 씁니다.

서브에이전트는 별도 지정이 없으면 메인 모델을 물려받으니 여기도 확인할 만합니다. 정의에 model: haiku를 적거나 CLAUDE_CODE_SUBAGENT_MODEL 환경변수로 일괄 지정할 수 있습니다. 계획은 Opus가 세우고 코드 편집은 Sonnet이 맡게 하는 opusplan이란 별칭도 있다고 합니다.

6. 대화 요약은 쉬기 전에 한다

한참 일하다 자리를 비웠다 돌아옵니다. 그제야 /compact를 입력하기 쉽습니다. 대화가 길어졌으니 정리하고 시작하려는 거죠. 오스마니는 “쉬기 전에 컴팩트하세요.”라고 권합니다. 캐시가 살아 있을 때 정리하려면 자리를 뜨기 전으로 순서를 앞당기는 편이 낫습니다.

대화 요약(/compact)은 오래된 대화를 요약해 모델이 읽을 내용을 줄이는 기능입니다. 대화를 읽어 요약을 만든 다음 줄어든 내용을 캐시에 새로 저장합니다. 이후 턴에서는 읽을 내용이 줄어듭니다. 이제 끝낼 세션이라면 굳이 정리할 필요는 없고요.

단, 캐시는 아직 살아 있어야 합니다. 캐시 수명보다 오래 쉬고 와서 같은 /compact를 돌렸다면 대화 전체를 다시 읽고 써야 합니다. 어차피 이어갈 긴 작업이라면 캐시가 남아 있을 때 정리해두자는 얘기죠. 작은 습관인데 차이는 제법 난다고 합니다.

물론 요약을 하면 반드시 잃는 내용이 있습니다. 디버깅을 하던 중 컴팩트했다가 꼭 필요했던 로그 한 줄이 빠질 수 있습니다. 그러니 일이 잠시 매듭지어지는 데까지 기다렸다가 하는 편이 좋겠습니다. 다음 작업에 필요한 정보가 있다면 ‘/compact 실패한 테스트 이름과 스키마 변경 내용을 남겨줘’처럼 남길 것을 적어줍니다.

아예 무관한 작업을 시작할 때는 /clear로 대화를 비우면 됩니다. 잘못된 방향으로 진행했다면 /rewind로 이전 턴에 돌아갈 수 있고요. 캐시가 살아 있는 동안이라면 돌아간 접두어는 이미 저장되어 있습니다. 자동 대화 요약이 시작되는 시점을 조정하고 싶을 때는 /autocompact에 토큰 수를 주면 됩니다.

7. 끝난 뒤에는 /usage를 확인한다

실제로 내 작업에서는 어디에 많이 썼는지, 그건 직접 열어봐야 알 수 있습니다. 오스마니가 거듭 강조하는 것도 그 점입니다. 클로드 코드에서는 /usage나 같은 기능인 /cost를 실행하고 세션(Session) 영역을 보면 됩니다.

처음 볼 것은 캐시 비중입니다. 길게 이어간 세션이라면 비중이 높아야 합니다. 낮게 나왔다면 세션을 떠올려봅니다. 오래 쉬었던 때가 있는지, 모델을 바꿨는지, 도중에 MCP 서버를 붙였는지요. 프롬프트 캐시(prompt cache) 항목에 마지막 캐시를 재사용하지 못한 원인이 표시되는 경우가 많습니다.

입력에 비해 출력이 얼마나 많은지도 봅니다. 변경은 작은데 출력이 유난히 많다면, 추론 강도를 높게 잡았을 수도 있고 모델이 재시도를 반복했을 수도 있습니다.

대화 크기와 총입력도 함께 볼 만하고요. 총입력이 대화 크기의 몇 배로 커졌다면 턴이 많이 쌓였다는 뜻입니다. 그 수치를 보고 대화를 되짚으면 어느 대목에서 같은 일을 되풀이했는지 찾을 실마리가 생깁니다. 모델과 추론 강도를 바꿔가며 같은 작업을 서너 번 돌려보면서 내 사용 방식에 맞는 기준을 조금씩 잡아가는 게 좋겠습니다.

저도 이 글을 쓰다가 제 화면을 열어봤는데요. 지난 사용량의 원인으로 클로드 코드가 짚은 것은 긴 문맥, 그리고 서브에이전트였습니다. 일감은 잔뜩 맡겨두고 어떻게 줄여볼 생각은 안 한 채, 남은 한도 게이지만 보고 발을 동동 구르던 어제가 생각나네요. 정작 어디에 썼는지도 봐야 했던 거죠.

마치며: 한도를 쓴 만큼 일이 끝났으면 좋겠다

아직 클로드한테 시킬 일이 남아 있습니다. 사실 끝이 잘 안 납니다. 그럴수록 한도가 더 아깝게 느껴지죠. 물론 클로드가 언제나 어려운 문제를 붙들고 해결해주면 기다릴 만합니다. 그 대신 다 끝낸 줄 알았던 일을 다시 설명하고 같은 수정을 반복할 때는 좀 열받고요. 추론 강도를 낮추거나 작은 모델을 써서 아껴뒀어도 재시도가 길어지면 그만큼 다시 쓸 수 있습니다.

자주 한도에 걸린다면 CLAUDE.md에 어떤 지시를 쌓아뒀는지, MCP는 무엇을 켜놓았는지부터 살펴볼 만합니다. 클로드가 제 작업을 검사할 테스트가 있는지도 보고요. 오래 이어갈 일은 다음에 필요한 맥락을 남겨두고 자리를 뜨기 전에 컴팩트해둡니다. 습관을 바꾼 뒤 얼마나 달라졌는지는 /usage에서 확인해볼 수 있습니다.

지금이라도 모델과 추론 강도를 바꿨을 때 얼마나 쓰고 어디까지 끝냈는지 비교해 보세요. 어떤 작업을 하는지에 따라 크게 달라지니까요. 오스마니의 글도 직접 테스트해보라는 이야기로 끝납니다. 어디에 얼마나 쓸 수 있을지 정확히 안다면, 한도가 오는 것도 그리 무섭지만은 않을 겁니다. 한도를 모조리 다 썼다는 알림이 와도, 그건 오늘 하려던 일은 끝난 뒤였으면 합니다.

현재 FDE로 일하시거나, 최근 1년 내 일하셨던 분들은

“국내 FDE 현황 조사 2026” 참여하고, 리포트 & 네이버페이 포인트 받아가세요!

ⓒ요즘IT의 모든 콘텐츠는 저작권법의 보호를 받는 바, 무단 전재와 복사, 배포 등을 금합니다.