우리가 크레딧(Credits)과 지갑(Wallets)을 일급 빌링 프리미티브(First-class billing primitives)로

요약(tl;dr): 대부분의 빌링 시스템(Billing systems)은 크레딧 지갑을 선불 현금 잔액으로 모델링합니다. 이는 초기 단계에서는 작동합니다. 하지만 제품이 토큰 레이어(Token layer)와 고객 대상 가격 사이에 서로 다른 단위당 비용, 서로 다른 마진, 서로 다른 요금표(Rate cards)를 가진 여러 유형의 크레딧을 갖게 되는 순간 시스템은 무너집니다. 우리의 고객인 Reson8은 하나의 선불 카운터가 아닌 요금표 레이어를 중심으로 구조화된 여러 개의 지갑이 필요했습니다.

수많은 빌링 시스템이 크레딧을 선불 현금으로 모델링합니다. 100달러를 지불하면 100달러의 크레딧을 받습니다. 크레딧을 사용하면 잔액이 줄어듭니다. 이는 크레딧이 종종 단순히 화려한 카운터 역할을 하는 "공학적인 문제"로 취급되기 때문입니다. 이 모델은 고객이 크레딧을 구매하는 대상이 두 가지 이상이 되는 순간 깨집니다.

왜 우리가 돈보다 크레딧을 보유하는 것을 선호하는가
우리가 내부적으로 다시 확인하는 원칙이 있습니다: "지갑에 돈보다 크레딧을 두는 것이 낫다. 왜냐하면 돈은 돌려줘야 하지만, 크레딧은 만료시킬 수 있기 때문이다." 현금 지갑은 부채(Liability)를 생성합니다. 고객가 무엇을 입금하든, 고객이 사용하지 않으면 돌려줘야 합니다. 크레딧은 귀하의 조건에 따라 작동합니다: 언제 만료되는지, 무엇을 커버하는지, 어떤 조건에서 유효한지 말입니다. 의무는 설계하는 쪽의 몫입니다. 고객에게 반드시 좋은 것은 아니지만, AI를 운영하는 비즈니스에는 매우 유리합니다.

단일 제품 카테고리를 대상으로 하는 지갑은 세법에서 말하는 단일 목적(Single-purpose)입니다: 구매 시점에 의도된 용도가 알려져 있으므로, 자금이 들어올 때 부가가치세(VAT)가 계산됩니다. 고객이 귀하의 제품 전반에 걸쳐 사용할 수 있는 범용 지갑(General-purpose wallet)은 다목적(Multiple-purpose)입니다: 구매 시점에 의도된 용도를 알 수 없으므로, 실제로 사용할 때 부가가치세(VAT)가 계산됩니다.

크레딧은 제3의 카테고리입니다. 귀하는 제품을 판매하는 것이며(90달러에 100 크레딧), 부가가치세(VAT)는 구매 시점에 적용되고, 크레딧은 통화와 완전히 분리된 자체 교환 메커니즘을 가집니다. 따라서 세 가지 유형의 지갑이 있다면, 세 가지 서로 다른 부가가치세(VAT) 처리 방식과 세 가지 서로 다른 수익 인식(Revenue recognition) 시점을 갖게 됩니다. 만약 이를 하나의 대상으로 모델링했다가 나중에 재무팀이 이를 알게 된다면, 그들은 당신에게 만족하지 않을 것입니다.

단일 지갑(Single wallet)이 적합하지 않은 이유

단일 지갑 모델은 상호 교환성(Interchangeability)을 가정합니다. 모든 크레딧(Credits)이 동일하다는 것이죠. 하나의 크레딧으로 제품 내의 무엇이든 한 단위를 구매할 수 있다고 가정합니다. 이러한 가정은 단순한 제품의 경우에는 어느 정도 사실이지만, 워크로드(Workload)에 따라 단위당 제공 비용이 달라지는 현대적인 AI 기술에서는 그렇지 않습니다. 맞춤형으로 학습된 도메인 모델(Domain model)에서 1분 동안 전사(Transcription)를 수행하는 비용은 일반적인 배치(Batch) 전사 1분보다 더 많이 듭니다. 언어를 변경하면 상황은 더욱 명확해지는데, 이는 근본적인 토큰 수(Token counts)가 동일하지 않기 때문입니다. 이 두 가지 워크로드가 동일한 크레딧 풀(Credit pool)에서 차감될 때, 빌링 시스템(Billing system)은 그 차이를 강제할 수 없습니다. 이는 고객의 크레딧이 서로 호환되지 않는 제품들 사이에서 대체 가능(Fungible)해짐을 의미하며, 마진(Margin)이 청구된 금액과 일치하지 않게 됩니다. 이것은 데이터 모델(Data model)의 문제입니다!

