Claude Code 1M 컨텍스트,
공짜인 줄 알았습니다

“1M 컨텍스트 추가 요금 없음”이라는 공식 발표를 봤을 때 솔직히 “와, 이건 진짜다”라고 생각했습니다. 그런데 막상 공식 문서를 꼼꼼히 뜯어보니 이야기가 좀 달랐습니다. 구독 플랜 사용자와 API 직접 사용자의 과금 구조가 완전히 다르고, Sonnet 4.6으로 1M을 쓰면 생각보다 정확도가 보장되지 않는 상황이 있습니다. Claude Code 1M Context에 대해 공식 수치와 실측 데이터를 기반으로 정리했습니다.

1M 컨텍스트 GA, 실제로 무엇이 달라졌나

2026년 3월 13일, Anthropic이 Claude Code v2.1.75를 릴리즈하면서 1M(100만) 토큰 컨텍스트 윈도우가 베타 딱지를 떼고 정식 출시됐습니다. 공식 발표문에 딱 이렇게 나옵니다: “No long-context premium. Standard pricing applies across the full 1M window.” (출처: Anthropic 공식 블로그, claude.com/blog/1m-context-ga, 2026.03.13)

바뀐 내용을 정리하면 네 가지입니다. 첫째, Opus 4.6과 Sonnet 4.6 모두 1M 컨텍스트를 표준 가격에 지원합니다. 둘째, 베타 헤더(`anthropic-beta: max-tokens-3-5-sonnet-2024-07-15` 같은 것)를 더 이상 넣을 필요가 없습니다. 셋째, 미디어 처리 한도가 이미지 또는 PDF 기준 기존 100장에서 600장으로 6배 늘었습니다. 넷째, 요청당 속도 제한(rate limit)도 긴 컨텍스트라는 이유만으로 낮아지지 않습니다.

1M 토큰이 얼마나 큰지 감을 잡아보면, 약 75만 단어 분량입니다. 평균적인 중형 코드베이스 전체, 또는 600페이지짜리 계약서 묶음을 한 번에 집어넣을 수 있는 크기입니다. 이전에는 컨텍스트가 넘치면 Claude Code가 자동으로 컴팩션(이전 대화 요약 후 삭제)을 실행했는데, 1M 윈도우를 쓰면 이 컴팩션 이벤트가 15% 줄었다고 실사용 데이터가 말해줍니다. (출처: Anthropic 공식 블로그, 2026.03.13) 컴팩션이 줄어든다는 건 중요한 맥락을 잃어버리지 않는다는 뜻입니다.

그런데 이 발표를 읽고 “그럼 이제 마음 놓고 1M을 쓰면 되겠구나”라고 생각했다면, 조금 기다려야 합니다. 과금 구조가 누구에게 해당되느냐에 따라 완전히 달라지기 때문입니다.

구독 플랜 vs API — 과금 구조가 아예 다릅니다

이 부분을 기존 한국어 블로그들이 거의 다루지 않고 있습니다. “1M 컨텍스트, 추가 요금 없음”이라는 공식 발표는 두 가지 사용자 그룹에게 의미가 전혀 다릅니다.

구독 플랜 사용자 (Max·Team·Enterprise)

Claude Code Max($100/월 또는 $200/월), Team, Enterprise 구독자는 Opus 4.6 기준으로 1M 컨텍스트가 자동으로 활성화됩니다. 기존에는 이 기능을 쓰려면 별도 추가 사용량이 소모됐는데, 이제는 플랜 내 한도 안에서 쓸 수 있습니다. 구독 요금 안에서 1M 컨텍스트를 자유롭게 쓸 수 있다는 뜻입니다.

API 직접 사용자 — 200K 임계선이 있습니다

API를 직접 호출하는 개발자라면 이야기가 다릅니다. 공식 발표문의 “동일한 토큰당 요율”이라는 설명은 Sonnet 4.6의 베타 시절 2배 할증을 없앤 것을 말합니다. 하지만 claudecodecamp.com의 직접 측정 데이터를 보면, 입력 토큰이 200K를 넘는 순간부터 적용되는 “롱 컨텍스트 요금”이 공식 API 요금표에 여전히 존재합니다. (출처: claudecodecamp.com, 2026.03.13 업데이트)

