Claude Sonnet 5 분석: 1M 컨텍스트보다 무서운 건 토크나이저 변경

Claude Sonnet 4.6을 쓰던 코드를 그대로 Sonnet 5로 갈아탔는데 갑자기 400 에러가 쏟아진다면, 아마 세 가지 중 하나에 걸렸을 겁니다. 6월 30일 출시된 Sonnet 5는 겉보기엔 무난한 마이너 업그레이드처럼 보이지만, 실제로는 API 호출 방식 자체를 몇 가지 건드려 놓았습니다. 이번 글에서는 뭐가 바뀌었는지, 그리고 실제 코드를 어떻게 고쳐야 하는지를 정리했습니다.

 

Sonnet 5는 겉으로는 Sonnet 4.6의 드롭인 업그레이드를 표방합니다. 모델 ID만 claude-sonnet-4-6에서 claude-sonnet-5로 바꾸면 대부분의 코드는 그대로 돌아간다는 게 Anthropic의 공식 입장입니다. 가격도 동일한 $3/$15(백만 토큰당)를 유지하되, 8월 31일까지는 $2/$10 도입 가격을 적용합니다. 컨텍스트 윈도우는 기본값이자 최댓값으로 1M 토큰을 지원하고, 최대 출력은 128k 토큰입니다.

 

Sonnet 4.6이 지원하던 도구와 플랫폼 기능을 거의 그대로 이어받았는데, 유일한 예외가 Priority Tier로 이 기능만은 Sonnet 5에서 빠졌습니다. AWS Bedrock 사용자라면 한 가지 더 주의할 게 있는데, Sonnet 5는 레거시 Bedrock API(InvokeModel, Converse)에서는 아예 지원되지 않고 새로운 Claude Platform on AWS 경로로만 호출할 수 있습니다.

 

성능 면에서는 코딩과 에이전틱 작업에서 가장 큰 폭으로 개선됐다고 Anthropic은 밝혔습니다. 벤치마크상으로는 Opus 4.8에 근접하면서도 Sonnet 가격을 유지한다는 게 핵심 셀링포인트입니다.

특히 Extra High 추론 강도로 돌리면 OSWorld-Verified나 BrowseComp 같은 컴퓨터 사용·에이전틱 검색 평가에서 Opus 4.8의 중간~높음 설정 성능에 근접한다고 합니다.

다만 이 정도로 강하게 돌리면 호출당 비용이 표준 강도 대비 훨씬 올라가고, 경우에 따라 Opus 4.8과 비용이 맞먹을 수도 있다는 점은 감안해야 합니다.

Anthropic은 또한 Sonnet 5가 가장 까다로운 자율 에이전틱 시나리오에서의 안전성 정렬 수준은 Opus 4.8이나 Mythos Preview에는 못 미친다고 명시했기 때문에, 안전 마진이 중요한 자율 작업이라면 Opus 4.8을 계속 쓰는 걸 권장하고 있습니다.

모델 ID만 바꿨는데 400 에러가 난다면 — sampling parameter부터 지우기

가장 흔하게 걸리는 문제는 temperature, top_p, top_k 같은 샘플링 파라미터입니다. Sonnet 4.6까지는 이 값들을 기본값이 아닌 다른 값으로 넘겨도 정상 동작했지만, Sonnet 5부터는 이 파라미터에 비기본값을 넣는 순간 요청 자체가 400 에러로 거부됩니다. (OpenRouter 경유는 예외적으로 에러 대신 무시하고 넘어가지만, Anthropic 공식 API는 그대로 에러를 반환합니다.) 아래는 마이그레이션 전후를 비교한 코드입니다.

# Sonnet 4.6에서 쓰던 방식 - Sonnet 5에서는 400 에러
response = client.messages.create(
    model="claude-sonnet-4-6",
    max_tokens=1024,
    temperature=0.7,  # 이 줄이 문제
    messages=[{"role": "user", "content": "요약해줘"}]
)

# Sonnet 5 마이그레이션 - 샘플링 파라미터 제거
response = client.messages.create(
    model="claude-sonnet-5",
    max_tokens=1024,
    messages=[{"role": "user", "content": "요약해줘"}]
)

 

응답의 창의성이나 다양성을 조절하려고 temperature를 써왔다면, 이제는 그 역할을 프롬프트 지시문으로 대체해야 합니다. 배포 전에 코드베이스 전체에서 temperature=, top_p=, top_k= 키워드를 검색해서 Sonnet 5 호출부에서 전부 제거하는 작업이 선행돼야 합니다.

응답이 갑자기 잘리기 시작했다면 — adaptive thinking과 토큰 예산 문제

