Claude Code 1M 컨텍스트,
크면 다 좋을까요?

2026년 3월 13일, Anthropic이 Claude Code의 1M(100만 토큰) 컨텍스트 윈도우를 베타에서 정식 출시(GA)로 전환했습니다. 화제가 된 건 추가 요금 없이 표준 가격으로 쓸 수 있다는 발표였습니다. 그런데 실제로 써보니, “크면 무조건 좋다”는 생각이 얼마나 위험한지를 먼저 이야기해야 할 것 같았습니다.

1M 컨텍스트 GA, 정확히 무엇이 달라졌나

2026년 3월 13일, Claude Code v2.1.75 업데이트를 통해 1M 컨텍스트 윈도우가 정식 출시됐습니다. (출처: Anthropic 공식 블로그, claude.com/blog/1m-context-ga, 2026.03.13)

발표 내용을 공식 문서 그대로 정리하면 이렇습니다.

• Opus 4.6, Sonnet 4.6 두 모델 모두 1M 윈도우 적용
• 베타 헤더(beta header) 별도 설정 없이 자동 활성화 — 기존 코드 수정 불필요
• 미디어 처리 한도: 요청당 100장 → 600장으로 6배 확대
• Claude Code에서 Max, Team, Enterprise 플랜 사용자는 Opus 4.6 기준 1M 자동 적용
• Amazon Bedrock, Google Cloud Vertex AI, Microsoft Foundry 세 외부 플랫폼에서도 동시 지원

이 중에서 “no long-context premium“이라는 표현이 가장 많이 회자됐습니다. 그런데 이 표현이 어떤 조건에서 적용되는지, 공식 문서를 그냥 읽으면 놓치는 부분이 있습니다. 다음 섹션에서 바로 짚어봤습니다.

▲ 목차로 돌아가기

“추가 요금 없음”이 실제로 맞는 조건

Anthropic이 “no long-context premium”이라고 발표한 것은 사실입니다. 단, 이 표현이 정확히 적용되는 맥락은 Claude Code Max·Team·Enterprise 플랜 사용자 기준입니다.

즉, Pro 플랜 사용자가 Opus 4.6 또는 Sonnet 4.6에서 1M 컨텍스트를 쓰려면 ‘extra usage 활성화’가 선행되어야 합니다. 요금 자체는 per-token 방식이고 추가 프리미엄이 없다는 뜻이지, 무료로 무한정 쓴다는 뜻이 아닙니다.

그리고 Claude Platform API를 직접 호출할 경우 — 다음 섹션에서 자세히 다루는 — 200K 토큰 경계를 넘으면 실제로 단가가 달라집니다.

▲ 목차로 돌아가기

200K를 1토큰만 넘어도 요금이 2배가 되는 이유

공식 블로그는 “no multiplier”를 강조했는데, 실제 API 요금표를 보면 이야기가 달라집니다. API를 직접 사용하는 경우, 입력 토큰이 200K를 넘으면 전체 토큰에 대해 프리미엄 단가가 소급 적용됩니다.

200K를 1토큰만 넘어도 그 이전 토큰까지 전부 2배 단가로 재계산됩니다. 2,000토큰을 더 쓴 비용이 무려 $1.015, 사실상 그 2,000토큰의 단가가 $507.50/M이 되는 겁니다.

캐시를 써도 마찬가지입니다. 캐시 읽기 단가도 200K를 넘으면 2배로 올라갑니다. 90% 할인이 유지되긴 하지만, 기준 단가 자체가 높아진 상태에서의 90% 할인입니다. Opus 기준 $0.50/M → $1.00/M. 캐시가 있어도 200K 경계선을 넘는 순간 비용 구조가 달라집니다.

▲ 목차로 돌아가기

Opus와 Sonnet, 같은 1M인데 성능이 다른 이유

1M 컨텍스트를 지원한다고 해서 모든 모델이 1M을 제대로 쓸 수 있는 건 아닙니다. MRCR v2 벤치마크 — 긴 문서 안에서 특정 정보를 정확히 꺼내오는 테스트 — 결과를 보면 차이가 분명합니다. (출처: Anthropic 공식 블로그, 2026.03.13)

Opus 4.6은 1M에서 76%를 유지합니다. 반면 Sonnet 4.5는 같은 길이에서 18.5%로 급락합니다. 실측 실험에서도 Sonnet은 400K부터 정보 회수가 불안정해지고, 600K에서는 거의 실패 수준이었습니다. (출처: claudecodecamp.com 실험 보고서, 2026.03.13)

이유는 훈련 방식에 있습니다. 모델이 긴 컨텍스트를 처리하려면, 사전 훈련(pretraining) 단계에서부터 긴 시퀀스를 학습해야 합니다. 지원은 가능하지만 학습이 충분하지 않으면, 컨텍스트 중간 부분의 정보를 제대로 꺼내오지 못하는 “lost in the middle” 현상이 나타납니다.

Sonnet 4.6의 MRCR v2 수치는 아직 공식 발표가 없습니다. Anthropic이 이유를 밝히지 않은 부분입니다. 현재로서는 1M 영역에서 Opus 4.6만 실전 투입에 적합하다고 보는 게 안전합니다.

▲ 목차로 돌아가기

1M이 진짜 필요한 상황 vs 오히려 손해인 상황

쓸수록 이득인 경우

