클로드 코드를 쓰다 보면 두 가지 고민이 생깁니다. “이 작업엔 어떤 모델, 어떤 작업량을 골라야 하지?” 그리고 “분명 같은 작업인데 왜 어떤 날은 사용 한도가 금방 바닥나지?” 클로드 코드 팀과 Anthropic이 공식 블로그에서 직접 밝힌 내용을 바탕으로, 이 두 질문에 대한 답을 원리부터 실전 기준까지 한 번에 정리한 시리즈 통합 가이드입니다.

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

---

이 가이드의 구성

	다루는 질문	핵심
1부. 모델과 작업량	무엇을 고르고, 언제 바꿔야 하나	모델은 누구를 고용할지, 작업량은 얼마나 꼼꼼하게 일하게 할지
2부. 토큰과 세션 효율	같은 요금제로 어떻게 더 많이 쓰나	토큰 단가의 3요소, 캐시, 그리고 “어떤 것도 한 번만 전송되지 않는다”

1부에서 클로드가 답을 만드는 원리와 설정의 의미를 잡고, 2부에서 그 원리 위에서 비용이 어떻게 계산되고 어떻게 아낄 수 있는지로 이어집니다.

---

1부. 모델과 작업량 — 언제 뭘 바꿔야 할까

흔한 두 가지 가정

클로드 코드에는 “답변을 더 좋게” 만들어주는 것처럼 보이는 설정이 두 가지 있습니다 — 모델과 작업량. 보통 이렇게 생각하기 쉽습니다.

1. Fable 5 같은 큰 모델을 쓰면 Sonnet보다 더 똑똑한 답이 나온다
2. 작업량을 높일수록 클로드가 답하기 전에 더 오래 생각한다

이 중 일부는 맞고, 일부는 오해입니다. 판단하려면 먼저 클로드가 답을 만드는 원리부터 알아야 합니다.

---

1-1. 클로드는 글자를 읽지 못한다 — 토큰

클로드는 우리가 쓴 글자를 읽지 못합니다. 숫자만 계산할 수 있습니다. 그래서 메시지는 모델에 도착하기 전에 변환됩니다.

1. 문장을 작은 조각으로 자릅니다 — 이 조각이 토큰. “클로드에게 질문했습니다”는 ‘클로드’, ‘에게’, ‘질문’, ‘했’, ’습니다’처럼 잘립니다. 단어 단위도 글자 단위도 아니고, 자주 함께 등장하는 덩어리끼리 묶입니다. (예시입니다)
2. 조각마다 번호표가 붙습니다 — ’클로드’는 3412번, ’에게’는 517번 하는 식. 결국 클로드가 받는 건 글이 아니라 번호들의 목록입니다.

모델이 하는 일은 “이 다음에 올 조각이 뭘까?“를 맞히는 것 — 카카오톡 자동완성과 본질적으로 같습니다. 사전의 조각 전부(수만 개)에 “다음에 올 가능성 몇 %“를 매기고 가장 높은 걸 골라 붙이고, 또 맞히고 — 수백 번 반복한 결과가 답변입니다.

💡 답변이 주르륵 흘러나오는 건 한 조각씩 만들어지는 과정을 실시간으로 보는 것. 요금이 토큰 단위로 매겨지는 이유도 이것 — 조각 하나하나가 클로드가 일한 양이니까요.

---

1-2. 가중치는 ’인쇄된 책’이다

’다음 조각을 맞히는 실력’의 정체가 가중치 — 수십억 개의 숫자 덩어리입니다. 우리가 “밥은 먹고 다니” 다음에 ’냐’가 온다는 걸 아는 건 그 말을 수없이 들어 머리에 새겨져 있기 때문이죠. 가중치가 바로 그것 — 모델의 기억이자 언어 감각 전체입니다.

그리고 이 숫자 덩어리는 학습이 끝나는 순간, 인쇄된 책처럼 굳습니다. 아무리 좋은 프롬프트를 써도, 최신 자료를 넣어줘도 책 내용은 안 바뀝니다.

💡 “자료를 넣어주면 잘 참고하던데?” — 그건 책에 내용이 추가된 게 아니라 책 사이에 포스트잇을 끼워준 것입니다. 이번 답변엔 참고하지만, 대화가 끝나면 포스트잇은 사라지고 책은 그대로. 그래서 다음 대화에서 “지난번에 알려줬잖아”가 통하지 않고, 최신 라이브러리는 매번 포스트잇으로 줘야 합니다.