결론부터 말씀드리면, API로 직접 사용하면서 세션이 200K 토큰을 자주 넘긴다면 비용이 2배가 되는 구간이 여전히 존재합니다. “무료”가 된 건 구독 플랜 내에서의 이야기입니다.

Sonnet 4.6으로 1M을 쓰면 생기는 문제

“Opus 4.6과 Sonnet 4.6 모두 1M 지원”이라는 발표만 보고 더 저렴한 Sonnet 4.6으로 1M 작업을 시도하는 경우가 있습니다. 이 선택이 생각보다 위험합니다.

Anthropic이 공식 발표문에서 공개한 MRCR v2(멀티 라운드 공참조 해석 — 긴 컨텍스트 안에서 정보를 얼마나 정확히 추적하는지 측정) 점수를 보면, Opus 4.6은 1M 토큰 구간에서 78.3%를 기록합니다. (출처: Anthropic 공식 스레드, 2026.03.13) 프론티어 모델 중 가장 높은 수치입니다.

반면 Sonnet 4.6의 1M 구간 MRCR 점수는 Anthropic이 공식적으로 밝히지 않았습니다. 발표문에는 Sonnet 4.6의 GraphWalks BFS(복잡한 구조 탐색 정확도) 68.4%만 언급됩니다. 이유는 아직 공개되지 않았습니다. claudecodecamp.com이 직접 측정한 실험 데이터에 따르면, 이전 세대 Sonnet 4.5는 1M 토큰에서 MRCR 18.5%로 Opus 4.6의 78.3%와 비교해 4배 이상 차이가 났습니다.

실무 기준으로 보면, 1M 이상의 긴 컨텍스트 작업에는 Opus 4.6을 쓰는 게 공식 벤치마크상 유일하게 검증된 선택입니다. Sonnet 4.6은 Sonnet 4.5보다는 나을 수 있지만, Anthropic이 아직 정확한 수치를 내놓지 않은 상태입니다.

200K 경계선을 넘는 순간 벌어지는 일

API 사용자 기준으로, 200K 토큰이라는 임계선이 얼마나 중요한지 구체적인 계산식으로 보겠습니다.

Opus 4.6 기준:
199,000 토큰 입력 → 199K × $5/M = $0.995
201,000 토큰 입력 → 201K × $10/M = $2.010
차이: 2,000 토큰 추가에 $1.015 더 발생
(추가된 2K 토큰의 실효 단가: $507.50/M — 표준가의 약 100배)

200K를 넘는 순간 그 이상의 토큰에만 할증이 붙는 게 아닙니다. 전체 토큰에 롱 컨텍스트 요율이 적용됩니다. 201K 요청은 1K 토큰만 롱 컨텍스트 구간에 있는데도 전체가 2배 요율로 계산됩니다. 경계선 근처에서 작업한다면 200K 아래를 유지하는 게 비용 면에서 결정적으로 유리합니다.

캐시(Prompt Cache)를 쓰더라도 예외가 없습니다. Opus 4.6 캐시 읽기 요금은 200K 이하에서 $0.50/M이지만, 200K를 초과하면 $1.00/M으로 그대로 2배가 됩니다. 캐시 할인(90%)은 여전히 적용되지만 베이스 가격 자체가 높아진 상태라 실질 절감 효과는 줄어듭니다.

또 하나 알아야 할 게 응답 지연입니다. claudecodecamp.com이 직접 측정한 결과, 캐시가 없는 콜드 스타트 상황에서 첫 토큰 응답 시간(TTFT)은 컨텍스트가 커질수록 급격히 늘어납니다. 500K 토큰 콜드 스타트는 35초, 1M으로 외삽하면 60~90초를 기다려야 응답이 시작됩니다. 캐시가 따뜻하게 유지된 상태면 500K에서도 3.5초 수준이지만, 캐시 TTL이 5분이라 그 이상 자리를 비웠다가 돌아오면 다시 콜드 스타트입니다.

API 사용자가 1M 컨텍스트를 쓴다면 캐시를 적극 활용하고, 세션 중간에 길게 자리를 비우는 상황을 피하는 게 현실적입니다.

1M이 진짜 유리한 상황, 딱 이 경우입니다

“대화가 길어질수록 1M이 유리하다”는 생각이 직관적으로 맞아 보이지만, 실제 데이터는 다른 이야기를 합니다.

