AI 모델 갑작스러운 장애 발생 시: AI API 페일오버 설계 전략

2026년 6월 12일, 미국의 수출 통제로 인해 Anthropic은 거의 아무런 경고 없이 Claude Fable 5를 오프라인으로 전환해야 했고, 이 모델은 7월 1일에 복구될 때까지 작동하지 않았습니다. 하나의 모델 문자열을 하드 코딩했던 팀들은 19일 동안 허둥지둥했지만, 페일오버 체인을 갖춘 팀들은 설정 값을 변경하고 다시 작업에 들어갔습니다.

이 교훈은 단순히 한 번의 서비스 중단보다 더 큰 의미를 가집니다. 대부분의 LLM 기반 애플리케이션은 모델 가용성을 DNS나 중력처럼 상수처럼 취급합니다. 이는 아키텍처적 가정이며, 잘못된 것입니다. 모델은 법적 노출, 용량 제한, 서비스 종료 일정, 그리고 언제든 모델을 철회할 수 있는 안전 팀을 가진 제품입니다. 이 가이드는 AI API를 위한 페일오버를 설계하는 방법을 다루며, 다음 번 모델 중단이 어떤 공급자에게 발생하든 인시던트 브릿지 대신 설정 변경만으로 해결할 수 있도록 돕습니다.

버튼

모델이 사라지는 이유

대부분의 팀이 예상하는 것보다 더 많은 이유로 모델이 사라집니다:

규제. Fable 5 중단은 기술적 결함이 아니라 수출 통제에서 비롯되었습니다. 법적 및 규제 관련 사건은 서비스 종료 일정을 따르지 않으며, 90일 사전 통지를 보내지도 않습니다. 서비스 중단 당시 외부에서 본 모습은 다음과 같습니다.
공급자 장애. 모든 주요 공급자는 몇 시간 동안의 서비스 중단을 겪었습니다. 공급자의 서비스가 복구되는 동안 고객과의 SLA는 중단되지 않습니다.
서비스 종료. 공급자는 공지된 일정에 따라 모델을 단종합니다. OpenAI는 지속적으로 서비스 종료 페이지를 유지하고 있으며, Anthropic도 같은 방식으로 이전 Claude 버전을 단종했습니다. 서비스 종료는 달력 날짜가 정해진 느린 속도의 서비스 중단입니다.
용량. 출시 주간이나 트래픽 급증 시, 공급자는 부하를 줄입니다. 모델이 "존재"하더라도 요청은 429 및 529 오류를 반환하기 시작합니다.
안전 롤백. 공급자는 출시 후 문제를 발견하면 모델을 차단하거나 철회할 수 있습니다. 이는 조용히, 때로는 계정별로 발생합니다.

원인은 다르지만 증상은 동일합니다: 코드에서 사용하는 모델 ID가 응답을 멈추는 것입니다. 원인에 관계없이 해결책은 동일하며, 이것이 페일오버 설계가 인시던트 대응이 아닌 상시적인 작업인 이유입니다.

페일오버 계층

페일오버는 하나의 결정이 아닙니다. 세 가지 수준이 있으며, 성숙한 시스템은 일반적으로 하나 이상을 구현합니다.

레벨 1: 동일 공급자 폴백. 동일 공급자의 자매 모델로 라우팅합니다. 예를 들어 Fable 5 → Opus 4.8 → Sonnet 4.6과 같이요. 동일한 SDK, 동일한 인증, 동일한 응답 형태이므로 전환이 저렴하고 빠릅니다. Anthropic은 심지어 동일한 API 호출 내에서 거부된 요청을 대체 모델로 재시도하는 폴백 매개변수를 통해 서버 측에서도 이를 지원합니다. 필요하기 전에 폴백 쌍을 알아두세요. Fable 5와 Opus 4.8 비교는 새벽 3시에 빛을 발하는 숙제와 같습니다.

레벨 2: 교차 공급자 폴백. 완전히 다른 공급업체로 라우팅합니다. 이는 동일 공급자 체인으로는 버틸 수 없는 공급자 전체 장애, 계정 정지, 지역 제한으로부터 보호해 줍니다. 비용은 두 번째 SDK, 두 번째 청구 관계, 두 번째 인증 경로, 그리고 다르게 동작하는 프롬프트입니다.

