Claude Opus 4.6 / Sonnet 4.6의 1M context window GA 출시 — 추가 요금 없음

Who Should Read

Claude API로 대규모 코드베이스 분석, 긴 문서 처리, 장시간 에이전트 세션을 돌리는 개발자. 특히 Claude Code로 작업하면서 컨텍스트 압축(compaction)에 불만이 있었던 사람.

Core Mechanics

• Opus 4.6($5/$25 per M tokens)과 Sonnet 4.6($3/$15 per M tokens) 모두 1M 컨텍스트 윈도우가 GA됐다. 핵심은 long-context premium이 사라졌다는 것 — 900K 토큰 요청이든 9K 토큰 요청이든 토큰당 단가가 동일하다.
• 요청당 이미지/PDF 페이지 수 제한이 100장에서 600장으로 6배 늘었다. 대형 계약서 세트나 기술 문서 묶음을 한번에 넣을 수 있게 됐다.
• Claude Platform, Microsoft Azure Foundry, Google Cloud Vertex AI에서 모두 사용 가능하고, 베타 헤더 없이 200K 넘는 요청이 자동으로 처리된다. 기존에 베타 헤더 쓰던 코드도 변경 불필요.
• Claude Code에서도 Max/Team/Enterprise 플랜 사용자는 Opus 4.6 세션에서 1M 컨텍스트를 자동으로 쓸 수 있다. 컨텍스트 압축(compaction) 빈도가 줄어들어 긴 대화에서 정보 손실이 적어진다.
• MRCR v2(장문맥 검색 벤치마크)에서 Opus 4.6이 78.3%로 프론티어 모델 중 최고 점수를 기록했다. 1M 토큰을 넣어도 정확도가 유지된다는 것이 핵심 셀링 포인트.
• 실제 사용 사례로, Cognition의 Devin Review 에이전트는 대형 diff를 200K에 못 넣어서 청크를 나눠야 했는데, 1M 컨텍스트로 전체 diff를 한번에 넣으니 크로스파일 의존성 파악이 좋아지고 리뷰 품질이 올라갔다고 한다.
• 한 사용자의 실무 경험에 따르면 compaction 이벤트가 15% 감소했고, 에이전트가 수시간 동안 초반에 읽은 내용을 잊지 않고 작업할 수 있게 됐다.
• 경쟁 맥락에서 GPT-5.4도 1M 윈도우를 제공하지만 추가 요금이 붙는다. Anthropic이 표준 가격으로 제공하는 것은 KV 캐시 경제성을 확보했다는 신호로 읽힌다.

Evidence

• 600~700K 토큰 부근에서 instruction following이 급격히 저하되는 'cliff'가 있다는 프로덕션 테스트 경험이 공유됐다. 검색(retrieval) 자체는 되지만 먼 컨텍스트의 가중치 반영이 약해진다는 것. 1M을 '넣을 수 있는 것'과 '잘 쓸 수 있는 것'은 다르다는 지적이 많았다.
• 한 개발자는 코드맵 전략(파일별 summary + public API 정리)과 자동 컨텍스트 선별로 실제 요청은 30K~80K에서 해결하고 있으며, 1M이 정말 필요한 유스케이스가 뭔지 궁금하다고 했다. 입력 정밀도를 높이면 출력 정밀도도 올라간다는 경험.
• Claude Code 사용자 중 compaction 때 모델이 핵심 맥락을 잊고 같은 실수를 반복하는 것이 고통스러웠다는 의견이 많았고, 이번 변경으로 다시 Claude를 메인 도구로 쓰겠다는 반응이 나왔다. GPT-5.4/Codex가 compaction을 더 잘 처리해서 갈아탔다가 돌아온다는 사례도.
• 추가 요금 없이 제공한다는 점 자체가 KV 캐시 최적화를 해결했다는 의미라 기술적으로 더 흥미롭다는 분석이 있었다. 윈도우 크기보다 경제성이 더 어려운 문제라는 것.
• 임베디드/하드웨어 쪽 코드에서는 Opus도 여전히 주니어 수준이라는 경험이 공유됐다. Python 같은 고수준 언어에서는 뛰어나지만 C/C++ 임베디드는 학습 데이터 부족 때문인지 한계가 있다는 의견.

