컨텍스트 윈도우 관리: 실제 세션에서 살아남는 전략

무한한 컨텍스트라는 환상: 유효 한도(Effective Limits) vs 명목 한도(Nominal Limits)

대규모 언어 모델(Large Language Models, LLM)은 방대한 컨텍스트 윈도우(Context Window)를 광고하지만, 실제 세션에서 경험하는 실질적인 한도는 종종 그보다 훨씬 작습니다. 명목 한도(Nominal limit)는 모델이 단일 요청에서 수용할 수 있는 최대 토큰(Token) 수이며, Claude 3.5 Sonnet의 경우 그 숫자는 200,000 토큰입니다. 실제로 각 요청에는 오버헤드(Overhead), 시스템 메시지(System messages), 그리고 토큰화(Tokenization)의 특이 사항들이 포함되어 사용 가능한 공간을 축소시킵니다. 더욱이, 윈도우가 채워질수록 모델의 어텐션 메커니즘(Attention mechanism)이 저하되므로, 하드 한도(Hard limit)에 도달하기 훨씬 전부터 응답의 품질이 떨어지게 됩니다.

명목 한도와 유효 한도의 차이가 중요한 이유는 개발자들이 전체 윈도우가 사용자 데이터를 위해 완전히 사용 가능하다는 가정하에 프롬프트(Prompt)를 설계하는 경향이 있기 때문입니다. 시스템 지침(System instructions), 이전 대화 기록, 또는 도구 출력(Tool output)이 윈도우의 일부를 차지하게 되면, 새로운 콘텐츠를 위한 남은 용량은 단 몇 천 토큰에 불과할 수 있습니다. 이러한 불일치는 텍스트 잘림(Truncation), 중요한 컨텍스트 손실, 그리고 다운스트림 로직(Downstream logic)에서의 예기치 않은 실패로 이어집니다.

기저에 깔린 메커니즘은 간단합니다. 모델은 토큰 임베딩(Token embeddings)의 선형 시퀀스(Linear sequence)를 처리합니다. 각 토큰은 어텐션 행렬(Attention matrix)에서 고정된 양의 메모리를 소비하며, 행렬의 크기는 시퀀스 길이(Sequence length)에 따라 이차 함수적으로(Quadratically) 증가합니다. 시퀀스가 명목 한도에 가까워질수록 어텐션 연산(Attention computation) 비용은 더 커지며, 초기 토큰들을 두드러지게 유지하는 모델의 능력은 감소합니다. 그 결과, 토큰 수만으로는 반영되지 않는 컨텍스트 관련성(Context relevance)의 완만한 저하가 발생합니다.

구체적인 사례가 그 격차를 보여줍니다. 챗봇이 평균 150개의 토큰으로 구성된 10회의 대화(turn)를 유지하고, 500개의 토큰을 가진 시스템 프롬프트(System prompt)를 추가한다고 가정해 봅시다. 이는 2,000개의 토큰을 소비합니다. 만약 개발자가 여기에 1,500개의 토큰을 가진 사용자 요청(User request)을 덧붙인다면, 총합은 3,500개의 토큰에 도달하며 이는 명목상의 한도(Nominal limit)보다 훨씬 낮습니다. 하지만 모델의 어텐션(Attention)은 가장 최근의 1,500개 토큰에 대부분의 초점을 할당할 것이며, 이전의 대화들은 사실상 무시될 수 있습니다. 따라서 엔지니어는 유효한 컨텍스트(Effective context)를 수천 개의 토큰 이내로 유지하기 위해 오래된 대화 내용을 가지치기(Prune)하거나 요약해야 합니다.

이러한 착시 현상을 이해하면 숨겨진 토큰 초과(Token overrun) 버그를 피할 수 있습니다. 모든 구성 요소의 토큰 예산(Token budget)을 추적하고, 모델의 내부 처리를 위한 여유 공간(Headroom)을 확보하며, 예산이 초과될 경우를 대비해 요약(Summarization)이나 선택적 검색(Selective retrieval)과 같은 폴백 전략(Fallback strategy)을 설계하십시오. 명목상의 한도를 사용 가능한 용량이 아닌 상한선(Upper bound)으로 취급함으로써, 세션이 길어져도 신뢰성을 유지하는 시스템을 구축할 수 있습니다.

