Sonnet 5에서 5.5로 바꿔야 할까? 호환성·비용·롤백 점검

Sonnet 5.5는 Sonnet 5 애플리케이션의 업그레이드 후보지만, 모델 이름만 보고 바로 교체할 대상은 아닙니다. 공식 토큰 단가는 같아도 허용 요청 필드, effort 동작, 응답 처리는 달라졌습니다. 자체 합격 기준을 통과하고 필요한 작업이 개선되는지 확인한 뒤 전환하세요.

이 글은 이미 Sonnet 5를 운영하는 팀을 위한 배포 판단 안내입니다. 종합 모델 순위 대신 업그레이드 결정을 다룹니다. 9월 28일 Sonnet 5.5 출시 후 2026년 9월 29일 문서를 확인했습니다. 모든 Sonnet 5 애플리케이션이 즉시 운영 환경을 옮겨야 한다는 뜻은 아닙니다.

유지되는 것과 달라지는 것

출처: Sonnet 5.5 모델 페이지, 변경 사항. 토크나이저가 같으면 같은 입력 텍스트가 일관되게 분할된다는 뜻이지 두 모델이 같은 수의 출력 토큰을 생성한다는 뜻은 아닙니다.

업그레이드 가설 하나 정하기

새 모델을 시험할 구체적인 이유를 적으세요. 예를 들어 “제한된 버그 수정 작업에서 회귀 테스트 통과율을 유지하면서 재시도 횟수를 줄인다” 또는 “문서 초안에서 필수 절 누락을 줄인다”입니다. 이는 검증할 가설이지 출시 발표로 입증된 개선이 아닙니다.

프롬프트, 검색 파이프라인, 도구, 모델을 한 번에 바꾸지 마세요. 결과가 좋아져도 어느 변화 때문인지 알기 어렵습니다. 기존 구성을 유지하고 같은 작업 세트를 비교합니다. Sonnet 5.5의 유효한 요청을 위해 필드를 바꿔야 한다면 호환성 변경도 새 구성의 일부로 기록하세요.

실제 사용 사례에서 작업을 고르고 필요하면 비공개 정보를 제거합니다. 흔한 요청, 어려운 사례, 사용자가 중요하게 여기는 실패 유형을 포함하세요. 공급사 최고의 데모와 닮은 예제만 구성하지 마세요.

성능보다 호환성이 먼저

우선 확인할 것은 지원 thinking 모드, 강제 도구 사용, 보존된 thinking 이력, computer use, advisor 호환성입니다. Sonnet 5.5는 thinking.type: disabled를 허용하지 않습니다. 문서에 나온 thinking을 줄이는 대안은 high 이하의 between_tools입니다. 강제 tool_choice 값도 변경해야 합니다.

요청 예제와 플랫폼 조건은 400 오류 마이그레이션 가이드를 참고하세요. 여기서는 전체 문제 해결 절차를 반복하지 않습니다. 성공 응답도 체크리스트에 포함해야 합니다. HTTP 200이어도 진행 표시나 기대한 도구 호출이 빠질 수 있습니다.

일반 텍스트, 도구 호출, thinking 블록, 거부에 대한 파서 동작을 테스트하세요. 대화 중 모델을 바꾸면 호환되지 않는 블록의 처리를 확인합니다. 이전 메시지를 수정한다면 바인딩 동작도 확인해야 합니다. 한 턴짜리 인사 응답으로 운영 에이전트 루프를 검증할 수는 없습니다.

품질과 비용을 함께 측정하기

합격 기준은 유지하세요. 코딩은 대상 테스트와 전체 회귀 테스트 통과, 무관한 수정 없음이 될 수 있습니다. 추출은 스키마와 실제 값, 문서는 필수 절과 입력 데이터에 관한 모든 주장을 확인합니다.

요청 수, 과금 사용량 구분, 통과 결과까지의 시간, 리뷰 노력을 기록하세요. 스트리밍이 빨라도 작업이 더 빨리 끝나는 것은 아닙니다. 요금표가 같아도 출력이 늘거나 도구 턴이 많아지면 청구액이 달라집니다.

Artificial Analysis 출시 보고서는 시험 대상을 정할 참고 자료이지만 출시 전 배포 문제와 재평가 계획을 명시합니다. 이를 내 애플리케이션에서 측정한 업그레이드 효과처럼 쓰지 마세요. 외부 결과와 자체 결과는 별도 열로 보존합니다.

