컨텍스트 윈도 이해하기

이 기능은 제로 데이터 보존(ZDR, Zero Data Retention) 대상입니다. 조직에 ZDR 계약이 적용되어 있다면, 이 기능을 통해 전송된 데이터는 API 응답이 반환된 이후 저장되지 않습니다.

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

장시간 이어지는 대화나 에이전트형 워크플로에서는 서버 측 컴팩션(compaction)이 컨텍스트 관리의 핵심 전략입니다. 더 특수한 요구 사항이 있다면, 컨텍스트 편집(context editing)이 도구 결과 비우기나 사고 블록 비우기 같은 추가 전략을 제공합니다.

컨텍스트 윈도 이해하기

"컨텍스트 윈도"란 언어 모델이 응답을 생성할 때 참조할 수 있는 모든 텍스트를 가리키며, 응답 자체도 여기에 포함됩니다. 이는 언어 모델이 학습한 방대한 데이터 말뭉치와는 다른 개념으로, 모델의 "작업 기억(working memory)"에 해당합니다. 컨텍스트 윈도가 클수록 모델은 더 복잡하고 긴 프롬프트를 다룰 수 있지만, 컨텍스트가 많다고 해서 무조건 더 좋은 것은 아닙니다. 토큰 수가 늘어날수록 정확도와 회상(recall) 성능이 저하되는데, 이를 컨텍스트 부패(context rot)라고 부릅니다. 그래서 컨텍스트에 무엇을 담느냐를 선별하는 일이, 가용 공간이 얼마나 되느냐만큼이나 중요합니다.

Claude는 MRCR, GraphWalks 같은 롱컨텍스트 검색 벤치마크에서 최고 수준의 성능을 달성하지만, 이러한 성과는 컨텍스트에 무엇이 들어 있느냐에 달려 있으며, 단순히 얼마나 많이 담기느냐에 달려 있는 것이 아닙니다.

긴 컨텍스트가 성능 저하를 일으키는 이유와 이를 우회하도록 설계하는 방법을 자세히 알고 싶다면, Effective context engineering 문서를 참고하세요.

아래 다이어그램은 API 요청에서의 표준적인 컨텍스트 윈도 동작을 보여줍니다.¹

¹claude.ai와 같은 채팅 인터페이스에서는 컨텍스트 윈도를 선입선출(first in, first out) 방식의 롤링 시스템으로 구성할 수도 있습니다.

점진적 토큰 누적: 대화가 여러 턴을 거치며 진행됨에 따라 각 사용자 메시지와 어시스턴트 응답이 컨텍스트 윈도 안에 누적됩니다. 이전 턴들은 온전히 보존됩니다.
선형 증가 패턴: 컨텍스트 사용량은 턴마다 선형으로 증가하며, 이전 턴들은 완전히 보존됩니다.
컨텍스트 윈도 용량: 전체 가용 컨텍스트 윈도(최대 1M 토큰)는 대화 기록을 저장하고 Claude가 새로운 출력을 생성하는 데 쓰이는 최대 용량을 나타냅니다.
입력-출력 흐름: 각 턴은 다음으로 구성됩니다.
입력 단계: 이전 대화 기록 전체와 현재 사용자 메시지를 포함합니다.
출력 단계: 텍스트 응답을 생성하며, 이 응답은 이후 입력의 일부가 됩니다.

확장 사고에서의 컨텍스트 윈도

확장 사고(extended thinking)를 사용할 때는 사고에 쓰인 토큰을 포함한 모든 입력 및 출력 토큰이 컨텍스트 윈도 한계에 포함되며, 멀티턴 상황에서는 몇 가지 미묘한 차이가 있습니다.

사고 예산 토큰은 max_tokens 파라미터의 일부이며, 출력 토큰으로 과금되고, 사용량 한도(rate limit)에 포함됩니다. 적응형 사고(adaptive thinking)를 사용하면 Claude가 사고에 할당할 양을 동적으로 결정하므로, 실제 사고 토큰 사용량은 요청마다 달라질 수 있습니다.

다만, 이전 사고 블록은 Claude API가 컨텍스트 윈도 계산에서 자동으로 제거하며, 이후 턴에서 모델이 "보는" 대화 기록에는 포함되지 않습니다. 덕분에 실제 대화 내용을 위한 토큰 용량이 보존됩니다.

아래 다이어그램은 확장 사고가 활성화되었을 때의 특수한 토큰 관리 방식을 보여줍니다.

확장 사고 제거: 확장 사고 블록(다이어그램에서 진한 회색으로 표시)은 각 턴의 출력 단계에서 생성되지만, 이후 턴의 입력 토큰으로는 이어지지 않습니다. 사고 블록을 직접 제거할 필요는 없습니다. 사고 블록을 그대로 다시 전달하면 Claude API가 자동으로 처리해 줍니다.
기술적 구현 세부 사항:
API는 대화 기록의 일부로 사고 블록을 다시 전달하더라도 이전 턴의 사고 블록을 자동으로 제외합니다.
확장 사고 토큰은 생성 시점에 단 한 번만 출력 토큰으로 과금됩니다.
실효 컨텍스트 윈도 계산식은 다음과 같습니다: context_window = (input_tokens - previous_thinking_tokens) + current_turn_tokens.
사고 토큰에는 thinking 블록이 포함됩니다.

