WaveSpeed 260개 LLM API, 모델 선택이 라우팅 계층으로 간다

AI 요약

• 무슨 일: WaveSpeed가 260개 이상 LLM을 하나의 OpenAI 호환 API로 접근하는 통합 LLM API 확장을 발표했습니다.
  • 같은 계정에서 이미지, 비디오, 오디오, 3D, 아바타까지 포함한 1,000개 이상 AI 모델을 쓰는 구성을 내세웁니다.
• 의미: 에이전트와 멀티모달 앱의 경쟁축이 모델 호출 코드에서 routing policy, 비용 관측, 장애 대응으로 이동하고 있습니다.
• 주의점: 모델 라우터는 편하지만 에이전트 컨텍스트와 도구 결과를 지나는 신뢰 경계가 됩니다.
  • 실제 도입 전에는 latency, fallback 품질, 로그 보관, 데이터 처리, 공급자별 약관을 따로 검증해야 합니다.

WaveSpeed가 2026년 5월 17일 통합 LLM API 확장을 발표했습니다. 발표 자체는 간단합니다. GPT, Claude, Gemini, Grok, DeepSeek, Llama, Qwen, Mistral 같은 모델 계열을 포함해 260개 이상의 언어 모델을 하나의 API로 접근하게 하겠다는 것입니다. 그런데 이 뉴스의 핵심은 숫자보다 위치입니다. WaveSpeed는 원래 이미지, 비디오, 오디오, 3D, 아바타 생성 모델을 API로 묶어 제공하던 쪽에 가까웠습니다. 이번 발표는 그 위에 LLM 라우팅 계층을 얹어, 에이전트와 생성형 미디어 워크플로 전체를 한 플랫폼 안으로 끌어오려는 시도입니다.

이것은 단순한 "모델 목록이 늘었다"는 소식이 아닙니다. 최근 AI 애플리케이션은 하나의 모델을 고정 호출하는 구조에서 벗어나고 있습니다. 기획은 비싼 추론 모델에 맡기고, 짧은 분류는 저렴한 모델로 처리하고, 사용자가 이미지를 올리면 비전 모델로 넘기고, 최종 산출물은 이미지·비디오·음성 모델로 만듭니다. 코딩 에이전트도 비슷합니다. 어떤 작업은 Claude류 모델이 강하고, 어떤 작업은 GPT 계열이 안정적이며, 어떤 작업은 오픈 웨이트 모델을 자체 배포하는 편이 낫습니다. 이때 개발팀이 매번 SDK, API key, billing, rate limit, 장애 대응을 따로 관리하면 제품보다 배선이 먼저 복잡해집니다.

WaveSpeed가 노리는 지점은 바로 그 배선입니다. 공식 발표에 따르면 새 LLM API는 표준 Chat Completions 인터페이스를 사용하고, streaming, JSON mode, tool use, vision을 지원합니다. WaveSpeed의 quick start 문서는 base URL을 https://llm.wavespeed.ai/v1로 두고 OpenAI SDK의 base_url 또는 baseURL만 바꾸는 예시를 제공합니다. 모델 ID는 vendor/model 형식입니다. 예를 들어 anthropic/claude-opus-4.6처럼 공급자 prefix를 붙이고, 나머지 요청 형식은 OpenAI Chat Completions에 맞추는 방식입니다.

이 패턴은 이미 개발자들에게 익숙합니다. OpenRouter, LiteLLM, Portkey, Vercel AI Gateway 같은 계층은 모델 공급자가 늘어날수록 중요해졌습니다. 다만 WaveSpeed의 포지션은 조금 다릅니다. LLM-only gateway가 아니라, 같은 API key와 billing 계정으로 이미지 생성, 비디오 생성, 오디오·음성 생성, 3D 생성, avatar/lipsync 모델까지 연결하겠다고 말합니다. 발표문은 전체 AI 모델 카탈로그가 1,000개 이상이라고 설명합니다. AI 앱이 텍스트 챗봇에서 멀티모달 제작 파이프라인으로 바뀌면, 이 차이는 작지 않습니다.

예를 들어 마케팅 자동화 제품을 생각해 보겠습니다. 첫 단계에서는 LLM이 캠페인 브리프를 읽고 카피와 장면 구성을 만듭니다. 다음 단계에서는 이미지 모델이 제품 컷을 만들고, 비디오 모델이 숏폼 광고를 생성하며, 음성 모델이 내레이션을 붙입니다. 여기에 에이전트가 성과 데이터를 읽고 다음 실험안을 제안한다면, workflow 안에는 이미 여러 모델 유형이 섞입니다. 이 흐름에서 "LLM API"와 "이미지 API"와 "비디오 API"를 완전히 별도 시스템으로 다루면, 인증·비용·로그·실패 처리도 쪼개집니다. WaveSpeed는 이를 하나의 모델 stack으로 묶겠다는 쪽입니다.

