Messages컨텍스트 관리

컨텍스트 윈도우

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

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

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

컨텍스트 윈도우 이해하기

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

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

긴 컨텍스트가 왜 저하되는지와 이를 해결하기 위한 엔지니어링 방법에 대한 심층적인 내용은 Effective context engineering을 참조하세요.

아래 다이어그램은 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 메시지까지 추가 확장 사고 없음).
- 토큰 계산: 모든 입력 및 출력 구성 요소가 컨텍스트 윈도우에 포함되며, 모든 출력 구성 요소는 출력 토큰으로 청구됩니다.
새로운 사용자 턴 (턴 3)
- 입력 구성 요소: 이전 턴의 모든 입력과 출력이 전달되지만, 사고 블록은 예외입니다. Claude가 전체 도구 사용 주기를 완료했으므로 이제 사고 블록을 제거할 수 있습니다. 사고 블록을 다시 전달하면 API가 자동으로 제거하거나, 이 단계에서 직접 제거해도 됩니다. 여기에서 다음 user 턴을 추가합니다.
- 출력 구성 요소: 도구 사용 주기 외부에 새로운 user 턴이 있으므로 Claude는 새로운 확장 사고 블록을 생성하고 거기서부터 계속 진행합니다.
- 토큰 계산: 이전 사고 토큰은 컨텍스트 윈도우 계산에서 자동으로 제거됩니다. 다른 모든 이전 블록은 여전히 토큰 윈도우의 일부로 계산되며, 현재 assistant 턴의 사고 블록은 컨텍스트 윈도우의 일부로 계산됩니다.

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

Claude 4 모델은 인터리브 사고를 지원하며, 이를 통해 Claude는 도구 호출 사이에 사고하고 도구 결과를 받은 후 더 정교한 추론을 수행할 수 있습니다.

확장 사고와 함께 도구를 사용하는 방법에 대한 자세한 내용은 확장 사고 가이드를 참조하세요.

Claude의 도구 선택은 대규모 입력 문서에서도 유지되도록 설계되어, 대화에 100K 이상의 비도구 컨텍스트 토큰이 포함되어 있을 때도 올바른 도구를 선택하거나 올바르게 사용을 자제합니다. 도구 자체가 소비하는 컨텍스트를 줄이려면 도구 컨텍스트 관리를 참조하거나, 도구 검색 도구를 사용하여 도구 정의를 지연시키세요.

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는 컨텍스트 인식 기능을 제공합니다. 이 기능을 통해 이러한 모델은 대화 전반에 걸쳐 남은 컨텍스트 윈도우(즉, "토큰 예산")를 추적할 수 있습니다. 이를 통해 Claude는 작업할 수 있는 공간이 얼마나 남았는지 이해함으로써 작업을 실행하고 컨텍스트를 더 효과적으로 관리할 수 있습니다. Claude는 남은 토큰 수를 추측하는 대신 이 컨텍스트를 정확하게 사용하여 작업이 끝날 때까지 지속하도록 학습되었습니다. 모델에게 컨텍스트 인식이 없다는 것은 시계 없이 요리 경연 대회에 참가하는 것과 같습니다. 컨텍스트 인식 모델은 남은 컨텍스트에 대한 정보를 명시적으로 받음으로써 이를 변화시켜, 사용 가능한 토큰을 최대한 활용할 수 있습니다.

작동 방식:

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

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

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

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

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

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

이점:

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

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

여러 세션에 걸쳐 실행되는 에이전트의 경우, 새 세션이 시작될 때 컨텍스트 복구가 빠르도록 상태 아티팩트를 설계하세요. 메모리 도구의 멀티 세션 패턴에서 구체적인 접근 방식을 안내합니다. Effective harnesses for long-running agents도 참조하세요.

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

압축을 통한 컨텍스트 관리

대화가 정기적으로 컨텍스트 윈도우 한계에 근접하는 경우, 서버 측 압축이 권장되는 접근 방식입니다. 압축은 대화의 이전 부분을 자동으로 요약하는 서버 측 요약 기능을 제공하여, 최소한의 통합 작업으로 컨텍스트 한계를 넘어서는 장기 실행 대화를 가능하게 합니다. 이 기능은 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에서 베타로 제공됩니다.

보다 특수한 요구 사항이 있는 경우, 컨텍스트 편집은 추가 전략을 제공합니다:

도구 결과 지우기 - 에이전트 워크플로우에서 오래된 도구 결과 지우기
사고 블록 지우기 - 확장 사고에서 사고 블록 관리

컨텍스트 윈도우 오버플로우 동작

Claude 4.5 모델 이상에서는 입력 토큰과 max_tokens의 합이 컨텍스트 윈도우 크기를 초과하더라도 API가 요청을 수락합니다. 이후 생성이 컨텍스트 윈도우 한계에 도달하면 stop_reason: "model_context_window_exceeded"와 함께 중지됩니다. 이전 모델에서는 API가 대신 유효성 검사 오류를 반환합니다. model-context-window-exceeded-2025-08-26 베타 헤더를 사용하여 model_context_window_exceeded 동작을 선택할 수 있습니다. 자세한 내용은 중지 이유 처리를 참조하세요.

컨텍스트 윈도우 한계 내에 머물려면 Claude에 메시지를 보내기 전에 토큰 계산 API를 사용하여 토큰 사용량을 추정하세요.

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

