AI 게이트웨이가 팔릴 때 제품이 받는 청구서

AI 모델 라우팅을 외부 게이트웨이에 위임하면 코드가 단순해진다. Stripe가 OpenRouter를 70억 달러에 인수하기로 했다는 소식은, 그 단순함이 어떤 대가를 치르는지 보여준다. 다만 "그냥 직접 API 쓰면 되잖아"도 방법을 잘못 선택하면 다른 형태의 의존성이 된다 — 이 차이가 생각보다 크다.

"Stripe for AI"가 진짜 Stripe에게 팔렸다

OpenRouter는 스스로를 "AI판 Stripe"라고 불렀다. 200개가 넘는 AI 모델을 단일 API로 라우팅해주는 게이트웨이 서비스다. GPT-4o를 쓰다가 Claude로 바꾸고 싶을 때 엔드포인트 URL 하나만 교체하면 된다. 모델 선택의 복잡성을 추상화해서, 제품팀이 "어디에 붙을 것인가"보다 "무엇을 만들 것인가"에 집중할 수 있게 해준다는 아이디어였다.

그 회사가 70억 달러, 한화로 약 9조 원에 Stripe에 인수되기로 했다.

아이러니가 제법 진하다. "AI의 Stripe"라고 불렀던 회사가 진짜 Stripe에 흡수된다. Stripe가 결제 레이어를 추상화해서 수백만 개발자 코드에 바꿀 수 없는 의존성으로 자리잡은 것처럼, OpenRouter는 AI 모델 레이어에서 그 위치를 노렸다. 전략이 충분히 효과를 발휘했기 때문에 9조 원짜리 인수 대상이 됐다. 하지만 이 소식을 제품팀 관점에서 읽으면, 축하보다 점검이 먼저다.

AI 게이트웨이가 실제로 쥐고 있는 결정들

OpenRouter 같은 게이트웨이가 제품에 끼면 겉으로는 "편리한 추상화"처럼 보인다. 실제로는 제품 결정의 일부를 위임하는 것이다.

어떤 모델이 카탈로그에 얼마나 빨리 올라오는가. 특정 모델 버전의 가격이 언제 어떤 방식으로 바뀌는가. 레이트 리밋 처리를 어떤 전략으로 하는가. 프롬프트 데이터가 어떤 경로로 흘러가는가. 이 결정들이 전부 게이트웨이 운영사의 영역이지, 내 제품팀의 영역이 아니다.

Stripe는 이미 OpenAI와 상당히 깊은 협력 관계를 쌓아왔다. OpenAI 에이전트와 Stripe 결제 인프라를 연결하는 공식 파트너십도 있다. OpenRouter가 Stripe 안에 들어가면, 어떤 모델이 먼저 최적화되고 어떤 파트너사의 모델이 우선적으로 카탈로그에 올라올지는 Stripe의 비즈니스 판단이 개입한다. 빅테크들이 AI 인프라 레이어를 잇달아 사들이는 방식이 바로 이것이다 — 인프라를 통해 생태계의 기울기를 조정한다.

구체적으로 시나리오를 그려보자. OpenRouter를 통해 Claude Sonnet을 쓰는 제품팀이 있다고 하자. Stripe 인수 이후, 특정 파트너 모델에 더 낮은 수수료를 적용하고 Anthropic 모델의 토큰당 가격에 마진 구조를 조정하기로 했다. 그 팀은 코드를 하나도 바꾸지 않았는데 비용 구조가 달라지고, 성능 특성이 미묘하게 달라진다. 사용자는 스택을 모른다. 답변 품질이 살짝 바뀐 것, 응답이 0.3초 느려진 것만 느낄 뿐이다.

우리가 외부 게이트웨이를 쓰지 않기로 한 이유

솔직히 처음엔 OpenRouter 같은 서비스가 꽤 매력적이었다. 우리 팀은 diet, insurance, money, pet 등 여러 사이트 봇을 동시에 운영한다. 사이트마다 적절한 모델이 다르다. 대량 콘텐츠 생성엔 빠르고 저렴한 모델이 낫고, 품질 판단이 필요한 검수 단계엔 더 강한 모델이 필요하다. 게이트웨이 하나에 위임하면 이 선택을 코드 밖으로 밀어낼 수 있었다.

근데 실제로 팀에서 직접 다뤄보니 문제가 따로 있었다. 라우팅 레이어가 하나 끼면 디버깅이 복잡해진다. 응답 지연이 모델 탓인지 게이트웨이 탓인지 분리가 안 된다. 우리 retry 로직이 기대하는 에러 형식과 게이트웨이가 반환하는 형식이 달라서 핸들링이 꼬이는 경우도 생겼다. 결정적으로, 우리 프롬프트와 응답이 제3자 인프라를 통과한다는 것 자체가 데이터 흐름 관점에서 불편했다.

