OpenRouter 1억1300만 달러 투자, 모델 라우터가 받은 표

AI 요약

• 무슨 일: OpenRouter가 CapitalG 주도 Series B에서 1억1300만 달러를 조달했습니다.
  • 공식 발표는 주간 처리량 25조 토큰, 800만+ 개발자, 400개+ 모델을 함께 제시했습니다.
• 의미: 모델 선택은 SDK 문제가 아니라 routing, 비용 상한, failover, compliance를 다루는 운영 계층이 됐습니다.
• 주의점: HN 토론은 billing cap과 실험 편의성을 인정하면서도 provider 직접 호출, cache hit rate, 데이터 경계를 따졌습니다.
  • 에이전트 트래픽은 프롬프트, 도구 결과, 코드 diff, 긴 컨텍스트가 지나가므로 gateway 선택이 보안 설계가 됩니다.

OpenRouter가 2026년 5월 28일 공식 발표에서 1억1300만 달러 Series B를 공개했습니다. 리드 투자자는 Alphabet의 독립 growth fund인 CapitalG입니다. 참여 투자자는 NVentures, ServiceNow Ventures, MongoDB Ventures, Snowflake Ventures, Databricks Ventures, AMP PBC, Pace Capital, 기존 투자자인 Andreessen Horowitz와 Menlo Ventures입니다. 발표문이 같이 내놓은 수치는 투자 규모보다 더 직접적입니다. OpenRouter는 최근 6개월 동안 주간 처리량이 5조 토큰에서 25조 토큰으로 늘었다고 밝혔습니다. 올해 1경 토큰 이상을 처리하는 pace에 있으며, 800만 명 이상 개발자가 400개 이상 모델을 사용한다는 수치도 제시했습니다.

이 뉴스는 "모델 API aggregator가 돈을 받았다"보다 좁게 읽어야 합니다. OpenRouter는 OpenAI, Anthropic, Google, xAI, DeepSeek, Mistral 같은 공급자 모델을 한 인터페이스에서 쓰게 해주는 라우팅 계층입니다. 사용자는 모델마다 계정, 결제, SDK, rate limit, fallback을 따로 묶지 않고 같은 API 표면에서 비교하고 전환할 수 있습니다. OpenRouter 발표가 agents and model providers 사이에 앉는다고 표현한 이유도 여기에 있습니다. 에이전트가 모델을 한두 번 부르는 단계에서 벗어나면, 어떤 요청을 어느 공급자에게 보내고 실패 시 어디로 돌리는지가 제품 품질과 비용을 직접 바꿉니다.

최근 AI 앱의 호출 패턴은 단일 모델 호출보다 batch, routing, cache, fallback에 가깝습니다. 코딩 에이전트는 repository 탐색, plan, patch 생성, test failure 분석, review comment 작성에 서로 다른 모델을 쓸 수 있습니다. 고객지원 에이전트는 intent classification에는 저렴한 모델을, 환불 정책 판단에는 더 강한 모델을, 음성 입력에는 transcription 모델을 붙입니다. 리서치 에이전트는 검색 결과 요약, 긴 문서 비교, 최종 보고서 생성을 따로 나눕니다. 이 구조에서는 "가장 좋은 모델 하나"보다 "각 단계의 비용과 실패 경계"가 더 빨리 문제로 올라옵니다.

투자자 구성도 발표문의 메시지와 맞물립니다. CapitalG는 Alphabet 쪽 자본이고, NVentures는 NVIDIA의 venture arm입니다. ServiceNow, MongoDB, Snowflake, Databricks는 기업 데이터, workflow, cloud data platform과 직접 연결된 회사들입니다. OpenRouter는 이 투자자들을 단순 재무 투자자가 아니라 기업이 이미 의존하는 인프라·플랫폼 회사라고 설명했습니다. 그 문장은 홍보 문구이지만 방향은 분명합니다. 모델 라우터는 consumer chatbot의 편의 기능이 아니라 enterprise AI workload의 중간 통제면으로 팔리고 있습니다.