다음 단계

압축

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

컨텍스트 편집

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

모델 비교 표

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

확장 사고 개요

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

Was this page helpful?

Messages컨텍스트 관리

컨텍스트 윈도우

컨텍스트 윈도우 이해하기

긴 컨텍스트가 왜 저하되는지와 이를 해결하기 위한 엔지니어링 방법에 대한 심층적인 내용은 Effective context engineering을 참조하세요.

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

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

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

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

확장 사고와 컨텍스트 윈도우

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

확장 사고가 포함된 컨텍스트 윈도우 다이어그램

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

이 아키텍처는 토큰 효율적이며, 사고 블록이 상당히 길 수 있기 때문에 토큰 낭비 없이 광범위한 추론을 가능하게 합니다.

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

확장 사고 및 도구 사용과 컨텍스트 윈도우

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

확장 사고 및 도구 사용이 포함된 컨텍스트 윈도우 다이어그램

첫 번째 턴 아키텍처
- 입력 구성 요소: 도구 구성 및 사용자 메시지
- 출력 구성 요소: 확장 사고 + 텍스트 응답 + 도구 사용 요청
- 토큰 계산: 모든 입력 및 출력 구성 요소가 컨텍스트 윈도우에 포함되며, 모든 출력 구성 요소는 출력 토큰으로 청구됩니다.
도구 결과 처리 (턴 2)
- 입력 구성 요소: 첫 번째 턴의 모든 블록과 tool_result. 확장 사고 블록은 반드시 해당 도구 결과와 함께 반환되어야 합니다. 이는 사고 블록을 반드시 반환해야 하는 유일한 경우입니다.
- 출력 구성 요소: 도구 결과가 Claude에 다시 전달된 후, Claude는 텍스트로만 응답합니다(인터리브 사고가 활성화되지 않은 경우, 다음 user 메시지까지 추가 확장 사고 없음).
- 토큰 계산: 모든 입력 및 출력 구성 요소가 컨텍스트 윈도우에 포함되며, 모든 출력 구성 요소는 출력 토큰으로 청구됩니다.
새로운 사용자 턴 (턴 3)
- 입력 구성 요소: 이전 턴의 모든 입력과 출력이 전달되지만, 사고 블록은 예외입니다. Claude가 전체 도구 사용 주기를 완료했으므로 이제 사고 블록을 제거할 수 있습니다. 사고 블록을 다시 전달하면 API가 자동으로 제거하거나, 이 단계에서 직접 제거해도 됩니다. 여기에서 다음 user 턴을 추가합니다.
- 출력 구성 요소: 도구 사용 주기 외부에 새로운 user 턴이 있으므로 Claude는 새로운 확장 사고 블록을 생성하고 거기서부터 계속 진행합니다.
- 토큰 계산: 이전 사고 토큰은 컨텍스트 윈도우 계산에서 자동으로 제거됩니다. 다른 모든 이전 블록은 여전히 토큰 윈도우의 일부로 계산되며, 현재 assistant 턴의 사고 블록은 컨텍스트 윈도우의 일부로 계산됩니다.

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

Claude 4 모델은 인터리브 사고를 지원하며, 이를 통해 Claude는 도구 호출 사이에 사고하고 도구 결과를 받은 후 더 정교한 추론을 수행할 수 있습니다.

확장 사고와 함께 도구를 사용하는 방법에 대한 자세한 내용은 확장 사고 가이드를 참조하세요.

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

작동 방식:

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

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

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

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

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

이점:

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

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

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

압축을 통한 컨텍스트 관리

보다 특수한 요구 사항이 있는 경우, 컨텍스트 편집은 추가 전략을 제공합니다:

도구 결과 지우기 - 에이전트 워크플로우에서 오래된 도구 결과 지우기
사고 블록 지우기 - 확장 사고에서 사고 블록 관리

컨텍스트 윈도우 오버플로우 동작

컨텍스트 윈도우 한계 내에 머물려면 Claude에 메시지를 보내기 전에 토큰 계산 API를 사용하여 토큰 사용량을 추정하세요.

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

다음 단계

압축

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

컨텍스트 편집

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

모델 비교 표

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

확장 사고 개요

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

Was this page helpful?

컨텍스트 윈도우 이해하기

확장 사고와 컨텍스트 윈도우

확장 사고 및 도구 사용과 컨텍스트 윈도우

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

압축을 통한 컨텍스트 관리

컨텍스트 윈도우 오버플로우 동작

다음 단계

컨텍스트 윈도우 이해하기

확장 사고와 컨텍스트 윈도우

확장 사고 및 도구 사용과 컨텍스트 윈도우

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

압축을 통한 컨텍스트 관리

컨텍스트 윈도우 오버플로우 동작

다음 단계

컨텍스트 윈도우 이해하기

확장 사고와 컨텍스트 윈도우

확장 사고 및 도구 사용과 컨텍스트 윈도우

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

압축을 통한 컨텍스트 관리

컨텍스트 윈도우 오버플로우 동작

다음 단계

컨텍스트 윈도우 이해하기

확장 사고와 컨텍스트 윈도우

확장 사고 및 도구 사용과 컨텍스트 윈도우

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

압축을 통한 컨텍스트 관리

컨텍스트 윈도우 오버플로우 동작

다음 단계