Stripe가 10조 원을 주고 산 것은 '라우터'가 아니라 'AI 결제의 관문'이었다

한눈에 보는 핵심 요약

결제 회사 Stripe가 AI 모델 라우팅 서비스 OpenRouter를 인수했습니다. 정확한 금액은 공개되지 않았지만, Bloomberg는 인수가를 70억 달러 이상(약 10조 원) 으로 보도했는데요. 이는 불과 몇 달 전 Series B에서 인정받았던 13억 달러 기업가치의 5배가 넘는 숫자입니다.

왜 결제 회사가 갑자기 LLM 라우터를 이렇게 비싸게 샀을까요? 표면적인 기능만 보면 설명이 잘 안 됩니다. 하지만 안을 들여다보면, Stripe가 산 것은 '코드'가 아니라 AI 시장 그 자체로 통하는 관문이라는 게 보입니다.

OpenRouter, 원래 뭐 하던 곳이야?

OpenRouter는 2023년 초, "하나의 모델이 모든 작업에서 이길 수는 없다"는 아이디어에서 출발했습니다. 처음부터 자체 모델을 만들거나 파는 회사가 아니라, 수많은 모델과 개발자를 연결하는 중립적인 유통 계층을 지향했죠.

2024년 6월 긱뉴스에도 소개된 바 있는데, 그때 이미 지금과 같은 핵심 구조를 갖추고 있었습니다.

• 하나의 표준 API로 여러 모델을 호출
• 가격과 출력 속도를 비교해 최적 모델 선택
• 같은 모델을 제공하는 여러 추론 공급자 사이의 로드밸런싱
• 어떤 모델이 어떤 앱/작업에 쓰이는지 보여주는 데이터
• 개발자와 모델 공급자를 잇는 마켓플레이스

2년 만에 지원 모델은 400개 이상, 하루 처리 토큰은 10조 개 이상, 이용자는 1,000만 명 이상으로 성장했습니다. Stripe의 인수는 갑작스러운 방향 전환이 아니라, 처음부터 그리던 그림이 무시할 수 없는 규모에 도달한 결과인 셈입니다.

겉보기엔 '통합 API', 속을 보면 다섯 가지 역할

"여러 LLM을 하나의 API로 호출한다"는 설명 안에는 사실 서로 다른 다섯 가지 역할이 섞여 있습니다.

1. 통합 인터페이스 — OpenAI, Anthropic, Google 등 제각각인 API 형식을 하나로 통일
2. 트래픽 제어 — 장애·속도 저하·한도 초과 시 다른 공급자로 자동 전환
3. 운영 통제 — 요청 기록, 예산, 레이트 리밋, 데이터 보존, 감사 로그 관리
4. 모델 선택 — 작업 성격·비용·품질을 판단해 최적 모델 결정
5. 마켓플레이스 — 여러 모델·공급자의 사용량을 한 계정, 하나의 청구서로 정산

이 중 앞의 두 가지(통합 인터페이스, 트래픽 제어)는 LiteLLM, Bifrost 같은 오픈소스로도 충분히 대체 가능합니다. 즉, 라우터 코드 자체는 희소하지 않습니다. 진짜 희소한 건 뒤의 세 가지, 특히 마켓플레이스로서 쌓인 데이터와 관계망입니다.

'모델 선택'과 '공급자 선택'은 다른 문제

LLM 라우팅에는 사실 두 가지 다른 질문이 숨어 있습니다.

• 같은 모델을 어느 공급자에게 보낼까? — 같은 모델도 여러 추론 공급자가 서비스하고, 가격·속도·가동시간·도구 호출 신뢰성이 제각각입니다.
• 어떤 모델이 이 작업을 맡아야 할까? — 작은 모델이 싸다고 무조건 이득은 아닙니다. 도구 호출을 여러 번 실패하면 오히려 전체 비용이 커지고, 대화 중 모델을 바꾸면 프롬프트 캐시도 날아갈 수 있죠.

그래서 라우팅은 '최저가 검색'이 아니라 작업을 끝내는 데 드는 총비용·품질·지연시간·실패확률을 함께 저울질하는 문제입니다. OpenRouter의 Auto Router가 이걸 자동화하고, 한발 더 나아간 Fusion API는 여러 모델을 병렬로 호출한 뒤 별도 심판 모델이 결과를 종합하는 오케스트레이션까지 시도하고 있습니다.

진짜 자산은 '시장' 그 자체

API 프록시 코드는 누구나 만들 수 있습니다. 하지만 OpenRouter 같은 마켓플레이스는 하루아침에 복제가 안 됩니다.

