AI 모델 페일오버(Failover) 훈련: 제공업체 장애 시에도 에이전트의 유용성을 유지하는 방법

다이어그램 상에서만 작동하는 모델 폴백(fallback)은 회복 탄력성(resilience)이 아닙니다. 그것은 그저 이름만 그럴싸하게 붙인 '할 일 목록(TODO)'일 뿐입니다.

만약 당신의 제품이 AI 에이전트(AI agents)에 의존하고 있다면, 단 하나의 느린 제공업체, 속도 제한(rate-limit) 급증, 지역적 제한, 잘못된 형식의 응답(malformed response), 또는 모델 동작의 변화만으로도 유용한 워크플로(workflow)가 혼란스러운 사용자 경험으로 변할 수 있습니다. 위험한 부분은 항상 깔끔한 서비스 중단(outage)인 것만은 아닙니다. 진짜 위험한 부분은 스키마(schema)를 조용히 변경하거나, 도구 상태(tool state)를 누락시키거나, 인용(citation)을 건너뛰거나, 사용자에게 알리지 않고 신뢰도가 낮은 출력을 제공하는 등 '절반만 작동하는 폴백(fallback)'입니다.

이 가이드는 실제 운영 트래픽이 당신에게 혹독한 교훈을 가르쳐주기 전에, 실질적인 AI 모델 페일오버(failover) 훈련을 수행하는 방법을 보여줍니다.

목표는 모든 모델을 서로 교체 가능하게 만드는 것이 아닙니다. 목표는 기본 모델이 제 역할을 수행할 수 없을 때 사용자 워크플로(workflow)를 안전하고, 정직하며, 복구 가능한 상태로 유지하는 것입니다.

모델 페일오버에 단순 재시도(retries)가 아닌 훈련이 필요한 이유

대부분의 팀은 단순한 폴백 체인(fallback chain)으로 시작합니다: 기본 모델을 시도하고, 그다음 백업 모델을 시도한 뒤, 에러를 표시하는 방식입니다. 이는 아무것도 하지 않는 것보다는 낫지만, AI 애플리케이션의 실제 문제점들을 놓치고 있습니다.

전통적인 API는 보통 타임아웃(timeout), 500 에러, 잘못된 인증 정보(bad credentials), 할당량 초과(quota exceeded)와 같이 명확한 방식으로 실패합니다. 하지만 AI 시스템은 훨씬 더 미묘하게 실패할 수 있습니다:

• 백업 모델이 필드 의미가 다른 유효한 JSON을 반환함.
• 더 저렴한 모델이 도구 정책(tool policy)의 일부를 무시함.
• 제공업체가 요청은 수락하지만 토큰(tokens)을 너무 느리게 스트리밍함.
• 폴백(fallback) 모델이 동일한 함수 호출(function-calling) 형식을 지원하지 않음.
• 지역 정책이나 액세스 규칙이 가용성(availability)을 변경함.
• 모델이 답변을 완성하지만 인용 규율(citation discipline)을 잃어버림.
• 에이전트가 재시도(retry)를 반복하며 테넌트 예산(tenant budget)을 소진함.
• 최종 응답은 깔끔해 보이지만 비용이 많이 드는 검증(verification) 단계를 건너뜀.

최근 AI 인프라에 관한 논의들은 모두 같은 방향을 가리키고 있습니다. 이제는 모델 자체만큼이나 모델을 둘러싼 시스템이 중요해졌다는 것입니다. 에이전트 벤치마크(Agent benchmarks), 제공업체 신뢰성(provider reliability), AI 비용 압박, 그리고 모델 라우팅(model routing)은 모두 개발자들이 활발하게 고민하는 주제입니다. 검색 결과에서도 LLM 폴백(fallback) 전략에 관한 광범위한 게시물은 많이 보이지만, 운영 드릴(operational drill)로서 페일오버(failover)를 연습하는 방법에 대한 실질적인 가이드는 드뭅니다.

AI 모델 페일오버 드릴의 실질적인 정의

AI 모델 페일오버 드릴(failover drill)이란 모델 경로의 한 부분을 의도적으로 중단시키거나 성능을 저하시킨 뒤, 제품이 여전히 안전하게 작동하는지 확인하는 계획된 테스트입니다.