Reson8에게 필요했던 것

Reson8은 유럽 언어를 위한 초고도로 맞춤화된 음성 인식 기술을 구축합니다. 실시간(Real-time) 방식이며, 도메인 적응형(Domain-adaptive)이고, 오디오를 보관하지 않은 채 EU GPU에서 실행됩니다. 이들은 여러 워크로드 유형에 걸쳐 분 단위로 비용을 청구합니다. 표준 전사(Standard transcription), 최대 100만 토큰의 고객 컨텍스트(Context)를 통해 적응된 커스텀 도메인 모델의 실시간 처리 방식, 그리고 배치(Batch) 방식이 있으며, 각각은 서로 다른 비용 기준(Cost basis)을 가집니다. Reson8의 고객이 분(Minute) 단위를 선구매하는 순간, 다음과 같은 질문이 생깁니다: 어떤 종류인가?

표준 전사 분(Standard-transcription minutes)과 커스텀 도메인 실시간 분(Custom-domain real-time minutes)은 서로 다른 제품입니다. 고객이 한 쪽의 풀을 다른 쪽에 사용하게 해서는 안 됩니다. 제품이 이를 허용하지 않을 뿐만 아니라, 마진 프로필(Margin profile)도 이를 지원하지 않기 때문입니다. Reson8, ElevenLabs, Wispr와 같은 기업에 필요한 것은 최소 세 가지의 별도 요금 산정 시스템(Rating systems)이며, 이는 지갑 유형(Wallet types)으로 변환됩니다: 하나는 표준 분(Standard minutes)을 위한 것, 하나는 커스텀 도메인 분(Custom-domain minutes)을 위한 것, 그리고 선구매한 풀이 소진되었을 때 사용량 기반 요금(Metered charge)으로 실시간 처리 초과분(Overages)을 처리하는 시스템입니다. 이론적으로 각 시스템은 고유한 충전 일정(Top-up schedule), 만료 규칙(Expiry rules), 그리고 인보이싱(Invoicing) 동작을 가질 수 있습니다. 단일 선불 잔액(Single prepaid balance)은 이를 모델링할 수 없습니다. 기껏해야 추측할 뿐입니다.

토큰 레이어(Token layer)는 Speech AI가 대부분의 빌링 시스템(Billing systems)이 설계될 당시 고려하지 않았던 차원을 추가하게 만드는 이유입니다. 모델은 토큰(Tokens) 단위로 생각합니다. 고객은 분(Minutes) 단위로 생각합니다. 계약은 크레딧(Credits) 단위로 명시됩니다. 재무 부서는 달러(또는 유로) 단위로 업무를 처리합니다. 각 연결 고리는 하나의 요율(Rate)입니다: 토큰 → 분 → 크레딧 → 달러. 전용 EU 클러스터에서 커스텀 적응형 모델(Custom-adapted model)을 사용하여 실시간 전사(Real-time transcription)를 1분 수행하는 것은 일반 모델을 사용하는 표준 배치 작업(Standard batch job)보다 더 많은 토큰을 소비합니다. 이 변환 계수(Conversion factor)는 워크로드(Workload), 모델 버전, 언어 팩, 그리고 고객이 구성한 도메인 적응(Domain adaptation) 수준에 따라 달라집니다.

