1M 컨텍스트 윈도우(Context Window) vs 프롬프트 캐싱(Prompt Caching): 언제 무엇을 사용해야 하는가

• 1M 컨텍스트는 매 쿼리마다 전체 비용이 발생하지만, 캐싱(Caching)은 반복되는 토큰 비용을 1/10로 줄여줍니다.

• 일회성 심층 분석(One-shot deep dives)에는 1M을 사용하고, 고정된 문서에 대한 반복 호출에는 캐싱을 사용하세요.

• 하이브리드 방식: 안정적인 80%는 캐싱하고, 동적인 20%는 새로 스트리밍(Stream)하세요.

• 제 파이프라인의 실제 수치에 따르면, 캐싱은 3번의 호출 이후부터 이점이 발생합니다.

저는 동일한 워크로드를 두 가지 다른 방식으로 실행하며 2주를 보냈습니다. 하나는 매 호출마다 전체 1M 토큰 컨텍스트 윈도우(Context Window)를 사용하는 방식이었고, 다른 하나는 고정된 시스템 프롬프트(System Prompt)를 캐싱하고 새로운 부분에 대해서만 전체 비용을 지불하는 방식이었습니다. 동일한 문서에 대해 3번 이상의 호출을 수행하자, 캐싱된 버전의 비용이 대략 10분의 1 수준으로 낮아졌습니다. 여러분에게 실제로 무엇이 필요한지 결정하는 방법은 다음과 같습니다.

1M 컨텍스트 윈도우가 실제로 비용을 청구하는 방식

1M 컨텍스트 윈도우는 정액제 방식과 같습니다. 최대 100만 개의 텍스트, 코드 또는 문서 토큰을 단일 요청에 로드하면, Claude는 답변하기 전에 그 모든 내용을 읽습니다. 매력은 분명합니다. 전체 코드베이스, 긴 PDF, 또는 1년 치의 채팅 로그를 하나의 프롬프트(Prompt)에 넣고 질문 하나만 던지면 됩니다. 청킹(Chunking), 벡터 검색(Vector Search), 유지 관리해야 할 검색 파이프라인(Retrieval Pipeline)이 필요 없습니다.

함정은 매 요청마다 모든 토큰에 대해 비용을 지불해야 한다는 점입니다. 만약 컨텍스트(Context)가 400,000 토큰이고 질문을 10번 던진다면, 총 4,000,000개의 입력 토큰에 대한 비용을 지불하게 됩니다. 모델은 이전 요청을 기억하지 못합니다. 각 호출은 전체 내용을 새로 읽는 과정입니다.

저는 280,000 토큰의 문서 세트로 이를 테스트했습니다. 질문 하나에 특정 비용이 발생했습니다. 질문 10개에는 그 10배의 비용이 들었습니다. 반복 작업(Iterating)을 할 때 숫자는 빠르게 불어나며, 반복 작업이야말로 실제 업무의 모습입니다. 완벽한 질문 하나를 던지는 경우는 드뭅니다. 질문하고, 읽고, 다듬고, 다시 질문하게 됩니다.

따라서 1M 컨텍스트 윈도우(1M window)는 편의를 위한 비용(convenience tax)입니다. 인프라를 구축하지 않는 대신 돈을 지불하는 것이죠. 일회성 작업이라면 아주 훌륭한 거래입니다. 예전에 저는 190,000 토큰에 달하는 법률 스타일의 계약서 꾸러미를 검토해야 했던 적이 있습니다. 저는 질문 네 개를 던졌고, 답변을 받은 뒤 탭을 닫았습니다. 이를 위해 검색 시스템(retrieval system)을 구축하는 것은 작업 자체보다 더 오래 걸렸을 것입니다. 호출당 발생하는 고정 비용(flat per-call cost)은 그만한 가치가 있었습니다.

이 방식이 가치를 잃는 지점은 바로 반복이 일어날 때입니다. 동일한 모델에게 동일한 배경 문서 세트를 반복해서 계속 질문하고 있다는 사실을 깨닫는 순간, 당신은 변하지 않는 토큰들에 대해 전체 비용을 온전히 지불하고 있는 것입니다. 이것이 바로 프롬프트 캐싱(Prompt Caching)이 해결하기 위해 설계된 정확한 상황입니다. 대규모 문서를 한 번에 로드하는 것에 대한 더 깊은 맥락을 알고 싶다면, 1M Context Window Workflows를 참조하세요.

