클로드 코드 세션 경제학 — 토큰은 어디서 새고, 캐시는 왜 1시간 뒤에 증발하는가

들어가며: 같은 일인데 왜 어떤 날은 3배 비쌀까

금요일 오후. 어느 백엔드 개발자가 Claude Code를 켜고 하루를 시작한다. 아침엔 API 엔드포인트 하나를 고쳤고, 점심 먹고 돌아와 같은 창에서 테스트 실패를 잡았고, 저녁엔 그 창에서 내일 발표용 README까지 썼다. 자기 전에 사용량 대시보드를 열어 본 그는 고개를 갸웃한다. "어제랑 한 일은 비슷한데, 왜 오늘 토큰이 3배지?"

답은 코드에 있지 않다. 세션을 어떻게 썼는가에 있다. 하나의 창에서 아침부터 저녁까지 버틴 것, 점심 먹는 동안 캐시가 증발한 것, 테스트 러너가 뿜어낸 4만 자짜리 로그가 저녁 README 작업까지 따라다닌 것 — 이 세 가지가 청구서를 불렸다.

2026년 8월 14일, Anthropic의 Lydia Hallie가 쓴 Maximizing the value of your Claude Code sessions는 바로 이 질문에 답하는 글이다. 짧고 실용적이다. 하지만 글이 제시하는 처방 — /clear, /compact, @멘션, 조용한 플래그, 서브에이전트 — 이 왜 효과가 있는지를 이해하려면, 트랜스포머가 문장을 읽는 방식부터 프롬프트 캐시가 등장한 배경, 그리고 "긴 맥락이 오히려 독이 된다"는 최근 연구까지 한 번 훑어야 한다.

이 글은 그 여정을 따라간다.

---

제1장: 토큰 한 개의 값은 어떻게 정해지나

가이드는 "토큰 한 개의 가격을 결정하는 것은 세 가지"라고 못 박는다. 어떤 모델이 처리하는가, 입력인가 출력인가, 캐시에서 읽는가. 이 세 가지는 독립적인 가격표가 아니라, 트랜스포머라는 기계가 돌아가는 물리적 방식에서 나온 결과다.

크게 보기

1-1. 모델: 큰 두뇌는 모든 토큰이 비싸다

가장 직관적인 요인이다. 파라미터가 많은 모델은 토큰 하나를 읽을 때도, 쓸 때도 더 많은 연산을 한다. 그래서 입력과 출력 양쪽의 단가가 모두 올라간다. 가이드는 이 요인을 비용 기여도 1순위로 꼽으며 "진짜 어려운 문제엔 큰 모델을, 일상적인 일엔 작은 모델을" 쓰라고 권한다.

당연한 말 같지만 현장에서는 잘 안 지켜진다. 이유는 단순하다. 모델을 바꾸는 게 귀찮고, 바꾸면 캐시가 깨진다(2장에서 설명). 그래서 한 번 큰 모델로 시작한 세션은 끝까지 큰 모델로 간다. 변수명 바꾸기, 로그 한 줄 읽기, 커밋 메시지 쓰기까지 전부 최고가 모델에게 시키는 셈이다.

1-2. 입력 vs 출력: 읽기는 병렬, 쓰기는 한 글자씩

여기가 첫 번째 "왜"다. 왜 출력 토큰이 입력 토큰보다 5배쯤 비쌀까?

트랜스포머의 추론은 두 단계로 나뉜다.

2017년 「Attention Is All You Need」가 제안한 구조는 학습할 때는 완벽히 병렬이었지만, 생성할 때는 본질적으로 한 글자씩 쓰는 타자기였다. 이 비대칭은 8년이 지난 지금도 그대로이고, 그게 가격표에 그대로 찍혀 있다.

사고 토큰이 출력이라는 점이 실무에서 중요하다. Claude Code의 /effort 수준을 높이면 모델이 답하기 전에 더 길게 생각한다. 그 생각은 전부 출력 토큰 — 즉 가장 비싼 토큰 — 으로 과금된다. 가이드가 "명백한 단순 작업에는 MAX_THINKING_TOKENS=0으로 사고를 꺼라"고 하는 이유다(단, 가이드에 따르면 Fable 5에서는 적용되지 않는다).

