Claude Sonnet 5가 공개됐습니다. Anthropic 문서 기준으로 claude-sonnet-5는 Sonnet 4.6의 drop-in upgrade에 가깝지만, 그대로 모델 ID만 바꾸면 일부 요청은 바로 400 에러가 납니다. 비용도 예상과 다르게 나올 수 있습니다.
이번 글은 “Sonnet 5가 얼마나 똑똑한가”보다 실제 마이그레이션에서 터지는 부분을 정리합니다. API 호출을 이미 운영 중인 팀이라면 모델 ID 변경 전에 세 가지를 확인해야 합니다. adaptive thinking, sampling parameter, tokenizer입니다.
Claude Sonnet 5는 1M token context window를 기본으로 지원하고, 최대 출력은 128k token입니다. 가격은 표준 기준 100만 토큰당 입력 $3, 출력 $15이며, 2026년 8월 31일까지는 introductory pricing으로 입력 $2, 출력 $10이 적용됩니다. 다만 새 tokenizer 때문에 같은 텍스트가 Sonnet 4.6 대비 약 30% 더 많은 토큰으로 계산될 수 있습니다. “단가는 같다”와 “요청 비용이 같다”는 같은 말이 아닙니다.
첫 번째는 manual extended thinking입니다. Sonnet 4.6에서 이미 deprecated였던 thinking: {type: "enabled", budget_tokens: N} 방식은 Sonnet 5에서 400 에러를 반환합니다. 이제는 adaptive thinking을 써야 합니다.
두 번째는 sampling parameter입니다. temperature, top_p, top_k를 non-default 값으로 보내면 400 에러가 납니다. 기존에 “창의적인 답변은 temperature 0.8”, “정확한 추출은 temperature 0”처럼 파라미터를 조정하던 코드는 정리해야 합니다. Anthropic은 system prompt instructions로 동작을 유도하라고 안내합니다.
세 번째는 max_tokens입니다. Sonnet 5에서는 adaptive thinking이 기본으로 켜집니다. max_tokens는 사고 토큰과 최종 응답 텍스트를 합친 하드 리밋입니다. Sonnet 4.6에서 thinking 없이 잘 나오던 응답이 Sonnet 5에서는 중간에 잘릴 수 있습니다.
Sonnet 4.6에서는 thinking 필드가 없으면 thinking 없이 실행됐습니다. Sonnet 5에서는 같은 요청이 adaptive thinking으로 실행됩니다. 이 변화는 품질에는 도움이 될 수 있지만, 지연 시간과 출력 토큰 예산에는 영향을 줍니다.
운영 서비스에서는 endpoint별로 판단해야 합니다. 예를 들어 사용자 질문에 짧게 답하는 FAQ, 단순 분류, JSON 필드 추출은 thinking이 필요 없을 수 있습니다. 이 경우 thinking: {type: "disabled"}를 명시하는 것이 낫습니다. 반대로 코드 리뷰, 긴 문서 분석, 복잡한 의사결정, multi-step planning은 adaptive thinking을 유지하는 편이 안전합니다.
중요한 건 “기본값을 믿고 방치하지 않는 것”입니다. 모델 기본값이 바뀌었으니 서비스 기본값도 다시 정해야 합니다. 특히 latency SLO가 있는 API라면 thinking on/off에 따른 p50, p95, p99를 따로 측정해야 합니다.
많은 팀이 temperature를 행동 제어 장치처럼 써왔습니다. 하지만 Sonnet 5에서는 non-default sampling parameter가 허용되지 않습니다. 그러면 제어를 어디로 옮겨야 할까요? 답은 system prompt와 output schema입니다.
예를 들어 “항상 보수적으로 답하라”는 temperature를 낮추는 대신 다음처럼 명시합니다.
insufficient_evidence 상태를 반환할 것창의적 글쓰기에서도 마찬가지입니다. temperature를 올리는 대신 스타일 예시, 금지 표현, 문장 길이, 구조 규칙을 prompt에 넣습니다. 모델 파라미터로 조정하던 습관을 계약 기반 출력 설계로 바꾸는 과정이라고 보면 됩니다.
Anthropic은 Sonnet 5의 새 tokenizer가 같은 텍스트를 약 30% 더 많은 토큰으로 만들 수 있다고 설명합니다. 정확한 증가는 콘텐츠와 workload shape에 따라 달라집니다. 이 변화는 네 군데에 영향을 줍니다.
첫째, token counting 결과가 달라집니다. Sonnet 4.6 기준으로 측정한 prompt budget을 재사용하면 안 됩니다.
둘째, 1M context window라도 실제 담을 수 있는 글자 수나 문서 수는 이전 모델과 다를 수 있습니다. 토큰이 더 잘게 쪼개지면 같은 1M token이 담는 텍스트는 줄어듭니다.
셋째, max_tokens가 빡빡한 요청은 응답이 잘릴 가능성이 커집니다. 특히 긴 JSON, 코드 생성, 보고서 생성 endpoint는 다시 측정해야 합니다.
넷째, 비용 예측이 달라집니다. 입력 단가는 같아도 토큰 수가 늘면 비용이 증가합니다. introductory pricing 기간에는 체감이 덜할 수 있지만, 8월 말 이후 표준 가격으로 돌아가면 더 분명해집니다.
마이그레이션 전에 요청 생성 코드를 grep으로 확인하세요. 아래 문자열이 있으면 수정 대상입니다.
claude-sonnet-4-6thinking: { type: "enabled"budget_tokenstemperaturetop_ptop_kNode나 Python SDK를 쓰는 팀은 공통 client wrapper에서 한 번에 막는 편이 좋습니다. 각 기능 팀이 직접 API payload를 만들게 두면 일부 endpoint만 Sonnet 5에서 깨질 가능성이 큽니다. request validator를 두고 unsupported field가 들어오면 배포 전에 실패하게 만드는 방식이 안전합니다.
새 모델 평가를 할 때 많은 팀이 바로 품질 비교부터 합니다. 하지만 마이그레이션 첫 단계에서는 호환성 테스트가 먼저입니다. 운영 요청 샘플 100개를 뽑아 Sonnet 5로 replay하고 다음을 봐야 합니다.
특히 Sonnet 5에는 Sonnet-tier 최초의 real-time cybersecurity safeguards가 들어갑니다. 고위험 사이버 보안 주제는 HTTP 에러가 아니라 200 응답에 stop_reason: "refusal"로 돌아올 수 있습니다. 보안 교육, 취약점 설명, 코드 감사 기능을 제공하는 서비스라면 이 케이스를 정상 응답 흐름으로 처리해야 합니다.
바로 전체 트래픽을 넘기지 말고 endpoint를 세 그룹으로 나눕니다.
1그룹은 저위험 read-only 작업입니다. 요약, 분류, 태깅, 내부 운영 도구 같은 기능입니다. 여기서 토큰 수와 latency를 먼저 측정합니다.
2그룹은 사용자에게 직접 노출되는 생성 작업입니다. 답변 품질, 거절률, 톤 변화를 봐야 합니다. A/B 테스트나 shadow run이 좋습니다.
3그룹은 코드, 보안, 금융, 의료처럼 실패 비용이 큰 작업입니다. 이 그룹은 수동 리뷰와 replay evaluation을 거친 뒤 천천히 전환합니다.
모델 ID를 feature flag로 관리하면 rollback이 쉽습니다. Sonnet 5 전환 중에는 request/response payload의 민감정보를 제거한 뒤, 토큰 수와 stop_reason만이라도 로깅하세요.
claude-sonnet-5로 바꾸기 전 요청 payload validator를 추가한다.budget_tokens, manual extended thinking, non-default temperature, top_p, top_k를 제거한다.thinking: {type: "disabled"}를 명시한다.max_tokens를 다시 산정한다.stop_reason: "refusal"을 정상 응답 케이스로 처리한다.Claude Sonnet 5 마이그레이션은 어렵지 않습니다. 하지만 “drop-in upgrade”라는 말만 믿고 모델 ID만 바꾸면 운영에서 작은 장애가 날 수 있습니다. 핵심은 unsupported parameter를 제거하고, adaptive thinking과 새 tokenizer가 비용과 응답 길이에 미치는 영향을 숫자로 확인하는 것입니다.