개발자 입장에서 가장 직접적인 변화는 모델 선택이 코드가 아니라 설정과 정책의 문제가 된다는 점입니다. 오늘은 openai/gpt-5.5, 내일은 anthropic/claude-opus-4.7, 특정 저비용 경로는 deepseek/deepseek-v4로 바꾸는 식입니다. WaveSpeed 발표는 모델을 price, context window, vision input, audio input, tool use 같은 capability tag로 비교할 수 있다고 설명합니다. 이런 구조에서는 "가장 좋은 모델 하나"를 고르는 것보다 "어떤 입력과 업무에서 어떤 모델을 쓸 것인가"가 더 중요해집니다.

이는 에이전트 아키텍처에도 영향을 줍니다. 에이전트는 보통 계획, 검색, 도구 호출, 검증, 요약, 사용자 응답 같은 여러 단계를 거칩니다. 모든 단계에 가장 비싼 모델을 쓰면 비용이 터집니다. 모든 단계에 가장 싼 모델을 쓰면 품질과 신뢰가 흔들립니다. 그래서 production agent에는 점점 라우팅 정책이 필요해집니다. 고위험 의사결정은 보수적인 모델과 인간 승인을 요구하고, 반복적인 변환은 저렴한 모델로 처리하며, 실패하면 다른 공급자로 fallback하는 구조입니다. WaveSpeed 같은 gateway는 이런 정책의 실행 지점이 될 수 있습니다.

하지만 바로 이 이유 때문에 신뢰 경계가 중요합니다. LLM gateway는 단순한 HTTP proxy가 아닙니다. 에이전트의 system prompt, 사용자 입력, 검색 결과, 내부 문서 요약, tool output, 때로는 코드 diff와 로그까지 지날 수 있습니다. 멀티모달 workflow에서는 이미지 prompt, 생성 결과 URL, 음성 합성 요청, 비디오 asset 메타데이터도 함께 다뤄집니다. 편의성은 중앙화에서 나오지만, 위험도 중앙화됩니다. 하나의 key로 많은 모델에 접근한다는 것은 key 유출 시 blast radius가 넓어진다는 뜻이기도 합니다.

따라서 이 발표를 읽는 개발팀은 "OpenAI SDK 그대로 쓸 수 있다"에서 멈추면 안 됩니다. 먼저 어떤 데이터가 gateway를 통과하는지 분류해야 합니다. 고객 PII, 내부 문서, source code, credential이 섞인 로그가 포함되는지 확인해야 합니다. 다음으로 공급자별 약관과 데이터 보관 정책을 확인해야 합니다. gateway가 upstream model provider와 어떤 계약·전송·저장 구조를 갖는지도 중요합니다. 마지막으로 에러와 fallback이 제품 의미를 바꾸지 않는지 테스트해야 합니다. 모델 A가 실패했을 때 모델 B로 넘기는 것은 쉬워 보이지만, 안전 정책과 출력 형식, tool call semantics가 달라질 수 있습니다.

latency도 별도 검증 대상입니다. WaveSpeed는 cold start를 줄이고 낮은 first-token latency를 제공하도록 인프라를 설계했다고 말합니다. 그러나 라우터 계층의 latency는 단일 숫자로 끝나지 않습니다. 요청이 gateway에 도착하는 시간, gateway가 upstream을 선택하는 시간, upstream 모델의 queue, streaming 시작 시간, media generation 완료 시간, 결과 asset 업로드 시간이 모두 합쳐집니다. 특히 에이전트는 한 번의 답변에서 여러 tool call과 모델 호출을 반복합니다. 단일 호출에서 500ms 차이는 작아 보여도, 30단계 에이전트에서는 사용자 경험과 비용을 바꿀 수 있습니다.

비용도 마찬가지입니다. per-token pricing과 subscription 없음은 초기 도입 장벽을 낮춥니다. 그러나 멀티모달 workflow의 비용은 token만으로 계산되지 않습니다. 이미지 생성은 해상도와 step, 비디오 생성은 길이와 품질, 음성은 duration, 3D 생성은 asset 복잡도에 따라 달라집니다. LLM이 계획을 잘못 세워 불필요한 이미지 후보를 20개 만들면, 모델 라우팅 비용보다 미디어 생성 비용이 더 커질 수 있습니다. 그래서 라우터는 가격표만 보여주는 계층이 아니라 budget guardrail과 observability까지 함께 가져야 합니다.

