사용량 기반 과금

값을 매기는 가장 쉬운 방법은 한 달에 얼마로 못 박는 것입니다. 파는 쪽은 다음 달 매출을 지금 계산하고 사는 쪽은 결재를 한 번만 올리면 됩니다. 그런데 고객마다 쓰는 양이 열 배, 백 배씩 벌어지는 제품에서는 이 방식이 양쪽 다 불편하게 만듭니다.

적게 쓰는 고객은 비싸다고 느낍니다. 갱신 협상마다 한 달에 세 번 열어 보는데 왜 매일 쓰는 회사와 같은 금액을 내는지 묻는 자리가 생깁니다. 반대쪽 끝에서는 파는 쪽이 손해를 봅니다. 한 고객이 전체 저장 비용의 40퍼센트를 쓰는데 받는 돈은 가장 가벼운 고객과 같은 식입니다.

정액제로 이 둘을 동시에 풀 수 없습니다. 금액을 내리면 무거운 고객에서 적자가 커지고, 올리면 가벼운 고객이 떠납니다. 사용량 기반 과금은 금액을 하나로 정하는 일 자체를 그만두고 고객마다 다른 청구서를 만들어 이 갈림길을 비켜 갑니다. 계량기가 돌아간 만큼만 내는 전기 요금과 같은 방식입니다.

무엇을 셀지 단위를 정하고, 주기마다 그 단위가 몇 번 발생했는지 재서 단가를 곱합니다. 청구서 금액은 매달 달라집니다.

1. 세는 단위를 정합니다. 저장 용량 1기가, 내보내기 1,000건, 발송한 메일 1통처럼 고객이 이해할 수 있는 크기여야 합니다. 단위를 잘못 잡으면 고객이 자기 청구서를 예상하지 못합니다. 자기가 몇 초를 쓰는지 짐작할 수 없는 서버 처리 시간 1초 같은 단위가 그렇습니다.
2. 단가와 무료 구간을 정합니다. 저장 용량 1기가당 500원, 처음 10기가는 무료라고 정하면 한 달에 34기가를 쓴 팀은 24기가에 대해 1만 2,000원을 냅니다. 무료 구간은 소액 청구서를 막는 장치입니다. 800원을 받으려고 결제 수수료 300원을 내는 것보다 안 받는 편이 낫습니다.
3. 재는 배관을 만듭니다. 사용 기록을 고객별로 쌓고 주기마다 합산하는 구조가 제품 안에 있어야 합니다. 이 숫자가 곧 청구 금액이라서 틀리면 환불과 사과가 따라옵니다. 고객이 같은 숫자를 볼 화면도 함께 만듭니다.
4. 놀라지 않게 막는 장치를 둡니다. 예상 금액을 미리 보여 주고, 평소의 세 배를 넘으면 알림을 보내고, 고객이 스스로 한도를 걸어 둘 수 있게 합니다. 이 장치가 없으면 실수로 같은 작업을 반복한 고객에게 평소의 스무 배 청구서가 나가고, 그 한 번이 계약을 끝냅니다.

주기마다 정해진 금액을 받는 구독과 겹쳐 쓰는 것이 보통입니다. 기본료 9만 9,000원에 포함된 저장 용량 50기가를 넘긴 만큼만 따로 받는 식으로 두 방식을 한 벌로 맞춥니다. 예측 가능한 매출은 기본료로 확보하고 무거운 고객에게서 드는 비용은 초과분으로 회수하는 구조입니다.

고객마다 쓰는 양이 크게 벌어지고, 그 양이 고객이 얻는 값과 함께 움직이는 제품에 맞습니다. 메일 발송 서비스가 전형입니다. 한 달에 1,000통 보내는 가게와 300만 통 보내는 회사를 같은 금액으로 묶을 수 없고, 많이 보내는 쪽이 그만큼 더 버니 금액이 올라가도 납득합니다. 클라우드 서버, 결제 대행, 지도 조회, 언어 모델 호출이 모두 같은 구조를 씁니다. 저장 용량이나 데이터 전송처럼 원가가 사용량에 비례하는 항목이면 그 원가를 청구서에 그대로 이어 붙이는 셈이라 무거운 고객이 늘어도 적자가 안 됩니다.