• 대형 코드베이스 단발성 분석 — 수만 줄 프로젝트 전체를 한 요청에 넣고 분석. 대화가 길어지지 않기 때문에 컨텍스트 분산(context rot)이 최소화됩니다.
• 수백 페이지 계약·문서 전체 참조 — 구체적인 조항을 인용해야 하는 법률·컴플라이언스 작업. 문서를 청크로 나누면 연결성이 끊깁니다.
• 에이전트 팀 구성 시 공유 상태 보존 — 여러 에이전트가 동시에 파일을 분석하고 결과를 공유할 때 누적 컨텍스트가 빠르게 커집니다.
• 복잡한 버그 추적 세션 — 15개 파일에 걸친 스택트레이스·재현 단계·실패 가설이 모두 한 창에 있어야 할 때. 컴팩션하면 가장 필요한 정보가 사라집니다.

쓰면 오히려 손해인 경우

Claude Code의 프롬프트 캐시 유효 시간은 5분입니다. 캐시가 살아있을 때 500K 컨텍스트의 응답 대기 시간은 약 3.5초. 그런데 캐시가 만료된 cold 상태에서는 같은 500K에서 약 35초가 걸립니다. 1M으로 추산하면 cold start에 60~90초를 기다려야 합니다. (출처: claudecodecamp.com 실측, 2026.03.13)

• 자리를 자주 비우는 작업 — 6분 자리를 비우면 캐시가 만료되고, 다음 메시지에서 cold start 패널티를 맞습니다.
• 일상적인 코딩 세션 — 실측 결과, 대부분의 세션은 컴팩션 전까지 80~120K 수준에 머뭅니다. 1M을 선택해도 200K를 넘지 않아 표준 요금이 적용되므로 손해는 없지만, 1M이 필요하지도 않습니다.
• Sonnet 4.6 단독으로 긴 컨텍스트 처리 — 위에서 정리한 것처럼, 400K 이상에서 정확도가 떨어집니다. 2배 요금을 내면서 성능 저하까지 동반할 수 있습니다.
• 80턴 이상의 긴 대화 — 오래된 탐색 맥락이 오히려 현재 작업에 방해가 됩니다. 이럴 때는 /clear로 새 세션을 여는 게 품질 면에서 유리합니다.

결론부터 말씀드리면, Max·Team·Enterprise에서 1M 모델을 선택해두는 건 비용이 없으니 나쁠 게 없습니다. 하지만 API를 직접 쓰는 개발자라면 세션이 200K를 넘기기 시작하는 순간부터 턴당 비용을 반드시 계산해야 합니다.

▲ 목차로 돌아가기

3월 업데이트에서 함께 달라진 것들

1M 컨텍스트 외에도 3월 한 달 동안 Claude Code는 14번 릴리즈됐고, 변경 사항이 400건을 넘겼습니다. (출처: dev.to 릴리즈 노트 분석, 2026.03.20) 실무에서 체감이 큰 변경 사항을 추렸습니다.

실무에서 바로 체감할 수 있는 건 음성 모드와 출력 토큰 확대입니다. 음성 모드는 코드 리뷰 중 수정 지시를 구두로 전달할 수 있어서, 키보드에서 손을 떼지 않아도 됩니다. 출력 토큰이 128K까지 늘어난 덕에, 대규모 파일을 한 번의 턴에서 완성할 수 있게 됐습니다.

macOS 응답 속도도 60ms 단축됐고, –resume 재개 속도는 45% 향상됐습니다. 대형 레포에서 메모리 사용량도 80MB 줄었습니다. 이 부분은 숫자가 작아 보이지만 세션이 길어질수록 누적 효과가 체감됩니다.

▲ 목차로 돌아가기

Q&A

▲ 목차로 돌아가기

마치며

Claude Code 1M 컨텍스트는 진짜 강력합니다. 대형 코드베이스 전체를 한 창에 올려두고 분석하거나, 수백 페이지 문서를 청크 없이 통으로 넣는 작업에서는 실제로 이전에는 불가능했던 수준의 작업이 됩니다.

단, 이 글을 쓰면서 직접 확인한 건, 발표문의 “no long-context premium”이 전부가 아니라는 점입니다. 200K를 1토큰이라도 넘으면 전체 요금이 2배로 뛰고, Sonnet은 1M에서 정확도가 크게 떨어집니다. 캐시가 5분 안에 만료되면 cold restart 패널티도 각오해야 합니다.

Max·Team·Enterprise 사용자라면 1M 모델을 설정해두는 게 손해는 없습니다. API를 직접 쓴다면 세션이 200K를 넘기 시작하는 순간부터 비용을 추적하는 게 맞습니다. 그리고 Opus 4.6을 쓰지 않는다면, 1M을 선택해도 그 공간을 충분히 활용하기가 어렵습니다.

3월 업데이트에서 나온 음성 모드, /loop 스케줄링, –bare 플래그는 코딩 흐름 자체를 바꾸는 변화입니다. 1M 컨텍스트는 그중 하나일 뿐입니다. 막상 써보면 200K 이하에서 세션을 잘 관리하는 게 1M을 꽉 채우는 것보다 성능과 비용 양쪽에서 유리한 경우가 더 많았습니다.

▲ 목차로 돌아가기

본 포스팅 참고 자료

1. Anthropic 공식 블로그 — 1M Context GA 발표 (claude.com/blog/1m-context-ga, 2026.03.13)
2. Claude 공식 지원 문서 — 컨텍스트 윈도우 안내 (support.claude.com, 2026.03.13)
3. Claude Platform 공식 문서 — 컨텍스트 윈도우 개발자 가이드 (platform.claude.com)
4. Claude Code Camp — 1M 컨텍스트 실측 실험 보고서 (claudecodecamp.com, 2026.03.13)
5. dev.to 정상록 — Claude Code 3월 업데이트 총정리 (dev.to, 2026.03.20)