1-3. 캐시: 이미 읽은 걸 다시 읽지 않는다

세 번째 다이얼은 가장 강력하다. 캐시에서 읽은 토큰은 입력 단가의 0.1배다. 10분의 1. 대신 캐시에 처음 쓸 때는 최대 2배의 비용이 들지만, 이건 토큰당 한 번뿐이다.

왜 이런 할인이 가능한지, 그리고 왜 이 할인이 1시간 뒤에 사라지는지는 별도의 장이 필요하다.

---

제2장: 프롬프트 캐시 — 0.1배의 마법과 1시간의 저주

2-1. 왜 같은 책을 매번 처음부터 읽었나

2023년까지 LLM API는 기억이 없었다. 대화형 앱이 열 번째 메시지를 보낼 때, 서버는 앞의 아홉 번의 대화를 처음부터 다시 읽었다. 사용자에게는 연속된 대화지만 서버에게는 매번 새 문서였다. 대화가 길어질수록 매 턴 재읽기 비용이 선형으로 늘었고, 턴 수를 곱하면 총비용은 제곱으로 늘었다.

이 낭비는 기술적으로는 오래 전부터 피할 수 있었다. 트랜스포머가 프롬프트를 읽을 때 각 토큰에 대해 만드는 중간 계산값 — 키(Key)와 밸류(Value) — 를 버리지 않고 저장해 두면, 다음 요청에서 같은 접두사가 오면 그 부분은 계산을 건너뛸 수 있다. 이것이 KV 캐시다. 문제는 이 캐시가 메모리를 엄청나게 먹는다는 것이었다. 2023년 UC 버클리 팀이 발표한 vLLM의 「PagedAttention」(Kwon et al., SOSP 2023)은 운영체제의 가상 메모리처럼 KV 캐시를 페이지 단위로 관리해 이 문제를 크게 완화했고, 이후 추론 서버들이 요청 간에 접두사를 공유하는 것이 현실적인 선택지가 됐다.

2024년 8월 Anthropic이 API에 프롬프트 캐싱을 공개했을 때, 내세운 숫자가 바로 "캐시 읽기 최대 90% 절감"이었다. 가이드에 나오는 0.1배는 이 약속이 2년 뒤 Claude Code까지 내려온 결과다.

크게 보기

2-2. 캐시는 '접두사'에만 적중한다

캐시를 이해하는 단 하나의 원리가 있다. 접두사(prefix)가 정확히 같아야 적중한다.

트랜스포머는 토큰을 순서대로 읽으며 각 토큰의 계산값이 앞의 모든 토큰에 의존한다. 그래서 대화의 100번째 토큰까지 캐시가 있더라도, 50번째 토큰이 한 글자라도 바뀌면 50번째 이후의 캐시는 전부 무효다. 반대로 뒤에 무언가를 덧붙이는 것은 앞의 캐시를 전혀 건드리지 않는다.

이 원리 하나로 가이드의 "캐시를 깨는 행동" 목록이 전부 설명된다.

가장 실용적인 교훈은 /rewind와 /compact의 차이다. 둘 다 "대화를 줄인다"는 점은 같다. 하지만 /rewind는 최근 턴을 잘라내는 것이라 앞부분 캐시가 그대로 살고, /compact는 전체를 요약해 다시 쓰는 것이라 캐시가 통째로 날아간다. 가이드의 표현을 빌리면 "되돌리기는 사실상 공짜다(rewinding costs nothing)". 방향을 잘못 잡은 최근 몇 턴을 지우고 싶다면 답은 /rewind다.

직접 판단해 보자. 아래 퀴즈는 가이드의 목록을 상황으로 바꾼 것이다.

2-3. 1시간의 저주, 그리고 점심시간의 전략

캐시는 서버 메모리를 점유한다. 무한히 둘 수 없으니 수명이 있다. 구독 플랜은 1시간, API 키는 5분. 이 수명이 만드는 실무 패턴이 흥미롭다.

사례를 보자. 오전 내내 큰 리팩터링을 하던 개발자가 12시에 점심을 나간다. 1시 반에 돌아와 "아까 하던 거 이어서"라고 친다. 이 순간 서버는 오전 내내 쌓인 15만 토큰의 대화를 처음부터 다시 프리필한다. 캐시가 만료됐기 때문이다. 캐시 쓰기 비용까지 더하면 아침 첫 프롬프트의 수십 배 비용이 한 번에 나간다.