How to Apply

• Claude Code로 대형 모노레포 작업 시, 기존에 수동으로 컨텍스트를 줄이거나 /compact를 자주 쓰던 워크플로우를 재검토하라. Max/Team/Enterprise 플랜이면 Opus 4.6에서 자동으로 1M이 적용되므로 compaction 없이 긴 세션을 유지할 수 있다.
• API로 대량 문서 분석(계약서, 기술 문서, 코드 리뷰)을 하는 경우, 청크를 나눠서 여러 번 호출하던 파이프라인을 단일 1M 요청으로 단순화하라. 특히 크로스레퍼런스가 필요한 작업에서 품질이 올라간다.
• 다만 600K+ 토큰 영역에서 coherence 저하 가능성이 보고되고 있으므로, 프로덕션 파이프라인에 적용하기 전에 자체 벤치마크(instruction following 테스트, needle-in-a-haystack)를 돌려서 품질 cliff를 확인하라.
• 비용 최적화 관점에서, 코드맵 + 자동 컨텍스트 선별 전략(파일별 summary 생성 → 관련 파일만 선별)을 병행하면 불필요하게 큰 컨텍스트를 쓰지 않으면서도 품질을 유지할 수 있다. 무조건 1M을 채우는 것이 최선은 아니다.

Terminology

관련 논문

• Swift로 LLM 학습시키기 Part 1: 행렬 곱셈을 Gflop/s에서 Tflop/s로 끌어올리기

  Apple Silicon에서 Swift로 직접 행렬 곱셈 커널을 구현하며 CPU, SIMD, AMX, GPU(Metal)를 단계별로 최적화해 Gflop/s에서 Tflop/s 수준까지 성능을 높이는 과정을 상세히 설명한 글이다. 프레임워크 없이 LLM 학습의 핵심 연산을 밑바닥부터 구현하고 싶은 개발자에게 Apple Silicon의 성능 한계를 체감할 수 있는 드문 자료다.

• fsync 없이 로컬 스토리지 엔진을 crash-consistent하게 만든 방법

  FractalBits가 fsync 없이 SSD 전용 KV 스토리지 엔진을 구현해 동일 조건 대비 약 65% 높은 쓰기 성능을 달성한 설계 방법을 공유했다. fsync의 메타데이터 오버헤드를 피하기 위해 사전 할당, O_DIRECT, SSD 원자 쓰기 단위 정렬 저널을 조합한 구조가 핵심이다.

• Google Chrome, 사용자 동의 없이 4GB AI 모델(Gemini Nano)을 몰래 설치

  Google Chrome이 사용자 동의 없이 Gemini Nano 4GB 모델 파일을 자동 다운로드하고, 삭제해도 재다운로드되는 문제가 발견됐다. GDPR 위반 가능성과 수십억 대 기기에 적용될 때의 환경 비용 문제가 제기되고 있다.

• OpenAI가 대규모 저지연 Voice AI를 제공하는 방법

  OpenAI가 9억 명 이상의 사용자에게 실시간 음성 AI를 제공하기 위해 WebRTC 스택을 어떻게 재설계했는지 설명하는 글로, relay + transceiver 분리 아키텍처의 설계 결정과 trade-off를 상세히 다룬다.

• Truncated Decoding Tree의 결정론적 탐색을 통한 효율적인 Test-Time Inference

  Self-consistency의 중복 샘플링 낭비를 없애는 결정론적 트리 탐색 디코딩 기법 DLE로 수학/코드 추론 성능과 속도를 동시에 개선

• GoModel – Go로 작성된 오픈소스 AI Gateway

  OpenAI, Anthropic, Gemini 등 여러 AI 프로바이더를 하나의 OpenAI 호환 API로 묶어주는 Go 기반 오픈소스 AI 게이트웨이로, LiteLLM의 컴파일 언어 대안이다.

Related Resources

• https://claude.com/blog/1m-context-ga