Data Eng Wiki

Zero-Sum by Design - 10 Years of Ubers Payments Platform

12 min read

Zero-Sum by Design: 10 Years of Uber’s Payments Platform

Author: Nimish Sheth, Manas Kelshikar, Dhirendra Kumar Singh (Uber) | Source: uber.com/blog | Published: 2026

한 줄 요약

수천억 달러를 옮기는 결제 플랫폼은 우연히 생기지 않는다 — 일찍 내리고 10년간 일관되게 방어한 원칙적 결정(불변성, zero-sum, 강한 일관성, 일반화된 추상)의 결과이고, 그 덕에 재아키텍처 없이 모든 신규 사업부와 결제 수단을 흡수했다.

핵심 주장/내용

  • 핵심 원칙 1 — Immutable Money Order: 아키텍처에서 가장 중요한 데이터 모델 중 하나가 Money Order로, 실세계 커머스 트랜잭션(트립, Uber Eats 주문, 화물 배송, Uber Cash 충전)에 관여하는 엔티티 사이의 일련의 차변·대변이다. 시스템을 self-auditable하게 만들기 위해 money order를 불변으로 만들었다
    • 트립이 조정되거나 Eats 주문의 항목이 누락되면? 조정을 포착하는 추가 money order를 쓴다. 원칙은 그대로 — 한 번 쓰인 order는 어떤 형태로도 바뀔 수 없다
  • 핵심 원칙 2 — Zero Sum: money order를 쓰기 전에 항상 pre-commit 검증을 돌리고, 그중 하나가 money order의 모든 항목의 합이 0인지 확인하는 것이다. 즉 돈이 절대 생성되거나 소멸될 수 없다. 더해서 double-entry bookkeeping 원칙을 따라 order의 모든 대변 항목에 동등한 차변 항목이 있게 하고, 이것이 zero-sum 원칙이 진짜로 위반될 수 없게 보장한다. 수년에 걸쳐 이 원칙들을 결제 플랫폼 상류 시스템에도 밀어넣었다
  • 핵심 원칙 3 — 강하게 일관된 ledger balance: 2016년 Uber는 모놀리스에서 막 벗어나던 참이었고 사내 sharded MySQL이 있었지만 ledger balance의 강한 일관성을 보장할 완벽한 해법이 없었다. 이 특정 데이터 스토어를 DynamoDB에 구축 — 각 엔티티(Spender, Earner, Business)가 여러 sub-ledger 계정을 가질 수 있고 모두 DynamoDB의 단일 row로 저장된다. 전형적 엔티티 크기는 1KB였지만 수년간 엔티티 내 sub-ledger 계정 수를 관리해야 했고 잔액 0인 계정은 row 크기 관리를 위해 pruning해야 했다
  • 핵심 데이터 모델 3가지 (초기에 데이터 모델 정의에 둔 강조가 전략적 투자였고 오늘도 운영의 기초로 남아 있다):
    • Money order — 둘 이상 실세계 엔티티 간 자금 이동을 모델링하며 Uber의 커머스 트랜잭션을 캡슐화
    • Ledger — 하나 이상의 계정을 가진 실세계 엔티티를 나타내고 각 계정이 잔액을 보유
    • Entity changelog — ledger의 잔액 갱신을 포착해 완전한 감사 추적과 엔티티의 ledger를 시작 시점부터 재생성할 능력을 제공
  • 느슨하게 결합된 아키텍처: 결제 플랫폼을 독립적이고 stateless한 마이크로서비스의 집합으로 설계했고, 각각이 자금 이동 생명주기의 개별 단위(money order 생성·처리·수금·지급)를 소유하며 Kafka가 기저 메시징 버스. 모든 서비스에 걸친 두 개의 공유 source of truth는 money order store와 entity balance store다. 이 async 파이프라인이 오늘날 Uber 자금 트래픽의 대부분을 처리하고, 사용자 세션 중 흐름은 Cadence(사내 워크플로 엔진)로 async backbone을 훼손하지 않으면서 동기 결제를 지원
  • LOB(Line of Business) 무관: 만들 당시 Uber에는 Rides라는 핵심 사업 하나와 막 시작한 Uber Eats가 있었지만, 새 제품 라인에 진출하면 그냥 바로 작동하도록 플랫폼을 만들고자 했다. 전형적 실세계 자금 이동을 모델링하기 위해 Collection Money Order, Disbursement Money Order, Refund Money Order 같은 일반 money order를 두었다 — 순수한 플랫폼 개념이고 특정 제품 라인과 아무 연관이 없다. 그리고 둘 이상 엔티티 간의 어떤 실세계 커머스 트랜잭션이든 나타낼 수 있는 일반 commerce Money Order도
    • 수년간 Uber Freight, 2-wheels, Transit, Hotels, Rental Cars, Grocery & Retail, Ads, Memberships(Uber One, Costco 등)를 온보딩했고 핵심 플랫폼에는 거의 또는 전혀 변경이 필요 없었다
  • 결제 수단 무관: 초기에도 이미 일부 지역 결제 수단을 포함해 6개 정도를 지원했지만, 시간이 지나며 특정 국가의 모든 주요 수단을 추가하고 싶어질 것을 알았다. 그래서 핵심 플랫폼이 charge, disburse, refund 같은 API를 가진 Payment integration 인터페이스에 뒷받침되는 일반 Payment Instrument 개념에서 작동하게 했다. 핵심 플랫폼 자체에는 수단별 로직이 없고 그것은 payment integration 구현으로 추상화되었다
    • 덕분에 신용·직불카드, PayPal, Paytm, UPI, Alipay, Apple Pay, Google Pay, iDEAL, PIX와 수십 개 지역 지갑, 그리고 Uber Cash 같은 네이티브 수단까지 모두 같은 일반 인터페이스로 플러그인되며 핵심 플랫폼은 거의 또는 전혀 변경 없이 확장되었다. reverse-integration 플랫폼인 Uber Pay만으로 오늘날 50개 이상의 결제 수단을 글로벌하게 관리
  • 10년의 스케일링 — 주목할 아키텍처 전환:
    • 데이터 레이어 — 감사 요구가 깊어지면서 off-the-shelf 데이터베이스를 넘어 고유 요구에 맞춘 인프라를 만들었고, Storage Platform 팀과 협력해 감사 가능성과 tamper-evident 기록 보관을 위해 목적 구축된 LedgerStore를 설계·구축
    • Entity Fares — 단일 트랜잭션에서 임의 수의 당사자 간 자금 이동을 모델링할 수 있었지만 상류 시스템은 같은 유연성을 온전히 갖지도, zero-sum 같은 원칙을 강제하지도 않았다. 요금 표현의 모호함이 확립한 핵심 원칙과 직접 충돌했으므로, 모든 참여 엔티티에 대해 요금을 명시적으로 기록하고 계산 시점에 zero-sum 원칙을 강제해 트랜잭션의 발생 시점부터 기초 원칙이 온전히 유지되게 했다
    • Hot Entity 문제 — Uber for Business와 Uber Direct 등 B2B 생태계가 급팽창하며 독특한 아키텍처 도전이 표면화. 같은 ledger row를 자주 갱신하면서 강한 전역 일관성을 유지하는 것이 직렬화된 쓰기 성능과 시스템 정확성에 큰 장애가 되었다. 특화된 직렬화 배치 쓰기 메커니즘을 혁신해 고트래픽 엔티티의 ledger mutation 처리량을 10배 증가
    • Ledger-as-a-Service — ledger 프리미티브가 Uber 전반의 다양한 중요 stored value·자금 이동 유스케이스를 지원할 만큼 범용적임이 입증되었다. Uber Cash와 Uber Money(closed-loop와 semi-open-loop stored value 시스템 관리에 절대적 금융 무결성을 보장할 battle-tested ledger 필요), Uber for Business(B2B 인보이스 기반 정산 흐름을 위해 전체 기업 청구 생명주기에 걸친 unbilled·billed·settled 잔액 추적). ledger 컴포넌트를 분리·일반화해 멀티테넌트 솔루션으로 진화시켰고, 이 모델이 각 팀이 자기 금융 프리미티브를 만드는 오버헤드 없이 구체적 비즈니스 요구를 반복하게 해줬다. 여러 멀티테넌트 ledger가 7년 넘게 안정적으로 운영 중

주요 수치 / 사실

  • 2016년 회의실 하나에서 작은 팀이 기초 마이크로서비스 세트를 부트스트랩. 10년 뒤 그 서비스 다수가 여전히 프로덕션에서 돌아 초기 설계의 durability를 보여준다
  • 같은 기간 Uber는 연환산 gross booking 500억 달러 → 2,170억 달러로 성장. 고객에게서 결제를 수금할 뿐 아니라 드라이버·courier·머천트에게 자금을 지급해 총 자금 이동으로는 gross booking의 거의 2배를 처리하고 12억 개 이상의 엔티티에 대한 ledger 잔액을 유지
  • hot entity에 대한 ledger mutation 처리량 10배 증가
  • 결론: 불변성이 감사 추적을 깨끗하게 유지했다. Zero-sum 회계가 돈이 결코 생성되거나 소멸되지 않게 보장했다. 강한 일관성이 신뢰할 수 있는 ledger를 주었다. 그리고 LOB 무관 money order와 수단 무관 결제 통합이라는 일반 추상을 중심으로 설계함으로써, 재아키텍처 필요를 피하면서도 Uber의 진화하는 요구에 맞춰 진화하는 기반을 만들었다

관련 위키

Source: 원문 보기

그래프 뷰

백링크