Claude Fable 5가 출시 4일 만에 중단된 이유를 확인했습니다. 이것은 장애가 아닙니다.

Claude Fable 5는 Anthropic의 새로운 최상위 모델로 출시되었습니다. 4일 후, Fable 5와 Mythos 5에 대한 접근이 중단되었습니다.

제가 처음 본 의견들은 예측 가능한 것들이었습니다:

"Fable 5가 탈옥(jailbroken)되었다."

"Claude가 다운되었다."

"이것은 단지 6월 22일의 구독 변경 사항일 뿐이다."

이 중 두 가지는 틀렸습니다. 나머지 하나는 헤드라인이 들리는 것보다 훨씬 더 좁은 의미에서만 그럴듯합니다.

저는 오전 내내 Anthropic 성명서, Claude 상태(Status) 인시던트, 그리고 Fable 라우팅(routing) 관련 문서를 읽었습니다. 저의 결론은 다음과 같습니다: 이것은 일반적인 장애(outage)가 아닙니다. 이것은 모델 접근 거버넌스(model-access governance) 이벤트이며, 프로덕션 환경에서 프런티어 모델(frontier models)을 운영하는 모든 팀은 이를 라우팅 설계(routing-design)에 대한 경고로 받아들여야 합니다.

요약 (TL;DR)

• 아니요, 이것은 단순히 "Claude가 다운된 것"이 아닙니다. Claude Status는 Fable 5와 Mythos 5를 구체적으로 명시하고 있으며, Anthropic은 다른 Claude 모델들은 영향을 받지 않는다고 밝혔습니다.
• 네, 실제 서비스 전반에 걸쳐 접근이 중단되었습니다. 해당 인시던트에는 claude.ai, Claude API, Claude Code, 그리고 Claude Cowork가 포함되어 있습니다.
• 트리거는 용량 문제가 아닌 법적 문제입니다. Anthropic은 6월 12일 오후 5시 21분(ET)에 미국 정부의 수출 통제(export-control) 지침을 받았다고 밝혔습니다.
• 공식적인 예상 복구 시간(ETA)은 없습니다. Anthropic이 상태 페이지를 업데이트하기 전까지 "몇 시간 내 복구"라는 모든 주장은 추측일 뿐입니다.
• 개발자가 취해야 할 조치는 지루하지만 시급합니다: 프로덕션 기본 라우트(default routes)에서 Fable을 제거하고, 무거운 Claude 워크로드는 Opus 4.8로 보내며, 실시간 상태 확인(health check)을 통과한 후에만 Fable을 복구하십시오.

실제로 무슨 일이 일어났는가

가장 명확한 버전은 다음과 같습니다:

Anthropic은 해당 지침이 미국 내외의 외국 국적자에 의한 접근을 대상으로 한다고 밝혔습니다. 또한 실질적인 효과로서 Anthropic이 규정을 준수하기 위해 모든 고객에 대해 두 모델을 모두 비활성화했다고 설명했습니다.

그 차이는 중요합니다. 만약 이것이 인프라 장애 (infrastructure outage)였다면, 저는 이를 에러 예산 (error-budget) 이벤트로 취급했을 것입니다. 만약 이것이 단순한 모델 선택 버그 (model-picker bug)였다면, Claude Code를 업데이트하고 넘어가면 그만이었을 것입니다. 하지만 이것은 특정 모델 제품군에 대한 법적 접근 상태 (legal access state) 문제입니다.

즉, 여러분의 재시도 로직 (retry logic)은 해결책이 아니라는 뜻입니다.

개발자가 저지르는 가장 중요한 실수: 중단된 모델 재시도

만약 여러분의 앱이 Fable을 호출했는데 모델 사용 불가 (model-unavailable) 응답을 받는다면, 최악의 패턴은 다음과 같습니다:

for attempt in range(5):
    try:
        return call_model("claude-fable-5", prompt)
...

이 패턴은 일시적인 500 에러 (transient 500s)에는 타당합니다. 하지만 모델 경로 자체가 중단된 경우에는 타당하지 않습니다.