이 구조는 토큰 효율적이며, 사고 블록은 분량이 상당히 길어질 수 있는데도 토큰 낭비 없이 폭넓은 추론을 가능하게 합니다.

컨텍스트 윈도와 확장 사고에 대한 자세한 내용은 확장 사고 가이드에서 확인할 수 있습니다.

확장 사고와 도구 사용을 함께 쓸 때의 컨텍스트 윈도

아래 다이어그램은 확장 사고와 도구 사용을 결합했을 때의 컨텍스트 윈도 토큰 관리 방식을 보여줍니다.

첫 번째 턴 구조

입력 구성 요소: 도구 설정(tools configuration)과 사용자 메시지
출력 구성 요소: 확장 사고 + 텍스트 응답 + 도구 사용 요청(tool use request)
토큰 계산: 모든 입력 및 출력 구성 요소가 컨텍스트 윈도에 포함되며, 모든 출력 구성 요소는 출력 토큰으로 과금됩니다.

도구 결과 처리 (턴 2)

입력 구성 요소: 첫 번째 턴의 모든 블록과 tool_result. 확장 사고 블록은 그에 대응하는 도구 결과와 함께 반드시 반환되어야 합니다. 사고 블록을 반드시 반환해야 하는 경우는 이때뿐입니다.
출력 구성 요소: 도구 결과가 Claude에게 다시 전달된 뒤, Claude는 텍스트만으로 응답합니다(추가 확장 사고 없음). 단, 다음 user 메시지가 오기 전까지는 그렇고, 인터리브 사고(interleaved thinking)가 활성화된 경우는 예외입니다.
토큰 계산: 모든 입력 및 출력 구성 요소가 컨텍스트 윈도에 포함되며, 모든 출력 구성 요소는 출력 토큰으로 과금됩니다.

새로운 사용자 턴 (턴 3)

입력 구성 요소: 이전 턴의 모든 입력과 출력이 그대로 이어지지만, 사고 블록은 예외입니다. Claude가 도구 사용 사이클 전체를 완료했으므로 이제 사고 블록은 제외할 수 있습니다. 사고 블록을 다시 전달하면 API가 자동으로 제거해 주며, 이 단계에서 직접 제거해도 무방합니다. 또한 이 지점이 다음 user 턴을 추가하는 곳이기도 합니다.
출력 구성 요소: 도구 사용 사이클 바깥에서 새로운 user 턴이 발생했으므로, Claude는 새로운 확장 사고 블록을 생성하고 거기서부터 이어 갑니다.
토큰 계산: 이전 사고 토큰은 컨텍스트 윈도 계산에서 자동으로 제거됩니다. 그 외 이전 블록들은 여전히 토큰 윈도의 일부로 포함되며, 현재 assistant 턴의 사고 블록도 컨텍스트 윈도에 포함됩니다.
확장 사고와 도구 사용을 함께 쓸 때의 고려 사항:
도구 결과를 전달할 때는 해당 도구 요청에 동반된 사고 블록 전체를(시그니처 부분 포함) 수정 없이 그대로 포함해야 합니다.
확장 사고와 도구 사용을 함께 쓸 때의 실효 컨텍스트 윈도 계산식은 다음과 같습니다: context_window = input_tokens + current_turn_tokens.
시스템은 암호화 시그니처를 사용해 사고 블록의 진위를 검증합니다. 도구 사용 중에 사고 블록을 보존하지 못하면 Claude의 추론 연속성이 끊길 수 있습니다. 따라서 사고 블록을 수정하면 API가 오류를 반환합니다.

Claude 4 모델들은 인터리브 사고(interleaved thinking)를 지원합니다. 이를 통해 Claude는 도구 호출 사이에 사고할 수 있고, 도구 결과를 받은 뒤 더 정교하게 추론할 수 있습니다.

확장 사고와 도구 사용에 대한 자세한 내용은 확장 사고 가이드를 참고하세요.

Claude의 도구 선택 능력은 대용량 입력 문서에서도 안정적으로 유지되도록 설계되어, 대화에 도구와 무관한 컨텍스트가 100K 토큰 이상 포함된 경우에도 올바른 도구를 선택하거나(또는 적절히 사용을 보류) 할 수 있습니다. 도구 자체가 소비하는 컨텍스트를 줄이려면 Manage tool context를 참고하거나, 도구 검색 도구(tool search tool)를 사용해 도구 정의를 지연 로드하세요.

Claude Opus 4.8, Claude Mythos Preview, Claude Opus 4.7, Claude Opus 4.6, Claude Sonnet 4.6은 Claude API, Amazon Bedrock, Vertex AI에서 1M 토큰 컨텍스트 윈도를 제공합니다. Microsoft Foundry에서는 Claude Opus 4.8이 200k 토큰 컨텍스트 윈도를 갖습니다. Claude Sonnet 4.5를 비롯한 그 밖의 Claude 모델들은 200k 토큰 컨텍스트 윈도를 갖습니다.

