Claude를 쓰다 보면 생각보다 사용량 한도가 빨리 차는 날이 있습니다. API로 서비스를 만들고 있다면 청구서가 예상보다 크게 나오기도 합니다. 작업이 복잡해서만은 아니고, 긴 대화 기록을 끌고 다니거나 같은 파일을 여러 번 읽거나 필요 이상으로 긴 답변을 받는 데서 토큰이 새는 흔한 원인입니다.
LLM은 사람처럼 앞선 대화를 기억해 두고 이어 가는 구조가 아닙니다. 새 요청을 처리할 때마다 필요한 대화 기록과 관련 정보를 다시 입력으로 받습니다. 그래서 대화가 길어질수록 매번 처리하는 입력이 커지고, 코딩 작업에서는 파일 내용과 명령 실행 결과, 도구 호출 기록까지 컨텍스트에 쌓여서 증가 속도가 더 빠릅니다. 줄일 수 있는 방향은 두 가지입니다. 불필요한 내용을 반복해서 읽지 않게 하는 것, 그리고 작업에 필요한 만큼만 탐색하고 답하게 하는 것입니다. 아래는 웹 서비스, Claude Code, API 순으로 적용할 수 있는 방법을 정리한 내용입니다.
대화는 작업 단위로 끊기
가장 단순하면서 효과가 큰 습관은 주제가 바뀔 때 새 대화를 여는 것입니다. 로그인 오류를 잡으면서 로그 수십 개와 소스 코드를 훑은 대화에서 곧바로 기술 문서를 쓰기 시작하면, 문서와 상관없는 디버깅 기록이 계속 입력에 딸려 갑니다. 이전 작업이 길수록 낭비도 큽니다. 웹 서비스라면 새 채팅을 시작하고, 이어야 할 내용은 결정 사항과 현재 상태만 짧게 요약해서 붙여 주는 편이 낫습니다.
Claude Code에서는 /clear로 대화 기록을 비울 수 있습니다. 공식 문서도 관련 없는 작업으로 넘어갈 때 비우라고 권하는데, 오래된 컨텍스트는 이후 모든 메시지에서 토큰을 쓰기 때문입니다. 나중에 돌아올 세션이라면 /rename으로 이름을 붙여 두고 /resume으로 다시 열 수 있습니다. 작업을 이어 가야 하는데 대화가 너무 길어졌다면 /compact로 요약해서 압축합니다. 뒤에 지시를 붙여 무엇을 남길지 정해 줄 수도 있습니다.
/compact 인증 모듈의 변경 사항과 남은 작업을 중심으로 요약압축하면 세부 내용이 빠질 수 있으니 중요한 설계 결정이나 정확한 오류 메시지는 따로 적어 두는 것이 안전합니다. 또 /compact는 압축하려는 대화를 읽어야 하므로 컨텍스트가 큰 상태에서 실행하면 그 자체가 큰 요청이 됩니다. 새로 시작해도 되는 상황이라면 /clear 쪽이 비용이 들지 않습니다.
답이 마음에 안 들 때 "아니, 그게 아니라" 하고 대화를 이어 가는 것도 토큰을 많이 씁니다. 잘못된 답변과 정정 요청이 전부 맥락에 남기 때문입니다. 웹 서비스에서는 처음 보낸 메시지를 편집해 요청을 구체화하는 편이 깔끔합니다. Claude Code에서는 Esc를 눌러 진행을 멈추고 /rewind나 Esc 두 번으로 이전 체크포인트로 돌아갈 수 있다고 안내합니다. 다만 대화 기록을 되돌리는 것과 이미 실행된 명령이 바꿔 놓은 바깥 상태를 되돌리는 것은 별개의 문제라서, 되돌린 뒤에 실제 파일과 환경이 어떤 상태인지는 직접 확인해야 합니다.
요청은 처음부터 구체적으로
요청이 모호하면 Claude가 그만큼 더 탐색합니다. Claude Code는 프로젝트 구조를 보고, 여러 파일을 읽고, 관련 함수를 검색하는 과정을 거치기 때문에 "로그인 버그 좀 고쳐 줘"보다 "src/auth/login.ts의 validateToken에서 만료된 토큰이 통과하는 문제를 고쳐 줘"가 훨씬 적은 읽기로 끝납니다. 공식 문서에도 "코드베이스를 개선해 줘" 같은 요청은 넓은 스캔을 유발하고, 특정 파일의 특정 함수를 지목하면 최소한의 파일 읽기로 일한다는 설명이 있습니다. 대상 파일과 함수, 지금 일어나는 문제, 원하는 결과, 건드리면 안 되는 부분, 답변 범위를 함께 적어 주면 좋습니다.
src/auth/login.ts의 validateToken 함수를 수정해 줘.
문제: 만료된 JWT 토큰이 인증을 통과하는 경우가 있음
- 토큰 만료 시간 검증 추가
- 기존 예외 처리 방식 유지
- 다른 함수는 수정하지 않음
- 변경된 부분만 설명"테스트해 줘"보다 "변경한 함수와 관련된 단위 테스트만 실행해 줘"가 낫고, "오류 원인 찾아 줘"보다 "첨부한 스택 트레이스 기준으로 가능성 높은 원인 세 가지만 정리해 줘"가 낫습니다. 다만 원인을 전혀 모르는 장애 분석에서는 탐색 범위를 처음부터 좁히지 않는 편이 맞습니다. 범위를 좁히는 것은 어디를 봐야 할지 알 때 쓰는 방법입니다. 큰 작업은 코드를 바꾸기 전에 계획부터 확인하는 것도 방법입니다. Claude Code는 Shift+Tab으로 plan mode로 넘어가 접근 방식을 먼저 제안받을 수 있고, 방향을 잘못 잡은 채 대규모 수정을 했다가 되돌리는 비용을 줄여 줍니다. 계획 단계에서도 토큰이 들지만 잘못된 구현을 갈아엎는 것보다는 대체로 적게 듭니다. 검증할 기준, 예를 들어 테스트 케이스나 기대 출력을 요청에 넣어 두면 Claude가 스스로 결과를 확인하고 고치니 재요청도 줄어듭니다.
입력과 출력의 크기 줄이기
입력 자료의 크기는 토큰 사용량에 그대로 반영됩니다. 수만 줄짜리 애플리케이션 로그를 통째로 붙이는 것보다 오류 주변만 잘라서 주는 쪽이 낫습니다.
grep -B 10 -A 20 "ERROR" application.log오류가 여러 번 났다면 이 출력도 커질 수 있으니 시간대나 오류 종류를 먼저 좁힙니다. 수백 쪽 PDF를 올려놓고 설정 하나를 묻는 것도 비효율적이라서 관련 장만 추출해 주는 편이 좋습니다. Claude Code에서 테스트나 빌드를 돌리면 출력이 수천 줄이 되기도 하는데, npm test 2>&1 | tail -50처럼 꼬리만 자르면 정작 원인이 앞쪽에 있을 수 있습니다. 무조건 자르기보다 테스트 도구의 실패 요약 기능을 쓰거나, 훅(hook)으로 실패한 부분만 걸러서 보여 주는 방법이 있습니다. Claude Code 문서에는 10,000줄짜리 로그를 읽는 대신 훅이 ERROR 줄만 뽑아 넘겨서 컨텍스트를 수만 토큰에서 수백 토큰으로 줄이는 예시가 실려 있습니다.
출력도 토큰입니다. API에서는 보통 출력 토큰 단가가 입력보다 높아서 답변이 길수록 비용 영향이 큽니다. 간단한 설정 방법을 물었는데 배경과 역사까지 늘어놓는 답이 돌아오면 그만큼 낭비입니다. 결론만 세 줄로, 수정된 코드만, 설명은 생략, 각 항목은 한 문장으로처럼 형식과 분량을 지정하면 됩니다. 코드 수정에서 파일 전체를 다시 출력할 필요도 없고, 바뀐 부분만 보거나 실제 파일의 수정 결과를 직접 검토하는 편이 효율적입니다.
API의 max_tokens는 응답에 쓸 수 있는 최대 출력 토큰의 상한입니다. 분류나 짧은 요약 작업이라면 큰 값을 줄 필요가 없습니다. 이 값이 출력을 짧게 만들어 주는 것은 아니고 상한을 두는 것이라서, 너무 낮게 잡으면 응답이 중간에 잘립니다.
모델과 추론 강도 고르기
모든 작업에 가장 큰 모델을 쓸 필요는 없습니다. 분류, 정보 추출, 간단한 요약이나 변환은 Haiku급으로 충분하고, 일반적인 코딩과 문서 작성, 코드 리뷰는 Sonnet급이 무난하며, 복잡한 설계나 어려운 디버깅처럼 깊은 추론이 필요한 일에 Opus급을 씁니다. Claude Code 문서도 대부분의 코딩은 Sonnet으로 충분하고 Opus는 아키텍처 결정이나 여러 단계의 추론에 아껴 쓰라고 안내합니다. 모델은 /model로 바꾸고, 단순한 서브에이전트에는 model: haiku를 지정할 수 있습니다.
여기서 짚어 둘 점은, 모델을 바꾼다고 토큰 수가 줄어드는 것은 아니라는 사실입니다. 같은 토큰이어도 모델별 단가가 달라서 비용이 달라질 뿐입니다. 오히려 성능이 낮은 모델이 같은 일을 몇 번씩 실패하면 토큰과 비용이 더 나갈 수 있으니, 가장 싼 모델이 아니라 작업을 안정적으로 끝낼 수 있는 모델을 고르는 쪽이 맞습니다. 세대에 따라 토크나이저가 바뀌어 같은 글도 토큰 수가 다르게 나옵니다. 공식 문서는 Claude Opus 4.7 이후 모델이 이전 모델보다 같은 입력에서 대략 30% 더 많은 토큰을 센다고 밝히고 있어서, 모델을 옮길 때는 예전 숫자를 그대로 쓰지 말고 새 모델로 다시 세어 봐야 합니다.
추론 강도도 비용에 영향을 줍니다. Claude Code는 확장 사고(extended thinking)가 기본으로 켜져 있고 사고 토큰은 출력 토큰으로 과금됩니다. 단순한 작업이라면 /effort로 강도를 낮춰 쓸 수 있습니다. 다만 최신 모델 일부는 사고를 끌 수 없고 effort 수준으로만 조절한다고 문서에 나와 있습니다.
Claude Code 컨텍스트 관리
Claude Code는 채팅과 달리 파일을 읽고 명령을 실행하고 외부 도구를 부르기 때문에 내가 입력한 메시지 말고도 많은 것이 컨텍스트를 차지합니다. 무엇이 차지하는지 모르면 줄일 곳도 못 찾으니 /context로 사용 현황을 먼저 보는 것이 좋습니다. 시스템 지침, 도구 정의, 대화 기록 중 어디가 큰지 확인한 뒤 정리하면 됩니다. /usage에서는 세션별 토큰 사용량을 볼 수 있고, 구독 플랜이라면 줄일 만한 항목에 대한 권장 사항도 함께 나옵니다.
CLAUDE.md는 세션이 시작될 때 컨텍스트에 로드됩니다. 특정 작업에만 필요한 상세 지침, 예를 들어 PR 리뷰 절차나 DB 마이그레이션 규칙까지 전부 넣어 두면 상관없는 작업을 할 때도 그 토큰이 따라옵니다. 공식 문서는 CLAUDE.md를 200줄 아래로 유지하고, 특정 워크플로우용 지침은 호출될 때만 로드되는 스킬(skill)로 옮기라고 권합니다. 파일 위치와 프로젝트 구성에 따라 실제로 읽히는 범위는 달라질 수 있습니다. 코딩 스타일, 테스트 방법, 변경 금지 규칙처럼 항상 필요한 것만 남기고 상세 설계 문서는 따로 두었다가 필요할 때 참조시키는 구성이 무난합니다.
MCP 서버도 정리 대상입니다. 예전에는 연결한 서버의 도구 정의가 전부 컨텍스트에 올라가는 것이 문제였는데, 현재 Claude Code는 MCP 도구 정의를 기본적으로 미뤄 두고 도구 이름과 서버 지침만 컨텍스트에 넣다가 실제로 쓸 때 불러옵니다. 그래도 안 쓰는 서버는 /mcp에서 비활성화하는 것이 좋고, gh, aws, gcloud 같은 CLI가 있다면 도구 목록을 늘리지 않으니 MCP 서버보다 컨텍스트 효율이 더 좋다는 것이 문서의 설명입니다. 이 동작은 버전에 따라 달라질 수 있습니다.
넓은 탐색이나 출력이 많은 작업은 서브에이전트에 맡길 수 있습니다. 결제 처리 로직이 어디 구현되어 있는지 찾는 일을 메인 대화에서 하면 검색 결과와 파일 내용이 메인 컨텍스트에 쌓이지만, 서브에이전트는 별도 컨텍스트에서 탐색하고 요약만 돌려줍니다. 다만 서브에이전트가 쓰는 토큰이 사라지는 것은 아닙니다. 문서에도 서브에이전트의 요청 역시 사용량에 잡힌다고 적혀 있습니다. 여러 개를 동시에 돌리면 전체 사용량은 오히려 늘 수 있어서, 서브에이전트는 전체 토큰을 줄이는 수단이 아니라 메인 대화의 컨텍스트를 분리해 관리하는 수단으로 보는 것이 정확합니다.
한 가지 더, 오래 열어 둔 세션이 한도를 많이 쓰는 이유 중에는 캐시도 있습니다. Claude Code는 매 요청마다 전체 대화를 보내는데 프롬프트 캐싱 덕분에 캐시된 토큰으로 읽혀서 비용이 줄어듭니다. 그런데 자리를 오래 비웠다가 돌아와 캐시 수명이 지난 뒤 보내는 첫 메시지는 캐시를 못 맞히고 전체 컨텍스트를 다시 처리하게 됩니다.
API에서 쓸 수 있는 캐싱과 배치
API로 개발한다면 대화 관리 말고도 비용을 줄이는 기능이 있습니다. 프롬프트 캐싱은 반복해서 보내는 프롬프트 앞부분을 재활용하는 기능입니다. 공통 시스템 프롬프트, 서비스 정책, 제품 매뉴얼, 도구 정의, 공통 참고 문서처럼 매번 똑같이 들어가는 내용이 대상입니다. 캐시는 tools, system, messages 순서로 앞에서부터 prefix가 만들어지고, 한 단계가 바뀌면 그 뒤 단계 캐시도 모두 무효가 됩니다. 그래서 변하지 않는 내용을 앞에, 요청마다 달라지는 내용을 뒤에 두어야 합니다. 공통 프롬프트 맨 앞에 타임스탬프나 요청 ID를 넣으면 캐시가 매번 깨집니다.
공식 문서 기준으로 캐시에 처음 쓸 때 5분 캐시는 기본 입력 가격의 1.25배가 들고, 1시간 캐시는 2배입니다. 캐시를 읽을 때는 기본 입력 가격의 0.1배인데, 모델에 따라 이보다 낮은 경우도 있습니다. 즉 쓰는 순간에는 오히려 비싸고, 같은 프롬프트가 캐시 수명 안에 여러 번 재사용되어야 이득입니다. 캐시 가능한 최소 길이도 모델별로 정해져 있어서 그보다 짧은 프롬프트는 오류 없이 그냥 캐시되지 않습니다. 응답의 cache_creation_input_tokens와 cache_read_input_tokens가 둘 다 0이면 캐시가 안 된 것입니다.
실시간 응답이 필요 없는 작업이라면 Message Batches API를 쓸 수 있습니다. 문서에 따르면 비용이 50% 절감되고 대부분의 배치가 1시간 안에 끝납니다. 대량 문서 분류, 수천 건의 고객 문의 요약, 로그 유형 분석, 데이터 정제 같은 작업이 맞고, 비동기로 처리되므로 즉시 답해야 하는 서비스에는 맞지 않습니다.
챗봇을 만든다면 대화 기록 관리가 중요합니다. Messages API는 요청에 포함된 메시지만 기준으로 응답을 만드니 이전 대화를 매번 전부 보내면 입력 토큰이 계속 늘어납니다. 오래된 대화는 요약하고 최근 몇 개와 핵심 정보만 남기는 구성이 흔합니다. 시스템 프롬프트, 이전 대화 요약, 최근 대화, 현재 질문 순으로 이어 붙이는 식인데, 최근 대화를 몇 개 유지할지는 서비스 특성에 따라 정해야 합니다. 요청을 보내기 전에는 Token Counting 엔드포인트로 입력 토큰 수를 미리 셀 수 있습니다. 문서에 따르면 무료이고 별도의 분당 요청 한도가 적용됩니다. 다만 결과는 추정치라 실제 값과 약간 다를 수 있고, 캐싱은 실제 메시지를 만들 때만 적용됩니다. 대용량 문서나 여러 파일을 처리하는 서비스에서 예상 밖의 사용량을 막는 데 쓸 만합니다.
토큰 절약과 비용 절약은 다릅니다
지금까지 나온 방법들은 효과가 서로 다릅니다. 새 대화를 열거나 로그와 문서를 줄이는 것은 입력 토큰 자체를 줄입니다. 답변 분량을 제한하면 출력 토큰이 줄고, 구체적인 요청은 불필요한 탐색과 재작업을 줄입니다. 그런데 저렴한 모델로 바꾸는 것은 토큰당 비용을 줄일 뿐 토큰 수는 그대로이고, 프롬프트 캐싱도 논리적으로 입력되는 토큰의 양이 아니라 반복 입력의 처리 비용을 줄입니다. Batch API 역시 토큰을 줄이는 것이 아니라 단가를 낮춥니다. 서브에이전트는 앞에서 말했듯 메인 컨텍스트는 가볍게 해도 전체 사용량은 늘 수 있습니다.
그래서 API 비용을 최적화하려면 입력과 출력 토큰, 캐시 사용량, 모델별 단가를 함께 봐야 합니다. 구독 플랜에서는 달러가 아니라 사용량 한도가 병목이므로 /usage에서 어떤 행동이 한도를 많이 쓰는지 확인하는 편이 빠릅니다.
짧게 쓰는 것이 목적은 아닙니다
토큰을 아낀다고 질문을 무조건 짧게 쓰거나 답변을 줄여야 하는 것은 아닙니다. 짧지만 모호한 요청은 되묻기와 탐색을 불러서 결국 더 많이 씁니다. 조금 길더라도 대상과 범위가 분명한 요청이 한 번에 원하는 결과를 얻기 쉽습니다. 필요한 정보는 충분히 주되, 불필요한 정보를 반복해서 처리하게 만들지 않는 것이 방향이라고 생각합니다.
이 글의 Claude Code 명령과 API 동작은 2026년 11월 기준 공식 문서를 확인해 정리했지만, 명령과 기능은 버전에 따라 바뀔 수 있으니 실제로 쓰는 환경의 안내를 함께 봐 주세요.