Sonnet 4.6에서는 thinking 필드를 안 넣으면 그냥 생각 없이 바로 답변했습니다. Sonnet 5는 반대로, 아무것도 지정하지 않으면 기본적으로 adaptive thinking이 켜진 채로 돌아갑니다. 문제는 max_tokens가 텍스트 응답뿐 아니라 thinking 블록까지 포함한 전체 출력의 상한이라는 점입니다. Sonnet 4.6 시절 텍스트 전용으로 산정해둔 max_tokens 값을 그대로 쓰면, thinking이 예산을 다 잡아먹고 정작 답변은 stop_reason: "max_tokens"로 잘려버리는 상황이 발생합니다.

# thinking을 끄고 Sonnet 4.6과 동일하게 동작시키고 싶은 경우
response = client.messages.create(
    model="claude-sonnet-5",
    max_tokens=4096,
    thinking={"type": "disabled"},
    messages=[{"role": "user", "content": "요약해줘"}]
)

# adaptive thinking을 쓰되 강도를 조절하고 싶은 경우
response = client.messages.create(
    model="claude-sonnet-5",
    max_tokens=8192,  # thinking 몫까지 감안해서 넉넉하게
    output_config={"effort": "medium"},
    messages=[{"role": "user", "content": "복잡한 버그를 분석해줘"}]
)

 

effort 단계는 low·medium·high·xhigh·max 순으로 다섯 단계이고, xhigh가 이번에 새로 추가된 단계입니다.

기존에 budget_tokens로 추론량을 세밀하게 제어하던 코드가 있다면 이 값은 이제 완전히 제거되고 400 에러를 반환하기 때문에, effort 파라미터 기반으로 전면 재작성해야 합니다. 응답이 잘리는 증상이 보이면 우선 max_tokens를 올리거나 effort를 medium으로 낮춰서 재현되는지부터 확인하는 게 디버깅 순서입니다.

토큰 비용이 갑자기 늘었다면 — 새 토크나이저 의심

Sonnet 5는 이전과 다른 토크나이저를 씁니다. 같은 텍스트를 넣어도 대략 1.0배에서 1.35배, Anthropic 공식 발표 기준으로는 평균 30% 더 많은 토큰으로 계산됩니다. 실제로 외부에서 측정해본 결과로는 영어가 약 1.4배, 스페인어 1.33배, 파이썬 코드 1.28배로 늘고 중국어 간체는 거의 차이가 없었다는 보고도 있습니다.

$2/$10 도입가가 이 토큰 증가분을 상쇄하려는 의도로 설계된 가격이라는 게 Anthropic 측 설명이지만, 8월 31일 이후 표준가로 돌아가면 토큰당 비용은 그대로인데 같은 요청에 쓰이는 토큰 수만 늘어난 셈이라 체감 비용은 오를 수 있습니다.

# 마이그레이션 전에 대표 프롬프트로 토큰 수 먼저 확인
response = client.messages.count_tokens(
    model="claude-sonnet-5",
    messages=[{"role": "user", "content": your_typical_prompt}]
)
print(f"Sonnet 5 기준 토큰 수: {response.input_tokens}")

 

Sonnet 4.6 기준으로 짜둔 max_tokens 상한이나 월간 예산 계산이 있다면, 이 코드로 실제 프롬프트를 다시 계산해서 예산을 재산정하는 작업을 마이그레이션 전에 반드시 거쳐야 합니다. 특히 긴 시스템 프롬프트나 코드베이스 전체를 컨텍스트로 넣는 워크플로우라면 토큰 증가분이 누적되면서 예상보다 훨씬 큰 비용 차이로 이어질 수 있습니다.

Sonnet 5 마이그레이션 체크리스트

항목	Sonnet 4.6	Sonnet 5
temperature/top_p/top_k	비기본값 허용	비기본값 시 400 에러
thinking 필드 없을 때	thinking 없이 동작	adaptive thinking 자동 활성화
budget_tokens 방식 추론	지원(지원 종료 예정)	완전 제거, 400 에러
effort 단계	low/medium/high/max	low/medium/high/xhigh/max
토크나이저	기존 방식	새 토크나이저, 동일 텍스트 기준 +30%
Priority Tier	지원	미지원
레거시 Bedrock API	호출 가능	호출 불가, 신규 API 경로 필요

결론

Sonnet 5는 이름만 보면 순한 버전업 같지만, 실제로 붙여보면 세 가지 지점에서 코드가 확실히 깨집니다. 샘플링 파라미터 제거, adaptive thinking 기본 활성화, 그리고 토크나이저 교체로 인한 토큰 예산 재계산이 그것입니다.

성능 자체는 코딩과 에이전틱 작업에서 Opus 4.8에 근접할 만큼 올라갔다는 점에서 마이그레이션할 가치는 충분하지만, 프로덕션에 바로 모델 ID만 바꿔서 배포하면 십중팔구 사고가 납니다.

대표 프롬프트로 토큰 수를 먼저 재보고, 샘플링 파라미터를 코드베이스에서 걷어내고, thinking 예산에 여유를 두는 세 가지 작업을 배포 전에 순서대로 거치는 게 가장 안전한 전환 경로입니다.