ℹ️ 할루시네이션도 여기서 나옵니다. 거짓말이 아니라, ’다음 조각 맞히기’가 책에 없는 내용을 그럴듯한 패턴으로 메워버린 것입니다.

---

1-3. 판정 — 모델과 작업량은 무엇을 정하나

모델: 누구를 고용할 것인가

모델을 바꾼다 = 다른 책을 꺼내 든다. 더 두껍고 더 많은 경험이 인쇄된 책으로 — 기술적으로는 가중치 덩어리가 통째로 교체되는 것.

→ 가정 1 “큰 모델이 더 똑똑한 답을 낸다”는 맞습니다.

모델 설정이 정하는 건 어떤 책이 답할지, 그리고 그 답변이 토큰당 얼마인지 — 시급이 정해진 직원을 고용하는 것과 같습니다(Opus는 시급 비싼 전문가, Sonnet은 시급 저렴한 실력자). 그런데 모델이 정하지 않는 게 하나 있습니다 — 그 직원이 몇 시간 일할지.

작업량: 얼마나 꼼꼼하게 일하게 할 것인가

같은 질문도 클로드는 그때그때 다르게 받아들입니다. “관련 파일 세 개는 읽고, 답 내고 검증도 해야겠다” 하고 일을 크게 벌이기도, 바로 답으로 가기도 하죠. 질문은 같은데 청구서가 달라지는 것 — 이걸 정하는 설정이 작업량이고, 조절하는 건 시간만이 아니라 일하는 태도 전체입니다.

작업량이 조절하는 것	낮음 쪽	높음 쪽
파일을 몇 개나 읽을지	직접 관련된 파일만	연결된 주변 파일까지
얼마나 검증할지	답을 내고 끝	테스트 돌리고 한 번 더 확인
혼자 얼마나 처리할지	중간중간 확인받으러 옴	끝까지 해놓고 완성본을 들고 옴

⭐ “이 정도면 됐다”의 기준선이 어디 있느냐 — 그게 작업량입니다. 높이면 스스로 확실해질 때까지 읽고 확인한 뒤 돌아오고, 낮추면 더 일찍 돌아옵니다.

→ 가정 2 “작업량을 높이면 더 오래 생각한다”는 절반만 맞습니다. 생각 시간도 늘지만, 실제로는 읽기·검증·자율 처리 범위까지 태도 전체가 달라집니다.

모델은, 누구를 고용할 것인가. 작업량은, 그 사람을 얼마나 꼼꼼하게 일하게 할 것인가.

둘은 완전히 별개의 설정입니다. 비싼 전문가에게 5분만 시킬 수도, 합리적인 가격의 실력자에게 하루 종일 시킬 수도 있습니다.

---

1-4. 시연 — 같은 모델, 작업량만 낮음 vs 높음

2026년 코딩 도구 비교 기사 20편이 든 폴더에서, 모델은 Opus로 고정하고 작업량만 바꿔 같은 요청을 두 번 돌렸습니다.

이 기사들에 나온 수치나 주장 중에서,
영상에 인용해도 안전한 것과 위험한 것을 구분해줘.

구분	작업량 낮음	작업량 높음
기사 읽기	20편 전부	20편 전부
검증 범위	폴더 안에서 기사끼리 대조 — “출처 없음”, “서로 충돌”, “제조사 자체 발표” 판정	폴더 밖으로 — 검증용 에이전트 투입, 웹 검색으로 원 출처 대조, 맥락과 다르게 인용된 수치까지 추적
부가 산출물	—	검증 결과를 참고 문서로 정리
소요	약 5분 · 약 31만 토큰	약 30분 · 약 220만 토큰

시간 6배, 토큰 7배. 그리고 주목할 공통점 — 낮음도 20편을 전부 읽었습니다. 필요한 일은 낮음도 건너뛰지 않습니다.

높음이 무조건 정답은 아니다

낮음의 답도 실무에서 바로 쓸 수준이었습니다. 7배의 토큰이 낭비였는지는 결과물이 어디에 쓰이느냐에 달렸습니다 — 혼자 참고하는 메모라면 낮음으로 충분하고, 임원 보고서에 들어가 “이 숫자 출처가 어디죠?“에 답해야 한다면 7배가 하나도 아깝지 않습니다.

“높음으로 두면 간단한 일도 매번 30분씩 벌이나?”

아닙니다. 필요 없는 일은 높음도 벌이지 않습니다.

