클로드 코드 — 같은 요금제로 더 많이 쓰는 법

Claude Code를 쓰다 사용 한도에 걸려본 적 있으신가요? 분명 똑같은 작업인데 어떤 날은 널널하고 어떤 날은 금방 바닥나죠. 같은 작업이라도 사용 방식에 따라 비용이 달라지기 때문입니다. Anthropic이 공식 블로그에 공개한 이 원리를, 개발을 몰라도 이해할 수 있게 처음부터 끝까지 정리한 가이드입니다.

📺 영상 채널: Aiden의 친절한 AI (https://www.youtube.com/@Aiden_channel)

ℹ️ 토큰·가중치가 뭔지, 모델을 작업에 따라 어떻게 고르는지는 지난 편(모델·작업량 선택 기준) 가이드에서 다뤘습니다. 이 부분이 낯설다면 그 편을 먼저 보고 오시면 좋습니다.

---

이 가이드로 아는 것

1. 토큰 가격을 결정하는 세 가지 요소 — 모델, 입력/출력, 캐시
2. 출력 토큰이 입력보다 약 5배 비싼 이유와 /effort의 비용 의미
3. 정가의 1/10을 만들어주는 프롬프트 캐싱, 그리고 그걸 깨뜨리는 행동들
4. “어떤 것도 한 번만 전송되지 않는다” — 컨텍스트에 짐이 쌓이는 원리
5. /clear /compact /rewind /context 멘션 서브에이전트 — 도구별 사용 기준
6. Anthropic이 정리한 비용 영향 순위 4가지

---

배경 — 토큰 가격은 무엇이 결정하나

AI 요금은 토큰 단위로 부과되지만, 실제로 지불하는 비용의 정체는 추론 시간 — GPU가 내 토큰들을 처리하며 모델을 돌리는 데 걸리는 시간입니다.

💡 전기요금과 비슷합니다. 고지서에는 “몇 kWh에 얼마”라고 사용량 단위로 찍히지만, 그 뒤에서 한전이 부담하는 핵심 비용은 발전소를 돌리는 연료비죠. 토큰도 마찬가지 — 청구는 토큰 개수로 되지만, 실제 비용은 GPU가 돌아간 시간입니다.

그럼 토큰 하나를 처리하는 시간은 뭐가 결정할까요? 세 가지입니다 — ① 어떤 모델을 쓰는지 ② 입력 토큰인지 출력 토큰인지 ③ 캐시가 되어 있는지.

---

요소 ① — 모델: 개수 단위 × 개당 단가

좋은 모델일수록 내부의 가중치(파라미터)가 훨씬 많고, 토큰 하나를 처리한다는 건 이 가중치 전체를 거쳐 계산한다는 뜻이라 — 같은 토큰 하나라도 큰 모델에서는 훨씬 많은 연산이 일어납니다. 같은 서류 한 장이라도 직원 수백 명이 검토하는 회사와 수만 명이 검토하는 회사는 인건비가 다른 것과 같습니다.

⭐ 토큰은 개수 단위, 모델은 개당 단가. 그리고 이게 중요한 이유가 하나 더 — 오늘 나올 다른 모든 절약 팁의 효과가 전부 모델 단가에 곱해집니다. 어려운 문제는 큰 모델, 단순 작업은 작은 모델. 이게 절약의 첫 번째 원칙입니다.

---

요소 ② — 입력 vs 출력: 프리필과 디코드

같은 모델이라도 토큰이 들어가는 방향이냐 나오는 방향이냐에 따라 가격이 다릅니다.

요청 하나가 처리되는 과정

단계	이름	무엇인가
읽기	프리필	모델은 기억이 없어서, 매 요청마다 지금까지의 상황 전체를 처음부터 다시 읽음 — 시스템 프롬프트, CLAUDE.md, 내 메시지, 이번 대화에서 쌓인 모든 것(읽은 파일, 실행 결과 포함). 이 “모델이 읽어들이는 모든 텍스트”가 입력 토큰
쓰기	디코드	응답을 만들어내는 과정. 화면의 답변 텍스트만이 아니라 속으로 하는 사고 과정, “이 파일 읽어줘” 같은 도구 실행 요청까지 전부 출력 토큰

💡 방향으로 기억하면 쉽습니다 — Claude Code에서 모델로 들어가는 건 입력, 모델에서 나오는 건 출력.

출력이 입력보다 약 5배 비싼 이유

• 읽기(프리필)는 시험지 지문 전체를 쭉 훑듯 한꺼번에 병렬 처리할 수 있습니다.
• 쓰기(디코드)는 다음 토큰이 뭐가 될지 직전 토큰까지 나와봐야 정해집니다. “안녕하” 다음에 “세”를 만들고, “안녕하세”까지 봐야 “요”를 만드는 구조 — 200토큰짜리 답변은 모델 전체를 200번 연달아 돌린 결과물입니다.

벽돌 200장을 한 트럭에 실어 나르는 것과, 한 장씩 200번 왕복해 나르는 것의 차이 — 당연히 한 토큰씩 만드는 쪽이 GPU를 훨씬 오래 붙잡습니다.

/effort — 사고 토큰의 손잡이

화면에 보이는 답변은 출력 토큰의 일부일 뿐이고, 상당 부분은 답을 내놓기 전에 속으로 하는 사고 토큰입니다. 눈에 안 보여도 전부 출력 토큰이라 5배 단가로 과금됩니다. 이 “속으로 생각하는 양”을 조절하는 손잡이가 /effort — 높이면 더 깊게 고민하는 대신 비싼 출력 토큰이 늘어나고, 낮추면 빠르고 싸게 처리하는 대신 고민이 얕아집니다.

⚠️ 설정은 세션이 끝나도 이월됩니다. effort도, 모델도 다음 세션의 기본값으로 그대로 유지돼요. 지난주에 어려운 작업 하느라 high로 올려놓고 잊으면, 오늘 단순 작업을 하면서도 비싼 설정으로 돌리고 있을 수 있습니다. 그래서 Anthropic이 권하는 습관 — 새 세션을 열면 /model과 /effort부터 확인. 설정이 우연이 아니라 의도된 선택이어야 합니다.

---

요소 ③ — 캐시: 같은 토큰을 1/10 가격으로 ⭐

프리필에서 “모델은 매 요청마다 대화 전체를 처음부터 다시 읽는다”고 했죠. 그런데 1분 전 요청의 대화와 지금 요청의 대화는 앞부분이 완전히 똑같고, 끝에 새 내용만 몇 줄 붙었을 뿐입니다. 똑같은 앞부분을 매번 다시 계산할 필요가 있을까요?

그래서 서버는 직전 요청의 계산 결과를 들고 있다가, 다음 요청이 똑같은 내용으로 시작하면 “앞부분은 아까 계산한 거 그대로 쓰고, 새로 붙은 뒷부분만 계산하자” 라고 합니다. 이게 프롬프트 캐싱입니다.

동작	가격	이유
저장	정가의 최대 약 2배	계산 결과를 다음 요청까지 메모리에 보관 — 계산비 + 보관료
재사용	정가의 0.1배 (1/10)	불러오기만 하면 되니까

2배 내고 저장하는 게 이득인가? 숫자로 보면 — 대화 초반에 들어온 토큰 하나가 있고, 이 세션에서 대화를 20번 주고받는다면 그 토큰은 20번 읽힙니다.

	계산	비용
캐싱 없음	정가 × 20	20
캐싱	저장 2 + 재사용 0.1 × 19	3.9

약 5배 차이. 그리고 Claude Code가 이걸 전부 자동으로 해줍니다. 우리가 할 일은 하나 — 캐시를 깨뜨리지 않는 것.

---

캐시는 언제 깨지나 — 기차 비유 ⭐

요청은 기차처럼 조립됩니다. 맨 앞에 도구 정의 → 시스템 프롬프트 → CLAUDE.md, 그 뒤로 대화가 한 칸씩 붙습니다. 이 기차는 매 요청마다 전체가 통째로 다시 전송되고, 캐시는 맨 앞 칸부터 직전 요청과 비교해 — 똑같은 구간까지는 캐시로, 달라지는 지점부터만 새로 계산합니다.

⭐ 맨 끝에 새 칸이 붙는 모양(평소 대화)이 가장 이상적입니다. 문제는 앞쪽 칸이 바뀔 때 — 바뀐 칸 뒤의 모든 칸이, 내용이 같더라도 도미노처럼 전부 다시 계산됩니다.

도미노를 넘어뜨리는 행동 세 가지:

행동	왜 깨지나
대화 중간에 모델·effort 변경	캐시에는 “어떤 모델·어떤 effort로 계산했는지” 꼬리표가 붙고, 재사용하려면 이 꼬리표까지 같아야 함 — 둘 중 하나라도 바꾸면 내용이 같아도 전체가 정가로 재계산
/compact 사용	긴 대화를 요약본으로 통째로 갈아치우는 기능이라, 기존 대화 부분의 캐시가 전부 무효 (대화보다 앞의 칸들만 살아남음)
1시간 경과	캐시는 마지막 대화 이후 1시간이 지나면 만료. 대화 중엔 타이머가 리셋되지만, 한 시간 넘게 자리를 비웠다 돌아오면 첫 대화에서 전체가 정가로 재계산

💡 “그럼 모델도 바꾸지 말고 compact도 하지 말라는 건가?” — 아닙니다. 세션 시작 직후나 /clear 직후처럼 비용이 적게 드는 시점과, 긴 대화 중간처럼 많이 드는 시점이 있다는 뜻입니다. 설정 변경은 세션 시작할 때 하세요.

실전: 잘못 흘러간 대화 지우기 — /rewind vs /compact

마지막 몇 번의 대화가 의도와 다르게 흘러간 경우 — 엉뚱한 파일을 잔뜩 읽었거나, 잘못된 수정을 반복하며 헤맨 경우 — 두 가지 방법이 있습니다.

명령어	동작	캐시	언제 쓰나
/rewind	문제 직전 시점으로 되감기 — 기차 뒤의 불량 칸 몇 개만 떼어냄	유지 (캐시는 앞에서부터 일치하는 데까지 유효하고, rewind는 뒤만 잘라내니 남은 대화가 캐시와 완벽히 일치)	문제가 마지막 몇 번의 대화에만 있을 때
/compact	대화 전체를 요약본으로 교체	대화 캐시 무효 + 요약 생성 비용	대화가 전체적으로 길고 무거워져 다이어트가 필요할 때

⭐ compact를 쓸 거라면 자리를 오래 비우기 전에 미리 하세요. compact는 모델이 대화 전체를 읽고 요약하는 작업이라 — 캐시가 살아 있을 때 하면 1/10 가격으로 읽지만, 한 시간 지나 캐시가 만료된 뒤에 하면 대화 전체를 정가로 다시 읽어야 합니다.

---

양의 문제 — “어떤 것도 한 번만 전송되지 않는다” ⭐

여기까지가 토큰 하나의 단가였다면, 이제부터는 토큰을 몇 개나 쓰게 되는지, 양의 이야기입니다. 출발점이 되는, 원문에서 제일 중요한 문장:

“어떤 것도 한 번만 전송되지 않는다.” 직관적으로는 파일 하나를 읽으면 비용을 한 번 내고 끝일 것 같지만 — Claude가 읽은 파일, 실행한 명령의 출력 등 대화에 들어온 모든 것은 세션이 끝날 때까지 대화를 주고받을 때마다 다시 전송됩니다. 캐시 덕에 싸긴 하지만, 싼 것과 공짜는 다릅니다.

그리고 돈보다 중요한 것 — 컨텍스트는 모델의 작업 책상입니다. 안 쓰는 짐이 책상을 차지하고 있으면 모델이 매번 그것까지 훑으며 생각해야 해서 품질에도 영향을 줍니다.

시작할 때부터 실려 있는 짐 — /context로 확인

도구 정의, 시스템 프롬프트, CLAUDE.md는 세션 시작과 동시에 로드돼 세션 내내 따라다닙니다. 특히 조용히 커지기 쉬운 게 MCP 서버 — 연결만 해두고 안 쓰는 서버의 도구 설명서가 수천, 많게는 수만 토큰씩 계속 실려 다닙니다. 도구를 한 번도 안 불러도, 연결돼 있다는 것만으로 비용이 나갑니다.

/context

새 세션에서 실행해보세요. 지금 뭐가 얼마나 실려 있는지 항목별로 보여줍니다. MCP 도구가 큰 자리를 차지하고 있다면 — 쓰지 않는 커넥터·MCP 연결을 정리하는 것만으로 매 세션이 가벼워집니다.

세션 중에 쌓이는 짐 — 지시가 모호할수록 커진다

세션 중 짐의 대부분은 Claude가 읽어오는 파일들과 실행 결과입니다. 내가 타이핑하는 메시지는 몇 줄이지만, Claude가 읽는 파일 하나는 수천 토큰씩 하죠. 그리고 Claude가 얼마나 많이 읽게 되는지는, 내가 얼마나 모호하게 시켰는지에 달려 있습니다. 같은 작업을 세 방식으로 시키면:

지시 방식	Claude가 하는 일	컨텍스트에 남는 것
“뭔가 잘 안 돼”	어디가 문제인지부터 탐색 — 폴더 검색, 관련 있어 보이는 파일을 하나씩 열어 확인	탐색 중 열어본 파일 전부 (문제와 상관없던 파일까지) 세션 끝까지
“이 파일의 문제를 고쳐줘” (파일명 지정)	그 파일 하나만 읽고 바로 작업	읽기 딱 한 번
@ 멘션으로 파일 선택 후 “문제를 고쳐줘”	멘션한 파일은 전송 전에 메시지에 미리 첨부됨 — “파일 읽어줘” 요청·응답 행위 자체가 생략	읽기 0번

⚠️ 멘션은 한 대화에 한 번이면 충분합니다. 파일이 이미 대화에 들어와 있으니, 같은 파일을 또 멘션하면 사본이 하나 더 붙어 오히려 컨텍스트가 늘어납니다. 두 번째부터는 그냥 파일명만 말하세요.

얼마나 오래 남나 — /clear vs /compact

매번 대화 전체가 재전송된다는 건, 40번째 질문을 할 때 앞의 39번을 전부 다시 읽는다는 뜻. 대화가 길어질수록 짊어지는 과거가 눈덩이처럼 불어나서 — 긴 세션 하나가 같은 작업을 짧은 세션 여러 개로 나눈 것보다, 생각보다 훨씬 비쌉니다.

기준은 이 질문 하나입니다 — “다음 작업에 지금까지의 대화 내용이 필요한가?”

상황	명령어
필요 없다 — 전혀 다른 작업 시작 (예: 오전의 블로그 정리를 끝내고 새 작업으로)	/clear — 대화를 백지로
요점만 필요하다 — 같은 작업의 다음 단계 (초반의 탐색 과정까지 다 들고 갈 필요는 없음)	/compact — 지나간 과정을 요약본으로 압축

💡 /compact는 남길 내용을 지정할 수도 있습니다. 뒤에 지시를 붙이세요:

/compact 결정된 내용과 파일 경로는 남겨줘

---

서브에이전트 — 짐이 생길 작업을 다른 곳에서 ⭐

지금까지의 팁은 전부 “내 대화에 짐이 덜 쌓이게 하자”였다면, 마지막은 발상이 다릅니다 — 짐이 생길 작업을 아예 처음부터 다른 곳에서 시키는 것.

서브에이전트는 메인 Claude가 작업 하나를 떼어 맡기는 별도의 Claude입니다. 필요할 때 만들어져 맡은 작업만 처리하고 사라지며, 자기만의 컨텍스트에서 일합니다.

	서브에이전트가 받는 것 / 남기는 것
시작할 때 받는 것	도구 정의, 시스템 프롬프트, CLAUDE.md — 내 대화 내용은 받지 않음 (메인에서 쌓인 파일·논의를 모르는 백지 상태)
메인으로 돌아오는 것	최종 답변 하나뿐 — 작업 중 읽은 파일, 실행 결과, 모든 과정은 작업이 끝나는 순간 전부 폐기

💡 팀장과 직원의 관계입니다. 팀장이 “이 서류더미에서 문제 되는 부분 찾아 보고해줘”라고 시키면, 직원이 자기 자리에서 서류를 다 뒤지고 팀장에게는 요약 보고서 한 장만 올리죠. 팀장의 책상(= 메인 세션의 컨텍스트)은 계속 깨끗합니다.

단, 공짜가 아닙니다. 서브에이전트는 내 대화를 모르니 메인에서 이미 읽었던 파일도 처음부터 다시 읽어야 하고, 그가 쓰는 토큰도 전부 요금에 포함됩니다. 메인 컨텍스트에 안 남을 뿐, 비용은 나갑니다. 그래서:

작업 성격	판정
작은 작업	❌ 오히려 손해
읽어야 할 건 산더미인데, 보관할 가치는 없는 작업 — 예: 수천 줄짜리 기록 파일에서 원인 찾기 (읽을 건 수천 줄, 필요한 답은 “원인은 이것” 한 줄)	⭕ 메인에서 하면 수천 줄이 세션 끝까지 짐, 서브에이전트면 결론 한 줄만 남음

사용법은 특별한 명령어가 아니라 말 한마디입니다:

이 파일은 서브에이전트에서 검토해줘

💡 좋은 소식 — Claude가 이런 성격의 작업을 만나면 알아서 서브에이전트를 쓰는 경우가 많습니다. 개념을 몰라도 이미 절약이 일어나고 있었던 거죠.

⚠️ 주의할 점 하나: 메인으로 돌아오는 건 서브에이전트가 보고하기로 선택한 내용뿐입니다. 작업 중 발견한 것이라도 답변에 담지 않으면 과정이 폐기될 때 함께 사라지니, 시킬 때 뭘 들고 돌아올지 미리 정해주세요.

---

정리 — 비용에 영향이 큰 순서 4가지

Anthropic이 원문 마지막에 정리한 순서 그대로입니다.

순위	비용 요인	대응
1위	긴 세션 — 매번 대화 전체가 재전송되어 한 세션 토큰의 대부분이 여기서 나감	새 작업은 /clear, 같은 작업의 다음 단계는 /compact — 세션을 짧고 가볍게 (절약의 절반)
2위	컨텍스트 과적 — 필요 없던 파일, 명령어 출력, 안 쓰는 MCP까지 매번 재전송되고 모델이 매번 안고 생각함	파일은 멘션으로 집어주기, 새 세션에서 /context로 짐 확인, 과정이 산더미인 작업은 서브에이전트
3위	작업에 비해 과한 모델·effort — 다른 모든 비용이 여기에 곱해지고, 두 설정 모두 다음 세션까지 이월	세션을 열면 /model과 /effort부터 확인
4위	캐시 깨뜨리기 — 대화 중간 모델·effort 변경, 1시간 이상 자리 비움 → 전체 정가 재계산	설정 변경은 세션 시작할 때, 오래 비우기 전엔 /compact 미리

단순히 팁 몇 개를 외우는 것과 원리를 이해하는 건 다릅니다. 원리를 알면 오늘 다루지 않은 상황을 만나도 “아, 이건 캐시가 깨지겠구나”, “이건 컨텍스트에 쌓이겠구나” 하고 스스로 판단할 수 있게 됩니다. 이 가이드가 그 기준이 되면 좋겠습니다.

---

참고 링크

• Anthropic 공식 블로그 (영상의 원문 자료)
• 함께 보면 좋은 가이드: 클로드 코드 — 모델과 작업량, 언제 뭘 바꿔야 할까 (토큰·가중치 원리와 모델 선택 기준)

---

Aiden의 친절한 AI