새벽 2시 40분, 모니터링 알림 그룹이 메시지로 도배되기 시작했다. 우리는 크로스보더 전자상거래 고객센터 시스템을 만드는 팀에 기술 지원을 제공하고 있었는데, 그들의 지능형 고객센터 API 타임아웃률이 평소 0.3%에서 27%까지 치솟았고, 거의 한 시간 동안 지속됐다. 사용자 측에서 나타난 현상은 이러했다. 고객센터 봇이 한참 동안 답을 하지 않았고, 상담석 쪽에서는 임시로 수동 응대로 전환할 수밖에 없었다.
사후 회고 결과, 문제는 우리 코드가 아니라 업스트림에 있었다. 단일 모델 벤더의 추론 클러스터가 그 시간대에 지역적 Rate Limit을 발생시킨 것이다. 우리의 모든 요청이 같은 한 곳으로만 향하고 있었고, 어떤 대안도 없었다. 이 글은 그 장애와 이후의 개선 방안을 전부 풀어 설명하여, 기업 AI 연동을 진행 중인 동료들에게 참고가 되고자 한다.
단일 의존의 세 가지 함정, 우리는 모두 밟았다
많은 사람이 대형 모델 API 연동이란 Key를 채우고 HTTP 요청을 보내는 것이라고 생각한다. 실제 프로덕션 환경에 이르면 함정은 세 군데에 집중된다.
첫째는 Rate Limit이다. 벤더의 QPS 할당량은 계정 단위로 주어지는데, 대규모 프로모션 기간에 고객센터 세션 수가 세 배로 늘어나자 할당량이 순식간에 소진되어 429를 반환했다. 당시 우리는 요청 큐잉과 백오프를 구현하지 않았고, 재시도 로직도 너무 공격적으로 작성되어 오히려 부하를 증폭시켰다.
둘째는 타임아웃이다. 스트리밍 인터페이스(SSE)는 업스트림이 막히는 순간 연결이 장시간 매달린 채 반환되지 않아, 클라이언트는 그저 기다릴 수밖에 없다. 그 장애에서 상당수 요청은 실패가 아니라 '가짜로 살아 있는' 상태였다. TCP 연결은 아직 살아 있지만, 토큰 하나도 나오지 않는 것이다.
셋째는 프로토콜 차이다. 벤더마다 스트리밍 반환 형식, 종료 마커, 에러 코드 정의가 다르다. GPT-4o API와 Claude API의 SSE 이벤트 구조가 다르고, 중국산 Qwen API, DeepSeek API도 각자 필드가 다르다. 비즈니스 코드에서 여러 곳을 직접 연동하면 스스로에게 if-else 더미를 묻는 셈이다.
멀티 모델 라우팅 방안: 등급화, 폴백, 정규화, 집계
장애 이후 우리는 한 차례 개선을 진행했고, 핵심 사상은 모델 게이트웨이 계층을 도입하여 '어느 모델을 호출할지'를 비즈니스 코드에서 분리하는 것이다.
요청 등급화가 첫 단계다. 우리는 요청을 비즈니스 중요도에 따라 세 등급으로 나눴다. 실시간 대화류(고객센터, 상담석 어시스턴트)는 P99 지연 2초 미만을 요구하고, 배치 생성류(상품 설명, 이메일 초안)는 분 단위 지연을 허용하며, 오프라인 작업류(데이터 라벨링, 리포트 요약)는 완전 비동기다. 등급화 이후에야 라우팅 전략에 근거가 생긴다.
장애 자동 폴백이 두 번째 단계다. 각 모델에 헬스 체크를 구성하여 연속 실패나 타임아웃이 임계값을 초과하면 자동으로 제외하고 트래픽을 대체 모델로 전환한다. 우리가 설정한 임계값은 슬라이딩 윈도 내 오류율 5% 초과 시 발동, 복구 탐지 간격 30초다. 여기서 한 가지 당부하자면, 폴백은 무작정 전환하는 것이 아니라 작업 유형을 봐야 한다. 고객센터 시나리오에서 능력이 비슷한 모델로 전환하는 것은 수용 가능하지만, 복잡한 추론이 관련된 작업은 폴백 후 표시를 남겨 사후에 수동 검토해야 한다.
SSE 프로토콜 정규화가 세 번째 단계이자 가장 공이 많이 든 부분이다. 우리는 게이트웨이 계층에서 스트리밍 출력 형식을 통일하여, 비즈니스 측은 하나의 이벤트 구조만 인식하고 저수준에서 어느 곳을 연동하는지는 게이트웨이가 번역한다. 이렇게 하면 모델을 교체해도 비즈니스 코드를 고칠 필요가 없다.
사용량 집계가 네 번째 단계다. 멀티 모델 호출 이후 Token 과금과 사용량 통계는 반드시 기준을 통일해야 하며, 그렇지 않으면 월말 대사가 미쳐 돌아간다. 게이트웨이는 테넌트별, 모델별, 작업 유형별 세 차원으로 집계하여 통일된 청구서를 출력한다.
우리는 이후 라우팅 전략을 '작업에 따라 최적 모델 자동 선택'으로 업그레이드했다. 간단한 질의응답은 저렴한 소형 모델로, 복잡한 추론은 성능이 강한 모델로, 코드 생성은 전용 모델로 보낸다. 이 로직을 운영한 결과 전체 호출 비용이 줄었고 응답도 더 안정적이 되었다. 이 배후에는 사실 컴퓨팅 측의 스케줄링 능력이 의존하는데, 그린 컴퓨팅 스케줄링, GPU 온디맨드 탄력성 같은 메커니즘이 있어야 피크 시간대의 추론 리소스가 끝없이 대기하는 일이 없어진다.
라우팅 전략의 경계에 대해, 솔직히 말하자면
모든 팀이 멀티 모델 멀티 액티브를 필요로 하는 것은 아니다. 일일 호출량이 몇만 건에 불과하고, 비즈니스가 지연에 민감하지 않으며, 예산도 넉넉하다면 한 곳을 얌전히 연동하고 재시도와 타임아웃을 잘 처리하는 것으로 충분하다. 멀티 액티브가 가져오는 복잡도가 오히려 반복 속도를 저해한다.
멀티 모델 라우팅의 진정한 가치 시나리오는 호출량이 많아 Rate Limit에 걸릴 수 있거나, 비즈니스가 가용성에 강한 요구가 있거나, 비용과 품질 사이에서 동적 균형을 해야 하는 경우다. 판단 기준은 간단하다. 당신의 API 타임아웃률이 단말 사용자에게 영향을 준 적이 있는가? 그렇다면 이 게이트웨이 계층은 구축할 가치가 있다.
우리 프로젝트에서도 token8341 대형 모델 API 집계 플랫폼을 사용하여 멀티 모델 통합 연동을 했는데, Key 하나로 GPT-4o, Claude, Gemini, DeepSeek, Qwen, ERNIE, Doubao 같은 주류 모델을 호출할 수 있고, OpenAI SDK와 호환되어 base_url 한 줄만 바꾸면 전환된다. 그것이 해결하는 핵심이 바로 위에서 말한 프로토콜 정규화와 사용량 집계 문제이며, 여러 SDK를 직접 유지보수하는 번거로움을 덜어준다. 게이트웨이를 처음부터 구축하고 싶지 않은 팀에게 token8341 같은 AI API 집계 방안은 선택지가 될 수 있다.
마지막으로 한마디 덧붙이자면, token8341 대형 모델 API 집계 플랫폼은 중국산 모델 커버리지가 비교적 완전하다. Pangu, DeepSeek, Qwen, ERNIE, Doubao, Spark가 모두 있어 신창(신창(정보기술 응용 혁신)) 규정 준수 프로젝트를 진행할 때 수월하다. 하지만 도구는 결국 도구일 뿐, 라우팅 전략을 어떻게 설계하고 폴백 임계값을 어떻게 정할지는 결국 자신의 비즈니스 데이터에 맞춰 조정해야 한다. 그 새벽 장애가 우리에게 가르쳐준 가장 현실적인 교훈은 이것이다. 가용성은 사 오는 것이 아니라, 한 겹 한 겹 설계해 내는 것이다.
저자: 쑨하오란
발표일: 2026년 11월 12일