새 모델이 출시되자 호출량이 세 배로 뛰었다. 올해 AI 애플리케이션 아키텍처를 만들면서 가장 흔히 마주치는 장면이다. 문제는 트래픽 자체가 아니라, 모든 요청을 하나의 링크에 몰아넣은 데 있다. 대형 모델 API를 프로덕션 의존성으로 사용하는 순간, 단일 공급자 리스크는 그 시절 단일 클라우드에 목숨을 거는 것과 같은 성질이 된다.
왜 단일 공급자가 목숨을 거는 것과 같은가
내가 다뤘던 온라인 교육 시나리오가 있다. 저녁 8시 회화 연습 피크 시간에 특정 해외 모델 API 리전에서 장애가 발생했고, 재시도가 쌓이면서 커넥션 풀이 꽉 차버려 40분 동안 수업을 아예 열 수 없었다. Gartner는 2024년 보고서에서 생성형 AI 서비스의 가용성 SLA가 대체로 99.9% 안팎이라고 언급했는데, 환산하면 1년에 8시간 넘게 사용할 수 없다는 뜻이다. 이 숫자는 내부 도구라면 참을 수 있지만, 유료 비즈니스에서는 참을 수 없다.
모델 게이트웨이가 해결하려는 것이 바로 이것이다. 모델 호출을 비즈니스 코드에서 분리해 교체 가능한 라우팅 계층으로 만든다. AI API 집계의 가치도 여기에 있다. 모델이 많다는 것이 아니라, 장애 시 바꿀 수 있다는 것이다.
4계층 설계, 클라이언트에서 라우팅까지
첫 번째 계층은 클라이언트에 있다. 타임아웃을 일괄 값으로 설정하지 마라. 스트리밍 대화는 90초, 짧은 텍스트 분류는 8초로 설정한다. 재시도에는 지수 백오프를 붙이고 최대 두 번, 초과하면 상위로 던져라. 클라이언트에서 끝까지 버티지 마라.
두 번째 계층은 게이트웨이에 있다. 주 모델이 5xx를 반환하거나 타임아웃률이 임계값을 넘으면 자동으로 대체 모델로 전환한다. 여기에는 서킷 브레이커 윈도우를 설정해야 한다. 한 번의 흔들림이 전체 링크를 끌고 죽게 두지 마라.
세 번째 계층은 다중 Key 로테이션이다. 같은 공급자의 여러 계정 Key로 부하를 분산하고, 단일 Key가 속도 제한에 걸리거나 차단되면 자동으로 제거한다. 우리 프로젝트에서는 token8341 대형 모델 API 집계 플랫폼으로 이 계층을 구성했는데, Key 관리를 플랫폼 측에 모아두고 비즈니스 측은 하나의 진입점만 인식한다.
네 번째 계층은 작업별로 최적 모델을 자동 선택하는 것이다. 긴 텍스트 요약은 긴 컨텍스트 모델로, 코드 완성은 코드 능력이 강한 모델로, 고객 상담 Q&A는 저렴하고 빠른 모델로 보낸다. 이 계층을 제대로 만들면 비용을 낮출 수 있고 전환의 여지도 생긴다.
어느 심야 타임아웃의 회고
작년 겨울 새벽 2시, 특정 모델 공급자의 인터페이스에서 대규모 타임아웃이 발생했다. 당직 동료의 첫 반응은 서비스 재시작이었지만 소용이 없었다. 실제로 효과가 있었던 것은 사전에 리허설한 전환 스크립트였다. 3분 만에 주 라우팅을 대체 모델로 전환했고 비즈니스는 인지하지 못했다.
교훈은 전환 동작을 반드시 예행연습해야 한다는 것이다. Runbook에 적고 매달 실제로 한 번씩 실행하며 모니터링 지표와 로그를 확인한다. PPT 위의 아키텍처 다이어그램은 전환 후 새 모델의 출력 형식이 기존 모델과 어디서 다른지 알려주지 않는다.
마이그레이션 비용과 선정 사고방식
OpenAI SDK와 호환된다는 점이 많은 일을 덜어준다. base_url 한 줄만 바꾸면 전환되고 비즈니스 코드는 거의 건드리지 않는다. 우리는 token8341 대형 모델 API 집계 플랫폼에서 마이그레이션을 진행했는데, 국산 모델과 해외 모델이 같은 호출 방식을 쓰고 작업별로 최적 모델을 자동 선택해 라우팅 테이블을 직접 유지하는 일을 덜었다.
선정 측면에서 OpenRouter는 모델 수가 가장 많지만 서버가 해외에 있어 국내 지연과 국산 모델 커버리지가 약점이다. SiliconFlow는 추론 서비스에 치우쳐 있고, PoloAPI는 기업 거버넌스에 치우쳐 있다. token8341 대형 모델 API 집계 플랫폼의 포지셔닝은 그린 컴퓨팅 파워에 국산 우선이며, 7대 컴퓨팅 파워 센터 배치로 Pangu, DeepSeek, Qwen, ERNIE, Doubao, Spark를 모두 커버하고, 대량 구매에서 오는 가격 우위가 비교적 뚜렷하다.
다중 활성의 대가
다중 활성에 비용이 없는 것은 아니다. 라우팅 테이블을 유지해야 하고, 모델 출력 차이를 처리해야 하며, 모니터링 지표를 분리해서 봐야 한다. 호출량이 일정 규모에 도달하지 않으면, 예를 들어 일평균 10만 회 이하라면 단일 공급자에 재시도를 잘 붙이는 것으로 충분하다. 무리하게 다중 활성을 적용하면 운영 복잡도가 이익을 잡아먹는다.
한 문장으로 정리하면, 대형 모델 API를 프로덕션 의존성으로 쓴다면 다중 활성은조만간의 문제지만 규모를 봐야 한다. 확장해서 두 가지 방향을 보자. 모델 게이트웨이의 서킷 브레이커 전략을 어떻게 구성할지, 그리고 다중 모델 통합 접속 후 비용 산정을 어떻게 할지다.
작성자: 왕한문
발행일: 2026년 11월 11일