Claude Opus·Sonnet 4.6 1M 컨텍스트 정식 출시, 실무에서 뭐가 달라지나

2026년 3월 14일 기준 Anthropic의 Claude 4.6 문서와 제품 페이지는 Claude Opus 4.6과 Sonnet 4.6 모두 1M 컨텍스트를 핵심 능력으로 안내하고 있습니다. 실무적으로는 이제 “긴 문맥이 되냐”보다 “어떤 단계에 Sonnet을 쓰고, 어떤 판단만 Opus로 올릴지”가 더 중요한 문제가 됐습니다.

저 사실 1M 컨텍스트 얘기 나오면 반쯤 흘려들었습니다.

“그래 봤자 PDF 더 많이 넣는 얘기 아닌가?” 싶었거든요.

근데 이번에는 느낌이 좀 달랐어요.

왜냐면 1M이 Opus 전용 무기가 아니라 Sonnet 4.6까지 같이 올라오면서, 실무 설계의 기준선 자체가 바뀌었기 때문입니다.

예전에는 긴 문맥이 필요하면 일단 비싼 모델부터 떠올렸어요.

이제는 그 반대예요.

기본은 Sonnet 4.6, 정말 어려운 판단만 Opus 4.6.

토큰 천장보다 라우팅이 더 중요해졌습니다.

먼저 팩트부터 짚고 가자

Anthropic 공식 문서 기준으로 지금 확인되는 핵심은 이렇습니다.

항목	Claude Sonnet 4.6	Claude Opus 4.6
출시일	2026년 2월 17일	2026년 2월 5일
포지션	속도, 비용, 지능 균형형	최고 성능, 장기 작업형
컨텍스트	1M 지원	1M 지원
최대 출력	64K	128K
입력 가격	$3 / 1M tokens	$5 / 1M tokens
출력 가격	$15 / 1M tokens	$25 / 1M tokens
사고 방식	adaptive thinking + effort	adaptive thinking + effort
눈에 띄는 차이	대부분의 실무 기본값으로 좋음	복잡한 오케스트레이션과 깊은 추론에 강함

여기서 중요한 포인트가 하나 있어요.

문서 표현이 완전히 한 줄로 정리돼 있지는 않습니다.

Anthropic의 2026년 2월 5일, 2월 17일 릴리즈 노트는 1M 컨텍스트를 beta라고 적고 있어요.

반면 2026년 3월 14일 기준 최신 Claude 4.6 문서는 Opus 4.6과 Sonnet 4.6이 둘 다 1M 컨텍스트를 지원한다고 정면으로 적고 있습니다.

제품 페이지도 1M을 전면에 내세우고 있고요.

그래서 실무자는 이렇게 이해하는 게 제일 안전합니다.

상품/메시징 관점에서는 사실상 전면 배치가 시작됐고, API 세부 동작이나 채널별 가용성 표기는 아직 beta 흔적이 남아 있는 과도기다.

이거 은근 중요합니다.

괜히 “완전 정식이다”라고 믿고 Bedrock이나 Vertex에서 바로 같은 조건을 기대하면, 문서 한 줄 때문에 멘탈이 삐끗할 수 있거든요.

이번에 진짜 달라진 건 1M 숫자보다 모델 선택 방식이다

예전에는 긴 컨텍스트 자체가 프리미엄 기능처럼 느껴졌어요.

그러다 보니 대형 문서 분석, 큰 코드베이스 정리, 길게 이어지는 에이전트 작업은 자연스럽게 Opus 쪽으로 생각이 기울었습니다.

그런데 Sonnet 4.6도 1M 컨텍스트와 adaptive thinking을 같이 가져오면서 판이 바뀌었어요.

이제 질문이 달라집니다.

“긴 문맥이 가능한가?”가 아니라,

“이 작업이 정말 Opus의 깊은 추론과 128K 출력을 필요로 하는가?”로 바뀌는 거예요.

이 차이가 실무에서는 꽤 큽니다.

왜냐면 Sonnet 4.6 가격은 Opus 4.6보다 입력, 출력 모두 약 60% 수준이니까요.

같은 긴 문맥을 다룰 수 있다면, 대부분의 팀은 먼저 Sonnet 4.6으로 붙여보고 막히는 지점만 Opus로 올리는 게 맞습니다.

쉽게 말해서 이거예요.

이제 Opus는 “긴 글 읽는 모델”이 아니라 “정말 어려운 판단 맡기는 모델” 쪽으로 더 선명해졌습니다.

실무에서 바로 달라지는 포인트 5가지

1. 대형 문서 QA의 시작점이 Opus가 아니라 Sonnet이 된다