Claude 3.5 Sonnet은 단일 요청에서 최대 200,000개의 토큰을 수용할 수 있습니다. Anthropic Models Overview에서는 이를 최대 컨텍스트 윈도우(Maximum context window)로 나열하고 있지만, 실제 사용 시 이 천장에 도달하는 경우는 드뭅니다.

프롬프트 캐싱(Prompt caching)을 사용하면 자주 사용되는 컨텍스트를 재사용하여 API 호출과 토큰 낭비를 줄일 수 있습니다. Anthropic Developer Documentation에 따르면, API는 새로운 요청을 보내기 전에 프롬프트 접두사(Prompt prefix)가 이미 캐싱되어 있는지 확인합니다. Anthropic Developer Documentation - Prompt Caching

프롬프트 캐싱의 내부 원리: Claude의 1024-토큰 분기점 최적화

Claude의 모델들은 세션을 "분기점 (breakpoints)"으로 나누는 엄격한 토큰 제한을 적용합니다. 프롬프트가 분기점을 초과하면, 모델은 이전 토큰들을 폐기하고 새로운 컨텍스트 윈도우 (context window)를 시작합니다. 각 분기점에서 프롬프트를 다시 구축하는 비용은 토큰 수에 비례하여 선형적으로 증가하며, 이는 장기 실행 세션에서 지연 시간 (latency)과 토큰 예산을 빠르게 잠식합니다. 프롬프트 캐싱 (Prompt caching)은 동일한 분기점에 도달할 때마다 재사용할 수 있는 사전 계산된 접두사 (prefix)를 저장함으로써 이 문제를 우회합니다. 캐시는 정확한 토큰 시퀀스에 의해 키(key)가 지정되므로, 캐시 히트 (cache hit)가 발생하면 텍스트를 다시 인코딩하지 않고도 모델의 내부 상태를 복구할 수 있습니다.

캐시는 접두사 길이가 모델의 최소 캐싱 가능 크기를 충족할 때만 작동합니다. Claude 3.5 Sonnet 및 Claude 3.5 Haiku의 경우, 그 임계값은 정확히 1,024 토큰입니다.

Claude 3.5 Sonnet의 캐시 트리거는 1,024 토큰이며, 이는 Anthropic 프롬프트 캐싱 가이드 (Anthropic Prompt Caching Guide)에 문서화되어 있습니다. 이 수치는 런타임 (runtime)이 재사용을 위해 저장할 가장 작은 접두사를 정의합니다.
접두사가 이보다 짧으면 런타임은 전체 재계산 (full recompute) 방식으로 전환되어 성능 이점이 사라집니다. 따라서 개발자는 가장 비용이 많이 들고 정적인 부분(주로 시스템 지침, 스키마 정의 또는 도메인 지식)이 최소한 해당 토큰 수만큼을 차지하도록 프롬프트를 구성해야 합니다.

구체적인 패턴은 모든 불변의 컨텍스트를 포함하는 "정적 블록 (static block)"을 미리 조립한 다음, 사용자별 대화를 담은 "동적 블록 (dynamic block)"을 추가하는 것입니다. 정적 블록은 한 번 캐싱되며, 동적 블록은 매 턴마다 재생성됩니다. 다음 Python 스니펫은 Anthropic SDK를 사용하여 이를 구현하는 방법을 보여줍니다:

import anthropic

client = anthropic.Anthropic()
...