대부분의 빌링 시스템은 이벤트당 가격이나 소비 단위당 가격을 설정할 수 있게 해줍니다. 하지만 이들이 지원하지 않는 것은 미터링 레이어(Metering layer)와 지갑 레이어(Wallet layer) 사이에 위치하는 요율표 레이어(Rate card layer)입니다. 즉, 다음과 같은 규칙을 말합니다: 'workload: custom-realtime' 태그가 붙은 미터 이벤트 1개는 지갑 B에서 3 크레딧을 소모하고, 'workload: standard-batch' 태그가 붙은 미터 이벤트 1개는 지갑 A에서 1 크레딧을 소모한다'는 규칙 말입니다. 엔지니어들이 이를 카운터(Counter)로 본다고 했던 것을 기억하시나요? 카운터는 그런 방식으로 작동하지 않습니다. 요율표가 빌링 설정이 아닌 애플리케이션 코드에 존재하게 되면, 재무 부서에서는 이를 확인할 수 없으며 비용 모델이 변경될 때마다 매번 코드를 다시 작성해야 합니다. 그리고 AI 분야에서 비용 모델은 매우 빈번하게 변경됩니다.

요율표가 반드시 빌링 레이어에 있어야 하는 이유: 많은 음성 기술 벤더들은 커스텀 모델 적응(Custom model adaptation) 자체를 하나의 제품으로 제공하기도 합니다. 즉, 고객의 데이터에 모델을 적응시키기 위한 일회성 비용을 청구한 다음, 이를 사용하기 위한 정기적인 크레딧 풀(Credit pool)을 제공하는 방식입니다. 초기 적응 비용과 지속적인 크레딧 지갑은 서로 연관되어 있지만 별개의 이벤트입니다. 전체 수익 스택(Revenue stack)은 동일한 인보이스(Invoice)에서 이 두 가지를 모두 처리해야 하며, 각각에 대해 적절한 시점에 수익을 인식해야 합니다. 이를 하이브리드(Hybrid) 방식이라고 부를 수 있는데, 여기서 일회성 비용은 지갑 프로비저닝(Wallet provisioning) 이벤트를 트리거하고, 고객이 워크로드를 실행함에 따라 지갑은 소진되며, 일정에 따라 또는 요청 시 자동으로 충전(Auto-tops-up)되고, 풀(Pool)이 바닥나면 초과 사용분은 실시간 미터링(Real-time metering)으로 전환됩니다.

이것이 제대로 작동하려면, 지갑(Wallet)은 단순한 카운터(Counter) 이상의 것을 보유해야 합니다. 즉, 어떤 플랜(Plan)이 이를 프로비저닝(Provisioning)했는지, 어떤 미터(Meter)가 여기에 데이터를 공급하는지, 어떤 요율표(Rate card)가 이벤트를 크레딧 차감으로 변환하는지와 같은 추가적인 메타데이터(Metadata)를 포함해야 합니다. 카운터는 그런 역할을 수행할 수 없습니다. Stripe 방식(및 다른 많은 벤더들)은 고객에게 기프트 카드나 "잔액(Balances)"을 제공하지만, 이들은 별개의 객체(Object)가 아닙니다. 즉, 이를 생성하거나 자유롭게 이동시킬 수 없습니다. 이를 연결하려면 직접 작성하고 유지 관리해야 하는 오케스트레이션(Orchestration) 코드가 필요합니다. Lago의 크레딧 프리미티브(Credit primitives)는 멀티 지갑(Multi-wallet), 멀티 요율표(Multi-rate-card) 구성과 자연스럽게 결합되지 않으며, 만약 그 위에서 시스템을 구축한다면 빌링 레이어(Billing layer) 위에 빌링 레이어를 다시 구현하는 별도의 커스텀 로직(Custom logic)이 필요합니다. Solvimon에서 지갑(Wallets)은 일급 프리미티브(First-class primitive)입니다. 고객당 여러 유형의 지갑을 가질 수 있으며, 각 지갑은 특정 미터(Meter) 및 요율표(Rate card)와 연결되고, 설정 가능한 충전(Top-up) 및 만료(Expiry) 규칙을 가집니다. 요율표는 설정(Configuration) 내에 존재합니다. 재무(Finance) 팀은 이를 확인할 수 있고, 빌링 시스템은 이를 강제(Enforce)합니다.

