사용량 기반 과금
사용량 기반 과금은 좌석 수나 정액 월 요금이 아니라 고객이 실제로 소비한 만큼 — API 호출, 발송 메시지, 생성 이미지, 저장 기가바이트 — 청구하는 방식입니다. 동작 하나마다 실제 한계비용이 발생하는 제품에 자연스러운 형태로, 청구서가 그 계정을 서비스하는 원가를 따라 움직이고 그 회사의 인원수를 따라가지 않습니다.
네 개의 부품, 그중 가격 결정은 하나뿐
좌석 과금은 몇 명이 쓰는지를 묻습니다. 사용량 기반 과금은 이 계정이 우리에게 얼마나 일을 시켰는지를 묻습니다. 가격 질문처럼 들리지만 대부분은 엔지니어링 질문입니다. 이 모델에는 부품이 넷 있고, 그중 셋은 숫자를 말하기 전에 먼저 만들어 두어야 하는 시스템이기 때문입니다.
- 단위 — 세는 대상. 호출 하나, 메시지 하나, 크레딧 하나, 생성물 하나, 기가바이트 하나, 활성 레코드 하나. 고객이 이미 머릿속에서 쓰는 단위를 고르지 않으면 청구서마다 번역이 필요해집니다.
- 계측 — 발생하는 순간에, 고객별로, 청구의 근거로 삼을 만큼 튼튼하게 기록하는 시스템. 이것이 없거나 대략적이면 이 목록의 나머지는 아무것도 성립하지 않습니다.
- 요율 — 단위당 가격. 거의 항상 포함 제공량과 함께 둡니다. 한산한 달이 무례한 청구서가 되지 않고, 바쁜 달이 놀랄 일이 되지 않도록 하기 위해서입니다.
- 상한 — 폭주한 계정이 아무도 못 낼 청구서를 만들어 내는 것을 막는 장치. 이론상 선택. 실무에서는 필수이며, 자동 흐름이 반복에 빠질 수 있는 곳에서 특히 그렇습니다.
가격 결정인 것은 요율뿐입니다. 나머지 셋은 기반 시설이고, 그래서 계측을 믿을 수 있게 되기 전에 사용량 과금을 발표한 팀은 결국 고객의 청구서를 두고 그 고객과 다투게 됩니다.
순수 사용량, 하이브리드, 크레딧
요즘 나오는 것은 거의 세 가지 형태 안에 들어가고, 그 차이는 고객보다 당신의 매출 예측에 더 크게 작용합니다.
- 순수 사용량. 쓴 만큼만, 하한 없음. 정직하고 불안합니다. 매출을 예측하기 어렵고, 고객에게 한산한 달은 당신에게도 한산한 달입니다.
- 하이브리드. 포함 제공량이 있는 구독과 그 위의 초과분. 당신에게는 예측 가능한 매출을, 고객에게는 예측 가능한 하한을 주기 때문에 가장 흔한 답입니다.
- 크레딧. 고객이 잔액을 사고 동작이 그것을 깎아 나갑니다. AI 제품에서 인기 있는 이유는, 내부 원가가 크게 다른 동작들을 숫자 하나로 덮을 수 있고, 요금제를 다시 매기지 않고도 모델 가격을 바꿀 수 있기 때문입니다.
크레딧에는 이름을 붙여 둘 만한 고유한 함정이 있습니다. 크레딧이 통제 코드가 읽는 단위가 되는 순간, 앞으로의 모든 반올림 결정과 모든 환산 비율이 표시 변경이 아니라 청구 버그가 됩니다.
우리 제품을 이 방식으로 매기며 배운 것
AgentCeres — the AI Growth Officer, agentceres.com — 는 고객별 모델 지출을 계측해 크레딧으로 보여 줍니다. 거기서 두 가지 결정이 나왔고, 둘 다 뻔한 쪽의 반대입니다.
첫째, 원장 전체는 통화로 돌아가고 크레딧은 숫자가 화면에 닿기 직전의 한순간에만 존재합니다. 모든 한도, 저장된 모든 잔액, 청구서의 모든 줄이 통화 단위이고, 단 하나의 변환 경계가 그것을 고객이 보는 크레딧으로 바꿉니다. 쓸데없는 우회처럼 보이지만, 대안인 크레딧 기반 통제가 반올림 결정을 영구적으로, 그것도 전 구간에서 한꺼번에 돈 버그로 바꾼다는 걸 알게 되면 달라집니다.
둘째, 포함 제공량은 의도적으로 요금제 가격을 우리 비율로 환산한 값이 아닙니다. 정확히 환산하면 아무도 외울 수 없는 숫자가 나오기에, 읽기 쉬운 숫자로 올림하고 그만큼의 마진을 감수합니다. 그리고 그 이유를 상수 바로 옆에 적어 두었습니다. 다음 사람이 이를 "정리"해 버리지 않도록요. 가격 페이지가 결코 보여 주지 않는 부분이 이것입니다. 가격과 제공량은 두 개의 결정이지 하나가 아니며, 하나로 취급하는 것이 둘 중 어느 하나가 움직이는 순간 문구가 낡아 버리는 이유입니다.
쓰지 말아야 할 때
사용량 기반 과금이 자동으로 더 현대적인 선택인 것은 아닙니다. 정액제가 그냥 더 나은 상황이 넷 있습니다.
- 한계비용이 거의 0일 때. 동작 하나가 더 들어가도 비용이 없다면, 계측해서 얻는 것은 제품을 쓰는 대신 카운터를 쳐다보는 고객뿐입니다.
- 구매자가 고정된 숫자를 필요로 할 때. 중견 기업의 구매팀은 분기마다 변동 청구서를 방어하느니 기꺼이 더 냅니다.
- 아직 계측할 수 없을 때. 추정치는 대시보드에는 충분하고 청구서에는 실격입니다.
- 단위를 고객이 통제할 수 없을 때. 자기가 유발하는 것이 보이지 않는 항목에 대한 청구는, 계산이 아무리 공정해도 자의적으로 읽힙니다.
모델이 아니라 숫자 자체를 고민 중이라면 AI 제품 가격 정하기가 원가가 움직이는 상황에서 요율에 도달하는 방법을 다룹니다. 빠진 쪽이 계측이라면 Flexprice가 직접 만들기 전에 안을 들여다볼 수 있는 오픈소스입니다. 그리고 여기 온 이유가 에이전트 자체를 직접 만들까 고민해서라면, 그 결정에는 따로 페이지가 있습니다.
FAQ
- 사용량 기반과 좌석 기반, 어느 쪽이 더 잘 전환됩니까?
- 추상적으로는 어느 쪽도 이기지 않습니다. 망가지는 방식이 다를 뿐입니다. 사용량은 시작 문턱을 낮춥니다. 작은 고객은 적게 내니까요. 그리고 원가가 활동량에 따라 커진다면 정직한 방식이기도 합니다. 좌석은 예측이 쉽고 위원회에 팔기가 훨씬 쉽습니다. 실무적인 시험은 고객이 두 주쯤 써 본 뒤 자기 청구액을 예측할 수 있느냐입니다. 못 한다면 지원 시간은 제품이 아니라 청구서에 쓰이게 됩니다.
- 고객이 청구서에 놀라지 않게 하려면?
- 장치는 셋이고 셋 다 필요합니다. 제품 안에서 보이는 잔액이나 미터. 청구 화면에 들어가지 않고도 현재 위치를 알 수 있게 하려는 것입니다. 제공량이 바닥나기 한참 전의 알림, 바닥난 뒤가 아니라요. 그리고 청구를 계속하는 대신 작업을 멈추는 강한 상한. 상한이 다들 건너뛰는 부분이자 가장 중요한 부분입니다. 반복에 빠진 자동 흐름은 지치지 않으니까요.
- 청구 플랫폼이 필요합니까, 세기만 하면 됩니까?
- 세는 것은 쉬운 절반입니다. 어려운 절반은 그 집계가 재시작을 견디고, 같은 이벤트가 두 번 와도 중복되지 않으며, 올바른 고객에게 귀속되고, 실제로 청구한 금액과 맞아떨어져야 한다는 점입니다. 테이블 하나와 야간 배치로 시작하는 팀이 많고 그것도 괜찮습니다. 다만 운영을 책임지겠다고 약속하는 대상은 가격 페이지가 아니라 계측 계층이라는 점만 알아 두십시오.
- 크레딧은 돈과 같은 것입니까?
- 같다고 정하면 같지만, 대개는 같지 않은 편이 낫습니다. 크레딧은 표시 단위입니다. 원가가 다른 동작들을 숫자 하나로 덮게 해 주고, 공급자 가격이 바뀌어도 요금제를 다시 내걸지 않게 해 줍니다. 표시 단위로 두십시오. 크레딧이 통제 로직이 읽는 숫자가 되는 순간, 반올림 문제를 청구 시스템 안으로 옮겨 놓은 것입니다.
An AI growth team that runs this for you
AgentCeres is a managed AI marketing team — you approve what ships. 14-day free trial, from $39/month.