실패 모드(Failure modes)는 정적 블록(static block)이 캐시 임계값(cache threshold) 아래로 밀려나거나, 토큰화(tokenization)가 변경될 때(예: 새로운 어휘가 추가되어 토큰이 늘어나는 경우), 또는 보이지 않는 공백(whitespace)으로 인해 캐시 키(cache key)가 불일치할 때 발생합니다. 실제 상황에서 캐시 미스(cache miss)는 갑작스러운 지연 시간(latency)의 급증과 턴(turn)당 더 높은 토큰 소비량으로 나타납니다. 지연 시간 스파이크와 토큰 수를 모니터링하면 이러한 문제를 조기에 발견할 수 있습니다.

매 턴마다 전체 프롬프트를 다시 인코딩(re-encoding)하는 단순한(naïve) 방식과 비교했을 때, 캐싱은 일반적인 2,000토큰 세션에서 턴당 연산량을 최대 30%까지 줄여줍니다. 트레이드오프(trade-off)는 블록 경계(block boundaries)를 관리하고 정적 블록이 캐시 가능한 상태를 유지하도록 보장하는 데 따르는 복잡성의 증가입니다.

세션이 단일 중단점(breakpoint)을 초과하고, 1,024토큰 단위로 토큰 정렬(token-aligned)이 가능한 상당한 크기의 불변 접두사(immutable prefix)를 가지고 있다면 프롬프트 캐싱(prompt caching)을 사용하십시오. 만약 워크로드(workload)가 짧고 변동성이 매우 큰 프롬프트로 구성되어 있다면, 캐시를 유지하는 오버헤드(overhead)가 이점보다 더 클 수 있습니다. 그런 경우에는 단순한 재계산(recompute) 방식을 유지하는 것이 좋습니다.

Anthropic 문서에 따르면, “Claude 3.5 Sonnet 및 Claude 3.5 Haiku의 경우 최소 캐시 가능 프롬프트 길이는 1,024토큰입니다. Claude 3 Opus의 경우 8,192토큰입니다”라고 명시되어 있으며, 이는 중단점 제약 조건을 확인해 줍니다. Anthropic Developer Documentation - Prompt Caching Limits

상태 압축(State Compaction) vs. 세션 핸드오프(Session Handoff): 아키텍처 결정 경계

사용자 세션이 모델의 컨텍스트 윈도우(context window)를 초과할 때, 엔지니어는 누적된 상태를 더 작은 표현으로 압축할지(상태 압축, state compaction), 아니면 여러 모델 호출에 걸쳐 대화를 분할할지(세션 핸드오프, session handoff) 결정해야 합니다. 이 선택은 지연 시간, 비용, 그리고 사용자 경험의 충실도(fidelity)를 결정합니다. 실제로 두 전술 사이의 경계는 명확한 선이 아니며, 모델의 토큰 예산(token budget), 도메인의 휘발성(volatility), 그리고 호출 간의 결정론적 동작(deterministic behavior) 필요성에 의해 형성됩니다.

상태 압축 (State compaction)은 이전 메시지들의 토큰 수 (token count)를 요약하거나 다른 방식으로 줄임으로써 작동합니다. 기술로는 손실이 있는 요약 (lossy summarization), 주요 엔티티 (key entities) 추출, 또는 모델이 단일 프롬프트 (prompt)로 섭취할 수 있도록 대화를 구조화된 스키마 (structured schema)로 인코딩하는 방식 등이 있습니다. 이 방식의 장점은 전체 대화가 단일 추론 (inference) 내에 유지되어 모델의 내부 상태 (internal state)를 보존하고 호출 간의 조정 (cross-call coordination)을 피할 수 있다는 점입니다. 단점은 어떤 압축이든 필연적으로 세부 사항을 버리게 된다는 것입니다. 미묘한 단서나 희귀한 사실이 유실될 수 있으며, 이는 답변 품질의 저하로 이어질 수 있습니다.