레벨 3: 기능 저하 모드. 첨단 모델 없이도 유용한 것을 제공합니다. 반복되는 쿼리에 대한 캐시된 답변, 분류 수준 작업에 사용되는 작은 로컬 모델, 또는 명확한 메시지와 함께 비활성화된 기능 등이 될 수 있습니다. 기능이 나빠지는 것은 용인되지만, 애플리케이션이 완전히 중단되는 것은 용납되지 않습니다.

수준	전환 지연 시간	품질 저하	엔지니어링 비용
동일 공급자 폴백	몇 초~몇 분; 설정 변경 또는 자동 재시도	작거나 중간; 동일 모델 계열, 익숙한 동작	낮음; 동일 SDK, 인증, 응답 형식
교차 공급자 폴백	몇 분~몇 시간; 라우팅 로직 및 테스트된 프롬프트 필요	중간; 다른 토크나이저, 형식, 거부 동작	중간에서 높음; 두 번째 통합, 청구, 모니터링
기능 저하 모드	구축 시 사실상 즉각적	크지만 예측 가능하고 정직함	중간; 캐시 계층, 로컬 모델 또는 기능 플래그

대부분의 팀은 이번 분기에 레벨 1을 배포하고, 레벨 3을 최소한의 수준으로 유지하며, 두 번째 통합에 따른 위험 수익이 정당화될 때만 레벨 2를 추가해야 합니다.

한 가지 더 설계 시 고려할 점: 단순히 대상을 넘어 트리거 조건을 정의해야 합니다. 트래픽을 어떤 조건으로 전환할지 결정하기 전까지는 체인이 완전하지 않습니다. 합리적인 기본값: 모델 ID에 대한 404 오류는 즉시 페일오버를 트리거하고, 거부 응답은 다음 모델로 한 번 재시도하며, 429 오류는 페일오버 전에 백오프하고, 세 번 연속 타임아웃은 해당 모델에 대한 서킷 브레이커를 엽니다. 이러한 규칙을 라우팅 계층에 인코딩하여 새벽 3시의 결정이 이미 내려져 있도록 합니다.

페일오버 비용을 절감하는 설계 방법

페일오버는 어떤 서비스 중단이 발생하기 훨씬 전에 내린 결정에 따라 저렴할 수도 있고 비쌀 수도 있습니다.

모델 ID를 코드 대신 설정 파일에 넣으세요. 모델 문자열에 대해 빠르게 grep을 실행해보세요. 하나의 설정 파일이 아닌 애플리케이션 코드에 나타난다면, 배포 없이는 페일오버할 수 없습니다. 경로별 우선순위 목록이 효과적인 형태입니다:

# config/model-routes.yaml
routes:
  chat-assist:
    primary: claude-fable-5
    fallbacks:
      - claude-opus-4-8
      - claude-sonnet-4-6
    degraded_mode: cached_answers
    max_output_tokens: 8192
    timeout_seconds: 120
  ticket-classifier:
    primary: claude-sonnet-4-6
    fallbacks:
      - claude-haiku-4-5
    degraded_mode: rules_engine

라우팅은 한 곳에서 관리하세요. 게이트웨이 서비스든 100줄짜리 래퍼든, 정확히 하나의 모듈이 어떤 모델이 요청을 처리할지 결정해야 하며, 다른 모든 것은 이를 호출해야 합니다. 최소 버전은 다음과 같습니다:

MODEL_CHAIN = ["claude-fable-5", "claude-opus-4-8", "claude-sonnet-4-6"]

def complete(prompt: str) -> str:
    last_error = None
    for model in MODEL_CHAIN:
        try:
            response = client.messages.create(
                model=model,
                max_tokens=8192,
                messages=[{"role": "user", "content": prompt}],
            )
            if response.stop_reason == "refusal":
                last_error = RefusalError(model)
                continue  # 체인의 다음 모델을 시도합니다
            return response.content[0].text
        except (anthropic.NotFoundError, anthropic.RateLimitError,
                anthropic.APIStatusError) as err:
            last_error = err
            continue
    raise AllModelsUnavailable(MODEL_CHAIN) from last_error

프로덕션 버전에는 서킷 브레이커와 모델별 타임아웃이 추가되지만, 호출자는 모델이 아닌 완성을 요청한다는 원칙은 어떤 규모에서도 동일합니다.