멘탈 모델(Mental model): 1M 컨텍스트는 택시와 같습니다. 단 한 번의 이동에는 훌륭하지만, 매일 같은 사무실로 타고 간다면 끔찍한 선택입니다.

프롬프트 캐싱이 계산 방식을 바꾸는 방법

프롬프트 캐싱을 사용하면 프롬프트의 일부를 재사용 가능한 상태로 표시할 수 있습니다. Claude가 이를 처음 읽을 때는 약간의 쓰기 프리미엄(write premium)을 지불합니다. 그 이후의 모든 호출에서는 해당 캐시된 토큰에 대해 일반 입력 가격의 약 10분의 1 정도만 지불하면 됩니다. 캐시는 짧은 시간 동안 유지되며, 캐시를 따뜻하게 유지(keep it warm)한다면 한 시간 동안 유지되는 더 긴 캐시 옵션도 있습니다.

여기서 중요한 구조가 있습니다. 일반적인 요청은 두 부분으로 나뉩니다. 안정적인 부분(시스템 프롬프트, 참조 문서, 지침, 예시 등)과 동적인 부분(실제 사용자 질문 또는 이번 호출을 위한 새로운 데이터)이 그것입니다. 보통 안정적인 부분이 훨씬 큽니다. 제 파이프라인(pipelines)의 경우, 고정된 컨텍스트가 전체 토큰 수의 85~90%를 차지하는 경우가 많습니다.

따라서 안정적인 85%를 캐싱합니다. 첫 번째 호출이 이를 기록합니다. 그 이후의 모든 호출은 10분의 1 가격으로 이를 읽어옵니다. 크기가 작은 동적인 질문은 전체 요율로 청구되지만, 워낙 미미하기 때문에 큰 상관이 없습니다.

수치로 설명해 보겠습니다. 고정된 컨텍스트 (Context)가 200,000 토큰이고 질문이 2,000 토큰이라고 가정해 봅시다. 1M 컨텍스트 윈도우 (Window)를 사용하면, 매 호출마다 202,000 토큰 전체에 대해 전체 요율로 비용이 청구됩니다. 캐싱 (Caching)을 사용하면, 첫 번째 호출에서는 200,000 토큰에 대한 쓰기 프리미엄 (Write premium)과 2,000 토큰에 대한 전체 요율을 지불합니다. 그 이후의 모든 호출은 200,000 토큰에 대해 10분의 1 가격을 지불하고, 2,000 토큰에 대해서는 전체 요율을 지불합니다. 세 번째 호출부터는 이미 캐싱 방식이 앞서기 시작합니다. 열 번째 호출에 이르면 격차는 압도적입니다.

제 테스트 결과, 손익분기점 (Break-even point)은 약 3회 호출 지점에서 형성되었습니다. 3회 미만의 호출에서는 캐시 쓰기 프리미엄 때문에 절약되는 금액이 거의 없으므로, 1M의 단일 읽기 방식이 더 간단합니다. 3회를 초과하면 캐싱이 승리하며 계속해서 격차를 벌립니다. 재사용을 더 많이 할수록 그 차이는 더 커집니다.

타이밍 세부 사항과 1시간 캐시 윈도우 (Cache window)에 대해서는 Claude Code 1-Hour Caching Update에서 더 자세히 다루었습니다. 기본 캐시는 몇 분 안에 만료되기 때문에 1시간 옵션이 중요합니다. 만약 호출이 업무 세션 전반에 걸쳐 분산되어 있다면, 더 긴 윈도우를 통해 호출 사이의 캐시를 유지함으로써 쓰기 프리미엄을 두 번 지불하지 않을 수 있습니다.

캐싱은 월간 교통 패스와 같습니다. 한 번만 지불하면 하루 종일 저렴하게 이용할 수 있습니다.

실제 파이프라인에서 실행 중인 하이브리드 패턴

실제로 저는 하나만 선택하지 않습니다. 저는 하이브리드 (Hybrid) 방식을 사용합니다. 핵심은 프롬프트 (Prompt)를 절대 변하지 않는 부분과 항상 변하는 부분으로 깔끔하게 나누고, 각각을 올바르게 처리하는 것입니다.