OpenRouter가 발표에서 강조한 제품 항목은 세 묶음입니다. 첫째, text 밖의 multimodal inference입니다. OpenRouter는 image, audio, speech, transcription, embedding, video 모델 지원을 언급했습니다. 둘째, enterprise controls입니다. Workspaces, spend management, guardrails, zero-data-retention policy를 조직 배포 기능으로 제시했습니다. 셋째, intelligent routing입니다. provider-level failover, cost and latency optimization, quality-aware routing을 단순 load balancing과 구분했습니다. 세 항목 모두 "모델을 많이 모아 놓았다"보다 운영에 가까운 단어입니다.

OpenRouter가 왜 지금 투자 대상으로 보이는지는 주간 25조 토큰이라는 수치에서 드러납니다. 토큰은 AI 제품의 전력 계량기입니다. 사용자 수나 메시지 수보다 거칠지만, inference 비용과 cache, context window, retry, agent loop가 결합된 결과를 가장 빨리 보여줍니다. 5조에서 25조 토큰으로 6개월 만에 늘었다는 말은 단순 가입자 증가만 뜻하지 않습니다. 더 긴 prompt, 더 많은 tool call, 더 많은 자동화 작업, 더 긴 에이전트 세션이 섞였을 가능성이 큽니다. OpenRouter 발표는 그 증가분을 production apps and agents 전환과 연결했습니다.

개발팀의 실무 질문은 여기서 시작됩니다. 모델을 직접 부르면 공급자별 최신 기능과 가격표를 더 정확히 통제할 수 있습니다. 라우터를 쓰면 여러 모델을 빨리 시험하고, key와 결제와 fallback을 한곳에 묶을 수 있습니다. 어느 쪽이 맞는지는 traffic 규모, compliance 요구, vendor 계약, latency 목표, 장애 대응 방식에 따라 달라집니다. 작은 팀이나 빠르게 실험하는 팀은 통합 계정과 billing cap의 이득이 큽니다. 반대로 월 수십억 토큰을 쓰는 팀은 provider 직접 계약, reserved capacity, 전용 endpoint, 자체 gateway가 더 나을 수 있습니다.

Hacker News 반응은 이 양면을 잘 보여줬습니다. 2026년 5월 30일 올라온 OpenRouter Series B 스레드는 8시간 만에 355 points와 172 comments를 기록했습니다. Simon Willison은 처음에는 LLM 앞에 proxy를 두는 이유를 이해하지 못했다고 썼습니다. 이후 여러 모델을 낮은 friction으로 시험하고, public service에 필요한 billing cap을 두며, ranking에서 모델 popularity 신호를 보는 가치가 있다고 평가했습니다. 같은 스레드의 다른 댓글은 기업 환경에서 통합 billing이 bureaucracy를 줄인다고 말했습니다.

반대편 댓글도 실무적입니다. 한 사용자는 scale이 커지면 1st-party API로 옮기는 편이 가격과 직접 통합 면에서 낫다고 주장했습니다. 또 다른 논의는 provider별 prompt cache hit rate였습니다. Kimi K2.6에서 Cloudflare 경로의 cache rate가 80-90% 범위에 자주 있다는 댓글이 있었습니다. 특정 모델 조합에서는 0%에 가까운 cache가 보인다는 반박과 DeepSeek V4에서 caching이 꼬일 수 있다는 지적도 이어졌습니다. 에이전트는 긴 conversation history를 반복해서 넣기 때문에 cache hit rate가 청구 금액을 크게 바꿉니다. 모델 라우터의 품질은 응답 성공 여부만이 아니라 prefix cache를 얼마나 유지하느냐까지 포함합니다.

