OpenRouter가 Stripe에 합류한다고 발표함
정확한 거래 가격은 공개되지 않았지만 Stripe의 OpenRouter 인수 합의에서 Bloomberg는 인수 금액을 70억 달러 이상(약 10조 원)으로 보도했음
불과 몇 달 전 1억 1,300만 달러 Series B에서 인정받은 13억 달러 기업가치의 5배가 넘음
OpenRouter는 400개 이상의 AI 모델을 하나의 API로 제공하고, 하루 10조 개 이상의 토큰을 처리하며, 1,000만 명이 넘는 개발자와 기업이 이용하는 서비스
설립 이후 추론 처리량은 매년 최소 10배씩 성장해 왔다고 밝힘
표면적으로는 서로 다른 모델 API를 하나로 묶어주는 게이트웨이임
하지만 API 형식을 통일하고 장애가 나면 다른 모델로 넘기는 소프트웨어만으로는 이 가격을 설명하기 어려움
비슷한 기능을 제공하는 오픈소스와 상용 서비스가 이미 많고, 직접 만드는 것도 불가능한 일은 아니기 때문
Stripe가 확보하려는 것은 라우터 코드보다 어떤 작업에 어떤 모델이 선택되고, 어느 공급자가 실제 요청을 처리하며, 그 사용량이 어떻게 비용과 매출로 바뀌는지 연결하는 시장의 관문에 가까움
150개 모델을 연결하던 서비스에서 시장의 관문으로
OpenRouter는 2023년 초 하나의 모델이 모든 작업에서 승리하지는 않을 것이라는 생각에서 출발함
2024년 6월에는 당시 OpenRouter에서 근무했던 개발자가 OpenRouter (오픈라우터): 통일된 LLM 인터페이스와 마켓플레이스를 긱뉴스 Show GN에 직접 소개함
당시 OpenRouter가 연결하던 모델은 150개 이상
이미 지금과 같은 핵심 구조를 갖추고 있었음
- 하나의 표준 API로 여러 모델 호출
- 가격과 출력 속도를 비교해 모델 선택
- 동일한 모델을 제공하는 여러 추론 공급자 사이의 로드밸런싱
- 어떤 모델이 어떤 앱과 작업에 사용되는지 보여주는 데이터
- 개발자와 모델 공급자를 연결하는 마켓플레이스
이 초기 소개에서 중요한 것은 OpenRouter가 처음부터 특정 모델을 개발하거나 판매하는 회사가 아니었다는 점
모델이 계속 늘어나고 최적의 선택도 계속 달라질 것이라는 전제 위에서, 선택과 유통을 담당하는 중립적인 계층을 만들고 있었음
2년 뒤 지원 모델은 400개 이상으로 늘었고, 하루 10조 개 이상의 토큰과 1,000만 명이 넘는 개발자와 기업이 이 계층을 이용하게 됨
Stripe의 인수는 OpenRouter가 그동안 해오던 사업에서 다른 방향으로 전환한 결과가 아님
2024년 소개 글에 이미 있던 통합 인터페이스, 라우팅, 사용량 데이터, 마켓플레이스가 빠르게 성장해, 결제와 정산 인프라를 가진 Stripe가 무시하기 어려운 규모에 도달한 것
하나의 API 뒤에 섞여 있는 다섯 가지 역할
여러 LLM을 하나의 API로 호출한다는 설명 아래에는 서로 다른 역할이 섞여 있음
- 통합 인터페이스
- OpenAI, Anthropic, Google처럼 서로 다른 API 형식과 스트리밍 응답을 하나로 통일
- 트래픽 제어
- 장애, 속도 저하, 사용 한도 초과가 발생하면 다른 공급자나 모델로 전환
- 운영 통제
- 요청 기록, 예산, 레이트 리밋, 데이터 보존 정책, 가드레일, 감사 로그 관리
- 모델 선택
- 작업의 성격과 비용, 품질을 판단해 어떤 모델을 사용할지 결정
- 마켓플레이스
- 여러 모델과 추론 공급자의 사용량을 한 계정에서 구매하고 하나의 청구서로 정산
이 가운데 통합 인터페이스와 트래픽 제어를 대신할 수 있는 도구는 이미 많음
LiteLLM, Bifrost - 초고속 엔터프라이즈 AI 게이트웨이, GoModel - Go로 작성된 고성능 AI 게이트웨이은 주로 회사 안에서 직접 운영하는 통합 API 프록시로, 자신이 보유한 API 키를 연결하고 로그, 예산, 장애 대응을 직접 통제하기 위한 도구
OmniRoute — 흩어진 무료/저가 AI 티어를 하나로 묶는 게이트웨이는 이미 구독한 서비스와 무료 티어, 저가 API를 하나의 예산처럼 묶어 소진하는 데 초점을 둠
국내 회사인 Cafe24가 공개한 LLM Router는 여러 모델을 통합하면서 원화 결제, 세금계산서, 국내 기업의 운영 편의까지 함께 제공하는 관리형 서비스
OpenRouter는 여기에 모델 카탈로그, 추론 공급자 네트워크, 크레딧, 결제, 라우팅 데이터를 모두 결합함
모델 가격은 그대로 전달하고 크레딧 구매액에 5.5%의 수수료를 붙이는 구조로, 단순 프록시보다 모델 사용량이 거래되는 마켓플레이스에 가까움
모델을 고르는 것과 공급자를 고르는 것은 다름
LLM 라우팅에는 서로 다른 두 가지 문제가 있음
첫 번째는 같은 모델을 어느 공급자에게 보낼 것인가
하나의 모델도 여러 추론 공급자가 서비스할 수 있고 공급자마다 가격, 속도, 가동시간, 데이터 보존 정책, 도구 호출 신뢰성이 달라짐
OpenRouter는 장애가 발생한 공급자를 피하고, 가격이나 처리 속도를 기준으로 요청을 분산하며, 도구 호출에서는 실제 요청에서 측정한 성공률까지 반영함
두 번째는 어떤 모델이 이 작업을 처리해야 하는가
간단한 분류에는 작은 모델이 충분하지만 복잡한 코딩이나 추론에는 더 비싼 모델이 필요할 수 있음
작은 모델이 싸더라도 도구 호출을 여러 번 실패하면 전체 작업 비용은 오히려 커질 수 있음
대화 중 모델을 바꾸면 응답 성격이 달라지고 기존 프롬프트 캐시를 활용하지 못할 수도 있음
그래서 라우팅은 단순한 최저가 검색이 아님
한 번의 호출 가격이 아니라 작업을 끝내는 데 필요한 전체 비용과 품질, 지연 시간, 실패 확률을 함께 판단하는 문제
OpenRouter의 Auto Router는 프롬프트의 작업 유형과 난이도를 분석해 모델을 선택하고, 같은 모델 안에서는 다시 공급자의 가격과 가동시간, 성능을 비교함
모델이 늘고 에이전트가 장시간 작업할수록 이 두 단계의 선택이 더 중요해지는 구조
OpenRouter Fusion API는 여기서 한 단계 더 나아감
하나의 모델을 고르는 대신 여러 모델을 병렬로 호출하고, 별도의 심판 모델이 합의와 모순, 사각지대를 정리해 최종 답변을 만듦
라우터가 요청을 전달하거나 적합한 모델 하나를 선택하는 데서 끝나지 않고 여러 모델을 하나의 작업에 배치하고 결과를 종합하는 오케스트레이션 계층으로 확장되는 사례
이런 방식에서는 사용자가 한 번 요청해도 내부에서는 여러 모델 호출과 비용이 발생함
어떤 모델을 몇 번 호출했는지 측정하고 하나의 가격으로 만들어 청구하는 일이 더 복잡해지므로, 라우팅과 사용량 과금이 결합될 이유도 커짐
라우터 코드는 만들 수 있지만 시장은 바로 만들 수 없음
OpenAI 호환 API와 폴백 로직을 구현하는 일 자체는 어려운 문제가 아님
실제로 수많은 오픈소스 게이트웨이가 비슷한 기능을 제공함
하지만 OpenRouter와 같은 시장을 만드는 것은 다른 문제
- 수백 개 모델의 가격과 기능 변경을 계속 추적
- 여러 추론 공급자와 용량, 가격, 정산 조건을 협의
- 공급자별 응답 형식과 도구 호출 차이를 보정
- 장애, 지연 시간, 처리량을 실제 트래픽에서 측정
- 기업 고객의 예산, 로그, 보안, 데이터 정책 지원
- 수백만 개발자의 수요를 새로운 모델과 공급자에게 연결
새로운 모델이 나와도 사용자가 없으면 공급자가 들어올 이유가 없고, 공급자가 부족하면 개발자가 모일 이유도 없음
이미 양쪽이 모인 OpenRouter에는 마켓플레이스의 네트워크 효과가 생김
OpenRouter가 축적한 데이터의 가치는 자사 보고서인 OpenRouter의 AI 현황 보고서 : 100조 토큰 실증 연구에서도 드러남
다만 OpenRouter를 통과한 트래픽만 본 부분적 시야이며, 기업 내부 배포와 로컬 호스팅은 범위 밖이라는 한계를 보고서 스스로 밝히고 있음
이 데이터에서는 단일 모델이 모든 영역을 지배하지 않았고 오픈 모델과 폐쇄형 모델이 서로 다른 작업에서 선택됨
가격이 10% 낮아져도 사용량 증가는 약 0.5~0.7%에 그쳐 가격과 사용량의 상관관계도 예상보다 약했음
Gemini 2.5 Pro와 Claude 4 Sonnet의 일부 초기 사용자 집단은 5개월 뒤에도 약 40%가 남아 있었음
더 저렴한 모델이 나와도 특정 모델이 먼저 해결한 워크로드에서는 사용자가 계속 머무르는 모델-워크로드 적합성이 나타난 것
OpenRouter는 어떤 모델이 더 뛰어난지를 벤치마크로만 추정하는 것이 아니라, 실제 시장에서 어떤 모델이 어떤 작업에 선택되고 계속 사용되는지를 관찰할 수 있는 위치에 있음
API 코드는 복제할 수 있지만 수요와 공급, 실제 운영 기록, 모델-워크로드 적합성, 결제량이 한곳에 모인 상태는 같은 규모의 트래픽 없이 만들기 어려움
Stripe가 높은 가격을 지불한 이유도 이 부분에서 찾을 수 있음
Stripe는 결제의 앞단으로 이동하고 있음
Stripe는 지금까지 거래가 결정된 뒤의 과정을 처리해 왔음
- 사용량 측정
- 가격 계산
- 청구와 결제
- 세금
- 사기 탐지
- 환불과 분쟁 처리
- 공급자 정산
Stripe는 사용량 기반 과금 업체 Metronome 인수를 완료해 AI 제품의 복잡한 토큰 과금과 기업별 계약을 처리하는 기능도 확보함
OpenRouter는 이보다 한 단계 앞에서 어떤 모델과 공급자의 사용량이 발생할지 결정함
개발자가 OpenRouter에서 모델을 호출하면 요청을 처리할 모델과 공급자가 선택되고 사용량이 측정됨
그 사용량에는 가격이 붙고, 고객에게 청구되며, 실제 돈이 공급자에게 정산됨
Stripe와 OpenRouter가 합쳐지면 다음 흐름이 하나의 시스템 안에서 연결될 수 있음
모델 선택 → 공급자 선택 → 사용량 측정 → 가격 적용 → 고객 청구 → 공급자 정산
Stripe가 결제에서 했던 일과도 닮아 있음
사용자가 카드 네트워크와 은행을 직접 연결하지 않아도 하나의 API로 결제를 처리하게 만들었듯, 개발자가 수백 개 모델 회사와 추론 공급자를 직접 계약하지 않아도 하나의 API로 이용하게 만드는 구조
OpenRouter가 오랫동안 LLM을 위한 Stripe라고 불렸는데, 이제는 실제 Stripe 안으로 들어온 셈
Stripe는 이미 Stripe Projects를 통해 에이전트가 Cloudflare 계정을 만들고, 도메인을 구매하고, 배포할 수 있게 했음
에이전트가 필요한 서비스를 찾으면 Stripe가 신원과 결제를 연결하고, 공급자는 계정과 사용 권한을 자동으로 준비함
사람이 서비스마다 계정을 만들고 API 키와 결제 수단을 직접 연결하던 과정을 서비스 선택 → 권한 부여 → 결제라는 하나의 흐름으로 만든 것
여기에 OpenRouter가 들어오면 서비스 카탈로그 옆에 모델 카탈로그가 놓임
에이전트가 필요한 모델을 선택하고 사용한 뒤, 발생한 비용까지 Stripe 안에서 처리하는 그림이 가능해짐
토큰은 이미 거래 가능한 자원이 되고 있음
AI 크레딧 재판매 시장 - 토큰 브로커와 Relay는 어떻게 움직이나를 보면 모델 사용량은 이미 단순한 API 호출을 넘어 거래 가능한 자원처럼 움직이기 시작함
스타트업이 사용하지 못한 크레딧을 되파는 Broker가 등장했고, 여러 계정과 API 키를 묶어 하나의 Endpoint로 제공하는 Relay도 형성됨
공식 가격보다 크게 싼 크레딧 중에는 무료 계정 남용, Chargeback, 도난 카드, 약관을 우회한 계정이 섞여 있을 가능성도 있음
이 시장이 보여주는 것은 값싼 토큰의 존재만이 아님
누가 제공한 모델인지, 실제로 요청한 모델이 맞는지, 프롬프트와 응답을 누가 볼 수 있는지, 비용이 누구에게 정산되는지도 함께 중요해짐
신뢰할 수 있는 게이트웨이라면 API 편의성과 함께 다음 항목을 확인할 수 있어야 함
- 모델과 크레딧의 출처
- 공급자의 실제 성능
- 요청과 응답의 데이터 정책
- 사용량과 가격의 정확성
- 장애 시 대체 경로
- 사기와 악용에 대한 책임
OpenRouter도 공식 인수 발표에서 AI 기업이 해결해야 할 사기와 악용 문제가 더 어려워지고 있으며, Stripe의 대응 역량을 합류의 중요한 이유로 제시함
글로벌 결제망에서 거래의 출처와 위험을 관리해 온 Stripe의 경험이 모델 유통망에도 필요하다고 본 것
게이트웨이는 편리하지만 새로운 집중 지점이기도 함
모든 요청을 한곳으로 모으면 운영은 쉬워지지만 위험도 함께 집중됨
게이트웨이는 모델 회사의 API 키, 프롬프트와 응답, 비용, 사용자별 사용 기록을 다룰 수 있음
잘못된 라우팅은 예상보다 비싼 모델을 호출하거나 요청한 것과 다른 모델의 결과를 돌려줄 수도 있음
셀프 호스팅도 자동으로 안전한 것은 아님
LiteLLM 공급망 공격 대응 기록에서는 악성 PyPI 패키지가 설치되면서 SSH 키와 클라우드 인증 정보, 환경 변수까지 탈취하려 한 일이 발생함
민감한 API 키를 한곳에 모으는 게이트웨이일수록 배포 경로와 의존성, 접근 권한을 더 엄격하게 관리해야 한다는 사례
LLM 게이트웨이를 선택할 때는 기능 목록보다 다음 질문이 중요함
- 모델과 공급자가 실제로 어떻게 선택됐는지 확인할 수 있는가
- 특정 공급자와 모델만 허용할 수 있는가
- 프롬프트와 응답이 저장되거나 학습에 사용되는가
- 비용과 실패율을 요청 단위로 추적할 수 있는가
- 게이트웨이에 장애가 나면 직접 공급자로 우회할 수 있는가
- 다른 게이트웨이로 옮길 수 있는 표준 인터페이스를 유지하는가
게이트웨이는 공급자 종속을 줄여주지만, 라우팅 규칙과 로그, 예산 관리까지 깊게 사용하면 게이트웨이 자체가 새로운 종속 지점이 될 수 있음
인수 이후 가장 중요한 것은 중립성
OpenRouter는 Stripe에 합류한 뒤에도 이름과 제품, 기존 연동 방식과 로드맵을 유지하고 특정 모델이나 공급자를 우대하지 않겠다고 밝힘
이 약속은 단순한 운영 방침이 아니라 OpenRouter의 핵심 자산
개발자가 OpenRouter를 이용하는 이유는 특정 모델을 더 많이 팔기 위해서가 아니라, 여러 모델 가운데 자신에게 유리한 선택을 할 수 있다고 믿기 때문
공급자 역시 공정하게 경쟁할 기회를 얻을 수 있다는 전제에서 플랫폼에 참여함
Stripe가 과금과 정산까지 담당하게 되면 이 중립성은 더 민감한 문제가 됨
- 기존 플랫폼 수수료가 유지되는가
- BYOK 조건이 달라지는가
- 특정 공급자나 Stripe와 계약한 모델이 유리해지는가
- 라우팅 결과와 기준을 사용자가 확인할 수 있는가
- 모델 사용 정보와 결제 정보가 어디까지 결합되는가
- 독립적인 신규 공급자가 계속 들어올 수 있는가
인수 전에는 중립성이 회사의 독립성으로 어느 정도 설명됐지만, 이제부터는 실제 제품 동작과 공개된 데이터로 증명해야 하는 약속이 됨
Stripe가 베팅한 것은 다중 모델의 미래
이번 인수의 가치는 OpenRouter의 현재 매출만으로 설명하기 어려움
핵심은 앞으로도 하나의 모델이 시장 전체를 차지하지 않고, 여러 모델과 추론 공급자가 계속 경쟁할 것이라는 판단
모델이 많아질수록 개발자는 모든 업체와 직접 계약하기 어려워지고, 새로운 모델이 등장할 때마다 평가하고 연결하는 비용도 커짐
에이전트가 더 많은 작업을 수행하면 모델 호출량뿐 아니라 예산 관리, 실패 대응, 데이터 정책, 과금과 정산도 복잡해짐
이 세계에서는 가장 좋은 모델 하나를 가진 회사뿐 아니라 여러 모델 가운데 무엇을 사용할지 결정하는 계층도 강한 위치를 차지할 수 있음
반대의 가능성도 이미 OpenRouter의 데이터 안에 있음
자사 보고서에서 프로그래밍은 2025년 초 약 11%에서 50%를 넘는 최대 카테고리가 됐지만, 이 영역의 지출은 Anthropic Claude 시리즈가 60% 이상을 지속적으로 차지함
OpenRouter라는 다중 모델 플랫폼 안에서도 가장 큰 워크로드는 한 회사로 쏠릴 수 있다는 의미
검색 기반 응답이나 실시간 음성처럼 모델별로 대체하기 어려운 고유 기능이 늘어나는 것도 하나의 공통 API로 묶기 어렵게 만드는 요인
시장이 안정돼 소수의 모델만 남으면 여러 모델을 즉시 전환하는 가치도 줄어들고, 사용량이 큰 고객에게는 5.5%의 수수료가 공급자와 직접 계약할 이유가 될 수 있음
대형 고객이 공급자와 직접 계약하고 자체 게이트웨이를 운영한다면 OpenRouter의 중간 계층 가치는 더 약해질 수 있음
결국 Stripe의 70억 달러가 넘는 베팅은 OpenRouter 하나에 대한 판단이면서 동시에 AI 시장의 구조에 대한 판단
최고의 모델은 계속 바뀌고, 모델과 공급자는 계속 늘어나며, 그 사이를 연결하는 중립적인 거래 계층이 필요할 것이라는 판단
Stripe는 OpenRouter를 통해 모델 선택 → 사용량 측정 → 가격 적용 → 공급자 정산이 이어지는 시장의 자리를 확보하려 함
인수의 성패는 연결한 모델 수보다, 개발자에게 유리한 선택과 신뢰할 수 있는 거래를 함께 제공할 수 있는지에 달려 있음