제 콘텐츠 파이프라인이 좋은 예시입니다. 저는 Shopify 스토어에 있는 제품들을 위한 설명, 소셜 게시물, 메타데이터 (Metadata)를 생성합니다. 안정적인 부분은 매우 방대하고 고정되어 있습니다. 브랜드 보이스 가이드라인 (Brand voice guidelines), 포맷팅 규칙 (Formatting rules), 모델이 따라하기를 원하는 긴 예시 출력 목록, 그리고 절대 사용할 수 없는 단어에 대한 규칙 등이 포함됩니다. 이 블록은 약 40,000 토큰 정도이며, 모든 제품에 대해 동일합니다.

그래서 저는 그것을 한 번 캐싱(Caching)합니다. 그 후 각 제품에 대해 작은 동적 청크(Dynamic chunk), 즉 제품명, 주요 특징, 원하는 관점을 보냅니다. 이는 약 800 토큰 정도입니다. 저는 한 세션에서 60개의 제품을 처리합니다. 캐싱을 사용하면 40,000 토큰에 대한 쓰기 프리미엄(Write premium)을 한 번만 지불하고, 그 후 10분의 1 가격으로 60번의 읽기(Read)와 60개의 작은 동적 질문을 처리합니다.

만약 1M 컨텍스트 윈도우(Context Window)를 그대로 사용했다면, 40,000 토큰에 800 토큰을 더한 금액을 60번 동안 전체 가격으로 지불했을 것입니다. 이는 240만 개의 입력 토큰에 해당하며, 캐싱 경로를 사용했을 때 비용의 아주 일부분만 지불하는 것과 대조적입니다. 단 한 번의 배치(Batch) 실행에서 얻은 절감 효과는 극적이었으며, 저는 이 배치를 매주 실행합니다.

순서 규칙은 엄격합니다. 캐싱된 콘텐츠는 프롬프트(Prompt)의 맨 앞에 와야 하며, 호출 간에 바이트 단위로(Byte-for-byte) 완전히 동일하게 유지되어야 합니다. 캐싱된 블록에서 단 한 글자라도 변경하면 캐시 미스(Cache miss)가 발생하여 쓰기 프리미엄을 다시 지불해야 합니다. 그래서 저는 시스템 프롬프트(System prompt)를 별도의 파일로 유지하며 배치 도중에 절대 수정하지 않습니다. 동적 콘텐츠는 항상 마지막에 위치합니다.

하이브리드 방식이 무너지는 지점은 '안정적인(Stable)' 부분이 실제로 안정적이지 않을 때입니다. 지침(Instructions)을 끊임없이 수정하고 있다면, 계속해서 캐시를 깨뜨리게 되고 쓰기 프리미엄을 반복해서 지불하게 됩니다. 그런 경우에는 솔직히 단순하게 1M 윈도우를 전체 가격으로 읽는 것이 번거로움이 덜합니다. 저는 매 실행 사이에 브랜드 규칙을 계속 수정했던 한 주 동안 이 사실을 뼈아프게 배웠습니다. 캐시는 전혀 예열(Warm up)되지 않았고, 저는 프리미엄을 아마 30번 정도 지불했습니다.

또 다른 패턴은 다음과 같습니다: 문서는 캐싱하고, 대화는 스트리밍(Streaming)하십시오. 고정된 보고서를 대상으로 하는 긴 연구 세션의 경우, 보고서를 캐싱하고 그 위에 저렴한 비용으로 주고받는 질문들을 얹으십시오. 이 단일 설정이 저에게 가장 큰 비용 절감을 가져다주었습니다.

5초 안에 적용할 수 있는 의사결정 체크리스트

너무 깊게 생각하는 것에 지쳐서 이 리스트를 간단하게 만들었습니다. 제가 매 작업 전에 머릿속으로 돌리는 실제 흐름은 다음과 같습니다.

첫 번째 질문: 동일한 배경 자료(background material)를 바탕으로 모델을 3회 이상 호출할 예정인가? 만약 아니라면, 그냥 1M 컨텍스트 윈도우(Context Window)를 사용하세요. 약간의 비용 절감보다 편의성이 더 크며, 별도의 엔지니어링 과정을 생략할 수 있습니다. 일회성 계약서 검토, 단일 긴 문서 요약, 일회성 코드베이스 질문 등이 이에 해당합니다. 그냥 로드하고 질문하면 됩니다.

두 번째 질문: 만약 3회 이상 호출한다면, 배경 자료가 정말로 고정되어 있는가? 세션 동안 자료를 수정하지 않을 계획이라면 캐싱(Caching)을 사용하세요. 브랜드 가이드라인, 참조 문서, 안정적인 코드베이스 스냅샷, 고정된 데이터셋 등이 있습니다. 이들은 호출 사이에 절대 변하지 않기 때문에 완벽한 캐시 후보입니다.

