6월 15일, 앤트로픽은 claude-sonnet-4-20250514와 claude-opus-4-20250514 두 모델을 유예 기간 없이 API에서 즉시 퇴출했다. 지디넷코리아 보도에 따르면 이 버전 식별자를 코드에 고정해온 팀이라면 그날 아침 호출이 그냥 실패했다. 사전 경고도, 단계적 축소도 없었다. 같은 날 앤트로픽은 자동화 도구 크레딧 체계도 개편했다. 두 가지 충격이 동시에 왔다.
6일 전인 6월 9일에는 다른 종류의 단절이 일어났다. Claude Fable 5 출시와 함께, 프론티어 모델이 처음으로 구독 한도 바깥으로 빠져나갔다. 브런치 분석에 따르면 Pro·Max·Team·Enterprise 구독자는 6월 22일까지 13일 동안만 추가 비용 없이 Fable을 쓸 수 있었고, 6월 23일 0시부터는 별도 프리페이드 크레딧을 사야 했다. "내 구독 안에 들어 있는 모델 중 가장 강한 것이 곧 프론티어 모델"이라는 가정이 처음으로 공식적으로 깨진 날이다.
두 사건은 표면적으로 별개처럼 보이지만 같은 구조적 리스크를 가리킨다. 모델 공급업체는 자원을 최신 모델에 집중하기 위해 구형 버전을 정리할 유인이 항상 존재한다. 그리고 이제 프론티어 모델 자체가 구독 번들에서 분리되는 방향으로 움직이고 있다. 팀 입장에서 보면 의존하던 모델이 사라지는 경로가 두 가지로 늘어난 셈이다. 공급업체의 버전 퇴출, 그리고 구독 번들에서의 이탈.
문제는 대부분의 팀이 이 두 경로 모두에 무방비 상태라는 점이다. 특정 모델 버전을 코드에 직접 박아두면 공급업체 퇴출에 바로 노출된다. alias 방식으로 최신 버전을 자동 추적하면 퇴출 리스크는 줄지만, 모델이 바뀔 때 출력 품질이나 동작이 달라지는 리스크가 생긴다. 정밀한 결과가 필요한 서비스일수록 이 두 위험 사이에서 균형을 잡아야 한다. 그리고 그 균형 지점은 팀마다 다르다. 한 번 설계하면 끝나는 문제가 아니라는 뜻이다.
비용 구조도 함께 복잡해지고 있다. Fable 5의 API 가격은 input 1백만 토큰당 10달러, output 1백만 토큰당 50달러로 Opus 4.8 정가의 두 배다. dev.to의 AI 라우팅 분석이 지적하듯, 대부분의 팀은 여전히 모든 쿼리를 가장 강한 모델 하나에 보내고 청구서를 받는다. 며칠짜리 대규모 코드 마이그레이션에는 정당화될 수 있지만, 단발 응답이나 짧은 추론에는 Opus로 충분한 경우가 많다. 모델이 프리미엄 구독 밖으로 나간 순간부터 이 구분을 팀 단위로 명시적으로 설계하지 않으면 첫 청구서가 충격이 된다.
그렇다면 팀이 지금 당장 설계해야 할 것은 무엇인가. 크게 세 층위다.
첫째, 모델 버전 의존성 감사. 코드베이스 전체에서 특정 모델 버전 식별자가 하드코딩된 지점을 찾아야 한다. CI/CD 파이프라인, 자동화 스크립트, 프롬프트 설정 파일 모두 포함이다. 앤트로픽이 다음에 어떤 버전을 언제 퇴출할지는 아무도 모른다. 퇴출 공지를 상시 추적하는 운영 체계가 없다면 6월 15일 같은 날은 반드시 다시 온다.
둘째, 워크로드별 모델 라우팅 정책. 팀 내 어떤 작업이 프론티어 모델을 정당화하는지를 명시적으로 문서화해야 한다. Fable 5처럼 구독 밖으로 나간 모델이 앞으로 더 늘어날 가능성이 높다. "가장 강한 모델을 쓰자"는 암묵적 규칙은 더 이상 비용 면에서 무해하지 않다. 작업의 복잡도, 자율성 필요 여부, 허용 비용 상한을 기준으로 어떤 모델을 쓸지 라우팅 기준을 팀 차원에서 합의해야 한다.
셋째, 모델 전환 테스트 체계. 모델이 바뀔 때 기존 워크플로우가 동일하게 동작하는지를 검증할 수 있어야 한다. 출력 품질 기준, 허용 오차 범위, 인간 개입이 필요한 조건을 미리 정의해두지 않으면 모델이 교체될 때마다 수동 점검에 시간을 쏟게 된다.
앞으로의 방향은 더 뚜렷하다. Fable 5의 사례처럼, 프론티어 모델은 공개판과 통제판으로 분리되고, 구독 번들에서 이탈해 종량제로 청구되는 패턴이 OpenAI와 Google로도 번질 가능성이 높다. 모델 세대 교체 주기는 빨라지고 있고, 퇴출 유예 기간이 짧아지거나 없어지는 경향도 이번 사례에서 확인됐다. 팀이 특정 모델 하나에 워크플로우를 단단히 묶어놓을수록 그 리스크는 커진다.
결국 모델 생명주기 단절에 버티는 워크플로우란 특정 모델에 의존하지 않는 설계다. 어떤 모델이 들어오고 나가도 팀의 작업 흐름이 멈추지 않으려면, 모델을 교체 가능한 부품으로 취급하는 추상화 레이어가 필요하다. 그게 코드 레벨의 모델 식별자 관리든, 팀 레벨의 라우팅 정책이든, 조직 레벨의 분기 청구서 거버넌스든 마찬가지다. "어떤 모델이 가장 강한가"보다 "우리 워크플로우는 모델이 사라져도 버티는가"가 지금 AI-First 팀이 먼저 던져야 할 질문이다.