되돌릴 수 있게 배포하기

먼저 분리된 테스트 환경에서 새 구성을 실행합니다. 점검을 통과하면 제품에 맞는 승인된 제한 배포 방식을 선택하세요. 정확한 모델, 설정, 릴리스 시간을 기록해 이후 트래픽을 이전 버전과 구별할 수 있게 합니다. 두 버전을 말없이 하나의 성능 요약에 섞지 마세요.

롤백 구성과 발동 조건을 정해 둡니다. 유효하지 않은 응답이 허용 기준을 넘거나 핵심 작업이 악화되는 경우가 예시입니다. 롤백은 모델이 전반적으로 더 나쁘다는 선언이 아닙니다. 연동이나 작업 특성을 더 조사해야 한다는 뜻일 수 있습니다.

새 버전이 나왔다고 이전 모델이 즉시 종료된다고 생각해 삭제하지 마세요. 공식 수명주기 약속은 따로 확인합니다. 서비스마다 접근과 지원 종료가 다를 수 있습니다. 제목이 주는 긴박감이 아니라 실제 지원 날짜와 현재 플랫폼 동작에 따라 계획을 세우세요.

통합 유형부터 나눠야 할 검증이 보인다

한 번 요청하고 최종 텍스트만 읽는 앱은 모델을 바꾸고 서명된 thinking 이력을 저장하며 도구 진행 상황을 스트리밍하는 에이전트보다 호환성 점검 범위가 작습니다. ID 변경 전에 앱을 분류하면 필요한 테스트를 정할 수 있습니다. 단순한 앱의 답이 동일하다는 보장은 아닙니다.

유효한 JSON도 사실 추출의 정확성을 증명하지 않습니다. 스키마가 invoice_total을 필수로 해도 금액은 원문과 대조해야 합니다. 인자가 올바른 도구 호출도 잘못된 레코드를 가리킬 수 있습니다. 호환성 테스트는 앱이 실행되는지, 작업 테스트는 결과가 유용한지를 확인합니다.

플랫폼도 중요합니다. 현재 마이그레이션 문서는 Bedrock의 Sonnet 5.5가 strict tool use를 포함한 structured outputs를 지원하지 않는다고 설명합니다. 이전 computer-use 도구도 플랫폼별 처리가 다릅니다. 한 엔드포인트 결과를 다른 서비스의 준비 완료 표에 복사하면 안 됩니다. 모델 ID와 엔드포인트 계열을 같이 기록하세요.

앱에 맞는 최소 회귀 묶음 준비하기

새 답을 생성하기 전에 픽스처를 만드세요. 일반 요청, 앱 자체 제한에 가까운 긴 입력, 의도적으로 불완전한 입력, 거부 또는 지원 밖 요청, 도구 실패, 다중 턴 이어가기에 영향이 가장 큰 과거 버그를 추가합니다. 이는 커버리지 점검의 시작이며 일곱 사례로 운영 안전성을 증명한다는 뜻은 아닙니다.

각 사례의 필수 동작과 실패 판정을 적습니다. 추출은 정확한 금액·통화·출처 위치를 요구하고 누락 정보를 만들어내면 실패로 볼 수 있습니다. 코딩은 기준선에서 회귀 테스트가 실패하고 패치 후 통과하되 검수 테스트는 수정하지 않아야 합니다. 문서는 원자료 사실을 지정한 절에 포함하고 가짜 인용을 금지할 수 있습니다.

파서 사례에서는 원본 응답 구조와 앱 표시 결과를 저장합니다. 올바른 블록에서 텍스트를 추출하고 thinking을 최종 답으로 표시하지 않으며, 진행 텍스트가 비어도 UI가 멈춘 것처럼 보이지 않는지 확인합니다. Sonnet 5.5는 요청이 성공한 상태에서도 중간 응답 구조가 달라질 수 있어 HTTP 코드만 보는 상태 확인으로는 놓칩니다.

도구 사례에서는 한 번 의도적인 오류를 반환하세요. 결과를 모델에 올바르게 전달하고 재시도 상한을 지키며, 첫 결과가 불확실한 외부 동작을 반복하지 않는지 봅니다. 파괴적 동작은 샌드박스 대체물을 사용합니다. 실제 결제나 이메일을 두 번 실행했는지 알아보려는 것이 아니라 실패 상황의 오케스트레이션을 검증하는 테스트입니다.

기본값까지 포함해 두 설정 명시하기