가이드의 처방은 역발상이다. "쉬기 전에 /compact하라." 어차피 1시간 뒤에 캐시가 죽을 거라면, 죽기 전에 대화를 작게 요약해 두는 편이 낫다. /compact가 캐시를 깨는 건 맞지만, 곧 만료될 캐시를 깨는 건 손해가 아니다. 돌아와서 다시 프리필할 토큰이 15만 개가 아니라 2만 개가 된다.

반대로 세션을 시작할 때의 규칙도 캐시에서 나온다. 가이드는 "/model과 /effort는 새 세션에서, 첫 프롬프트를 치기 전에 설정하라"고 한다. 첫 프롬프트 전에는 캐시에 쓴 게 거의 없으니 바꿔도 손해가 없다. 대화가 10만 토큰 쌓인 뒤에 /effort high를 치는 순간, 그 10만 토큰의 캐시가 증발하고 다시 2배 비용으로 써진다. 두 명령 모두 마지막 선택을 기억하므로, 오늘의 기본값을 정해 두는 습관이 비용을 가른다.

---

제3장: 컨텍스트라는 병(瓶) — 무엇이 채우고, 무엇이 넘치나

3-1. 컨텍스트 창의 짧은 역사

컨텍스트 창은 모델이 한 번에 "볼 수 있는" 토큰의 한계다. 이 창은 지난 7년 동안 1,000배 커졌다.

1K에서 1M으로. 그래서 한동안 업계의 분위기는 "이제 다 넣어도 된다"였다. 리포지토리 전체를 붙이고, 문서 수백 쪽을 붙이고, 대화를 끝없이 이어가도 된다고. 하지만 두 가지 현실이 이 낙관을 꺾었다. 하나는 돈이고(창이 커져도 토큰당 가격은 0이 되지 않는다 — 그리고 컨텍스트가 클수록 매 턴 그 전체를 다시 보낸다), 다른 하나는 품질이다(4장에서 다룬다).

3-2. Claude Code의 병은 무엇으로 채워지나

가이드는 컨텍스트를 채우는 항목을 명확히 나열한다. 세션을 시작하는 순간 시스템 프롬프트, 도구 정의, CLAUDE.md가 들어간다. 그 뒤로 대화가 진행되면서 Claude가 Read로 읽은 파일, 실행한 명령의 출력, 그리고 주고받은 메시지가 쌓인다. 그리고 결정적인 한 문장:

"Command output stays in the conversation for all subsequent turns." — 명령 출력은 그 이후 모든 턴에 남아 있다.

크게 보기

이게 왜 중요한가. 아침에 npm test를 한 번 돌려 4만 자짜리 실패 로그가 들어왔다고 하자. 그 로그는 저녁에 README를 쓸 때도 여전히 컨텍스트 안에 있다. 캐시 덕에 0.1배로 싸게 실리긴 하지만, 0이 아니다. 그리고 한 번 /compact나 캐시 만료를 거치면 그 4만 자는 다시 정가로 읽힌다. 더 나쁜 건, 모델이 README를 쓰는 동안 그 실패 로그에 주의를 빼앗긴다는 것이다.

아래 탐색기에서 병을 채우는 항목들을 확인하고, 가이드가 권하는 절약 습관을 하나씩 켜 보자.

3-3. 병을 덜 채우는 다섯 가지 습관

가이드가 제시하는 처방을 "왜 효과가 있는가"와 함께 정리한다.

① @멘션으로 파일을 붙인다. "email.ts 좀 봐줘"라고 말하면 Claude는 그 파일을 찾기 위해 탐색하고, 비슷한 이름의 파일 여러 개를 읽을 수 있다. 각 Read는 컨텍스트에 남는다. @src/lib/email.ts라고 쓰면 그 파일이 현재 턴에 바로 첨부된다. 탐색 과정의 Read 호출이 사라지고, 덤으로 접두사가 바뀌지 않아 캐시도 안전하다.

