안녕하세요, Tom입니다. Codex나 Sora 써보신 분들은 다 겪어봤을 겁니다. 막 몰입해서 작업하고 있는데 갑자기: > "Rate limit exceeded. Please try again later." 이 메시지만큼 몰입을 깨는 게 또 있을까요? OpenAI도 똑같이 고민했습니다. 그래서 "rate limit에 걸려도 멈추지 않게 하는" 시스템을 만들었어요. 오늘은 그 아키텍처를 뜯어봅니다. ## 기존 접근 방식의 한계 전통적인 액세스 모델은 양자택일을 강요합니다: ### 1. Rate Limits (사용량 제한) 장점: - 수요 평준화 가능 - 공정한 접근 보장 - 서버 과부하 방지 단점: - "나중에 다시 와" → 최악의 UX - 몰입 중단 - 사용자 이탈 ### 2. Usage-based Billing (종량제) 장점: - 유연한 사용 - 쓴 만큼만 과금 단점: - 첫 토큰부터 과금 → 초기 탐색 어려움 - 비동기 정산 → 지연/초과 청구/정산 오류 - 실시간성 부족 OpenAI가 원한 것: - Rate limit의 공정성과 안정성 - 종량제의 유연성 - 실시간 결정 - 100% 정확한 과금 ## 해결책: 하이브리드 실시간 액세스 엔진 OpenAI는 완전히 새로운 접근을 택했습니다: ``` 사용자 요청 ↓ Rate Limit 체크 ↓ 남았나? → Yes → 처리 ↓ No 크레딧 있나? → Yes → 크레딧 차감 + 처리 ↓ No 차단 (하지만 크레딧 구매 옵션 제시) ``` 핵심 아이디어: - Rate limit은 무료 티어의 보호막 - 크레딧은 무제한 사용의 열쇠 - 둘 사이의 전환은 단일 요청 내에서 즉시 결정 ## Access as a Waterfall (폭포수 모델) OpenAI는 접근 제어를 폭포수처럼 흐르는 의사결정으로 설계했습니다: ``` 요청 들어옴 ↓ 1. Rate Limit 체크 (무료 티어) ↓ 소진 2. Free Tier 크레딧 체크 (프로모션 등) ↓ 소진 3. Paid Credits 체크 (구매한 크레딧) ↓ 소진 4. Enterprise Entitlements (기업 계약) ↓ 모두 소진 5. 차단 ``` 사용자 입장에서는: - "시스템을 전환"하는 느낌이 아니라 - 그냥 계속 쓰는 것처럼 느껴짐 이게 바로 "크레딧이 보이지 않는" 이유입니다. ## 왜 서드파티 솔루션을 안 쓰고 직접 만들었나? OpenAI는 Stripe Billing 같은 서드파티 솔루션도 평가했습니다. 서드파티의 한계: 1. 실시간성 부족 - "Best-effort" 카운팅 → 지연 발생 - 깜짝 차단, 잔액 오류, 잘못된 과금 2. 투명성 부족 - "왜 차단됐는지" 설명 어려움 - "얼마나 썼는지" 즉시 확인 불가 - "어떤 limit/balance가 적용됐는지" 추적 어려움 OpenAI가 원한 것: - 밀리초 단위 실시간 결정 - 모든 결정의 완벽한 추적 - 100% 정확한 과금 → 직접 만드는 수밖에 없었습니다. ## 아키텍처: Provably Correct Billing System OpenAI는 "증명 가능하게 정확한" 빌링 시스템을 만들었습니다. ### 핵심 구조 ``` 사용자 요청 ↓ ┌─────────────────────────────────────┐ │ 1. 실시간 Access Decision │ │ - Rate limit 동기 체크 │ │ - 크레딧 잔액 동기 확인 │ │ → 즉시 허용/차단 결정 │ └─────────────────────────────────────┘ ↓ ┌─────────────────────────────────────┐ │ 2. Product Usage Event 발행 │ │ (사용자가 실제로 뭘 했는지) │ └─────────────────────────────────────┘ ↓ ┌─────────────────────────────────────┐ │ 3. Monetization Event 생성 │ │ (이 사용에 대해 얼마를 청구할지) │ └─────────────────────────────────────┘ ↓ ┌─────────────────────────────────────┐ │ 4. Balance Update (비동기) │ │ - 크레딧 차감 │ │ - Audit Trail 기록 │ │ - Idempotency Key로 중복 방지 │ └─────────────────────────────────────┘ ``` ### 3가지 독립적인 데이터셋 1. Product Usage Events — 사용자가 실제로 한 행동 2. Monetization Events — 청구할 금액 3. Balance Updates — 실제 잔액 변경 왜 분리했나? - 각 레이어를 독립적으로 감사, 재실행, 검증 가능 - 문제 발생 시 어느 단계에서 잘못됐는지 정확히 파악 ## 핵심 기술적 보장 ### 1. Idempotency (멱등성) ```python # 같은 요청을 여러 번 보내도 한 번만 차감 event_key = f"{user_id}_{request_id}_{timestamp}" if already_processed(event_key): return # 중복 처리 방지 else: deduct_credits(amount) mark_processed(event_key) ``` ### 2. Atomic Transaction (원자성) ```sql BEGIN TRANSACTION; -- 크레딧 차감 UPDATE credit_balance SET amount = amount - 10 WHERE user_id = 'user123'; -- 감사 기록 삽입 INSERT INTO balance_updates VALUES ('user123', -10, 'event_xyz', now()); COMMIT; ``` 보장: - 크레딧 차감과 감사 기록이 항상 함께 발생 - 둘 중 하나라도 실패하면 전체 롤백 ### 3. Serialized Updates (직렬화) ```python # 동시 요청이 같은 크레딧을 쓰려고 해도 # 계정 단위로 직렬화되어 처리됨 with account_lock(user_id): if balance >= cost: balance -= cost else: raise InsufficientCredits ``` ### 4. Automatic Refunds (자동 환불) ```python # 비동기 업데이트 지연으로 잔액을 초과 차감했을 경우 if balance < 0: refund(abs(balance)) # "사용자 신뢰 > 엄격한 집행" ``` ## 성능 vs 정확성 트레이드오프 OpenAI는 정확성을 선택했습니다: 동기 처리 (실시간): - Rate limit 체크 - 크레딧 잔액 확인 - 허용/차단 결정 비동기 처리 (약간 지연): - 크레딧 차감 - 감사 기록 생성 결과: - 크레딧 잔액 업데이트가 1~2초 지연될 수 있음 - 하지만 그 대신 100% 정확한 감사 추적 확보 - 초과 차감 발생 시 자동 환불 ## 우리가 배울 수 있는 것 1. Trade-off를 명확히 하라 - 성능 vs 정확성 - OpenAI는 정확성 선택 2. 감사 추적을 1급 시민으로 - "나중에 추가"가 아니라 시스템 설계의 핵심 3. 사용자 경험을 중단하지 마라 - "나중에 와" → "계속 쓰되, 과금됨" 4. Provably Correct > Best Effort - 증명 불가능하면 만들지 마라 ## 마무리하며 OpenAI의 이 시스템은 단순히 "rate limit 우회"가 아닙니다. 본질은: - 사용자 몰입을 보호하면서 - 시스템 안정성을 유지하고 - 100% 정확한 과금을 보장하는 아키텍처입니다. "간단한 크레딧 시스템"처럼 보이지만, 그 뒤에는 실시간성, 정확성, 투명성을 모두 만족시키기 위한 정교한 설계가 숨어 있습니다. 다음에 Codex나 Sora 쓸 때 rate limit 안 걸리고 계속 쓸 수 있다면, 이 복잡한 시스템이 뒤에서 돌아가고 있다는 걸 기억해주세요. --- _이 글은 OpenAI 공식 블로그 포스트를 정리한 것입니다. 원본은 [여기](https://openai.com/index/beyond-rate-limits)에서 확인할 수 있습니다._

인프라 태그 글 모음