• Anthropic은 학습 단계에서 ’과잉 사고’를 일부러 억제한다고 밝힙니다. 돈 낭비라서가 아니라, 쓸데없이 오래 고민할수록 결과물이 오히려 나빠지기 때문.
• 높음이 일을 벌였다가도 적절한 답이 나오면 계획을 접습니다. 클로드 코드에서 작업 목록이 실행 중에 지워지거나 바뀌는 것 — 버그가 아니라 이 현상입니다.

⭐ 작업량을 높인다는 건 “필요하면 더 해도 돼”라는 허락이지, “무조건 더 해”라는 명령이 아닙니다.

---

1-5. 클로드가 틀렸을 때 — 진단 3단계 ⭐

틀린 답이 나오면 본능적으로 설정으로 손이 갑니다. Anthropic은 그 손을 멈추라고 합니다.

1단계 — 내가 제대로 줬나?

점검	질문
요청	“적당히 정리해줘”처럼 모호하게 시켜놓고 결과를 탓하고 있진 않은가?
자료	봐야 할 파일은 연결도 안 해놓고 알아서 찾길 바라진 않는가?
환경	필요한 도구나 권한 없이 시키고 있진 않은가?

💡 클로드는 우리가 건네준 포스트잇으로 일합니다. 포스트잇을 부실하게 줘놓고 사람을 바꾸거나(모델) 더 꼼꼼히 하라고(작업량) 해봐야 없는 자료가 생기지는 않습니다.

2단계 — 다 읽고도 틀렸으면 → 모델

“몰라서 틀렸다” = 실력 문제, 책에 없는 것.

• 올릴 신호는 하나 — 클로드가 자신 있게, 계속 틀릴 때. 포스트잇을 아무리 붙여도 안 되는 상황입니다.
• 내릴 신호는 없습니다. 어려운 작업 때문에 올렸다가 고비를 넘긴 뒤에도 그대로 두는 패턴이 흔합니다 — 시급 비싼 전문가에게 복사 업무를 시키는 셈. 일상적 작업엔 작은 모델로 내려주세요.

⭐ 지시가 구체적일수록 작은 모델로 충분하고, 모호할수록 큰 모델이 필요합니다. “이 파일의 이 부분을 이렇게 바꿔줘”는 작은 모델이, “우리 자료 어딘가 문제가 있는 것 같은데 찾아봐줘”는 큰 모델이 필요하죠. 뒤집으면 — 요청을 구체적으로 쓰는 노력 자체가 돈을 아껴주는 기술입니다.

3단계 — 건너뛰고 틀렸으면 → 작업량

“대충 해서 틀렸다” = 꼼꼼함 문제. 클로드 코드는 어떤 파일을 읽었는지, 뭘 실행했는지 화면에 다 보여주므로 진단은 감이 아니라 관찰로 합니다.

💡 건너뛰는 일은 주로 작업량을 기본값보다 낮춰놨을 때 생깁니다. 더 올리기 전에 기본값으로 돌아오는 것부터.

---

1-6. 기본값의 재발견

기본값은 제조사가 대충 중간에 놓은 값이 아니라, “대부분의 사람이 이 작업에 이 정도면 쓰겠다” 싶은 지점에 맞춰 조율한 품질·비용의 균형점입니다. 세부 조절은 클로드가 작업마다 알아서 합니다. 그래서 공식 결론은 — “대부분의 작업에는 기본값을 쓰세요.”

작업량은 작업마다 바꾸는 게 아니라, 내 일의 성격에 맞춰 한 번 정해두는 것입니다.

나는 어떤 사람인가	설정
틀리면 안 되는 자료를 만드는 사람	높게
아이디어를 빠르게 쳐내는 게 중요한 사람	낮게
둘 다 아니라면	기본값 그대로 두고 잊기

---

2부. 토큰과 세션 효율 — 같은 요금제로 더 많이 쓰는 법

같은 작업이라도 사용 방식에 따라 비용이 달라집니다. Anthropic이 공개한 원리를 따라가 보겠습니다.

2-1. 토큰 가격은 무엇이 결정하나

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

💡 전기요금과 비슷합니다. 고지서엔 “몇 kWh에 얼마”라고 찍히지만, 그 뒤의 핵심 비용은 발전소를 돌리는 연료비죠. 청구는 토큰 개수로, 실제 비용은 GPU가 돌아간 시간으로.

토큰 하나의 처리 시간을 결정하는 건 세 가지 — ① 모델 ② 입력인지 출력인지 ③ 캐시 여부.