WaveSpeed가 발표문에서 언급한 use case 중 흥미로운 것은 "developer teams evaluating models"입니다. 실제 팀은 벤치마크 리더보드보다 자기 workload에서 모델을 봅니다. 고객 support ticket 분류, SQL 생성, 코드 리뷰, 제품 이미지 설명, 한국어 문서 요약처럼 각자 다른 데이터와 실패 기준이 있습니다. 통합 API는 같은 요청을 여러 모델에 보내고, 품질·속도·가격을 비교하는 실험을 쉽게 만듭니다. 이것이 제대로 작동하면 모델 선택은 분기마다 하는 큰 결정이 아니라, 기능 단위로 지속적으로 조정되는 운영 작업이 됩니다.

그렇다고 모든 팀이 즉시 gateway로 가야 한다는 뜻은 아닙니다. 규제가 강한 회사, 고객 데이터가 민감한 회사, 모델 공급자와 직접 계약해야 하는 회사는 오히려 자체 gateway나 cloud-native AI gateway가 더 맞을 수 있습니다. 특정 모델의 최신 기능을 day one으로 써야 하는 팀도 중간 계층이 기능을 얼마나 빨리 따라오는지 확인해야 합니다. 예를 들어 tool use, structured output, vision input, reasoning control, audio input 같은 기능은 공급자마다 구현과 제약이 다릅니다. "OpenAI 호환"이라는 표현은 개발자 경험을 단순화하지만, 모든 모델 기능이 완전히 동일하다는 뜻은 아닙니다.

이번 뉴스의 더 큰 의미는 AI 인프라 시장이 세 층으로 나뉘고 있다는 점입니다. 첫째는 모델 공급자입니다. OpenAI, Anthropic, Google, xAI, DeepSeek, Meta, Alibaba, Mistral이 여기에 있습니다. 둘째는 모델 실행과 호스팅 계층입니다. 자체 inference cloud, serverless GPU, managed endpoint, batch 처리 등이 들어갑니다. 셋째는 애플리케이션에 가까운 라우팅·관측·정책 계층입니다. 개발자는 점점 세 번째 층에서 실제 제품 품질을 조정하게 됩니다. WaveSpeed의 발표는 첫째 층의 모델 경쟁을 직접 이기겠다는 선언이라기보다, 둘째와 셋째 층 사이에서 멀티모달 모델 stack을 장악하려는 움직임에 가깝습니다.

이 흐름은 devlery가 최근 다룬 에이전트 운영 계층 뉴스와도 연결됩니다. 코딩 에이전트는 승인 루프와 하네스를 경쟁하고, 기업 에이전트는 거버넌스와 관측성을 경쟁하며, 보안 에이전트는 권한과 audit trail을 경쟁합니다. 모델 라우터는 그 아래에서 어떤 모델이 언제 호출되는지 결정합니다. 겉으로는 infrastructure plumbing처럼 보이지만, 실제로는 AI 제품의 품질과 비용, 장애 대응을 좌우합니다.

WaveSpeed의 약속이 강해 보이는 이유는 명확합니다. 모델은 계속 늘어나고, 팀은 모든 공급자와 직접 통합할 시간이 없습니다. 특히 작은 팀은 한 명의 엔지니어가 모델 평가, billing, fallback, media generation, API key 관리까지 떠안기 쉽습니다. 통합 API는 그 부담을 줄입니다. 하지만 그 약속이 실무에서 성립하려면, 플랫폼은 모델 목록만 넓히는 데서 끝나면 안 됩니다. 라우팅 로그, 비용 분석, 실패 원인, output diff, 정책 기반 차단, key scope, 팀별 권한, 데이터 보관 옵션까지 갖춰야 합니다.

그래서 이번 발표를 평가하는 기준은 "260개가 충분히 많은가"가 아닙니다. 이미 모델 수는 개발자가 직접 기억하기 어려울 만큼 많습니다. 중요한 질문은 "이 많은 모델을 안전하고 예측 가능하게 쓸 수 있는가"입니다. 모델 선택이 라우팅 계층으로 이동하는 순간, AI 앱의 차별화는 더 이상 모델 이름 하나로 설명되지 않습니다. 어떤 요청을 어느 모델에 보내고, 실패했을 때 어디로 돌리고, 비용이 일정 한도를 넘으면 무엇을 멈추고, 민감 데이터는 어떤 경로를 금지하는지가 제품의 일부가 됩니다.

WaveSpeed 통합 LLM API는 그 변화의 한 장면입니다. 멀티모달 에이전트 시대에는 LLM이 생각하고, 이미지 모델이 그리고, 비디오 모델이 움직이고, 음성 모델이 말합니다. 개발팀에게 필요한 것은 이 모든 모델을 부르는 코드가 아니라, 그 호출이 어떤 책임 구조 안에서 일어나는지 설명할 수 있는 운영 계층입니다. WaveSpeed가 이 계층을 정말 안정적으로 제공할 수 있다면, 모델 라우터는 AI 앱의 보조 도구가 아니라 제품 아키텍처의 중심이 됩니다.