수익 인식(Revenue recognition) 측면에서 변화하는 점

훌륭한 지갑 모델링은 수익 인식을 깔끔하게 만듭니다. 고객이 10,000 표준 분(Standard minutes)을 선결제하면 이연 수익 부채(Deferred revenue liability)가 생성됩니다. 소비되는 매 분마다 적절한 지갑에 대해 인식 이벤트(Recognition event)가 트리거됩니다. 풀(Pool)이 비워지고 고객이 미터링된 초과 사용분(Metered overages)으로 넘어가면, 빌링은 크레딧 소진(Credit burn)에서 실시간 사용량(Real-time usage)으로 전환됩니다. 재무 팀은 하나의 인보이스(Invoice)와 하나의 원장(Ledger)을 보게 됩니다. 지갑의 고갈이 곧 수익 인식 일정(Revenue recognition schedule)이 됩니다. 빌링 계산 중에 크레딧은 대기 중인 인보이스에 대해 예약(Reserved)되며, 인보이스가 확정(Final)될 때만 차감됩니다. 가용 잔액(Available balance)은 실제 잔액(Real balance)에서 예약액(Reservations)을 뺀 값입니다. 예약과 차감 사이의 이 간극은 고객이 주기 중간에 과다 지출하는 것을 방지하며, 스프레드시트 없이도 인식 일정을 추적할 수 있게 합니다. Reson8에게 이것은 매우 중요합니다. EU 고객들은 데이터 처리와 계약 구조를 중요하게 생각하기 때문입니다.

커스텀 도메인 사용량(custom-domain usage), 표준 사용량(standard usage), 그리고 실시간 초과 사용량(real-time overages)을 각각 별도의 품목(line items)으로 반영하고, 각 항목이 자신의 지갑(wallet)과 요금표(rate card)로 추적되는 인보이스(invoice)는 조달(procurement), 감사(audit), 그리고 고객 관계 측면에서 그 정당성을 유지합니다. 이것은 제가 설계할 때 선호하는 방식은 아니지만, 의료 및 금융 서비스 분야의 조달 팀은 이 부분을 매우 중요하게 생각합니다.

크레딧(Credits) 가격 책정 뒤에 숨겨진 커다란 결정/질문은 다음과 같습니다. 크레딧은 그 내부에 가격 책정 결정 사항을 포함해야 합니다: 즉, 각 단위에 어떤 가치를 부여할 것인가 하는 점입니다. 구조적인 질문은 여러분의 빌링 시스템(billing system)이 엔지니어의 번역 작업 없이도 미터링 레이어(metering layer), 크레딧 풀(credit pools), 그리고 수익 인식(revenue recognition) 사이의 관계를 모델링할 수 있는지 여부입니다. 서로 다른 비용 기반을 가진 여러 워크로드(workloads)를 실행하는 AI 기업의 경우, 이를 위해서는 각 풀(pool)이 무엇을 나타내는지 이해하는 요금표(rate card) 레이어와 여러 개의 지갑(wallets)이 필요합니다.

자주 묻는 질문 (Frequently Asked Questions)

왜 기업이 현금 지갑(money wallet)보다 크레딧을 선호하나요?
현금 지갑은 재무적 부채(financial liability)를 생성합니다. 고객이 금액을 사용하지 않으면 입금된 금액을 돌려줘야 하기 때문입니다. 반면 크레딧은 제품 판매(product sale)입니다. 고객은 크레딧의 만료 시점을 포함하여 정의된 조건과 함께 정의된 단위를 구매합니다. 이러한 차이는 대차대조표(balance sheet), 부가가치세(VAT) 처리 방식, 그리고 수익을 인식하는 방식에 영향을 미칩니다. 많은 AI 기업에게 크레딧이 선호되는 이유는 바로 기한이 없는 의무를 지는 대신 만료 조건을 직접 설정할 수 있기 때문입니다.

