대화가 길어지면 결국 컨텍스트 윈도우 한계에 도달하게 됩니다. 이 가이드에서는 컨텍스트 윈도우의 작동 방식을 설명하고 이를 효과적으로 관리하기 위한 전략을 소개합니다.
장시간 실행되는 대화 및 에이전트 워크플로우의 경우, 서버 측 압축이 컨텍스트 관리의 주요 전략입니다. 보다 전문적인 요구 사항에 대해서는 컨텍스트 편집이 도구 결과 지우기 및 사고 블록 지우기와 같은 추가 전략을 제공합니다.
"컨텍스트 윈도우"는 응답 자체를 포함하여 언어 모델이 응답을 생성할 때 참조할 수 있는 모든 텍스트를 의미합니다. 이는 언어 모델이 학습된 대규모 데이터 코퍼스와는 다르며, 대신 모델의 "작업 메모리"를 나타냅니다. 더 큰 컨텍스트 윈도우는 모델이 더 복잡하고 긴 프롬프트를 처리할 수 있게 합니다. 더 작은 컨텍스트 윈도우는 확장된 대화에서 모델의 일관성 유지 능력을 제한할 수 있습니다.
아래 다이어그램은 API 요청에 대한 표준 컨텍스트 윈도우 동작을 보여줍니다1:
1claude.ai와 같은 채팅 인터페이스의 경우, 컨텍스트 윈도우는 롤링 "선입선출" 시스템으로 설정할 수도 있습니다.
확장된 사고를 사용할 때, 사고에 사용된 토큰을 포함한 모든 입력 및 출력 토큰은 컨텍스트 윈도우 한계에 포함되며, 다중 턴 상황에서 몇 가지 뉘앙스가 있습니다.
사고 예산 토큰은 max_tokens 매개변수의 하위 집합이며, 출력 토큰으로 청구되고 속도 제한에 포함됩니다. 적응형 사고를 사용하면 Claude가 사고 할당을 동적으로 결정하므로 실제 사고 토큰 사용량은 요청마다 다를 수 있습니다.
그러나 이전 사고 블록은 Claude API에 의해 컨텍스트 윈도우 계산에서 자동으로 제거되며, 후속 턴에서 모델이 "보는" 대화 기록의 일부가 아니므로 실제 대화 콘텐츠를 위한 토큰 용량을 보존합니다.
아래 다이어그램은 확장된 사고가 활성화되었을 때의 전문화된 토큰 관리를 보여줍니다:
context_window = (input_tokens - previous_thinking_tokens) + current_turn_tokens.thinking 블록과 redacted_thinking 블록이 모두 포함됩니다.이 아키텍처는 토큰 효율적이며, 사고 블록이 상당한 길이가 될 수 있으므로 토큰 낭비 없이 광범위한 추론을 가능하게 합니다.
컨텍스트 윈도우와 확장된 사고에 대한 자세한 내용은 확장된 사고 가이드에서 확인할 수 있습니다.
아래 다이어그램은 확장된 사고와 도구 사용을 결합할 때의 컨텍스트 윈도우 토큰 관리를 보여줍니다:
첫 번째 턴 아키텍처
도구 결과 처리 (턴 2)
tool_result. 확장된 사고 블록은 해당 도구 결과와 함께 반드시 반환되어야 합니다. 이것은 사고 블록을 반드시 반환해야 하는 유일한 경우입니다.user 메시지까지 추가 확장된 사고 없음).세 번째 단계
User 턴을 추가하는 곳입니다.User 턴이 있으므로, Claude는 새로운 확장된 사고 블록을 생성하고 거기서부터 계속합니다.Assistant 턴의 사고 블록은 컨텍스트 윈도우의 일부로 포함됩니다.context_window = input_tokens + current_turn_tokens.Claude 4 모델은 인터리브 사고를 지원하여 Claude가 도구 호출 사이에 사고하고 도구 결과를 받은 후 더 정교한 추론을 할 수 있습니다.
Claude Sonnet 3.7은 인터리브 사고를 지원하지 않으므로, tool_result가 아닌 사용자 턴 없이는 확장된 사고와 도구 호출의 인터리빙이 없습니다.
확장된 사고와 도구 사용에 대한 자세한 내용은 확장된 사고 가이드를 참조하세요.
Claude Opus 4.6, Sonnet 4.5, Sonnet 4는 100만 토큰 컨텍스트 윈도우를 지원합니다. 이 확장된 컨텍스트 윈도우를 통해 훨씬 더 큰 문서를 처리하고, 더 긴 대화를 유지하며, 더 광범위한 코드베이스로 작업할 수 있습니다.
1M 토큰 컨텍스트 윈도우는 현재 사용 티어 4 및 맞춤 속도 제한이 있는 조직을 위한 베타 버전입니다. 1M 토큰 컨텍스트 윈도우는 Claude Opus 4.6, Sonnet 4.5, Sonnet 4에서만 사용할 수 있습니다.
1M 토큰 컨텍스트 윈도우를 사용하려면 API 요청에 context-1m-2025-08-07 베타 헤더를 포함하세요:
curl https://api.anthropic.com/v1/messages \
-H "x-api-key: $ANTHROPIC_API_KEY" \
-H "anthropic-version: 2023-06-01" \
-H "anthropic-beta: context-1m-2025-08-07" \
-H "content-type: application/json" \
-d '{
"model": "claude-opus-4-6",
"max_tokens": 1024,
"messages": [
{"role": "user", "content": "Process this large document..."}
]
}'중요 고려 사항:
Claude Sonnet 4.5와 Claude Haiku 4.5는 컨텍스트 인식 기능을 갖추고 있습니다. 이 기능을 통해 이러한 모델은 대화 전반에 걸쳐 남은 컨텍스트 윈도우(즉, "토큰 예산")를 추적할 수 있습니다. 이를 통해 Claude는 작업할 수 있는 공간이 얼마나 남았는지 이해하여 작업을 실행하고 컨텍스트를 더 효과적으로 관리할 수 있습니다. Claude는 이 컨텍스트를 정확하게 사용하도록 학습되어, 남은 토큰 수를 추측하는 대신 맨 마지막까지 작업을 지속합니다. 모델에게 컨텍스트 인식이 없다는 것은 시계 없이 요리 대회에 참가하는 것과 같습니다. Claude 4.5 모델은 모델에게 남은 컨텍스트에 대해 명시적으로 알려줌으로써 이를 변경하여, 사용 가능한 토큰을 최대한 활용할 수 있게 합니다.
작동 방식:
대화 시작 시 Claude는 전체 컨텍스트 윈도우에 대한 정보를 받습니다:
<budget:token_budget>200000</budget:token_budget>예산은 200K 토큰(표준), 500K 토큰(claude.ai Enterprise), 또는 1M 토큰(베타, 적격 조직용)으로 설정됩니다.
각 도구 호출 후 Claude는 남은 용량에 대한 업데이트를 받습니다:
<system_warning>Token usage: 35000/200000; 165000 remaining</system_warning>이 인식은 Claude가 작업에 남은 용량을 파악하는 데 도움이 되며, 장시간 실행되는 작업에서 더 효과적인 실행을 가능하게 합니다. 이미지 토큰도 이러한 예산에 포함됩니다.
이점:
컨텍스트 인식은 특히 다음에 유용합니다:
컨텍스트 인식을 활용하기 위한 프롬프팅 가이드는 프롬프팅 모범 사례 가이드를 참조하세요.
대화가 정기적으로 컨텍스트 윈도우 한계에 도달하는 경우, 서버 측 압축이 권장되는 접근 방식입니다. 압축은 대화의 이전 부분을 자동으로 요약하는 서버 측 요약을 제공하여, 최소한의 통합 작업으로 컨텍스트 한계를 넘어서는 장시간 대화를 가능하게 합니다. 현재 Claude Opus 4.6에 대해 베타로 제공됩니다.
보다 전문적인 요구 사항에 대해서는 컨텍스트 편집이 추가 전략을 제공합니다:
최신 Claude 모델(Claude Sonnet 3.7부터)은 프롬프트와 출력 토큰이 컨텍스트 윈도우를 초과할 때 자동으로 잘라내는 대신 유효성 검사 오류를 반환합니다. 이 변경은 더 예측 가능한 동작을 제공하지만 더 신중한 토큰 관리가 필요합니다.
Claude에 메시지를 보내기 전에 토큰 카운팅 API를 사용하여 토큰 사용량을 추정하세요. 이를 통해 계획을 세우고 컨텍스트 윈도우 한계 내에 머물 수 있습니다.
모델별 컨텍스트 윈도우 크기 목록은 모델 비교 표를 참조하세요.
장시간 실행되는 대화에서 컨텍스트를 관리하기 위한 권장 전략입니다.
도구 결과 지우기 및 사고 블록 지우기와 같은 세밀한 전략입니다.
모델별 컨텍스트 윈도우 크기 및 입력/출력 토큰 가격 목록은 모델 비교 표를 참조하세요.
확장된 사고의 작동 방식과 도구 사용 및 프롬프트 캐싱과 같은 다른 기능과 함께 구현하는 방법에 대해 자세히 알아보세요.
Was this page helpful?