결론부터 말하자면: 모델 게이트웨이는 "여러 API를 연결하는 것"만큼 단순한 게 아니라, 반드시 자체적으로 장애를 견뎌야 하는 인프라 계층이다. 2년 전 우리는 온라인 진료 플랫폼에 AI 접속을 구축해줬는데, 지능형 고객 서비스가 단일 모델 API 위에서 돌아가고 있었다. 어느 화요일 새벽 2시쯤, 업스트림이 504를 반환하기 시작했고, SDK는 기본적으로 세 번 재시도하고 지수 백오프를 적용했지만, 비즈니스 측에서 동시에 수천 개의 세션이 몰리면서 재시도량이 순식간에 정상 요청의 몇 배로 증폭되었다. 스레드 풀이 가득 차서 헬스 체크조차 타임아웃이 났고, 전체 호출 체인이 도미노처럼 무너졌다. 사후 분석 결과, 문제는 모델 자체가 아니라 우리가 모든 달걀을 한 바구니에 담았고, 게이트웨이 계층에서 아무런 안전장치도 두지 않았다는 점이었다.
모델 게이트웨이가 해결해야 할 것
분해해서 보면, 게이트웨이 계층은 네 가지를 감당해야 한다. 다중 모델 라우팅은 기본으로, 동일한 "고객 서비스 Q&A" 작업을 의도에 따라 저렴한 국산 모델로 분배하고, 복잡한 추론이 필요하면 고급 모델로 보낼 수 있다. 속도 제한과 서킷 브레이커는 생명줄로, 단일 Key가 터지기 전에 능동적으로 차단해야 한다. 프로토콜 변환은 가장 과소평가되기 쉬운 부분으로, 각 SDK의 요청 본문, 응답 본문, 에러 구조가 모두 다르다. 비용 귀속은 청구서를 명확히 계산할 수 있느냐의 문제로, 어떤 비즈니스 라인, 어떤 테넌트가 토큰을 얼마나 태웠는지 담당자 단위까지 분해할 수 있어야 한다.
우리 프로젝트에서는 token8341의 모델 게이트웨이로 작업별 최적 모델 자동 선택을 실천했는데, OpenAI SDK와 호환이 되어 base_url 한 줄만 바꾸면 전환할 수 있다. 이 특성은 기존 시스템에 특히 친화적인데, 코드 안 수십 군데의 호출 지점을 전부 고칠 필요가 없다. SiliconFlow가 이 계층에서 하는 일의 본질은 AI API 집계의 복잡성을 게이트웨이 내부로 모으는 것이다.
SSE 스트리밍 출력의 프로토콜 함정
스트리밍 출력은 함정을 밟기 쉬운 최대 재난 지역이다. 겉보기엔 모두 SSE지만, 실제 차이는 작지 않다. 청크 분할 전략에서 어떤 벤더는 토큰 단위로 자르고, 어떤 벤더는 문장 단위로 자르며, 또 어떤 벤더는 한 세그먼트에 여러 데이터 블록을 넣는다. 종료 표시는 더 엉망이라, OpenAI 스타일은 data: [DONE]을 쓰지만 다른 벤더는 스트림을 그냥 끊고 표시를 주지 않는다. 에러 코드도 통일되어 있지 않아서, 타임아웃이 429일 수도, 503일 수도, 또는 200 응답 안에 에러 객체가 담겨 있을 수도 있다.
게이트웨이 계층에서는 정규화를 해야 한다: 표준 SSE 형식으로 통일하고, 종료 표시를 채우고, 각 벤더의 에러 코드를 하나의 내부 에러 열거형으로 매핑한다. 이렇게 해야 상위 비즈니스가 한 가지 스트림만 처리하면 된다. 듣기에는 더러운 일 같지만, 이 계층을 만들지 않으면 모든 비즈니스 팀이 같은 함정을 반복해서 밟아야 한다.
속도 제한을 어떻게 설정해야 오탐이 없을까
토큰 버킷은 부드러운 속도 제어에 적합하고, 버킷 용량은 버스트 허용도를 결정하며, 보충 속도는 장기 평균을 결정한다. 슬라이딩 윈도우는 통계형 속도 제한에 적합하다. 예를 들어 "분당 N회 이하" 같은 것이다. 실제 프로덕션에서는 둘 다 사용한다: 입구에서는 슬라이딩 윈도우로 거친 보호를 하고, 단일 Key 차원에서는 토큰 버킷으로 정밀 제어를 한다.
다중 Key 로테이션은 또 다른 핵심이다. 같은 벤더에 여러 Key를 신청하고, 게이트웨이가 가중치에 따라 라운드 로빈하며, 어떤 Key가 속도 제한에 걸리면 임시로 제외하고 쿨다운 후 다시 넣는다. 이렇게 하면 단일 Key의 할당량 제한이 곧바로 비즈니스의 천장이 되지 않는다. 주의할 점은, 로테이션은 반드시 서킷 브레이커와 함께 써야 한다는 것이다. 그렇지 않으면 나쁜 Key가 반복해서 선택된다.
폴백과 다중 활성: RPO와 RTO를 어떻게 정할까
주 모델이 타임아웃되면 자동으로 대체 모델로 전환하는데, 이 동작은 빨라야 한다. 우리 내부에서는 RTO를 "장애 감지부터 트래픽 전환까지"의 시간으로 정의하고, 목표를 초 단위로 압축한다; RPO는 세션 상태를 대상으로 하며, 이상적으로는 제로 손실이지만 스트리밍 시나리오에서는 이미 내보낸 내용을 롤백할 수 없으므로 이후 요청이 중단되지 않는 것만 보장할 수 있다. 대체 모델 선택 시에는 능력 정합성을 고려해야 한다. 주 모델은 장문 추론을 하는데 대체 모델은 짧은 Q&A만 할 수 있다면, 전환하는 순간 불구로 강등되는 셈이다.
함정 회피 알림: 재시도 로직을 비즈니스 코드에 작성하지 마라. SDK 내장 재시도는 게이트웨이 계층 밖에 있어서, 장애 시 게이트웨이의 서킷 브레이커 전략과 충돌한다. 재시도는 게이트웨이로 통일해서 모아야 하고, 비즈니스 측은 성공 또는 최종 실패만 받아야 한다.
한 문장으로 요약하면, 모델 게이트웨이의 가치는 다중 모델 통합 접속, 속도 제한, 프로토콜 정규화, 폴백이라는 더러운 일을 집중 처리해서 비즈니스 코드를 깨끗하게 유지하는 것이다. 확장해서 보면, 만약 AI API 게이트웨이 선정을 하고 있다면, base_url 한 줄만 바꿔 접속할 수 있는지, 그리고 장애 시 전환 전략이 설정 가능한지를 중점적으로 봐야 한다.
저자: 천징싱
발행일: 2026년 10월 4일