모델 ID, 엔드포인트, SDK·클라이언트 버전, thinking 모드, effort, 출력 제한, 시스템 프롬프트 해시, 도구 스키마 해시, 검색 버전을 기록합니다. 요청에 필드를 생략해도 적용되는 기본값을 적어야 합니다. Sonnet 5.5의 API 기본값은 high, Claude Code는 medium이므로 같은 모델 이름도 클라이언트에 따라 시작 조건이 달라집니다.

변하지 않는 기준 commit이나 설정 버전을 유지하세요. 새 필드가 필요하면 유일한 이전 요청을 덮어쓰지 말고 별도 5.5 설정을 만듭니다. ID만 되돌리고 호환되지 않는 5.5 필드를 남기는 것은 신뢰할 수 있는 롤백이 아닙니다. 보고서에는 비밀값을 넣지 말고 해시와 민감하지 않은 설정으로 버전을 식별합니다.

공식 문서상 Sonnet 5와 5.5의 tokenizer와 요율은 같습니다. 동일 입력 비교에는 도움이 되지만 출력 길이와 도구 루프 동작은 여전히 확인해야 합니다. 호환성 변경이 필요하지 않다면 현재 프롬프트부터 시작하세요. 나중에 프롬프트를 조정하면 별도 설정으로 남겨 모든 개선을 모델 업그레이드 탓으로 돌리지 않습니다.

테스트 결과를 출시 판단으로 연결하기

호환성 실패, 작업 실패, 운영 실패를 나누세요. 요청 필드 거절은 호환성 문제, 형식은 맞는데 금액이 틀리면 작업 실패, 타임아웃이나 의존성 중단은 운영 실패입니다. 모두 출시를 막을 수 있지만 해결책은 다릅니다. 하나의 정확도에 합치면 다음 행동이 불분명해집니다.

가상의 출시 조건은 중요 픽스처 전부 통과, 외부 동작 중복 없음, 일반 작업은 팀의 기존 합격 기준 충족, 비용과 완료 시간은 사전 예산 이내로 정할 수 있습니다. 보편적 임계값은 아닙니다. 중요 하위 집합은 전체 평균이 좋아져도 반드시 지켜야 하는 조건입니다. 숫자는 제품 요구와 기존 측정에서 정하고 모델 발표에서 만들지 마세요.

20개 작업에서 두 버전 모두 18개를 통과했다고 동등한 것은 아닙니다. 이전 버전은 영향이 작은 초안 두 개, 새 버전은 재무 추출과 마이그레이션에 실패할 수 있습니다. 90% 대 90%가 아니라 작업 ID와 실패 심각도를 비교합니다. 새로운 실패를 조사하고 모호한 사례를 반복하며 작은 표본이라는 한계를 판단 기록에 남깁니다.

롤백은 이름뿐 아니라 동작을 복원해야 한다

승인된 제한 배포에서는 요청을 기록된 설정에 배정하고, 따로 시험하지 않은 한 실행 중인 작업의 모델을 중간에 바꾸지 않습니다. 로그에서 구버전과 신버전 트래픽을 구분할 메타데이터를 저장하세요. 읽기 전용 출력의 그림자 평가는 유용할 수 있지만 비교 때문에 부작용 있는 도구를 두 번 실행해서는 안 됩니다.

롤백 조건에 도달하면 새 설정에 새 작업을 보내지 않고 검증된 어댑터를 복원하며, 진행 중인 작업은 저장 상태에 맞춰 처리합니다. 결과가 불확실한 외부 동작은 재시도 전에 대조합니다. 민감 정보를 보호하면서 실패 응답과 usage를 조사용으로 남기세요. 운영을 되돌렸다고 새 버전 기록을 지우는 것은 아닙니다.

최종 출시 기록에는 통과한 픽스처, 미해결 문제, 검수 담당자나 방식, 대체 설정을 명시합니다. 모델이나 플랫폼 접근 권한 때문에 실행하지 못했다면 “준비 완료, 검증 전”으로 표시해야 합니다. 문서 확인과 로컬 요청 구조 검증은 유용하지만 종단 간 업그레이드 성공으로 보고할 수는 없습니다.

다음으로 확인할 자료

산술 계산은 요금 기록표, 설정 테스트는 effort 비교를 활용할 수 있습니다. 더 큰 모델로 옮길지가 실제 질문이라면 업그레이드와 등급 변경을 한 실험에 섞지 말고 Sonnet과 Opus 비교를 참고하세요.