① 모델 — 개수 단위 × 개당 단가

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

⭐ 토큰은 개수 단위, 모델은 개당 단가. 그리고 아래 나올 모든 절약 팁의 효과가 전부 모델 단가에 곱해집니다. 어려운 문제는 큰 모델, 단순 작업은 작은 모델 — 절약의 첫 번째 원칙입니다.

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

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

출력이 입력보다 약 5배 비싼 이유 — 읽기는 시험지 지문을 훑듯 한꺼번에 병렬 처리되지만, 쓰기는 직전 토큰이 나와봐야 다음 토큰이 정해집니다(“안녕하세”까지 봐야 “요”). 200토큰 답변은 모델 전체를 200번 연달아 돌린 결과 — 벽돌 200장을 한 트럭에 싣는 것과 한 장씩 200번 왕복하는 것의 차이입니다.

/effort — 비싼 사고 토큰의 손잡이

화면의 답변은 출력의 일부일 뿐, 상당 부분은 속으로 하는 사고 토큰이고 이것도 5배 단가입니다. 이 양을 조절하는 게 /effort — 1부의 작업량이 비용 측면에서 이런 의미를 갖는 것이죠.

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

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

매 요청마다 대화 전체를 다시 읽는다고 했죠. 그런데 1분 전 요청과 지금 요청은 앞부분이 완전히 똑같고 끝에 몇 줄 붙었을 뿐입니다. 그래서 서버는 직전 계산 결과를 들고 있다가, 같은 내용으로 시작하면 앞부분은 재사용하고 새 뒷부분만 계산합니다 — 프롬프트 캐싱.

동작	가격
저장	정가의 최대 약 2배 (계산비 + 보관료)
재사용	정가의 0.1배

대화 초반의 토큰 하나가 20번 읽힌다면:

	계산	비용
캐싱 없음	1 × 20	20
캐싱	2 + 0.1 × 19	3.9

약 5배 차이. Claude Code가 이걸 자동으로 해주고, 우리가 할 일은 캐시를 깨뜨리지 않는 것뿐입니다.

---

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

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

⭐ 끝에 새 칸이 붙는 평소 대화가 이상적입니다. 문제는 앞쪽 칸이 바뀔 때 — 그 뒤 모든 칸이 내용이 같아도 도미노처럼 전부 재계산됩니다.

도미노를 넘어뜨리는 행동	이유
대화 중간에 모델·effort 변경	캐시엔 “어떤 모델·effort로 계산했는지” 꼬리표가 붙고, 재사용하려면 꼬리표까지 같아야 함
/compact 사용	대화를 요약본으로 통째로 교체 — 대화 부분 캐시 전부 무효
1시간 경과	마지막 대화 후 1시간이 지나면 캐시 만료 (대화 중엔 타이머 리셋)

💡 “모델도 바꾸지 말고 compact도 하지 말라는 건가?” — 아닙니다. 세션 시작 직후나 /clear 직후처럼 비용이 적게 드는 시점이 따로 있다는 뜻입니다. 1부에서 “작업량은 작업마다가 아니라 한 번 정해두라”고 한 것과도 맞닿는 이야기죠.

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

명령어	동작	캐시	언제
/rewind	문제 직전 시점으로 되감기 — 뒤의 불량 칸만 떼어냄	유지 (남은 대화가 캐시와 앞에서부터 완벽히 일치)	문제가 마지막 몇 번의 대화에만 있을 때
/compact	대화 전체를 요약본으로 교체	무효 + 요약 비용	대화가 전체적으로 길고 무거울 때

⭐ compact는 자리를 오래 비우기 전에 미리. 캐시가 살아 있을 때 하면 1/10 가격으로 읽으며 요약하지만, 만료 후에 하면 대화 전체를 정가로 다시 읽습니다.

---

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

단가 다음은 양입니다. 출발점이 되는, 원문에서 가장 중요한 문장:

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

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

시작할 때부터 실린 짐 — /context

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

/context

새 세션에서 실행하면 뭐가 얼마나 실려 있는지 항목별로 보여줍니다. MCP가 크게 차지한다면 쓰지 않는 커넥터·MCP 연결 정리만으로 매 세션이 가벼워집니다.

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

짐의 대부분은 클로드가 읽는 파일과 실행 결과입니다. 그리고 얼마나 읽게 되는지는 내가 얼마나 모호하게 시켰는지에 달려 있습니다. 1부의 “구체적 지시가 작은 모델로 충분하게 해준다”와 같은 원리가 여기서는 양을 줄입니다.