기능 계층별 프롬프트를 작성하세요. 특정 모델의 특이점에 의존하는 프롬프트는 페일오버를 불가능하게 만듭니다. 전체 폴백 세트에서 허용 가능한 출력을 생성하는 핵심 프롬프트를 작성한 다음, 모델별 특정 트릭(특정 사고 구성, 조정된 서식 습관)을 작업에 지장 없이 삭제할 수 있는 모델별 오버레이로 분리하세요. 가장 강력한 기본 모델이 아닌 가장 약한 폴백 모델에서 기본 프롬프트를 테스트하세요. 이는 생각보다 중요합니다. 최신 첨단 모델은 간결하고 목표 지향적인 프롬프트를 선호하는 반면, 작은 폴백 모델은 더 명시적인 구조를 필요로 합니다. 기본 모델에 맞춰 모든 것을 조정하면 폴백 모델이 잘 따를 수 없는 지침을 상속받게 되지만, 전체 세트에 맞춰 조정하면 기본 모델의 정교함이 약간 떨어지더라도 처음부터 끝까지 작동하는 체인을 얻게 됩니다.

요청 매개변수도 이식 가능하게 유지하세요. 프롬프트만이 모델별 특이점은 아닙니다. 사고 구성, 샘플링 매개변수, 출력 제한은 모델 세대마다 다르며, 기본 모델이 허용하는 매개변수가 폴백 모델에서 400 오류를 반환할 수 있습니다. 모델별 매개변수 세트를 설정 파일의 모델 ID 옆에 저장하고, 라우팅 계층이 디스패치 시점에 이를 적용하도록 하세요. 유효하지 않은 매개변수 오류로 중단되는 페일오버는 사실상 없는 것과 마찬가지입니다.

공급자 중립적으로 응답을 처리하세요. 라우팅 경계에서 응답을 자체 내부 형식으로 정규화하세요. 텍스트 출력, 구조화된 필드 유효성 검사, 중지 이유를 자체 열거형에 매핑하는 방식입니다. 공급자별 응답 객체에 여러 곳에서 접근하는 코드는 공급자를 교체하는 날 작동을 멈출 것입니다.

비용 및 제한 차이를 고려하세요. 폴백 모델은 토큰당 가격, 컨텍스트 윈도우, 최대 출력에서 차이가 있습니다. Fable 5에서 Opus 4.8로 전환하면 토큰당 비용이 대략 절반으로 줄어들고, Sonnet 4.6은 더 저렴하지만 출력 한도가 낮습니다. 기억에 의존하기보다는 현재 모델 개요를 확인하세요. 라우팅 계층은 모델별 max_output_tokens 및 잘림 동작을 처리하여 폴백이 자동으로 잘린 답변을 생성하거나 예상치 못한 청구서로 이어지지 않도록 해야 합니다.

폴백 세트 전반에 걸친 계약 테스트

한 번도 실행해 보지 않은 페일오버 경로는 필요할 때 실패하는 경로입니다. 폴백 체인을 API 계약으로 간주하고 그에 따라 테스트하세요.

효과적인 패턴: Apidog에 하나의 테스트 시나리오를 유지하여, 폴백 체인의 모든 모델에 대해 중요한 프롬프트를 정기적으로 그리고 CI에서 실행합니다. 각 모델에 대해 다음 세 가지를 확인하세요:

스키마. 응답이 파싱되고, 필수 필드가 존재하며, 구조화된 출력이 JSON 스키마에 대해 유효한지 확인합니다. 이는 폴백 모델이 JSON을 다르게 이스케이프하거나 파서가 가정하는 필드를 누락하는 것과 같은 미묘한 오류를 포착합니다.
지연 시간. p95 지연 시간이 해당 모델에 설정된 예산 미만을 유지하는지 확인합니다. 기술적으로 작동하지만 40초가 걸리는 폴백은 다른 종류의 서비스 중단입니다.
품질 신호. 저렴하고 기계적인 확인: 출력이 비어 있지 않고, 올바른 언어로 되어 있으며, 필수 요소가 포함되어 있고, 프롬프트 세트 전반의 거부율이 기준선에 가까운지 확인합니다. CI에서는 유창함을 평가하는 것이 아니라, 작업을 멈춘 모델을 탐지하는 것입니다.