올바른 동작은 서킷 브레이커 (circuit breaker)를 적용하는 것입니다:

def choose_model(task, fable_status, requires_zero_data_retention=False):
    if requires_zero_data_retention:
        return "claude-opus-4.8"
...

저는 여기에 두 가지 운영 규칙 (production rules)을 더 추가하겠습니다:

def should_retry(error):
    if error.type in {"model_unavailable", "model_not_found", "access_suspended"}:
        return False
...

마지막 로그 라인은 허세가 아닙니다. 만약 여러분이 사용자에게 비용을 청구하거나, 디버깅 과정에서 품질 저하 (quality regressions)를 확인하거나, 평가 결과 (eval results)를 비교한다면, 사용자가 Fable을 요청했으나 실제로 Opus를 받았는지 여부를 반드시 알아야 합니다.

하룻밤 사이에 바뀐 비용 계산법

중단되기 전, Fable에 대한 질문은 일반적인 모델 경제학 (model economics)의 영역이었습니다:

중단된 이후, 비싼 부분은 토큰 가격이 아닙니다. 바로 실패한 작업 (failed work)입니다.

100K 입력 / 20K 출력을 사용하는 Fable 실행 비용은 약 다음과 같았을 것입니다:

100K input * $10 / 1M = $1.00
20K output * $50 / 1M = $1.00
Total = $2.00

Opus 4.8에서 동일한 규모로 실행할 경우 비용은 약 다음과 같습니다:

100K input * $5 / 1M = $0.50
20K output * $25 / 1M = $0.50
Total = $1.00

하지만 이것은 과거의 프레임입니다. 중단 기간 동안 Fable 요청의 비용은 "$2이며 아마 가치가 있을 것"이 아닙니다. 그것은 다음과 같은 비용을 의미합니다:

실패한 사용자 작업

• 재시도 낭비
• 고객 지원 티켓
  ...

만약 개발자 한 명이 경로(route)를 패치하는 데 2시간을 허비한다면, 해당 사고의 비용은 이미 토큰당 비용 차이(per-token delta)를 압도합니다. 만약 하루에 1,000번의 에이전트(agent) 실행이 Fable을 우선적으로 시도하다 실패한다면, Opus가 사용 가능한 상태임에도 불구하고 귀하의 제품은 고장 난 것처럼 보일 것입니다.

그렇기 때문에 저는 지금 당장 Fable 우선 라우팅(Fable-first routing)을 비활성화하고, 다음 두 가지 확인 절차를 통과한 후에만 복구할 것입니다:

1. Claude 상태 페이지(Claude Status)에서 사고가 해결되었다고 명시하는 경우.
2. 귀하의 자체 라이브 API 상태 확인(health check)을 통해 귀하의 계정에서 해당 경로가 작동함을 확인하는 경우.

이것은 6월 22일 구독 크레딧 사건이 아닙니다

사람들이 이 두 사건을 혼동하는 것을 계속 보고 있습니다.

이 둘은 별개의 사건입니다.

이 구분이 중요한 이유는 중단 조치가 현재 API와 제품 인터페이스(surfaces)에 영향을 미치고 있기 때문입니다. 이는 단순히 미래의 결제 차단 문제가 아닙니다.

만약 귀하가 Fable 가용성을 기반으로 무언가를 구축했다면, 이것은 오늘 당장의 운영(production) 문제입니다.

저의 현재 라우팅 방식

만약 제가 오늘 운영 트래픽을 실행하고 있다면, 다음과 같이 라우팅할 것입니다:

저는 제 시스템에서 Fable을 영구적으로 삭제하지는 않을 것입니다. 그것은 시기상조입니다. Anthropic은 액세스 복구를 위해 노력하고 있다고 밝혔습니다.

하지만 기본 경로(default routes)에서는 제거할 것입니다. 중단된 프런티어 모델(frontier model)은 느린 의존성(slow dependency)이 아니라, 비활성화된 의존성(disabled dependency)처럼 취급되어야 합니다.

더 큰 그림

이 부분은 Anthropic을 넘어 더 중요한 의미를 갖는다고 생각합니다.

