스트라이프, 오픈라우터 인수 합의…결제사가 AI 토큰 관문을 산 이유

스트라이프가 8월 19일 오픈라우터 인수에 합의했다. 거래가 끝났다는 얘기는 아니다. 스트라이프 발표와 오픈라우터 발표에서 확인되는 단계는 아직 ‘인수 합의’다.

양사는 거래액을 공개하지 않았다. 보도된 인수가를 확정된 숫자처럼 제목에 넣지 않은 이유다. 지금 눈여겨볼 대목은 가격보다 스트라이프가 왜 AI 모델 회사가 아닌 ‘모델 관문’을 골랐느냐에 있다.

400개 넘는 AI 모델이 오가는 관문

오픈라우터는 서로 다른 AI 모델을 한 인터페이스로 연결하는 게이트웨이다. 스트라이프는 80곳이 넘는 공급자의 400개 이상 모델을 지원한다고 밝혔다. 오픈라우터 쪽 설명으로는 하루 처리량이 10조 토큰을 넘는다. 개발자와 기업을 합친 이용자 공동체는 1천만 명 이상이다.

둘 다 회사가 공개한 운영 수치다. 독립 감사로 확인된 시장점유율은 아니다. 그래도 이번 거래의 성격은 선명하다. 결제회사가 모델 자체가 아니라, 모델을 고르고 호출하고 비용을 기록하는 길목을 택했다.

오픈라우터는 통상적인 종결 조건을 거쳐 거래가 몇 주 안에 마무리될 것으로 내다봤다. 지금 쓰는 제품과 연동 방식은 바뀌지 않는다는 설명도 내놨다. 같은 이름·제품·로드맵을 유지하겠다는 말은 약속이다. 결과로 확인된 건 아직 없다.

결제회사가 계산서의 반대쪽으로 넘어갔다

이번 일을 ‘스트라이프의 AI 진출’ 정도로 읽으면 반쪽이다. 스트라이프는 지금까지 기업이 고객에게 돈을 받는 쪽에 강했다. 오픈라우터를 품으면 AI 서비스를 운영하며 빠져나가는 토큰 비용까지 닿을 수 있다.

TechCrunch의 Julie Bort는 이 거래를 장부의 반대쪽, 곧 AI 지출 관리로 이동한 사례로 봤다. 스트라이프가 지난해 토큰 사용량 기반 청구를 위한 Token Billing을 내놓은 흐름과도 맞물린다.

AI 서비스의 손익은 매출만 봐서는 모른다. 같은 기능도 어떤 모델을 어느 공급자에서 불렀느냐에 따라 원가와 속도, 실패율이 달라진다. 고객에게 사용량대로 청구하면서 요청은 더 경제적이거나 안정적인 경로로 보낸다면, 매출과 원가를 한 흐름에서 다룰 수 있다.

결제 단추만으로는 이 구조가 보이지 않는다. 오픈라우터는 요청이 모델 비용으로 바뀌는 길목에 있다. 스트라이프는 AI 토큰의 ‘계량기와 교환대’를 산 셈이다.

진짜 자산은 자동 라우팅 버튼이 아니다

이름만 보면 오픈라우터는 프롬프트를 읽고 싼 모델을 자동으로 골라 주는 서비스처럼 들린다.

투자사인 Menlo Ventures의 Matt Murphy와 Deedy Das는 주력 제품을 라우터보다 AI 게이트웨이로 설명한다. 이용자 다수가 모델을 직접 고르되, 하나의 API와 청구 체계로 여러 모델을 쓰기 위해 들어온다는 얘기다.

긴 에이전트 작업에서는 첫 프롬프트만 보고 모델을 고르는 방식이 오히려 위험하다. 단순해 보이는 파일 찾기도 저장소 크기와 앞선 대화에 따라 작은 모델로 충분할 수도, 고성능 모델이 필요할 수도 있다. 초반 선택이 틀리면 뒤 단계의 오류와 재시도 비용이 함께 불어난다.

결국 오래 남을 자산은 자동 분기 버튼보다 통합 API와 운영 신호에 가깝다. 어떤 작업에 어떤 모델을 썼는지, 어느 공급자에서 지연이나 실패가 났는지 비교해야 품질을 지키면서 비용을 줄일 수 있다.

단, Menlo Ventures는 오픈라우터 투자사이며 이사와 이사회 옵서버로 참여한 이해관계자다. 이 글은 제품 가치를 읽는 해설로만 참고했다. 이들이 제시한 성장 수치나 향후 데이터 활용을 독립 검증된 사실로 옮기지는 않았다.

중립성은 인수 뒤에 증명된다

오픈라우터는 앞으로도 모든 모델을 동등하게 다루겠다고 약속했다. 라우팅은 이용자에게 가장 유리한 방향으로 결정한다는 입장이다. 스트라이프는 기초 모델을 직접 만드는 회사가 아니다. 모델 제조사가 게이트웨이를 사는 경우보다는 눈에 보이는 이해충돌이 적다.

그렇다고 중립성이 저절로 따라오지는 않는다. 결제와 모델 사용 비용이 한 사업자에게 모이면 가격 협상력과 추천 영향력도 커진다. 기본 라우팅의 기준, 특정 공급자에 붙는 할인이나 우선순위, 요청·비용 데이터의 쓰임을 이용자가 확인할 수 있어야 한다.

더구나 ‘가장 좋은 모델’은 하나로 정해지지 않는다. 가격, 응답 속도, 정확도, 데이터 보관 조건 중 무엇을 앞에 두느냐에 따라 답이 바뀐다. 중립 라우터라면 추천 결과와 함께 그 추천에 쓴 기준도 보여줘야 한다.

한국 개발팀은 연동보다 로그부터 볼 때다

거래가 끝나지 않은 지금, 기존 연동을 급히 바꿀 이유는 없다. 여러 모델을 쓰는 팀이라면 대신 이 네 가지를 남겨둘 만하다.

• 요청별 모델과 실제 공급자
• 입력·출력 토큰과 최종 비용
• 작업 유형별 성공률, 지연 시간, 재시도 횟수
• 오픈라우터 장애 때 쓸 직접 API 또는 대체 게이트웨이

이 기록이 있어야 인수 뒤 수수료나 라우팅 정책이 달라졌을 때 영향을 계산할 근거가 생긴다. 모델 이름만 저장하면 같은 모델을 어느 공급자가 처리했는지, 장애 전환이 비용과 품질에 어떤 차이를 냈는지 놓치기 쉽다.

처음부터 세 업체 API를 직접 붙여 차이를 살피려면 코딩하는 상인의 OpenAI·Claude·Gemini API 예제처럼 호출과 오류 처리를 나눠 두는 방법도 있다. 게이트웨이를 쓰더라도 대체 경로가 있어야 협상력과 복구력이 생긴다.

이번 인수에서 먼저 볼 숫자는 알려지지 않은 거래액이 아니다. 거래 종결 뒤 기본 라우팅 기준, 공급자 표시, 수수료와 데이터 처리 조건이 어떻게 달라지는지가 첫 확인 항목이다. 그대로라면 오픈라우터는 편리한 중립 관문으로 남는다. 흐려진다면 스트라이프가 산 것은 관문뿐 아니라 통행 방향을 정할 힘이었다는 뜻이다.