모델이 갑자기 사라져도 AI 앱이 살아남게 만드는 방법

AI 위에 무언가를 만드는 모든 개발자는 결국 같은 교훈을 어렵게 배웁니다: 당신이 의존하는 모델이 거기 있으리라는 보장은 없다는 것입니다. 피크 트래픽에서 속도 제한이 걸리거나, 거부 응답을 반환하거나, 과부하 오류에 부딪히거나 — 2026년 6월 Claude Fable 5에 일어난 것처럼 — 당신의 코드와는 전혀 무관한 이유로 완전히 꺼질 수 있습니다. 이런 순간에 살아남는 앱은 최고의 프롬프트를 가진 앱이 아닙니다. 모델이 사라지는 상황을 미리 대비한 앱입니다.

이 가이드는 한 제공자를 직접 호출하든 게이트웨이를 통해 라우팅하든 통하는, 실용적이고 계층적인 복원력 접근법을 안내합니다.

1단계: 절대 단일 모델을 하드코딩하지 마세요

가장 흔한 취약점은 모델 이름을 요청에 직접 박아 넣는 것입니다. 그 문자열이 작동을 멈추는 순간 모든 호출이 실패합니다. 대신 모델을 상수가 아닌 설정 — 작은 우선순위 목록 — 으로 정의하세요:

MODEL_CHAIN = [
    "claude-opus-4-8",      # primary
    "claude-sonnet-4-6",    # same provider, cheaper/faster
    "gpt-5.5",              # different provider entirely
]

이 한 가지 변경은 장애 중에 제공자를 전환하는 것이 코드 배포가 아니라 설정 수정이 되게 합니다. 세 번째 항목이 다른 벤더라는 점에 주목하세요. 동일 제공자 폴백은 단일 모델 다운으로부터 보호하고, 교차 제공자 폴백은 제공자 전체가 다운되거나 — 또는 오프라인 명령을 받는 것 — 으로부터 보호합니다.

2단계: 단일 시도가 아니라 폴백 체인을 사용하세요

패턴은 단순합니다: 각 모델을 순서대로 시도하고, 실패 시 다음으로 넘어가며, 체인 전체가 소진되었을 때만 오류를 드러냅니다.

def call_with_fallback(messages):
    last_error = None
    for model in MODEL_CHAIN:
        try:
            return client.complete(model=model, messages=messages)
        except (RateLimitError, OverloadError, RefusalError) as e:
            last_error = e
            continue  # try the next model
    raise AllModelsFailedError(last_error)

무엇에 대해 폴백하느냐가 중요합니다. 일시적인 overloaded(HTTP 529) 오류에서 짧은 백오프 후 같은 모델을 재시도하는 것은 합리적입니다. 하지만 인증 오류나 잘못된 형식의 요청은 모든 모델에서 동일하게 실패합니다 — 그런 것들은 체인 전체를 태우는 대신 즉시 드러나야 합니다.

3단계: 플랫폼이 폴백을 기본 제공하면 그것에 기대세요

항상 직접 구현해야 하는 것은 아닙니다. 여러 플랫폼이 이제 이를 서버 측에서 처리합니다:

• Anthropic의 API는 거부된 요청을 단일 왕복으로 대체 모델에서 재시도하는 베타 fallbacks 파라미터를 추가했습니다 — 예를 들어 Fable 5는 분류기가 요청을 거절할 때 Opus 4.8로 폴백하도록 설정되어 있었습니다. 과금은 실제로 응답을 제공한 모델을 따릅니다.
• OpenRouter는 우선순위 순서로 models 배열을 전달하게 해주며, 컨텍스트 길이 오류, 모더레이션 플래그, 속도 제한, 다운타임 시 자동으로 장애 조치하고 응답한 모델의 요율로 과금합니다.
• LiteLLM은 배포와 벤더 전반에 걸쳐 재시도, 폴백, 부하 분산이 내장된 Router를 제공하며, 최대한의 제어를 위해 직접 셀프 호스팅합니다.

OpenRouter나 LiteLLM 같은 게이트웨이는 여러 제공자에 걸쳐 하나의 통합 엔드포인트를 제공하므로, 교차 제공자 폴백은 통합할 두 번째 SDK가 아니라 목록의 또 다른 항목일 뿐입니다.

4단계: 빠르게 실패하도록 서킷 브레이커를 추가하세요

모델이 명백히 다운되었다면, 모든 요청이 타임아웃되어 떨어질 때까지 기다리길 원치 않을 것입니다. 서킷 브레이커는 최근 실패를 추적하고, 임계값을 넘으면 쿨다운 기간 동안 망가진 모델을 완전히 건너뜁니다. 2026년 프로덕션 팀들은 흔히 연속 5회 실패 시 브레이커를 작동시키고, 복구를 테스트하기 전 약 60초 쿨다운으로 정착합니다. 브레이커가 열려 있는 동안 트래픽은 체인의 다음 모델로 곧장 갑니다 — 낭비되는 지연 시간이 없습니다.

5단계: 제품에서 "성능 저하"가 무엇을 의미하는지 결정하세요

더 저렴한 모델로 폴백하는 것은 공짜가 아닙니다 — 품질이 떨어지고, 프롬프트가 다르게 동작할 수 있습니다. 이를 계획하세요:

• 체인의 모든 모델에 대해 프롬프트를 테스트하세요. 한 모델에 맞춰 조정된 프롬프트는 폴백에서 눈에 띄게 나쁜 출력을 낼 수 있습니다.
• 성능이 저하되었을 때 사용자에게 알리세요 (예: "빠른 모드로 실행 중") — 그것이 중요하다면, 더 낮은 품질의 결과를 조용히 내보내는 대신 말입니다.
• 각 요청을 실제로 어떤 모델이 처리했는지 로깅하세요 — 장애 후에 폴백이 얼마나 많은 트래픽을 흡수했는지 볼 수 있도록요.

핵심 정리

복원력은 출시 후에 덧붙이는 기능이 아닙니다 — 일찍 추가하는 약간의 구조입니다: 상수 대신 설정, 단일 호출 대신 우선순위 체인, 빠르게 실패하기 위한 서킷 브레이커, 그리고 모든 단계에서 테스트된 프롬프트. 6월 Fable 5 차단 중에도 앱이 유지된 팀들은 운이 좋았던 것이 아닙니다. 그들은 모든 AI 빌더가 첫날에 던져야 할 질문에 이미 답해 두었을 뿐입니다: 이 모델이 내일 없다면 무슨 일이 일어나는가?