토큰 단가가 같아도 작업당 실제 비용은 크게 달라질 수 있습니다. Claude Code를 Opus 5.5로 사용할 때 작업당 비용이 어느 정도인지, 그리고 어떤 설정이 요금을 좌우하는지 살펴봅니다.
처음부터 수백만 개의 토큰을 사겠다고 마음먹는 사람은 없습니다. 기능을 구현하거나, 마이그레이션을 마무리하거나, 작업 하나를 완료하려는 거죠. 토큰 수는 모델이 그 목적을 달성하는 데 쓴 양일 뿐입니다.
토큰 단가가 같아도 동일한 작업에서 실제 비용은 크게 달라질 수 있습니다. 어떤 모델은 코드를 한 번 읽고 끝냅니다. 다른 모델은 읽고, 수정을 시도하고, 다시 읽습니다. 이 각각의 단계가 하나의 턴이고, 턴마다 그때까지의 대화 전체를 다시 전송합니다. 그래서 턴이 많이 필요한 모델은 단가가 같더라도 비용이 더 많이 듭니다.
이 글을 다 읽고 나면 자신의 작업에 대해 세 가지 질문에 답할 수 있게 됩니다.
먼저 솔직하게 짚어둘 트레이드오프가 있습니다. 토큰을 줄이는 방법은 어떤 것이든 작업을 완료하지 못할 위험을 함께 안고 있습니다. 낮은 effort, 소형 모델, 적은 컨텍스트는 분명히 토큰을 아낄 수 있지만, 재시도 한 번의 비용이 그 절감액을 금세 앞질러 버립니다. 이 글에서는 각 트레이드오프에 실제 비용을 붙여보려 합니다.
여기서 제시하는 수치 중 일부는 공식 정가이고, 일부는 그 정가를 바탕으로 만든 예시입니다. 수치는 인터랙티브하게 조작할 수 있으니 읽으면서 직접 값을 바꿔보세요. 어디까지나 참고용 예시이므로, 공식 문서와 직접 계산한 값을 꼭 확인하세요.
Claude Code에서 작업은 루프로 진행됩니다. 모델이 대화를 읽고, 도구를 호출하고, 결과를 읽고, 완료될 때까지 이 과정을 반복합니다. 루프를 한 바퀴 도는 것이 요청 하나입니다. 루프의 비용을 결정하는 요소는 네 가지입니다.
턴 수. 매 턴마다 그때까지의 대화 전체를 다시 전송합니다. 턴이 줄면 처리되는 입력도 줄어듭니다.
캐시 읽기. 턴마다 재전송하는 내용의 대부분은 직전 턴에서 모델이 이미 본 텍스트입니다. 이 부분은 캐시 읽기로 청구되며, 일반 입력 가격의 일부에 불과합니다.
출력 토큰 유형. 입력 가격의 다섯 배로 가장 비싼 토큰입니다. Thinking도 출력으로 청구되므로, 답을 도출하는 과정에서 추론을 덜 하는 모델이 비용도 덜 듭니다.
모델. 모델마다 가격 페이지에 별도 가격이 있어, 선택한 모델이 모든 토큰의 단가를 결정합니다.
예시에는 Opus 5.5 API 정가를 사용했습니다. 입력 토큰 100만 개당 $4, 출력 토큰 100만 개당 $20, 캐시 읽기 100만 개당 $0.20입니다. 아래 계산기와 마찬가지로, 캐시된 입력은 읽기 가격으로, 나머지는 입력 가격으로 청구하며 캐시 쓰기는 제외했습니다. 토큰 수는 모두 예시 수치입니다.
작업이 20K 토큰의 컨텍스트로 시작해 모델이 파일과 도구 결과를 읽으면서 120K까지 늘어난다고 가정해 봅시다. 40턴 기준으로 턴당 평균 약 70K 토큰이 전송됩니다. 대화 자체는 120K를 넘지 않았지만, 작업 전체에서는 약 280만 개의 입력 토큰이 사용됩니다. 90%가 캐시에서 읽히면 입력 비용은 약 $1.62입니다. 같은 작업을 25턴에 마치면 약 175만 개의 토큰을 처리하고 입력 비용은 약 $1.02가 됩니다.
턴 하나의 비용은 그 턴이 새로 추가하는 토큰보다 비쌉니다. 앞의 모든 내용을 다시 보내기 때문입니다. 그래서 가장 싼 턴은 아예 필요 없는 턴입니다.
턴을 줄이는 데 효과적인 방법 중 하나는 모델이 스스로 결과를 검증할 수단을 제공하는 것입니다. 실행할 수 있는 테스트, 빌드, 또는 엔드포인트를 호출하는 스크립트가 있으면 모델이 실수를 더 일찍 발견합니다.
필요한 정보를 한 번에 수집하고 도구 호출을 묶어서 처리하는 모델도 재전송 횟수를 줄일 수 있습니다.
동일한 280만 개의 입력 토큰도 캐시를 전혀 쓰지 않으면 $11.20이 듭니다. 캐시 적중률 90%에서는 $1.62, 96%에서는 약 $0.99입니다. 입력 비용을 이 정도로 바꾸는 설정은 없습니다. 꾸준히 이어지는 세션은 자연스럽게 높은 적중률을 유지합니다. 캐시를 깨뜨리는 행동은 이 글 후반부에서 다룹니다.
Opus 5.5에서 출력 토큰 하나는 캐시 읽기의 100배입니다. 일반적인 작업에서 나오는 출력 6만 토큰의 비용은 $1.20으로, 캐시에서 600만 토큰을 읽는 것과 같습니다. 출력에는 thinking도 포함됩니다. Claude Code가 요약만 보여줄 때도 전체 비용을 냅니다. 그래서 모델의 thinking 양을 주로 조절하는 effort 설정이 청구 금액을 크게 움직이는 것입니다.
캐시 읽기가 저렴한 모델은 긴 세션에서 효과가 크고, 출력이 저렴한 모델은 추론을 많이 요구하는 작업에서 유리합니다.
두 가지가 달라졌습니다. 가격과 모델이 처리하는 작업량입니다.
모든 가격 항목이 내렸습니다. 입력·출력 토큰은 Opus 5 대비 20% 저렴해졌고, 캐시 읽기는 60% 내렸습니다. 입력 가격이 낮아지면서 읽기 요율도 함께 낮아졌는데, 입력 가격의 10분의 1에서 20분의 1로 떨어졌습니다. Fig A에서 두 모델의 100만 토큰당 가격을 비교해 볼 수 있습니다. 이는 API 정가 기준입니다. Pro, Max, Team 플랜에서는 캐시된 컨텍스트를 포함해 낮아진 Opus 5.5 가격이 한도에도 반영되므로, Opus 5 대비 약 25% 더 여유 있게 사용할 수 있습니다. 캐시 읽기의 추가 인하는 API 가격 변경 사항입니다.

