AI 모델이 '수출 관리'로 인해 중단된다는 것은 무엇을 의미하는가: Fable 5 중단을 기술자 관점에서 풀이

사용하던 AI 모델이 어느 날 에러를 반환하기 시작했습니다. "선택한 모델에 문제가 있습니다. 존재하지 않거나 액세스 권한이 없을 수 있습니다". 장애인가 싶어 조사해 보니, 원인은 장애도 가격 인상도 아닌 '수출 관리 (export control)'였습니다.

2026년 6월 12일, Anthropic이 Claude Fable 5와 Mythos 5를 모든 고객을 대상으로 무효화했습니다. 미국 정부의 수출 관리 명령을 따르기 위해서입니다. 이 "수출 관리로 인해 모델이 중단되는" 사태는 기술자에게는 생소하기 때문에, 무엇이 일어났는지 풀어서 정리해 보겠습니다. 그 후에 자신의 운영 환경을 어떻게 보호할지에 대해서도 쓰겠습니다.

사실은 확인한 시점(2026년 6월 13일)의 것입니다. 이 건은 몇 시간 단위로 상황이 변하고 있으며, Anthropic은 24시간 이내에 상세 내용을 발표할 예정이라고 합니다. 최신 정보는 공식 채널에서 확인해 주세요. 출처는 말미에 정리하겠습니다.

먼저 사실만을 나열하겠습니다.

• Fable 5와 Mythos 5는 6월 9일에 공개되었다
• 6월 12일 동부 시간 17시 21분, 미국 정부로부터 수출 관리 명령이 전달되었다
• 명령 내용은 "어떠한 외국 국적자에 의한 액세스도 금지". 미국 내외를 불문하고 Anthropic 자신의 외국 국적 직원도 포함한다
• Anthropic은 실시간으로 국적을 판별하여 차단할 수 없기 때문에, 모든 고객을 대상으로 두 모델을 완전히 중단했다
• Opus 4.8 등 다른 모델은 영향을 받지 않았다

여기까지가 거의 논란의 여지가 없는 사실입니다.

이 부분이 가장 풀어서 설명하고 싶은 대목입니다.

수출 관리 (export control)는 평소에는 무기나 특정 반도체 등, 국경을 넘어 이동하는 것을 국가가 관리하고자 하는 '물건'에 대해 사용하는 법적 프레임워크입니다. 누구에게, 어디로 넘겨도 되는지를 국가가 제한하며, 경우에 따라서는 라이선스 (license, 허가)가 없으면 넘겨줄 수 없습니다. 기술자의 감각으로 치환하면, 특정 암호 기술이나 군사 전용이 가능한 부품이 수출 규제 리스트에 올라 자유롭게 반출할 수 없게 되는 바로 그 메커니즘입니다.

이번에는 그것이 이미 배포된 AI 모델의 능력에 적용되었습니다. 즉, 국가는 이 모델을 "국경을 넘어 넘겨주어서는 안 되는 물건"으로 취급했다는 뜻입니다. 실제로 보도에 따르면, 상무부의 서한에서는 이 모델들의 수출·재수출·국내 이전 시 라이선스가 필요하다고 명시되어 있습니다. 소프트웨어의 액세스 권한이 규제 대상 화물과 동일한 틀 안에서 논의되고 있는 것입니다. 이 점이 새로운 부분입니다.

엔지니어로서 의구심이 드는 지점은 바로 여기일 것입니다. 명령은 "외국 국적자의 액세스 금지"인데, 왜 모두가 사용할 수 없게 되는가?

이유는 구현상의 제약입니다. Anthropic은 미국 사용자 중에서 외국 국적자만을 실시간으로 판별하여 걸러내는 작업을 할 수 없습니다. 국적은 IP나 계정 정보만으로는 확실히 알 수 없기 때문입니다. 명령의 대상은 "미국 내외의 모든 외국 국적자"이므로, 확실하게 준수하려고 하면 누가 외국 국적인지 판별할 수 없는 이상 모두를 중단시킬 수밖에 없습니다. 선택적으로 준수하려고 하면 자사의 외국 국적 직원까지 포함하여 광범위하게 차단해야 하는 상황이 발생합니다. 따라서 기술적으로 "전원 중단"이 유일하고 확실한 컴플라이언스 (compliance, 준수)가 된 것입니다.

이는 콘텐츠 필터나 지역 제한과는 성격이 다릅니다. 지역 제한이라면 IP 기반으로 차단할 수 있지만, "국적"은 요청(request) 데이터만으로는 판별할 수 없는 속성입니다. 판별할 수 없는 조건으로 차단을 요구받았을 때, 안전한 방향으로 기울여 전부 중단시키는 것은 구현 측면에서 이해할 수 있는 귀결입니다.

여기서 일어난 일은 벤더의 사정 때문도, 당신의 코드 실수 때문도 아닙니다. 지정학에 의한 중단입니다. 게다가 대부분의 SLA나 이용 약관은 이러한 종류의 "정부 명령에 의한 이용 불능"을 커버하지 않습니다. 가용성 (availability)의 전제가 기술이나 상관습의 외부에서 무너졌다는 점이 새로운 리스크입니다.

