Claude Sonnet 5 출시와 Managed Agents 업데이트: 1M 컨텍스트 운영 체크포인트

요약: Anthropic은 2026년 6월 말 Claude Sonnet 5를 Claude API에 공개했고, Managed Agents 관련 기능도 같이 확장했다. Sonnet 5는 1M 토큰 컨텍스트, 128k 최대 출력, 기본 adaptive thinking, 새 토크나이저를 제공한다. 동시에 세션 이벤트 델타, 세션 페이지네이션, 세션별 agent override, vault credential 주입 위치, lifecycle webhook이 추가됐다. 단순 모델 교체로 보면 놓치는 부분이 많다. 이 업데이트는 장문 컨텍스트 기반 에이전트를 운영하는 팀의 비용·프롬프트·관측성·보안 설계를 한 번에 건드린다.

무엇이 바뀌었나

공식 릴리즈 노트 기준으로 Claude Sonnet 5의 중요한 변경점은 다섯 가지다. 첫째, 1M 토큰 컨텍스트 윈도우를 지원한다. 둘째, 최대 출력은 128k 토큰이다. 셋째, Claude Sonnet 4.6과 비슷한 도구와 플랫폼 기능을 제공하지만 Priority Tier는 지원하지 않는다. 넷째, adaptive thinking이 기본 활성화되고, 기존 manual extended thinking 설정은 제거됐다. 다섯째, 새 토크나이저 때문에 같은 텍스트라도 약 30% 더 많은 토큰으로 계산될 수 있다. 정확한 증가는 콘텐츠와 워크로드에 따라 다르다.

가격도 확인해야 한다. 출시 안내에는 2026년 8월 31일까지 introductory pricing으로 MTok당 입력 $2, 출력 $10이 제시됐고, 이후 표준 가격은 $3 / $15로 안내됐다. 긴 컨텍스트를 적극적으로 쓰는 팀은 단가만 볼 것이 아니라 토크나이저 변화와 출력 길이 증가까지 같이 계산해야 한다. 1M 컨텍스트가 가능하다고 해서 모든 문서를 통째로 넣는 방식이 경제적이라는 뜻은 아니다.

마이그레이션에서 가장 위험한 부분

가장 먼저 볼 것은 thinking 파라미터다. 이전 모델에서 thinking: {type: 'enabled', budget_tokens: N} 같은 수동 확장 사고 설정을 쓰고 있었다면 Sonnet 5에서는 400 에러가 날 수 있다. sampling parameter도 비기본 temperature, top_p, top_k를 설정하면 400 에러가 반환된다고 안내됐다. 모델 이름만 바꾸고 운영에 넣으면 일부 요청이 조용히 실패하는 것이 아니라 명시적으로 깨질 수 있다. SDK 래퍼나 사내 gateway에서 모델별 파라미터 allowlist를 두는 편이 안전하다.

두 번째는 토큰 비용이다. 새 토크나이저가 같은 텍스트를 평균적으로 더 많은 토큰으로 계산할 수 있다는 것은 캐시 전략과 chunking 전략에 직접 영향을 준다. 예를 들어 기존에 700k 토큰 문서 묶음이 안전하다고 봤던 파이프라인이 Sonnet 5에서는 900k 이상으로 튈 수 있다. 입력이 긴 RAG, 법무 검토, 코드베이스 분석, 콜센터 로그 분석은 배치 전 token estimate를 다시 측정해야 한다.

세 번째는 출력 제어다. 128k 출력은 매력적이지만, 프론트엔드나 webhook consumer가 그 길이를 감당하지 못할 수 있다. 긴 출력이 필요한 작업과 아닌 작업을 구분하고, 기본 max_tokens를 보수적으로 둬야 한다. 보고서 생성처럼 긴 출력이 필요한 경우에도 목차, 섹션별 스트리밍, 중간 저장을 설계하는 것이 좋다.

Managed Agents 업데이트가 의미하는 것

이번 릴리즈 노트에서 모델보다 더 실무적인 부분은 Managed Agents다. 세션 이벤트 스트림의 event deltas는 agent message가 완성되기 전에 텍스트 preview를 받을 수 있게 한다. 사용자 대기 시간이 긴 에이전트 제품에서는 이 기능이 체감 품질을 크게 바꾼다. 단, preview는 최종 메시지가 아니므로 UI에서 확정 결과처럼 저장하면 안 된다. 로그에는 delta와 final을 구분해야 한다.