프런티어 모델에 대한 액세스는 과거에 기술적인 문제로 느껴졌습니다:

• 모델이 충분히 좋은가?
• 충분히 저렴한가?
• 충분히 빠른가?
• API가 충분히 안정적인가?

Fable 5는 여기에 또 다른 항목을 추가합니다:

• 이 모델이 내 사용자들에게 법적, 운영적으로 계속 가용할 수 있는가?

그 질문은 과거에는 수출 통제 대상 칩, 엔터프라이즈 지역, 그리고 정부 워크로드(workloads)를 위해서만 남겨두었던 것이었습니다. 이제는 출시된 지 불과 며칠 된 상용 프런티어 모델 (frontier model)에 이 질문이 붙게 되었습니다.

모든 프런티어 모델이 동일한 처우를 받게 될 것이라고 말하는 것은 아닙니다. 그것은 추측일 뿐입니다. 하지만 저는 이것이 이제 단일 최상위 모델에 의존하는 모든 에이전트 플랫폼 (agent platform), IDE 통합, 또는 엔터프라이즈 워크플로 (enterprise workflow)에 있어 실제적인 설계 입력값 (design input)이 될 것이라고 생각합니다.

아키텍처 교훈은 간단합니다:

def production_ai_rule():
    return "최신 프런티어 모델을 유일한 경로로 만들지 마십시오."

모델이 나쁘기 때문이 아닙니다. 모델이 더 뛰어나고 민감해질수록, 재시도 루프 (retry loop)로는 해결할 수 없는 이유로 모델을 사용할 수 없게 되는 방식이 더 많아지기 때문입니다.

이번 주에 제가 할 일

만약 제가 API 개발자라면:

• claude-fable-5를 기본 프로덕션 경로에서 비활성화하겠습니다.
• 까다로운 Claude 작업은 Opus 4.8로 라우팅하겠습니다.
• 모델 사용 불가 시 작동하는 서킷 브레이커 (circuit breaker)를 추가하겠습니다.
• 요청된 모델과 실제 제공된 모델을 로그로 남기겠습니다.
• 상태 확인 및 계정 수준의 API 체크를 통과한 후에만 Fable을 다시 활성화하겠습니다.

만약 제가 엔터프라이즈 관리자라면:

• 사용자들에게 Fable/Mythos가 중단되었음을 알리겠습니다.
• 승인된 폴백 (fallback) 모델을 고정하겠습니다.
• Anthropic이 정책을 변경하기 전까지는 ZDR 민감 워크로드를 Fable에서 제외하겠습니다.
• 조달/법무 부서에 이것이 모델 리스크 요구 사항을 변경하는지 문의하겠습니다.

만약 제가 모델 게이트웨이 (model gateway)를 구축하고 있다면:

• Fable을 성능 저하 (degraded)가 아닌 비활성화 (disabled) 상태로 표시하겠습니다.
• 상태 확인 (health check)을 통해 확인될 때까지 사용 가능하다고 광고하는 것을 중단하겠습니다.

Claude Fable 5가 출시 4일 만에 중단된 것은 단순히 Anthropic의 일시적인 실수(hiccup)가 아닙니다. 이는 프론티어 모델(frontier-model)의 리스크가 이제 지연 시간(latency), 가격, 벤치마크 점수뿐만 아니라 정책적 접근성(policy access)까지 포함한다는 점을 상기시켜 줍니다.

저의 의견은 다음과 같습니다: 패닉에 빠질 필요는 없지만, 가만히 기다려서도 안 됩니다. 오늘 즉시 운영 환경(production)의 기본 설정을 Fable에서 제외하고, Claude의 폴백(fallback) 모델로 Opus 4.8을 유지하십시오. 그리고 공식 상태 페이지(status page)와 귀하의 자체 상태 확인(health check) 결과가 일치할 때만 Fable을 다시 복구하십시오.

만약 당신이 AI 코딩 제품을 운영하고 있다면, Fable이 사라졌을 때 사용자에게 폴백 모델을 명시적으로 보여주겠습니까, 아니면 조용히 Opus를 제공하겠습니까?