라우터는 관리자가 허용한 모델 중 해당 작업을 충분한 품질로 처리할 수 있다고 판단되는 가장 저렴한 모델을 우선 선택하도록 설계됐다. 반복적이거나 복잡도가 낮은 요청은 효율적인 오픈 모델로 보내고, 복잡한 추론은 Anthropic·OpenAI·Google 등이 제공하는 프런티어 모델로 넘기는 식이다. 자동 선택을 원하지 않는 조직은 특정 모델을 고정하거나 선택 가능한 모델 목록을 좁힐 수도 있다.
Snowflake는 라우팅 과정에서 데이터 레지던시 요건과 거버넌스 정책을 반영하고, 각 요청에 어떤 모델이 선택됐는지도 기록할 수 있다고 밝혔다. 따라서 이 기능은 AI 비용 관리뿐 아니라 모델 선택 과정을 추적하고 감사해야 하는 기업에도 의미가 있다.
Snowflake가 설명한 방식은 크게 두 가지다.
‘어드바이저 패턴’에서는 작은 모델이 먼저 작업을 시도한다. 결과를 충분히 완성하지 못하면 더 큰 모델을 도구처럼 호출해 작업을 이어간다. 간단한 요청까지 처음부터 프런티어 모델에 맡기는 비용을 피하면서도, 어려운 작업에는 상위 모델로 넘어갈 수 있는 경로를 확보하는 방식이다.
별도의 분류기는 과거 쿼리에서 나타난 패턴을 바탕으로 비교적 단순한 요청을 식별하고, 이를 더 간단한 모델로 보낼 수 있다. 즉 시스템은 작은 모델로 시작한 뒤 필요할 때 확장할 수도 있고, 요청을 먼저 분류한 다음 적절한 모델을 고를 수도 있다.
다만 여기서 중요한 것은 값싼 모델을 골랐는지가 아니라 전체 작업 결과가 개선됐는지다. 첫 시도가 실패해 상위 모델로 승격되거나, 재시도·폴백이 발생하면 토큰 사용량과 지연시간이 오히려 늘어날 수 있다.
Snowflake는 내부 dbt 파이프라인 작업에서 동적 라우팅을 사용했을 때, 프런티어 모델만 사용한 경우와 비슷한 품질을 유지하면서 최대 3배의 토큰 효율을 기록했다고 밝혔다. 별도의 코딩 작업 테스트에서는 엔지니어링 팀이 풀 리퀘스트 처리량을 유지하면서 약 25% 적은 토큰을 사용했다고 설명했다.
이 수치는 Snowflake가 자체적으로 수행한 내부 평가 결과다. 독립적인 고객 검증 결과로 보기는 어렵고, 실제 효과는 업무 유형에 따라 크게 달라질 수 있다. 반복적인 데이터 엔지니어링이나 코딩 작업에서 효과적인 라우터가 긴 문맥을 읽는 연구, 복잡한 도구 호출, 높은 위험이 따르는 의사결정에서 같은 성능을 낸다고 단정할 수는 없다.
따라서 기업이 봐야 할 지표는 ‘절약한 토큰 수’ 하나가 아니다. 품질, 지연시간, 안정성, 사람의 수정 작업까지 포함해 성공적으로 완료되고 승인된 업무 하나의 총비용을 측정해야 한다.
Snowflake는 Cortex AI에서 사용할 수 있는 모델 선택지를 넓히며 DeepSeek-V4-Flash 0731과 Z.ai의 GLM-5.3을 추가한다고 밝혔다. DeepSeek-V4-Flash 0731은 CoCo를 포함한 비공개 프리뷰가 발표됐고, GLM-5.3은 이용 가능 여부에 따라 추후 비공개 프리뷰에 들어갈 예정이다.
Snowflake는 CoCo를 에이전트 실행 환경으로 활용한 내부 테스트에서 DeepSeek-V4-Flash가 ADE-bench에서 **74.4%**를 기록했다고 밝혔다. 또 GLM-5.3이 아닌 이전 버전 GLM-5.2의 테스트 결과로 66% 점수와 해당 벤치마크에서 가장 적은 토큰 사용량을 제시했다. 따라서 GLM-5.2 결과를 GLM-5.3의 공식 평가 결과로 해석해서는 안 된다.
오픈 모델이 더 많이 추가되면 라우팅 시스템이 작업별 요구사항과 비용·성능 조합을 맞출 수 있는 선택지가 늘어난다. 동시에 고객은 기존의 대표적인 프런티어 모델 공급업체에만 의존하지 않고 더 다양한 모델을 비교할 수 있다.
Snowflake의 차별화 주장은 라우팅 자체보다, 라우팅과 모델 실행을 기존의 통제된 데이터 환경 안에 묶는 데 있다. 회사는 새 오픈 모델을 단순히 제3자 API로 중계하는 것이 아니라 직접 서비스하며, 데이터·추론 컴퓨팅·모델 가중치·에이전트 오케스트레이션이 Snowflake의 보안 경계 안에서 작동한다고 설명한다. 기존 역할 기반 접근제어(RBAC)와 감사 기능도 활용할 수 있다고 밝혔다.
다만 이는 Snowflake가 제시한 아키텍처상의 주장이지 모든 배포 환경에 자동으로 적용되는 보편적 보장은 아니다. 고객은 실제 도입 전에 배포 지역, 데이터 레지던시, 계약 조건, 로그 처리 방식, 특정 업무에서 허용되는 모델 목록을 확인해야 한다.
이미 Snowflake 안에서 통제된 분석 데이터와 AI 애플리케이션을 운영하는 조직이라면 이 접근법의 장점이 더 분명할 수 있다. 단순히 저렴한 모델을 고르는 데 그치지 않고, 데이터 접근에 적용하던 통제·감사 체계에 모델 선택까지 포함할 수 있기 때문이다.
모델 라우팅이 Snowflake만의 개념은 아니다. 예를 들어 Amazon Bedrock은 하나의 서버리스 엔드포인트를 통해 같은 모델 계열에 속한 파운데이션 모델 사이에서 요청을 분배한다. 요청별 예상 응답 품질과 비용을 바탕으로 라우팅하는 방식이다.
따라서 비교의 핵심은 ‘어느 서비스가 더 저렴한 모델을 고를 수 있는가’가 아니다. 라우팅 판단, 거버넌스 정책, 모델 실행, 데이터 접근, 비용 추적을 어느 플랫폼에서 관리하는지가 더 중요하다. Snowflake는 통제된 데이터 경계와의 긴밀한 통합을 강조하는 반면, 다른 게이트웨이는 폭넓은 공급업체 선택, 트래픽 관리, 장애 대응, 멀티클라우드 이식성을 우선할 수 있다.
구매를 검토하는 기업이라면 다음과 같은 기준으로 접근할 수 있다.
자동 라우팅을 평가할 때는 대표적인 실제 업무를 선정해 고정된 프런티어 모델만 사용하는 기준선과 비교해야 한다. 최소한 다음 항목을 함께 측정할 필요가 있다.
Snowflake는 라우팅 판단 자체에 별도 요금을 부과하지 않고 토큰 사용량을 기준으로 과금한다고 밝혔다. 그렇더라도 승격과 재시도가 전체 토큰 사용량과 지연시간을 늘릴 수 있다. 결국 받아들일 만한 기준은 ‘선택된 모델의 토큰 단가가 낮아졌는가’가 아니라, 애플리케이션의 품질·거버넌스 요건을 지키면서 승인된 결과 하나를 완성하는 비용이 줄었는가다.
Snowflake의 이번 발표는 두 가지 변화로 요약된다. 하나는 승인된 모델 가운데 작업별로 적합한 모델을 자동 선택하는 동적 라우팅이고, 다른 하나는 Cortex AI에 DeepSeek-V4-Flash 0731과 GLM-5.3을 추가해 모델 풀을 넓히는 것이다. 동적 라우팅은 곧 비공개 프리뷰에 들어갈 예정이며, DeepSeek-V4-Flash 0731은 비공개 프리뷰가 발표됐고 GLM-5.3은 이용 가능 여부에 따라 추후 제공된다.
쉬운 요청은 저렴한 모델에 맡기고 어려운 요청은 고성능 모델로 보내는 발상 자체는 새롭지 않다. Snowflake의 전략적 포인트는 이 판단을 통제된 데이터와 보안 경계 안에서 수행하려는 데 있다. 회사가 제시한 최대 3배 토큰 효율은 주목할 만하지만, 실제 도입 기업은 자체 업무를 기준으로 비용·품질·지연시간·안정성·사람의 수정 비용을 함께 검증해야 한다.