GA 이전과 이후, 요금이 이렇게 달라졌습니다

Anthropic이 Opus 4.6을 처음 발표한 건 2026년 2월 5일이었습니다. 당시 공식 발표문에는 1M 컨텍스트를 ‘베타’로 명시했고, 200K 토큰을 초과하는 요청에는 프리미엄 요금이 붙는다고 직접 적혀 있었습니다. Opus 4.6 기준으로 입력 $10/백만 토큰, 출력 $37.50 — 표준 요금의 2배와 1.5배입니다.

그런데 2026년 3월 13일 공식 블로그 포스트 하나가 이 구조를 완전히 뒤집었습니다. 1M 컨텍스트 GA 전환과 함께, 200K 초과에 붙던 프리미엄 멀티플라이어가 사라졌습니다. 900K짜리 요청도, 9K짜리 요청도 이제 같은 토큰 단가로 청구됩니다. (출처: Anthropic 공식 블로그 claude.com/blog/1m-context-ga, 2026.03.13)

요금만 보면 좋은 소식처럼 보입니다. 그런데 claudecodecamp.com의 실측 실험 데이터(2026.03.13)를 같이 놓고 보면 이야기가 달라집니다. 이 부분은 섹션 3에서 다시 다룹니다.

(출처: Anthropic 공식 블로그 1M GA 발표, 2026.03.13 / Anthropic Opus 4.6 출시 발표, 2026.02.05)

▲ 목차로 돌아가기

1M이 생긴 기술적 이유 — FlashAttention 이야기

왜 2~3년 전엔 100K짜리 컨텍스트도 없었을까요. 이유는 트랜스포머의 어텐션 연산 방식에 있습니다. 모든 토큰이 나머지 모든 토큰과 서로를 참조하기 때문에, 시퀀스 길이가 2배 늘어나면 연산량이 4배로 커지는 O(n²) 구조입니다. GPT-3를 학습할 당시 4K 컨텍스트가 이미 한계였던 이유입니다.

이 문제를 바꾼 건 하드웨어가 아니라 알고리즘이었습니다. 2022년 스탠퍼드에서 발표된 FlashAttention 논문은 어텐션 계산 결과는 똑같이 유지하면서, 데이터를 GPU의 느린 외부 메모리 대신 빠른 온칩 메모리 안에 최대한 머물도록 타일링(tiling)하는 방식으로 메모리 사용량을 O(n)으로 줄였습니다. 계산식이 달라진 게 아니라 데이터 이동 경로가 달라진 것입니다.

이 알고리즘 변화 덕분에 100K, 200K, 1M 컨텍스트가 현실적으로 가능해졌습니다. 하드웨어는 크게 달라지지 않았습니다. 다만, 컨텍스트 창이 커진 것과 모델이 그 공간을 실제로 잘 쓰는 건 별개 문제입니다. 이 차이가 섹션 3에서 수치로 드러납니다.

▲ 목차로 돌아가기

모델별로 1M을 다루는 능력이 다릅니다

1M 컨텍스트를 지원한다는 말과, 1M 안에서 정확히 찾아낸다는 말은 전혀 다릅니다. Anthropic이 Opus 4.6 공식 출시 발표에서 직접 인용한 MRCR v2(Massive Multidoc Retrieval and Comprehension) 벤치마크 결과를 보면 이 차이가 숫자로 드러납니다.

Opus 4.6는 1M 토큰 조건에서 MRCR v2 8-needle 변형 기준으로 78.3%를 기록했습니다. 반면 Sonnet 4.5는 같은 조건에서 18.5%에 그쳤습니다. (출처: Anthropic Opus 4.6 공식 출시 발표, anthropic.com/news/claude-opus-4-6, 2026.02.05) 18.5%는 사실상 찍는 수준입니다. 두 모델 모두 1M 창을 지원한다고 표시되지만, Sonnet 4.5로 1M을 쓰는 건 비용만 내고 결과를 포기하는 것과 가깝습니다.