예전에는 회의록, PRD, 정책 문서, 로그, 스프레드시트 설명까지 한 번에 묶어 읽히려면 괜히 겁부터 났어요.

“이거 Sonnet으로 넣었다가 괜히 날리는 거 아냐?” 싶은 불안이 있었거든요.

그런데 이제 Sonnet 4.6도 긴 문맥을 기본 능력으로 들고 오면서, 문서 기반 분석의 기본값이 바뀝니다.

예를 들면 이런 작업들요.

300페이지짜리 제안서 + 기존 계약서 + 내부 FAQ 비교
큰 저장소의 README, ADR, 이슈 로그, 테스트 실패 로그 동시 분석
고객 인터뷰 20개 묶어서 반복 패턴 찾기

이런 건 이제 “일단 Sonnet으로 시작”이 훨씬 자연스러워졌어요.

Opus는 그다음입니다.

분쟁 리스크가 크거나, 문서 간 충돌 해석이 필요하거나, 최종 전략안을 뽑아야 할 때 올리면 됩니다.

2. 비용 최적화의 핵심이 프롬프트 압축에서 모델 라우팅으로 넘어간다

지금까지는 긴 문맥이 비싸니까 요약하고, 또 요약하고, 필요한 조각만 잘라 넣는 데 에너지를 많이 썼죠.

물론 그 습관이 완전히 사라지진 않습니다.

근데 이제는 비용 절약의 승부처가 조금 옮겨가요.

“얼마나 잘 줄였나”보다 “어떤 단계를 어느 모델에 태웠나”가 더 커집니다.

예를 들어 리서치 수집, 문서 정리, 초안 뼈대 작성은 Sonnet 4.6으로 충분한 경우가 많아요.

반대로 최종 의사결정, 다중 에이전트 통제, 긴 출력이 필요한 설계 문서는 Opus 4.6이 값어치를 합니다.

즉,

수집은 저렴하게 넓게
합성은 기본 모델로 안정적으로
판단은 비싸더라도 필요한 순간만

이 구조가 전보다 더 또렷해졌습니다.

3. “검색 후 필터링” 파이프라인이 더 현실적이 됐다

Claude 4.6 문서에서 내가 제일 반가웠던 부분은 1M 자체보다 이거였어요.

web search, web fetch, code execution 조합이 더 실무형으로 붙기 시작했다는 점.

Anthropic은 Claude 4.6에서 web search와 web fetch에 dynamic filtering을 붙였고, web search 또는 web fetch와 함께 쓰는 code execution은 추가 과금 없이 쓸 수 있다고 안내합니다.

이게 왜 좋으냐면요.

그동안은 검색 결과를 그냥 잔뜩 긁어와서 컨텍스트에 밀어 넣는 순간, 긴 문맥이 있어도 금방 더러워졌어요.

노이즈가 너무 많았거든요.

그런데 이제는 검색 결과를 코드로 먼저 거르고, 필요한 결과만 문맥으로 올리는 흐름이 표준 기능에 가까워졌습니다.

실무 체감은 이겁니다.

1M로 더 많이 넣는 시대가 아니라, 1M를 더 깨끗하게 쓰는 시대로 가고 있다.

4. 장기 실행 에이전트는 “계속 이어서 일하기”가 더 중요해진다

Opus 4.6 쪽은 compaction API도 같이 보셔야 합니다.

이건 서버 쪽에서 긴 대화를 요약해 이어 가는 기능인데, 길게 달리는 코딩 세션이나 리서치 세션에서 꽤 의미가 있어요.

예전에는 컨텍스트가 길어지면 결국 사람이 중간 요약을 던져서 다시 태워야 하는 경우가 많았죠.

물론 지금도 완전 자동 천국은 아닙니다.

근데 방향이 확실해졌어요.

긴 컨텍스트 자체보다, 긴 일을 끊기지 않게 계속 이어가는 기능이 모델 경쟁력의 일부가 됐습니다.

그래서 Opus 4.6은 단순히 “더 똑똑한 모델”이 아니라, 장기 실행 에이전트를 위한 운영 모델처럼 보입니다.

5. Opus 4.6의 128K 출력은 문서 생성 계열에서 체감이 크다

이건 은근히 많이 놓칩니다.

사람들은 1M 입력만 보고 와 하고 끝나요.

근데 실무에서는 출력 제한도 진짜 중요합니다.

Opus 4.6은 최대 128K 출력까지 지원합니다.

이 말은 곧,

대형 마이그레이션 계획서
세부 구현 초안이 포함된 기술 설계서
다단계 리서치 보고서
긴 패치 설명과 검증 체크리스트

