Claude 컨텍스트 윈도우 완벽 가이드
공식 문서만 봐서는 모르는 실전 토큰 관리법 — 에이전트가 실제로 어떻게 동작하는지, 어떤 원리로 토큰이 소비되는지, 그리고 비용을 87%까지 절감하는 전략까지 총정리
목차
01. 컨텍스트 윈도우란 무엇인가?
Claude를 포함한 대규모 언어 모델(LLM)에는 "컨텍스트 윈도우"라는 핵심 개념이 있습니다. 이것은 모델이 응답을 생성할 때 참조할 수 있는 모든 텍스트의 총량을 의미합니다. 응답 자체도 포함됩니다.
쉽게 비유하면, 컨텍스트 윈도우는 모델의 "작업 메모리"입니다. 사람이 책상 위에 올려놓을 수 있는 서류의 총량이 한정되어 있는 것처럼, Claude도 한 번에 처리할 수 있는 텍스트 양에 한계가 있습니다. 이것은 모델이 학습한 대규모 데이터(지식 자체)와는 완전히 다른 개념입니다. 학습 데이터는 "장기 기억", 컨텍스트 윈도우는 "단기 기억(작업 메모리)"이라고 생각하면 됩니다.
- 시스템 프롬프트 (System Prompt)
- 이전 대화 기록 전체 (모든 턴의 User + Assistant 메시지)
- 현재 사용자 메시지
- 도구(Tool) 정의 및 도구 결과
- Claude의 응답 (출력 토큰)
- 확장된 사고(Extended Thinking) 블록 (해당 턴에서만)
현재 Claude의 기본 컨텍스트 윈도우는 200,000 토큰(약 15만 단어, 68만 유니코드 문자)이며, 베타 기능으로 최대 1,000,000 토큰까지 확장 가능합니다. 200K 토큰은 일반적인 소설 한 권(약 7~8만 단어)의 2배 분량을 한 번에 처리할 수 있는 크기입니다.
아래 다이어그램은 공식 문서에서 제공하는 컨텍스트 윈도우의 동작 구조를 재현한 것입니다. 턴이 진행될수록 Input 영역이 점점 커지는 것에 주목하세요. 이전 대화가 모두 누적되기 때문입니다.
[ 공식 문서 기반 — 컨텍스트 윈도우 구조: Turn이 진행될수록 Input에 이전 대화가 누적 ]
Turn 1에서는 User message 하나만 Input이지만, Turn 3에서는 Turn 1~2의 모든 User message + Text response가 전부 Input에 포함됩니다. 이것이 바로 토큰 비용이 선형적으로 증가하는 근본 원인입니다.
[ 기본 API 호출 시 토큰 사용량 확인 — 단일 요청에서 입력/출력 토큰이 어떻게 집계되는지 ]
위 스크린샷에서 보듯, 단순한 질문 하나에도 입력 24토큰 + 출력 187토큰 = 총 211토큰이 소비됩니다. 200,000 토큰 중 겨우 0.1%이지만, 대화가 길어지면 이 숫자가 기하급수적으로 늘어나는 것이 핵심입니다.
02. 에이전트는 실제로 어떻게 동작하는가?
요즘 화제인 "AI 에이전트"가 내부적으로 어떻게 동작하는지, 대부분의 사용자는 잘 모릅니다. 공식 문서를 읽어봐도 추상적인 설명이 대부분이죠. 실제 동작 원리를 컨텍스트 윈도우 관점에서 분해해보겠습니다.
에이전트의 기본 루프
Claude 기반 에이전트는 기본적으로 다음과 같은 반복 루프로 동작합니다:
겉보기에는 단순해 보이지만, 핵심은 매 단계마다 이전 대화 전체가 다시 전송된다는 점입니다. Claude API는 "상태를 유지하지 않는(stateless)" 구조이기 때문에, 매 요청마다 처음부터 전체 대화 기록을 보내야 합니다.
에이전트가 도구를 10번 호출하면, 시스템 프롬프트 + 도구 정의 + 모든 이전 대화가 10번 반복 전송됩니다. 1턴의 응답이 500토큰이라면, 10턴 시점에서는 이전 응답만 합쳐도 5,000토큰 이상이 매번 입력으로 들어가는 것입니다.
에이전트 아키텍처의 핵심: Stateless API
Claude API는 웹의 HTTP 프로토콜처럼 각 요청이 독립적입니다. 서버 측에 "이전 대화를 기억하는" 세션이 없습니다. 따라서 개발자(또는 에이전트 프레임워크)가 메시지 배열을 직접 관리하고, 매 요청마다 전체 대화 기록을 함께 보내야 합니다.
# 에이전트의 실제 동작 (의사 코드)
messages = []
while not task_complete:
# 1. 전체 대화 기록 + 새 메시지를 함께 전송
response = claude.messages.create(
model="claude-opus-4-6",
messages=messages, # ← 매번 전체 기록!
tools=tool_definitions # ← 매번 도구 정의도!
)
# 2. 도구 호출이 필요하면 실행
if response.stop_reason == "tool_use":
tool_result = execute_tool(response)
messages.append(response) # 응답 추가
messages.append(tool_result) # 도구 결과 추가
# → 다시 루프 (messages가 점점 커짐!)
# 3. 완료되면 최종 응답 반환
else:
return response.text이 구조를 이해하면, 왜 컨텍스트 윈도우 관리가 비용과 성능 모두에 결정적인지 알 수 있습니다. 에이전트가 많은 도구를 호출할수록, 매 요청의 입력 토큰이 선형적으로 증가하고, 그것이 곧 비용 증가로 이어집니다.
03. 멀티턴 대화의 토큰 누적 원리
컨텍스트 윈도우에서 가장 중요하지만 많은 사람이 간과하는 것이 바로 토큰 누적 패턴입니다. 공식 문서에서 "선형 성장 패턴"이라고 표현한 것의 실체를 직접 확인해봤습니다.
[ 5턴 대화에서 입력 토큰이 턴마다 누적 증가하는 모습 ]
위 테스트 결과를 보면 패턴이 명확합니다. 턴 1에서 12토큰이었던 입력이, 턴 5에서는 2,340토큰으로 약 200배 증가했습니다. 이는 이전 대화 전체가 매번 입력으로 포함되기 때문입니다.
[ 턴별 누적 토큰 증가를 차트로 시각화 — 선형을 넘어 가속 증가하는 패턴 ]
턴 N의 입력 토큰 = 시스템 프롬프트 + 도구 정의 + (턴 1~N-1의 모든 메시지) + 현재 메시지이것이 바로 "대화를 길게 하면 비용이 기하급수적으로 늘어나는" 이유입니다. 10턴 대화에서 턴 1의 응답은 10번 중복 전송되고, 10번 모두 입력 토큰으로 과금됩니다.
실제 운영에서 이 패턴이 의미하는 것은 명확합니다. 30턴짜리 코드 리뷰 대화를 Sonnet 4.5로 진행하면, 단순 누적만으로도 총 입력 토큰이 200만을 넘기 쉽습니다. 여기에 도구 사용까지 더하면 비용이 눈덩이처럼 불어납니다.
이것이 바로 제가 Anthropic 공식 문서를 꼼꼼히 읽고, 컨텍스트 관리 전략을 적극 활용하는 이유입니다. 원리를 알면 토큰도 아끼고, 딱 필요한 일만 시킬 수 있습니다.
04. 확장된 사고(Extended Thinking)의 토큰 마법
Claude의 확장된 사고(Extended Thinking) 기능은 복잡한 문제를 풀 때 모델이 "생각하는 과정"을 거치게 합니다. 이 사고 과정은 때로 수천 토큰에 달하는데, 여기서 Anthropic이 설계한 영리한 토큰 관리 메커니즘이 작동합니다.
사고 블록 자동 제거
핵심 원리는 이것입니다: 이전 턴의 사고(thinking) 블록은 다음 턴에서 자동으로 제거됩니다. Claude API가 대화 기록을 다시 받을 때, 이전 턴의 사고 블록을 자동으로 제외하는 것입니다.
아래 공식 문서 기반 다이어그램을 보면 이 메커니즘이 명확하게 보입니다. Turn 1에서 생성된 Extended thinking 블록이 Turn 2의 Input에는 포함되지 않고, Turn 2에서 생성된 것도 Turn 3의 Input에서 빠져 있습니다.
[ 공식 문서 기반 — 확장된 사고 컨텍스트 윈도우: 이전 턴의 thinking 블록이 자동 제거되는 구조 ]
다이어그램에서 빨간색으로 "thinking 자동 제거!"라고 표시된 부분을 주목하세요. Turn 2의 Input에서 Turn 1의 Extended thinking이 빠져 있고, Turn 3의 Input에서는 Turn 1, 2의 thinking이 모두 빠져 있습니다. 이것이 실제로 어떤 효과를 만드는지 터미널에서 확인해보겠습니다.
[ Extended Thinking의 사고 블록이 다음 턴에서 자동 제거되어 88% 토큰 절감 ]
위 테스트에서 3턴 동안 총 7,937토큰의 사고 블록이 생성되었지만, 실제 3번째 턴의 입력에는 726토큰만 포함되었습니다. 사고 블록이 자동 제거되지 않았다면 6,229토큰이 추가로 필요했을 것이고, 이는 88.3%의 토큰 절감에 해당합니다.
유효 컨텍스트 = (입력 토큰 - 이전 사고 토큰) + 현재 턴 토큰사고 토큰은 생성 시 한 번만 출력 토큰으로 과금되고, 이후 턴에서는 자동 제거되어 입력 토큰에 포함되지 않습니다. 이 아키텍처 덕분에 토큰 낭비 없이 깊은 추론이 가능합니다.
도구 사용과 사고 블록의 특수 규칙
단, 한 가지 중요한 예외가 있습니다. 도구 결과(tool_result)를 전달할 때는 해당 도구 요청에 수반된 사고 블록을 반드시 함께 반환해야 합니다. 이것은 Claude가 도구를 왜 호출했는지의 추론 맥락을 유지하기 위한 것입니다.
시스템은 암호화 서명을 사용하여 사고 블록의 진위를 확인합니다. 사고 블록을 수정하면 API가 오류를 반환하므로, 반드시 원본 그대로 전달해야 합니다. 도구 사용 주기가 완료된 후 새로운 User 턴이 시작되면, 그때부터 이전 사고 블록은 안전하게 제거됩니다.
참고로 Claude 4 모델들은 인터리브 사고(Interleaved Thinking)도 지원하여, 도구 호출 사이사이에 추가적인 사고를 할 수 있습니다. Claude Sonnet 3.7에서는 이 기능이 지원되지 않으므로, 모델 선택 시 이 점도 고려할 필요가 있습니다.
05. 도구 사용(Tool Use) 시 컨텍스트 변화
에이전트의 핵심 기능인 도구 사용은 컨텍스트 윈도우에 상당한 영향을 미칩니다. 도구 정의 자체가 매 요청마다 포함되고, 도구 호출/결과도 대화 기록에 누적되기 때문입니다.
[ 도구 사용 시 컨텍스트 윈도우에 포함되는 요소들 — 도구 정의, 호출, 결과의 토큰 추적 ]
도구 사용 시 컨텍스트 구성을 단계별로 살펴보면 다음과 같습니다.
첫 번째 턴 (사용자 요청 + 도구 호출)
입력에는 도구 정의(1,245 토큰), 시스템 프롬프트(380 토큰), 사용자 메시지(18 토큰)가 포함됩니다. 총 1,643 토큰. 여기서 주목할 점은 도구를 3개만 정의해도 1,245 토큰이 소비된다는 것입니다. 도구가 10개, 20개로 늘어나면 매 요청마다 수천 토큰이 도구 정의에만 쓰이게 됩니다.
도구 결과 전달 (두 번째 턴)
이전 대화(1,643 + 156 토큰) + 도구 결과(234 토큰)가 입력으로 들어갑니다. 그리고 확장된 사고를 사용했다면, 이 시점에서는 사고 블록도 반드시 포함해야 합니다. 이것이 유일하게 사고 블록을 반드시 반환해야 하는 경우입니다.
세 번째 턴 (새 사용자 메시지)
도구 사용 주기가 완료되었으므로, 이전 사고 블록(2,100 토큰)이 자동 제거됩니다. 유효 입력이 4,233에서 2,489 토큰으로 줄어드는 것을 확인할 수 있습니다.
도구 정의는 매 요청마다 전송되므로, 불필요하게 긴 설명이나 사용하지 않을 도구는 과감히 제거하세요. 도구 10개의 정의가 총 5,000토큰이라면, 20턴 대화에서만 100,000토큰(전체의 50%)이 도구 정의에 소비됩니다.
06. 모델별 비교 — 어떤 모델을 언제 쓸까?
Anthropic은 현재 세 가지 최신 모델 라인업을 제공합니다. 각 모델의 특성을 정확히 이해하면, 작업별로 최적의 모델을 선택하여 비용을 크게 줄일 수 있습니다.
| 기능 | Claude Opus 4.6 | Claude Sonnet 4.5 | Claude Haiku 4.5 |
|---|---|---|---|
| 포지셔닝 | 가장 지능적 (에이전트/코딩) | 속도 + 지능 최적 조합 | 가장 빠른 모델 |
| 가격 (입력) | $5 / MTok | $3 / MTok | $1 / MTok |
| 가격 (출력) | $25 / MTok | $15 / MTok | $5 / MTok |
| 컨텍스트 윈도우 | 200K / 1M(베타) | 200K / 1M(베타) | 200K |
| 최대 출력 | 128K 토큰 | 64K 토큰 | 64K 토큰 |
| 확장 사고 | 지원 (적응형 포함) | 지원 | 지원 |
| 지연 시간 | 보통 | 빠름 | 가장 빠름 |
| 지식 기준일 | 2025년 5월 | 2025년 1월 | 2025년 2월 |
[ 동일 프롬프트에 대한 모델별 비용 비교 — Haiku는 Opus 대비 약 1/10 비용 ]
모델 선택 전략
Opus 4.6 — 복잡한 추론, 에이전트 구축
가장 비싸지만 가장 똑똑합니다. 복잡한 코드 리팩토링, 아키텍처 설계, 멀티스텝 에이전트 작업처럼 추론 능력이 결정적인 작업에 사용하세요. 적응형 사고(Adaptive Thinking)를 지원하는 유일한 모델이기도 합니다.
Sonnet 4.5 — 범용 개발 작업
대부분의 개발 작업에서 최적의 가성비를 제공합니다. 코드 작성, 리뷰, 일반적인 질의응답에 적합합니다. Opus의 60% 비용으로 상당히 높은 품질을 제공합니다.
Haiku 4.5 — 간단 작업, 대량 처리
분류, 요약, 간단한 코드 생성, 데이터 변환 등 비교적 단순한 작업에 최적입니다. Opus의 1/5 비용으로 충분히 좋은 결과를 제공합니다.
07. 토큰 카운팅 API — 보내기 전에 확인하자
토큰 관리에서 가장 실용적인 도구가 바로 Token Counting API입니다. 실제 메시지를 보내지 않고도, 해당 요청이 몇 토큰을 소비할지 미리 확인할 수 있습니다.
[ Token Counting API로 전송 전에 토큰 수를 미리 확인하는 모습 ]
# Token Counting API 실전 사용법
count = client.messages.count_tokens(
model="claude-sonnet-4-5",
messages=messages
)
remaining = 200000 - count.input_tokens
print(f"현재 입력 토큰: {count.input_tokens}")
print(f"남은 여유: {remaining} 토큰")
# 한계 근접 시 사전 조치
if count.input_tokens > 180000:
# 압축 실행 또는 오래된 메시지 제거
messages = apply_compaction(messages)
elif count.input_tokens > 150000:
# 경고 로그
logger.warning("컨텍스트 75% 사용 - 압축 준비")08. 컨텍스트 초과 시 무슨 일이 일어나는가?
Claude Sonnet 3.7 이후의 최신 모델에서는 컨텍스트 윈도우를 초과하면 자동 잘림(truncation) 없이 즉시 에러를 반환합니다. 이전 세대 모델에서는 입력을 자동으로 잘라서 처리했지만, 이로 인해 중요한 맥락이 누락되는 예측 불가능한 문제가 있었습니다.
[ 200K 토큰 초과 시 발생하는 에러 — 자동 잘림 없이 명확한 에러 반환 ]
위 테스트에서 볼 수 있듯, 214,032 토큰을 보내면 invalid_request_error와 함께 "prompt is too long: 214032 tokens > 200000 maximum"이라는 명확한 에러가 반환됩니다.
해결 전략은 세 가지입니다. 첫째, Token Counting API로 사전에 확인하여 한계에 도달하기 전에 조치합니다. 둘째, Compaction(압축) 기능으로 이전 대화를 요약하여 컨텍스트를 줄입니다. 셋째, 불필요한 도구 결과나 오래된 메시지를 수동으로 제거하는 컨텍스트 편집을 적용합니다.
09. Compaction(압축) — 장시간 대화의 비밀 무기
Compaction은 제가 가장 적극적으로 활용하는 기능입니다. 장시간 대화나 에이전트 워크플로에서 컨텍스트 한계에 도달했을 때, 이전 대화를 자동으로 요약하여 훨씬 적은 토큰으로 핵심 맥락을 유지합니다.
Compaction 동작 원리
압축이 활성화되면, API는 입력 토큰이 지정된 트리거 임계값(기본 150,000 토큰, 최소 50,000 토큰)을 초과하는지 감지합니다. 초과하면 현재 대화의 요약을 생성하고, 이 요약을 담은 compaction 블록을 반환합니다. 후속 요청에서 이 블록이 포함되면, API는 블록 이전의 모든 메시지를 자동으로 삭제하고 요약에서부터 대화를 이어갑니다.
[ 100K 트리거에서 압축 발동 — 103,892 토큰이 12,456 토큰으로 88% 압축 ]
Compaction 사용 코드
# Compaction 기본 사용법
response = client.beta.messages.create(
betas=["compact-2026-01-12"],
model="claude-opus-4-6",
max_tokens=4096,
messages=messages,
context_management={
"edits": [{
"type": "compact_20260112",
"trigger": {"type": "input_tokens", "value": 100000}
}]
}
)
# 응답을 그대로 추가하면 compaction 블록도 자동 포함
messages.append({"role": "assistant", "content": response.content})사용자 정의 요약 지침
기본 요약 프롬프트 대신 자신만의 지침을 제공할 수 있습니다. 예를 들어 코드 관련 작업이면 "코드 스니펫, 변수명, 기술적 결정을 중심으로 보존"하라고 지시할 수 있습니다. instructions 매개변수를 사용하면 기본 프롬프트를 완전히 대체하므로, 필요한 모든 지침을 포함해야 합니다.
pause_after_compaction — 세밀한 제어
pause_after_compaction: true로 설정하면, 압축 요약 생성 후 API가 일시 중지합니다. 이 시점에 개발자가 추가 콘텐츠(예: 최근 메시지 보존, 특정 지침)를 삽입한 후 이어갈 수 있습니다. 이것은 마지막 몇 턴의 상세 내용은 유지하면서 오래된 대화만 요약하고 싶을 때 매우 유용합니다.
시스템 프롬프트에
cache_control 중단점을 추가하면, 압축이 발생해도 시스템 프롬프트 캐시는 유효한 상태로 유지됩니다. 긴 시스템 프롬프트를 사용하는 경우, 이 조합으로 추가 비용을 크게 줄일 수 있습니다.
비용 추적 주의점
Compaction은 추가 샘플링 단계를 필요로 하며, 이 비용도 청구됩니다. API 응답의 usage.iterations 배열에서 각 반복의 사용량을 확인할 수 있습니다. 중요한 점은, 최상위 input_tokens와 output_tokens에는 압축 반복 사용량이 포함되지 않는다는 것입니다. 정확한 총 비용을 계산하려면 iterations 배열의 모든 항목을 합산해야 합니다.
# 압축 비용을 포함한 정확한 비용 계산
total_input = sum(i["input_tokens"] for i in response.usage.iterations)
total_output = sum(i["output_tokens"] for i in response.usage.iterations)
total_cost = (total_input * 5 + total_output * 25) / 1_000_000 # Opus 기준10. 컨텍스트 인식(Context Awareness) 기능
Claude Sonnet 4.5 이상 모델에서 지원하는 컨텍스트 인식 기능은 매우 흥미로운 메커니즘입니다. Claude가 대화 중 남은 컨텍스트 윈도우를 실시간으로 파악하여, 작업을 더 효과적으로 관리할 수 있게 합니다.
[ Context Awareness — Claude가 남은 토큰 예산을 실시간으로 인지하는 모습 ]
공식 문서에서 인상적인 비유를 사용했습니다: "모델에게 컨텍스트 인식이 없는 것은 시계 없이 요리 대회에 참가하는 것과 같습니다." 시간(토큰)이 얼마나 남았는지 모르면 계획을 세울 수 없죠. 컨텍스트 인식 덕분에 Claude는 "남은 토큰이 적으니 현재 작업을 마무리하자"와 같은 판단을 스스로 내릴 수 있습니다.
동작 방식
대화 시작 시 Claude는 <budget:token_budget>200000</budget:token_budget> 형태로 총 예산을 받고, 각 도구 호출 후에는 <system_warning>Token usage: 35000/200000; 165000 remaining</system_warning> 형태로 업데이트를 받습니다.
이 기능은 특히 장시간 실행되는 에이전트 세션, 다중 컨텍스트 윈도우 워크플로, 신중한 토큰 관리가 필요한 복잡한 작업에서 큰 차이를 만듭니다. 개발자가 별도의 토큰 관리 로직을 구현하지 않아도, 모델 자체가 남은 자원을 인식하고 행동을 조절합니다.
11. 실전 비용 최적화 전략
지금까지 배운 원리를 종합하면, 실제 운영에서 놀라운 수준의 비용 절감이 가능합니다. 30턴 코드 리뷰 대화를 시나리오로 각 전략의 효과를 비교해보겠습니다.
[ 전략별 비용 비교 — 전략 없음 $10.05 vs 모델 분리+압축 $1.23 (87.8% 절감) ]
전략 1: 확장 사고 자동 제거 활용
별도의 코드 수정 없이도 Claude API가 자동으로 이전 사고 블록을 제거합니다. 이것만으로 약 24.5% 비용 절감이 가능합니다. 확장 사고를 사용한다면, 이 혜택은 자동으로 적용됩니다.
전략 2: Compaction 적용
100K 토큰마다 압축을 발동시키면, 30턴 동안 약 3회의 압축이 발생합니다. 총 입력 토큰이 2,450,000에서 450,000으로 줄어들어 74.6% 비용 절감을 달성합니다. 압축 자체의 비용(약 120,000 토큰)을 포함해도 압도적인 절감입니다.
전략 3: 모델 분리 + Compaction (최적)
가장 강력한 전략입니다. 작업의 복잡도에 따라 모델을 분리합니다.
간단한 작업 (코드 포맷팅, 변수명 변경, 간단한 질문) → Haiku 4.5 ($1/MTok)
중간 작업 (코드 작성, 일반 리뷰) → Sonnet 4.5 ($3/MTok)
복잡한 추론 (아키텍처 설계, 버그 분석, 최적화) → Opus 4.6 ($5/MTok)
이 분리에 Compaction까지 적용하면 총 87.8% 비용 절감이 가능합니다!
12. 에이전트 워크플로 실전 적용
마지막으로, 앞서 배운 모든 전략을 종합한 실전 에이전트 워크플로의 동작을 살펴보겠습니다.
[ 에이전트 워크플로 전체 과정 — 도구 14회 호출, Compaction 적용으로 65% 비용 절감 ]
위 시나리오에서 코드 리뷰 에이전트는 파일 분석(5회) → 코드 수정(3회) → 테스트(2회) → 추가 수정+검색(5회) → 최종 리포트 생성의 과정을 거쳤습니다. 중간에 토큰이 112,300에 도달하자 Compaction이 자동 발동하여 18,500 토큰으로 압축했고, 최종 비용은 $1.474로 마무리되었습니다. 압축 없이 진행했다면 $4.230이었을 것이므로, 65.1%의 비용 절감을 달성한 것입니다.
내가 실전에서 적용하는 원칙
에이전트에게 명확하고 구체적인 지시를 내립니다. "코드를 개선해줘" 대신 "함수 X의 에러 핸들링을 추가하고, Y 변수의 타입을 string에서 number로 변경해줘"처럼. 모호한 지시는 불필요한 도구 호출과 사고를 유발하고, 그만큼 토큰이 낭비됩니다.
매 요청에서 어떤 정보가 반복 전송되는지 인지합니다. 시스템 프롬프트, 도구 정의, 이전 대화 전체가 매번 포함된다는 것을 알면, 시스템 프롬프트를 간결하게 유지하고, 도구 수를 최소화하고, 적절한 시점에 대화를 리셋하거나 압축하는 판단을 내릴 수 있습니다.
모든 작업에 Opus를 사용하는 것은 모든 이동에 택시를 타는 것과 같습니다. 간단한 이동은 버스(Haiku)로, 중거리는 지하철(Sonnet)로, 정말 중요한 곳만 택시(Opus)로. 이 전략만으로도 비용이 절반 이하로 줄어듭니다.
많은 개발자가 "요약하면 정보가 손실되지 않을까" 걱정하지만, Compaction의 요약 품질은 실전에서 충분히 우수합니다. 특히 사용자 정의 요약 지침을 활용하면, 작업에 정말 중요한 정보(코드 스니펫, 결정 사항, 남은 작업)를 선택적으로 보존할 수 있습니다. 중요한 것은 "모든 것을 기억하는 것"이 아니라 "필요한 것만 정확히 기억하는 것"입니다.
+ 1M 토큰 컨텍스트 윈도우 (베타)
Claude Opus 4.6과 Sonnet 4.5는 베타 기능으로 100만 토큰 컨텍스트 윈도우를 지원합니다. 이는 약 75만 단어, 340만 유니코드 문자에 해당하는 방대한 양입니다.
사용하려면 API 요청에 context-1m-2025-08-07 베타 헤더를 추가하면 됩니다. 단, 사용 티어 4 이상의 조직에서만 사용 가능하며, 200K 토큰을 초과하는 요청은 프리미엄 요금(입력 2배, 출력 1.5배)이 적용됩니다. 정말 필요한 경우에만 사용하되, Compaction과 병행하면 1M 컨텍스트의 이점을 비용 효율적으로 누릴 수 있습니다.
# 1M 컨텍스트 윈도우 사용
response = client.beta.messages.create(
model="claude-opus-4-6",
max_tokens=1024,
messages=[{"role": "user", "content": huge_document}],
betas=["context-1m-2025-08-07"]
)* 마치며
Claude의 컨텍스트 윈도우는 단순한 "크기 제한"이 아닙니다. 그 안에서 토큰이 어떻게 흐르고, 누적되고, 관리되는지를 이해하면, 같은 작업을 훨씬 적은 비용으로, 더 안정적으로 수행할 수 있습니다.
정리하면 핵심은 다음과 같습니다.
1) 매 요청마다 전체 대화 기록이 재전송된다는 것을 인지하세요. 이것이 비용의 근본 원인입니다.
2) 확장된 사고의 자동 제거 메커니즘을 활용하세요. 별도 코드 없이 자동으로 토큰이 절약됩니다.
3) Compaction은 장시간 대화의 필수 전략입니다. 88%까지 토큰을 압축할 수 있습니다.
4) Token Counting API로 사전에 토큰을 확인하세요. 예방이 치료보다 쉽습니다.
5) 작업 복잡도에 따라 모델을 분리하세요. 이것만으로 50% 이상 절감이 가능합니다.
6) 컨텍스트 인식 기능이 있는 Sonnet 4.5+ 모델을 활용하면, 모델 자체가 토큰 관리를 도와줍니다.
공식 문서는 필요한 정보가 모두 있지만, 실제로 읽는 사람이 많지 않습니다. 이 글이 여러분의 Claude API 활용과 비용 최적화에 실질적인 도움이 되었으면 합니다. 원리를 알면 토큰도 아끼고, 딱 필요한 일만 시킬 수 있습니다.
참고 문서 컨텍스트 윈도우 · 모델 개요 · 압축(Compaction)
'AI > Claude' 카테고리의 다른 글
| Claude Cowork Dispatch 사용 후기+ OpenClaw 비교 분석 (0) | 2026.03.24 |
|---|---|
| Claude Code Agent Teams vs Subagent 차이점 (1) | 2026.03.23 |
| Claude Pixel Agents Plugin: AI 에이전트를 픽셀 아트로 본다면? (0) | 2026.03.23 |
| Claude Cowork for Windows 실사용기 — 파일 327개 자동 정리, 이 정도면 쓸 만하다 🤔 (0) | 2026.03.19 |
| 나만의 Claude Skills 만들기— 설계부터 배포까지 완전 정복 (0) | 2026.03.19 |