② 시끄러운 명령에 조용한 플래그를 붙인다. 테스트 러너의 기본 출력은 사람을 위한 것이다. 진행 막대, 색상, 각 테스트의 이름… Claude에게 필요한 건 "뭐가 실패했나"뿐이다. --reporter=dot 같은 플래그 하나가 4만 자를 400자로 줄인다. 가이드는 한발 더 나아가 자주 쓰는 명령을 플래그까지 포함해 CLAUDE.md에 적어 두라고 권한다. 그러면 Claude가 매번 조용한 버전을 쓴다.

③ CLAUDE.md를 구체적으로, 얇게 유지한다. CLAUDE.md는 모든 세션의 첫 페이지다. 여기 적힌 모든 문장이 모든 세션, 모든 턴에 실린다. 가이드는 "워크플로 지침은 스킬(skills)로 옮기라"고 한다. 스킬은 필요한 순간에만 로드되므로, 가끔 쓰는 배포 절차 같은 것을 CLAUDE.md에 두는 건 매 턴 통행료를 내는 셈이다.

④ /context로 한 번 들여다본다. 새 세션을 열고 /context를 치면 지금 무엇이 얼마나 실려 있는지 보인다. 연결만 해 두고 안 쓰는 MCP 서버의 도구 정의가 수만 토큰을 차지하고 있는 경우가 드물지 않다. 가이드의 권고는 간단하다 — "한 번만 해 봐라, 놀랄 것이다."

⑤ 큰 출력은 서브에이전트에게 시킨다. 이건 별도의 절이 필요하다.

3-4. 서브에이전트: 격리된 방에서 일하고 쪽지만 돌려준다

서브에이전트는 자기만의 컨텍스트 창을 가진다. 시스템 프롬프트와 도구는 받지만, 내 대화 이력은 받지 않는다. 일을 마치면 결과만 짧게 돌려주고 사라진다. 그 과정에서 읽은 파일, 돌린 명령의 출력은 내 컨텍스트에 들어오지 않는다.

크게 보기

가이드는 서브에이전트가 비용 효율적인 조건을 정확히 짚는다. "그 작업이 다시는 필요 없을 출력을 만들 때." 예를 들면:

• 전체 테스트 스위트를 돌리고 실패한 것만 추려 오기
• 로그 파일 수만 줄에서 특정 에러의 첫 발생 지점 찾기
• 리포지토리 전체를 훑어 어떤 함수가 어디서 호출되는지 목록 만들기

이런 작업의 중간 산출물(로그 전체, 읽은 파일 수십 개)은 본체가 기억할 필요가 없다. 필요한 건 "3개 실패, 모두 auth 모듈" 같은 한 줄이다. 서브에이전트는 이 한 줄만 건네고, 수십만 토큰의 쓰레기는 자기 방에서 처리하고 끝낸다.

이 발상은 2025년 6월 Anthropic이 공개한 멀티에이전트 리서치 시스템 설계에서 이미 핵심이었다. 그 글은 서브에이전트를 "컨텍스트 격리" 장치로 설명하며, 각 서브에이전트가 자기 창에서 탐색을 하고 압축된 결과만 리드 에이전트에게 돌려주는 구조를 택했다. Claude Code의 서브에이전트는 같은 원리를 개인 개발자의 터미널로 가져온 것이다.

주의점도 있다. 서브에이전트는 내 대화를 모르므로 과제를 자족적으로 적어 줘야 한다. "아까 그 버그"는 통하지 않는다. 그리고 서브에이전트 자신도 토큰을 쓴다 — 다만 그 토큰이 내 세션에 복리로 붙지 않는다는 점이 다르다. 복리 이야기는 다음 장이다.

---

제4장: 긴 세션의 역설 — 비용은 복리로 붙는다

4-1. 턴마다 전부 다시 보낸다

가이드에서 가장 중요한 문장을 꼽으라면 이것이다.

"Costs compound across turns because every turn re-sends (and re-reads from cache) everything in the conversation history." — 비용은 턴마다 복리로 쌓인다. 모든 턴이 대화 이력 전체를 다시 보내기 때문이다.

이걸 숫자로 느껴 보자. 턴마다 4,000토큰씩 쌓이는 세션이 있다고 하자. 10번째 턴에서 서버가 받는 입력은 4만 토큰. 50번째 턴에서는 20만 토큰. 100턴을 채우면 서버로 보낸 누적 입력은 약 2천만 토큰이다. 캐시가 0.1배로 깎아 주더라도, 이 누적 구조 자체는 변하지 않는다. 한 턴의 비용 = 그 시점의 컨텍스트 크기이고, 컨텍스트는 턴마다 커진다.

