컨텍스트 윈도우

컨텍스트 창

This feature is eligible for Zero Data Retention (ZDR). When your organization has a ZDR arrangement, data sent through this feature is not stored after the API response is returned.

대화가 길어지면서 결국 컨텍스트 윈도우 제한에 접근하게 됩니다. 이 가이드는 컨텍스트 윈도우가 어떻게 작동하는지 설명하고 효과적으로 관리하기 위한 전략을 소개합니다.

장기 실행 대화 및 에이전트 워크플로우의 경우, 서버 측 압축이 컨텍스트 관리의 주요 전략입니다. 더 특화된 요구사항의 경우, 컨텍스트 편집은 도구 결과 삭제 및 사고 블록 삭제와 같은 추가 전략을 제공합니다.

컨텍스트 윈도우 이해하기

"컨텍스트 윈도우"는 응답 자체를 포함하여 언어 모델이 응답을 생성할 때 참조할 수 있는 모든 텍스트를 의미합니다. 이는 언어 모델이 학습한 대규모 데이터 코퍼스와는 다르며, 대신 모델의 "작업 메모리"를 나타냅니다. 더 큰 컨텍스트 윈도우를 사용하면 모델이 더 복잡하고 긴 프롬프트를 처리할 수 있지만, 더 많은 컨텍스트가 자동으로 더 나은 것은 아닙니다. 토큰 수가 증가하면서 정확도와 회상이 저하되는데, 이를 컨텍스트 부패라고 합니다. 이는 컨텍스트에 무엇이 있는지를 큐레이션하는 것이 사용 가능한 공간의 크기만큼 중요하게 만듭니다.

Claude는 MRCR 및 GraphWalks와 같은 장문 컨텍스트 검색 벤치마크에서 최첨단 결과를 달성하지만, 이러한 성과는 얼마나 많은 양이 맞는지가 아니라 컨텍스트에 무엇이 있는지에 달려 있습니다.

긴 컨텍스트가 왜 저하되는지, 그리고 이를 어떻게 해결할 수 있는지에 대한 심층 분석은 효과적인 컨텍스트 엔지니어링을 참조하세요.

아래 다이어그램은 API 요청에 대한 표준 컨텍스트 윈도우 동작을 보여줍니다¹:

컨텍스트 윈도우 다이어그램

¹claude.ai와 같은 채팅 인터페이스의 경우, 컨텍스트 윈도우는 "선입선출" 롤링 시스템으로도 설정할 수 있습니다.

점진적 토큰 누적: 대화가 턴을 거치면서 진행되면서 각 사용자 메시지와 어시스턴트 응답이 컨텍스트 윈도우 내에 누적됩니다. 이전 턴은 완전히 보존됩니다.
선형 성장 패턴: 컨텍스트 사용량은 각 턴마다 선형으로 증가하며, 이전 턴은 완전히 보존됩니다.
컨텍스트 윈도우 용량: 총 사용 가능한 컨텍스트 윈도우(최대 1M 토큰)는 대화 기록을 저장하고 Claude에서 새 출력을 생성하기 위한 최대 용량을 나타냅니다.
입출력 흐름: 각 턴은 다음으로 구성됩니다:
- 입력 단계: 모든 이전 대화 기록과 현재 사용자 메시지를 포함합니다
- 출력 단계: 향후 입력의 일부가 되는 텍스트 응답을 생성합니다

확장된 사고를 사용한 컨텍스트 윈도우

확장된 사고를 사용할 때, 사고에 사용된 토큰을 포함한 모든 입력 및 출력 토큰이 컨텍스트 윈도우 제한에 포함되며, 다중 턴 상황에서 몇 가지 미묘한 차이가 있습니다.

사고 예산 토큰은 max_tokens 파라미터의 부분집합이며, 출력 토큰으로 청구되고, 속도 제한에 포함됩니다. 적응형 사고를 사용하면 Claude가 동적으로 사고 할당을 결정하므로 실제 사고 토큰 사용량은 요청마다 다를 수 있습니다.

그러나 이전 사고 블록은 Claude API에 의해 컨텍스트 윈도우 계산에서 자동으로 제거되며 후속 턴에서 모델이 "보는" 대화 기록의 일부가 아니므로, 실제 대화 내용을 위한 토큰 용량을 보존합니다.

아래 다이어그램은 확장된 사고가 활성화되었을 때의 특화된 토큰 관리를 보여줍니다:

확장된 사고를 사용한 컨텍스트 윈도우 다이어그램

