Claude Sonnet 5 마이그레이션: 400 에러와 토큰 비용을 피하는 체크리스트

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에서는 중간에 잘릴 수 있습니다.

Adaptive thinking 기본값을 어떻게 다룰까

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를 따로 측정해야 합니다.

Sampling parameter 제거는 프롬프트 설계 문제다

많은 팀이 temperature를 행동 제어 장치처럼 써왔습니다. 하지만 Sonnet 5에서는 non-default sampling parameter가 허용되지 않습니다. 그러면 제어를 어디로 옮겨야 할까요? 답은 system prompt와 output schema입니다.

예를 들어 “항상 보수적으로 답하라”는 temperature를 낮추는 대신 다음처럼 명시합니다.

• 모르는 정보는 추정하지 말 것
• 근거가 부족하면 insufficient_evidence 상태를 반환할 것
• 출력은 JSON schema를 따를 것
• 선택지가 여러 개면 confidence와 reason을 함께 반환할 것

창의적 글쓰기에서도 마찬가지입니다. temperature를 올리는 대신 스타일 예시, 금지 표현, 문장 길이, 구조 규칙을 prompt에 넣습니다. 모델 파라미터로 조정하던 습관을 계약 기반 출력 설계로 바꾸는 과정이라고 보면 됩니다.

새 tokenizer가 비용과 컨텍스트를 바꾼다

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-6
• thinking: { type: "enabled"
• budget_tokens
• temperature
• top_p
• top_k
• assistant prefill을 쓰는 메시지 구조
• max_tokens가 매우 낮게 고정된 endpoint

Node나 Python SDK를 쓰는 팀은 공통 client wrapper에서 한 번에 막는 편이 좋습니다. 각 기능 팀이 직접 API payload를 만들게 두면 일부 endpoint만 Sonnet 5에서 깨질 가능성이 큽니다. request validator를 두고 unsupported field가 들어오면 배포 전에 실패하게 만드는 방식이 안전합니다.

테스트는 품질보다 호환성부터 본다

새 모델 평가를 할 때 많은 팀이 바로 품질 비교부터 합니다. 하지만 마이그레이션 첫 단계에서는 호환성 테스트가 먼저입니다. 운영 요청 샘플 100개를 뽑아 Sonnet 5로 replay하고 다음을 봐야 합니다.

• 400 에러 발생 여부
• refusal stop_reason 발생 여부
• max_tokens로 인한 잘림 여부
• JSON schema 위반 여부
• 평균 입력/출력 토큰 변화
• latency 변화
• 기존 모델 대비 비용 변화

특히 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만이라도 로깅하세요.

바로 적용할 체크리스트

• 모델 ID를 claude-sonnet-5로 바꾸기 전 요청 payload validator를 추가한다.
• budget_tokens, manual extended thinking, non-default temperature, top_p, top_k를 제거한다.
• thinking이 필요 없는 endpoint에는 thinking: {type: "disabled"}를 명시한다.
• 긴 출력 endpoint는 max_tokens를 다시 산정한다.
• Sonnet 5 기준 token counting으로 대표 prompt 비용을 다시 계산한다.
• 100개 이상 운영 샘플을 replay해 400 에러, refusal, schema violation을 측정한다.
• 보안 관련 서비스는 stop_reason: "refusal"을 정상 응답 케이스로 처리한다.
• introductory pricing 종료 후 비용을 별도로 예측한다.
• 전체 전환 전 feature flag와 rollback 경로를 준비한다.

Claude Sonnet 5 마이그레이션은 어렵지 않습니다. 하지만 “drop-in upgrade”라는 말만 믿고 모델 ID만 바꾸면 운영에서 작은 장애가 날 수 있습니다. 핵심은 unsupported parameter를 제거하고, adaptive thinking과 새 tokenizer가 비용과 응답 길이에 미치는 영향을 숫자로 확인하는 것입니다.