사용량 기반 과금(Usage-based pricing, UBP)은 네 가지 결정 사항이 하나의 트렌치코트 안에 모여 있는 것과 같습니다. 즉, 무엇을 측정할 것인가(meter), 어떤 단위로 요금을 부과할 것인가(unit), 요금표(rate card)를 어떻게 구성할 것인가, 그리고 약정(commits)과 초과 사용량(overages)을 어떻게 처리할 것인가입니다. 저는 많은 팀이 이 중 하나를 잘못 결정했다가 나중에야 이를 발견하고, 결국 설계를 다시 해야 하는 상황을 수없이 보았습니다.

보통 창업자는 Snowflake의 회고록을 읽거나, Tomasz Tunguz의 글을 보고, 혹은 유출된 이사회 자료를 접한 뒤, 누군가가 Notion 문서에 "사용량 기반으로 가자"라고 적고 내장된 AI를 통해 몇 가지 원칙을 설계하곤 합니다. 그리고 몇 주 후 마침내 서비스가 출시되면... 수많은 문제점을 발견하게 됩니다.

오늘날 제가 UBP에 대해 읽는 대부분의 내용은 "가치와 가격을 일치시켜라" 또는 "고객의 성공을 위해 최적화하라"와 같은 컨설팅 스타일의 아이디어들입니다. 솔직히 말씀드리면 저 또한 그런 글을 쓰곤 합니다. 물론 틀린 말은 아니지만, 출시를 며칠 앞두고 측정 단위(meter)를 API 호출(API call)로 할지 아니면 성공적인 트랜잭션(successful transaction)으로 할지 결정해야 하는 상황에서는 여전히 도움이 되지 않을 수 있습니다.

설계 문제는 현실에 뿌리를 두고 있으므로, 어떻게 설계해야 하는지 살펴보겠습니다.

The four failure modes of usage+based pricing

사용량 기반 과금(Usage-based pricing)이란 무엇인가 (요약)

사용량 기반 과금(Usage-based pricing, UBP)은 고객이 계정 수(seat)나 플랫폼 이용료와 같은 고정 요금(flat fee) 대신, 실제로 소비한 제품의 양에 따라 비용을 지불하는 모델입니다.

일반적으로 단위(unit)는 API 호출(Twilio, OpenAI), 기가바이트(Snowflake, Datadog), 처리된 이벤트(Segment), 번역된 글자 수(DeepL), 또는 가치와 연결된 기타 측정 가능한 수량이 될 수 있습니다.

결과 기반(Outcome-based) 모델도 결과물에 대해 동일한 방식으로 요금을 부과한다는 점에서 종종 사용량 기반 모델에 포함됩니다.

사용량은 요청(request)당 측정하거나, 배치(batched) 처리하거나, 특정 기간 경계에서 요약(summarised)할 수 있습니다. 그 후 가격은 선형(linear), 계층형(tiered), 또는 대량 구매 할인(volume-discounted) 방식으로 책정될 수 있습니다. 계약 방식은 종량제(pay-as-you-go), 선불 크레딧(prepaid credits), 또는 초과 사용량이 포함된 최소 약정(committed minimum) 방식이 될 수 있습니다.

사용량 기반 과금 방식의 표면적인 측면을 살펴보았으니, 이제 결정해야 할 사항들을 살펴보겠습니다.

무엇이 올바른 미터(meter)인가?

미터(meter)는 당신이 '측정하는' 대상입니다. 따라서 잘못된 미터를 선택한다는 것은 청구서가 공정한지에 대해 고객과 오랫동안 싸워야 함을 의미합니다.

좋은 미터의 조건은 무엇일까요? 저는 네 가지 속성이 있다고 생각합니다.

1. 고객이 얻는 가치와 상관관계가 있어야 합니다. 예를 들어, Adyen은 API 호출당이 아니라 성공적인 트랜잭션(transaction)당 비용을 청구합니다. Snowflake는 쿼리(query)당이 아니라 컴퓨팅(compute) 초당 비용을 청구합니다. 고객의 비즈니스가 성장할 때 고객의 청구 금액도 정확히 함께 상승합니다. 가치와 상관관계가 없을 때, 고객은 청구서를 마치 더 큰 세금을 내는 것처럼 느끼며 이탈(churn)하게 됩니다 (혹은 더 나쁜 경우, 비용을 0으로 깎아달라고 협상합니다).

