지난주 Claude Code 사용량을 집계했더니, 일주일 동안 1.36B 토큰이라는 숫자가 나왔다.

13억 토큰.

"역시 너무 많이 쓴 거 아닌가?"라고 생각하며 내역을 조사해 보니, 예상과는 상당히 다른 구조를 가지고 있었다.

내역을 보니 97%가 캐시였다

Claude Code의 세션 로그로부터 주 단위 토큰 사용량을 집계한 결과가 이것이다.

1.36B 중 1.33B, 즉 97.4%가 cache_read였다.

반면, 새롭게 캐시에 투입된 cache_create는 30.2M, Claude가 생성한 output은 5.9M였다.

단순히 합계하면, 새롭게 생성·투입된 토큰량은 약 36M가 된다.

총 토큰 수만 보면 1.36B이지만, 그 대부분은 과거에 처리한 문맥(Context)의 재사용이었다.

cache_read란 무엇인가

Claude의 API에는 Prompt Caching이라는 메커니즘이 있다.

Claude Code에서는 코딩 중에 대량의 문맥을 반복해서 참조한다.

예를 들어,

• CLAUDE.md 등의 프로젝트 지시 사항
• 읽어들인 소스 코드
• 도구(Tool) 정보
• 그때까지의 대화 이력
• 세션 내에서 축적된 컨텍스트 (Context)

등이다.

매번 모든 것을 일반적인 input으로 처리하는 것이 아니라, 재사용할 수 있는 부분을 캐싱하고 그 이후의 요청에서는 캐시에서 읽어온다.

로그상에서는 이것이 cache_read로 나타난다.

Prompt Caching에서는 일반적인 input보다 cache_read의 단가가 낮기 때문에, 동일한 긴 문맥을 몇 번이고 참조하는 워크로드에서는 큰 효과가 있다.

Claude Code와 궁합이 상당히 좋은 메커니즘이다.

1주일에 13,972턴

또 하나 흥미로운 숫자가 있다.

같은 기간의 턴(Turn) 수는,

13,972턴

이었다.

7일로 나누면 하루에 약 2,000턴.

물론 이것이 인간이 2,000번 채팅을 입력했다는 의미는 아니다.

Claude Code에서는,

• 파일을 읽는다
• 명령을 실행한다
• 결과를 확인한다
• 코드를 작성한다
• 테스트를 한다
• 다음 판단을 한다

와 같은 일련의 에이전트 동작에서도 모델 호출이 발생한다.

그렇기 때문에 인간이 보기에는 "한 번 부탁했을 뿐"이라도, 뒷단에서는 여러 턴이 진행된다.

13,972턴이라는 숫자는 Claude Code를 채팅이라기보다, 상시 작동하는 개발 에이전트로서 사용하고 있음을 잘 보여준다.

1턴당 약 97,000토큰

총 토큰 수 1,362.7M를 13,972턴으로 나누면,

1턴당 약 97,500토큰

이 된다.

상당히 크다.

다만, 그 97,000토큰을 매번 처음부터 처리하는 것은 아니다.

97.4%는 cache_read이므로, 실제로는 거대한 문맥을 몇 번이고 캐시에서 참조하면서 소량의 새로운 정보를 추가하여 처리하고 있는 것이다.

이 구조를 보면 Claude Code의 동작 방식을 상당히 쉽게 이해할 수 있다.

입출력 비는 약 230:1

더욱 흥미로운 점은 Claude가 "읽는 양"과 "쓰는 양"의 차이다.

input 계열을 합치면 input + cache_create + cache_read로 약 1,356M.

그에 반해 output은 5.9M이다.

즉,

입력 : 출력 ≒ 230 : 1

이 된다.

Claude는 자신이 출력하는 양의 약 230배에 달하는 정보를 읽고 있다.

실제 사용감과도 상당히 일치한다.

Claude Code는 대량의 코드나 대화 이력을 읽어 들여,

"이 3줄을 수정한다", "이 함수를 추가한다", "이 테스트를 실행한다"

와 같이 비교적 작은 출력을 반환한다.

인간에 비유하자면, 방대한 자료를 읽고 단 몇 줄의 판단을 적는 업무에 가깝다.

생성량만 보고 있으면 이러한 구조는 보이지 않는다.

cache_read가 많은 것은 좋은 일인가

적어도 비용 효율성 측면에서는 좋은 상태다.

동일한 컨텍스트를 일반적인 input으로 몇 번이고 처리하는 것보다, 캐시에서 재사용하는 편이 저렴하다.

이번 로그에서는 97% 이상이 cache_read였으므로, 상당히 높은 비율로 기존 컨텍스트를 재사용하고 있다.

반대로, 세션이 긴데도 cache_read가 적고, 보통 input이나 cache_create가 대량으로 증가하고 있다면,

• 캐시가 제대로 작동하지 않고 있음
• 컨텍스트 (Context)가 빈번하게 변화하고 있음
• 세션을 잘게 나누어 다시 만들고 있음

과 같은 가능성을 의심해 봐도 좋다.

하지만 여기서 한 가지 주의할 점이 있다.

캐시 효율이 높은 것과, 장시간 세션에서 답변 품질이 떨어지지 않는 것은 별개의 문제다.

긴 문맥을 저렴하게 다시 읽을 수 있다고 하더라도, 문맥 자체가 거대해지면 중요한 정보를 오해하거나 이전에 정한 규칙에서 점차 벗어날 수도 있다.

비용 측면의 효율과 추론 품질 측면의 효율은 별개로 생각하는 것이 좋다.

Max plan이므로 직접적인 종량제는 아니다

이번 Claude Code는 Max plan으로 이용하고 있기 때문에, API처럼 토큰 수가 그대로 청구 금액이 되는 것은 아니다.

하지만 이 로그를 보면 Claude Code 내부에서 모델을 어떻게 사용하고 있는지는 상당히 잘 보인다.

중요한 것은,

1.36B 토큰 전부가 새롭게 처리된 1.36B 토큰은 아니다

라는 점이다.

약 97%는 기존 컨텍스트의 캐시 읽기(cache_read)였다.

따라서 '총 토큰 수'만 보고 부하나 이용량을 판단하면 실태를 상당히 오해하게 된다.

API 이용의 경우도 보통 input, cache_write/cache_create, cache_read, output은 요금 체계가 다르기 때문에, 합계 토큰 수만으로는 비용을 판단할 수 없다.

요약

이번 1주일간의 Claude Code 이용 로그는,

• 총 토큰 수: 1.36B
• cache_read: 1.33B (97.4%)
• cache_create: 30.2M
• output: 5.9M
• 턴(Turn) 수: 13,972
• 1턴 평균: 약 97,500 토큰
• 입력 : 출력: 약 230 : 1

이라는 결과였다.

처음에 1.36B라는 숫자를 보았을 때는 엄청난 양을 소비하고 있는 것처럼 보였다.

하지만 내역을 보면 그 대부분은 동일한 거대한 컨텍스트를 재사용하는 cache_read였다.

Claude Code의 이용량을 볼 때는 '몇 토큰을 사용했는가'뿐만 아니라 '그 토큰이 무엇이었는가'까지 확인해야 한다. 여기까지 보고 나면 Claude Code라는 도구가 어떻게 작동하고 있는지도 상당히 명확히 보인다.

그리고 개인적으로는 1.36B 토큰보다,

1주일 동안 13,972턴을 돌렸다

라는 사실이 조금 무섭다.

Discussion