API 키를 사용한다면 캐시 읽기 가격 인하가 Claude Code에서 가장 체감이 큽니다. 긴 에이전트 세션은 입력의 대부분을 캐시 읽기로 소비하기 때문입니다. 아래 Fig B에서 계산한 세션을 보면, 캐시 항목이 $1.00에서 $0.40으로 떨어져 영수증에서 가장 큰 폭으로 줄었습니다.
절감 폭은 작업의 특성에 따라 달라집니다. 캐시 읽기가 대부분인 세션은 입력 비용을 최대 60%까지 절약할 수 있습니다. 캐시 없이 짧게 묻고 길게 답하는 경우는 최대 20% 절약에 그치는데, 출력 비중이 높기 때문입니다. 대부분의 Claude Code 작업은 이 두 극단 사이 어딘가에 있습니다. 아래 계산기로 자신의 경우를 확인해 보세요.
Opus 5.5는 답변 전에 항상 thinking을 거치기 때문에 답변 하나에 더 많은 토큰을 쓸 수 있습니다. Opus 5.5에서 더 많은 작업을 처리하게 될 것으로 기대하지만, 작업에 따라 차이가 있으므로 직접 측정해 보세요. Fig C에서 두 모델의 작업당 비용을 비교해 볼 수 있습니다. 이 부분은 가격보다 작업의 특성에 훨씬 더 크게 좌우됩니다.
범위가 명확하게 정의된 작업이라면 두 모델 모두 비슷한 턴 수로 완료하므로 가격 인하 효과가 전부입니다. 반면 열린 구조의 작업에서는 격차가 가장 크게 벌어지는데, 모델이 잘못된 방향으로 여러 턴을 소비할 수 있기 때문입니다. 어떤 코드베이스에도 딱 맞는 단일 수치는 없으니 직접 측정해 보세요(마지막 섹션 참고).
장시간 실행이 끝나면 보고서가 남습니다. Opus 5.5는 긴 실행을 마치면 변경한 내용, 발견한 사항, 그리고 사용자에게 필요한 것을 정리해 보여줍니다. 무슨 일이 있었는지 확인할 수 있으면 세션을 다시 실행하는 일이 줄어들어 비용 절감으로도 이어집니다.
Fig B는 동일한 토큰 수를 기준으로 두 모델의 세션 비용을 계산합니다. 즉, 차이는 순전히 가격 변화만 반영합니다. 모델을 전환해 비교해 보세요. 토큰 수는 예시 수치입니다.
Fig B. 두 모델에서 동일한 토큰을 사용한 예시 세션으로, 가격 변화만 반영합니다.
영수증에는 /usage가 세션에 대해 보여주는 세 항목이 있습니다. 캐시 읽기가 200만 토큰으로 가장 많고, 출력은 토큰 수로는 가장 적지만 비용으로는 가장 비쌉니다. 신규 입력은 그 사이에 위치하며, 각 파일의 첫 읽기와 새로운 도구 결과 처리가 여기에 해당합니다.
Fig B는 두 모델에 같은 토큰 수를 적용했으므로 순전히 가격 변화만 보여줍니다. 실제 세션에서는 Opus 5.5에서 토큰이 더 많거나 적게 사용될 수 있습니다. 이 기준으로 계산하면 세션 비용이 약 31% 줄어듭니다.
실제 실행 기록을 반영하면 두 번째 효과, 즉 모델의 작업량 변화가 더해집니다. 잘못된 시작이 있었던 작업이라면 격차는 더 벌어져야 합니다. 직접 수치를 입력해 보세요.
자신의 작업에서 사용하는 값을 직접 입력하거나 프리셋에서 시작하세요. 프리셋은 어디까지나 참고용이니 직접 계산해 보기를 권합니다. 캐시된 입력은 캐시 읽기 가격으로, 신규 입력은 입력 가격으로 청구되므로 캐시 슬라이더를 조정하면 격차 중 캐시 읽기에서 오는 부분을 확인할 수 있습니다.
실제 세션 값으로 슬라이더를 채우려면 작업 마지막에 /usage를 실행하세요. Session 블록에서 입력, 출력, 캐시 수치를 확인할 수 있습니다. 마지막 슬라이더는 Opus 5.5가 자신의 작업에서 얼마나 적은 작업을 하는지에 대한 가정값입니다. 가격 변화만 보려면 0%로 두세요. 직접 측정하려면, Opus 5와 Opus 5.5에서 같은 작업을 실행하고 턴 수와 출력 토큰을 비교하면 됩니다. 직접 측정하기 섹션에 방법이 나와 있고, 세션 읽기 섹션에서는 /usage에서 무엇을 확인해야 하는지 설명합니다.
Opus 5.5의 낮아진 가격 덕분에 토큰당 비용이 줄었습니다. 세션에서 토큰을 얼마나 쓰는지는 사용 방식이 결정하며, 아래 방법들이 도움이 됩니다.
Effort는 모델이 매 턴에 쓰는 토큰의 전반적인 수준을 조정합니다. 여기에는 thinking, 생성하는 텍스트, 도구 호출이 포함됩니다. Effort가 낮으면 도구 호출 횟수와 길이가 줄어듭니다. Opus 5.5는 low, medium, high, xhigh 네 단계에 단일 세션용 max까지 총 다섯 단계를 제공합니다. 아래에서 원하는 단계를 선택하면 언제 쓰는지와 설정 명령어를 확인할 수 있습니다.
Claude Code는 모델마다 기본 단계를 설정하며, /effort status로 현재 단계를 확인할 수 있습니다. 범위가 명확한 일상 작업에는 medium을 사용해 보세요. medium에서 막힐 때는 high를 시도하세요. medium보다 턴당 비용이 더 들지만, 더 큰 모델로 바꾸는 것보다는 저렴합니다. 이름 바꾸기나 알려진 패턴을 여러 파일에 적용하는 등 기계적인 작업에는 low를 사용하세요.
Effort 가격을 대략적으로 생각해 보면, high가 작업 전체에 걸쳐 2만 개의 thinking 토큰을 추가한다고 할 때 Opus 5.5에서 $0.40입니다. 10만 토큰의 캐시된 컨텍스트 기준으로 10턴을 재시도하고 출력 토큰이 총 1만 개인 루프도 비슷한 비용입니다. 재시도 한 번을 줄여주는 작업이라면 high가 본전을 뽑습니다. medium으로도 충분히 끝날 작업이라면 낭비가 됩니다.
더 높은 effort가 필요하다는 가장 명확한 신호는 수정이 한 레이어에서만 멈추는 경우입니다.
예를 들어 API 핸들러에서 필드명이 바뀌었다고 합시다. medium에서는 모델이 핸들러를 수정하고 핸들러 테스트는 통과시키지만, 클라이언트가 여전히 예전 필드명을 보냅니다. 요청받은 대로 했지만, 두 번째 호출자를 찾을 만큼 멀리 읽지 않은 것입니다. high에서는 코드를 작성하기 전에 더 많은 턴을 들여 호출 지점을 읽고, 두 레이어를 한 번에 수정합니다.
검증 수단을 추가해도 같은 버그를 잡을 수 있습니다. 클라이언트를 거치는 테스트를 모델이 실행할 수 있다면, 예전 필드명을 사용한 그 턴에서 바로 테스트가 실패합니다. effort를 높이기 전에, 모델이 스스로 결과를 검증할 수단이 있는지 먼저 확인하세요. 테스트 실행은 턴 하나와 그 출력 비용이면 됩니다. effort를 높이면 모든 턴에 thinking이 추가됩니다.
Effort를 높이고 검증 수단을 추가해도 해결되지 않는다면, 그때 더 큰 모델로 전환하세요.
Claude Code에서는 /effort high처럼 단계를 붙여 /effort를 실행합니다. /effort status는 현재 단계를 출력합니다. 작업 도중에도 변경할 수 있으며, 새 단계는 다음 요청부터 적용됩니다.
Effort나 thinking 설정을 바꾸면 캐시된 대화가 초기화됩니다. 해당 설정들이 캐시 일치 기준이 되는 프롬프트의 일부이기 때문입니다. 다음 요청에서는 전체 대화에 캐시 쓰기 가격이 적용됩니다.
모델 선택은 세션 내 모든 토큰의 단가를 결정하므로, effort보다 청구 금액을 더 크게 바꿉니다. 영향 범위도 더 넓습니다. 메인 모델을 상속받는 모든 서브에이전트도 같은 가격을 적용받습니다. 대부분의 업무에는 세 가지 모델이 필요합니다. 조회용 소형 모델, 직접 관여하며 진행하는 작업용 Opus 5.5, 그리고 가장 어려운 작업을 위한 대형 모델입니다.