그래서 가이드는 이렇게 말한다. "긴 세션 하나가 같은 일을 짧은 세션 몇 개로 나눈 것보다 비싸다."

아래 시뮬레이터로 직접 확인해 보자. 턴 수, 턴당 쌓이는 양, 모델, 캐시 상태, 세션을 몇 개로 나누는지를 바꿔 가며 세 막대를 비교하면 된다.

4-2. 돈만의 문제가 아니다 — 'Lost in the Middle'에서 'Context Rot'까지

긴 세션이 비싼 것은 절반의 문제다. 나머지 절반은 품질이다.

2023년 스탠퍼드의 Nelson Liu 등이 발표한 「Lost in the Middle」(TACL 2024)은 단순한 실험으로 업계를 놀라게 했다. 모델에게 문서 여러 개를 주고 질문하는데, 정답이 든 문서의 위치만 바꿨다. 결과는 U자 곡선이었다. 정답이 맨 앞이나 맨 뒤에 있으면 잘 맞히고, 가운데 있으면 크게 떨어졌다. 창 안에 있다고 해서 모델이 그걸 똑같이 "보는" 건 아니었다.

2025년 7월 Chroma 연구팀의 「Context Rot」은 이 현상을 18개 최신 모델로 확장했다. 결론은 더 불편했다. 입력이 길어질수록 성능이 떨어지는 경향은 아주 단순한 과제에서도 나타났고, 관련 없는 내용(distractor)이 섞이면 더 나빠졌다. 창이 100만 토큰이라는 건 "100만 토큰을 똑같은 품질로 처리한다"는 뜻이 아니었다.

Anthropic 자신도 2025년 9월 「Effective context engineering for AI agents」에서 이를 공식화했다. 컨텍스트는 "한계 수익이 체감하는 유한한 자원"이며, 모델에게는 일종의 "주의력 예산(attention budget)"이 있어서 토큰이 늘수록 한 토큰에 쓸 수 있는 주의가 줄어든다는 것이다.

이 흐름을 보면 가이드의 위치가 분명해진다. 학계가 "긴 컨텍스트는 생각보다 약하다"를 증명했고, Anthropic이 "그러니 컨텍스트를 설계하라"는 원칙을 세웠으며, 이 가이드는 그 원칙을 터미널 앞의 개발자가 오늘 할 수 있는 동작으로 번역한 것이다. 컨텍스트 엔지니어링의 이론적 배경은 이 블로그의 컨텍스트 엔지니어링 완전 정복과 긴 맥락이 독이 된다: Context Rot에서 더 깊이 다뤘다.

크게 보기

4-3. 세션을 자르는 기술

그래서 가이드의 세션 관리 규칙은 이렇게 정리된다.

마지막 항목은 특히 뼈아픈 실수 유형이다. 3시간짜리 대화가 실린 세션에서 "5분마다 CI 상태 확인해 줘"라고 /loop를 걸면, 5분마다 3시간짜리 대화가 재전송된다. 확인 자체는 100토큰짜리 일인데, 그 일을 하기 위해 매번 수십만 토큰의 배낭을 지고 나가는 셈이다. 이 블로그의 제번스의 역설과 추론 경제학에서 다룬 "에이전트 한 작업이 챗의 1,000배 토큰을 먹는" 현상의 상당 부분은 이런 구조적 낭비에서 온다.

---

제5장: 2026년, '세션 경제학'이 개발자 역량이 된 이유

5-1. 우선순위 — 네 가지 레버

가이드는 친절하게도 비용 기여도 순서를 알려 준다. 이 순서가 곧 "어디부터 손댈 것인가"의 답이다.

※ 막대 길이는 가이드가 제시한 순서를 시각화한 것이며 정량 비율이 아니다.

이 넷을 하나의 문장으로 묶으면 이렇다. "어떤 두뇌를(모델), 얼마나 오래(세션), 얼마나 깊이(effort), 얼마나 시끄럽게(출력) 쓸 것인가." 네 레버 모두 코드와 무관하다. 전부 운용 습관이다.