그래서 /opt/common/claude_cli.py라는 얇은 래퍼를 직접 만들었다. Anthropic API를 직접 호출하되, retry 로직과 모델 식별자만 인자로 뽑아낸 구조다. 본문 생성엔 Haiku, 검수 판단엔 Sonnet 이상 — 이 라우팅이 코드 두 줄로 바뀐다. OpenRouter 없이, 외부 카탈로그 업데이트를 기다릴 필요 없이. Anthropic이 새 모델을 출시하면 우리가 직접 모델 ID를 넣으면 끝이다.

거창한 기술 결정처럼 말하면 과장이고, 사실 별 거 없다. 얇은 추상화 하나를 팀 안에 두기로 한 것이다. 근데 Stripe가 OpenRouter를 9조 원에 사들이는 뉴스를 보고 나면, 그 소소한 결정이 꽤 중요한 자율성을 지켜줬다는 게 느껴진다.

인수 이후 사용자가 받는 충격의 경로

제품팀이 AI 인프라 의존성을 이야기할 때 보통 "비용이 얼마나 오르냐"부터 본다. 실제 사용자 경험에 미치는 영향은 더 세밀한 경로로 전달된다.

우리 봇 구조를 예시로 쓰자면, Haiku로 초안을 쓰고 Sonnet이 검수해서 본문이 1500자 미만이면 재생성 또는 발행 차단하는 게이트가 있다. 이 두 모델의 성능 특성이 독자가 최종적으로 읽는 글 품질의 기저다. 만약 이 라우팅을 외부 게이트웨이에 위임했고, 인수 이후 그 게이트웨이가 Haiku 기본 버전을 조용히 이전 세대로 교체했다고 하자. 우리 1500자 게이트 통과율이 달라진다. 발행량이 줄거나, 기준에 아슬아슬하게 걸리는 글이 늘어난다.

독자는 "최근 글이 좀 이상하다"고 느낀다. 팀은 한동안 원인을 못 찾는다. 게이트웨이 안에서 무슨 일이 있었는지 직접 들여다볼 수 없으니까.

응답 지연도 비슷하다. OpenRouter가 특정 시간대에 트래픽 폭주로 부하를 받으면 그 지연이 우리 제품 사용자의 대기 시간으로 직결된다. 팀은 아무것도 안 건드렸는데 사용자가 느리다고 한다. 이 상황에서 할 수 있는 게 별로 없다.

이게 인프라 의존성이 제품 결정인 이유다. AI 게이트웨이 선택이 "어디서 API 쓸 것인가"처럼 느껴지지만, 실제로는 "사용자 경험의 어느 부분을 우리가 통제하고 어느 부분을 외주 줄 것인가"의 결정이다. 중간 레이어가 하나 늘어날 때마다, 우리 제품이 사용자에게 약속할 수 있는 것의 범위가 줄어든다.

지금 당장 할 수 있는 점검

OpenRouter를 현재 쓰고 있거나, 비슷한 AI 게이트웨이 서비스에 의존하고 있다면 세 가지를 해두는 게 낫다.

첫째, 모델 의존성 지도를 만든다. 제품의 각 기능이 어떤 모델에 의존하고, 그 모델의 어떤 성능 특성을 가정하고 있는지 명시해둔다. "요약 기능은 Claude Haiku, 최대 4096 토큰 입력을 가정한다"처럼 구체적으로. 모델이 교체됐을 때 어디서 무엇이 깨지는지 파악하려면 이게 먼저다.

둘째, 직접 API 경로를 병행 테스트해둔다. 지금 OpenRouter를 통해 특정 모델을 쓰고 있다면, 프로바이더 직접 API로 동일 요청을 날렸을 때 응답 품질과 지연 차이를 확인한다. 전환 경로를 미리 만들어두면 정책이나 가격이 바뀌었을 때 이동 비용이 크게 줄어든다.

셋째, 게이트웨이를 통과하는 데이터 내용을 점검한다. 사용자 개인정보나 민감 정보가 담긴 프롬프트가 게이트웨이를 거치고 있는지 확인한다. 인수 이후 데이터 정책은 Stripe 기준으로 재정의된다. 지금까지 괜찮았던 것이 바뀔 수 있다.

추상화 레이어를 직접 만드는 건 처음엔 귀찮아 보인다. 하지만 중간 레이어 하나가 9조 원에 팔리는 세상에서, 그 귀찮음이 제품 자율성을 지키는 가장 저렴한 보험이었다는 게 점점 분명해진다.

원문: AI News & Artificial Intelligence | TechCrunch