• 수백 개 모델의 가격·기능 변경을 계속 추적
• 여러 추론 공급자와 용량·가격·정산 조건 협의
• 실제 트래픽에서 장애·지연·처리량 측정
• 수백만 개발자의 수요를 새 모델·공급자와 연결

사용자가 없으면 공급자가 들어올 이유가 없고, 공급자가 없으면 개발자가 모일 이유도 없는 닭과 달걀 문제입니다. 이미 양쪽을 다 모아놓은 OpenRouter에는 강력한 네트워크 효과가 생겼죠.

실제로 OpenRouter 자체 리포트(100조 토큰 분석)를 보면 흥미로운 패턴이 나옵니다.

• 가격이 10% 낮아져도 사용량 증가는 약 0.5~0.7%에 불과 — 가격 민감도가 생각보다 낮음
• Gemini 2.5 Pro, Claude 4 Sonnet의 초기 사용자 중 약 40%가 5개월 뒤에도 잔류 — 더 싼 모델이 나와도 '모델-워크로드 적합성' 때문에 잘 안 옮겨감

즉 OpenRouter는 벤치마크가 아니라 실제 시장에서 어떤 모델이 어떤 작업에 계속 선택되는지를 관찰할 수 있는 유일한 위치에 있었던 겁니다. 이게 Stripe가 높은 값을 치른 진짜 이유로 보입니다.

Stripe는 왜 이걸 원했나: '결제의 앞단'으로 이동

Stripe는 지금까지 '거래가 이미 결정된 뒤'의 일을 처리해왔습니다. 사용량 측정, 가격 계산, 청구, 세금, 사기 탐지, 환불, 공급자 정산 같은 것들이죠. (사용량 기반 과금 업체 Metronome 인수로 AI 특유의 복잡한 토큰 과금 처리 역량도 이미 확보한 상태였습니다.)

OpenRouter는 그보다 한 단계 앞, 즉 애초에 어떤 모델·공급자의 사용량이 발생할지 결정하는 지점에 있습니다. 둘이 합쳐지면 다음 흐름이 하나의 시스템으로 이어집니다.

모델 선택 → 공급자 선택 → 사용량 측정 → 가격 적용 → 고객 청구 → 공급자 정산

마치 예전에 Stripe가 "카드 네트워크·은행을 직접 연결할 필요 없이 하나의 API로 결제하게" 만들었던 것처럼, 이제는 "수백 개 모델 회사·추론 공급자와 직접 계약할 필요 없이 하나의 API로 AI를 쓰게" 만드는 구조를 완성하려는 셈입니다. OpenRouter가 오랫동안 'LLM을 위한 Stripe'라고 불렸는데, 이제 정말 Stripe 안으로 들어온 거죠.

여기에 Stripe가 이미 진행 중인 Stripe Projects(에이전트가 스스로 Cloudflare 계정을 만들고 도메인을 사고 배포하게 하는 서비스)까지 더하면, "에이전트가 필요한 모델을 고르고 쓰고 그 비용까지 Stripe 안에서 자동 정산되는" 그림이 그려집니다.

그래서 주의 깊게 봐야 할 지점

토큰은 이미 거래 가능한 자원이 되어가고 있습니다. 쓰지 않은 크레딧을 되파는 브로커, 여러 계정·API 키를 묶어주는 릴레이 서비스까지 등장했는데, 이 중에는 무료 계정 남용이나 도난 카드 같은 위험 요소가 섞여 있을 가능성도 있죠.

그래서 신뢰할 수 있는 게이트웨이라면 편의성 못지않게 다음을 담보할 수 있어야 합니다.

• 모델·크레딧의 출처
• 공급자의 실제 성능
• 요청·응답의 데이터 정책
• 사용량·가격의 정확성
• 장애 시 대체 경로
• 사기·악용에 대한 책임

OpenRouter도 공식 인수 발표에서 "AI 기업의 사기·악용 대응이 점점 어려워지고 있다"며 Stripe의 대응 역량을 합류 이유로 꼽았습니다. 글로벌 결제망에서 거래 출처와 위험을 관리해온 노하우가, 이제는 모델 유통망에도 필요해진 셈입니다. 다만 모든 요청이 한곳으로 모이는 만큼, 게이트웨이 자체가 새로운 단일 장애점이자 집중 위험 지점이 된다는 점도 함께 따라오는 숙제입니다.

---

원문: https://news.hada.io/article/openrouter-is-not-just-a-proxy