2. 매출원가(COGS, cost of goods sold)와 상관관계가 있어야 합니다. 만약 당신이 AI 기업이라면, 추론(inference) 비용은 토큰(token)당 발생합니다. 요청(request)당 고정된 미터를 사용한다면, 고객이 매우 매우 긴 프롬프트(prompt)를 보내는 순간 매출 총이익률(gross margin)이 파괴될 것입니다. 최근 한 컨설팅 회사가 토큰 비용으로 5억 달러를 지출했다는 이야기가 있었습니다…

3. 감사 가능(auditable)해야 합니다. 당신과 고객 모두 독립적으로 측정하여 동일한 수치에 도달할 수 있어야 합니다. 만약 당신의 재무 팀이 로우 이벤트(raw events)로부터 어제의 사용량을 재구성할 수 없다면, 고객 또한 할 수 없으며, 그것이 바로 고객이 이의를 제기할 청구서가 됩니다.

4. 시간이 지나도 안정적이어야 합니다. 미터의 정의가 매 분기마다 바뀌어서는 안 됩니다. 고객은 이를 바탕으로 예측(forecast)을 세우기 때문입니다. 만약 2분기와 3분기 사이에 '활성 사용자(active user)'의 정의를 다시 내린다면, 당신은 방금 갱신 주기(renewal cycle)를 망쳐버린 것입니다.

대부분의 B2B 제품에서 미터는 이벤트(API 호출, 생성된 문서, 워크플로 실행)이거나 시간 경과에 따른 리소스(컴퓨팅 초, 스토리지 GB-월, 월간 활성 사용자) 중 하나입니다.

하나만 선택하세요! 두 개를 선택한 뒤 고객이 어떤 것이 주된 것인지 이해하기를 바라지 마십시오…

예를 들어 보겠습니다. Twilio는 API 호출(API call)당 비용을 청구할 수도 있었지만, 대신 전송된 메시지(delivered message)당 비용을 청구합니다. 1만 건을 보내고 9천 건이 전송된 고객은 9천 건에 대해서만 비용을 지불합니다. 전송되지 않은 1천 건은 Twilio의 네트워크 문제입니다. 측정 기준(meter)이 정직하고 방어 가능할 때, 청구서 또한 정직해집니다.

Snowflake는 쿼리(query)당 또는 로드된 데이터(data loaded)당 비용을 청구할 수도 있었습니다. 이는 흔히 사용되는 방식이었습니다. 대신, 그들은 컴퓨팅 시간(compute)의 초(second) 단위로 비용을 청구합니다. 전체 테이블을 스캔하는 잘못 작성된 쿼리는 인덱스(index)를 사용하는 쿼리보다 더 많은 비용이 발생합니다. 이 측정 기준은 고객의 행동을 Snowflake의 매출원가(COGS)와 일치시킵니다. (측정 기준 설계를 경쟁 우위의 지렛대로 활용하십시오. 대부분의 팀은 잘못된 측정 기준을 출시한 후에야 이 지렛대의 존재를 깨닫습니다.)

요금표(Rate card)란 무엇인가?

요금표는 _측정 단위당 가격_을 의미합니다.

가장 먼저 던져야 할 질문은 다음과 같습니다: 선형(linear), 계층형(tiered), 아니면 대량 할인(volume-discount)인가?

선형 (Linear)

선형 방식이 가장 단순합니다. 예를 들어, 호출 횟수에 상관없이 API 호출당 $0.01를 부과하는 방식입니다. 매출원가(COGS) 또한 선형적이고 경쟁 환경이 이를 허용할 때 사용하십시오.

chart via BVP

(차트 출처: BVP)

계층형 (Tiered)

계층형은 특정 임계값(thresholds)에 따라 요율이 변하는 것을 의미합니다. 처음 10만 건은 무료, 다음 100만 건은 $0.02, 그 이상은 $0.005를 부과하는 식입니다. 계층형 요금표는 사용량이 이질적일 때(어떤 고객은 월 5천 건을 사용하고, 어떤 고객은 5백만 건을 사용하는 경우)와, 대형 고객으로부터의 마진을 잃지 않으면서 낮은 가격대로 소규모 고객을 확보하고 싶을 때 효과적입니다. Vercel은 계층형 방식을 사용합니다. Datadog도 계층형을 사용합니다. AWS는 수천 페이지의 각주와 함께 계층형 방식을 사용합니다.

대량 할인 (Volume discounts)