데이터 경계 논쟁도 빠지지 않았습니다. HN의 일부 사용자는 무료 모델이나 aggregator 경로를 쓸 때 입력과 출력이 training database로 들어갈 가능성을 걱정했습니다. 다른 사용자는 OpenRouter traffic이 여러 end user, 여러 system prompt, 여러 model 호출이 섞인 stream이어서 training material로 바로 쓰기 어렵다고 반박했습니다. 또 다른 댓글은 model distillation이나 usage analytics 관점에서는 여전히 가치가 있을 수 있다고 지적했습니다. 이 논쟁은 OpenRouter 하나의 문제가 아닙니다. AI gateway는 프롬프트와 응답, tool output, 코드 조각, 검색 결과가 지나가는 위치이기 때문입니다.

보안팀이 봐야 할 지점은 API key의 blast radius입니다. 한 key로 400개 이상 모델에 접근할 수 있다는 말은 개발 경험을 단순하게 만듭니다. 동시에 key가 frontend에 새거나 로그에 남거나 CI secret에서 탈취되면 호출 가능한 범위도 커집니다. 그래서 OpenRouter가 말한 spend management와 Workspaces는 편의 기능이 아니라 위험 제한 기능입니다. 팀별 key scope, 월별 budget, per-key cap, model allowlist, audit log가 없다면 model gateway는 조직의 모든 AI 비용이 빠져나가는 넓은 문이 됩니다.

프라이버시도 zero-data-retention label 하나로 끝나지 않습니다. 어떤 요청이 OpenRouter에 저장되지 않는지, upstream provider에는 어떤 정책으로 전달되는지 확인해야 합니다. abuse monitoring이나 billing analytics에는 어떤 metadata가 남는지, enterprise workspace와 free model route의 정책이 다른지도 따로 봐야 합니다. 고객 PII, 의료·금융 데이터, source code, unpublished research를 다루는 팀은 "모델이 train에 쓰지 않는다"와 "gateway가 무엇을 log로 남긴다"를 분리해서 읽어야 합니다. 에이전트는 tool 결과와 내부 문서를 붙여 넣기 때문에 이 차이가 더 커집니다.

비용 관측성에서는 billing cap이 HN에서 좋은 평가를 받은 이유를 볼 수 있습니다. Metered API는 악용되거나 loop가 돌면 하룻밤에 큰 청구서를 만들 수 있습니다. 에이전트는 특히 위험합니다. 실패한 test를 계속 고치려 하거나, retrieval 결과가 중복되어 context가 커지거나, browser automation이 같은 페이지를 반복 처리하면 토큰이 빠르게 늘어납니다. per-key limit과 refill 정책은 개발자 경험보다 incident containment에 가깝습니다. OpenRouter의 장점이 단일 endpoint라면, 그 endpoint는 budget circuit breaker도 가져야 합니다.

캐시와 라우팅은 다음 비용 축입니다. Prompt caching이 작동하면 긴 system prompt와 repository summary를 반복 호출하는 에이전트 비용이 줄어듭니다. 하지만 cache는 provider, model, prefix 안정성, request routing에 따라 달라집니다. 라우터가 매번 다른 upstream instance나 provider로 요청을 보내면 cache hit rate가 낮아질 수 있습니다. 반대로 라우터가 provider 상태와 cache 정보를 잘 활용하면 직접 호출보다 더 나은 경로를 고를 수도 있습니다. HN에서 cache hit rate가 토론된 이유는 이 차이가 이론이 아니라 실제 비용 차이로 나타나기 때문입니다.

기능 호환성도 확인해야 합니다. OpenAI-compatible API는 많은 도구와 SDK를 빨리 붙이는 데 유리합니다. 그러나 model provider마다 tool calling, structured output, reasoning control, image input, audio output이 다릅니다. safety refusal와 token accounting도 공급자별 차이가 납니다. 같은 request schema로 보낸다고 같은 의미의 응답이 돌아오지는 않습니다. 예를 들어 code review agent가 JSON schema를 꼭 지켜야 한다면 fallback 모델의 structured output 실패율이 제품 장애가 됩니다. 고객지원 agent가 refund 승인 같은 결정을 한다면 모델별 policy 차이가 직접적인 사업 리스크가 됩니다.