같이 “생각도 길고 결과물도 길어야 하는 작업”에서 훨씬 유리하다는 뜻이에요.

Sonnet 4.6은 대부분의 일상 작업에 충분하지만, 결과물 자체가 거대해지는 순간 Opus 쪽으로 기울 이유가 분명해졌습니다.

그래서 나는 어떻게 나눠 쓸 거냐

내 기준에서는 이렇게 가는 게 제일 현실적입니다.

작업 종류	먼저 쓸 모델	Opus로 올리는 조건
대형 문서 요약, 비교, 질의응답	Sonnet 4.6	해석 충돌이 많고 책임 비용이 클 때
저장소 전체 맥락 파악, 버그 조사	Sonnet 4.6	여러 설계 대안을 비교해야 할 때
초안 작성, 리서치 패키지 정리	Sonnet 4.6	전략적 논지와 긴 출력이 필요할 때
다중 에이전트 오케스트레이션	Opus 4.6	처음부터 Opus 권장
깊은 리서치, 아키텍처 판단	Opus 4.6	기본값
긴 보고서, 128K 가까운 출력	Opus 4.6	기본값

핵심은 이거예요.

1M이 양쪽에 다 들어오면, 기본 모델은 Sonnet으로 내려오고 Opus는 더 비싸지만 더 또렷한 역할을 맡게 됩니다.

예전보다 역할 분담이 쉬워진 거죠.

내 워크플로우에 대입하면 뭐가 바뀌나

나는 원래 에이전트 팀, 리서치 자동화, 블로그 파이프라인 같은 걸 계속 만지작거리고 있잖아요.

이런 워크플로우에서는 1M 컨텍스트가 “파일을 왕창 넣는 자유”보다 “중간 압축을 덜 해도 되는 여유”로 느껴집니다.

차이가 꽤 큽니다.

예를 들어 블로그 파이프라인에서는 보통 이런 재료가 동시에 필요해요.

공식 문서 링크
기존에 써둔 관련 글
내부 메모
비교 대상 제품 정보
SNS 반응이나 발표 문구

예전에는 여기서 뭘 빼야 할지부터 고민했어요.

이제는 Sonnet 4.6으로도 초반 묶음 작업을 더 넉넉하게 시작할 수 있습니다.

그리고 마지막 판단, 논지 압축, 긴 문서 출력은 Opus 4.6으로 넘기는 방식이 더 자연스러워졌어요.

이건 내가 2월에 에이전트 팀 비용 실험하면서 느꼈던 흐름하고도 이어집니다.

당시에는 같은 작업도 구조를 잘 나누면 비용을 크게 줄일 수 있었어요.

그러니까 이번 1M 변화의 핵심도 결국 같습니다.

무조건 큰 모델 하나가 다 먹는 구조가 아니라, 큰 문맥을 여러 단계로 다루는 구조가 더 강해진다.

1M이 있다고 해서 설계가 사라지는 건 아닙니다.

오히려 설계가 더 중요해져요.

내가 느낀 점

솔직히 나는 이번 변화를 “토큰 자랑”으로 보면 좀 아깝다고 봐요.

물론 1M이라는 숫자는 멋있습니다.

근데 실무자는 숫자에 취하면 안 돼요.

진짜 중요한 건 Sonnet 4.6이 여기까지 올라왔다는 사실입니다.

예전 같으면 긴 문맥, 복잡한 작업, 에이전트 워크플로우 얘기만 나오면 바로 Opus부터 열었을 텐데, 이제는 그 출발점이 확실히 내려왔거든요.

이게 팀 운영에는 훨씬 큰 변화예요.

모든 작업을 최고가 모델로 돌리지 않아도 된다는 확신이 생기니까요.

그리고 Opus 4.6도 덜 애매해졌습니다.

“그냥 더 좋은 모델”이 아니라,

“깊은 추론, 긴 출력, 장기 오케스트레이션에 돈 낼 이유가 있는 모델”로 포지션이 또렷해졌어요.

솔직한 마음

한편으로는 아직 문서가 좀 덜 정리된 느낌도 있습니다.

어떤 페이지는 1M을 전면 capability처럼 말하고, 어떤 페이지는 아직 beta라고 적고 있거든요.

실무자 입장에서는 이런 게 제일 사람 열받게 합니다.

“그래서 지금 내 경로에서 되는 거야, 안 되는 거야?”

이 질문이 남으니까요.

그래서 나는 당분간 1M 관련 기능을 볼 때 무조건 세 가지를 같이 확인할 생각입니다.