대량 할인 (Volume discounts)은 계층형 (Tiered) 방식의 SaaS 스타일 연장선에 있습니다. 특정 임계값(Threshold)을 넘어서면 모든 단위에 대해 동일한 단위당 가격이 적용되는 방식입니다. 고객에게 설명하기는 더 쉽지만, 내부적으로 모델링하기는 더 어렵습니다. 고객이 이해하기 쉬운 방식을 선택하십시오.

다만, 아주 작은 단위의 가격 책정(Penny pricing)에 대해 한 가지 유의할 점이 있습니다. 토큰당 $0.0001와 같은 가격은 정직한 가격처럼 보입니다. 하지만 이는 고객이 그 가치를 이해하기 위해 1,000만(10M)을 곱해야 함을 의미합니다. 아주 작은 단위의 가격 책정은 청구서와의 정서적 거리감을 만들어내는데, 이는 초기 도입(Adoption)에는 매우 유리하지만 갱신(Renewal) 시점의 신뢰 측면에서는 최악입니다. 반올림하십시오. 묶음(Bundle)으로 만드십시오. 고객이 논리적으로 추론할 수 없는 소비 단위를 만들어내지 마십시오.

chart via BVP

(chart via BVP)

약정(Commits)과 초과 사용료(Overages)를 어떻게 구성할 것인가?

대부분의 기업은 종량제 (Pay-as-you-go)로 시작하여, 계약 규모가 커짐에 따라 약정 (Commits) 방식으로 전환합니다. 가장 효과적인 구조는 다음과 같습니다:

피해야 할 두 가지 실패 유형은 다음과 같습니다:

1. 이월 (Rollover) 기능이 없는 약정은 '기프트 카드 문제'를 발생시킵니다. 고객이 월 1,000만(10M) 건의 API 호출을 약정했는데, 도입 단계라 1월에는 600만(6M) 건만 사용했다고 가정해 봅시다. 12월이 되어서야 고객은 사용하지도 않은 월 400만(4M) 건의 호출에 대해 비용을 지불해 왔다는 사실을 깨닫게 됩니다. 이는 버려진 가치 (Stranded value)입니다. 고객은 속았다고 느끼며, 갱신 단계에서 관계가 냉각됩니다.

2. 너무 공격적으로 책정된 초과 사용료 (Overages)는 확장 (Expansion)을 저해합니다. 만약 초과 사용 요율이 약정 요율보다 3배 높다면, 고객은 페널티를 피하기 위해 약정 수치에 도달하기도 전에 내부적으로 사용량을 엄격하게 제한할 것입니다. 이는 매출을 억제하면서 청구서만 최적화하는 결과를 초래합니다.

크레딧 (Credits)은 그 형태 사이의 어딘가에 위치합니다... 크레딧은 고객이 만료 규칙과 함께 모든 미터 (meter)에 대해 차감할 수 있는 현금 또는 기타 지표의 선불 잔액 (prepaid balance)입니다. 잘 설계된 경우 유연성(고객이 필요한 엔드포인트에 1,000만 건의 호출을 자유롭게 사용할 수 있음)을 제공합니다. 하지만 부주의하게 사용하면 이는 "파기 (breakage)" 매출이 되어 재무 감사 부채 (finance audit liability)가 됩니다.

크레딧은 가격 책정 모델이 아니라 아키텍처 결정 사항입니다.

기존 고객을 사용량 기반 과금 모델(usage-based pricing)로 어떻게 전환시키나요?

이 부분은 아무도 쓰지 않는 내용인데, 왜냐하면 원활한 소통 능력이 필요하고 고객이 무엇을 가치 있게 여기는지 이해해야 하는 어려운 부분이기 때문입니다.

정해진 플레이북(playbook)이나 템플릿은 없으며, 일반적으로 단순히 스위치를 전환하는 것만으로는 불가능합니다.

기존 플랜을 사용하는 모든 고객은 계약, 예산, 그리고 기대치를 가지고 있습니다. 만약 고객을 놀라게 한다면 갱신 시의 신뢰를 잃게 됩니다.

하지만, 효과적으로 작동하는 일련의 순서를 따를 수는 있습니다:

1. 1단계: 섀도 빌링 (shadow billing). 60~90일 동안 각 고객이 새로운 모델 하에서 얼마를 지불하게 될지 계산하여 송장의 메모란에 기재합니다. 재무적 영향은 없습니다. 고객은 앞으로 다가올 상황을 미리 볼 수 있습니다. 재무 팀은 계약 변경 전에 코호트 (cohort) 영향을 모델링할 수 있습니다.

