크레딧 모델
Credit Model
개념
고객이 적립분을 미리 사 두고 기능을 쓸 때마다 잔액에서 깎아 나가게 하는 과금 방식입니다.
등장 배경
제품에 쓸 때마다 돈이 나가는 기능이 붙기 시작하면서 문제가 생겼습니다. 문서를 요약해 주는 기능은 실행할 때마다 외부 모델 호출 비용이 들고, 대용량 내보내기나 문자 발송도 건당 비용이 붙습니다. 매달 정해진 금액만 받는 구독으로는 이런 기능을 감당할 수 없습니다. 같은 요금을 내는 고객 중 누군가는 한 달에 세 번 쓰고 누군가는 삼천 번 쓰는데, 삼천 번 쓰는 고객 한 명이 그 요금제 전체의 이익을 지워 버립니다.
그렇다고 쓴 만큼 청구하는 쪽으로 옮기면 다른 벽에 부딪힙니다. 고객 입장에서는 이번 달 청구서가 얼마일지 월말까지 알 수 없습니다. 담당자가 사내 승인을 받아 둔 예산은 월 50만 원인데 청구서가 120만 원으로 오면 그 사람이 곤란해집니다. 실제로 이런 일을 한 번 겪은 팀은 기능을 더 잘 쓰는 대신 아예 꺼 버립니다.
크레딧 모델은 이 두 문제를 돈 받는 순서를 바꿔 푼 방식입니다. 쓴 양을 세는 것은 그대로 두되, 청구를 나중에 하지 않고 고객이 쓸 만큼을 먼저 사게 합니다. 고객은 자기가 정한 금액 위로는 절대 청구되지 않는다는 것을 아는 상태에서 기능을 쓰고, 파는 쪽은 비용이 발생하기 전에 현금을 먼저 받습니다.
작동 방식
고객이 크레딧을 묶음으로 사 두면, 기능을 한 번 실행할 때마다 정해진 만큼이 잔액에서 빠집니다. 설계할 때 정해야 하는 것은 다섯 가지입니다.
- 차감 단위 — 어떤 동작 한 번에 몇 크레딧을 뺄지 정합니다. 문서 요약 1회에 5크레딧, 대용량 내보내기 1건에 20크레딧 같은 식입니다. 이 숫자는 건당 매출원가, 그러니까 그 동작을 처리하는 데 실제로 나가는 비용에 맞춰 잡습니다. 원가와 어긋나게 잡아 두면 많이 쓰는 고객일수록 손해가 커집니다.
- 충전 묶음 — 크레딧을 파는 단위를 정합니다. 1만 크레딧에 5만 원, 5만 크레딧에 20만 원처럼 많이 살수록 단가를 낮추는 것이 보통입니다.
- 잔액 표시 — 남은 크레딧과 이번 동작에 들어갈 크레딧을 실행 전에 보여 줍니다. 이 표시가 없으면 고객은 얼마가 빠지는지 모른 채 누르게 되고, 결국 안 쓰는 쪽을 고릅니다.
- 소진 시 처리 — 잔액이 0이 됐을 때 무엇을 할지 정합니다. 기능을 잠그고 충전을 안내하는 방식과, 미리 등록한 카드로 자동 충전하는 방식이 있습니다. 자동 충전은 작업이 끊기지 않는 대신 예산 통제라는 이 모델의 장점을 약하게 만듭니다.
- 유효기간 — 산 크레딧이 언제까지 유효한지 정합니다. 12개월이 흔하고, 기간이 지나면 남은 분은 소멸합니다. 너무 짧게 잡으면 고객이 손해 보는 느낌을 받아 재충전을 꺼립니다.
돈이 먼저 들어온다고 해서 그 금액이 바로 매출이 되지는 않습니다. 받은 돈은 고객이 크레딧을 실제로 쓰기 전까지 선수수익으로 잡힙니다. 아직 제공하지 않은 몫이라 매출로 셀 수 없는 금액이라는 뜻입니다.
쓰이는 곳
가장 잘 맞는 자리는 기능 한 번에 원가가 또박또박 발생하는 제품입니다. 외부 API, 그러니까 다른 회사 프로그램에 요청을 보내 결과를 받아 오는 창구를 호출할 때마다 비용이 나가는 기능이 대표적입니다. 원가가 사용량에 정비례하니 청구도 사용량에 붙이는 편이 자연스럽고, 그 청구를 앞당긴 것이 크레딧입니다.
기업 고객의 구매 절차와도 잘 맞습니다. 규모가 있는 회사는 금액이 달라지는 청구서를 받을 때마다 결재를 다시 올려야 합니다. 연초에 한 번 발주를 내고 1년 치 크레딧을 받아 두면 그 절차가 한 번으로 끝납니다.
다른 과금 방식 위에 얹어 쓰는 경우도 많습니다. 계정 수로 받는 기본 요금은 그대로 두고, 돈이 드는 기능만 크레딧으로 따로 파는 식입니다.
다만 월 반복 매출, 즉 매달 반복해서 들어오는 매출을 보는 팀에게는 이 방식이 다루기 까다롭습니다. 충전은 몰아서 일어나고 소진은 흩어져 일어나기 때문에, 이번 달에 받은 돈으로는 고객이 제품을 계속 쓰고 있는지 알 수 없습니다. 그래서 크레딧 모델을 쓰는 팀은 충전액 대신 소진율을 봅니다. 산 크레딧을 다 쓰지 못하고 남긴 고객은 다음 충전을 하지 않을 확률이 높습니다.
실무 용례
"이 기능은 구독에 넣지 말고 크레딧으로 빼시죠. 호출당 비용이 그대로 나가요."
정액 요금제 안에 두면 많이 쓰는 고객에게서 손해가 난다는 뜻입니다.
"크레딧 단가를 5에서 8로 올리면 그건 그냥 가격 인상이에요."
크레딧 개수는 그대로 보여도 고객이 같은 돈으로 할 수 있는 일이 줄어든다는 지적입니다.
"이번 달 충전액은 늘었는데 소진율이 40퍼센트예요. 매출로 보면 안 됩니다."
돈은 들어왔지만 고객이 제품을 그만큼 쓰지 않고 있다는 경고입니다.
페이지덱이 문서 요약 기능을 내놓을 때 이 논의가 있었습니다. 지현은 상위 요금제에 포함시키자고 했고, 태오가 호출 한 번에 나가는 비용을 계산해 왔습니다. 사내 문서를 옮겨 오는 고객이 하루에 수백 건을 돌리는 경우가 있어서, 그 한 회사만으로 요금제 이익이 사라지는 계산이 나왔습니다. 결국 요약은 크레딧으로 빼고 요금제마다 매달 일정량을 얹어 주는 쪽으로 정했습니다.
규원은 조건을 하나 걸었습니다. 실행 버튼 옆에 들어갈 크레딧과 남은 잔액을 항상 보여 줄 것. 수아가 상담에서 가장 많이 듣는 질문이 "이거 누르면 얼마 나가요" 였기 때문입니다.
흔한 오해
미리 받은 돈을 매출로 읽는 경우가 가장 흔합니다. 통장에 실제로 들어온 금액이니 그렇게 보기 쉽습니다. 하지만 이 돈은 고객이 크레딧을 쓸 때 조금씩 매출이 되는 금액이고, 쓰지 않으면 언젠가 돌려주거나 소멸 처리해야 할 빚에 가깝습니다. 충전액만 보고 분기 계획을 세운 팀은 다음 분기에 충전이 멈추는 순간 두 배로 흔들립니다. 그 분기에는 새로 들어오는 돈도 없고, 지난 분기에 팔아 둔 크레딧을 처리하는 원가만 계속 나가기 때문입니다.
고객에게 무조건 유리한 방식이라고 보는 오해도 있습니다. 쓴 만큼만 깎이니 낭비가 없어 보이는 것은 사실입니다. 그런데 잔액이 보이는 순간 고객은 쓸 때마다 값어치를 따지게 됩니다. 요약 한 번에 5크레딧이 빠지는 것을 보면 이 문서에 5크레딧을 쓸 만한지 잠시 고민하고, 그 고민이 반복되면 기능을 덜 쓰게 됩니다. 그래서 제품에 자리 잡아야 할 핵심 기능까지 크레딧으로 빼면, 고객이 그 기능을 익히기도 전에 아껴 쓰기 시작합니다.
자주 헷갈리는 용어
| 용어 | 언제 청구하는가 | 크레딧 모델과의 차이 |
|---|---|---|
| 사용량 기반 과금 | 쓴 뒤에 그달치를 청구 | 세는 방식은 같고 순서만 다릅니다. 고객은 한도를 미리 정하지 못하고, 파는 쪽은 돈을 나중에 받습니다 |
같이 보면 좋은 페이지
마지막 업데이트 2026-09-16