OpenRouter의 이번 투자는 Vercel AI Gateway, LiteLLM, Portkey, WaveSpeed, cloud provider gateway와 같은 범주의 경쟁을 더 선명하게 만듭니다. 차이는 출발점입니다. Cloud provider는 이미 compute, identity, network, compliance 계약을 가지고 있습니다. Vercel은 web app 배포와 AI SDK surface에 붙습니다. LiteLLM은 open-source proxy와 self-hosting 쪽 강점이 있습니다. WaveSpeed는 LLM과 생성형 미디어 모델을 한 platform으로 묶는 방향을 택했습니다. OpenRouter는 marketplace, ranking, multi-provider billing, 모델 선택의 낮은 friction에 강합니다.

이 시장에서 승부는 모델 수만으로 나지 않습니다. 모델 수는 금방 commodity가 됩니다. 더 오래 남는 기준은 latency 분포, upstream 장애 대응, per-model feature parity, enterprise logging, 데이터 보관 옵션입니다. budget guardrail, cache efficiency, pricing transparency도 같은 목록에 들어갑니다. 개발팀은 dashboard에서 모델을 고르는 순간보다 장애가 났을 때 더 많은 것을 배웁니다. Anthropic API가 느려질 때 어떤 모델로 넘겼는지, 그 fallback이 tool call을 깨뜨렸는지, 비용 cap에 닿았을 때 어떤 요청을 거절했는지가 제품 신뢰를 좌우합니다.

OpenRouter가 발표한 "quality-aware routing"은 그래서 조심해서 읽어야 합니다. 품질은 일반 benchmark 점수만으로 측정되지 않습니다. 코딩 에이전트의 품질은 test pass, patch size, reviewability, repository convention 준수로 봐야 합니다. 고객지원 agent의 품질은 escalation rate, refund error, policy violation, 평균 처리 시간으로 봐야 합니다. 라우터가 정말 quality-aware가 되려면 provider 상태와 함께 각 팀의 업무별 평가 신호를 받아야 합니다. 그렇지 않으면 "좋은 모델"이라는 추상 점수만 route decision에 남습니다.

그래도 이번 발표가 개발자에게 주는 실용적 결론은 분명합니다. 첫째, 모델 라우팅은 이제 side project용 편의 계층이 아닙니다. 25조 주간 토큰이라는 수치는 aggregator 경로가 production traffic의 일부가 됐다는 근거입니다. 둘째, AI 앱의 architecture review에는 model gateway 질문을 넣어야 합니다. 어떤 데이터가 지나가는지, 어떤 key가 어떤 모델을 부를 수 있는지 확인해야 합니다. 비용 한도는 어디서 걸리는지, fallback 결과는 어떻게 검증하는지도 같은 review 항목입니다. 셋째, provider 직접 계약과 gateway 사용은 둘 중 하나만 고르는 문제가 아닙니다. 고위험·대량 traffic은 직접 경로로, 실험·long tail 모델·비교 평가는 gateway로 나누는 hybrid pattern이 현실적입니다.

OpenRouter Series B는 모델 회사가 아닌 라우팅 회사에 붙은 표입니다. 이 표는 AI 인프라의 병목이 "모델이 있느냐"에서 "모델을 어떻게 안전하고 싸게, 끊기지 않게 쓰느냐"로 옮겨 갔다는 투자자의 판단을 담고 있습니다. 에이전트 제품을 만드는 팀이라면 이번 숫자를 funding news로만 넘기기 어렵습니다. 앞으로 비용 초과 incident, provider 장애, cache miss, data retention 질문은 모델 선택 뒤의 운영 계층에서 더 자주 터질 것입니다. OpenRouter가 받은 1억1300만 달러는 그 계층이 독립 시장으로 인정받고 있다는 현재 시점의 증거입니다.