5-2. 가이드가 덧붙인 실전 장치들

가이드 후반부에는 2026년 Claude Code에 들어온 장치들이 짧게 언급된다. 각각이 위의 원리와 어떻게 맞물리는지 보자.

/autocompact 200k는 특히 상징적이다. 100만 토큰 모델이 있는데도 일부러 20만에서 압축하라는 옵션이다. 2024년의 업계라면 이해 못 했을 설정이다. 창이 커서 좋은 게 아니라, 창을 어디까지 쓸지 정하는 게 엔지니어링이라는 인식 변화가 이 한 줄에 담겨 있다.

5-3. 하루를 다시 써 보면

1장의 그 개발자로 돌아가 보자. 가이드를 읽은 그는 다음 주 금요일을 이렇게 보낸다.

코드는 한 줄도 다르게 쓰지 않았다. 바뀐 건 세션을 다루는 손놀림뿐이다.

5-4. 왜 이것이 '역량'인가

2026년의 소프트웨어 개발은 점점 더 "에이전트에게 일을 시키는 기술"이 되고 있다. 그 기술에는 프롬프트를 잘 쓰는 능력, 작업을 잘 쪼개는 능력, 결과를 검증하는 능력이 포함된다. 이 가이드가 보여 주는 것은 거기에 한 항목이 더 추가됐다는 사실이다. 바로 컨텍스트와 캐시의 물리학을 이해하고 세션을 운용하는 능력.

이것은 1970년대 프로그래머가 메모리를 바이트 단위로 아꼈던 것, 2000년대 웹 개발자가 HTTP 캐시 헤더와 CDN을 익혔던 것과 같은 종류의 역량이다. 자원이 희소하고 가격이 붙어 있을 때, 그 자원의 작동 원리를 아는 사람과 모르는 사람의 생산성은 몇 배씩 벌어진다. 토큰은 2026년의 그 희소 자원이고, 컨텍스트 창은 그 메모리이며, 프롬프트 캐시는 그 CDN이다.

가이드의 TL;DR을 원리와 함께 다시 읽으면 이렇게 된다.

---

마치며: 창이 커질수록, 창을 다루는 손이 중요해진다

이 가이드의 마지막 문장은 담담하다. 네 가지 — 모델, 세션 길이, 사고 수준, 출력 크기 — 를 순서대로 챙기라는 것. 하지만 그 뒤에는 2017년의 트랜스포머, 2023년의 PagedAttention과 Lost in the Middle, 2024년의 프롬프트 캐싱, 2025년의 Context Rot와 컨텍스트 엔지니어링이 차례로 놓여 있다. 가이드는 그 9년의 결론을 터미널 명령 여섯 개로 압축한 문서다.

컨텍스트 창은 앞으로도 커질 것이다. 캐시 수명도 길어지고, 가격도 내릴 것이다. 하지만 "매 턴 전체를 다시 본다"는 트랜스포머의 본성과 "많이 볼수록 하나에 덜 집중한다"는 주의력의 본성은 당분간 그대로일 것이다. 그렇다면 창을 얼마나 크게 받느냐보다, 창을 언제 비우고, 무엇을 넣지 않고, 언제 옆방에 맡길지 아는 손이 더 오래 가치를 가진다.

다음 세션을 열기 전에 딱 하나만 해 보자. /context. 거기서부터 시작이다.

---

참고 자료

• Lydia Hallie, Maximizing the value of your Claude Code sessions, Anthropic, 2026.8.14
• Vaswani et al., "Attention Is All You Need", NeurIPS 2017
• Kwon et al., "Efficient Memory Management for Large Language Model Serving with PagedAttention", SOSP 2023 (vLLM)
• Anthropic, "Prompt caching with Claude", 2024.8
• Liu et al., "Lost in the Middle: How Language Models Use Long Contexts", TACL 2024
• Chroma Research, "Context Rot: How Increasing Input Tokens Impacts LLM Performance", 2025.7
• Anthropic, "How we built our multi-agent research system", 2025.6
• Anthropic, "Effective context engineering for AI agents", 2025.9
• 코어닷투데이, 컨텍스트 엔지니어링 완전 정복 · 긴 맥락이 독이 된다: Context Rot · 제번스의 역설과 추론 경제학