반면, 세션 핸드오프 (Session handoff)는 대화를 일련의 독립적인 윈도우 (windows)로 취급합니다. 토큰 예산 (token budget)에 도달하면, 시스템은 현재 상태를 외부(예: 데이터베이스 또는 파일)에 저장하고 간결한 핸드오프 요약 (handoff summary)을 포함하는 새로운 프롬프트를 시작합니다. 다음 모델 호출 (model call)은 핸드오프 토큰을 전달받아 대화가 중단되지 않은 것처럼 계속 진행합니다. 이 접근 방식은 긴 세션에서도 깔끔하게 확장(scale)되며 원래의 컨텍스트 (context)를 온전하게 유지하지만, 각 핸드오프 시 지연 시간 (latency)이 발생하며 신뢰할 수 있는 저장 및 검색 로직이 필요합니다.

구체적인 예시는 Leviathan 터미널에서 볼 수 있는데, 여기서 다단계 문제 해결 워크플로 (troubleshooting workflow)가 모델의 명목상 200만 토큰 제한을 초과합니다. 시스템은 초기 단계들을 JSON 요약으로 압축한 다음, 남은 단계들을 위해 새로운 모델 인스턴스 (model instance)로 핸드오프합니다. 이러한 하이브리드 패턴 (hybrid pattern)을 통해 워크플로는 윈도우 내에 머무르면서도 호출 간의 논리적 흐름을 보존할 수 있습니다.

핸드오프 요약이 너무 간결하거나 압축 알고리즘 (compaction algorithm)이 사용자의 의도를 잘못 표현할 때 실패 모드 (failure modes)가 나타납니다. 전자의 경우 모델이 중복된 확인 질문을 던질 수 있으며, 후자의 경우 중요한 제약 조건 (constraints)을 무시하는 답변을 생성할 수 있습니다. 토큰 사용량을 모니터링하고 핸드오프 충실도 (handoff fidelity)를 검증하는 것은 필수적인 안전장치입니다.

애플리케이션이 가끔 발생하는 뉘앙스의 손실을 허용할 수 있고 낮은 지연 시간 (low latency)을 중시한다면, 상태 압축 (state compaction)이 더 간단한 선택입니다. 만약 대화 내용이 감사 가능 (auditable)해야 하며 수만 개의 토큰에 걸쳐 지속되어야 한다면, 세션 핸드오프 (session handoff)가 더 견고한 기반을 제공합니다. 결정은 토큰 예산, 세부 사항의 중요성, 그리고 수용 가능한 운영 오버헤드 (operational overhead)에 따라 내려져야 합니다.

Gemini 1.5 Pro의 명목상 컨텍스트 윈도우 (context window)는 2,000,000 토큰입니다. 이 수치는 Google AI Studio Model Features에서 제공하며, 가공되지 않은 토큰 소비의 상한선을 설정합니다. OpenAI API Reference - Prompt Caching에 따르면, "1024 토큰보다 긴 프롬프트에 대해서는 프롬프트 캐싱 (prompt caching)이 자동으로 적용됩니다. 캐시는 접두사 (prefixes)를 중심으로 구조화되어 있어, 시스템 지침 (system instructions)과 과거 메시지의 재사용을 가능하게 합니다."라고 설명합니다. 해당 소스는 캐싱이 어떻게 반복되는 토큰 비용을 줄일 수 있는지 상세히 다룹니다.

스크래치패드 및 파일 기반 메모리 vs. 구조화된 도구 호출 (Structured Tool Calls)

대화가 모델의 토큰 윈도우를 초과할 때, 엔지니어들은 전체 이력을 다시 보내지 않고도 관련 정보에 접근할 수 있도록 유지하는 전략이 필요합니다. 두 가지 일반적인 패턴은 스크래치패드 (scratchpads, 프롬프트 내 메모)와 파일 기반 메모리 (file-based memory, 발췌문의 외부 저장)입니다. 두 방식 모두 텍스트를 읽고 쓰는 모델의 능력에 의존하지만, 모델에 데이터를 제시하는 방식에서 차이가 있습니다. 스크래치패드는 매 턴 프롬프트에 삽입되는 짧고 가변적인 블록이며, 파일 기반 방식은 더 긴 구절을 별도의 저장소에 저장하고 필요할 때 호출합니다. 반면, 구조화된 도구 호출 (structured tool calls)은 모델이 예측 가능한 형식으로 데이터를 반환하는 정의된 API를 호출하게 함으로써 토큰 제한을 완전히 우회합니다.