훌륭한 드릴은 워크플로(workflow)가 계속 실행되는지, 스키마(schema)와 도구 상태(tool state)를 보존하는지, 정직하게 성능을 저하시키는지(degrades honestly), 비용 및 지연 시간(latency) 예산 내에 머무는지, 그리고 다음을 위한 회귀 테스트(regression test)를 생성하는지를 점검합니다.

이는 대규모 팀만을 위한 것이 아닙니다. 1인 개발자도 몇 가지 골든 태스크(golden tasks), 가짜 제공업체 어댑터(fake provider adapter), 그리고 구조화된 로그(structured logs)를 활용하여 유용한 드릴을 실행할 수 있습니다.

페일오버가 우선적으로 필요한 워크플로 선정하기

모든 프롬프트를 멀티 제공업체(multi-provider)로 만드는 것부터 시작하지 마세요. 실패가 신뢰를 해치는 워크플로부터 시작하십시오.

우선순위가 높은 후보군:

• 고객 대면 채팅 답변
• 보고서 생성
• 도구를 호출하는 에이전트 워크플로(Agent workflows)
• 인용(citations)이 포함된 RAG 답변
• 구조화된 필드로의 데이터 추출
• 외부 시스템에 기록하는 워크플로 자동화
• 결제, 컴플라이언스(compliance), 보안 또는 정책 지원 작업
• 유료 사용 제한 또는 넌트 예산(tenant budget)이 있는 모든 기능

우선순위가 낮은 후보군에는 내부 초안, 있으면 좋은 요약, 비차단형(non-blocking) 제안, 그리고 명확한 재시도 메시지가 허용되는 기능들이 포함됩니다.

유용한 규칙:

만약 잘못된 답변이 답변이 없는 것보다 더 나쁘다면, 페일오버에는 단순히 다른 모델을 호출하는 것뿐만 아니라 품질 게이트(quality gates)가 포함되어야 합니다.

백업 모델을 선택하기 전에 폴백 계약(fallback contract) 구축하기

최악의 폴백 설계는 모델 이름부터 정하는 것입니다. 더 나은 설계는 계약(contract)에서 시작합니다.

폴백 계약은 제공업체와 모델이 바뀌더라도 반드시 유지되어야 하는 사항들을 정의합니다.

지원 답변 에이전트(support-answer agent)의 경우, 계약(contract)에는 답변, 신뢰 수준(confidence level), 인용(citations), 누락된 정보, 전송 가능 플래그(safe-to-send flag), 테넌트 ID(tenant ID), 정책 버전(policy version), 소스 ID(source IDs), 도구 권한(tool permissions), 그리고 남은 예산(remaining budget) 등이 포함될 수 있습니다.

이 계약은 모델 목록보다 더 중요합니다. 이는 페일오버(failover) 과정에서 무엇을 잃어서는 안 되는지를 시스템에 알려줍니다.

AI 빌더들에게 핵심적인 계약 필드는 보통 다음과 같습니다:

• 입력 형태 (Input shape): 프롬프트(prompt), 메시지(messages), 컨텍스트 패킷(context packet), 도구 스키마(tool schemas), 메모리 슬라이스(memory slices)
• 출력 형태 (Output shape): JSON 스키마(JSON schema), 인용(citations), 신뢰도(confidence), 실행 계획(action plan), 최종 답변(final answer)
• 상태 (State): 워크플로우 단계(workflow step), 이전 도구 결과(previous tool results), 재시도 횟수(retry count), 사용된 예산(budget used)
• 권한 (Permissions): 테넌트 경계(tenant boundary), 도구 범위(tool scope), 승인 요구 사항(approval requirements)
• 품질 게이트 (Quality gates): 검증(validation), 증거 확인(evidence checks), 정책 확인(policy checks), 판정 루브릭(judge rubrics)
• 사용자 경험 (User experience): 재시도(retry), 저하 모드(degraded mode), 검토를 위한 대기열(queue for review), 또는 정직한 실패(honest failure)

재시도 로직을 작성하기 전에 실패 모드(failure modes)를 분류하세요

모든 실패가 동일한 폴백(fallback)을 트리거해야 하는 것은 아닙니다.

간단한 실패 분류 체계(failure taxonomy)를 만드세요:

실패 모드 (Failure mode)	예시 (Example)	최적의 대응 (Best response)
타임아웃 (Timeout)	제공업체가 너무 느림	한 번 재시도 후, 지연 시간이 낮은 모델로 라우팅
...

이는 흔히 발생하는 실수, 즉 모든 실패를 동일한 페이로드(payload)로 다른 모델을 시도해야 하는 이유로 취급하는 것을 방지합니다.