이유 부분은 아직 확정되지 않았습니다. 이 부분은 깊게 파고들지 않고 요점만 남겨둡니다.

Anthropic의 설명에 따르면, 정부는 Fable 5의 탈옥 (jailbreak) 수법이 발견되었다고 판단하고 있다고 합니다. 다만 동사는 그것이 다른 공개 모델에서도 별도의 회피 없이 발견되는 경미하고 알려진 취약성에 불과하며, 유니버설한 탈옥은 발견되지 않았다고 반론하고 있습니다. 동사는 이 상황을 오해라고 부르며, 액세스 복구를 위해 노력하고 있다고 밝혔습니다.

한편, Axios는 "다른 기업이 Mythos를 탈옥했다고 주장한 것이 발단"이라고 보도했으나, 이는 단일 소스의 보도이며 Anthropic은 확인해주지 않았습니다. 사실로 취급하지 마십시오. 정치적·전례적 심층 분석은 내용이 길어지므로 별도의 기사로 나누겠습니다. 이 기사의 주안점은 기술자로서 무엇이 일어나고 있으며, 무엇을 할 수 있는가입니다.

일어난 일이 "내가 의존하는 모델이 외부 요인으로 인해 갑자기 사라지는 것"이라면, 대처법은 명확합니다. 모델을 교체 가능하게 만들어 두는 것, 이 한 가지에 달려 있습니다.

생각하는 방식은 데이터베이스나 클라우드 벤더 락인 (Vendor Lock-in) 대책과 같습니다. 특정 모델명을 코드 곳곳에 직접 작성하지 마세요. 한 곳으로 집약하여 설정(Configuration)을 통해 교체할 수 있도록 합니다. 그리고 교체할 대상을 사전에 결정하고, 실제로 작동하는지 테스트해 둡니다.

범용적인 의사 코드 (Pseudo-code)로 보여드리겠습니다. 먼저, 모델 선택을 설정값으로 분리합니다.

# config: 모델을 코드에 직접 쓰지 않고, 우선순위와 폴백 (Fallback)을 설정으로 관리
MODEL_CHAIN = [
{"provider": "anthropic", "model": "primary-model"}, # 평소 사용하는 모델
...

호출하는 쪽은 특정 모델명을 알 필요가 없습니다. 체인 (Chain)을 위에서부터 시도하며, 사용할 수 없는 것은 다음으로 넘기기만 하면 됩니다.

def call_model(messages):
    last_error = None
    for entry in MODEL_CHAIN:
        ...

여기서 핵심은 ModelUnavailableError의 처리입니다.

이번 사례처럼 어제까지 사용 가능했던 모델이 "존재하지 않음" 또는 "액세스 권한 없음" 에러를 반환하는 경우를 일시적인 실패로 간주하여 폴백 (Fallback) 단계로 넘깁니다. 예외 (Exception)를 무시하지 말고, 다음 후보로 확실히 넘기도록 합니다. 이 부분을 처음부터 설계해 두면, 모델 하나가 사라져도 서비스는 중단되지 않습니다.

실제로 이번에 Opus 4.8 등이 무사했던 덕분에, 폴백 (Fallback) 경로를 갖추고 있던 통합 시스템은 파괴되지 않고 기능 축소 (Degradation) 수준에서 그쳤습니다. 반대로 fable-5와 같이 특정 모델에 고정되어 있던 구현은 그 자리에서 멈췄습니다. 차이는 체인 (Chain)을 가지고 있었느냐 없었느냐뿐입니다.

마지막으로, 폴백 (Fallback) 경로는 반드시 테스트하십시오. 작성만 하고 한 번도 실행해 보지 않은 폴백 (Fallback)은 정작 위급한 상황에서 작동하지 않습니다. 평소 테스트 시 의도적으로 첫 번째 모델을 다운시키고, 두 번째나 세 번째 모델이 응답하는지 확인해 두어야 합니다. 이를 해두면 "어느 날 아침 모델이 사라졌다"는 상황이 설정 변경 하나로 끝날 수 있는 문제가 됩니다.

이번 사건을 통해 제 안의 전제 중 하나가 바뀌었습니다. 프런티어 모델 (Frontier Model)은 기반 (Foundation)이 아니라 의존 (Dependency)이라는 점입니다. 기반은 내 발밑에 있어 움직이지 않지만, 의존은 외부 사정에 의해 제거될 수 있습니다. 그리고 이번에는 그 "외부 사정"에 지정학적 이슈와 수출 관리 (Export Control)라는, 지금까지 가용성 설계 (Availability Design)에서 고려하지 않았던 축이 추가되었습니다.

그러므로 특정 모델에 고정하지 마십시오. 교체가 설정 변경만으로 가능하도록 만들고, 폴백 (Fallback)을 사전에 테스트하십시오. 이것은 현명한 모델을 고르는 문제가 아니라, 어떤 모델이 사라지더라도 자신의 서비스가 유지될 수 있도록 하는 설계의 문제입니다. 3일 만에 공개되고 3일 만에 사라진 모델을 보며 가장 남기고 싶은 교훈은 이것입니다.

숫자나 사양은 공식 문서를 통해 최신 정보를 확인하시기 바랍니다.