요약: Anthropic은 2026년 6월 15일 Claude Sonnet 4(claude-sonnet-4-20250514)와 Claude Opus 4(claude-opus-4-20250514)를 종료했고, 해당 모델 호출은 이제 오류를 반환한다고 공지했습니다. 운영 API에서 예전 모델 ID를 그대로 쓰는 팀은 단순히 문자열만 바꾸면 끝나지 않습니다. 토큰화, 거절 응답, 캐시 조건, 추론 기본값이 함께 달라질 수 있으므로 배포 전 회귀 테스트가 필요합니다.
모델 종료 공지는 보통 “새 모델로 바꾸세요” 한 줄로 보입니다. 하지만 실제 서비스에서는 이 한 줄이 검색, 요약, 코드 생성, 고객 상담, 내부 자동화까지 여러 경로를 건드립니다. 특히 모델 ID를 환경변수 하나로만 관리하지 않고 워커, 배치 스크립트, 프롬프트 실험 도구, 운영 콘솔에 흩어둔 팀은 장애가 더 조용하게 발생합니다.
Anthropic release notes는 6월 15일부터 Claude Sonnet 4와 Claude Opus 4 요청이 오류를 반환한다고 설명합니다. 권장 대체 모델은 각각 Claude Sonnet 4.6, Claude Opus 4.8입니다. 여기서 핵심은 “호환되는 최신 모델”이라는 표현을 그대로 믿지 않는 것입니다. 같은 Claude 계열이라도 출력 길이, 추론 방식, 안전 거절 처리, 프롬프트 캐시 조건이 바뀌면 애플리케이션 레벨 동작이 달라집니다.
개발팀이 먼저 해야 할 일은 사용 위치를 전부 찾는 것입니다. 서버 코드만 grep하면 부족합니다. CI 스크립트, 데이터 라벨링 노트북, 고객 지원용 매크로, 오래된 cron job, 사내 어드민 테스트 페이지까지 포함해야 합니다. 모델 종료는 런타임 에러로 드러나는 경우가 많아서, 사용량이 낮은 경로일수록 늦게 발견됩니다.
첫 번째 범위는 요청 파라미터입니다. Claude Opus 4.8 계열은 최근 release notes에서 effort 기본값, prompt caching 최소 길이, adaptive thinking 동작 같은 항목이 계속 업데이트됐습니다. 기존 코드가 temperature, top_p, top_k 같은 샘플링 파라미터를 임의로 넣고 있었다면 새 모델에서 400 오류가 날 수 있습니다. 모델 교체 PR에는 “문자열 변경”만 넣지 말고 요청 스키마 검증도 같이 넣어야 합니다.
두 번째 범위는 응답 처리입니다. Claude API는 거절 응답에서 stop_reason과 stop_details를 더 명시적으로 제공합니다. 일부 요청은 output 없이 refusal로 끝날 수 있고, 사전 출력 없이 거절된 요청은 과금되지 않는 정책도 별도로 공지됐습니다. 기존 코드가 stop_reason을 end_turn만 가정했다면 사용자에게 빈 답변을 보여주거나 재시도 루프에 빠질 수 있습니다.
세 번째 범위는 비용입니다. 새 모델은 더 긴 컨텍스트와 더 큰 출력 한도를 제공하지만, 실제 비용은 프롬프트 구조에 따라 달라집니다. “성능 좋아졌으니 그대로 교체”가 아니라, 대표 요청 20~50개를 뽑아 토큰 수와 응답 길이를 비교해야 합니다. 특히 긴 시스템 프롬프트와 도구 정의를 매번 보내는 에이전트는 prompt caching 적용 여부에 따라 비용 차이가 큽니다.
모델 교체 테스트를 사람이 몇 개 읽어보고 “괜찮네”로 끝내면 위험합니다. AI 출력은 매번 달라질 수 있으므로 정확히 같은 문장을 기대하면 테스트가 깨지고, 반대로 너무 느슨하면 실제 문제를 놓칩니다. 실무에서는 계약 테스트 방식이 낫습니다.
예를 들어 고객 문의 분류 모델이라면 다음 항목을 검사합니다.
코드 생성이나 SQL 생성처럼 위험도가 큰 기능은 실행 전 정적 검사를 추가합니다. SQL이면 읽기 전용 쿼리인지, 테이블 allowlist를 벗어나지 않는지, LIMIT가 있는지 확인합니다. 코드면 파일 경로, 네트워크 호출, 삭제 명령을 검사합니다. 모델 품질을 믿는 것보다 출력 계약을 좁히는 편이 운영에 안전합니다.
바로 전체 트래픽을 새 모델로 넘기지 마세요. 첫 단계는 shadow 실행입니다. 기존 모델 응답을 사용자에게 보여주되, 같은 입력을 새 모델에도 보내 비교 로그만 남깁니다. 종료된 모델은 더 이상 호출할 수 없으므로 아직 대체 전이라면 과거 로그를 리플레이하는 방식으로 shadow를 흉내낼 수 있습니다.
두 번째는 canary입니다. 내부 사용자, 테스트 계정, 낮은 위험도의 기능부터 새 모델을 사용합니다. 이때 단순 성공률만 보면 안 됩니다. 응답 지연 시간, 입력 토큰, 출력 토큰, refusal 비율, 후처리 실패율, 사용자 재질문 비율을 같이 봐야 합니다. 모델 교체 후 “성공률 99%”여도 응답이 2배 길어져 UX가 나빠질 수 있습니다.
세 번째는 feature flag 기반 전체 전환입니다. 모델 ID를 코드에 박지 말고 라우팅 설정으로 분리합니다. 장애가 나면 이전 모델로 되돌리는 것이 이상적이지만, 이번처럼 이전 모델이 종료된 경우에는 대체 후보를 최소 2개 준비해야 합니다. 예를 들어 고품질 경로는 Opus 4.8, 일반 경로는 Sonnet 4.6, 장애 시 저비용 fallback 모델처럼 운영 정책을 정합니다.
모델 마이그레이션 후에는 로그가 없으면 원인 분석이 거의 불가능합니다. 최소한 다음 필드를 남기세요.
개인정보와 원문 프롬프트를 무조건 저장하라는 뜻은 아닙니다. 민감한 서비스라면 입력 원문 대신 해시, 길이, 카테고리, 검증 결과를 저장해도 됩니다. 중요한 것은 “모델 변경 후 무엇이 달라졌는지”를 수치로 볼 수 있어야 한다는 점입니다.
출처: Anthropic Claude Platform release notes, 2026년 6월 15일 모델 종료 공지.