확장된 사고 제거: 확장된 사고 블록(진회색으로 표시됨)은 각 턴의 출력 단계 중에 생성되지만, 후속 턴의 입력 토큰으로 전달되지 않습니다. 사고 블록을 직접 제거할 필요가 없습니다. Claude API가 자동으로 이를 수행합니다.
기술 구현 세부사항:
- API는 대화 기록의 일부로 다시 전달할 때 이전 턴의 사고 블록을 자동으로 제외합니다.
- 확장된 사고 토큰은 생성 중에 한 번만 출력 토큰으로 청구됩니다.
- 효과적인 컨텍스트 윈도우 계산은 다음과 같이 됩니다: context_window = (input_tokens - previous_thinking_tokens) + current_turn_tokens.
- 사고 토큰에는 thinking 블록이 포함됩니다.

이 아키텍처는 토큰 효율적이며 사고 블록이 상당한 길이일 수 있으므로 토큰 낭비 없이 광범위한 추론을 가능하게 합니다.

컨텍스트 윈도우와 확장된 사고에 대해 더 자세히 알아보려면 확장된 사고 가이드를 참조하세요.

확장된 사고와 도구 사용을 사용한 컨텍스트 윈도우

아래 다이어그램은 확장된 사고와 도구 사용을 결합할 때의 컨텍스트 윈도우 토큰 관리를 보여줍니다:

확장된 사고와 도구 사용을 사용한 컨텍스트 윈도우 다이어그램

첫 번째 턴 아키텍처
- 입력 구성요소: 도구 구성 및 사용자 메시지
- 출력 구성요소: 확장된 사고 + 텍스트 응답 + 도구 사용 요청
- 토큰 계산: 모든 입력 및 출력 구성요소가 컨텍스트 윈도우에 포함되며, 모든 출력 구성요소가 출력 토큰으로 청구됩니다.
도구 결과 처리(턴 2)
- 입력 구성요소: 첫 번째 턴의 모든 블록과 tool_result. 확장된 사고 블록은 반드시 해당 도구 결과와 함께 반환되어야 합니다. 이것이 사고 블록을 반드시 반환해야 하는 유일한 경우입니다.
- 출력 구성요소: 도구 결과가 Claude에 다시 전달된 후, Claude는 텍스트만으로 응답합니다(다음 user 메시지까지 추가 확장된 사고 없음).
- 토큰 계산: 모든 입력 및 출력 구성요소가 컨텍스트 윈도우에 포함되며, 모든 출력 구성요소가 출력 토큰으로 청구됩니다.
세 번째 단계
- 입력 구성요소: 모든 입력과 이전 턴의 출력이 전달되며, 사고 블록은 예외입니다. Claude가 전체 도구 사용 사이클을 완료했으므로 이제 사고 블록을 삭제할 수 있습니다. API가 자동으로 사고 블록을 제거해 드리거나, 이 단계에서 직접 제거할 수 있습니다. 이것은 또한 다음 User 턴을 추가할 위치입니다.

확장된 사고를 사용한 도구 사용 고려사항:
- 도구 결과를 게시할 때, 해당 특정 도구 요청과 함께하는 전체 수정되지 않은 사고 블록(서명 부분 포함)을 포함해야 합니다.
- 도구 사용을 사용한 확장된 사고의 효과적인 컨텍스트 윈도우 계산은 다음과 같이 됩니다: context_window = input_tokens + current_turn_tokens.
- 시스템은 암호화 서명을 사용하여 사고 블록의 진정성을 확인합니다. 도구 사용 중에 사고 블록을 보존하지 못하면 Claude의 추론 연속성이 깨질 수 있습니다. 따라서 사고 블록을 수정하면 API가 오류를 반환합니다.

Claude 4 모델은 인터리브된 사고를 지원하므로, Claude가 도구 호출 사이에 생각하고 도구 결과를 받은 후 더 정교한 추론을 할 수 있습니다.

Claude Sonnet 3.7은 인터리브된 사고를 지원하지 않으므로, 비tool_result 사용자 턴이 없으면 확장된 사고와 도구 호출의 인터리빙이 없습니다.

도구를 사용한 확장된 사고 사용에 대한 자세한 정보는 확장된 사고 가이드를 참조하세요.

Claude Mythos Preview, Claude Opus 4.7, Claude Opus 4.6, 및 Claude Sonnet 4.6은 1M 토큰 컨텍스트 윈도우를 가집니다. Claude Sonnet 4.5 및 Sonnet 4(더 이상 사용되지 않음)를 포함한 다른 Claude 모델은 200k 토큰 컨텍스트 윈도우를 가집니다.