지시 방식	클로드가 하는 일	남는 짐
“뭔가 잘 안 돼”	폴더 검색, 관련 있어 보이는 파일을 하나씩 열어봄	탐색 중 연 파일 전부 (상관없던 파일까지)
“이 파일의 문제를 고쳐줘”	그 파일 하나만 읽고 작업	읽기 1번
@ 멘션으로 파일 선택 + “문제를 고쳐줘”	전송 전에 메시지에 미리 첨부 — 읽기 요청·응답 자체가 생략	읽기 0번

⚠️ 멘션은 한 대화에 한 번이면 충분합니다. 다시 멘션하면 사본이 하나 더 붙어 오히려 늘어납니다. 두 번째부터는 파일명만 말하세요.

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

40번째 질문을 할 때는 앞의 39번을 전부 다시 읽습니다. 그래서 긴 세션 하나가, 짧은 세션 여러 개로 나눈 것보다 생각보다 훨씬 비쌉니다.

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

답	명령어
필요 없다 — 전혀 다른 작업 시작	/clear — 백지로
요점만 필요하다 — 같은 작업의 다음 단계	/compact — 과정을 요약본으로 압축

💡 /compact는 남길 내용을 지정할 수도 있습니다:

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

---

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

지금까지가 “내 대화에 짐이 덜 쌓이게”였다면, 이건 짐이 생길 작업을 처음부터 다른 곳에서 시키는 것입니다. 서브에이전트는 메인 Claude가 작업을 떼어 맡기는 별도의 Claude로, 자기만의 컨텍스트에서 일합니다.

시작할 때 받는 것	도구 정의, 시스템 프롬프트, CLAUDE.md — 내 대화 내용은 받지 않음 (백지 상태)
메인으로 돌아오는 것	최종 답변 하나뿐 — 읽은 파일, 실행 결과 등 과정은 끝나는 순간 전부 폐기

💡 팀장이 “이 서류더미에서 문제 되는 부분 찾아 보고해줘”라고 하면, 직원이 자기 자리에서 다 뒤지고 팀장에겐 요약 보고서 한 장만 올리죠. 팀장의 책상(= 메인 컨텍스트)은 깨끗하게 유지됩니다.

단, 공짜가 아닙니다. 메인에서 읽은 파일도 다시 읽어야 하고, 서브에이전트가 쓰는 토큰도 전부 요금에 포함됩니다.

작업 성격	판정
작은 작업	❌ 오히려 손해
읽을 건 산더미인데, 보관할 가치는 없는 작업 — 수천 줄 로그에서 원인 찾기 (필요한 답은 “원인은 이것” 한 줄)	⭕ 결론 한 줄만 남음

사용법은 말 한마디입니다:

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

💡 클로드는 이런 성격의 작업을 만나면 알아서 서브에이전트를 쓰는 경우가 많습니다.

⚠️ 메인으로 돌아오는 건 서브에이전트가 보고하기로 선택한 내용뿐 — 시킬 때 뭘 들고 돌아올지 미리 정해주세요.

---

정리 — 시리즈 한 장 요약

비용에 영향이 큰 순서 (Anthropic 원문 기준)

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

클로드가 틀렸을 때 (1부)

① 내가 제대로 줬는지 확인 → ② 다 읽고도 틀렸으면 모델 ↑ → ③ 건너뛰고 틀렸으면 작업량 ↑ (먼저 기본값으로)

두 편을 관통하는 한 가지

⭐ 요청을 구체적으로 쓰는 것. 1부에서는 더 작은 모델로도 충분하게 만들어 단가를 낮추고, 2부에서는 클로드가 헤매며 읽는 파일을 줄여 양을 낮춥니다. 가장 싸고 가장 효과적인 절약법입니다.

팁 몇 개를 외우는 것과 원리를 이해하는 건 다릅니다. 원리를 알면 이 가이드에서 다루지 않은 상황을 만나도 “이건 작업량 문제구나”, “이건 캐시가 깨지겠구나”, “이건 컨텍스트에 쌓이겠구나” 하고 스스로 판단할 수 있게 됩니다.

---

참고 링크

• 클로드 코드 팀 공식 블로그 — 모델·작업량 선택 기준 (1부 원문)
• Anthropic 공식 블로그 — 토큰·캐시·세션 효율 (2부 원문)

---

Aiden의 친절한 AI