Claude Code 1M 컨텍스트, 이 조건 아니면 오히려 손해입니다
Anthropic이 2026년 3월 13일 Claude Code에 100만 토큰 컨텍스트 윈도우를 정식 출시했습니다. 발표문만 읽으면 “무료로 5배 더 쓸 수 있게 됐다”로 느껴지는데, 실제로는 요금제·모델·사용 패턴에 따라 비용이 3~5배 더 나오는 경우가 생깁니다.
200K 초과 시 입력 단가 2배
Max·Team·Enterprise 자동 포함
결론부터: 어떤 조건에서 쓰면 되고, 어떤 조건에서 쓰면 안 되나
Claude Code 1M 컨텍스트는 2026년 3월 13일부터 정식 출시됐고, Max·Team·Enterprise 요금제 사용자는 Opus 4.6 기준 추가 비용 없이 자동으로 활성화됩니다. (출처: Anthropic 공식 블로그, 2026.03.13) 여기까지는 맞는 얘기입니다.
단, API로 직접 연결하는 경우는 다릅니다. 입력 토큰이 200K를 넘는 순간 그 요청의 전체 입력 토큰에 단가 2배가 적용됩니다. 199K로 끝낸 요청과 201K로 넘어간 요청의 비용 차이는 단순한 2K 토큰 추가 비용이 아닙니다. 그 차이가 실질적으로 어느 정도인지는 아래에서 계산식으로 직접 보여드립니다.
그리고 모델을 잘못 고르면 1M 컨텍스트가 사실상 무용지물이 됩니다. Sonnet 4.6의 1M 구간 정확도 데이터가 공식적으로 공개되지 않은 상태이고, 이전 버전인 Sonnet 4.5 기준 MRCR 점수는 18.5%입니다. Opus 4.6의 78.3%와 비교하면 수치 자체가 다른 제품 수준입니다.
Claude Code 1M 컨텍스트가 뭔지 30초 안에 정리
Claude Code는 터미널에서 실행되는 Anthropic의 에이전트형 코딩 도구입니다. 여기서 ‘컨텍스트 윈도우’는 AI가 한 번의 요청에 읽을 수 있는 텍스트 분량의 상한선입니다. 토큰 1개는 대략 영문 4글자, 한글 1~2글자 수준이라 생각하면 1M 토큰은 대략 A4 용지 1,400장 분량입니다.
기존 200K 컨텍스트는 Claude Code가 대화를 누적할수록 오래된 내용을 요약·삭제하는 ‘컴팩션(compaction)’ 과정을 거쳤습니다. 이게 싫었던 사람들은 중요한 정보가 요약 과정에서 날아가는 경험을 했을 겁니다. 1M로 확장되면서 이 컴팩션이 훨씬 드물어졌고, Anthropic 공식 발표에서 한 파트너 기업의 CPO는 “컴팩션 이벤트가 15% 감소했다”고 밝혔습니다.
아울러 미디어 처리 한도가 기존 100개에서 600개로 늘어났습니다. 이미지나 PDF 수백 장을 한 세션에 올리는 작업이 가능해진 겁니다. (출처: Anthropic 공식 블로그, 2026.03.13)
💡 공식 발표문과 실제 사용 흐름을 같이 놓고 보니 이런 차이가 보였습니다
Anthropic 발표문은 “추가 비용 없이 표준 단가 적용”이라고 했는데, 이게 Max·Team·Enterprise 구독 플랜 기준입니다. API 직접 연동 시에는 200K 초과 구간부터 다른 단가표가 적용됩니다. 같은 문장이 두 가지 다른 의미로 읽히는 구조입니다.
200K 경계에서 생기는 가격 절벽, 직접 계산해봤습니다
솔직히 말하면, 이게 이번 업데이트에서 가장 주의해야 할 부분입니다. 1M 컨텍스트를 API로 쓸 때 입력 토큰이 200K를 넘기면 해당 요청의 전체 입력 토큰에 2배 단가가 적용됩니다. 경계를 넘는 순간 그 전 토큰까지 전부 비싸지는 구조입니다.
| 요청 크기 | 적용 단가 (Opus 4.6) | 실제 비용 (입력) |
|---|---|---|
| 199,000 토큰 | $5.00/M (표준) | $0.995 |
| 201,000 토큰 | $10.00/M (2배 적용) | $2.010 |
▲ 출처: Anthropic API 공식 가격표 기준 / claudecodecamp.com 실측 데이터 재구성 (2026.03.13)
2K 토큰 차이로 비용이 2배가 됩니다. 이 200K 경계를 기준으로 계산하면, 경계를 넘기는 그 2,000토큰의 실효 단가는 토큰당 $507.50/M 수준입니다. 가장 비싼 구간에서 가장 비싼 값을 내는 셈입니다.
프롬프트 캐싱도 마찬가지입니다. 200K를 넘기면 캐시 읽기 비용도 $0.50/M에서 $1.00/M으로 오릅니다. 단, Max·Team·Enterprise 구독 플랜으로 Claude Code를 쓰는 경우는 이 가격 절벽과 무관합니다. 플랜 내 사용량에 1M이 자동 포함됩니다. (출처: Anthropic 공식 블로그 2026.03.13)
Sonnet 4.6도 1M 된다고요? 벤치마크가 다른 말을 합니다
“Opus 4.6과 Sonnet 4.6 모두 1M 컨텍스트 지원”이라는 게 공식 발표 내용입니다. 기술적으로는 사실입니다. 하지만 1M 구간에서의 정확도는 모델마다 완전히 다릅니다.
| 모델 | MRCR v2 점수 (1M 구간) | 실사용 판단 |
|---|---|---|
| Opus 4.6 | 78.3% | 1M 구간 실전 사용 가능 |
| Gemini 3 Pro | 26.3% | 400K 이상 신뢰 낮음 |
| Sonnet 4.5 | 18.5% | 1M 구간 실전 부적합 |
▲ 출처: Anthropic MRCR v2 벤치마크 공식 발표 / claudecodecamp.com 독립 검증 (2026.03.13 기준)
MRCR v2는 긴 텍스트 안에 심어둔 정보를 모델이 얼마나 정확하게 찾아내는지 측정하는 벤치마크입니다. Opus 4.6이 78.3%라면 Sonnet 4.5의 18.5%는 같은 시험지에서 20점도 못 받은 셈입니다. 독립 실험에서도 Sonnet 4.6은 400K 이상 구간에서 정답을 놓치거나 수치를 잘못 인용하는 경향이 확인됐습니다.
주의할 점은 Anthropic이 아직 Sonnet 4.6의 공식 MRCR 점수를 공개하지 않은 상태라는 겁니다. 4.5보다 나아졌을 가능성은 있지만, 공식 수치가 나오기 전까지 1M 구간에서 Sonnet을 믿는 건 근거가 없는 도박입니다. 1M 컨텍스트 구간 작업에서는 Opus 4.6을 쓰는 게 맞습니다.
💡 벤치마크 점수와 실제 코딩 작업을 같이 보니 이런 패턴이 보였습니다
실험에서 Sonnet 4.6은 600K 구간에서 직원 이름은 맞히는데 보너스 금액을 다르게 말하는 ‘부분 정답’ 패턴을 보였습니다. 코딩 작업으로 치면 함수명은 기억하는데 인자를 틀리게 넘기는 것과 같은 상황입니다. 실수가 티 안 나는 곳에서 나옵니다.
자리 비우면 돈 나오는 이유, 캐시 TTL과 콜드 스타트
Claude Code의 프롬프트 캐시는 마지막 사용 후 5분 뒤 만료됩니다. 캐시가 살아있으면 모델은 이전에 처리한 컨텍스트를 재사용하기 때문에 응답 시작 속도가 빠릅니다. 캐시가 식으면 다음 요청 시 전체 컨텍스트를 처음부터 다시 처리해야 합니다. 이게 ‘콜드 스타트’입니다.
실측 데이터를 보면, 500K 컨텍스트 기준 캐시가 warm할 때 첫 응답 대기 시간은 약 3.5초, cold 상태에서는 약 35초입니다. 1M 기준으로 외삽하면 cold 상태에서 첫 응답까지 60~90초를 기다릴 수 있습니다. (출처: claudecodecamp.com 실측, 2026.03.13)
| 컨텍스트 크기 | 캐시 warm (첫 응답) | 캐시 cold (첫 응답) |
|---|---|---|
| 50K | 약 0.8초 | 약 2초 |
| 200K | 약 1.6초 | 약 9초 |
| 500K | 약 3.5초 | 약 35초 |
| 1M (추정) | 약 7~10초 (추정) | 약 60~90초 (추정) |
▲ 출처: claudecodecamp.com 실측 데이터 (2026.03.13) / 1M 행은 멱함수 외삽 추정치
커피 마시고 돌아오거나 회의 다녀온 뒤 Claude Code를 재개하면, 1M 컨텍스트 세션에서는 1분 넘게 첫 응답을 기다려야 할 수 있습니다. API 과금 환경에서는 이 cold 재처리 비용도 그대로 부과됩니다. 작업 중간에 자리를 자주 비우는 패턴이라면, 1M보다 200K에서 컴팩션을 적극 활용하는 쪽이 실제 비용은 더 낮습니다.
진짜 써야 할 상황 vs 쓰면 손해인 상황
실제로 세션을 열어보면 일반적인 Claude Code 세션은 컴팩션 전 80~120K 토큰에서 정점을 찍습니다. 대부분의 사람이 200K도 채우지 않습니다. 그러니 1M이 필요한 상황이 실제로 언제인지를 구분하는 게 핵심입니다.
쓸 만한 상황
대용량 코드베이스를 단 한 번의 요청으로 분석할 때 효과가 가장 큽니다. 수백 개 파일이 얽힌 레거시 코드의 의존성 지도를 그리거나, 400페이지짜리 계약서에서 특정 조항을 찾는 작업이 대표적입니다. 이 경우에는 컨텍스트 분열 없이 한 번에 읽고 답을 내놓기 때문에 1M이 명확하게 유리합니다.
버그를 15개 파일에 걸쳐 추적하는 세션처럼 컨텍스트가 중간에 잘리면 안 되는 작업에도 적합합니다. 공식 발표에서 한 엔지니어가 인용한 것처럼, 컴팩션이 발생하면 “정확히 필요한 정보가 사라진다”는 문제가 해소됩니다. (출처: Anthropic 공식 블로그, 2026.03.13)
피하는 게 나은 상황
일반적인 기능 개발 세션에서는 1M이 필요 없습니다. 세션이 80턴을 넘기면 초반의 탐색 기록이 오히려 모델의 주의를 분산시킵니다. 이럴 땐 /clear로 초기화하고 새로 시작하는 편이 낫습니다. 컨텍스트 크기가 작을수록 모델이 현재 목표에 집중합니다.
‘Lost in the middle’ 현상도 고려해야 합니다. 트랜스포머 기반 모델은 컨텍스트의 앞부분과 끝부분에 집중하는 경향이 있고, 중간부는 상대적으로 덜 참조합니다. 1M 컨텍스트에서 중요한 정보를 중간에 두면 모델이 그 정보를 제대로 활용하지 못할 수 있습니다. 핵심 지시사항은 컨텍스트의 맨 앞이나 맨 끝에 배치하는 게 안전합니다.
Q&A 5가지
마치며
Claude Code 1M 컨텍스트는 분명 의미 있는 업데이트입니다. 특히 대규모 코드베이스를 한 번에 읽어야 하거나, 수백 페이지 문서에서 정확한 인용이 필요한 작업에서는 이전과 다른 경험을 줍니다. Max·Team·Enterprise 플랜 사용자라면 이미 포함된 기능이니 안 쓸 이유가 없습니다.
써보니까 한계도 있습니다. 200K 경계 가격 절벽, Sonnet 4.6의 장거리 정확도 미검증, 캐시 만료 후 콜드 스타트 지연. 이 세 가지를 모른 채 “1M이니까 무조건 크게 쓰면 되겠다”고 접근하면 비용이나 품질 모두 기대에 못 미칩니다. 핵심 정보는 컨텍스트 앞뒤에 배치하고, 1M이 정말 필요한 작업인지 먼저 확인하는 게 순서라고 봅니다.
Sonnet 4.6의 공식 MRCR 수치는 아직 공개되지 않았습니다. 수치가 나오면 이 판단이 달라질 수 있어서 이 부분은 계속 지켜볼 예정입니다.
본 포스팅 참고 자료
- Anthropic 공식 블로그 — Claude Opus 4.6 & Sonnet 4.6: 1M Context GA
https://claude.com/blog/1m-context-ga - Claude Code 공식 문서 — 비용 관리 가이드
https://code.claude.com/docs/ko/costs - ClaudeCodeCamp — 1M Context Window 실측 분석 (2026.03.13)
https://www.claudecodecamp.com/p/claude-code-1m-context-window - Anthropic 지원 센터 — Claude March 2026 Usage Promotion
https://support.claude.com/ko/articles/14063676-claude-march-2026-usage-promotion
본 포스팅은 2026년 3월 28일 기준 공식 자료를 토대로 작성되었습니다. 본 포스팅 작성 이후 서비스 정책·UI·기능이 변경될 수 있습니다. 특히 Anthropic의 가격 정책과 모델 스펙은 사전 공지 없이 변경될 수 있으니 최신 내용은 Anthropic 공식 채널을 확인하시기 바랍니다.
댓글 남기기