때로는 올바른 폴백이 다른 모델이 아닐 수도 있습니다. 다음과 같을 수 있습니다:

• 사용자에게 확인 요청
• 부분적인 결과 반환
• 작업을 나중에 처리하도록 대기열에 추가
• 위험한 동작 비활성화
• 규칙 기반(rules-based) 응답 사용
• 더 작은 추출 전용(extraction-only) 단계 실행
• 워크플로우를 사람의 검토(human review)로 전달

페이로드 어댑터(payload adapters)를 명시적으로 만드세요

모델과 제공업체마다 지원하는 메시지 형식, 도구 스키마, JSON 모드, 컨텍스트 창(context windows), 이미지 입력, 그리고 스트리밍 동작이 다릅니다.

만약 폴백 계층이 단순히 동일한 페이로드를 전달하기만 한다면, 이상한 방식으로 실패할 수 있습니다.

모델 어댑터 인터페이스(model adapter interface)를 생성하세요:

type ModelRequest = {
  taskId: string;
  tenantId: string;
...

그런 다음 제공업체별 세부 사항을 어댑터 뒤에 배치하세요:

• 도구 스키마 (tool schemas) 변환
• 최대 컨텍스트 크기 (max context size) 강제 적용
• 종료 사유 (finish reasons) 정규화
• 토큰 사용량 (token usage) 정규화
• JSON 검증
• 제공업체 오류를 자체 장애 분류 체계 (failure taxonomy)로 변환
• 모델 및 제공업체 메타데이터 첨부

이를 통해 애플리케이션 로직을 다시 작성하지 않고도 어댑터 수준의 장애를 시뮬레이션할 수 있으므로 훈련 (drills)이 더 쉬워집니다.

훈련 1: 기본 제공업체 타임아웃 (Primary provider timeout)

가장 쉬운 훈련부터 시작합니다: 기본 모델이 전혀 응답하지 않는 경우입니다.

테스트 설정:

• 기본 어댑터가 타임아웃(timeout) 이상으로 대기(sleep)하도록 강제하는 플래그를 추가합니다.
• 에이전트를 통해 10개의 골든 태스크 (golden tasks)를 실행합니다.
• 폴백 (fallback)이 사용자 체감 지연 시간 예산 (latency budget) 내에 발생하는지 확인합니다.

예상 동작:

• 시스템은 최대 한 번만 재시도합니다.
• 폴백 모델이 정제되고 변환된 페이로드 (payload)를 전달받습니다.
• 워크플로우에 페일오버 (failover) 사유가 로그로 남습니다.
• 사용자가 무한정 기다리지 않습니다.
• 출력 스키마 (output schema)가 여전히 유효합니다.

이미 장애가 발생 중인 제공업체에 앱이 계속해서 요청을 퍼붓지 않도록 서킷 브레이커 (circuit breaker)를 추가하세요.

훈련 2: 속도 제한 급증 (Rate-limit spike)

속도 제한 (Rate limits)은 드문 예외 상황이 아닙니다. 서비스 출시, 크론 작업 (cron bursts), 테넌트 급증, 재시도 및 제공업체 장애 상황에서 빈번하게 발생합니다.

테스트 설정:

• 기본 어댑터가 정규화된 rate_limited 결과를 반환하도록 강제합니다.
• 여러 테넌트로부터 동시 요청을 실행합니다.
• 하나의 노이즈가 심한 테넌트가 다른 모든 사용자의 폴백 용량을 소진하지 않는지 확인합니다.

예상 동작:

• 테넌트별 예산 (budgets)이 여전히 적용됩니다.
• 백오프 (Backoff)에 지터 (jitter)가 적용됩니다.
• 폴백 용량이 우선순위가 높은 워크플로우를 위해 예약됩니다.
• 낮은 우선순위의 작업은 대기열에 추가되거나 성능이 저하 (degraded)됩니다.
• 시스템이 좁은 루프 (tight loop) 내에서 재시도하지 않습니다.

작은 큐 정책 (queue policy)만으로도 큰 효과를 볼 수 있습니다: 높은 우선순위 요청은 즉시 페일오버되고, 일반 요청은 잠시 대기하며, 낮은 우선순위 요청은 성능이 저하되거나 건너뜁니다. 이는 비용과 사용자 신뢰를 모두 보호합니다.

훈련 3: 폴백 중 스키마 드리프트 (Schema drift during fallback)

이것은 제품을 조용히 망가뜨리는 장애 유형입니다.

기본 모델은 summary, risk, next_action을 반환할 수 있습니다. 반면 폴백 (fallback) 모델은 message와 priority를 반환할 수 있습니다. 두 결과 모두 인간이 보기에는 합리적으로 보일 수 있습니다. 하지만 다운스트림 (downstream) 자동화에 안전한 것은 단 하나뿐입니다.

테스트 설정:

• 서로 다른 포맷팅 동작을 가진 모델로 폴백 (fallback)을 강제합니다.
• 추출 (extraction) 및 액션 플래닝 (action-planning) 작업을 실행합니다.
• 엄격한 스키마 (schema)를 기준으로 출력을 검증합니다.

예상 동작:

• 유효하지 않은 스키마는 한 번의 복구 시도를 트리거합니다.
• 복구 시에는 환각 (hallucination)에 취약한 새로운 프롬프트가 아닌, 동일한 증거 (evidence)를 사용합니다.
• 복구에 실패하면 워크플로 (workflow)가 중단되거나 검토 단계로 넘어갑니다.
• 유효하지 않거나 모호한 출력으로부터는 어떠한 쓰기 작업 (write action)도 실행되지 않습니다.

Zod, Pydantic 또는 JSON Schema와 같은 스키마 라이브러리를 사용하여 엄격한 검증을 수행하세요.

훈련 4: 도구 호출 (Tool-call) 불일치

에이전트 워크플로 (agent workflows)는 종종 도구 호출 (tool calling)에 의존합니다. 백업 모델이 동일한 도구 형식을 사용할 수 없거나 도구 선택 능력이 떨어지는 경우, 폴백 (fallback)은 더 어려워집니다.

폴백 (fallback) 모델이 도구 사용을 임의로 수행하게 두지 마세요.

도구 모드 정의:

모드	모델이 할 수 있는 일	사용 시점
전체 도구 모드 (Full tool mode)	모델이 승인된 도구를 호출할 수 있음	기본 경로 또는 역량 있는 폴백 (fallback)
...

테스트 설정:

• 폴백 (fallback) 어댑터에서 도구 지원을 비활성화합니다.
• 일반적으로 도구 호출이 필요한 워크플로 (workflows)를 실행합니다.
• 에이전트가 계획 전용 (plan-only) 또는 읽기 전용 (read-only) 모드로 전환되는지 확인합니다.

예상 동작:

• 폴백 (fallback) 모델은 쓰기 작업 (write actions)을 직접 트리거할 수 없습니다.
• 도구 의도 (tool intent)는 데이터로 표현됩니다.
• 고위험 작업은 승인을 필요로 합니다.
• 최종 답변은 누락된 작업이 있다면 이를 명확하게 반영합니다.

계획 전용 (plan-only) 객체에는 제안된 도구, 이유, 필요한 승인 및 증거 ID (evidence IDs)가 포함될 수 있습니다. 이를 통해 성능이 저하된 모델이 동일한 역량을 가진 것처럼 가장하지 않으면서도 워크플로 (workflow)의 유용성을 유지할 수 있습니다.

훈련 5: 완전한 장애 없는 품질 저하

가장 까다로운 사고는 서비스 중단이 아닙니다. 바로 품질 저하입니다.

제공업체 (provider)는 응답합니다. 지연 시간 (latency)도 괜찮습니다. JSON도 검증을 통과합니다. 하지만 답변이 더 약하거나, 근거가 부족하거나, 유용성이 떨어집니다.

이를 위해 골든 태스크 (golden tasks)가 필요합니다.

골든 태스크 (golden task)에는 입력 프롬프트 (input prompt), 필수 소스 (required sources) 또는 픽스처 (fixtures), 기대되는 출력 속성 (expected output properties), 금지된 동작 (forbidden behaviors), 인용 규칙 (citation rules), 비용 제한 (cost limits), 지연 시간 제한 (latency limits), 그리고 성능 저하 모드 (degraded mode) 허용 여부가 포함되어야 합니다.

예시:

{
  "name": "refund_policy_edge_case",
  "input": "Can this customer get a refund after 31 days?",
...

이러한 태스크들을 기본 경로 (primary path)와 폴백 경로 (fallback path) 모두에서 실행하십시오. 최종 답변뿐만 아니라 트레이스 (trace) 전체에 점수를 매겨야 합니다.

체크리스트:

• 올바른 소스를 검색했는가?
• 테넌트 경계 (tenant boundaries)를 유지했는가?
• 올바른 도구 모드 (tool mode)를 호출했는가?
• 예산 범위 내에 머물렀는가?
• 근거를 인용했는가?
• 지원되지 않는 주장 (unsupported claims)을 피했는가?

만약 폴백 (fallback)이 이러한 체크 항목들을 정기적으로 통과하지 못한다면, 이는 조용히 이루어지는 폴백 (silent fallback)이 되어서는 안 됩니다. 이는 성능 저하 모드 (degraded mode), 검토 경로 (review path), 또는 사용자에게 보이는 재시도 (user-visible retry)가 되어야 합니다.

우아한 성능 저하 (graceful degradation) 메시지 설계

사용자는 모든 제공업체의 세부 사항을 알 필요는 없습니다. 하지만 제품의 정직한 동작은 알아야 합니다.

나쁜 메시지:

문제가 발생했습니다.

또한 나쁜 메시지:

우리의 기본 LLM 제공업체가 429 에러를 반환하여, 도구 지원이 없는 하위 티어 모델로 시도했습니다.

더 나은 메시지:

여전히 도움을 드릴 수 있지만, 실시간 작업은 일시적으로 제한됩니다. 다음 단계를 검토용으로 초안을 작성해 드릴 수 있으며, 또는 몇 분 후에 전체 워크플로 (workflow)를 다시 시도하실 수 있습니다.

좋은 성능 저하 UX (degraded UX)는 사용자에게 무엇이 여전히 작동하는지, 무엇이 일시적으로 제한되는지, 조치가 필요한지, 데이터가 저장되었는지, 그리고 다음에 어떤 일이 일어나는지를 알려줍니다.

AI 도구의 경우, 신뢰는 모든 것이 괜찮은 척하는 것이 아니라 명확한 경계를 설정하는 데서 오는 경우가 많습니다.

폴백 (failover) 중에 로그에 남겨야 할 것

로그 없는 폴백 (failover)은 단순히 단계를 더 추가한 추측에 불과합니다.

사고를 안전하게 재현 (replay)할 수 있을 만큼 충분히 로그를 남기십시오: 태스크 ID (task ID), 테넌트 해시 (tenant hash), 워크플로 단계 (workflow step), 기본 모델 (primary model), 실패 모드 (failure mode), 폴백 모델 (fallback model), 도구 모드 (tool mode), 스키마 상태 (schema status), 품질 게이트 (quality gate), 지연 시간 (latency), 비용 (cost), 성능 저하 모드 상태 (degraded-mode status), 그리고 트레이스 ID (trace ID).

민감한 원문 프롬프트 (raw prompts)를 영구적으로 저장하는 것은 피하십시오. 가능한 경우 해시 (hashes), 비식별화된 페이로드 (redacted payloads), 소스 ID (source IDs), 모델 메타데이터 (model metadata), 스키마 버전 (schema versions), 그리고 재현용 픽스처 (replay fixtures)를 사용하는 것을 권장합니다.

모든 페일오버(failover) 사고를 회귀 테스트(regression test)로 전환하세요

실제 또는 시뮬레이션된 사고가 발생한 후, 다음 질문을 던져보세요:

• 무엇이 가장 먼저 실패했는가?
• 서킷 브레이커(circuit breaker)가 충분히 빠르게 작동했는가?
• 폴백(fallback)이 스키마(schema)와 상태(state)를 보존했는가?
• 사용자가 유용한 메시지를 확인했는가?
• 예산(budgets)이 유지되었는가?
• 실행되지 말아야 할 시점에 도구 액션(tool action)이 실행되었는가?
• 다음 주에 픽스처(fixture)를 사용하여 이를 재현(replay)할 수 있는가?

그 다음 회귀 케이스(regression case)를 추가하세요.

가벼운 파일 구조 예시:

evals/
  failover/
    timeout_primary.json
...

CI(지속적 통합)가 모든 풀 리퀘스트(pull request)마다 실제 제공업체(live providers)를 호출할 필요는 없습니다. 빠른 점검을 위해 어댑터(adapters)를 모킹(mock)할 수 있으며, 실제 드릴(live drills)은 정해진 일정에 따라 실행할 수 있습니다.

소규모 팀을 위한 구현 계획

만약 당신이 1인 개발자이거나 소규모 팀이라면, 다음과 같이 단계별로 진행하세요: