Claude Code 컨텍스트 비용: 세션이 길어질수록 요금이 커지는 구조

Claude Code 공식 문서의 비용 안내에는 이런 문장이 있습니다. 하루 종일 열어 둔 세션에서는 한 줄짜리 질문 하나도 대화 전체만큼의 사용량을 쓴다는 내용입니다. 질문은 열 글자인데 사용량은 열 글자가 아니라는 얘기입니다.

세션을 여러 개 열고 에이전트까지 붙여 쓰기 시작하면 이 차이가 곱해집니다. 그래서 비용이 어디서 생기는지부터 정리하고, 세션을 나누고 초기화하는 기준을 제 판단으로 적어 보겠습니다.

요청마다 대화 전체가 함께 나가는 구조

비용은 내가 입력한 글자 수와 Claude가 답한 글자 수에 비례한다고 생각하기 쉽습니다. 그러면 짧은 질문은 싸야 하고, 사용량이 튀는 날은 긴 질문을 많이 한 날이어야 합니다.

실제로는 Claude Code 비용 문서가 설명하는 구조가 다릅니다. Claude Code는 요청을 보낼 때마다 지금까지의 대화 전체를 함께 보냅니다. 도구를 한 번 쓰면 그 결과를 담아 요청이 한 번 더 나갑니다. 파일을 열고, 명령을 돌리고, 결과를 읽는 한 번의 작업이 요청 여러 건입니다.

캐시 읽기 단가와 컨텍스트 길이의 곱

다행히 매번 전체를 정가로 처리하지는 않습니다. 프롬프트 캐싱 덕분에 이미 처리한 앞부분은 읽기 단가로 다시 읽습니다. 공식 가격표 기준으로 백만 토큰당 가격은 이렇습니다.

모델	일반 입력	캐시 읽기	캐시 쓰기(5분)	캐시 쓰기(1시간)
Claude Opus 5.5	$4	$0.20	$5	$8
Claude Sonnet 5.5	$2	$0.10	$2.50	$4

읽기 단가는 일반 입력의 5%입니다(이 두 모델 기준. 다른 모델은 10%). 싸졌지만 0은 아닙니다. 컨텍스트가 20만 토큰이면 요청 한 번에 Opus 5.5 기준 $0.04, 도구를 백 번 쓰면 $4가 읽기만으로 나갑니다. 5만 토큰짜리 세션이라면 같은 백 번이 $1입니다. 단가는 같고 컨텍스트 길이만 달랐습니다.

합계가 길이의 제곱에 가깝게 자라는 이유

더 중요한 쪽은 합계입니다. 요청이 나갈 때마다 컨텍스트가 조금씩 커진다면, 읽는 양은 그 누적입니다. 제가 쓴 가정은 하나입니다. 요청 한 번에 컨텍스트가 2천 토큰씩 늘어난다고 두고(실제 값이 아니라 계산을 위한 임의의 수입니다), 캐시 읽기만 세었습니다.

경우	읽는 토큰 합계	Opus 5.5	Sonnet 5.5
50번 요청한 세션 하나	255만	$0.51	$0.26
100번 요청한 세션 하나	1,010만	$2.02	$1.01
50번씩 두 세션	510만	$1.02	$0.51

표는 공식 가격표에 위 가정을 대입해 계산한 값이고, 측정한 값이 아닙니다. 새로 늘어나는 토큰의 캐시 쓰기 비용과 출력 비용은 뺐습니다. 그래도 방향은 분명합니다. 같은 일을 백 번의 요청으로 하더라도 한 세션에서 이어 하면 오십 번씩 둘로 나눌 때의 두 배를 읽습니다. 길이가 두 배가 되면 읽는 양은 네 배에 가깝게 늡니다.

캐시가 끊긴 뒤 첫 메시지의 가격

읽기 단가는 캐시가 살아 있을 때의 이야기입니다. API 기준 캐시 수명은 기본 5분이고, 1시간짜리도 있습니다. 자리를 비웠다가 돌아와 보낸 첫 메시지는 캐시를 놓치고 컨텍스트 전체를 다시 처리합니다. Claude Code 비용 문서도 휴식이 캐시 수명보다 길면 첫 메시지가 전체 컨텍스트를 다시 처리한다고 적고 있습니다.