단일 요청은 최대 600개의 이미지 또는 PDF 페이지(200k 토큰 컨텍스트 윈도우가 있는 모델의 경우 100개)를 포함할 수 있습니다. 많은 이미지나 큰 문서를 보낼 때, 토큰 제한 전에 요청 크기 제한에 접근할 수 있습니다.

Claude Sonnet 4.6, Sonnet 4.5, 및 Haiku 4.5의 컨텍스트 인식

Claude Sonnet 4.6, Claude Sonnet 4.5, 및 Claude Haiku 4.5는 컨텍스트 인식 기능을 갖추고 있습니다. 이 기능을 통해 이러한 모델은 대화 전체에서 남은 컨텍스트 윈도우(즉, "토큰 예산")를 추적할 수 있습니다. 이를 통해 Claude는 작업을 실행하고 남은 공간이 얼마나 되는지 이해함으로써 컨텍스트를 더 효과적으로 관리할 수 있습니다. Claude는 남은 토큰이 몇 개인지 추측하기보다는 작업이 끝날 때까지 이 컨텍스트를 정확하게 사용하도록 학습되었습니다. 모델의 경우, 컨텍스트 인식이 없는 것은 시계 없이 요리 쇼에서 경쟁하는 것과 같습니다. Claude 4.5+ 모델은 모델에 남은 컨텍스트를 명시적으로 알려줌으로써 이를 변경하므로 사용 가능한 토큰을 최대한 활용할 수 있습니다.

작동 방식:

대화 시작 시, Claude는 총 컨텍스트 윈도우에 대한 정보를 받습니다:

<budget:token_budget>1000000</budget:token_budget>

예산은 1M 토큰(더 작은 컨텍스트 윈도우가 있는 모델의 경우 200k)으로 설정됩니다.

각 도구 호출 후, Claude는 남은 용량에 대한 업데이트를 받습니다:

<system_warning>Token usage: 35000/1000000; 965000 remaining</system_warning>

이 인식은 Claude가 작업을 위해 남은 용량이 얼마나 되는지 결정하는 데 도움이 되며 장기 실행 작업에서 더 효과적인 실행을 가능하게 합니다. 이미지 토큰은 이러한 예산에 포함됩니다.

이점:

컨텍스트 인식은 특히 다음에 유용합니다:

지속적인 집중이 필요한 장기 실행 에이전트 세션
상태 전환이 중요한 다중 컨텍스트 윈도우 워크플로우
신중한 토큰 관리가 필요한 복잡한 작업

여러 세션에 걸친 에이전트의 경우, 새 세션이 시작될 때 컨텍스트 복구가 빠르도록 상태 아티팩트를 설계하세요. 메모리 도구의 다중 세션 패턴은 구체적인 접근 방식을 설명합니다. 장기 실행 에이전트를 위한 효과적인 하네스도 참조하세요.

컨텍스트 인식을 활용하기 위한 프롬프팅 지침은 프롬프팅 모범 사례 가이드를 참조하세요.

압축을 사용한 컨텍스트 관리

대화가 정기적으로 컨텍스트 윈도우 제한에 접근하는 경우, 서버 측 압축이 권장되는 접근 방식입니다. 압축은 대화의 초기 부분을 자동으로 압축하는 서버 측 요약을 제공하므로, 최소한의 통합 작업으로 컨텍스트 제한을 초과하는 장기 실행 대화를 가능하게 합니다. 현재 Claude Opus 4.7, Claude Opus 4.6, 및 Claude Sonnet 4.6에 대해 베타로 사용 가능합니다.

더 특화된 요구사항의 경우, 컨텍스트 편집은 추가 전략을 제공합니다:

도구 결과 삭제 - 에이전트 워크플로우에서 오래된 도구 결과 삭제
사고 블록 삭제 - 확장된 사고를 사용한 사고 블록 관리

다음 단계

압축

장기 실행 대화에서 컨텍스트를 관리하기 위한 권장 전략입니다.

컨텍스트 편집

도구 결과 삭제 및 사고 블록 삭제와 같은 세밀한 전략입니다.

모델 비교 표

모델별 컨텍스트 윈도우 크기 및 입력/출력 토큰 가격의 목록을 보려면 모델 비교 표를 참조하세요.

컨텍스트 윈도우 이해하기

확장된 사고를 사용한 컨텍스트 윈도우

확장된 사고와 도구 사용을 사용한 컨텍스트 윈도우

Claude Sonnet 4.6, Sonnet 4.5, 및 Haiku 4.5의 컨텍스트 인식

압축을 사용한 컨텍스트 관리

최신 Claude 모델을 사용한 컨텍스트 윈도우 관리

다음 단계