직접 관여하며 진행하는 작업에는 Opus 5.5를 사용하세요. 몇 개의 파일에 걸친 기능 개발, 디버깅, 후속 수정이 포함된 코드 리뷰가 여기에 해당합니다. 모델의 작업을 읽고 방향이 틀어지면 개입하기 때문에 루프가 짧게 유지됩니다. Fable 5.1로 올리는 경우
결과가 토큰 비용보다 중요할 때 Fable 5.1로 올리세요. 예를 들어 직접 관여하지 않는 장시간 실행, 코드베이스에 기존 패턴이 없는 문제, 많은 서브에이전트를 조율하는 대규모 변경이 해당합니다. 세 번째 실패를 기다리지 마세요. Opus 5.5가 high에서 같은 문제에 두 번 막히면 전환하고, 해결되면 다시 돌아오세요. 인터랙티브한 작업에는 레이턴시가 낮고 비용도 적은 Opus 5.5가 더 적합합니다.
Fable 5.1의 정가는 입력 토큰 100만 개당 $10, 출력 토큰 100만 개당 $50으로 Opus 5.5 가격의 2.5배입니다. 캐시 읽기는 100만 개당 $0.25로, Opus 5.5의 1.25배에 불과합니다. 입력 가격의 0.025배로 청구되기 때문입니다. 따라서 캐시 읽기 비중이 높은 긴 실행에서 두 모델의 격차가 가장 좁고, 출력이 많은 작업에서 가장 크게 벌어집니다.
자연스러운 중단 시점에 전환하세요. 캐시는 이전 모델에 속하므로, 새 모델로의 첫 턴에서 전체 대화에 쓰기 가격이 적용됩니다. 전환 전에 /compact를 먼저 실행하거나, 간단한 계획을 적어 새 세션을 시작해 첫 턴의 크기를 줄이세요. 전환할 때는 별칭이나 모델명과 함께 /model을 실행하세요. /model은 선택한 모델을 새 세션의 기본값으로 저장하므로, 어려운 부분이 끝나면 다시 돌아오는 것을 잊지 마세요.
코드 작성이 아닌 조회 작업에만 Sonnet이나 Haiku로 내리세요. 검색·요약을 맡는 서브에이전트, 로그·테스트 출력 읽기, "이게 어디에 정의되어 있나" 같은 질문이 여기에 해당합니다. 여러 파일에 걸친 기계적인 수정은 Opus 5.5를 유지하면서 effort를 low로 내리세요. 나머지 코드를 작성하는 모델에서 낮은 턴당 비용으로 수정을 처리할 수 있습니다.
서브에이전트를 소형 모델에 할당하려면, 해당 정의에 model: haiku 또는 model: sonnet을 설정하세요. 모든 서브에이전트를 하나의 모델로 지정하려면 CLAUDE_CODE_SUBAGENT_MODEL 환경 변수를 설정하면 됩니다. 서브에이전트 정의에 명시된 모델이 환경 변수보다 우선합니다. 모델 설정이 없는 서브에이전트는 환경 변수가 설정되어 있지 않으면 메인 모델에서 실행됩니다.
각 서브에이전트는 독립된 컨텍스트 창에서 실행되고 요약만 반환하므로, 서브에이전트의 파일 읽기가 메인 대화에 포함되지 않습니다. 다만 자체 토큰 비용은 발생하므로, 모델 설정이 해당 비용을 결정합니다.
트레이드오프도 있습니다. 소형 모델이 검색 결과를 잘못 읽으면 메인 모델이 엉뚱한 파일을 찾아가게 되고, 메인 모델이 그 우회 비용을 부담합니다. 파일 찾기, 테스트 실행, 로그 읽기처럼 실수해도 발견하기 쉬운 작업에만 소형 모델을 사용하세요.
판단이 필요한 작업은 메인 모델에 맡기세요. opusplan 별칭은 작업을 다른 방식으로 나눕니다. Opus가 플랜 모드에서 계획을 세우고 Sonnet이 실행합니다. 코드 수정을 Sonnet에 맡기는 방식으로, 위의 권장 사항과 반대입니다. 기본값으로 삼기 전에 자신의 작업에서 먼저 측정해 보세요.
이전 모델에 맞게 작성된 지시사항은 Opus 5.5가 필요 이상으로 많이 쓰고 도구 호출을 반복하게 만들 수 있습니다. Claude Code에서 /claude-api prompt-audit를 실행해 스킬과 CLAUDE.md 파일 등 Claude Code 설정에 이런 프롬프팅 안티패턴이 있는지 확인하세요. Claude 플랫폼 위에 만드는 앱 코드도 함께 점검합니다.
이 방법을 Opus 4.8에서 Opus 5.5로의 마이그레이션에 적용해 테스트해 봤습니다. 여러 패턴이 섞인 프롬프트로 작성된 44개 티켓의 사내 고객 지원 벤치마크를 사용했습니다. Opus 5.5로 전환하고 low effort를 적용하자 벤치마크 비용이 약 18% 절감됐습니다. 이어서 prompt-audit를 실행했더니 9%가 추가로 줄어, Opus 4.8 시작점 대비 약 25% 낮아졌습니다. 감사에서는 모델이 더 많이 쓰고 도구 호출을 반복하게 만든 형식적인 지시사항이 제거됐습니다. 의무적인 6단계 절차, 스크래치패드 규칙, 이중 확인 규칙, 그리고 서로 모순된 지시사항이 여기에 해당합니다.