Claude Fable 5와 Claude Mythos 5(claude-fable-5, claude-mythos-5)는 Claude API에서 1M 토큰 컨텍스트 윈도를 제공합니다. 1M이 최댓값인 동시에 기본값이며, 단일 요청으로 최대 128k 출력 토큰(max_tokens)을 생성할 수 있습니다.

단일 요청에는 최대 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는 컨텍스트 인식(context awareness) 기능을 갖추고 있습니다. 이 기능을 통해 이들 모델은 대화 내내 남은 컨텍스트 윈도(즉 "토큰 예산")를 추적할 수 있습니다. 덕분에 Claude는 자신에게 남은 작업 공간이 얼마인지 파악하여, 작업을 수행하고 컨텍스트를 더 효과적으로 관리할 수 있습니다. Claude는 이 컨텍스트를 정밀하게 사용하도록 학습되어 있어, 남은 토큰이 얼마인지 추측하기보다 작업을 끝까지 끈기 있게 이어 갑니다. 모델 입장에서 컨텍스트 인식이 없다는 것은 시계 없이 요리 경연에 참가하는 것과 같습니다. 컨텍스트 인식 모델은 남은 컨텍스트에 대한 정보를 명시적으로 받음으로써 이 상황을 바꾸어, 가용 토큰을 최대한 활용할 수 있습니다.

작동 방식:

대화가 시작될 때 Claude는 자신의 전체 컨텍스트 윈도에 대한 정보를 받습니다.

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

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

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

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

이러한 인식 덕분에 Claude는 작업에 남은 용량이 얼마인지 판단할 수 있으며, 장시간 이어지는 작업을 더 효과적으로 수행할 수 있습니다. 이미지 토큰도 이 예산에 포함됩니다.

이점:

컨텍스트 인식은 특히 다음과 같은 경우에 유용합니다.

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

여러 세션에 걸쳐 작동하는 에이전트의 경우, 새 세션이 시작될 때 컨텍스트 복구가 빠르게 이루어지도록 상태 아티팩트(state artifact)를 설계하세요. memory 도구의 다중 세션 패턴이 구체적인 접근법을 단계별로 안내합니다. Effective harnesses for long-running agents 문서도 함께 참고하세요.

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

컴팩션으로 컨텍스트 관리하기

대화가 컨텍스트 윈도 한계에 자주 가까워진다면, 서버 측 컴팩션(server-side compaction)이 권장되는 방식입니다. 컴팩션은 대화의 앞부분을 자동으로 압축하는 서버 측 요약 기능을 제공하여, 최소한의 통합 작업만으로 컨텍스트 한계를 넘어서는 장시간 대화를 가능하게 합니다. 이 기능은 Claude Fable 5, Claude Mythos 5, Claude Opus 4.8, Claude Mythos Preview, Claude Opus 4.7, Claude Opus 4.6, Claude Sonnet 4.6에서 베타로 제공됩니다.

더 특수한 요구 사항이 있다면, 컨텍스트 편집(context editing)이 추가 전략을 제공합니다.

도구 결과 비우기(Tool result clearing) - 에이전트형 워크플로에서 오래된 도구 결과를 비웁니다.
사고 블록 비우기(Thinking block clearing) - 확장 사고를 사용할 때 사고 블록을 관리합니다.

컨텍스트 윈도 초과 동작

Claude 4.5 이상 모델에서는 입력 토큰과 max_tokens의 합이 컨텍스트 윈도 크기를 초과하더라도 API가 요청을 수락합니다. 이후 생성 과정에서 컨텍스트 윈도 한계에 도달하면 stop_reason: "model_context_window_exceeded"로 생성을 중단합니다. 이전 모델에서는 API가 대신 검증 오류를 반환합니다. model-context-window-exceeded-2025-08-26 베타 헤더를 통해 model_context_window_exceeded 동작을 선택적으로 적용할 수 있습니다. 자세한 내용은 Handling stop reasons를 참고하세요.

컨텍스트 윈도 한계 안에 머무르려면, 메시지를 Claude에 보내기 전에 토큰 카운팅 API(token counting API)로 토큰 사용량을 미리 추정하세요.

모델별 컨텍스트 윈도 크기 목록은 모델 비교 표를 참고하세요.

다음 단계

컴팩션

장시간 이어지는 대화에서 컨텍스트를 관리하는 권장 전략입니다.

컨텍스트 편집

도구 결과 비우기, 사고 블록 비우기 같은 세밀한 전략입니다.

모델 비교 표

모델별 컨텍스트 윈도 크기와 입력/출력 토큰 가격 목록은 모델 비교 표에서 확인하세요.

확장 사고 개요

확장 사고가 어떻게 작동하는지, 그리고 도구 사용이나 프롬프트 캐싱 같은 다른 기능과 함께 어떻게 구현하는지 알아보세요.