Anthropic이 Claude Sonnet 5를 공개했습니다. 모델 ID는 claude-sonnet-5이고, Claude Sonnet 4.6의 drop-in upgrade로 설명됩니다. 하지만 “모델 ID만 바꾸면 끝”이라고 보기에는 운영상 확인할 항목이 꽤 많습니다. adaptive thinking 기본 활성화, sampling parameter 제한, manual extended thinking 제거, 새 tokenizer로 인한 약 30% 토큰 증가가 핵심입니다.
이 글은 Claude Sonnet 5 마이그레이션, 1M token context, adaptive thinking, Claude API 400 error, 토큰 비용 최적화를 찾는 개발자를 위한 실무 가이드입니다. API 변경 표를 외우는 것보다, 배포 전에 어떤 코드를 점검해야 하는지에 집중합니다.
Claude Sonnet 5는 1M token context window를 기본으로 지원합니다. max output token은 128k이며, Claude Sonnet 4.6과 같은 도구 및 플랫폼 기능을 대부분 유지합니다. 단, Priority Tier는 지원되지 않습니다. 가격은 표준 기준 입력 $3/MTok, 출력 $15/MTok이고, 2026년 8월 31일까지는 introductory pricing으로 $2/$10이 적용됩니다.
가장 큰 운영 변화는 세 가지입니다. 첫째, adaptive thinking이 기본으로 켜집니다. 둘째, temperature, top_p, top_k를 non-default로 설정하면 400 error가 납니다. 셋째, thinking: {type: "enabled", budget_tokens: N} 형태의 manual extended thinking은 제거됐고 400 error가 납니다.
여기에 새 tokenizer가 붙습니다. Anthropic 문서에 따르면 같은 텍스트가 Claude Sonnet 4.6 대비 약 30% 더 많은 토큰으로 계산될 수 있습니다. 1M 컨텍스트가 커 보이지만, 기존 모델 기준으로 계산한 문서 길이를 그대로 믿으면 안 됩니다.
Sonnet 4.6에서는 thinking 필드가 없으면 thinking 없이 실행됐습니다. Sonnet 5에서는 같은 요청이 adaptive thinking으로 실행됩니다. 이 변화는 품질에는 도움이 될 수 있지만, 응답 길이와 지연시간, max_tokens 예산에 영향을 줍니다.
Claude API에서 max_tokens는 최종 답변만이 아니라 thinking과 response text를 포함한 총 출력 제한으로 봐야 합니다. 기존에 max_tokens를 빠듯하게 잡아둔 서비스라면 Sonnet 5 전환 후 출력이 잘리거나, 예상보다 짧은 답이 나올 수 있습니다. 특히 코드 생성, 긴 리포트, JSON output처럼 끝까지 완성돼야 하는 작업은 사전 테스트가 필요합니다.
thinking을 끄고 싶다면 thinking: {type: "disabled"}를 명시합니다. 다만 모든 요청에서 끄는 것은 추천하지 않습니다. 단순 분류, 짧은 추출, 포맷 변환은 disabled로 비용과 지연시간을 줄이고, 설계 검토, 코드 수정, 다단계 분석은 adaptive로 두는 식의 라우팅이 현실적입니다.
Sonnet 5는 temperature, top_p, top_k를 non-default로 받지 않습니다. 기존 코드에서 모델별 기본 config를 공통으로 주입하는 구조라면 여기서 바로 400 error가 날 수 있습니다. 예를 들어 모든 provider 요청에 temperature: 0.2를 넣는 wrapper가 있으면 Sonnet 5 요청은 실패합니다.
해결책은 모델별 capability map을 두는 것입니다. “Claude Sonnet 5는 sampling override 불가”, “OpenAI 특정 모델은 temperature 지원”, “일부 reasoning 모델은 reasoning effort만 허용”처럼 provider와 model ID 기준으로 허용 필드를 필터링해야 합니다. 프롬프트 레벨에서 출력 스타일을 제어하고, 파라미터는 정말 지원되는 모델에만 넣는 방식이 안전합니다.
실무에서는 API client에 request sanitizer를 두는 편이 좋습니다. 호출 직전에 모델 ID를 보고 지원하지 않는 필드를 제거하거나, 개발 환경에서는 에러를 던져 잘못된 설정을 빨리 찾게 합니다. production에서 조용히 제거할지, 실패시킬지는 팀의 운영 성향에 따라 다릅니다.
같은 문서가 약 30% 더 많은 토큰으로 계산된다는 점은 비용과 context budgeting에 직접 영향을 줍니다. per-token 가격이 같아도 토큰 수가 늘면 요청 비용은 올라갑니다. 또한 1M token context는 여전히 크지만, 같은 텍스트 기준으로 이전보다 담을 수 있는 실제 글자량은 줄어들 수 있습니다.
RAG 파이프라인은 특히 주의해야 합니다. 기존에 top-k chunk를 고정해두고 “전체가 800k 안에 들어간다”고 계산했다면 Sonnet 5 기준으로 다시 세야 합니다. chunk size, overlap, reranking threshold, citation 포함 여부를 재조정해야 합니다. 장문 문서 요약도 map-reduce 단계의 batch size를 다시 잡아야 합니다.
비용 테스트는 간단히 시작할 수 있습니다. 대표 요청 50~100개를 뽑아 Sonnet 4.6 기준 token count와 Sonnet 5 기준 token count를 비교합니다. 평균 증가율만 보지 말고 p90, p95를 보세요. 특정 언어, 코드 블록, JSON, markdown table에서 증가폭이 더 클 수 있습니다.
첫 단계는 모델 ID 변경이 아니라 호출 로그 수집입니다. 지난 7~14일 요청 중 대표 샘플을 뽑아 입력 길이, 출력 길이, 에러율, latency, 비용을 봅니다. 그다음 Sonnet 5 sandbox에서 같은 요청을 replay합니다.
둘째, request schema를 정리합니다. manual extended thinking을 쓰는 곳은 adaptive thinking과 effort 기반으로 바꿉니다. sampling parameter는 제거합니다. assistant prefill을 기대하는 코드가 있다면 Sonnet 4.6에서도 이미 지원되지 않았지만, 구조화 출력이나 system prompt 지시로 대체해야 합니다.
셋째, output validation을 강화합니다. thinking 기본 활성화와 tokenizer 변화 때문에 응답 길이와 형식이 달라질 수 있습니다. JSON schema validation, markdown section count, citation presence, tool result consistency 같은 검사를 붙여야 합니다.
고객 지원 챗봇은 adaptive thinking을 전부 켜기보다 intent classification은 disabled, 환불 정책 해석이나 복잡한 이슈 분석은 adaptive로 나누는 것이 좋습니다. 코드 리뷰 봇은 adaptive를 기본으로 두되, diff가 작은 경우만 빠른 경로를 둘 수 있습니다. 문서 분석 제품은 1M context를 활용하되, “전문을 다 넣는 것”보다 검색과 요약을 섞는 편이 비용 예측에 유리합니다.
보안 관련 제품은 refusal 처리를 반드시 구현해야 합니다. Sonnet 5는 Sonnet-tier 최초로 real-time cybersecurity safeguards를 포함하며, 금지되거나 고위험인 사이버 요청은 stop_reason: "refusal"로 성공 HTTP 200 안에서 거절될 수 있습니다. HTTP error가 아니므로 일반 성공 응답처럼 처리하면 빈 결과나 이상한 UI가 나올 수 있습니다.
claude-sonnet-5 모델 ID를 별도 feature flag 뒤에 둡니다.temperature, top_p, top_k를 공통 wrapper에서 무조건 넣고 있지 않은지 확인합니다.budget_tokens 사용 지점을 검색해 adaptive thinking으로 바꿉니다.max_tokens가 빠듯한 코드 생성, JSON 생성, 보고서 생성 요청을 우선 재조정합니다.stop_reason: "refusal"를 정상 응답 안에서 처리합니다.Claude Sonnet 5는 단순 모델 업그레이드가 아니라 호출 계약의 일부가 바뀌는 전환입니다. 1M 컨텍스트와 향상된 agentic 성능은 매력적이지만, 토큰 증가와 파라미터 제한을 반영하지 않으면 비용과 장애가 먼저 보입니다. 모델 ID 변경 전에 요청 계층을 정리하는 팀이 안전하게 이득을 가져갑니다.