스트라이프의 메트로놈 인수에 비친 SW 아키텍처의 함정
학습 차원에서 틈틈이 해외 전문가들이 블로그나 미디어 그리고 책에서 쓴 글을 번역 또는 요약 정리하고 있습니다. 이번 포스팅도 그중 하나고요. 거칠고 오역된 부분이 있을 수 있습니다. 제대로 번역되지 않은 부분은 확인 주시면 반영토록 하겠습니다. 의미 전달이 애매한 문장은 삭제했습니다. 이번 글은 결제 스타트업 라고(Lago) CEO인 Anh-Tho Chuong이 X에 공유한 글을 정리한 것입니다.
2026년 1월 스트라이프가 메트로놈을 약 10억 달러에 인수했을 때, 대부분 사람들은 가격을 주목했다. 하지만 나는 보다 단순한 질문을 계속 되새겼다.: 왜 스트라이프가 직접 이걸 만들지 못했을까? 그들은 수천 명의 엔지니어를 보유하고 있다. 돈도 많다. 미터링 및 빌링(Metering and billing) 시스템은 말 그대로 스트라이프가 이미 하는 일과 가까운 분야다. 그런데도 스트라이프는 스트라이프 빌링의 단순한 확장이었어야 할 기능에 왜 10억 달러를 쏟아부었을까?
그 해답은 소프트웨어 아키텍처와 초기 설계 결정이 시간이 지남에 따라 어떻게 누적되는지에 대해 많은 것을 알려준다.
아키텍처의 함정
2018년 출시된 스트라이프 빌링은 당시 주류였던 SaaS 구독 모델을 위해 설계됐다. 핵심 가정은 간단했다: 사용량 데이터는 빌링 시스템에 전달되기전 미리 집계되어야 한다는 것이었다.
워크플로는 다음과 같다. API 호출당 과금하는 경우, 자체 인프라에서 원래(primitives) 이벤트를 수집한 후 청구 가능한 단위(예: “1월 중 10,000회 API 호출”)로 집계한다. 그런 다음 청구 주기가 종료되기 전에 해당 총계를 스트라이프 사용량 기록(Usage Records)API로 전송한다. 스트라이프는 전송된 집계 수치를 기반으로 청구서를 발행한다.
이는 2018년 당시 사용 사례에는 완벽히 부합했다. 기본 구독에 저장 공간이나 추가 사용자당 초과 요금이 부과되는 프로젝트 관리 SaaS 서비스였다. 내부적으로 사용량을 추적하고, 월별 총계를 스트라이프에 전송하면 청구가 완료됐다.
하지만 사용량이 부가 서비스가 아닌 비즈니스 모델 자체일 때는 이 아키텍처가 완전히 무너진다. 스트라이프는 수십억 개 원시 이벤트(raw events)를 처리하도록 설계되지 않았기 때문에 실시간 이벤트 수집이 불가능하다. 사용량이나 비용이 특정 임계값(threshold)을 초과할 때마다 청구서를 발행하는 방식은 프로그레시브 빌링(Progressive billing)은 시스템 전체가 월간 또는 연간 주기를 가정하기 때문에 먹혀들지 않는다.
고객이 월 중순에 1만 달러 한도를 초과해도 청구서가 발송되지 않는다. 다차원 미터링(Multi-dimensional metering)은 토큰 소모량, API 요청 횟수, 컴퓨팅 시간에 대한 과금을 동시에 하는 것은 독립적인 집계가 필요한 세 가지 개별 사용량 기록을 동시에 처리해기 때문에, 우회적인 방법이 필요하다.
선불 크레딧은? 스트라이프는 기본적인 고객 잔액만 지원할 뿐, 크레딧 유형, 만료 정책, 자동 충전 기능과는 거리가 멀다. OpenAI도 이 벽에 부딪혔다. 복잡한 요금 산정 로직으로 인해 수십억 개 추론 이벤트를 측정하고, 고객이 크레딧을 소진할 때마다 점진적으로 청구해야 했다. 스트라이프 빌링 아키텍처로는 불가능했다. OpenAI만 그런 것도 아니었다.
AI 세금은 AI 기업만을 위한 것이 아니다
이같은 아키텍처 한계가 이례적인 사례는 아니다. 이러한 기능을 필요로 하는 기업이 AI 전문 기업뿐만 아니라 모든 기업으로 확대되고 있기 때문이다. AI 기능을 추가하는 모든 기업이 동일한 빌링 복잡성을 떠안고 있다. AI 리드 스코어링(AI lead scoring)을 추가하는 CRM은 추론 호출을 측정해야 한다. AI 생성을 추가하는 디자인 도구는 토큰을 추적해야 한다. 코드 완성 기능을 추가하는 개발자 플랫폼은 제안당 청구가 필요하다. AI 채팅을 추가하는 SaaS 제품은 대화 턴(횟수)을 측정해야 한다.
AI 기능이 '있으면 좋은 것'에서 핵심 차별화 요소로 전환되고, 비용이 구독 등급에 흡수되지 않고 사용량에 따라 바로 늘어날 때 모든 소프트웨어 기업은 실시간 미터링, 프로그레시브 빌링, 크레딧 지갑이 필요하다. 스트라이프 빌링은 사전 집계 모델 기반이라, 이들 모두가 스트라이프에 데이터를 보내기 전에 별도 미터링 인프라를 구축해야 한다한다는 것을 의미한다.
투명성 측면에선 보다 근본적인 문제가 있다. 전 GitHub CEO 토마스 돔케는 오픈소스 AI 개발 도구를 위해 6000만달러를 조달했다. 그의 주장은 이렇다.: “AI 에이전트가 우리 인프라의 더 많은 부분을 차지할수록 오픈소스는 필수 요소가 된다. 내부 작동 방식을 확인할 수 없다면? 그것은 리스크다. AI가 무엇을 하는지 감사할 수 있어야 한다.”
AI가 청구(가격 책정, 수익, 비즈니스 모델 전체)에 관여할수록 블랙박스 문제는 악화된다. 청구 시스템이 독점적이어서 이벤트 미터링 방식, 가격 규칙 적용, 청구서 계산 과정을 검사할 수 없다면, 감사나 수정이 불가능한 미션 크리티컬 비즈니스 로직을 운영 중인 셈이다. 다차원 미터링, 프로그레시브 빌링, 궁극적으로는 AI 기반 가격 최적화로 청구 시스템이 복잡해질수록, 돔케가 시대를 위해 오픈소스에 집중하는 것은 이념적 선택이 아니다. 실용적인 위험 관리다.
재구축이 인수 비용보다 더 비쌌을 이유
스트라이프가 단순히 이러한 기능을 추가할 수 있다고 생각할 수 있다. 이미 기반 인프라(Kafka, Redis, S3, 분석 시스템)를 보유하고 있기 때문이다. 하지만 이는 스트라이프 빌링 아키텍처가 현재 데이터 모델과 얼마나 깊게 결합되어 있는지를 간과한 것이다. 스트라이프 빌링은 사용 기록 API(Usage Records API)를 통해 전송되는 사전 집계된 사용량 데이터를 전제로 한다. 전체 시스템(데이터베이스 스키마, 청구 주기 로직, 인보이스 생성, 고객 포털)은 이 전제 위에 구축돼 있다.
그리고 보다 근본적인 아키텍처 제약이 있다: 스트라이프 빌링은 이벤트 수집 관련 HTTP에 의존한다. 사용량 기록을 푸시하려면 REST API 호출을 수행해야 한다. 이는 근본적으로 동기식 요청-응답 방식이다.
실질적 한계: 스트라이프 빌링은 초당 약 1000개 이벤트로 최대 처리량이 제한된다. 공격적인 배치 처리라 해도 HTTP 요청-응답 주기, API 속도 제한, 타임아웃 문제에 제약을 받다. 참고로 OpenAI는 매일 수십억 개 추론 이벤트를 처리한다—이는 초당 10만개 이상 이벤트를 지속적으로 처리하는 것으로, 순간적으로 훨씬 더 높은 수치를 보인다.
차세대 기업들은 소스 시스템에서 직접 이벤트 스트리밍이 필요하다. Kafka, Kinesis, 이벤트 버스 등은 원시 이벤트를 비동기적으로 수집하여 실시간으로 처리한다. 단일 Kafka 클러스터는 초당 100만 개 이상의 이벤트를 단일 자릿수 밀리초 지연으로 처리하며 필요에 따라 수평적으로 확장된다.
이는 단순히 다른 API 엔드포인트가 아니다. 이는 완전히 다른 수집 모델이다.: 발행-구독 방식 대 요청-응답(pub-sub versus request-response), 스트림 처리 대 배치 집계, 백프레셔 처리 대 속도 제한, 초당 수백만 건 대 수만 건.
AI 규모에서 실시간 이벤트 수집을 지원하려면 다음과 같은 것들이 필요하다.
HTTP/REST에서 이벤트 스트리밍으로 전체 수집 계층을 재구축해야 한다. 그런 다음 사용량이 사전 집계된 상태로 도착한다는 가정에서 청구 로직을 분리해야 한다. 이는 스트라이프 빌링이 사용량 데이터를 저장하고, 청구서 생성을 트리거하며, 프로그레시브결제를 처리하고, 분석 기능을 제공하는 방식을 재작성해야 함을 의미한다. 기존 API에 Kafka를 연결하는 것이 아니다. 근본적인 수집 모델과 시스템이 수용하는 방식을 변경하는 것이며, 이는 모든 하위 시스템에 파급된다.
문제는 인프라가 아니다. 스트라이프 빌링 아키텍처가 기존 통합에 파괴적 변경을 초래한다는 점이다. 기업들은 사전 집계 모델을 기반으로 구축해왔다. 기본 데이터 모델을 변경해 원시 이벤트를 수용하려면 기존 고객을 끊거나 완전히 분리된 두 개 청구 시스템을 유지해야 한다.
이는 전형적인 플랫폼 딜레마를 야기한다.: 고객을 재구축하고 마이그레이션할 것인가(수년간의 프로젝트와 수익 위험), 아니면 병렬 시스템을 유지할 것인가(두 개 코드베이스, 두 개 API, 운영 복잡성)?
스트라이프는 세 번째 옵션을 선택했다.: 기존 고객의 스트라이프 빌링을 끊지 않으면서 이미 OpenAI를 위해 이 문제를 해결한 메트로놈(Metronome)을 인수한 것이다.
통합은 보기보다 어렵다
여기서 스트라이프 인수 실적이 흥미로워진다. 스트라이프는 인수합병에서 성공과 고전을 모두 경험했다.
스트라이프 레이더(2016년 엘리먼츠 인수)는 모두가 언급하는 성공 사례다. 스트라이프 페이먼트에 깊이 통합되어 사기 탐지가 결제 스택 전반에서 원활하게 작동한다. 모두가 메트로놈이 이처럼 되길 바란다.
하지만 나머지 실적은 평가가 엇갈린다. TaxJar는 2021년 인수되어 스트라이프 빌링의 세금(Tax) 엔진이 될 예정이었지만 3년이 지난 지금 TaxJar는 사실상 존재감이 없다(진짜로, Stripe 메인 사이트에서 찾아보라). 스트라이프 택스(Stripe Tax)는 자체 API를 가진 완전히 별개 제품으로 존재한다. 약속된 통합은 실현되지 않았다.
Bouncer(2022)는 사기 탐지 기능을 스트라이프 페이먼츠(Stripe Payments)와 깊이 통합할 예정이었지만, 여전히 대부분 독립적으로 운영되고 있다. Okay(2023)는 Stripe Identity와 통합될 예정이었지만 별도 제품, 별도 가격 정책이 유지되고 있다. Bridge(2024)는 11억 달러 규모 스테이블코인 인수로, 기존 스트라이프 인프라에 통합되지 않고 별도 제품 라인으로 통합되었다.
패턴은 이렇다: 전문 솔루션을 인수하지만, 심층적인 아키텍처 결합은 예상보다 어렵다. 팀들은 통합 대신 각자 따로 서비스를 출시한다. 이 패턴이 메트로놈에도 적용된다면, 우리는 이벤트 중심 아키텍처의 Stripe Billing 2.0을 보지 못할 것이다. “구독용 Stripe Billing + 사용량 기반 메트로놈 + 양자 간 API 브릿지를 얻게 될 것이다.
기업들은 더 긴밀한 결합이 아닌 결제 수단 다각화를 원한다.
이번 인수 시점을 흥미롭게 만드는 또 다른 트렌드가 있다. 기업들은 공급업체 종속성을 강화하기보다 결제 프로세서 선택의 폭을 넓히는 방향으로 움직이고 있다는 것이다.
오픈AI는 최근 결제 분야에서 스트라이프 의존도를 낮추기 위해 다각화를 추진 중이다. 특정 처리 업체에 얽매이지 않는 결제 데이터 저장 공급업체를 모색하고 있다. 이는 스트라이프 역량 문제가 아니다. 이는 재무 최적화(다중 통화 지갑, 환율 타이밍 통제), 협상 레버리지(다중 프로세서 보유로 인한 경쟁적 가격 압박), 지역 최적화(일부 지역은 더 나은 현지 결제 인프라 보유), 복원력(단일 장애점 부재)을 위한 것이다.
에어월렉스는 이를 완벽히 이해했다. 초기에는 신뢰성과 통합 편의성을 위해 스트라이프 페이먼츠와 협력하면서 동시에 자체 결제 인프라를 구축했다. 현재는 일부 시장에서는 스트라이프와 경쟁하고 다른 시장에서는 협력하는 형태다. 최대의 선택권 확보다.
긴장 지점: 기업이 결제 처리 업체 다각화를 원할 때, 청구(메트로놈)와 결제(스트라이프) 간 긴밀한 통합이 가치를 창출할까, 아니면 원치 않는 결합을 초래할까?
메트로놈은 인수 전 실제로 스트라이프 페이먼츠를 필수로 요구했기에, 애초에 결제 중립적이지 않았다는 점은 주목할 만하다. 그러나 기업들이 선택의 폭을 원한다는 더 넓은 맥락은 여전히 유효하다.
수직적 통합은 양날의 검이다
스트라이프의 강점은 항상 수직적 통합이었다. 결제, 청구, 자금 관리, 보고, 정산을 하나의 스택으로 통합한 것이다. 이는 기업 요구가 그들의 모델과 일치할 때 완벽하게 작동한다.
하지만 한 계층의 아키텍처 결정은 인접 계층을 제약한다. 스트라이프 빌링은 스트라이프 페이먼츠 정산 모델을 중심으로 설계되었다.: 독립적으로 정산되는 개별 거래, 결제 일정에 맞춰진 청구 주기.
사용량 기반 가격 책정은 다른 기본 요소가 필요하다. 개별 거래 대신 지속적으로 누적되는 이벤트. 달력 주기가 아닌 지출 한도에 따라 트리거되는 청구. 월별 정산되는 청구서 대신 실시간으로 차감되는 크레딧.
다른 가정 아래 설계된 시스템에 이를 개조하는 작업은? 처음부터 구축하는 것보다 어렵다. 그래서 인수가 경제적 타당성을 가졌던 것이다.. 문제는 그들이 실제로 통합을 실행할 수 있느냐다.
이 패턴은 어디에서나 나타난다
이 아키텍처 부채 패턴은 업계 전반에서 볼 수 있다. Salesforce가 Slack을 인수한 이유는 Salesforce 페이지 기반 아키텍처에 실시간 협업 기능을 구축하려면 근본적인 UI 기본 요소를 재작성해야 했기 때문이다. 어도비가 피그마를 인수하려 한 이유는 웹 기반 멀티플레이어 디자인 도구에 필요한 CRDT(분산 변경 추적) 기능이 크리에이티브 클라우드 데스크톱 중심 아키텍처에는 구현되지 않았기 때문이다. 마이크로소프트가 깃허브를 인수한 이유는 git 기반 협업 워크플로가 애저 DevOps 중앙 집중식 VCS(버전 관리 시스템) 모델과 깔끔하게 매핑되지 않기 때문이다.
모든 사례에서 인수 기업은 자체적으로 해당 기능을 구축할 자원, 인재, 인접 분야 전문성을 보유하고 있었다. 그러나 수년 전에 내려진 아키텍처 결정이 제약을 만들어 내부 개발보다 인수가 더 저렴하게 느껴지게 했다.
초기 아키텍처 결정은 고객뿐 아니라 플랫폼 자체에도 복합적 영향을 미친다.
다음은 어떻게 될까
남은 질문들:
메트로놈 통합은 레이더 모델(Radar model, 원활하게 작동하는 심층 통합)을 따를까, 아니면 택스자 모델(TaxJar model, 결국 통합되지 않는 병렬 제품)을 따를까?
결제 다각화 추세가 결제-청구 연동 강화의 가치를 떨어뜨릴까, 아니면 스트라이프가 편의성이 여전히 승리할 것이라고 내기하고 있을까?
청구 복잡성에 부과되는 'AI 통합 비용'은 일시적인가(기업들이 사전 집계 방식을 구현할 방법을 찾아낼 것인가), 영구적인가(이벤트 중심 아키텍처가 기본 요건이 되는가)?
어느 규모부터 기업들은 통합 스택보다 분야별 최적 솔루션 조합(별도의 청구, 결제, 재무 시스템)을 선호하기 시작하는가?
각 기업마다 이 질문들에 대해 서로 다른 베팅을 하고 있으며, 이는 아직 단일 정답이 존재하지 않음을 시사한다.
시사점
스트라이프의 메트로놈 인수는 경쟁 역학보다 한 세대 제품에 맞춰진 아키텍처 결정이 시장 진화 시 구조적 제약으로 전환될 수 있음을 보여준다.
스트라이프 빌링의 구독 중심 아키텍처는 2018년 당시 올바른 선택이었다. 하지만 5년 후 등장한 AI 시대의 사용 모델에는 적합하지 않았다. 몇 년이 소요되고 고객이 넘어올 것이라고 확신할 수 없는 재작성 대신, 스트라이프는 인수라는 경제적으로 합리적인 선택을 했다.
인프라를 구축하는 모든 이에게 주는 교훈: 오늘 아키텍처에 구축하는 유연성이 내일 어떤 시장을 서비스할 수 있을지 결정한다. 때로는 초기 결정 사항을 변경하는 비용이 다른 선택을 한 회사를 인수하는 것보다 더 비싸질 수 있다.