맞지 않는 자리도 분명합니다. 사용량이 고객이 얻는 값과 따로 움직이면 이 방식은 벌이 됩니다. 협업 문서 툴에서 문서 개수로 값을 받으면 고객은 문서를 덜 만드는 쪽으로 움직이고, 그것은 제품을 덜 쓴다는 뜻입니다. 기업 고객의 결재 절차도 걸림돌입니다. 1년 예산을 미리 승인받는 회사는 금액이 안 정해진 계약서를 통과시키기 어려워서, 연간 사용량을 미리 약정하고 초과분만 정산하는 형태로 바꿔 팝니다.

사용자 한 명이 내는 평균 매출인 사용자당 평균 매출도 읽는 법이 달라집니다. 고객 간 편차가 커서 평균 하나로는 아무것도 안 보이고, 상위 10퍼센트와 나머지를 나눠야 분포가 드러납니다.

"이번 달 사용량 과금분이 기본료보다 많이 나온 고객이 열두 곳이에요."

요금제 설계가 실제 사용과 어긋나서 등급을 다시 짤 때가 됐다는 뜻입니다.

"사용량 기반으로 가면 다음 분기 매출을 못 잡습니다."

금액이 미리 정해지지 않아 재무 계획이 어려워진다는 반대 의견입니다.

"일단 무료 구간 10기가로 열고 초과분만 받는 걸로 하죠."

작게 쓰는 고객은 그대로 두고 무거운 고객에게서만 비용을 회수하자는 제안입니다.

페이지덱은 팀 단위 정액 요금제로 시작했는데 1년쯤 지나 저장 용량 청구서가 문제로 올라왔습니다. 고객 200곳 중 여덟 곳이 영상과 설계 파일을 올려 전체 저장 비용의 절반 가까이를 쓰고 있었습니다. 규원은 이 여덟 곳의 요금을 올리자고 했고, 수아는 그러면 갱신 때 다 나간다고 했습니다.

지현이 가져온 안은 기본 요금제에 저장 용량 50기가를 포함하고 그 위로만 1기가당 500원을 받는 것이었습니다. 200곳 중 192곳은 청구서가 그대로였고 여덟 곳만 금액이 올랐습니다. 올린다는 사실을 두 달 전에 알리고 사용량 화면을 먼저 열자 여덟 곳 중 다섯 곳이 안 쓰는 파일을 지워 50기가 아래로 내려왔습니다.

쓴 만큼 받으니 고객에게 언제나 유리하고 매출도 저절로 따라 오른다고 여기는 경우가 많습니다. 공정해 보이는 구조라서 그렇게 읽힙니다. 하지만 고객이 실제로 겪는 것은 얼마가 나올지 모르는 청구서입니다. 예산을 정해 둔 담당자는 불확실한 금액을 피하려고 사용을 줄이고, 줄인 사용은 제품이 자리를 잡지 못한다는 뜻입니다. 안 쓰는 달에 0원이 나온다는 것은 파는 쪽에서 보면 들어오던 돈이 사라진다는 뜻입니다. 그래서 대개 기본료를 함께 두고 예상 금액을 미리 보여 주는 장치를 붙입니다.

값만 바꾸면 되는 일로 보는 것도 흔합니다. 요금표를 고치는 일처럼 보이지만 실제로 필요한 것은 고객별 사용 기록과 합산, 청구, 환불까지 이어지는 배관입니다. 이 배관 없이 요금제를 먼저 발표하면 매달 담당자가 기록을 손으로 뽑아 금액을 만들게 됩니다. 고객이 500곳이 되면 청구 오류가 매달 나오고, 틀린 청구서 한 장이 요금제 설계보다 신뢰를 크게 깎습니다.