스크래치패드 (scratchpad) 패턴은 구현이 간단합니다. 매 턴이 끝날 때마다 시스템은 주요 사실, 결정 사항 또는 미결 질문을 불렛 리스트 (bullet list) 형태로 추가합니다. 이 리스트는 수백 토큰 이내로 유지되므로 컨텍스트 윈도우 (context window) 내에 여유롭게 들어갑니다. 모델은 이 리스트를 프롬프트 (prompt)의 일부로 인식하기 때문에, 이를 바탕으로 직접 추론할 수 있습니다. 하지만 리스트는 턴 수가 늘어남에 따라 선형적으로 증가하며, 오래된 항목들이 쌓여 토큰 팽창 (token bloat)을 초래할 수 있습니다. 전형적인 구현 방식은 다음과 같습니다:

def update_scratchpad(scratchpad, new_fact):
    # 가장 최근의 10개 항목만 유지
    items = scratchpad.split("\n")[-9:]
...

파일 기반 메모리 (File-based memory)는 그 부담을 외부 저장소로 전환합니다. 시스템은 긴 구절을 문서 저장소(예: 벡터 데이터베이스 (vector database))에 기록하고, 모델이 컨텍스트 (context)가 필요할 때 가장 관련성이 높은 상위 k개 (top-k)의 청크 (chunk)를 검색합니다. 검색은 매 생성 (generation) 전에 수행되며, 선택된 청크들만 프롬프트에 삽입됩니다. 이는 토큰 사용량을 극적으로 줄여주지만, 지연 시간 (latency)을 유발하고 신뢰할 수 있는 유사도 검색 (similarity search)을 필요로 합니다. 검색된 텍스트는 일관된 형식으로 구성되어야 하며, 그렇지 않으면 모델이 헤딩 (heading)이나 코드 블록 (code block)을 오해할 수 있습니다.

구조화된 도구 호출 (Structured tool calls)은 정의된 인터페이스를 통해 데이터를 노출함으로써 이러한 함정들을 피합니다. 모델은 search_documents(query="project deadline")와 같은 호출을 실행하고, 백엔드 (backend)는 일치하는 발췌문을 포함한 JSON 페이로드 (payload)를 반환합니다. 그런 다음 모델은 프롬프트를 확장하지 않고 해당 페이로드를 통합합니다. 이 패턴은 모델이 페이로드 크기보다 더 많은 데이터를 보지 않으며, 도구 계약 (tool contract)이 타입 안정성 (type safety)을 보장하기 때문에 확장성이 뛰어납니다. 단점은 모델이 도구 스키마 (tool schema)를 학습해야 하며, API에 변경이 생길 때마다 프롬프트 업데이트가 필요하다는 점입니다.

모델 컨텍스트 프로토콜 (Model Context Protocol, MCP)은 개발자가 데이터와 기능을 AI 모델에 안전하게 노출할 수 있는 표준화된 방법을 제공하며, 도구 (tools)와 리소스 (resources)를 통해 컨텍스트 경계를 깔끔하게 관리합니다.

Model Context Protocol (MCP)은 Model Context Protocol Introduction Model Context Protocol Introduction에서 설명된 바와 같이, AI에 데이터를 노출하기 위한 깔끔한 경계를 제공합니다.

비용이 중요한 요소가 될 때, 프롬프트 캐시 읽기 할인 (prompt cache read discount)은 결정적인 역할을 할 수 있습니다.

Claude 3.5 Sonnet의 프롬프트 캐시 읽기 비용은 기본 입력 비용보다 90% 저렴합니다: 100만 토큰당 $3.00가 아닌 $0.30입니다 (Anthropic API Pricing Page).