Sonnet 4.6의 MRCR 수치는 아직 Anthropic이 공개하지 않은 상태입니다. 개선됐을 가능성이 있지만, 공식 수치가 나오기 전까지는 긴 컨텍스트 작업에 Sonnet 4.6을 쓰는 건 조심해야 합니다. 반면 독립 실험 플랫폼 claudecodecamp.com의 needle-in-a-haystack 테스트(2026.03.13)에서는 Opus 4.6이 400K 심도까지 완벽하게 정확했고, 600K에서 75% 위치 데이터는 부분적으로 혼동되기 시작했습니다.

(출처: Anthropic Opus 4.6 공식 발표, 2026.02.05 / claudecodecamp.com 실측, 2026.03.13)
※ Sonnet 4.6 MRCR 수치는 Anthropic이 공식 공개하지 않은 상태입니다.

▲ 목차로 돌아가기

“가운데는 잘 안 본다” — 실측에서 드러난 패턴

트랜스포머 모델에는 공통적으로 알려진 주의 분포 패턴이 있습니다. 컨텍스트의 앞부분과 뒷부분에 어텐션이 집중되고, 가운데 영역은 상대적으로 덜 처리됩니다. 연구자들이 ‘lost in the middle’이라고 부르는 현상입니다. (Stanford, 2023, arxiv.org/abs/2307.03172)

1M 토큰 창에서 이 문제는 훨씬 심각합니다. “가운데”가 수십만 토큰에 달하기 때문입니다. Claudecodecamp.com의 needle 실험에서 Opus 4.6는 75% 위치(즉, 컨텍스트 후반부)에서 부분 혼동이 시작됐습니다. 600K 기준 75% 위치는 약 450K 지점입니다. 중요한 정보를 1M 문서의 중간에 배치하면 Opus 4.6이라도 놓칠 수 있습니다.

실용적 함의는 간단합니다. 1M 컨텍스트를 쓸 때 모델이 반드시 참조해야 하는 핵심 정보는 컨텍스트 앞이나 뒤에 두는 게 안전합니다. 이건 Claude 고유의 문제가 아니라 현재 트랜스포머 계열 모델 전반에 해당하는 구조적 특성입니다.

▲ 목차로 돌아가기

지연 시간, 직접 재보니 이렇습니다

요금이 동일해졌어도 지연 시간(latency)은 다른 이야기입니다. Claudecodecamp.com이 스트리밍 요청으로 측정한 첫 토큰 수신 시간(TTFT) 데이터입니다. 캐시가 없는 콜드 스타트 기준입니다.

(출처: claudecodecamp.com 실측, 2026.03.13 / 1M 콜드 스타트는 지수 곡선 외삽 추정치)

콜드 스타트 시 500K에서 첫 토큰이 35초 뒤에 옵니다. 커피 한 잔 타오는 시간입니다. 1M 캐시 없는 세션을 처음 시작하면 1분 이상 대기할 수 있습니다. 다만 캐시가 따뜻한 상태(warm)에서는 500K도 3.5초 정도로 수용 가능한 수준입니다.

캐시 유효 시간은 5분입니다. 작업 중간에 6분 이상 자리를 비웠다가 돌아오면 캐시가 만료되고 다음 메시지에서 콜드 스타트 패널티를 다시 맞습니다. 자주 자리를 이동하는 작업 방식이라면 이 점이 체감 불편으로 이어집니다.

▲ 목차로 돌아가기

1M을 써야 하는 경우 vs. 쓰지 않아도 되는 경우

공식 블로그와 실측 데이터를 교차해서 보면, 1M이 진짜 힘을 발휘하는 순간과 그렇지 않은 순간이 꽤 명확하게 나뉩니다.

써야 하는 경우

• 단일 대규모 문서 분석: 코드베이스 전체, 수백 페이지짜리 계약서, 논문 묶음을 한 요청에 넣고 결과를 뽑는 경우입니다. 대화가 길어지는 게 아니라 자료가 처음부터 큰 경우에 유리합니다. 실측에서 Opus 4.6은 이 방식으로 쓸 때 가장 정확했습니다.
• 파일 교차 의존성이 깊은 코드 리뷰/디버깅: 파일 A의 함수가 파일 B의 클래스를 참조하고, 그게 파일 C의 인터페이스를 상속하는 구조라면, 청크 단위 검색보다 전체를 한 번에 올리는 게 낫습니다. Cognition 엔지니어링 팀은 Opus 4.6으로 Devin Review 에이전트를 운용하면서 버그 검출률이 올라갔다고 밝혔습니다. (출처: Anthropic Opus 4.6 공식 발표 파트너 후기, 2026.02.05)

• 컴팩션 없이 긴 에이전트 세션 유지: Claude Code에서 Max·Team·Enterprise 요금제 사용 시 Opus 4.6이 자동으로 1M 창을 씁니다. 한 서비스 제공사는 이 전환 이후 컴팩션 이벤트가 15% 줄었다고 밝혔습니다. (출처: 동일 공식 발표 파트너 후기, 2026.02.05) 15% 감소는 에이전트가 이전 맥락을 잃지 않고 더 오래 작업한다는 뜻입니다.

굳이 쓸 필요가 없는 경우

• 일반적인 Claude Code 세션: Claudecodecamp.com 실측에 따르면 대부분의 세션은 컴팩션 전까지 80~120K 토큰 정도입니다. 200K에도 못 미치는 상황에서 1M 모델을 선택해도 요금도 같고 동작도 같습니다. 추가 이득이 없습니다.
• Sonnet 4.6으로 대용량 작업: 공식 MRCR 수치가 아직 없습니다. Sonnet 4.5 기준 18.5%라는 수치가 존재하는 상황에서, Sonnet 4.6의 개선 폭이 어느 정도인지 확인 전까지는 긴 컨텍스트 작업에 Sonnet을 쓰는 건 권장하기 어렵습니다.
• 자주 자리를 비우는 작업 환경: 5분마다 캐시가 리셋되고, 그때마다 콜드 스타트 대기가 생깁니다. 500K 이상에서 30~60초 이상 대기가 반복된다면 실제 작업 흐름이 끊깁니다.

▲ 목차로 돌아가기

Q&A 5가지

▲ 목차로 돌아가기

마치며

1M 컨텍스트 GA 전환의 핵심은 두 가지입니다. 첫째, 프리미엄 요금이 사라졌다는 것 — 더 이상 200K 경계에서 청구 계산을 할 필요가 없습니다. 둘째, 그럼에도 불구하고 모든 모델이 1M을 제대로 쓸 수 있는 건 아니라는 것 — MRCR 수치가 명확하게 보여줍니다.

솔직히 말하면, 1M 설정을 켜놓는다고 해서 갑자기 생산성이 달라지는 건 아닙니다. 대부분의 일반 세션은 200K에도 안 닿습니다. 진짜 차이는 코드베이스 전체를 한 번에 올려야 하는 상황, 수백 페이지 문서를 청크로 쪼개지 않고 한 번에 분석해야 하는 상황에서 나옵니다. 그 상황에서만큼은 GA 이후 Opus 4.6의 1M이 이전과는 다른 선택지가 됐습니다.

콜드 스타트 지연, lost in the middle 편향, Sonnet 계열의 성능 제약은 아직 남아 있습니다. 이 부분은 다음 모델 업데이트에서 어떻게 달라지는지 계속 확인할 계획입니다.

▲ 목차로 돌아가기

📎 본 포스팅 참고 자료

1. Anthropic 공식 블로그 — 1M Context GA 발표 (claude.com/blog/1m-context-ga, 2026.03.13)
2. Anthropic 공식 — Claude Opus 4.6 출시 발표 (anthropic.com/news/claude-opus-4-6, 2026.02.05)
3. claudecodecamp.com — 1M Context Window 실측 실험 (claudecodecamp.com, 2026.03.13)
4. MindStudio — 1M 컨텍스트 vs RAG 비교 분석 (mindstudio.ai, 2026.03)
5. Stanford — Lost in the Middle 연구 논문 (arxiv.org/abs/2307.03172, 2023)