Claude Code v2.1.75+
Opus 4.6 기준
Claude Code 1M 컨텍스트,
켜지면 무조건 좋을까요?
2026년 3월 13일, Anthropic이 Claude Code의 1M 토큰 컨텍스트 윈도우를 정식 지원(GA)으로 전환했습니다. 추가 요금도 없고, Rate Limit 불이익도 없다는 발표였는데 — 막상 써보면 이 설명만으론 부족합니다.
MRCR 1M 점수
같은 테스트
응답 대기
1M 컨텍스트 정식 지원, 뭐가 달라졌나
2026년 3월 13일 이전까지 Claude Code에서 1M 컨텍스트를 쓰려면 anthropic-beta: context-1m-2025-08-07 헤더를 명시적으로 붙여야 했습니다. 게다가 200K 토큰을 넘으면 입력 요금이 2배로 뛰었습니다. Max 플랜 구독자라도 예외가 없었어요.
3월 13일 GA 전환으로 세 가지가 한꺼번에 바뀌었습니다.
| 변경 항목 | GA 이전 (베타) | GA 이후 (2026.03.13~) |
|---|---|---|
| Beta 헤더 | 필수 | 불필요 (자동 적용) |
| 200K 초과 요금 | 입력 2배, 출력 1.5배 | 표준 단가 동일 적용 |
| Rate Limit | 1M 전용 Rate Limit 별도 | 표준 계정 처리량 통합 |
기존 코드를 전혀 수정하지 않아도 됩니다. Claude Code v2.1.75 이상, Max·Team·Enterprise 플랜이면 Opus 4.6의 1M 컨텍스트가 자동 활성화됩니다. (출처: Anthropic 공식 Opus 4.6 발표, 2026.02.05 / GA 발표 분석, 2026.03.13)
💡 공식 발표문과 실제 적용 흐름을 함께 놓고 보면 — GA 이전 베타 시절에는 200K 초과 순간 비용이 급격히 올라가는 구조였습니다. 베타 기간에 1M을 써온 분들은 그 요금이 사라졌다는 게 가장 큰 변화입니다.
컨텍스트 창이 크다고 성능도 1M만큼 좋아지는 건 아닙니다
“1M이 됐으니 이제 뭐든 다 집어넣으면 되겠다” — 막상 벤치마크를 보면 이 생각이 흔들립니다.
Anthropic이 공식 발표에서 제시한 MRCR v2 8-needle 1M 벤치마크는 100만 토큰짜리 텍스트 안에 숨겨진 8개 정보를 찾아내는 테스트입니다. 결과는 이렇습니다:
| 모델 | 1M MRCR 점수 | 비고 |
|---|---|---|
| Claude Opus 4.6 | 76% | 프론티어 중 최고 |
| Gemini 3 Pro | 26.3% | Anthropic 측정 기준 |
| Claude Sonnet 4.5 | 18.5% | 1M 지원이지만 사실상 사용 불가 |
출처: Anthropic 공식 Opus 4.6 발표문 (2026.02.05)
Sonnet 4.5의 18.5%는 사실상 랜덤 수준입니다. 8개 중 1~2개를 찾는 정도. 1M 창이 열려 있어도 모델이 그 공간을 활용하는 능력이 없으면 의미가 없습니다.
실측 실험에서도 비슷한 패턴이 나왔습니다. Opus 4.6은 400K까지 완벽한 정보 검색을 보여줬지만, 600K에서 75% 위치에 심어놓은 정보를 일부 놓쳤습니다 — 이름은 맞는데 금액을 잘못 기억하거나, 관련 없는 항목에 연결하는 식으로요. (출처: Claude Code Camp 실측, 2026.03.13) 600K 이상에서 핵심 정보가 있다면 앞쪽이나 뒤쪽에 배치하는 것이 중간보다 훨씬 안전합니다.
💡 실측 실험과 공식 벤치마크를 나란히 놓으면 — Sonnet 4.6의 1M MRCR 수치는 아직 Anthropic이 공개하지 않은 부분입니다. Sonnet 4.5보다 나을 수 있지만, 장거리 검색이 핵심인 작업이라면 Opus 4.6을 쓰는 게 지금 기준으로 더 확실한 선택입니다.
요금 구조, 생각보다 단순하지 않습니다
“GA 전환으로 추가 요금 없다”는 발표를 보고 API 직접 사용자들이 안심하는 경우가 많은데, 여기에 중요한 단서가 붙습니다.
Claude Code 구독자 (Max·Team·Enterprise)
구독 플랜 사용량 한도 안에서 1M 컨텍스트를 추가 토큰 비용 없이 사용합니다. 단, Max 플랜의 Fast Mode는 구독 플랜에 포함되지 않고 별도 청구됩니다.
API 직접 사용자
공식 요금은 아래와 같습니다. (출처: Anthropic 공식 가격 문서)
| 모델 | 입력 단가 | 출력 단가 | 적용 범위 |
|---|---|---|---|
| Opus 4.6 | $5/MTok | $25/MTok | 전체 컨텍스트 동일 |
| Sonnet 4.6 | $3/MTok | $15/MTok | 전체 컨텍스트 동일 |
핵심은 이겁니다 — 900K 토큰 요청이나 9K 토큰 요청이나 토큰당 단가가 동일합니다. GA 이전 베타 시절에는 200K 초과 시 입력 요금이 2배($10/MTok)로 올랐습니다. 이 프리미엄 배율이 사라진 게 가장 큰 실질적 변화입니다.
💡 구독자 vs API 사용자 — 체감이 다른 이유
API를 직접 쓰는 개발자는 토큰 비용이 눈에 보입니다. 반면 Max 구독자는 월정액 안에서 사용량 한도만 신경 쓰면 됩니다. 같은 “1M GA”를 두고 체감이 크게 다른 이유가 여기 있습니다.
자리를 비우면 다시 30초 기다려야 하는 이유
대부분의 리뷰가 언급하지 않는 부분이 있습니다. 1M 컨텍스트 세션에서 잠시 자리를 비웠다 돌아오면, 다음 응답이 시작되기까지 한참 기다려야 할 수 있습니다.
원인은 Prompt Caching의 TTL(Time-to-Live)입니다. Claude Code는 컨텍스트를 GPU 메모리에 캐싱해두는데, 이 캐시는 5분이 지나면 만료됩니다. 캐시가 만료되면 다음 요청 시 모델이 전체 컨텍스트를 처음부터 다시 처리하는 “콜드 스타트”가 발생합니다.
실측 데이터를 보면 이렇습니다:
| 컨텍스트 크기 | 캐시 웜 (TTFT) | 콜드 스타트 (TTFT) |
|---|---|---|
| 50K 토큰 | 약 0.8초 | 약 2초 |
| 200K 토큰 | 약 1.6초 | 약 9초 |
| 500K 토큰 | 약 3.5초 | 약 35초 |
| 1M 토큰 (추정) | 약 5~7초 (추정) | 60~90초 (추정) |
출처: Claude Code Camp 실측 (2026.03.13) — 1M 콜드 스타트는 500K 기준 거듭제곱 추정치. 실제 값은 네트워크·서버 상황에 따라 다릅니다.
500K 세션에서 커피 한 잔 마시고 돌아오면 첫 응답까지 35초를 기다려야 합니다. 1M이라면 1분이 넘을 수 있습니다. 자주 자리를 비우는 작업 스타일이라면 1M 컨텍스트는 오히려 불편할 수 있습니다.
진짜 써야 할 상황 vs 안 써도 되는 상황
실측 데이터를 교차 분석해서 정리한 판단 기준입니다.
✅ 1M 컨텍스트가 실제로 도움 되는 상황
- 단발성 대규모 코드베이스 분석: 수백 개 파일을 한 번에 올려서 아키텍처를 파악하는 작업. 다중 턴 대화가 아니라 한 번에 넣고 분석하는 용도라면 “Context Rot”이 최소화됩니다.
- Compaction 없이 긴 디버깅 세션 유지: 에러 로그, 스택 트레이스, 관련 파일이 Compaction으로 날아가면 맥락을 잃는 작업에 유용합니다.
- 레거시 코드 전체 리팩터링: SentinelOne은 공식 파트너 후기에서 “다중 백만 줄 코드베이스 마이그레이션을 Opus 4.6이 시니어 엔지니어처럼 처리했다”고 밝혔습니다. (출처: Anthropic 공식 발표문)
- Agent Teams 작업: 여러 서브에이전트가 파일을 병렬로 읽고 결과를 통합할 때, 1M 컨텍스트가 누적 결과를 담는 공간이 됩니다.
❌ 1M을 켜도 체감 차이가 없거나 오히려 불편한 상황
- 일반 코딩 작업: 실측 데이터에서 대부분의 Claude Code 세션은 컨텍스트가 80~120K에서 Compaction을 맞이합니다. 200K는 물론 1M 근처에도 안 갑니다.
- 자리를 자주 비우는 환경: 5분마다 캐시가 날아갑니다. 멀티태스킹 중에 Claude Code를 쓴다면 콜드 스타트가 반복됩니다.
- Sonnet 4.5로 1M 사용: MRCR 18.5%라는 수치는 사실상 긴 컨텍스트를 제대로 읽지 못한다는 의미입니다. 이미 사라진 베타 시절 2배 요금을 냈다면 특히 손해였습니다.
결론적으로 — 50K짜리 컨텍스트에서 집중도 있게 작업하는 것이 500K 컨텍스트에서 주의가 분산된 채 작업하는 것보다 코딩 품질이 높은 경우가 많습니다. 창이 크다고 성능이 자동으로 올라가지 않습니다.
Claude Code에서 1M 설정하는 법 (명령어 포함)
Claude Code v2.1.75 이상, Max·Team·Enterprise 플랜이라면 이미 자동 활성화되어 있습니다. 세션 내에서 직접 전환하려면 이렇게 입력합니다:
# Opus 4.6 1M 모델로 전환
/model opus[1m]
# Sonnet 4.6 1M 모델로 전환 (추가 사용량 필요)
/model sonnet[1m]
# 현재 모델·컨텍스트 크기 확인
/model
# 버전 확인 (v2.1.75 이상인지 체크)
claude --version1M 컨텍스트를 비활성화하고 싶다면 환경변수로 끌 수 있습니다:
# 해당 세션만 비활성화
export CLAUDE_CODE_DISABLE_1M_CONTEXT=1
claude
# 영구 비활성화 (~/.claude/settings.json)
{
"env": {
"CLAUDE_CODE_DISABLE_1M_CONTEXT": "1"
}
}Compaction 임계값을 낮춰서 더 일찍 압축하고 싶다면:
# 700K 토큰에서 Compaction 발생 (기본 950K)
export CLAUDE_CODE_AUTO_COMPACT_WINDOW=700000
# settings.json에 영구 설정
{
"env": {
"CLAUDE_CODE_AUTO_COMPACT_WINDOW": "700000"
}
}💡 Opus vs Sonnet 선택 기준 (Anthropic 공식 권장)
Anthropic 공식 권장 전략은 Sonnet 4.6으로 시작하고, 복잡한 아키텍처 판단·다중 에이전트 코디네이션·고위험 작업 시에만 Opus 4.6으로 전환하는 것입니다. API 단가는 Opus가 입력 $5/MTok, Sonnet이 $3/MTok입니다. (출처: Anthropic 공식 모델 선택 가이드)
Q&A
Q1. Pro 플랜에서도 1M 컨텍스트를 무료로 쓸 수 있나요?
아닙니다. GA 발표 기준으로 Pro 플랜에서 Opus 4.6의 1M 컨텍스트를 사용하면 추가 사용량이 필요합니다. 무료 사용은 Max·Team·Enterprise 플랜에서만 적용됩니다. (출처: Anthropic 공식 Opus 4.6 발표문 및 Claude Code Camp 실측, 2026.03.13)
Q2. Sonnet 4.6도 1M이 됐으니 Sonnet으로 써도 되지 않나요?
장거리 정보 검색이 중요한 작업이라면 신중해야 합니다. Sonnet 4.5의 1M MRCR 점수는 18.5%입니다. Sonnet 4.6의 수치는 Anthropic이 아직 공개하지 않은 부분이라, 긴 컨텍스트에서 정보 검색 정확도가 핵심인 경우라면 지금 기준으로 Opus 4.6이 더 확실합니다.
Q3. AWS Bedrock이나 Vertex AI에서도 1M 컨텍스트를 쓸 수 있나요?
사용은 됩니다. 단, Bedrock에서 Opus 4.6의 1M 컨텍스트는 현재 “preview” 클래스로 처리량이 표준 클래스보다 크게 낮습니다. 대규모 1M 요청이 필요하다면 Vertex AI(리전당 200 QPM·2M input TPM) 또는 Anthropic 직접 API를 우선 검토하는 것이 낫습니다.
Q4. 베타 시절에 쓰던 Beta 헤더를 그대로 코드에 남겨도 되나요?
Opus 4.6·Sonnet 4.6에는 헤더가 없어도 1M이 자동 동작하지만, 남겨둔다고 오류가 생기지는 않습니다. 다만 Sonnet 4·Sonnet 4.5는 여전히 구 Beta 방식(헤더 필수 + 200K 초과 프리미엄 요금)을 씁니다. 모델별로 다르게 적용되는 구조라 코드 정리 차원에서 확인해두는 것이 좋습니다.
Q5. 1M 컨텍스트가 활성화된 세션에서 Compaction이 아예 안 생기나요?
기본 임계값이 950K(전체 1M의 95%)로 높아졌을 뿐, Compaction 자체가 없어진 건 아닙니다. 일반적인 코딩 세션에서는 거의 발생하지 않지만, 매우 긴 에이전트 작업이라면 여전히 트리거될 수 있습니다. 환경변수 CLAUDE_AUTOCOMPACT_PCT_OVERRIDE로 임계값을 조정할 수 있습니다.
마치며
솔직히 말하면, 1M GA 발표가 나온 순간 “이제 뭐든 다 넣으면 되겠다”는 반응이 나오는 게 자연스럽습니다. 하지만 써보면 이야기가 달라집니다.
창이 크다고 성능이 자동으로 올라가는 게 아니고, Sonnet 4.5는 1M에서 MRCR 18.5%로 사실상 긴 컨텍스트를 소화하지 못합니다. 캐시 TTL 5분이라는 제약 때문에 자주 자리를 비우는 환경에서는 콜드 스타트 지연이 생각보다 크게 다가옵니다.
1M 컨텍스트가 진짜 빛을 발하는 순간은 명확합니다 — 대규모 코드베이스를 한 번에 올려서 분석하거나, 길고 복잡한 디버깅 세션에서 맥락을 날리지 않아야 할 때. 그 외의 일반적인 작업에서는 Sonnet 기본 + 적절한 `/clear` 관리가 여전히 효율적입니다.
기능이 생겼다는 것과 써야 한다는 것은 다른 이야기입니다.
본 포스팅 참고 자료
본 포스팅은 2026년 3월 28일 기준 공식 문서 및 실측 데이터를 바탕으로 작성되었습니다. 본 포스팅 작성 이후 서비스 정책·UI·기능이 변경될 수 있습니다. 정확한 요금 및 기능은 Anthropic 공식 사이트에서 확인하세요.
댓글 남기기