다시 쓰는 값은 읽기보다 훨씬 비쌉니다. 20만 토큰을 5분 수명으로 다시 쓰면 Opus 5.5 기준 $1.00, 1시간 수명이면 $1.60입니다. 같은 컨텍스트를 읽을 때의 $0.04와 비교하면 25배에서 40배입니다. 점심을 먹고 돌아와서 한 줄을 물었는데 사용량이 크게 움직였다면 이 경우일 가능성이 높습니다.

세션을 나누는 기준, 일의 단위

여기서부터는 문서의 사실이 아니라 제 판단입니다. 저라면 세션 하나에 일 하나를 담습니다. 일이 끝나서 이전 대화가 더는 필요 없어지면 그 세션을 이어 쓰지 않고 비웁니다. 문서도 같은 권고를 합니다. 관련 없는 일로 넘어갈 때는 /clear로 새로 시작하라는 것입니다. 낡은 컨텍스트는 이후의 모든 메시지에서 값을 치르게 합니다. /clear는 비용이 들지 않습니다.

/compact는 다릅니다. 요약하려면 요약할 대화를 읽어야 하므로, 큰 컨텍스트를 줄이는 일이 그 자체로 큰 요청입니다. 컨텍스트가 작을 때 하는 것이 쌉니다. 이어 가야 하는 일이면 압축하고, 이어 가지 않아도 되는 일이면 비웁니다.

비울 때 잃는 것은 인수인계 메모로 막습니다. 비우기 직전에 다음 세션이 알아야 할 것만 파일 하나에 적어 두는 방식입니다. 저라면 이 네 가지를 씁니다. 지금까지 정한 것과 그 이유, 아직 남은 일, 건드리면 안 되는 것, 확인한 사실과 추정을 구분한 목록입니다. 대화 전체를 요약하는 것보다 짧고, 새 세션은 이 파일 하나만 읽고 시작합니다.

서브에이전트와 팀이 여는 또 하나의 컨텍스트

서브에이전트는 비용을 줄이는 도구이면서 늘리는 도구입니다. 문서가 권하는 쓰임은 로그 처리나 문서 조회처럼 출력이 긴 일을 맡기는 것입니다. 긴 출력이 서브에이전트의 컨텍스트에 남고, 메인 대화에는 요약만 돌아옵니다. 대신 서브에이전트의 요청도 사용량에서 나갑니다. 요청 수를 줄이는 장치가 아니라 메인 컨텍스트를 작게 지키는 장치입니다.

팀으로 묶으면 더 눈에 띕니다. 문서에 따르면 에이전트 팀은 팀원이 계획 모드로 돌 때 일반 세션보다 약 7배의 토큰을 씁니다. 팀원마다 자기 컨텍스트 창을 갖는 별도 인스턴스이기 때문입니다. 단순한 서브에이전트 작업에는 모델을 haiku로 지정하라는 안내도 있습니다.

같은 일에 붙는 두 가지 단가, 모델과 effort

앞의 표에서 보이듯 Opus 5.5의 입력 단가는 Sonnet 5.5의 두 배입니다. 출력도 $20 대 $10으로 같은 비율입니다. 문서는 대부분의 코딩 작업을 Sonnet이 잘 해내고, Opus는 복잡한 설계나 여러 단계의 추론에 아끼라고 권합니다. 서브에이전트는 세션의 모델을 이어받으므로 Opus로 바꾸면 서브에이전트도 같이 바뀝니다.

effort는 생각에 쓰는 토큰의 양을 조절합니다. 생각 토큰은 출력 토큰으로 청구됩니다. 단순한 작업이면 effort를 낮춰 비용을 줄일 수 있습니다. 다만 Opus 5.5, Sonnet 5.5, Haiku 5.5 등에서는 생각을 끌 수 없고, 낮추는 것까지만 가능합니다.

여기까지가 확실한 부분

단가표와 합계 계산은 API 정가를 기준으로 했습니다. 구독 요금제의 사용량 한도는 이 계산과 같은 방식으로 깎이는지 제가 확인하지 못했습니다. 구독을 쓰신다면 문서가 말하는 /usage의 항목별 비율을 보는 편이 정확합니다. 요청 한 번에 컨텍스트가 얼마나 느는지는 일마다 다르고, 위의 2천 토큰은 계산을 위한 가정입니다. 캐시 수명도 설정과 버전에 따라 달라질 수 있어, 자신의 세션이 어느 쪽인지는 상태 표시로 직접 확인하셔야 합니다.

참고: Claude Code 비용 관리, 프롬프트 캐싱과 가격표