세션 listing의 backward pagination은 운영 콘솔과 감사 로그에서 중요하다. 장애 조사 중 ‘이 세션 직전 상태’를 찾을 수 있어야 하는데, next cursor만 있으면 뒤로 돌아가는 UX가 불편하다. prev_page cursor 지원은 작아 보이지만 운영자 도구 품질을 높인다.

세션별 agent override는 더 큰 변화다. 기존 agent 정의를 바꾸지 않고 특정 세션에서 model, system prompt, tools, MCP servers, skills를 교체할 수 있다. A/B 테스트, 긴급 핫픽스, 고객별 도구 제한에 유용하다. 반대로 무분별하게 쓰면 같은 agent 이름인데 세션마다 실제 동작이 달라져 재현성이 떨어진다. override를 적용한 세션은 반드시 별도 metadata와 감사 로그를 남겨야 한다.

vault credential의 injection_location도 보안팀이 봐야 한다. credential 값을 outbound request header, body, 또는 둘 다에 주입할 수 있다는 것은 외부 API 연동 유연성을 높이지만, 민감정보가 예상하지 못한 body 로그에 남을 위험도 만든다. 기본은 header 전용으로 두고, body 주입은 API가 요구하는 경우에만 허용하는 정책이 안전하다.

마지막으로 agent, deployment, deployment run lifecycle webhook은 폴링 의존도를 줄인다. 새 agent 버전 발행, deployment pause, scheduled run 실패를 이벤트로 받을 수 있다. 에이전트 운영팀은 이 webhook을 Slack 알림 정도로만 쓰지 말고, 실패 run 자동 재시도, owner 알림, incident ticket 생성까지 연결하는 편이 좋다.

1M 컨텍스트를 실제로 쓰는 방법

긴 컨텍스트는 ‘검색 없이 다 넣기’가 아니라 ‘검색 실패 비용을 줄이는 선택지’로 봐야 한다. 실무에서는 세 단계 접근이 낫다. 첫째, 요청에 반드시 필요한 문서만 선별한다. 둘째, 긴 문서를 넣더라도 요약본과 원문 위치 인덱스를 함께 넣는다. 셋째, 모델 출력에는 근거 위치를 요구한다. 1M 컨텍스트에서도 모델이 모든 내용을 균일하게 잘 쓰는 것은 아니다. 긴 입력일수록 평가 케이스가 더 중요하다.

코드베이스 분석을 예로 들면, 전체 repo를 무작정 넣는 대신 dependency graph, 최근 변경 파일, failing test, 관련 ADR, API schema를 우선 넣는다. 그 다음 필요할 때만 주변 파일을 추가한다. 긴 컨텍스트는 사고를 대체하지 않는다. 좋은 컨텍스트 큐레이션을 더 크게 확장해주는 도구다.

실행 체크리스트

• Sonnet 5 전환 전 gateway에서 temperature, top_p, top_k, manual extended thinking 사용 여부를 검사한다.
• 대표 입력 20~50개로 새 토크나이저 기준 토큰 증가율을 측정하고 비용표를 다시 만든다.
• max output 기본값을 보수적으로 두고, 긴 보고서 작업만 별도 프로파일을 사용한다.
• event deltas는 preview로 표시하되 final message와 분리 저장한다.
• agent override 사용 시 model, prompt, tools, MCP server, skill 차이를 audit metadata로 남긴다.
• credential body 주입은 예외 승인 방식으로 제한한다.
• lifecycle webhook을 장애 대응 루프에 연결한다. 배포 실패, scheduled run 실패, agent pause를 사람이 뒤늦게 발견하는 구조는 피한다.

Sonnet 5의 핵심은 큰 컨텍스트 하나가 아니다. 모델 동작 방식, API 파라미터, 비용 계산, managed agent 운영 기능이 같이 바뀌었다는 점이다. 개발팀은 ‘성능이 좋아졌으니 교체’가 아니라 ‘운영 계약이 달라졌으니 재검증’으로 접근해야 한다.