모델 또는 공급자당 하나의 Apidog 환경으로 구성하고, 엔드포인트 URL, API 키, 모델 ID를 환경 변수로 저장하세요. 그런 다음 동일한 시나리오가 환경 전환을 통해 claude-fable-5, claude-opus-4-8, claude-sonnet-4-6에 대해 변경 없이 실행되며, 체인에 네 번째 모델을 추가하는 것은 새로운 테스트를 작성하는 것이 아니라 환경을 추가하는 것을 의미합니다.

프롬프트 세트를 신중하게 선택하세요. 수백 개의 사례가 필요한 것이 아니라, 프로덕션 트래픽을 대표하는 10~20개의 프롬프트가 필요합니다. 가장 긴 컨텍스트를 보내는 경우, 가장 엄격한 구조화된 출력을 파싱하는 경우, 한때 파서를 망가뜨렸던 엣지 케이스, 그리고 거부율 변화가 지원 티켓 대신 테스트 실행에서 나타나도록 도메인의 민감한 경계 근처에 있는 최소 하나의 프롬프트가 포함되어야 합니다. 이 세트를 프롬프트와 함께 버전 관리하고, 프로덕션에서 예상치 못한 상황이 발생하면 해당 사례를 스위트에 추가하세요.

서비스 중단 시 추가적인 이점이 있습니다. 하나의 환경을 기록된 응답을 반환하는 목 서버로 지정하면, 공급자가 다운되어 있는 동안에도 CI가 모델 다운스트림의 모든 것을 계속 검증합니다. Apidog은 테스트에서 이미 사용하는 동일한 API 스펙으로부터 해당 목을 생성할 수 있으므로, 서비스 중단이 릴리스 파이프라인도 막지 않습니다.

6월 12일, 침착한 팀과 혼란에 빠진 팀의 차이는 바로 이것으로 귀결되었습니다. 일부 팀은 Opus 4.8 경로가 주요 프롬프트에 대해 유효한 출력을 생성한다는 야간 증거를 가지고 있었습니다. 다른 팀들은 희망만 가지고 있었습니다.

운영 준비성

아키텍처는 페일오버 기능을 제공하고, 운영은 빠르고 깔끔한 결정을 가능하게 합니다.

기본 모델뿐만 아니라 모든 모델을 프로브하세요. 사용자 트래픽과 별개로 체인 내 각 모델에 대해 예약된 합성 프롬프트를 실행하세요. status.anthropic.com과 같은 공급자 상태 페이지는 유용하지만, 지연이 있고 공급자 전체의 상황을 설명할 뿐, 귀하의 계정, 지역 또는 속도 제한 계층을 나타내지는 않습니다. 당신의 자체 프로브가 먼저 실패를 감지할 것입니다.
5xx 오류뿐만 아니라 거부율 및 오류율에 대해 경고하세요. 모델 수준의 문제는 종종 HTTP 수준 대시보드가 녹색을 유지하는 동안 거부율 증가, 404 model_not_found 오류 급증 또는 429 오류로 나타납니다.
필요하기 전에 전환 런북을 작성하세요. 누가 페일오버를 결정하고, 어떤 설정 값이 변경되며, 지원팀과 고객에게 어떤 공지를 하고, 첫 시간 동안 어떤 대시보드를 주시할지 등을 명시합니다. Fable 5 서비스 중단 동안 런북이 없는 팀은 실행보다 결정에 더 많은 시간을 낭비했습니다.
복구를 단계별로 진행하세요. 기본 모델이 복구될 때, 모든 트래픽을 한 번에 전환하지 마세요. 작은 부분부터 카나리 배포를 하고, 폴백 기준선과 품질 및 거부율 지표를 비교한 다음 점차 늘려나가세요. Fable 5 API로 다시 전환하는 방법에서 이 과정의 메커니즘을 다루며, 이 패턴은 어떤 기본 모델의 복귀에도 적용됩니다.
리허설을 하세요. 분기별로 한 번씩, 스테이징 환경에서 의도적으로 페일오버를 수행하거나, 위험 허용 범위가 허락한다면 작은 트래픽 조각에 대해 프로덕션에서도 수행하세요. 훈련을 통해 폴백 계정의 만료된 API 키, 아무도 찾을 수 없는 대시보드, 6개월 전에 이름이 바뀐 설정 값 등을 발견할 수 있습니다. 이러한 것들은 평온한 화요일에 발견하는 것이 훨씬 저렴합니다.

