AI 서비스가 중단될 때: 멀티 모델 폴백(Fallback) 시스템 구축하기

제 주말 프로젝트가 악몽으로 변했던 바로 그 순간을 기억합니다. 저는 특정 개발자 커뮤니티를 위한 챗봇을 만들고 있었고, OpenAI의 GPT-4를 사용하여 모든 것이 순조롭게 운영되고 있었습니다. 그러던 중, 예고도 없이 API가 503 에러를 반환하기 시작했습니다. 제 앱은 침묵에 빠졌고, 사용자들은 제 편지함으로 몰려들었습니다. 그리고 저에게는 백업 계획이 없었습니다.

그날 오후, 저는 혹독한 교훈을 얻었습니다: 단일 AI 제공업체에 의존하는 것은 단일 장애점(Single Point of Failure)이 된다는 것입니다.

내가 처음 시도했던 것 (그리고 왜 실패했는가)

저의 즉각적인 반응은 OpenAI 호출 부분에 try-catch 문을 씌우고 다른 모델로 폴백(Fallback)하는 것이었습니다. 다음과 같은 방식이었죠:

async function getCompletion(prompt) {
  try {
    return await openai.createCompletion(prompt);
...

이것은 순진한 생각이었습니다. 폴백 대상이 정의되지 않았기 때문입니다. 설령 다른 제공업체로 전환한다 하더라도, 다음과 같은 것들이 필요했습니다:

서로 다른 API 엔드포인트(Endpoint)와 키(Key)
서로 다른 요청/응답(Request/Response) 형식
각 제공업체별로 특화된 속도 제한(Rate limits) 처리
토큰 제한(Token limits) 관리 (OpenAI, Cohere, Anthropic은 모두 다름)

저는 무차별 대입(Brute-force) 방식을 시도했습니다: OpenAI가 실패하면 Anthropic을 시도하고, 그것도 실패하면 Cohere를 시도하는 식이었죠. 하지만 코드 곳곳에 중복이 발생했고, 인증(Auth) 방식이 뒤섞였으며, 에러 처리(Error handling)는 스파게티 코드가 되어버렸습니다.

이 막다른 길들은 저에게 한 가지를 가르쳐 주었습니다: 단순한 try-catch의 사슬이 아니라, 진정한 추상화 계층(Abstraction layer)이 필요하다는 것입니다.

실제로 효과가 있었던 접근 방식

저는 가벼운 **AI 모델 라우터(AI model router)**를 구축했습니다. 이는 제공업체 간의 차이를 추상화하고 통일된 인터페이스를 제공하는 모듈입니다. 핵심 아이디어는 다음과 같습니다: 공통 응답 형태를 정의한 다음, 각 AI 서비스에 대한 제공업체 클래스(Provider class)를 구현하고, 어떤 제공업체를 사용할지(그리고 언제 폴백할지) 결정하는 라우터를 만드는 것입니다.

다음은 제가 최종적으로 프로덕션 환경에서 사용한 축약된 버전입니다:

1. 공통 응답 인터페이스 정의

interface AIResponse {
  text: string;
  model: string;
...

모든 제공업체는 반드시 이 정확한 형태를 반환해야 합니다. 이를 통해 앱을 위한 데이터를 정규화(Normalize)할 수 있습니다.

2. 제공업체 클래스 구축

각 제공업체(Provider)는 generate(prompt: string): Promise<AIResponse> 메서드를 구현합니다. 다음은 OpenAI를 위한 단순화된 예시입니다:

class OpenAIProvider {
  private client: OpenAIApi;
  private model: string;
...

그리고 Anthropic (Claude)를 위한 유사한 클래스입니다:

class AnthropicProvider {
  private client: Anthropic;
  private model: string;
...

3. 라우터 클래스 (The Router Class)

여기가 마법이 일어나는 곳입니다. 라우터는 순서대로 제공업체를 시도하며 에러를 유연하게 처리합니다.

class AIRouter {
  private providers: { provider: AIProvider; weight: number }[];
  private currentIndex: number = 0;
...

각 제공업체 클래스 내부에 지수 백오프 (Exponential Backoff)를 적용한 재시도 로직 (Retry logic)도 추가했지만, 라우터는 전체적인 서비스 중단 (Total outages)을 처리합니다. 또한, 이미 다운된 것으로 알려진 제공업체를 건너뛰기 위해 상태 확인 (Health checks, 매 30초마다)을 구현할 수도 있습니다.

실제 코드: 하나로 합치기

const openaiProvider = new OpenAIProvider(process.env.OPENAI_API_KEY);
const anthropicProvider = new AnthropicProvider(process.env.ANTHROPIC_API_KEY);
// 더 많은 제공업체 추가 (Cohere, 로컬 LLM 등)
...

이 패턴은 매우 단순하지만 저를 여러 번 구해주었습니다. 라우터는 단순히 폴백 (Fallback)만 수행하는 것이 아니라, 제공업체 간에 부하 분산 (Load-balancing)도 수행하여 특정 제공업체의 속도 제한 (Rate limits)을 피하는 데 도움을 줍니다.

교훈 및 트레이드오프 (Lessons Learned & Trade-offs)

다음에 다르게 시도해 볼 점:

제공업체의 지연 시간 (Latency)과 실패율을 추적하고, 동적으로 가중치 (Weights)를 조정합니다 (예: Prometheus 메트릭을 통해).
비용과 지연 시간을 줄이기 위해 동일한 프롬프트에 대한 응답을 캐싱 (Cache)합니다.
실패하는 제공업체를 반복적으로 시도하지 않도록 서킷 브레이커 (Circuit breakers)를 구현합니다.

이 방식이 과할 때 (Overkill):

앱이 몇 분 또는 몇 시간의 다운타임을 견딜 수 있다면, 큐 (Queue)를 사용하는 단순한 단일 제공업체 방식도 괜찮습니다.
무료 또는 저렴한 모델만 사용하는 경우, 여러 제공업체를 사용하는 복잡성이 비용 대비 타당하지 않을 수 있습니다.
제공업체 간에 정확히 동일한 동작(예: 특정 토큰화 (Tokenization))이 필요한 경우, 정규화 (Normalization) 문제에 직면하게 됩니다.

트레이드오프 (Trade-offs):

이제 여러 개의 API 키를 관리해야 하며, 여러 개의 구독 비용을 지불하게 될 가능성이 높습니다.
제공자(Provider)마다 응답 품질이 다를 수 있으므로, 앱이 서로 다른 스타일을 처리할 수 있어야 합니다.
폴백 체인 (Fallback chain)을 거치면서 지연 시간 (Latency)이 증가합니다 (단, 타임아웃 (Timeout)을 설정할 수 있습니다).

저는 결국 이 라우터 (Router)의 최소 버전을 오픈 소스로 공개했으며, 기존 솔루션들도 살펴보았습니다. ai.interwestinfo.com과 같이 내장된 모니터링 기능을 갖춘 유사한 멀티 제공자 라우팅 (Multi-provider routing) 서비스를 제공하는 곳들도 있지만, 저는 제 프로젝트를 위해 완전한 제어권을 원했습니다.

마치며

이 라우터를 구축하는 과정은 화려하지 않았습니다. 공포와 좌절 속에서 탄생했습니다. 하지만 이 과정은 AI 통합 (AI integration)에 관한 근본적인 진실을 가르쳐 주었습니다. 그것들은 실패할 것이며, 당신에게는 우아한 퇴장로 (Graceful exit)가 필요하다는 사실입니다.

이제 저는 AI 기반 기능을 배포할 때마다 스스로에게 묻습니다. "만약 이 제공자가 새벽 3시에 중단된다면 어떻게 될까?" 그 대답이 "내 앱이 망가진다"가 되어서는 결코 안 됩니다.

AI API가 다운되었을 때 여러분의 폴백 전략 (Fallback strategy)은 무엇인가요? 다른 분들은 이 문제를 어떻게 처리하는지 정말 듣고 싶습니다. 특히 재학습 (Retraining) 없이는 단순히 전환할 수 없는 하위 레벨 모델 (Lower-level models)의 경우라면 더욱 그렇습니다.