🧠 레슨

컨텍스트 재활용 — 단일 세션은 왜 싸질까

프롬프트 캐싱·prefix·cache read/write로 Claude Code 비용과 세션 운영 감각을 잡는다.

① 오늘의 질문

왜 긴 단일 세션이 생각보다 싸게 느껴질까?

Claude Code를 오래 쓰다 보면 이상한 감각이 생깁니다. 한 세션에서 파일을 많이 읽고 대화를 계속 이어가는데, 매번 모든 내용을 처음부터 다시 계산하는 것처럼 비싸지는 않아 보입니다.

오늘 보는 자료는 roboco-io의 context reuse mechanism 메모입니다. 핵심은 프롬프트 캐싱(prompt caching)이에요.

한 줄 요약

모델이 이전 컨텍스트를 매번 새로 읽는 게 아니라, 앞에서부터 똑같은 prefix를 서버 쪽 캐시에서 훨씬 싸게 다시 읽는 구조입니다.

📚 「컨텍스트 재활용 — 단일 세션은 왜 싸질까」 레슨 내용 전체 텍스트로 훑어보기

왜 긴 단일 세션이 생각보다 싸게 느껴질까?

오늘 보는 자료는 roboco-io의 context reuse mechanism 메모입니다. 핵심은 프롬프트 캐싱(prompt caching)이에요.

한 줄 요약

모델이 이전 컨텍스트를 매번 새로 읽는 게 아니라, 앞에서부터 똑같은 prefix를 서버 쪽 캐시에서 훨씬 싸게 다시 읽는 구조입니다.

프롬프트 캐싱에서 캐시 히트가 나는 기준으로 가장 가까운 설명은 무엇일까요?

맞아요. 핵심은 prefix입니다. 앞부분이 똑같이 이어지면 그 부분의 해시가 맞고, 모델은 그 구간을 다시 정가로 처리하지 않고 캐시에서 읽어옵니다. 세션 ID 자체보다 '앞부분이 얼마나 안정적으로 같은가'가 중요합니다.

비용 감각은 이 비교로 잡으면 됩니다.

정가 입력: 새로운 파일, 새 메시지, 바뀐 시스템/도구 정의처럼 캐시에 없는 입력은 일반 input 가격으로 처리된다. 캐시에 새로 쓰는 비용은 기본 입력보다 더 비쌀 수도 있다.

캐시 읽기: 이미 같은 prefix가 캐시에 있으면 cache_read로 계산된다. Anthropic 문서 기준 기본 input의 약 0.1배라서, 같은 긴 앞부분을 반복해서 읽는 비용이 크게 줄어든다.

Claude Code의 대화는 보통 append-only로 쌓입니다. 앞 대화가 사라지는 게 아니라, 뒤에 새 요청과 응답이 붙는 식이에요.

매 턴의 모양

시스템 프롬프트 + 도구 정의 + CLAUDE.md + 이전 대화 전체 + 이번 사용자 요청

앞부분은 직전 턴과 거의 같습니다. 그래서 매 턴마다 이전까지의 긴 히스토리가 안정된 prefix가 되고, 새로 붙은 이번 요청만 정가에 가깝게 처리됩니다.

이게 한 세션에서 계속 작업할 때 “이전 맥락을 재활용한다”는 말의 기술적 배경입니다.

긴 세션에서 이전 히스토리 100,000토큰이 캐시 히트되고, 이번 새 요청이 2,000토큰이라고 해봅시다. 비용 감각으로 가장 가까운 것은?

맞아요. cache read는 공짜가 아니라 싸게 읽는 것입니다. 그래서 긴 단일 세션이 유리하지만, 무한히 길어지면 cache_read도 누적되어 다시 비싸질 수 있습니다.

여러 세션으로 작업을 쪼개면 공통 시스템 프롬프트나 도구 정의 일부는 재사용될 수 있습니다. 하지만 진짜 비싼 부분은 보통 각 세션이 새로 읽은 파일과 새로 쌓은 히스토리입니다.

새 세션의 세금

파일을 다시 읽고, 요구사항을 다시 설명하고, 이전 결정을 다시 주입하면 그 세션만의 고유 prefix가 새로 생깁니다. 이 부분은 캐시에 새로 써야 하므로 비용이 커집니다.

그래서 작은 독립 작업은 세션 분할이 괜찮지만, 같은 코드베이스와 같은 목표를 계속 다루는 작업은 단일 세션의 재활용 이점이 큽니다.

아래 중 캐시 효율을 떨어뜨릴 가능성이 가장 큰 행동은 무엇일까요?

맞아요. 캐시는 계층적으로 깨집니다. tools → system → messages 같은 앞쪽 구조가 바뀌면 그 아래 prefix가 달라져 캐시 히트가 줄어듭니다. 타임스탬프처럼 매번 달라지는 값을 앞쪽에 넣는 것도 나쁩니다.

실무 판단은 단순히 하나가 항상 좋다는 식이 아닙니다.

긴 단일 세션이 좋은 경우: 같은 목표, 같은 파일, 같은 의사결정을 계속 참조한다. 이전 히스토리가 안정된 prefix가 되어 cache_read로 재활용된다. 탐색→수정→검증이 이어지는 코딩 작업에 유리하다.

나누는 게 좋은 경우: 서로 독립적인 주제이거나, 이전 히스토리가 너무 길어져 불필요한 cache_read가 커진다. 이때는 요약·compact·새 세션으로 갈아타는 편이 낫다.

오늘 배운 내용을 한 줄로 정리해봅시다.

정답입니다. 핵심은 안정된 prefix입니다. 같은 앞부분을 유지할수록 캐시 재사용이 잘 되고, 앞쪽 구조를 자주 흔들수록 캐시가 깨집니다.

즉, 컨텍스트 재활용은 “AI가 알아서 기억한다”가 아니라 같은 앞부분을 유지해 캐시 히트를 만들고, 너무 길어지면 압축하는 운영 기술입니다.