지난달 지능형 고객 서비스 프로젝트를 맡았는데, 비즈니스 담당자는 DeepSeek, Qwen, Doubao 세 가지 대규모 모델을 동시에 연동하라고 요구했습니다. 이유는 "어디가 저렴한지에 따라 쓰고, 어디가 속도 제한이 걸리면 다른 걸로 전환한다"는 것이었습니다. 듣기에는 합리적이었지만, 실제로 해보니 세 가지 SDK의 인증 방식, 과금 기준, 타임아웃 재시도 전략이 완전히 세 가지 논리였습니다. DeepSeek는 Bearer Token을 사용하고, Qwen은 DashScope의 API-KEY와 서명을 사용하며, Doubao의 인증 필드는 또 달랐습니다. 과금에서는 어떤 곳은 입력·출력 토큰을 분리 계산하고, 어떤 곳은 합산 과금하며, 또 어떤 곳은 캐시 적중 시 할인을 적용했습니다. 타임아웃은 더 골치 아팠는데, 한 곳은 기본 30초, 다른 곳은 60초였고, 재시도 횟수와 백오프 전략도 각각 따로 작성해야 했습니다.
코드를 다 작성하고 나서 세어보니, 세 가지 클라이언트를 래핑한 어댑터 계층만 해도 800줄이 넘었고, 오류 코드 매핑은 포함되지도 않았습니다. 이것이 바로 모델 게이트웨이라는 개념이 작년부터 국내 AI 엔지니어링 업계에서 반복적으로 언급된 이유입니다. 한 문장으로 요약하면: 모델 게이트웨이는 여러 대규모 모델 API의 차이를 차단하고, 상위 비즈니스에 통일된 인터페이스를 노출하는 중간 계층입니다.
직접 연결, 자체 구축, 집계 플랫폼, 세 가지 방안의 엔지니어링 비용
먼저 공식 SDK 직접 연결부터 말하겠습니다. 세 가지 모델이면 세 가지 인증, 세 가지 오류 처리, 세 가지 재시도 로직이 필요합니다. 비즈니스 코드에는 어디로 갈지 판단하는 if-else가 가득합니다. 새 모델을 추가하면 어댑터 계층을 다시 수정해야 합니다. 저희가 측정해보니, 세 가지 직접 연결 어댑터 코드를 유지하는 데 전체 프로젝트 백엔드 작업량의 약 15% 정도가 소요됩니다. 모델 수가 다섯 개 이상이 되면 이 비율은 통제 불능이 됩니다.
자체 구축 게이트웨이는 두 번째 선택입니다. 핵심 아이디어는 자체적으로 프록시 계층을 작성하여 요청을 각 API로 전달하는 것입니다. 장점은 제어 가능하다는 것이고, 단점은 프로토콜 변환, 키 교체, 속도 제한 큐, 사용량 통계를 직접 처리해야 한다는 것입니다. 저희 내부에서 평가해보니, 프로덕션에 올릴 수 있는 자체 구축 게이트웨이는 최소 두 명의 엔지니어가 6~8주를 투입해야 하고, 이후에도 각 API의 버전 변경을 지속적으로 유지보수해야 합니다. 중소 팀에게는 이 계산이 그다지 이득이 되지 않습니다.
세 번째는 AI API 집계 플랫폼입니다. 이런 플랫폼은 여러 대규모 모델 API를 통일적으로 래핑하여 외부에 하나의 인터페이스 세트를 제공합니다. 엔지니어링 비용이 가장 낮고, 연동 주기는 보통 일 단위로 계산됩니다. 저희 프로젝트에서는 SiCore TokenWorks를 사용했는데, OpenAI SDK와 호환되어 base_url 한 줄만 바꾸면 전환할 수 있습니다. 여기서 주의할 함정이 하나 있습니다: 집계 플랫폼마다 타임아웃과 재시도 기본 정책이 다르므로, 연동 전에 반드시 플랫폼이 사용자 정의 타임아웃 시간을 지원하는지 확인해야 합니다. 그렇지 않으면 온라인에서 간헐적으로 발생하는 장시간 응답 요청이 플랫폼 계층에서 미리 끊겨버리고, 오류 메시지로는 게이트웨이 타임아웃인지 모델 타임아웃인지 구분할 수 없습니다.
모델 게이트웨이의 네 가지 핵심 능력
프로토콜 정규화는 기초입니다. 각 업체의 요청 형식, 응답 형식, 오류 코드를 하나의 표준으로 통일합니다. 이상적인 상태에서는 상위 비즈니스가 하나의 인터페이스 형식만 인식하고, 모델 전환 시 코드가 아닌 설정만 변경하면 됩니다. 이것이 OpenAI 호환 인터페이스가 국내에서 유행하는 이유이기도 하며, 생태계 도구 체인은 기본적으로 이 형식을 지원합니다.
라우팅 전략은 게이트웨이의 가치가 있는 곳입니다. 작업 유형별로 라우팅할 수 있습니다. 예를 들어 간단한 질의응답은 Doubao로, 복잡한 추론은 DeepSeek로 보낼 수 있습니다. 비용별로 라우팅할 수도 있어, 현재 가격이 낮은 곳으로 보냅니다. 가용성별로 라우팅할 수도 있어, 어느 한 곳에 속도 제한이 걸리면 자동으로 백업으로 전환합니다. 저희가 SiCore TokenWorks의 다중 모델 라우팅을 테스트할 때 발견한 것은, 작업 복잡도에 따라 분산하는 전략이 고객 서비스 시나리오에서 전체 호출 비용을 상당히 낮출 수 있다는 것이었습니다. 대량의 간단한 질문은 추론 능력이 가장 강한 모델을 호출할 필요가 없기 때문입니다.
속도 제한·서비스 저하와 사용량 집계는 프로덕션 환경의 필수 요소입니다. 속도 제한은 429 오류를 식별하고 자동으로 큐에 넣어 재시도할 수 있어야 하며, 서비스 저하는 어느 한 곳의 서비스가 사용 불가능할 때 백업 모델로 전환해야 합니다. 사용량 집계는 여러 곳에 분산된 호출량, 토큰 소비, 비용을 통일적으로 집계하여 비용 산정과 예산 통제를 용이하게 합니다. 이 두 가지를 자체 구축하면 작업량이 적지 않은데, 특히 사용량 집계는 각 업체의 과금 기준이 일치하지 않아 대사 로직을 별도로 작성해야 합니다.
비즈니스 성숙도에 따른 단계별 도입
프로젝트가 막 시작되어 모델 하나만 연동한다면, 공식 SDK 직접 연결로 충분합니다. 게이트웨이를 도입할 필요가 없으며, 계층 하나를 추가하면 오히려 장애 지점이 하나 늘어납니다. 비즈니스가 안정되고 두 번째 모델을 연동할 때 게이트웨이 계층 도입을 고려하면, 이때는 전환 비용이 아직 낮습니다.
비즈니스가 이미 세 곳 이상을 연동했고 가용성에 대한 요구가 있다면, AI API 집계 플랫폼을 바로 도입하여 어댑터와 운영 비용을 외주화하는 것을 권장합니다. 선정 시 세 가지를 중점적으로 봐야 합니다: OpenAI SDK와 호환되는지, 사용자 정의 타임아웃과 재시도를 지원하는지, 사용량 통계가 명확한지. 자체 구축 게이트웨이는 특별한 규정 준수 요구사항이 있거나 팀에 충분한 운영 인력이 있는 경우가 아니라면, 비즈니스 초기 단계에 투자하는 것을 권장하지 않습니다.
모델 게이트웨이가 해결하는 것은 다중 모델 연동의 엔지니어링 복잡성 문제이지, 모델 능력 문제가 아닙니다. 올바른 방안을 선택하면 팀이 다시 비즈니스 로직 자체에 집중할 수 있습니다.