크레딧 지갑(credit wallet)과 선불 잔액(prepaid balance)의 차이점은 무엇인가요?
선불 잔액은 통화로 표시된 단일 가치 풀(pool of value)입니다. 크레딧 지갑은 제품 특화 단위(분, 토큰, API 호출 등)로 표시된 유형화된 풀(typed pool)이며, 이것이 통화로 어떻게 전환되는지를 정의하는 요금표(rate card)와 무엇이 이를 소비하는지를 정의하는 미터(meter)가 함께 존재합니다. 단순한 제품의 경우 이 둘은 동일합니다. 하지만 여러 워크로드 유형이 있는 제품의 경우, 오직 지갑(wallet) 모델만이 유효합니다.

왜 AI 기업이 동일한 고객에 대해 여러 개의 크레딧 지갑을 필요로 하나요?

단위 비용(unit costs)과 마진(margins)이 서로 다른 여러 개의 별도 워크로드(workloads)를 가진 제품의 경우, 단일 풀(single pool)은 전달 비용(delivery cost)에 관계없이 모든 크레딧 소비를 동일하게 취급합니다. 여러 개의 지갑(wallets)은 그 경계를 강제합니다. 각 지갑은 고유한 요금표(rate card)와 충전(top-up) 동작을 가지며, 해당 지갑이 커버하는 워크로드에 연결됩니다. AI 빌링(billing)에서 요금표(rate card)란 무엇일까요? 요금표는 미터링 이벤트(metering event)가 어떻게 크레딧 차감으로 전환되는지를 정의하는 설정 계층(configuration layer)입니다. 음성 AI 기업의 경우, 다음과 같을 수 있습니다: 실시간 커스텀 도메인 전사(transcription) 1분 = 커스텀 지갑에서 3 크레딧 차감. 요금표는 미터링 계층(소비를 측정하는 계층)과 지갑 계층(잔액을 추적하는 계층) 사이에 위치합니다. 요금표가 애플리케이션 코드 내에 존재하면 재무 팀에서는 확인할 수 없고 업데이트하기도 어렵습니다. 이것이 바로 요금표를 빌링 시스템(billing system)에 유지해야 하는 이유입니다. 토큰-크레딧 전환(token-to-credit conversion)은 실제로 어떻게 작동할까요? 모델 계층(model layer)은 토큰을 소비합니다. 제품 계층(product layer)은 고객에게 노출되는 단위(예: 분)를 제공합니다. 빌링 계층(billing layer)은 요금표에 정의된 비율에 따라 해당 단위를 크레딧으로 변환합니다. 특정 모델 설정에서 전사(transcription) 1분은 생성하는 데 정해진 수의 토큰이 소요됩니다. 모델이 변경되어 분당 토큰 비용이 변경되면, 요금표의 설정이 업데이트됩니다. Stripe Billing은 여러 유형의 크레딧 지갑을 처리할 수 있나요? Stripe Billing은 구독 빌링(subscription billing)과 미터링 사용량(metered usage)의 기본적인 조합을 지원하며, 크레딧 부여(credit grants) 기능이 있지만 지갑(wallets)과 연결되어 있지는 않습니다. 이들을 상호작용하게 만드는 것, 특히 서로 다른 요금표를 가진 여러 크레딧 유형 간에 상호작용하게 만드는 것은 커스텀 오케스트레이션(orchestration) 코드를 필요로 합니다. 다중 워크로드 AI 제품을 구축하는 대부분의 팀은 결국 해당 오케스트레이션 계층을 직접 유지 관리하게 됩니다. Solvimon은 크레딧 지갑을 어떻게 모델링하나요? Solvimon은 지갑을 일급 프리미티브(first-class primitive)로 취급합니다. 고객당 여러 유형의 지갑을 제공하며, 각 지갑은 특정 미터(meter) 및 요금표(rate card)와 연결되고, 각각 설정 가능한 충전(top-up) 및 만료(expiry) 규칙을 가집니다.

요금표 (rate card) 레이어는 소비 단위 (consumption units)와 크레딧 차감 (credit deductions) 사이의 변환을 처리합니다. 수익 인식 (Revenue recognition)은 지갑 이벤트 (wallet events)를 기준으로 계산됩니다. 지갑 설정 (Wallet configuration)은 애플리케이션 코드 (application code)가 아닌 Solvimon에 존재합니다.