세 번째 질문: 나의 세션이 시간에 걸쳐 분산되어 있는가? 호출이 몇 분 이내에 이루어진다면 기본 캐시로도 충분합니다. 하지만 작업이 한 시간에 걸쳐 분산된다면, 캐시가 만료되어 다시 작성해야 하는 상황을 방지하기 위해 더 긴 캐시 윈도우(Cache Window)를 사용합니다. 이 부분에서 많은 사람들이 실수합니다. 캐싱을 올바르게 설정해두고 20분간 커피 휴식을 취하고 돌아왔더니, 캐시가 만료되어 다시 쓰기 프리미엄(write premium) 비용을 지불하게 되는 경우입니다.

네 번째 질문: 동적인(dynamic) 부분이 고정된(stable) 부분에 비해 작은가? 캐싱은 고정된 블록이 변하는 블록보다 압도적으로 클 때만 이득이 됩니다. 만약 질문의 크기가 컨텍스트의 크기만큼 크다면, 여전히 거대한 동적 청크(dynamic chunk)에 대해 전체 비용을 지불해야 하므로 캐싱으로 절약할 수 있는 금액이 적습니다. 가장 이상적인 지점(sweet spot)은 거대한 고정 컨텍스트와 아주 작은 동적 질문의 조합입니다.

이 파이프라인에서 생성되는 소셜 포스트(social posts)를 예약할 때, 저는 Buffer를 통해 전달하여 생성 비용과 타이밍 관리를 분리합니다. 이러한 관심사들을 분리해 두면 비용 구조가 더 명확해집니다. 각 생성 배치(batch)의 비용과 예약 비용이 각각 얼마인지 정확히 알 수 있으며, 어느 한쪽이 다른 쪽의 비용 속에 숨겨지지 않습니다.

솔직한 요약은 다음과 같습니다: 1M 컨텍스트(Context)는 탐색과 원샷(one-shots)을 위한 것입니다. 캐싱(Caching)은 프로덕션 루프(production loops)를 위한 것입니다. 하이브리드(Hybrid) 방식은 두 번 이상 실행되는 모든 진지한 작업에 적합합니다. 단 한 번만 사용하는 것을 캐싱하지 마세요. 그리고 50번이나 사용하는 것을 매번 새로 읽어 들이지 마세요. 이 단 하나의 규칙이 실제 의사결정의 90%를 해결해 줍니다.

결론 (Bottom Line)

선택의 기준은 어떤 기능이 더 나은가가 아닙니다. 얼마나 많이 호출하느냐의 문제입니다. 단 한 번의 호출이라면, 1M 컨텍스트 윈도우(Context Window)가 단순성 측면에서 승리합니다. 고정된 자료를 대상으로 여러 번 호출한다면, 3회 호출을 넘어가는 시점부터 캐싱이 비용 면에서 약 10대 1의 비율로 승리합니다. 그리고 대부분의 실제 파이프라인(pipelines)은 하이브리드 방식을 원합니다. 즉, 안정적인 85%는 캐싱하고, 동적인 15%는 매번 새롭게 스트리밍(stream)하는 방식입니다.

저는 이 작업을 매주 수행하며, 올바르게 설정하는 것과 잘못 설정하는 것의 차이는 저렴한 배치(batch)와 비싼 배치 사이의 차이와 같습니다. 순서 규칙(ordering rule)과 캐시 수명(cache lifetime)을 이해하고 나면 설정에는 몇 분밖에 걸리지 않습니다. 그 이후에는 그냥 실행될 뿐입니다.

제가 이러한 AI 파이프라인을 엔드 투 엔드(end to end)로 구축할 때 사용하는 전체 시스템을 알고 싶다면, Claude Blueprint에서 캐싱된 프롬프트(cached prompts)를 구조화하는 방법과 고정된 콘텐츠를 동적인 콘텐츠와 분리하는 방법을 포함한 전체 설정을 살펴볼 수 있습니다. 모델을 몇 번 이상 호출하는 무언가를 구축하고 있다면 거기서부터 시작하세요. 분리(split)를 한 번만 제대로 해두면 더 이상 고민할 필요가 없습니다.

이 기사에는 제휴 링크가 포함되어 있습니다. 이 링크를 통해 가입하시면 귀하에게 추가 비용 없이 저에게 소정의 수수료가 지급될 수 있습니다. (광고)