1M 컨텍스트가 진짜 힘을 발휘하는 상황은 하나입니다. 처음에 대용량 자료를 한꺼번에 넣고, 그것을 기반으로 작업하는 경우입니다. 코드베이스 전체를 한 번에 로딩하거나, 수백 페이지 계약서 묶음을 전부 넣고 교차 분석하는 작업이 여기에 해당합니다. 이 경우 컨텍스트 로트(context rot — 긴 세션에서 정확도가 떨어지는 현상)가 최소화됩니다. 한 번 읽고 분석하는 방식이라 회화가 길어지지 않기 때문입니다.

실제로 Opus 4.6의 니들-인-헤이스택(특정 정보를 대용량 문서에서 찾아내는 능력) 테스트 결과, 400K까지는 100% 정확도를 유지하고, 600K에서 75% 지점에 심은 정보는 일부 오류가 생기기 시작합니다. (출처: claudecodecamp.com 직접 실험, 2026.03.13) 가장 중요한 정보를 컨텍스트의 앞이나 끝에 배치하는 이유입니다.

반대로, 일반적인 Claude Code 일상 세션은 대부분 80~120K 토큰 범위에서 컴팩션이 발생합니다. 200K 근처에도 가지 않는 세션이 다수입니다. 이런 작업에 1M 모델을 선택해도 비용은 같고 동작도 동일합니다. 1M을 “선택”하는 것 자체에 비용이 드는 게 아니라, 실제로 200K를 넘겼을 때 비용이 달라지기 때문입니다.

GPT-5·Gemini와 비교하면 무엇이 다를까

1M 컨텍스트가 Claude만의 독보적인 기능인지, 아니면 경쟁사와 비교했을 때 어느 정도 위치인지 짚어봤습니다.

숫자에서 한 가지 짚어야 할 게 있습니다. Gemini 3.1 Pro의 MRCR 26.3%는 Anthropic이 자체 벤치마크로 측정한 수치입니다. Gemini 1.5 Pro(1M 컨텍스트를 처음부터 염두에 두고 사전학습한 이전 세대)는 자체 테스트에서 거의 완벽한 리콜을 보인 바 있습니다. 세대가 다른 모델을 같은 기준으로 비교한 것이어서, 단순히 26.3%를 Gemini 전체의 한계로 봐서는 안 됩니다.

확인되는 사실은, GPT-5.4는 현재 256K가 상한이라 1M 비교 자체가 성립하지 않는다는 점, 그리고 Gemini는 1M 구간에서 티어 요금이 있다는 점입니다. Claude의 “추가 요금 없음(구독자 기준)”은 현재 시점에서 경쟁사 대비 명확한 차이입니다.

Q&A — 자주 나오는 질문 5가지

마치며

Claude Code 1M Context GA는 실제로 의미 있는 업데이트입니다. 특히 Max·Team·Enterprise 구독자라면 대형 코드베이스를 통째로 넣거나 수백 페이지 문서를 한 번에 처리하는 작업에서 기존과 다른 경험을 할 수 있습니다. 컴팩션이 15% 줄었다는 수치는 긴 디버깅 세션에서 맥락을 잃어버리는 빈도가 줄었다는 뜻이기도 합니다.

다만 두 가지는 기억하는 게 좋습니다. API 직접 사용자는 200K 임계선에 주의해야 합니다. 그리고 Sonnet 4.6으로 1M 작업을 진행하기 전에, Anthropic이 공식 MRCR 수치를 아직 공개하지 않은 상황임을 감안해야 합니다. 긴 컨텍스트 정확도가 검증된 건 Opus 4.6뿐입니다.

가장 실용적인 접근은 이겁니다. 대부분의 일상 코딩 세션은 100K 안에서 끝납니다. 1M이 정말 필요한 순간은 대용량 자료를 한꺼번에 분석할 때, 그리고 크로스파일 의존성이 복잡한 대형 리팩토링 작업입니다. 그 순간에 Opus 4.6으로 단발성 요청을 보내는 것이 가장 비용 효율적이고 정확도도 높습니다.

본 포스팅 참고 자료

1. Anthropic 공식 블로그 — 1M Context GA 발표 (claude.com/blog/1m-context-ga)
2. Claude Platform 공식 문서 — Context Windows (platform.claude.com/docs)
3. Claude Code Camp — 1M Context 직접 측정 분석 (claudecodecamp.com)
4. AI Tool Ranked — 1M Context GA 비교 분석 (aitoolranked.com)