Claude Sonnet 5.5 공개: 성능보다 ‘마이그레이션 변화’를 먼저 봐야 하는 이유

팀에서 Sonnet 5 기반 코드 리뷰 봇이나 문서 자동화 에이전트를 이미 운영 중이라면, Sonnet 5.5 발표에서 먼저 볼 것은 벤치마크 막대가 아니다. “모델 ID만 바꿔도 되는가”, “기존 thinking 설정이 400 오류를 내지 않는가”, “도구 호출 사이의 진행 메시지가 UI에서 사라지지 않는가”가 더 급하다. 기준일은 한국시간 2026-09-29이며, 아래 내용은 그 시점에 확인된 자료만 기준으로 한다.

발표를 봤다면 다음 질문은 ‘교체 가능성’이다

Anthropic은 2026-09-28 Sonnet 5.5를 공개하며 Sonnet 5보다 빠르고, 대부분의 작업에서 작업당 비용이 낮아질 수 있다고 설명했다.[1] 발표문은 코딩, 지식 작업, 장기 작업, 이미지 이해 개선을 강조하지만, 이는 회사가 제시한 평가와 초기 고객 발언이 섞인 설명이다.[1] 따라서 운영팀이 그대로 받아들일 문장은 “좋아졌다”가 아니라 “우리 워크로드에서 다시 측정해야 한다”에 가깝다.

개발자에게 더 중요한 문서는 모델 개요다. Claude Platform 문서는 Sonnet 5.5를 Active latest로 표시하고, Claude API 모델 ID claude-sonnet-5-5, Bedrock 모델 ID anthropic.claude-sonnet-5-5, 1M 컨텍스트, 128K 최대 출력, 입력 $2/MTok·출력 $10/MTok을 제시한다.[2] Message Batches API의 300K 출력은 output-300k-2026-03-24 베타 헤더가 필요한 별도 조건이다.[2]

핵심 변화: 성능보다 API 계약이 먼저 바뀐다

Sonnet 5.5의 가장 실무적인 변화는 thinking이다. 공식 문서는 adaptive thinking이 기본이며, thinking, forced tool use, thinking block 보존, computer use 도구 버전 등 기존 Sonnet 5 코드에 영향을 주는 breaking change를 명시한다.[2] 특히 temperature, top_p, top_k를 비기본값으로 설정하면 400 오류가 날 수 있다는 주의도 있다.[2]

Anthropic의 개발자 블로그도 같은 방향을 말한다. Sonnet 5.5에서 thinking: {"type":"disabled"} 대신 up-front thinking을 줄이려면 between_tools를 쓰라고 안내하고, Claude API와 Google Cloud에서는 이전 computer_20251124 computer use 도구가 허용되지 않는다고 설명한다.[3] 즉 이번 업그레이드는 “모델 ID 교체”라기보다 “요청·응답 계약 재확인”에 가깝다.

적용 전 확인 순서: 화면이 조용한지, 모델이 멈춘 건지 구분하라

첫째, 응답 렌더러가 content block의 첫 항목을 무조건 text로 가정하는지 확인해야 한다. 모델 문서는 도구 호출 사이의 텍스트가 thinking block으로 돌아올 수 있고, 이를 그대로 사용자에게 스트리밍하던 앱은 표시 설정을 바꾸거나 between_tools를 쓰기 전까지 조용해 보일 수 있다고 설명한다.[2] 채팅형 제품에서는 장애로 오인하기 쉬운 지점이다.

둘째, 도구 호출과 대화 저장 방식을 점검하자. 개발자 블로그는 thinking block이 모델과 대화에 묶이므로 assistant turn을 append-only로 유지하라고 설명하고, Claude Code에서는 일정 버전 이후 sonnet 별칭이 Sonnet 5.5로 해석된다고 안내한다.[3] 셋째, 대표 작업을 medium과 high effort 중심으로 다시 돌려야 한다. 같은 effort 이름이라도 Sonnet 5와 동일한 생각량을 뜻한다고 추론해서는 안 된다.

선택 비교: Sonnet 5.5를 어디에 둘 것인가

회사 주장과 독립 평가를 분리해 읽기

Anthropic 발표는 Terminal-Bench, FrontierCode, CursorBench, AA-Briefcase 등에서 Sonnet 5.5가 Sonnet 5보다 좋은 비용 대비 성능을 낸다고 주장한다.[1] 그러나 이 문장은 공급자 평가다. 실제로 비용이 줄어드는지는 출력 토큰, thinking 토큰, 도구 호출 횟수, 재시도율이 함께 움직이기 때문에 내부 로그로 확인해야 한다.

독립 평가인 Artificial Analysis는 더 미묘한 그림을 제시한다. 해당 글은 Sonnet 5.5 max effort가 Intelligence Index 56으로 Sonnet 5 max의 38보다 높고 Opus 5.5 max보다 2점 낮다고 평가했다.[5] 동시에 max effort에서 출력 토큰 사용이 매우 커져 작업당 비용이 $7.60으로 측정됐고, 높은 effort에서는 비용 효율의 장점이 약해질 수 있다고 지적했다.[5] 따라서 안전한 해석은 “Sonnet 5.5가 항상 싸다”가 아니라 “낮거나 중간 effort로 품질을 만족할 때 매력이 커진다”이다.

지역 제공과 베타 상태는 별도 의사결정이다

AWS를 쓰는 팀은 “Bedrock에서 제공”이라는 문장만으로 충분하지 않다. Amazon Bedrock 모델 카드는 Standard 서비스 티어 지원과 함께 Regional Availability를 나누어 설명하며, In-Region, Geo Cross-Region, Global Cross-Region의 데이터 라우팅 의미를 구분한다.[4] 특히 데이터 레지던시나 규제 요구가 있으면 endpoint, inference profile, 리전별 지원 여부를 배포 전 체크해야 한다.[4]

베타 기능도 운영 정책에 분리해 적어야 한다. Sonnet 5.5의 기본 최대 출력은 128K이고, Batch API 300K 출력은 베타 헤더 조건이다.[2] 클라우드·베타·정식 기능을 섞어 문서화하면 장애 대응 때 원인을 찾기 어렵다. 운영 런북에는 “정식 기본값”, “베타 헤더 필요”, “특정 플랫폼 한정”을 따로 적는 편이 낫다.

독자가 지금 해볼 일

오늘 할 일은 세 가지다. 먼저 staging에서 모델 ID만 바꾸지 말고 thinking, effort, 도구 선언, content block 렌더링, computer use 버전을 점검한다.[2][3] 다음으로 대표 작업 세트를 골라 Sonnet 5, Sonnet 5.5 medium, Sonnet 5.5 high를 비교하고, 성공률뿐 아니라 총 토큰, 첫 응답 지연, 거절 응답, 재시도율을 같이 기록한다.

마지막으로 라우팅 정책을 정하자. 잘 정의된 반복 업무는 Sonnet 5.5 후보로 올리고, 실패 비용이 큰 장기 설계·정책 판단은 Opus 계열 또는 사람 검토를 남기는 식이다.[3] 직접 시험하지 않았다면 “우리 서비스에서 30% 싸졌다”고 쓰지 말자. 이번 업데이트의 핵심은 발표 수치보다, 마이그레이션 변화까지 포함해 운영 가능한 선택지를 만드는 데 있다.