Fable 5 사태가 특히 가르쳐주는 것

7월 1일 복구에는 정책 수립의 가치가 있는 세부 사항이 있었습니다. Anthropic은 재훈련된 안전 분류기를 포함하여 Fable 5를 재배포했습니다. 동일한 모델 ID, 동일한 API 표면이지만, 오프라인으로 전환되기 전의 모델과 바이트 단위로 동일하지는 않았습니다. 거부 경계가 이동했습니다. 6월 초에 문제없이 통과했던 프롬프트가 7월에는 다르게 처리될 수 있었고, 이전에 발생했던 일부 거부도 더 이상 발생하지 않았습니다.

여기서 도출되는 규칙: 복구 시 재활성화하지 말고 재테스트하세요. 정지, 롤백, 또는 장기간의 서비스 종료 유예 등 어떤 이유로든 복귀하는 모델은 새로운 모델 버전으로 취급해야 합니다. 전체 계약 스위트를 실행하여 테스트하세요. 거부율 및 품질 지표를 폴백 모델의 수치가 아닌 서비스 중단 이전의 기준선과 비교하세요. 점진적으로 늘리기 전에 카나리 배포를 하세요.

두 번째로, 덜 명시적인 교훈이 있습니다. 19일은 폴백 모델이 사실상의 기준선이 되기에 충분히 긴 시간입니다. 사용자들은 Opus 4.8의 동작에 적응했고, 내부 팀은 이에 맞춰 프롬프트를 조정했습니다. 복귀는 단순히 기술적인 이벤트가 아니라 제품 변경이며, 제품을 출시할 때와 동일한 주의를 기울여야 합니다.

자주 묻는 질문

동일 공급자 폴백 체인으로 충분한가요, 아니면 두 번째 공급자가 필요한가요?

동일 공급자부터 시작하세요. 이는 엔지니어링 비용의 일부만으로 서비스 종료, 용량 문제, 안전 롤백, 모델별 정지 등을 처리할 수 있으며, Anthropic의 서버 측 폴백과 같은 기능은 거의 무료로 채택할 수 있게 합니다. 전체 공급자 장애 또는 계정 수준 이벤트로 인해 두 번째 통합을 유지하는 것보다 더 많은 비용이 발생할 경우에만 교차 공급자 경로를 추가하세요. 어떤 경우든 기능 저하 모드를 구축할 가치는 있습니다.

트래픽이 더 작은 모델로 페일오버될 때 사용자들이 알아차릴까요?

작업에 따라 다르므로 추측하는 대신 측정하세요. 추출 및 분류의 경우, 잘 프롬프트된 더 작은 모델은 종종 구별할 수 없습니다. 장문 추론의 경우 차이가 나타납니다. 저희의 Fable 5 대 Opus 4.8 비교와 같은 벤치마크가 시작 지도를 제공합니다. 기능 계층별 프롬프트와 정직한 UI 문구("현재 응답이 더 간결할 수 있습니다")는 인지되는 격차를 더욱 줄여줍니다.

폴백 경로는 얼마나 자주 테스트해야 하나요?

정기적으로 매일 밤, 프롬프트 또는 라우팅 설정 변경 시 CI에서, 그리고 체인에 영향을 미치는 모든 공급자 발표 직후에 테스트해야 합니다. 상위 20개 프롬프트를 세 가지 모델에 대해 실행하는 토큰 비용은 서비스 중단 중에 고장 난 폴백을 발견하는 것에 비하면 아주 적은 비용입니다.

모델 가용성은 더 예측하기 어려워질 것입니다: 더 엄격한 규제, 더 빠른 릴리스 및 서비스 종료 주기, 그리고 출시 때마다 변동하는 용량 때문입니다. 다음 Fable 5와 같은 상황을 헤쳐나갈 팀은 모델을 영구적인 고정물이 아닌, 테스트된 예비 부품을 가진 교체 가능한 구성 요소로 취급한 팀일 것입니다. 이 작업은 설정 파일, 라우팅 래퍼, 그리고 매일 밤 실행되는 계약 스위트에 맞춰집니다. 지금 Apidog을 다운로드하여 폴백 체인을 예약된 테스트에 연결하세요. 다음 서비스 중단은 '언제'의 문제입니다.