지난 1년 동안 Codex와 Sora는 빠르게 채택되어 당초 예상했던 것 이상으로 사용량이 빠르게 증가했습니다. 그에 따라 사용자가 사용하기 시작하고 실질적인 가치를 발견한 후 사용 한도에 부딪히는 일관된 패턴을 보였습니다.
사용 한도는 수요를 원활하게 하고 공정한 액세스를 보장하는 데 도움이 될 수 있지만, 사용자가 가치를 얻고 있을 때 강제로 사용이 중단되면 실망감을 줄 수 있습니다. 따라서 시스템 성능과 사용자 신뢰를 보호하면서 사용자가 계속 사용할 수 있는 방법이 필요했습니다.
이를 해결하기 위해 사용량을 집계하는 실시간 액세스 엔진을 구축했습니다. 해당 엔진의 계층 중 하나는 크레딧을 구매할 수 있는 기능입니다. 사용자가 사용 한도를 초과할 경우, 크레딧 잔액을 소진함으로써 계속해서 OpenAI 제품을 계속 사용할 수 있습니다.
그 바탕에는 한도, 실시간 사용량 추적, 크레딧 잔액을 단일 액세스 모델에 통합하는 복잡한 시스템이 있습니다. 이 글에서는 Codex와 Sora를 확장하면서 액세스 제어를 재고해야 했던 이유, 정확한 실시간 시스템이 요청당 사용 제한과 크레딧을 혼합하는 방법, 그리고 그 기반 위에서 두 제품에 대한 추가 액세스 권한을 부여하는 방법에 대해 설명합니다.
한 걸음 물러서서 보면 기존 액세스 모델은 선택을 강요하는 경향이 있습니다.
- 사용 한도는 처음에는 도움이 될 수 있지만, 한도가 소진되면 “나중에 다시 시도하세요”라는 메시지와 함께 사용자에게 좋지 않은 경험을 남길 수 있습니다.
- 사용량 기반 요금 청구는 유연하지만 사용자가 첫 번째 토큰부터 비용을 지불해야 하므로 초기 시범 사용에는 적합하지 않습니다.
Codex와 Sora의 경우, 어느 쪽도 단독으로는 충분하지 않았습니다. 단순히 사용 한도를 올리면 중요한 수요 평준화 및 공정성 제어 기능을 잃고, 모든 사람에게 서비스를 제공할 수 있는 용량이 부족해집니다. 비동기식 사용량 청구에만 의존한다면 지연, 초과 청구, 또는 정산 문제를 초래할 수 있습니다. 이는 사용자가 가장 몰입해 있을 때 바로 알아차리는 문제입니다.
따라서 실시간 한도와 종량제 액세스를 결합한 단일 하이브리드 시스템이 필요했습니다.
이 시스템은 다음을 수행해야 했습니다.
- 사용 한도에 도달할 때까지 적용
- 동일한 요청 내에서 크레딧으로 원활하게 전환
- 실시간으로 그러한 의사 결정 내리기
- 매우 정확하고 감사 가능하게 크레딧 소비 추적
우리가 이룬 핵심 개념적 전환 중 하나는 액세스를 의사 결정 워터폴로 모델링한 것이었습니다. “이게 허용되나?”라고 묻는 대신에 “얼마나 허용되며, 어디서부터 허용되나?”라는 질문을 합니다. 사용량을 집계할 때 시스템은 다음 순서로 진행합니다.
이 모델은 사용자가 실제로 제품을 경험하는 방식을 반영합니다. 사용 한도, 무료 티어, 크레딧, 프로모션, 엔터프라이즈 자격은 모두 동일한 의사결정 스택의 계층에 불과합니다. 사용자 관점에서 보면, 사용자는 “시스템을 전환”하는 것이 아니라 Codex와 Sora를 계속 사용할 뿐입니다. 그렇기 때문에 크레딧은 워터폴의 또 다른 요소일 뿐이며 보이지 않는 것처럼 느껴집니다.
크레딧 소비를 처리하기 위해 서드파티 사용량 청구 및 측정 플랫폼을 평가했습니다. 인보이스 발행과 보고에는 적합하지만 두 가지 중요한 요구 사항을 충족하지 못했습니다.
사용자가 한도에 도달하여 크레딧을 사용할 수 있게 되면 시스템에서 이를 즉시 파악해야 합니다. 최선의 노력 또는 지연된 계산은 갑작스러운 차단, 일관되지 않은 잔액, 잘못된 여금 청구로 나타납니다. Codex와 Sora 같은 인터랙티브 제품의 경우 이러한 실패는 눈에 띄고 실망감을 안겨줍니다.
또한 모든 결과에 대한 투명성을 제공해야 했습니다.
- 요청이 허용되거나 차단된 이유
- 소비된 사용량
- 적용된 한도 또는 잔액
이 기능은 상황의 일부분만 확인할 수 있는 별도의 사용량 청구 플랫폼에서 개별적으로 해결하기보다는 의사 결정 워터폴에 긴밀하게 통합되어야 했습니다. 사용자가 신뢰를 저해하지 않고 제품에 액세스할 수 있도록 하려면 정확성, 타이밍, 관찰 가능성에 대한 완전한 제어가 필요했습니다. 그로 인해 우리는 사내 솔루션을 선택하게 되었습니다.
따라서 동기식 액세스 결정을 위해 특별히 설계된 분산된 사용량 및 잔액 관리 시스템을 구축했습니다.
시스템의 전반적인 개요는 다음과 같습니다.
- 사용자별, 기능별 사용량 추적
- 요금 한도 기간 유지
- 실시간 크레딧 잔액 유지
- 스트리밍 비동기 프로세서를 통해 잔액을 멱등적으로 차감
모든 요청은 단일 평가 경로를 통해 사용 한도에서 동기적으로 소비하고 필요한 경우 충분한 크레딧을 확인하여 허용되는 사용량을 실시간으로 결정한 다음, 비동기적으로 크레딧 차감을 정산하면서 하나의 최종 결과를 반환합니다. 이렇게 하면 제품 전반에서 일관된 동작을 보장하고 팀 간에 중복되는 로직을 제거할 수 있습니다.
이 시스템의 주요 설계 원칙 중 하나는 청구가 정확하다는 것을 입증할 수 있어야 한다는 것입니다. 이는 기업 고객으로부터 시작된 당사의 크레딧 지원의 근원을 반영합니다. 위의 시스템 다이어그램에는 서로 연결된 세 개의 개별 데이터세트가 있습니다.
- 제품 사용 이벤트: 사용자가 실제로 한 일
- 수익화 이벤트: 사용량에 따라 사용자에게 청구하는 항목
- 잔액 업데이트: 사용자의 크레딧 잔액을 조정한 금액과 그 이유
이 데이터세트은 단순한 부산물이 아니라 실제로 시스템을 구동하며, 각 데이터세트가 다음 데이터세트를 트리거합니다. 발생한 일, 관련 요금, 인출한 금액을 분리하여 모든 계층을 독립적으로 감사, 재생, 조정할 수 있습니다. 이는 크레딧 잔액 업데이트가 다소 지연되는 대신 입증 가능한 정확성을 우선시하는 의도적인 절충안입니다. 다음은 우리가 이를 어떻게 달성했는지에 대한 설명입니다.
- 제품 사용 이벤트는 크레딧 소비와 관계없이 모든 사용자 활동에 대해 게시됩니다. 이를 통해 사용자 활동에 대한 감사 추적을 제공하고 크레딧 요금을 청구하거나 청구하지 않은 이유를 설명할 수 있습니다.
- 모든 이벤트에는 안정적인 멱등성 키가 있기 때문에 재시도, 리플레이 또는 작업자 재시작으로 인해 잔액이 이중으로 차감되지 않으므로 이중 과금을 방지할 수 있습니다. 또한 일괄 조정을 실행하여 오프라인에서 작업을 확인할 수 있습니다.
- 감사 추적을 생성하기 위해 동기식 업데이트 대신 비동기식(그러나 여전히 실시간에 가까운) 잔액 업데이트를 수행합니다. 시스템이 제대로 작동하고 있음을 입증하고 사용자에게 잘못 청구되지 않았음을 보장하기 위해 사용자의 잔액을 업데이트하는 데 약간의 지연이 발생하는 것을 용인합니다. 짧은 지연으로 인해 사용자의 크레딧 잔액이 초과되는 경우 자동으로 환불합니다. 당사는 엄격한 집행보다는 입증 가능한 정확성과 사용자의 신뢰를 우선시합니다.
- 크레딧 잔액을 감소시키고 단일 원자 데이터베이스 트랜잭션에 잔액 업데이트 레코드를 삽입합니다. 잔액 업데이트는 계정별로 순차적으로 이루어지므로 동시 요청이 동일한 크레딧을 사용하려고 경합하는 일은 발생하지 않습니다. 잔액 업데이트 레코드에는 차변 금액과 업데이트를 트리거한 수익화 이벤트에 대한 귀속 정보가 포함되며, 이를 단일 데이터베이스 트랜잭션으로 처리하면 크레딧 잔액의 모든 조정에 대한 감사 추적이 보장됩니다.
이 모든 엄격함은 간편하고 안전한 액세스라는 한 가지 목표를 뒷받침합니다. 사람들이 창작이나 코딩을 할 때 요청이 제대로 처리될지, 과다 청구될지, 잔액이 정확한지 걱정할 필요가 없어야 합니다. 사용량, 청구, 잔액이 입증 가능한 방법으로 정확하게 표시되도록 함으로써 사용자의 경험을 방해하지 않는 시스템을 제공합니다. 이를 통해 하드 스톱을 지속적인 액세스로 대체할 수 있으며, 크레딧을 인보이스뿐만 아니라 실제 업무 중에도 사용할 수 있습니다.
당사 접근 방식의 기본 원칙은 사용자 모멘텀을 보호하는 것입니다. 실시간 잔액은 불필요한 중단을 방지하고, 원자 소비는 이중 과금을 방지하며, 통합 액세스 로직은 예측 가능한 동작을 보장하는 등 모든 아키텍처 결정은 사용자 중심의 결과로 이어집니다. 그 결과 사람들은 갑자기 중단해야 하거나 계획을 조기에 변경하지 않고도 더 오래 일하고, 더 깊이 탐구하고, 프로젝트를 계속 진행할 수 있습니다.
사용자가 몰입해 있을 때 시스템은 사용자를 방해하지 않고 계속 진행할 수 있도록 도와야 합니다. 그러면 한도와 크레딧에 대해 주의를 기울이지 않게 됩니다.
이러한 경험을 구축하려면 액세스, 사용량, 청구를 단일 시스템으로 다시 생각하고 정확성을 최우선 제품 기능으로 취급하는 인프라를 구축해야 했습니다. 이와 동일한 토대는 시간이 지남에 따라 더 많은 제품으로 확장될 수 있으며 Codex와 Sora는 시작에 불과합니다.
