2026년 6월 12일, 많은 개발자가 사용하던 고성능 모델이 갑자기 응답을 멈췄습니다. 속도 제한이나 지역 장애가 아니라, 미국 정부의 수출 통제 지침에 따른 전 세계적 접근 중단이었습니다. 동부 표준시 오후 5시 21분, Anthropic은 클로드 페이블 5와 클로드 미토스 5에 대한 접근을 중단하라는 지침을 받았고, 결과적으로 모든 사용자에게 영향이 갔습니다.
앱, 에이전트, CI 파이프라인에서 claude-fable-5를 직접 호출하고 있었다면 해당 호출은 실패했을 가능성이 큽니다. 이 글에서는 무엇이 발생했는지, 왜 발생했는지, 그리고 LLM API 위에 서비스를 구축할 때 어떤 방어 설계를 해야 하는지 정리합니다.
요약
- 무슨 일: Anthropic은 2026년 6월 12일 미국 정부의 수출 통제 지침에 따라 페이블 5와 미토스 5 접근을 중단했습니다.
- 영향 범위: 실질적으로 전 세계 사용자입니다. 지침은 “미국 내외의 모든 외국인”을 대상으로 했고, 공급업체가 모든 API 호출자의 국적을 실시간으로 확실히 구분하기 어렵기 때문에 전체 중단으로 이어졌습니다.
- 이유: 다른 회사가 탈옥 방법을 발견했다고 주장한 뒤, 정부는 국가 안보를 이유로 조치했습니다. Anthropic은 “다른 모델에서도 널리 사용 가능한” 코드 분석 기술을 사용한 “제한적인 잠재적 탈옥”만 확인했다고 밝혔습니다.
- 영향받지 않은 모델: Opus, Sonnet, Haiku는 계속 사용 가능했습니다. 중단 대상은 Mythos 등급 모델 두 개였습니다.
- 현재 상태: Anthropic은 근거에 이의를 제기하면서도 지침을 준수하고 있으며, 접근 복원을 위해 노력 중이라고 밝혔습니다.
- 개발자 관점의 교훈: 모델은 코드 품질과 무관한 외부 요인으로 사라질 수 있습니다. 모델 가용성은 통제 불가능한 외부 의존성으로 다뤄야 합니다.
무슨 일이 일어났나
Anthropic은 2026년 6월 12일 동부 표준시 오후 5시 21분, 미국 정부로부터 지침을 받았다고 성명을 통해 밝혔습니다. 수출 통제 당국의 지침에 따라 회사는 페이블 5와 미토스 5 접근을 즉시 중단해야 했습니다.
문제는 지침의 적용 범위였습니다. 해당 지침은 “해외 거주자, 미국 내외의 외국인 Anthropic 직원을 포함한 모든 외국인”에게 적용됩니다. 클라우드 API 제공자가 모든 API 키 뒤의 실제 사용자 국적을 실시간으로 완벽히 검증하기는 어렵습니다.
따라서 확실히 준수하는 유일한 방법은 모델 접근을 전체적으로 끄는 것이었습니다.
중요한 점은 범위가 모델 단위로는 좁았다는 것입니다.
영향받은 모델은 페이블 5와 미토스 5뿐입니다. Anthropic은 “다른 모든 Anthropic 모델에 대한 접근은 영향을 받지 않을 것”이라고 밝혔습니다. Opus, Sonnet, Haiku는 계속 온라인 상태를 유지했습니다.
페이블 5와 미토스 5는 무엇인가
두 모델은 중단 직전 며칠 전에 출시되었습니다. 따라서 일부 팀은 이미 이 모델들로 마이그레이션을 마친 상태였을 수 있습니다.
클로드 페이블 5는 2026년 6월 9일 출시된 일반 가용성 Mythos 등급 모델입니다. 내장된 안전 장치를 포함하며, 개발자는 Claude API에서 claude-fable-5로 호출했습니다. 가격은 입력 토큰 백만 개당 10달러, 출력 토큰 백만 개당 50달러였습니다.
클로드 미토스 5는 동일한 기반 모델이지만, 사이버 보안 전문가나 신뢰할 수 있는 접근 프로그램의 공인 연구원처럼 검증된 사용자에게 안전 장치가 해제된 형태로 제공되었습니다.
이 모델들이 주목받은 이유는 다음과 같습니다.
- 소프트웨어 엔지니어링: Anthropic은 페이블 5가 “몇 달간의 엔지니어링 작업을 며칠로 압축”한다고 설명했으며, 5천만 줄의 Ruby 코드베이스를 하루 만에 Stripe로 마이그레이션한 사례를 언급했습니다.
- 장문 컨텍스트 추론: 두 모델 모두 자율적인 장기 실행 작업에서 “수백만 개의 토큰에 걸쳐 집중력을 유지”한다고 소개되었습니다.
- 비전: 스크린샷에서 웹 앱 소스를 재구축하거나 과학 그림에서 정확한 숫자를 추출하는 등의 기능이 강조되었습니다.
- 생명 과학: 미토스 5는 약물 설계를 약 10배 가속화한 것으로 알려졌습니다.
페이블 5의 안전 장치는 이번 논쟁의 핵심입니다. 페이블 5는 공격적 사이버 요청, 특정 생물학 및 화학 관련 요청, 증류 시도처럼 위험한 쿼리를 AI 분류기를 통해 처리합니다. 이 분류기는 필요한 경우 Claude Opus 4.8로 대체됩니다.
Anthropic은 “페이블 세션의 95% 이상이 전혀 대체되지 않는다”고 설명했습니다.
Anthropic과 OpenAI가 잠긴 사이버 모델과 개방형 사이버 모델을 두고 어떻게 다른 접근을 취하는지에 대한 배경은 OpenAI Daybreak vs Claude Mythos에서 다뤘습니다.
정부가 이들을 중단시킨 이유
CNBC와 Bloomberg 보도에 따르면, 상무부는 다른 회사가 미토스를 탈옥했다고 주장한 후 조치를 취했습니다.
정부가 제시한 우려는 국가 안보였습니다. 즉, 페이블의 안전 장치를 우회하고 외국인에게 위험한 기능을 노출할 수 있는 방법이 존재한다는 것입니다.
Anthropic의 설명은 더 제한적입니다.
회사는 시연을 검토한 결과, 코드 분석 기술을 기반으로 한 “제한적인 잠재적 탈옥”을 발견했다고 밝혔습니다. 또한 이 기능은 “다른 모델에서도 널리 사용 가능한” 것이라고 주장했습니다.
Anthropic은 지금까지 구두 증거만 확인했으며, 재현 가능하고 보편적인 탈옥은 아니라고 설명했습니다.
핵심 쟁점은 다음과 같습니다.
제한적이고 재현 가능성이 불분명한 탈옥 가능성이 수억 명이 사용하는 모델의 즉시 중단을 정당화하는가?
Anthropic의 대응
Anthropic은 지침을 준수하면서 동시에 그 근거에 이의를 제기하고 있습니다.
회사는 당일 저녁 모델 접근을 중단했습니다. 그러나 공개적으로 다음과 같은 입장도 밝혔습니다.
- 완벽한 탈옥 방지는 불가능합니다. Anthropic을 포함한 어떤 모델 제공업체도 모델이 절대 뚫리지 않는다고 보장할 수 없습니다.
- 해당 기능은 독점적이지 않습니다. 문제가 일반적인 코드 분석 기술에 의존한다면, 다른 최첨단 모델에도 유사한 기능이 존재할 수 있습니다.
- 비용이 불균형합니다. Anthropic은 제한적인 익스플로잇 가능성이 “수억 명의 사람들”이 의존하는 모델 중단을 정당화하지 않는다고 주장했습니다.
Anthropic은 24시간 이내에 추가 정보를 공유하고 접근 복원을 위해 노력하겠다고 밝혔습니다.
API 기반 서비스를 운영한다면 무엇이 문제인가
이번 사건은 일반적인 장애와 다릅니다.
모델이 사전 공지된 일정에 따라 종료된 것도 아니고, 성능 저하나 비용 문제로 교체된 것도 아닙니다. 제3자인 정부가 규제 이유로 접근을 차단했습니다.
claude-fable-5를 직접 의존하고 있었다면 다음 문제가 발생할 수 있습니다.
- 프로덕션 호출 실패: 중단된 모델에 대한 모든 요청이 오류를 반환합니다.
- 유예 기간 없는 마이그레이션: 6개월 전 공지가 아니라 당일 중단입니다.
- 기능 수준의 회귀: 장문 컨텍스트, 비전, 추론 품질에 의존했다면 단순히 작은 모델로 바꾸기 어렵습니다.
- 에이전트 워크플로우 불안정: 특정 모델 출력을 가정한 다단계 에이전트는 멈추거나, 루프에 빠지거나, 품질이 낮은 결과를 만들 수 있습니다.
결론은 명확합니다.
LLM 모델 가용성은 여러분이 소유하지 않는 외부 의존성입니다. 규제, 수출법, 보안 사고, 공급업체 정책에 의해 갑자기 바뀔 수 있습니다.
따라서 목표는 “절대 장애가 나지 않게 하기”가 아니라, 모델 장애를 통제 가능한 페일오버로 바꾸는 것입니다.
모델 중단에 대비한 구현 패턴
이 문제는 API 엔지니어링 문제입니다. Apidog는 AI 엔드포인트를 설계, 모의 테스트, 테스트, 모니터링하여 공급업체 이벤트가 서비스 인시던트로 번지지 않도록 돕는 데 사용할 수 있습니다.
1. 모델 ID를 애플리케이션 코드에서 제거하세요
애플리케이션 곳곳에서 공급업체 모델 ID를 직접 호출하면 장애 대응이 느려집니다.
피해야 할 방식:
await anthropic.messages.create({
model: "claude-fable-5",
messages: [{ role: "user", content: prompt }],
});
대신 내부 API를 하나 두고, 서버 측 설정에서 모델을 선택하세요.
POST /v1/ai/complete
Content-Type: application/json
{
"task": "code_review",
"input": "..."
}
내부 게이트웨이 예시:
const modelByTask = {
code_review: process.env.CODE_REVIEW_MODEL,
summarization: process.env.SUMMARY_MODEL,
agent_planning: process.env.AGENT_MODEL,
};
app.post("/v1/ai/complete", async (req, res) => {
const { task, input } = req.body;
const model = modelByTask[task] ?? process.env.DEFAULT_MODEL;
const result = await callModel({
model,
input,
});
res.json(result);
});
이렇게 하면 claude-fable-5를 대체 모델로 바꿀 때 전체 서비스를 재배포하지 않고 설정만 변경할 수 있습니다.
이는 상위 공급업체 변경으로부터 애플리케이션을 보호하는 계약 우선 원칙과 같은 접근입니다.
2. 대체 체인을 미리 정의하세요
모델 장애가 발생한 뒤 어떤 모델로 바꿀지 결정하면 늦습니다.
작업 유형별로 기본 모델과 대체 모델을 미리 정하세요.
{
"routes": {
"code_review": {
"primary": "claude-fable-5",
"fallback": ["claude-opus-4.8", "claude-sonnet"]
},
"summarization": {
"primary": "claude-fable-5",
"fallback": ["claude-sonnet", "claude-haiku"]
}
}
}
페일오버 로직 예시:
async function callWithFallback({ task, input }) {
const route = routes[task];
const candidates = [route.primary, ...route.fallback];
let lastError;
for (const model of candidates) {
try {
return await callModel({ model, input });
} catch (err) {
lastError = err;
if (!isAvailabilityError(err)) {
throw err;
}
}
}
throw lastError;
}
function isAvailabilityError(err) {
return [403, 404, 429, 503].includes(err.status);
}
중요한 점은 모든 오류에서 무조건 fallback하지 않는 것입니다. 인증 오류, 프롬프트 오류, 잘못된 요청 형식까지 fallback하면 실제 버그가 숨겨질 수 있습니다.
3. 공급업체 오류를 모의 테스트하세요
페일오버 로직은 실제 장애 전에 검증해야 합니다.
예를 들어 모의 서버가 다음과 같은 응답을 반환하도록 설정합니다.
{
"error": {
"type": "model_unavailable",
"message": "The requested model is currently unavailable."
}
}
그 다음 내부 게이트웨이가 다음을 올바르게 수행하는지 확인합니다.
-
claude-fable-5호출 실패 감지 - 대체 모델 호출
- 클라이언트에는 정상 응답 반환
- 로그와 메트릭에 fallback 발생 기록
Apidog를 사용하여 모의 서버에서 공급업체의 오류 형식을 반환하고 실패 모드를 테스트하면 프로덕션 장애 전에 페일오버 동작을 확인할 수 있습니다.
4. 에이전트는 대체 모델에서도 테스트하세요
단일 요청/응답 API보다 에이전트 워크플로우가 더 취약합니다.
에이전트는 보통 다음과 같은 가정을 연결합니다.
- 계획 생성
- 도구 선택
- API 호출
- 결과 해석
- 다음 단계 결정
모델이 바뀌면 각 단계의 출력 형식, 추론 깊이, 도구 선택 패턴이 달라질 수 있습니다.
테스트해야 할 항목은 다음과 같습니다.
- 대체 모델에서도 JSON 스키마를 지키는가
- 도구 호출 이름을 정확히 선택하는가
- 긴 컨텍스트에서 이전 단계를 잃지 않는가
- 실패 시 무한 루프에 빠지지 않는가
- 결과 품질이 허용 범위 안에 있는가
API를 통해 AI 에이전트를 테스트하는 방법을 참고하면 동일한 에이전트 테스트 스위트를 여러 백엔드 모델에 대해 실행할 수 있습니다.
5. 모델 상태를 별도 모니터링하세요
공급업체 상태 페이지를 수동으로 확인하는 방식으로는 부족합니다.
의존 중인 모델별로 주기적인 헬스체크를 실행하세요.
async function checkModelHealth(model) {
try {
const started = Date.now();
await callModel({
model,
input: "Reply with OK only.",
maxTokens: 5,
});
return {
model,
ok: true,
latencyMs: Date.now() - started,
};
} catch (err) {
return {
model,
ok: false,
status: err.status,
message: err.message,
};
}
}
알림 기준 예시:
- 3회 연속 실패
- 평균 지연 시간 급증
- 특정 모델만
403,404,503반환 - fallback 발생률 증가
사용자 문의로 장애를 알기 전에, 자체 모니터링이 먼저 감지해야 합니다.
6. 보조 공급업체를 실제로 연결해 두세요
비즈니스 연속성이 중요하다면 “나중에 붙일 수 있는 공급업체”는 백업이 아닙니다.
백업 공급업체는 다음 상태여야 합니다.
- API 키 발급 완료
- 내부 게이트웨이에 연결 완료
- 인증 및 과금 확인 완료
- 최소 기능 테스트 통과
- 에이전트/워크플로우 회귀 테스트 완료
- 장애 시 전환 절차 문서화 완료
Claude 기반 실험과 검증을 계속하면서 복원력을 준비하려면 무료 무제한 Claude API 접근 방법도 참고할 수 있습니다.
실전 체크리스트
LLM API를 프로덕션에서 사용한다면 다음을 점검하세요.
- [ ] 애플리케이션 코드에 공급업체 모델 ID가 하드코딩되어 있지 않은가
- [ ] 내부 AI 게이트웨이 또는 추상화 API가 있는가
- [ ] 작업 유형별 기본 모델과 대체 모델이 정의되어 있는가
- [ ] 모델 가용성 오류와 일반 애플리케이션 오류를 구분하는가
- [ ] fallback 로직이 테스트되어 있는가
- [ ] 공급업체 오류 응답을 모의 테스트할 수 있는가
- [ ] 에이전트 워크플로우를 여러 모델에서 검증하는가
- [ ] 모델별 헬스체크와 알림이 있는가
- [ ] 보조 공급업체가 실제로 연결되어 있는가
- [ ] 장애 시 전환 절차가 문서화되어 있는가
결론
페이블 5와 미토스 5 중단은 단순한 모델 장애가 아닙니다. LLM API가 규제, 보안, 정책 리스크를 포함한 외부 의존성이라는 점을 보여준 사례입니다.
모델 성능은 중요합니다. 하지만 프로덕션 시스템에서는 모델 가용성, 교체 가능성, 테스트 가능성도 같은 수준으로 중요합니다.
claude-fable-5 같은 특정 모델을 직접 의존하지 말고, 내부 API 뒤에 감추고, 대체 체인을 정의하고, 장애 응답을 모의 테스트하고, 에이전트를 여러 모델에서 검증하세요.
모델은 갑자기 사라질 수 있습니다. 하지만 서비스까지 같이 멈출 필요는 없습니다.
Top comments (0)