이 결과는 하나의 벤치마크에서 나온 것이므로 기대치로 삼기보다는 참고 사례로 보세요. 감사를 실행한 뒤, 실제 작업에서 전후 /usage를 비교해 보세요(직접 측정하기 참고).
캐싱과 컴팩션은 Claude Code가 자동으로 처리합니다. 세션을 어떻게 운영하느냐에 따라 절감 효과가 달라집니다.
Claude Code는 요청에서 반복되는 부분, 즉 시스템 프롬프트, 도구 정의, 현재까지의 대화 내용을 캐시합니다.
Opus 5.5에서 캐시 읽기는 신규 입력 토큰의 5% 비용입니다. 캐시 쓰기는 신규 읽기보다 비싼데, 오늘 기준으로 5분짜리 캐시는 입력 가격의 1.25배, 1시간짜리는 2배입니다. 적중할 때마다 유효 기간은 추가 비용 없이 초기화됩니다.
Claude Code에서 유효 기간은 결제 방식에 따라 달라집니다. Claude 구독에서는 1시간이며, API 키나 클라우드 제공업체에서는 기본 5분입니다. 구독도 사용 크레딧을 쓰기 시작하면 5분으로 줄어듭니다.
컨텍스트가 12만 토큰일 때 Opus 5.5에서 5분짜리 캐시 쓰기는 약 $0.60, 읽기는 약 $0.02입니다. 쓰기 한 번이 읽기 25번과 맞먹습니다. API 키를 사용하는 경우, 커피 한 잔 마시며 6분을 쉬면 다음 $0.02짜리 읽기가 $0.60짜리 쓰기로 바뀝니다. 같은 크기의 1시간짜리 쓰기는 약 $0.96이며, API에서는 이 비용을 내고 하루 중 빈 시간을 커버할 수 있습니다.
캐시는 접두사 방식으로 저장되므로, 이전 요청의 시작 부분과 일치하는 부분만 재사용할 수 있습니다.
꾸준히 이어지는 세션은 매 턴마다 대화 끝에 내용을 추가하므로 적중률이 높게 유지됩니다. 요청의 앞부분을 바꾸는 것은 무엇이든 적중률을 낮춥니다. 도구 정의를 변경하면 전체 캐시가 초기화되고, 시스템 프롬프트를 수정하면 그 지점부터, 즉 거의 모든 것이 초기화됩니다.
실제로 캐시 쓰기가 발생하는 상황은 다음과 같습니다.
따라서 이러한 설정은 세션 시작 시에 완료하고, 작업 중에는 건드리지 마세요.
매 턴마다 전체 컨텍스트를 다시 전송하므로, 캐시가 따뜻한 상태에서도 컨텍스트가 커질수록 턴당 비용이 늘어납니다. Opus 5.5에서 컨텍스트가 2만 토큰일 때 턴당 캐시 읽기 비용은 약 $0.004입니다. 15만 토큰에서는 약 $0.03이며, 이 크기로 30턴을 진행하면 읽기 비용만 $0.90입니다. 같은 30턴을 2만 토큰으로 진행하면 약 $0.12입니다. Claude 4.6 이후 모델에서는 컨텍스트 창이 커져도 토큰당 가격은 변하지 않으므로, 비용 증가는 전적으로 대화를 재전송하는 데서 옵니다.
컨텍스트의 상당 부분은 이미 끝난 작업의 잔재입니다. 한 시간 전 스택 트레이스, 이미 마무리한 파일, 이미 수정된 테스트 실행 출력 같은 것들이 여전히 매 턴마다 전송됩니다.
세션이 컨텍스트 한도에 가까워지면 Claude Code가 오래된 기록을 요약해 이후 턴의 전송량을 줄입니다. /autocompact에 토큰 수를 지정하면 컨텍스트가 얼마나 찼을 때 이 작업이 시작되는지 변경할 수 있습니다.
직접 실행할 수 있는 명령어도 두 가지 있습니다. /clear는 대화를 비우며 비용이 들지 않으니 관련 없는 작업으로 넘어갈 때 사용하세요. /compact는 연속성을 유지하며 요청 하나의 비용이 듭니다. 요약할 대화를 읽고, /compact keep the failing test names and the schema change처럼 유지할 내용을 지정할 수 있습니다.
15만 토큰에서 컴팩션하는 대략적인 비용은 약 $0.25입니다. 읽기 비용, 수천 토큰의 출력 요약, 그리고 짧아진 컨텍스트에 대한 새 캐시 쓰기가 포함됩니다. 이후 매 턴마다 읽기에서 약 $0.025가 절약되므로, 약 10턴이면 컴팩션 비용을 회수합니다. 작업을 거의 마쳤을 때 하는 컴팩션은 절약보다 비용이 더 큽니다.
요약하면 세부 정보가 손실됩니다. 디버깅 세션 중간의 컴팩션은 중요한 로그 한 줄을 날려버릴 수 있습니다. 자연스러운 중단 시점에 컴팩션하고, 다음 단계가 특정 내용에 의존한다면 /compact 지시사항에 명시하세요.
CLAUDE.md 파일은 모든 세션 시작 시 컨텍스트에 로드되므로, 파일의 각 줄이 모든 턴에서 재전송하는 내용의 일부가 됩니다. 비용 문서에서는 200줄 이하로 유지할 것을 권장합니다. MCP 도구 정의는 지연 로드됩니다. 시작 시에는 도구 이름과 서버 지시사항만 로드되고, 전체 정의는 해당 도구가 실제로 사용될 때 로드됩니다. /mcp로 연결된 서버를 확인하고, 사용하지 않는 서버는 끄세요.
아래 표에는 Claude Code 세션 요금에 영향을 미치는 기타 청구 규칙과 해당 문서 링크가 정리되어 있습니다.

이 글의 수치는 어디까지나 예시입니다. 코드베이스, 프롬프트, 사용 습관은 사람마다 다르므로 실제 작업에서 직접 비용을 측정해 보세요. 방법은 다음과 같습니다.
작업이 끝나면 /usage에서 세 가지를 확인하세요.
기준점으로, Claude Code 비용 문서에 따르면 엔터프라이즈 배포 기준 활성 일 기준 개발자 1인당 평균 약 $13이며, 90%의 사용자는 활성 일 기준 $30 미만입니다. 자신의 평소 수준보다 훨씬 높은 세션은 검토해 볼 가치가 있습니다.
이 글이 도움이 되셨으면 좋겠습니다. Opus 5.5에서 Opus 5보다 한도가 더 늘어나지 않는다면 /feedback으로 알려주세요.
더 읽어보기: 비용 효율적으로 관리하기 · 모델 설정 · Claude Code에서 Claude 모델과 effort 수준 선택하기 · Effort · 프롬프트 캐싱 · Claude Code 세션 효율 극대화하기
검토해 주신 Michael Segner, Kacie Jenkins, Molly Vorwerck에게 감사드립니다.