"그냥 폴백 모델(fallback model)을 추가하세요"라는 조언은 실제로 서비스를 출시하기 전까지는 완벽하게 들리는 종류의 조언입니다. 단일 백업 모델은 한 가지 장애 모드(기본 모델의 다운)는 처리하지만, 프로덕션 환경에서 나타나는 나머지 네 가지 장애 모드는 조용히 무시합니다: 느린 응답, 잘못된 형식의 출력(malformed output), 속도 제한(rate limits), 그리고 기본 모델과 동일한 컨텍스트 형태(context shape)를 수용하지 못하는 폴백 모델입니다.

다음은 실제로 유효한 패턴 분석입니다.

다섯 가지 패턴, 그리고 각 패턴이 적절한 시점

이 중 어느 것도 다른 것을 대체하지 않습니다. 프로덕션 시스템은 보통 다음과 같은 조합이 필요합니다: 캐시 확인, 모델 상태 확인, 요청 분류, 경로 선택, 출력 검증, 결정 사항 로깅. 검증 단계를 건너뛰면 결국 망가진 응답을 다운스트림 도구 호출(downstream tool call)로 직접 라우팅하게 될 것입니다.

실제로 문제가 되는 부분: 모델 컨텍스트 (model context)

이것은 "폴백 추가" 버전을 이미 출시한 후에야 나타나는 장애 모드입니다. 모델 컨텍스트, 즉 시스템 프롬프트(system prompt), 대화 기록(conversation history), 검색된 문서(retrieved documents), 도구 스키마(tool schemas), 출력 형식 규칙(output format rules)은 모델 간의 전환 시 깔끔하게 유지된다는 보장이 없습니다. 조용히 차이를 만드는 요소들은 다음과 같습니다:

• 컨텍스트 길이 제한 (Context length limits)
• 시스템 프롬프트가 해석되는 방식
• 도구/함수 스키마(Tool/function schema) 기대치
• JSON 형식의 엄격함 (JSON formatting strictness)
• 스트리밍 동작 (Streaming behavior)

OpenAI 스타일과 Anthropic 스타일의 API는 진정으로 다른 요청 형태(request shapes)를 사용합니다 (OpenAI reference, Anthropic Messages API). "OpenAI 호환" 게이트웨이는 요청/응답 형식을 매끄럽게 만들어 줄 뿐, 동일한 입력이 주어졌을 때 폴백 모델이 동일하게 동작한다는 것을 보장하지는 않습니다. 페일오버를 구현하는 데 급급할 때 이 차이점은 간과하기 쉽지만, 매우 중요한 차이입니다.

에이전트의 경우 특히 그렇습니다

단일 사용자 작업은 계획(planning), 도구 선택(tool selection), 요약(summarization) 및 최종 응답을 트리거할 수 있으며, 각각은 별도의 모델 호출입니다. 이 중 어느 하나라도 합리적인 재시도(retry)나 폴백(fallback) 경로 없이 실패하면 전체 작업이 무너질 수 있습니다. 처음부터 구축할 가치가 있는 사항들:

• 지수 백오프(backoff) 및 지터(jitter)를 사용한 재시도 제한 (무제한 재시는 아님)
• 짧은 폴백 체인: 긴 체인은 신뢰성을 높이지 않고 지연 시간만 추가합니다.
• 타임아웃, 5xx, 그리고 429 패턴을 추적하는 건강 검사(health checks)를 구체적으로 수행
• 하위 시스템(downstream)에서 어떤 작업(도구 호출, 데이터베이스 쓰기 등)이 응답에 접근하기 전에 출력 유효성 검사(Output validation)
• 경로별 로깅: 어떤 모델을 사용했는지, 지연 시간, 토큰 사용량, 폴백이 발동되었는지 여부

라우터가 들어갈 위치

AI 게이트웨이나 모델 라우터는 모든 서비스가 자체 버전을 재구현하는 대신 라우팅/재시도/캐시 로직을 중앙 집중화합니다. GonkaRouter가 한 예시로, Gonka 분산 컴퓨팅 네트워크를 기반으로 MiniMax-M2.7, Kimi-K2.6, GLM-5.2에 현재 라우팅되는 OpenAI 및 Anthropic과 호환 가능한 엔드포인트입니다. 여기서 정확할 필요가 있습니다: '호환 가능(compatible)'하다는 것은 요청/응답 _형식(format)_이 일치한다는 의미이지, 모든 모델이 OpenAI나 Anthropic에서 직접 얻을 수 있는 것과 동일하게 동작한다는 의미가 아닙니다. 그 차이는 바로 위에서 언급한 모델-컨텍스트 문제이며, 어떤 게이트웨이도 이 문제를 스스로 사라지게 만들 수는 없습니다.

만약 이런 것을 평가하고 있다면, 실제 테스트는 다음과 같습니다: 기존 통합의 엔드포인트만 변경하고, 각 지원되는 모델을 통해 실제 프롬프트를 실행하여 앱 레벨의 재시도 및 폴백 로직이 어디에 위치해야 할지 결정하기 전에 지연 시간, 출력 품질, 실패 동작을 측정하는 것입니다.

페일오버 배포 전 빠른 체크리스트

• 단순히 "요청 실패"가 아니라, 타임아웃(timeout), 5xx, 429, 그리고 유효하지 않은 JSON(invalid JSON)에 대한 정의된 동작(Defined behavior)이 있는가
• 무제한 재시도가 아닌, 백오프(backoff)를 포함한 재시도 제한(Retry limits)이 설정되어 있는가
• 폴백 체인(Fallback chains)이 짧게 유지되는가
• 모델 간의 컨텍스트 변환(Context transformation)이 가정되지 않고 명시적으로 처리되는가
• 단순히 "모든 것을 캐싱"하는 것이 아니라, 실제 무효화 규칙(invalidation rules)과 함께 범위가 지정된 캐싱(Caching)을 사용하는가
• 모든 경로(route)가 기록되는가: 모델, 지연 시간(latency), 토큰, 폴백 발생 여부
• 출력이 도구 호출(tool call)이나 다운스트림 쓰기(downstream write)에 도달하기 전에 검증되는가

특히 컨텍스트 변환(context-transformation) 단계에서 다른 분들은 무엇을 사용하고 있는지 궁금합니다. 폴백 모델이 기본 모델과 다르게 시스템 프롬프트(system prompts)를 조용히 다르게 처리할 때, 이 부분이 사람들에게 가장 큰 타격을 주는 것을 보았습니다.