내가 쓰는 채널이 Claude API인지
Bedrock, Vertex, Foundry 중 어디인지
beta header나 별도 제한이 남아 있는지

이건 좀 귀찮아요.

근데 귀찮다고 확인 안 하면 더 큰 귀찮음이 옵니다.

AI 쪽은 늘 그렇죠.

멋진 발표 한 줄보다 설정값 한 줄이 더 무섭습니다.

앞으로 할 것들

이번 변화로 내가 바로 적용할 액션은 세 가지예요.

첫째, 긴 문서 리서치와 초안 합성은 Sonnet 4.6 기본값으로 테스트할 겁니다.

둘째, 최종 전략 문서나 긴 설계 출력만 Opus 4.6으로 올려서 비용 대비 체감을 다시 재보려고 해요.

셋째, web search + dynamic filtering 조합을 붙여서 “긴 문맥을 많이 넣는 구조”보다 “긴 문맥을 깨끗하게 유지하는 구조”를 먼저 개선할 생각입니다.

아마 앞으로 좋은 에이전트 시스템은 이렇게 갈 거예요.

큰 문맥 하나에 몰아 넣는 시스템이 아니라,

필요한 걸 찾고, 걸러서 올리고, 필요한 순간만 깊게 생각하는 시스템.

그게 진짜 실무형입니다.

자주 나올 질문들

Q1. 이제 Sonnet 4.6만 써도 되는 거 아닌가?

대부분의 시작점은 맞아요.

긴 문맥, 속도, 가격 균형을 같이 보려면 Sonnet 4.6이 훨씬 매력적입니다.

다만 최종 판단의 정확도, 복잡한 오케스트레이션, 128K 출력이 필요한 작업은 여전히 Opus 4.6이 낫습니다.

Q2. Opus 4.6은 언제 써야 제값을 하나?

작업이 길고, 여러 단계 판단이 엮이고, 결과물도 길 때요.

예를 들면 복잡한 기술 설계, 다중 에이전트 통제, 대규모 마이그레이션 계획서, 깊은 리서치 보고서 같은 것들입니다.

Q3. 1M 컨텍스트면 저장소 전체를 다 넣고 끝내면 되나?

그건 아직 환상에 가깝습니다.

실무에서는 여전히 중요한 정보 우선순위, 검색, 필터링, 중간 요약이 필요해요.

1M은 설계를 없애는 기능이 아니라 설계의 여유 폭을 넓혀주는 기능에 더 가깝습니다.

Q4. 정식 출시라면서 왜 공식 문서에 beta라는 말이 남아 있나?

2026년 3월 14일 기준으로 Anthropic 문서에는 과도기 흔적이 있습니다.

Claude 4.6 소개 문서와 제품 페이지는 1M을 핵심 capability로 밀고 있지만, 일부 릴리즈 노트와 가용성 문구에는 beta 표현이 남아 있어요.

그래서 실제 적용 전에는 사용 경로별 문서를 꼭 다시 확인하는 게 안전합니다.

Q5. 비용 차이는 얼마나 체감되나?

단가만 보면 Sonnet 4.6은 입력 $3, 출력 $15이고, Opus 4.6은 입력 $5, 출력 $25입니다.

긴 문맥을 다루는 일을 자주 한다면 이 차이는 금방 커집니다.

그래서 “처음부터 Opus”보다 “먼저 Sonnet, 막히면 Opus”가 대부분의 팀에서 현실적인 운영 전략이 됩니다.

Q6. web search와 code execution 변화는 왜 중요하다고 보나?

검색 결과를 그대로 쌓아 넣는 구조는 긴 컨텍스트가 있어도 금방 지저분해집니다.

반대로 검색 후 필터링이 좋아지면 같은 1M를 훨씬 효율적으로 쓸 수 있어요.

긴 문맥 시대일수록 retrieval 품질이 더 중요해지는 이유입니다.

내 결론

Claude Opus 4.6과 Sonnet 4.6의 1M 컨텍스트 확장은 분명 큰 변화입니다.

근데 진짜 포인트는 “이제 더 많이 넣을 수 있다”가 아닙니다.

이제 Sonnet을 기본값으로 삼고, Opus를 정말 어려운 구간에만 쓰는 설계가 가능해졌다는 것.

실무는 보통 여기서 돈도 아끼고 품질도 챙깁니다.

한마디로 정리하면 이렇습니다.

1M 시대의 승부처는 토큰 숫자가 아니라 모델 라우팅이다.

이제 누가 더 길게 읽느냐보다,

누가 더 똑똑하게 나눠 쓰느냐가 중요합니다.