Claude Code / Opus 4.6 · Sonnet 4.6
Claude Code 1M 컨텍스트, 용량보다 가격이 먼저입니다
Claude Code의 1M 토큰 컨텍스트 창이 2026년 3월 13일 정식 GA로 전환됐습니다. 가장 많이 잘못 이해되는 부분이 있는데, 이번 변화의 핵심은 용량 확대가 아니라 200K 초과 시 청구되던 2배 프리미엄의 완전 폐지입니다. Anthropic 공식 발표(출처: claude.com/blog/1m-context-ga)에는 이렇게 나와 있습니다: “A 900K-token request is billed at the same per-token rate as a 9K one.” 900K짜리 요청이 9K짜리와 같은 단가입니다.
이번 GA에서 진짜 바뀐 것
Claude Code 1M 컨텍스트는 2026년 2월 5일 Opus 4.6 출시 때 베타로 나왔습니다. 그때는 200K 초과 입력에 2배 프리미엄이 붙었고, Sonnet 4.6에도 같은 조건이었습니다. 3월 13일 GA 전환과 함께 이 조건이 통째로 사라졌습니다. (출처: Anthropic 공식 블로그, 2026.03.13)
구체적으로 정리하면 이렇습니다. Opus 4.6은 입력 토큰 100만 개당 $5, 출력 100만 개당 $25로 전체 창에 동일하게 적용됩니다. Sonnet 4.6은 입력 $3, 출력 $15입니다. 여기서 400K짜리 요청이 이전에는 200K 이하 구간은 기본 단가, 초과 200K는 2배로 계산되었습니다. 지금은 400K 전체가 하나의 단가입니다. 장문 코딩 세션을 자주 돌리는 팀이라면 청구서 계산이 단순해집니다.
추가로 미디어 한도도 6배 늘었습니다. 요청당 이미지나 PDF 페이지를 기존 100개에서 600개까지 넣을 수 있습니다. 클라이언트 코드 수정도 없습니다. 기존에 베타 헤더(anthropic-beta: long-context-2025-01-01)를 쓰던 분은 그냥 두면 무시됩니다.
왜 경쟁사 1M과 다른지
💡 공식 발표문과 경쟁사 요금표를 같이 놓고 보니 이런 차이가 보였습니다
가격 구조가 다르다는 것은 단순한 할인이 아닙니다. 긴 컨텍스트에 페널티를 붙이는 구조는 사용자가 스스로 창을 덜 채우게 만듭니다. 그 페널티가 사라진다는 것은 워크플로 설계 자체가 달라진다는 뜻입니다.
성능 비교에서 더 눈에 띄는 수치가 있습니다. GPT-5.4는 256K에서 1M 구간으로 넘어가면 정확도가 약 54% 떨어집니다. Gemini 3.1 Pro도 256K를 넘으면 50% 매칭률을 간신히 넘는 수준으로 내려옵니다. Opus 4.6은 1M에서 78.3%를 유지합니다. 숫자로 치면 경쟁사 대비 약 1.5배 이상의 정확도입니다. (출처: Anthropic 공식 블로그, MRCR v2 기준, 2026.03.13) 단순히 창이 크다는 게 아니라 그 창을 실제로 쓸 수 있다는 의미입니다.
컴팩션이 왜 이렇게 문제였나
Claude Code는 컨텍스트가 일정 한도에 가까워지면 자동으로 이전 대화를 요약합니다. 이 과정을 컴팩션(compaction)이라고 합니다. 한 번 일어나면 세션 초반의 세부 내용이 압축 요약으로 대체됩니다. 정확한 오류 메시지, 아키텍처 결정 이유, 파일 간 의존성 같은 정보가 손실됩니다.
문제는 이 손실이 선형이 아니라는 점입니다. 컴팩션이 한 번은 괜찮습니다. 두 번이면 “요약의 요약”이 됩니다. 세 번이면 원본 정보의 핵심 뉘앙스가 거의 남지 않습니다. 실제 현장에서는 긴 코딩 세션에서 이미 한 결정을 반복 설명해야 하거나, 에이전트가 같은 파일을 다시 읽는 루프에 빠지는 현상이 여기서 나옵니다. (출처: Anthropic CPO Jon Bell, claude.com/blog/1m-context-ga)
💡 “컴팩션 15% 감소”가 실제로 의미하는 바
컴팩션 이벤트 15% 감소(출처: Anthropic CPO, 2026.03.13)는 단순 통계 이상입니다. 한 세션에서 컴팩션이 3번이 아닌 2번으로 줄었다면, “요약의 요약의 요약”이 “요약의 요약”으로 개선됩니다. 정보 손실이 줄어드는 것은 맞지만, 더 중요한 것은 두 번째 컴팩션을 아예 피할 수 있는 세션이 늘었다는 점입니다.
법률 계약서, 재무 보고서처럼 요약이 오해를 낳는 문서를 다루는 에이전트 워크플로에서 이 차이는 결과물의 품질에 직결됩니다. 소프트웨어 코드는 구조화되어 있어서 요약도 상대적으로 잘 되지만, 비정형 문서를 다루는 작업일수록 컴팩션의 피해가 컸습니다.
Claude Code 실제 유효 컨텍스트 계산
Claude Code는 버퍼로 약 33K 토큰을 예약해 두고, 전체 창의 약 83.5% 시점에서 컴팩션을 트리거합니다. 이를 기준으로 실제 쓸 수 있는 토큰을 계산하면 이렇게 됩니다.
1M 창 기준: 1,000,000 × 83.5% ≈ 802,000 토큰 (컴팩션 이전 유효 컨텍스트)
증가율: 802,000 ÷ 134,000 ≈ 약 5.9배
흔히 “5배 늘었다”고 말하지만 실제는 5.9배입니다. 표면적인 창 크기 비교(200K 대 1M = 5배)보다 압축 없이 쓸 수 있는 실질적 공간이 더 크게 늘었습니다. (출처: paddo.dev/blog/million-token-context, 2026.03.15에서 Claude Code 내부 동작 수치 인용) 긴 작업을 자주 돌리는 환경이라면 첫 번째 컴팩션까지 버티는 시간이 거의 6배 늘어났다는 의미입니다.
비교로 참고할 만한 것이 있습니다. Opus 4.6를 200K에서 500K로 올려서 쓰고 있던 한 팀은 컨텍스트 창을 확장하자 오히려 에이전트가 전반적으로 더 적은 토큰을 소비했다고 밝혔습니다. (출처: Izzy Miller, AI Research Lead, claude.com/blog/1m-context-ga) 더 넓은 창이 불필요한 파일 재탐색을 줄였기 때문입니다.
1M도 채울수록 정확도가 떨어집니다
이 부분이 많이 빠져 있는 이야기입니다. MRCR v2 기준 Opus 4.6의 전체 1M에서의 정확도는 78.3%입니다. 수치가 낮은 것이 아니라, 거꾸로 읽으면 100번 중 22번은 틀린다는 뜻입니다. 같은 Opus 4.6이 256K 구간에서는 92~93%를 기록합니다. 창의 4분의 1도 안 채웠을 때와 가득 채웠을 때 정확도가 약 14~15%p 차이납니다. (출처: paddo.dev/blog/million-token-context, Liu et al. 2024 인용)
💡 벤치마크 수치와 실사용 흐름을 같이 놓고 보니 이런 차이가 보였습니다
MRCR v2는 “바늘 찾기” 형태의 검색 테스트입니다. 긴 문맥 전체를 추론해야 하는 코딩 작업은 단순 검색보다 더 일찍 성능이 꺾일 수 있습니다. 즉 1M 창의 후반부일수록 성능 하락은 벤치마크보다 빠릅니다.
이른바 “로스트 인 더 미들(Lost in the Middle)” 문제도 있습니다. Liu et al. (2024) 연구는 AI 모델이 컨텍스트의 처음과 끝에는 잘 집중하지만, 중간에 있는 정보는 최대 30% 이상 놓친다는 구조적 특성을 보고했습니다. 위치 임베딩 방식에서 오는 문제라 단순 패치로 해결되지 않습니다. 실제로 Anthropic 내부 실험에서 Claude 2.1의 장문 정확도를 27%에서 98%로 끌어올린 것이 단 하나의 프롬프트 힌트 문장이었다는 사례도 있었습니다. 모델이 정보를 보유하고 있으면서도 참조하지 않을 수 있다는 의미입니다.
GitHub의 Claude Code 이슈 트래커(#35296, 2026.03.16)에는 컨텍스트 50% 초과 시 단순한 성능 저하가 아니라 “적극적 환각(active fabrication)”이 발생한다는 버그 리포트도 올라왔습니다. Anthropic이 공식 답변을 내놓지 않은 부분입니다. 1M 창을 쓸 때 컨텍스트 중간 이후에 넣은 정보는 더 주의해서 결과를 검토하는 것이 안전합니다.
Max·Team·Enterprise 플랜은 어떻게 달라지나
구독 플랜 기준으로 변화가 적용되는 방식이 다릅니다. Claude Code Max, Team, Enterprise 플랜 사용자는 Opus 4.6 세션에서 1M 컨텍스트가 자동으로 활성화됩니다. 따로 설정을 바꾸지 않아도 됩니다. 이전에는 1M 창을 쓰면 추가 사용량이 차감됐지만, GA 이후로 그 조건이 제거됐습니다.
| 구분 | Claude Code Max/Team/Enterprise |
API 직접 호출 | 기타 플랜 |
|---|---|---|---|
| 1M 창 자동 활성 | ✅ | ✅ | – |
| 200K 초과 프리미엄 | 없음 | 없음 | – |
| 미디어 한도 | 약 600개 | 약 600개 | 약 100개 |
| Sonnet 4.6 지원 | ✅ | ✅ | – |
(출처: Anthropic 공식 블로그 claude.com/blog/1m-context-ga, 2026.03.13 기준)
API를 직접 쓰는 분들은 클라우드 플랫폼 경유 여부와 관계없이 적용됩니다. Amazon Bedrock, Google Cloud Vertex AI, Microsoft Foundry 모두 지원합니다. 단 Claude.ai 개인 계정(Pro 포함)에서는 별도 안내가 없었습니다. 개인 계정 기준으로는 아직 이유가 공개되지 않았습니다.
지금 당장 달라지는 것, 안 달라지는 것
솔직히 말하면, 대부분의 일반적인 코딩 세션은 크게 달라지지 않습니다. 짧고 반복적인 단일 기능 작업은 컨텍스트 창 200K도 충분했습니다. 이번 변화의 수혜는 명확한 두 가지 시나리오에 집중됩니다.
첫 번째는 대규모 코드베이스 전체를 한 세션에 올려야 하는 경우입니다. SentinelOne 사례처럼 수백만 줄 코드베이스 마이그레이션 작업이나, 수십 개 파일 간 의존성을 추적해야 할 때 이전에는 중간에 컴팩션이 개입해서 파일을 다시 읽는 루프가 생겼습니다. 이제 해당 루프가 상당히 줄어듭니다. (출처: Anthropic 공식 파트너 사례, 2026.02.05)
두 번째는 법률·금융처럼 문서 원문 전체를 참조해야 하는 에이전트 작업입니다. 계약서 여러 장을 한 세션에 넣고 교차 참조할 때 요약본이 아닌 원문이 창에 남아 있는 것과 없는 것은 결과 품질이 다릅니다. 이 차이가 1M 창이 코딩보다 오히려 법률·금융 에이전트에서 더 명확하게 드러나는 이유입니다.
반면 달라지지 않는 것도 있습니다. 비용 계산의 기본 단가는 그대로입니다. Opus 4.6 입력 $5/M, Sonnet 4.6 입력 $3/M은 변하지 않습니다. 창을 크게 쓸수록 절대 비용은 비례해서 늘어납니다. 단일 1M 토큰 Opus 요청의 입력 비용만 $5입니다. 여러 차례 주고받는 긴 세션은 빠르게 쌓입니다. 컨텍스트를 무조건 크게 유지하는 것이 비용 절감이 아닙니다. “최소한의 고신호 토큰” 원칙은 여전히 유효합니다. (출처: Anthropic context engineering 가이드)
자주 묻는 질문
Claude Code Free 또는 Pro 개인 계정도 1M 컨텍스트가 됩니까?
▼
현재 공식 발표 기준으로 1M 컨텍스트 GA는 Claude Code Max·Team·Enterprise 및 API(Claude Platform, Amazon Bedrock, Google Vertex AI, Microsoft Foundry) 사용자에게 적용됩니다. Claude.ai 개인 Pro 계정에서의 적용 여부는 Anthropic이 별도 안내를 하지 않은 상태입니다.
베타 헤더를 이미 쓰고 있었는데 코드 수정이 필요합니까?
▼
아닙니다. anthropic-beta: long-context-2025-01-01 헤더는 GA 이후 자동으로 무시됩니다. 헤더를 제거하든 그대로 두든 동작이 동일합니다. (출처: Anthropic 공식 블로그, 2026.03.13)
1M 토큰을 꽉 채워서 쓰는 게 가장 효율적입니까?
▼
그렇지 않습니다. 창을 많이 채울수록 정확도가 낮아지는 경향이 있습니다. Opus 4.6의 256K 구간 MRCR v2 정확도는 92~93%이지만, 1M 전체에서는 78.3%로 낮아집니다. 1M 창의 가치는 “꽉 채워서 쓰는 것”이 아니라 “컴팩션 없이 버틸 수 있는 여유”를 주는 데 있습니다.
Sonnet 4.6도 1M이 됩니까, 아니면 Opus 4.6만입니까?
▼
Opus 4.6과 Sonnet 4.6 모두 1M 컨텍스트를 단일 단가로 제공합니다. Sonnet 4.6 기준으로는 입력 $3/M, 출력 $15/M이 1M 전체에 적용됩니다. 다만 장문 정확도 벤치마크에서 Opus 4.6이 Sonnet 4.6보다 높은 성능을 유지합니다.
RAG(검색 증강 생성)을 쓰고 있는데, 1M 창으로 대체할 수 있습니까?
▼
단순 대체는 어렵습니다. 창이 커도 맥락 중간부에 놓인 정보는 여전히 놓칠 수 있습니다. 전체 문서가 항상 필요한 계약서 분석이나 전체 코드베이스 탐색처럼 문서를 자를 수 없는 경우에는 1M 창이 RAG보다 낫습니다. 하지만 수천만 개 이상의 대형 문서 DB를 검색해야 한다면 여전히 RAG가 필요합니다. 두 방식은 경쟁이 아니라 상호보완적으로 쓰는 것이 현실적입니다.
마치며 — 진짜 변화는 조용히 옵니다
솔직한 제 의견을 말하면, 이번 발표에서 가장 중요한 한 줄은 “No long-context premium”입니다. 어떤 기능이 추가 요금 없이 기본값이 되는 순간 워크플로가 달라집니다. 이전에는 비용 때문에 컨텍스트를 아껴 쓰는 습관을 들여야 했다면, 이제는 프롬프트 설계 방식 자체를 다시 생각할 수 있습니다. 물론 컨텍스트를 꽉 채우는 것이 항상 좋은 건 아닙니다. 그 여유를 어떻게 설계하느냐가 남은 숙제입니다.
기대했던 것과 다를 수 있는 부분도 짚어 드렸습니다. 1M을 가득 채우면 여전히 4분의 1은 틀릴 수 있고, 중간에 넣은 정보는 끝에 넣은 것보다 주목받지 못할 가능성이 있습니다. 좋은 기술을 잘 쓰려면 그 한계를 먼저 아는 편이 낫습니다.
본 포스팅 참고 자료
- Anthropic 공식 블로그 — 1M context is now generally available (2026.03.13)
- Anthropic 공식 뉴스 — Introducing Claude Opus 4.6 (2026.02.05)
- paddo.dev — Context Stops Being Scarce (2026.03.15)
- Martin Alderson — Why Claude’s new 1M context length is a big deal (2026.03.15)
- Anthropic 공식 가격표 — Claude Platform Pricing
본 포스팅은 2026년 3월 23일 기준으로 작성되었습니다. Anthropic의 서비스 정책·UI·기능·가격은 업데이트로 내용이 달라질 수 있습니다. 본 포스팅 작성 이후 서비스 정책·UI·기능이 변경될 수 있으니, 최신 정보는 Anthropic 공식 문서(platform.claude.com/docs)에서 직접 확인하시기 바랍니다.
댓글 남기기