요청에 대해 첫 번째 AI 모델을 선택하는 것은 프로덕션 모델 관리의 일부일 뿐입니다.

더 어려운 질문은 해당 모델이 느려지거나, 사용할 수 없거나, 너무 비싸거나, 잘못된 출력을 반환하거나, 워크플로우에 대해 더 이상 성능을 제대로 발휘하지 못할 때 어떤 일이 발생하는가 하는 점입니다.

그 지점에서 폴백(Fallback) 규칙이 중요해집니다.

AI 애플리케이션이 단일 모델 통합을 넘어 확장됨에 따라, 팀들은 챗봇, RAG 시스템, 에이전트(Agents), 코딩 도구, 문서 분석 및 자동화 워크플로우 전반에서 GPT, Claude, Gemini, DeepSeek, Qwen, Kimi, GLM, MiniMax, Doubao 및 기타 모델들을 사용할 수 있습니다.

이러한 환경에서 폴백은 단순한 에러 처리 기능이 아닙니다.

그것은 AI 인프라 계층의 일부가 됩니다.

AI 모델 폴백 규칙이란 무엇인가?

AI 모델 폴백 규칙은 선호하는 모델이 요청을 성공적으로 완료할 수 없을 때 어떤 일이 일어나야 하는지를 정의합니다.

예를 들어:

• 동일한 모델로 한 번 더 재시도(Retry)
• 유사한 능력을 가진 다른 모델로 전환
• 우선순위가 낮은 작업을 위해 더 저렴한 모델로 전환
• 지연 시간(Latency)이 중요할 때 더 빠른 모델로 전환
• 단순화된 답변 반환
• 나중에 처리하기 위해 요청을 대기열(Queue)에 추가
• 작업을 사람의 검토(Human review)로 전달

핵심 포인트는 폴백이 무작위로 이루어져서는 안 된다는 것입니다.

폴백은 워크플로우, 사용자 경험, 비용 제한 및 품질 요구 사항을 중심으로 설계되어야 합니다.

모든 실패가 서비스 중단은 아니다

많은 팀이 모델 제공업체가 다운되었을 때만 폴백이 중요하다고 생각합니다.

실제 애플리케이션에서 실패는 그보다 더 광범위합니다.

모델 요청이 기술적으로는 응답을 반환할 수 있지만, 제품 경험은 여전히 저하될 수 있습니다.

일반적인 실패 신호는 다음과 같습니다:

• API 타임아웃 (Timeout)
• 속도 제한 (Rate limit) 에러
• 제공업체 측 에러 (Provider-side errors)
• 유효하지 않은 JSON 출력
• 비어 있거나 불완전한 응답
• 워크플로우 제한을 초과하는 지연 시간 (Latency)
• 컨텍스트 길이 초과 (Context length overflow)
• 예상치 못한 비용 증가
• 모델 업데이트 후의 품질 저하 (Quality regression)

챗봇의 경우, 느린 응답이 가장 큰 문제일 수 있습니다.

RAG 시스템의 경우, 검색된 컨텍스트를 무시하는 답변이 더 큰 문제일 수 있습니다.

자동화 워크플로우(automation workflow)의 경우, 잘못된 구조화된 출력(structured output)은 출력이 아예 없는 것보다 더 나쁠 수 있습니다.

워크플로우 기반의 폴백(Fallback)부터 시작하기

좋은 폴백 전략은 워크플로우를 분리하는 것에서 시작됩니다.

서로 다른 워크플로우가 항상 동일한 폴백 모델을 사용할 필요는 없습니다.

워크플로우	주요 관심사	폴백 목표
고객 지원 챗봇	지연 시간(Latency) 및 유용성	빠르고 안전한 답변 반환
...

이것이 바로 폴백이 백엔드 에러 처리(backend error handling)뿐만 아니라 제품 설계(product design)와 연결되어야 하는 이유입니다.

트리거 조건(Trigger conditions) 정의하기

폴백 규칙에는 명확한 트리거 조건이 필요합니다.

예시는 다음과 같습니다:

• 요청이 20초 후에 타임아웃(timeout)되는 경우
• 모델이 잘못된 JSON을 두 번 반환하는 경우
• 제공업체(provider)가 속도 제한(rate limit) 에러를 반환하는 경우
• 예상 요청 비용이 워크플로우 예산을 초과하는 경우
• 컨텍스트(context)가 선택된 모델에 비해 너무 큰 경우
• 내부 모니터링에서 모델의 성능 저하(degraded)가 감지된 경우

명확한 트리거가 없으면 폴백 동작을 디버깅하기 어려워집니다.

팀은 특정 요청이 선호되는 모델을 사용했는지, 백업 모델을 사용했는지, 아니면 여러 번의 재시도(retries)를 거쳤는지 알 수 없게 될 수 있습니다.

맹목적인 모델 전환 피하기

폴백은 단순히 하나의 모델에서 다른 모델로 전환하는 것이 아닙니다.

만약 작업에 엄격한 JSON 출력이 필요하다면, 구조화된 포맷팅(structured formatting) 능력이 더 약한 모델로 전환하는 것은 더 많은 실패를 초래할 수 있습니다.

만약 작업에 중국어 문서 이해가 필요하다면, 강력한 중국어 프런티어 모델(frontier model)에서 영어 우선의 범용 모델로 전환하는 것은 품질을 저하시킬 수 있습니다.

만약 작업에 낮은 비용이 필요하다면, 더 큰 프런티어 모델로 전환하는 것은 요청은 해결할 수 있으나 예산을 초과할 수 있습니다.

유용한 폴백 규칙은 다음 사항들을 고려해야 합니다:

• 모델 능력 (model capability)
• 언어 성능 (language performance)
• 컨텍스트 길이 (context length)
• 지연 시간 (latency)
• 비용 (cost)
• 구조화된 출력 신뢰성 (structured output reliability)
• 워크플로우 우선순위 (workflow priority)

다양한 폴백 경로 사용하기

하나의 폴백 경로만으로는 대개 충분하지 않습니다.

프로덕션 시스템에는 여러 가지 유형의 폴백이 필요할 수 있습니다:

• 재시도 폴백 (Retry fallback): 일시적인 네트워크 또는 제공업체(provider) 오류 발생 시 동일한 모델로 한 번 더 재시도합니다.
• 동등 모델 폴백 (Equivalent model fallback): 첫 번째 모델을 사용할 수 없을 때 유사한 모델로 전환합니다.
• 저비용 모델 폴백 (Cheaper model fallback): 중요도가 낮은 작업에는 비용이 더 적게 드는 모델을 사용합니다.
• 고성능 모델 폴백 (Stronger model fallback): 더 강력한 모델로 격상(escalate)합니다.