GA 전환으로 달라진 것 3가지

2026년 3월 13일 이전까지 Claude Sonnet 4.6의 100만 토큰 컨텍스트는 공개 베타였습니다. 200K 토큰을 초과하는 순간 입력 요금이 2배로 뛰는 구조였습니다. Opus 4.6은 아예 1M 자체가 없었습니다.

GA 이후 달라진 것은 크게 세 가지입니다. 첫째, 단일 요금 구조입니다. 200K를 넘어도 추가 요금 없이 Sonnet 4.6은 입력 백만 토큰당 3달러, Opus 4.6은 5달러가 그대로 적용됩니다. 이전엔 200K를 1토큰만 넘어도 해당 요청의 모든 입력 토큰이 2배 요금으로 재산정됐습니다. 199K짜리 요청과 201K짜리 요청의 비용 차이가 약 2배였던 구조가 사라진 것입니다.

둘째, 베타 헤더 불필요입니다. 기존에는 API 요청에 anthropic-beta: long-context-2025-01-01 헤더를 수동으로 붙여야 200K 이상 요청이 가능했습니다. 이제는 자동으로 처리됩니다. 코드 수정이 필요 없습니다.

셋째, 미디어 한도 6배 확대입니다. 요청당 이미지·PDF 페이지 한도가 기존 100개에서 600개로 늘었습니다. 대형 계약서 수십 건이나 리서치 논문 묶음을 한 번에 밀어넣는 작업이 가능해졌습니다. Claude Platform 네이티브, Amazon Bedrock, Google Vertex AI, Microsoft Foundry 모두 오늘부터 적용됩니다. (출처: Anthropic 공식 블로그, 2026.03.13, claude.com/blog/1m-context-ga)

1M 토큰이 생각보다 훨씬 복잡한 이유

100만 토큰은 숫자만 보면 단순합니다. 소설 750권 분량입니다. 중간 규모 코드베이스 전체가 들어갑니다. 그런데 “1M 컨텍스트 윈도우를 지원한다”는 말과 “1M 토큰에 걸쳐 제대로 추론한다”는 말은 완전히 다른 이야기입니다.

모든 트랜스포머 모델은 각 토큰이 자신과 다른 모든 토큰의 관계를 계산하는 ‘어텐션(attention)’ 연산을 거칩니다. 이 연산은 시퀀스 길이에 비례해 메모리가 급증합니다. 시퀀스를 두 배 늘리면 메모리는 네 배가 필요합니다. 1M 토큰 세션 하나가 수백 GB의 GPU 메모리를 독점하는 구조입니다. 이것이 Anthropic이 서버 비용을 이유로 오랫동안 프리미엄 요금을 붙였던 근거입니다.

2022년 등장한 FlashAttention 알고리즘이 이 문제를 어느 정도 해결했습니다. 메모리 사용량을 줄이는 방식으로 긴 시퀀스를 처리할 수 있게 됐고, 그 결과 Claude 2.1의 100K, Gemini 1.5의 1M이 차례로 가능해졌습니다. Gemini 1.5는 처음부터 1M 컨텍스트를 전제로 사전학습을 진행했습니다. 그러나 Claude 4.6 계열은 기존 아키텍처에서 컨텍스트 창을 확장한 구조입니다. 이 차이가 실제 품질에서 어떻게 나타나는지가 다음 섹션의 핵심입니다.

Sonnet 4.6에서 1M 꽉 채우면 생기는 일

실측 데이터가 있습니다. Claude Code Camp가 실제 API를 통해 50K에서 600K 구간까지 점진적으로 컨텍스트를 늘리며 검색 정확도를 측정했습니다. 문서 더미 안에 가짜 직원 정보(이름·ID·보너스 금액)를 숨겨두고, 모델이 얼마나 정확히 찾아내는지를 기록했습니다.

Opus 4.6의 결과는 400K까지 완벽한 정확도를 보였습니다. 600K에서 75% 위치에 숨긴 정보를 찾을 때 이름은 맞히지만 보너스 금액을 다르게 말하는 현상이 생겼습니다. Sonnet 4.6의 결과는 훨씬 빨리 무너졌습니다. 200K에서 75% 위치 검색이 흔들리기 시작했고, 400K에서는 50% 위치도 불안정했습니다. 600K에서는 핵심 정보를 찾지 못했습니다.

MRCR v2 벤치마크 공식 점수도 마찬가지입니다. Opus 4.6은 256K 구간에서 92~93%이고, 1M 구간에서 78.3%입니다. 1M에서도 업계 최고 수치입니다. 그러나 달리 보면, 1M 토큰 범위에서 약 5회 중 1회는 관련 정보를 놓친다는 의미이기도 합니다. (출처: Anthropic 공식 블로그 1M GA 발표, 2026.03.13) Sonnet 4.5는 같은 구간에서 18.5%였고, Sonnet 4.6의 점수는 아직 Anthropic이 공개하지 않았습니다.

여기서 또 하나의 함정이 있습니다. 모델은 컨텍스트 윈도우 안에서도 처음과 끝에 집중하고 중간을 놓치는 경향이 있습니다. 연구자들은 이를 “중간에서 잃어버리기(lost in the middle)”라고 부릅니다. 류 등(Liu et al., 2024)의 연구에 따르면, 관련 정보가 컨텍스트 가장자리에서 중앙으로 이동할 때 성능이 30% 이상 떨어집니다. Anthropic 자신도 Claude 2.1 시절에 긴 컨텍스트 정확도가 27%였던 것이 단 하나의 프롬프트 힌트(“아래에 가장 관련된 문장이 있습니다”)를 추가하자 98%로 올라갔다는 내부 실험 결과를 공유한 적 있습니다. 모델이 정보를 갖고 있었지만 어디에 집중해야 하는지 몰랐던 것입니다.

Anthropic 자신이 “다 쓰지 말라”고 하는 이유

GA 발표와 함께 Anthropic이 공개한 컨텍스트 엔지니어링 가이드에는 주목할 만한 문장이 있습니다. “목표는 원하는 결과의 확률을 최대화하는 최소한의 고신호 토큰 집합을 찾는 것(The goal is finding the smallest set of high-signal tokens that maximize the likelihood of your desired outcome)”입니다. 더 많이 넣을수록 좋은 게 아니라는 뜻입니다.

이 점을 가장 구체적으로 보여주는 것이 Claude Code의 컴팩션 동작 방식입니다. Claude Code는 컨텍스트가 한도의 83.5%에 도달하면 자동으로 이전 대화를 요약해 압축합니다. 200K 모델에서는 약 134K 토큰을 쓰면 압축이 시작됩니다. 1M 모델에서는 약 802K까지 압축 없이 진행됩니다. 단순 계산으로는 5배지만, 실제 효과는 다릅니다. 압축이 한 번만 일어나면 품질 손실은 미미합니다. 세 번, 네 번 반복되면 “요약의 요약의 요약”이 됩니다. 1M 창은 첫 번째 압축이 시작되는 시점 자체를 뒤로 미룰 뿐, 무한정 늘리는 게 아닙니다. Anthropic CPO가 1M 도입 이후 압축 이벤트가 15% 줄었다고 밝혔습니다. (출처: Anthropic 1M GA 블로그, 2026.03.13)

에이전트 개발 커뮤니티에서 통용되는 “12-factor agents” 프레임워크는 컨텍스트 창의 40% 이상을 채우면 “멍청한 구간(dumb zone)”에 진입한다고 규정합니다. 신호 대 잡음 비율이 무너지고, 어텐션이 분산되며, 에이전트가 실수를 시작합니다. Princeton NLP의 HELMET 벤치마크는 59개 모델을 대상으로 테스트했고, 요약 작업에서 32K를 넘을 때부터 대부분의 모델이 눈에 띄게 성능이 떨어진다는 결과를 보여줬습니다. 오픈소스 모델은 아예 무너졌습니다.

경쟁 모델과 가격 구조 비교

현재 1M 컨텍스트를 제공하는 주요 모델들의 가격 구조는 제각각입니다. 이 차이가 실사용에서 꽤 중요합니다.

지금 상황에서 1M을 장문 프리미엄 없이 제공하는 건 Claude Sonnet 4.6과 Opus 4.6뿐입니다. OpenAI와 Google은 여전히 일정 구간을 넘으면 추가 요금을 부과합니다. 이것이 Anthropic의 GA 전환이 기술 발표가 아닌 경쟁 전략이기도 한 이유입니다. 추가 요금이 없어지는 순간, 긴 컨텍스트는 특별 기능이 아닌 기본값이 됩니다.

단, 비교할 때 한 가지를 추가해야 합니다. Gemini 3 Pro의 1M MRCR 점수는 26.3%입니다. Sonnet 4.6 이전 버전인 Sonnet 4.5의 18.5%보다 높지만, Opus 4.6의 78.3%에는 한참 못 미칩니다. 1M 토큰을 갖고 있다는 것과 1M 토큰 안에서 제대로 추론한다는 것은 다른 문제입니다.

실제로 1M이 도움 되는 상황 vs. 낭비인 상황

GA 이후 1M 모델을 선택해도 표준 요금은 동일합니다. 그렇다면 모든 상황에서 1M을 켜두는 것이 합리적일까요? 직접 확인한 실측 데이터는 그렇지 않다고 보여줍니다.

도움 되는 상황: 대용량 코드베이스나 문서 전체를 한 번에 밀어넣고 단회성 분석을 요청할 때입니다. 모델이 한 번만 읽고 결과를 내는 구조이므로 컨텍스트 부패 문제가 최소화됩니다. 계약서 수십 건을 같이 검토하거나, 대형 레포지토리 전체에서 의존성 분석을 요청하는 경우가 여기에 해당합니다. Devin의 엔지니어는 200K에서는 대형 diff를 여러 조각으로 나눠야 했는데, 1M 이후 전체를 한 번에 넘기면서 크로스파일 의존성이 유지된다고 밝혔습니다. (출처: Anthropic 1M GA 블로그)

도움 되는 두 번째 상황: 여러 에이전트가 병렬로 작업하고 그 결과를 한 세션에 모아야 할 때입니다. 각 에이전트 리포트가 누적되면서 컨텍스트가 빠르게 차오르는데, 압축 없이 전체를 유지할 수 있습니다.

낭비인 상황: 일반적인 코딩 세션은 대부분 80~120K 선에서 멈춥니다. 200K에도 못 미치는 세션에서 1M 모델을 선택하는 것은 요금 변화가 없습니다. 그러나 장시간 멀티턴 대화에서 1M을 끝까지 채우려 하면 두 가지 문제가 생깁니다. 비용이 3배 이상이 되고, 앞서 설명한 “중간에서 잃어버리기” 문제가 심해집니다. Claude Code Camp의 실측에 따르면 500K 컨텍스트에서 캐시가 없는 상태로 첫 메시지를 보낼 때 응답 시작까지 30초 이상이 걸립니다. 1M에서는 60~90초로 추정됩니다. 5분 이상 자리를 비워 캐시가 만료되면 매번 이 대기 시간을 겪게 됩니다.

낭비인 두 번째 상황: 장시간 세션에서 초반 탐색 과정이 담긴 오래된 컨텍스트를 지우고 새 출발이 필요한 경우입니다. 이 경우엔 오히려 `/clear` 명령으로 컨텍스트를 정리하고 다시 시작하는 것이 1M을 유지하는 것보다 품질 면에서 낫습니다. 주의력이 분산되지 않고 지금 작업에 집중하기 때문입니다.

Q&A

마치며

100만 토큰 컨텍스트 GA는 단순한 기술 발표가 아닙니다. 추가 요금이 사라지는 순간, 장문 컨텍스트는 선택지가 아니라 기본값이 됩니다. 이전에는 “200K를 넘기면 비용을 2배 더 쓸 가치가 있는가”를 판단해야 했지만, 이제는 그 기준이 사라졌습니다.

하지만 수치를 보고 나면 한 가지는 분명합니다. 1M을 갖고 있다고 1M을 전부 잘 쓸 수 있는 게 아닙니다. Opus 4.6이 업계 최고 수준인 78.3%를 기록한다는 것은, 동시에 1M 구간에서 5번 중 1번은 놓친다는 말이기도 합니다. 컨텍스트 자체보다 어떤 정보를, 어디에 배치하는지가 여전히 더 중요합니다.

Anthropic이 스스로의 가이드에 “최소한의 고신호 토큰”을 강조하는 이유가 있습니다. 크게 열린 창이 능사가 아닙니다. 무엇을 넣을지 고르는 능력이 이제 더 중요해졌습니다.

본 포스팅 참고 자료

1. Anthropic 공식 발표 — Claude Sonnet 4.6 출시 (anthropic.com/news/claude-sonnet-4-6)
2. Anthropic 공식 블로그 — 1M 컨텍스트 GA 전환 (claude.com/blog/1m-context-ga), 2026.03.13
3. Anthropic — Claude Sonnet 4.6 System Card (anthropic.com/claude-sonnet-4-6-system-card), 2026.02.17
4. Claude Code Camp — 1M Context Window 실측 (claudecodecamp.com)
5. paddo.dev — Context Stops Being Scarce (paddo.dev/blog/million-token-context/), 2026.03.16
6. Liu et al. — Lost in the Middle, Princeton NLP, 2024 (arxiv.org/abs/2307.03172)