2. 2단계: 신규 계정에만 선택적 적용 (opt-in). 신규 고객에게는 사용량 기반 과금 모델(UBP)을 기본값으로 제공합니다. 기존 고객군은 기존 조건대로 유지합니다. 누구에게도 피해를 주지 않으면서 제품 피드백을 받을 수 있습니다.

3. 3단계: 혜택을 동반한 자발적 전환. 기존 고객에게 가격 보호 보장 (price-protection guarantee)이나 전환을 위한 일회성 크레딧 증정을 제안합니다. 일부는 응할 것이지만, 대부분은 4단계 전까지는 움직이지 않을 것입니다.

4. 4단계: 갱신 시 강제 전환. 계약 갱신 시점에 새로운 모델이 유일한 옵션이 됩니다. 이 시점에 도달하면 여러분은 6~12개월 치의 섀도 데이터 (shadow data)와 고객 레퍼런스를 확보하게 됩니다. 대화의 내용은 "여기 청구서가 있고, 여기 근거 데이터가 있으며, 유연성 측면에서의 이점은 이렇습니다"가 됩니다. 일부 고객은 이탈 (churn)할 것입니다. 이에 대한 계획을 세우십시오.

이 과정은 여전히 매우 오래 걸릴 수 있습니다. 저희 고객 중에는 기술적인 작업은 단 며칠 만에 끝났지만, 계약 갱신(contract rollover)에만 9개월이 걸린 사례도 있었습니다. 불행하게도 이것이 현실적인 모습입니다.

과금 인프라(Billing infrastructure)가 처리해야 할 사항

사용량 기반 과금(Usage-based pricing)이 실제 운영 환경에서 실패하는 이유는 지루한 이유들 때문입니다. 대부분은 가격 책정(pricing)의 문제가 아니라 과금 인프라(billing-infrastructure)의 문제입니다.

시스템은 대규모로 이벤트를 수집(ingest)하고, 중복을 제거(deduplicate)하며, 이를 고객에게 대조(reconcile)하고, 적절한 요율표(rate card)를 적용해야 합니다. 또한 중복 계산 없이 약정 사용량(commits)과 초과 사용량(overages)을 처리하고, 재무 팀이 감사(audit)할 수 있는 송장(invoice)을 생성해야 합니다. 대부분의 팀은 Stripe Billing, 미터링 서비스(metering service), 스프레드시트, 그리고 4,000줄에 달하는 오케스트레이션(orchestration) 코드를 이어 붙여 이를 구현합니다. 이제 그 코드가 그들의 실제 과금 시스템이 된 것입니다. 이는 매우 취약합니다.

사용량 기반 과금을 출시하기 전에 던져야 할 인프라 질문은 다음과 같습니다:

1. 고객별, 미터(meter)별, 기간별 사용량을 1분 이내에 계산할 수 있습니까? 그렇지 않다면, 월 결산(monthly close)에 일주일이 걸릴 것입니다.

2. 재무 팀이 모든 항목을 원시 이벤트(raw events)까지 추적하여 감사할 수 있습니까? 그렇지 않다면, 모든 분쟁(dispute)에서 패배하게 될 것입니다.

3. 고객이 송장과 정확히 일치하는 사용량 내역을 셀프 서비스(self-serve)로 확인할 수 있습니까? 그렇지 않다면, 고객 지원 티켓(support ticket) 양이 세 배로 늘어날 것입니다.

4. 과거의 송장을 다시 작성하지 않고도 주기 중간에 요율표(rate card)를 변경할 수 있습니까? 그렇지 않다면, 모든 가격 실험은 6주짜리 프로젝트가 됩니다.

Solvimon은 미터링(metering), 원장(ledger), 요율표 엔진(rate-card engine)을 하나의 시스템으로 실행하므로, 위의 인프라 질문들이 더 이상 엔지니어링 문제가 되지 않습니다. 다섯 가지 도구를 이어 붙이는 것과는 다릅니다.

자주 묻는 질문 (Frequently Asked Questions)

사용량 기반 과금(Usage-based pricing)이란 무엇인가요?

사용량 기반 과금은 고객이 고정된 구독료(flat subscription fee)를 내는 대신, 제품의 실제 소비량(API 호출, 기가바이트, 이벤트, 컴퓨팅 초 단위 등)에 따라 비용을 지불하는 과금 모델입니다. 각 미터(meter)는 추적되며, 종종 계층형(tiered) 또는 볼륨 할인(volume discounts)이 적용된 정의된 요율로 청구됩니다.

UBP는 하이브리드 과금 모델(hybrid pricing)과 어떻게 다른가요?