과금 모델

소프트웨어를 설치 파일이나 시디로 팔던 시절에는 돈을 받는 방법이 하나뿐이었습니다. 한 번 팔고 끝났습니다. 값을 얼마로 부를지만 정하면 나머지는 저절로 따라왔고, 산 쪽이 몇 명이서 쓰는지 다음 달에 얼마나 더 쓰는지는 판 쪽이 알 수도 없었고 알 필요도 없었습니다.

제품이 웹으로 옮겨 오면서 사정이 달라졌습니다. 서비스가 계속 켜져 있으니 매달 돈을 받을 수 있게 됐고, 누가 언제 몇 번 썼는지가 전부 기록으로 남았습니다. 돈을 받을 수 있는 방법이 여러 개로 늘어나자 값을 얼마로 매길지 정하는 일과 무엇을 세어서 받을지 정하는 일이 서로 다른 문제로 갈라졌습니다.

이 둘을 갈라 놓지 않으면 회의가 겉돕니다. 어느 팀의 요금제 회의는 "월 2만 원으로 갑시다" 라는 합의만 남기고 끝났습니다. 개발팀은 그 말을 계정 하나당 2만 원으로 알아듣고 청구 계산을 짰고, 영업은 회사 하나당 2만 원으로 알아듣고 제안서를 돌렸습니다. 30명이 쓰는 회사에 한쪽 계산으로는 60만 원, 다른 쪽 계산으로는 2만 원짜리 청구서가 나갑니다. 같은 문장에서 서른 배가 어긋난 겁니다.

단위를 무엇으로 잡느냐는 들어오는 돈만 정하지 않습니다. 고객이 제품을 쓰는 방식까지 함께 바꿉니다. 계정 수로 세면 고객사는 자리를 아껴 쓰려고 꼭 필요한 사람에게만 계정을 내주고, 쓴 양으로 세면 파일 하나를 올리기 전에 한 번 더 망설입니다. 둘 다 파는 쪽이 바란 행동은 아니지만 단위를 정하는 순간 따라붙습니다. 그래서 어떤 모델을 고를지 볼 때는 매달 얼마가 들어오는지뿐 아니라 고객이 무엇을 아끼게 되는지도 같이 봅니다.

그래서 값과 별개로 무엇을 단위로 세는지를 못 박는 자리가 따로 생겼습니다. 과금 모델은 그 자리를 가리키는 말입니다. 단위가 정해지면 그 뒤가 전부 거기에 얹힙니다. 청구서 금액을 만드는 계산식, 가입 화면에 적는 문구, 영업이 고객에게 꺼내는 질문, 다음 분기 매출 예측이 모두 같은 단위 위에서 돌아갑니다. 단위를 바꾸는 일이 어려운 이유도 같습니다. 숫자 하나를 바꾸는 게 아니라 그 위에 얹힌 것들을 함께 들어내야 하기 때문입니다.

과금 모델 아래 묶인 용어 여덟 개는 모두 유형 갈래에 속합니다. 여덟 개를 가르는 기준은 셋입니다. 무엇을 세어 청구하는지, 돈을 내기 전에 어디까지 열어 주는지, 기본 요금 위에 무엇을 더 얹는지입니다.

무엇을 세는지가 첫 기준입니다. 청구서 금액을 만드는 숫자가 무엇이냐에 따라 넷으로 갈립니다.

1. 구독 — 주기마다 정해진 금액을 받습니다. 매달 1일에 9만 9,000원처럼 날짜와 금액이 미리 정해져 있어서, 고객은 다음 달 청구서를 지금 알고 파는 쪽은 다음 분기 매출을 지금 계산합니다. 대신 그 달에 많이 썼든 한 번도 안 열었든 금액이 같습니다. 아래 나오는 다른 유형 대부분이 구독을 바탕에 깔고 그 위에서 변형되기 때문에, 여덟 개 중 가장 넓게 쓰이는 말이기도 합니다.
2. 시트 기반 과금 — 제품을 쓰는 계정 수에 비례해 받습니다. 한 자리에 1만 원이면 30명 쓰는 회사는 30만 원입니다. 고객 회사가 커져 사람이 늘면 파는 쪽이 아무것도 안 해도 매출이 늘어난다는 점이 이 방식의 값어치입니다. 반대로 고객은 계정 하나를 여럿이 돌려 쓰려는 유인이 생기고, 그래서 이 방식을 쓰는 제품은 동시 접속을 막거나 계정별 기록을 남기는 장치를 함께 둡니다.
3. 사용량 기반 과금 — 실제로 쓴 양을 세어 받습니다. 저장 용량 1기가당 얼마, 내보내기 1,000건당 얼마처럼 단위를 정해 두고 달마다 잰 값을 곱합니다. 전기 요금 계량기와 같은 방식이라 안 쓴 달은 0원에 가깝게 나옵니다. 고객에게 공정하게 느껴지는 대신, 청구서가 도착하기 전까지 얼마가 나올지 아무도 모른다는 점이 양쪽 모두에게 부담입니다. 파는 쪽도 다음 달 매출을 예측하기 어려워집니다.
4. 크레딧 모델 — 고객이 적립분을 미리 사 두고 쓸 때마다 깎아 나갑니다. 10만 원어치를 먼저 받고 내보내기 한 건에 100을 차감하는 식입니다. 세는 방식은 사용량 기반과 같지만 돈이 먼저 들어온다는 점이 다릅니다. 파는 쪽은 현금을 미리 확보하고, 고객은 쓸 수 있는 한도를 스스로 정해 둡니다.

돈을 내기 전에 어디까지 열어 주는지가 두 번째 기준입니다. 무료와 유료 사이에 선을 어떻게 긋느냐로 셋이 갈립니다.

5. 티어 요금제 — 기능을 묶어 등급을 나눕니다. 기본 등급은 문서 100개까지, 상위 등급은 무제한에 권한 관리까지 주는 식으로 층을 쌓습니다. 등급이 둘이면 고민이 단순한 대신 중간에 낀 고객을 놓치고, 다섯이면 어느 줄을 골라야 할지 몰라 아무것도 고르지 않는 사람이 늘어납니다. 대개 셋에서 넷 사이로 잡습니다.
6. 프리미엄 — 기본 기능을 기한 없이 무료로 열어 두고 고급 기능만 돈을 받습니다. 무료로 쓰는 사람이 100명이면 그중 서너 명이 돈을 내는 정도가 흔한 수치라, 무료 사용자를 감당할 서버 비용을 버틸 수 있을 때만 성립합니다.
7. 무료 체험 — 14일이나 30일 동안 전체 기능을 열어 주고 기간이 끝나면 닫습니다. 프리미엄과 갈리는 지점은 무엇으로 선을 긋느냐입니다. 프리미엄은 기능으로 긋고 무료 체험은 시간으로 긋습니다. 그래서 무료 체험은 기간 안에 고객이 제품의 쓸모를 체감하지 못하면 아무것도 남기지 못하고 끝납니다.

기본 요금 위에 무엇을 더 얹는지가 마지막 기준입니다.

8. 애드온 — 요금제에 포함되지 않은 것을 따로 파는 선택 상품입니다. 저장 용량 100기가 추가, 전담 담당자 배정 같은 것들이 여기 들어갑니다. 등급을 통째로 올리기는 부담스럽고 한 가지만 더 필요한 고객이 쓰는 길이라, 티어 요금제의 빈틈을 메우는 자리에 놓입니다.

실제 제품은 이 여덟 개 중 하나만 고르지 않습니다. 팀이 함께 쓰는 협업 문서 툴이라면 계정 수로 세고, 그 위에 등급을 세 층 얹고, 가장 아래 등급은 무료로 열어 두고, 저장 용량은 따로 파는 식으로 넷을 겹쳐 씁니다. 그래서 과금 모델을 정한다는 말은 여덟 개 중 하나를 고른다는 뜻이 아니라, 세는 단위와 여는 범위와 얹는 상품을 각각 정해 한 벌로 맞춘다는 뜻입니다.

세 기준은 따로 답할 수 없습니다. 하나를 정하면 나머지 둘의 선택지가 줄어듭니다. 계정 수로 세면서 무료 구간을 계정 수로 끊으면 고객은 무료 계정을 여러 개 만들어 그 선을 피해 갑니다. 쓴 양으로 세면서 대용량 처리를 상위 등급에만 열어 두면 가장 많이 쓰는 고객이 등급 문턱에 걸려 나갑니다. 한 기준만 정하고 나머지를 나중으로 미룬 팀이 대개 이런 자리에서 막힙니다.

"이번 건은 시트로 가야 할까요, 사용량으로 가야 할까요?"

무엇을 세어 청구할지를 아직 안 정했다는 뜻이고, 고객이 사람 수가 많은 쪽인지 쓰는 양이 들쭉날쭉한 쪽인지를 먼저 보자는 제안입니다.

"가격은 그대로 두고 모델만 바꾸는 겁니다."

한 자리에 1만 원이라는 값은 유지하되 세는 단위를 계정 수에서 실제 사용량으로 옮기자는 말입니다.

"이 고객사는 모델이 안 맞아서 계약서를 따로 씁니다."

표준 요금제의 단위로는 이 고객의 사용 형태를 담지 못해 별도 계약으로 처리한다는 뜻입니다.

페이지덱의 요금제 개편 회의는 늘 같은 질문에서 시작합니다. 지현이 화이트보드에 "무엇을 셀 것인가" 를 적고 그 아래 후보를 늘어놓습니다. 지금은 계정 수로 세고 있는데, 계정을 스무 개 만들어 놓고 실제로는 다섯 명만 쓰는 회사가 늘면서 해지 이야기가 나오고 있기 때문입니다.

수아는 현장에서 듣는 말을 옮깁니다. 고객사 담당자들이 "안 쓰는 자리까지 왜 돈을 내느냐" 고 묻는데, 자리를 줄이자니 나중에 쓸 사람 몫을 미리 빼는 셈이라 결정을 못 하고 미룬다는 것입니다. 태오는 다른 쪽을 짚습니다. 실제로 문서를 연 사람만 세려면 접속 기록을 달마다 집계하고 청구 직전에 잠그는 절차가 필요한데, 지금 구조로는 두 달은 걸린다는 이야기입니다. 규원이 묻는 것은 매출입니다. 계정 수로 세면 다음 분기 숫자를 지금 계산할 수 있지만 쓴 만큼 받기 시작하면 그 예측이 흔들립니다.

이 회의에서 정해진 것은 한 줄이었습니다. 자리 수로 세는 방식은 유지하되, 90일 동안 한 번도 안 들어온 계정은 다음 청구에서 자동으로 빼 주기로 했습니다. 단위를 통째로 바꾸는 대신 단위의 정의를 좁힌 셈입니다. 태오가 잡은 일정은 두 달이 아니라 2주로 줄었고, 매출 예측도 그대로 쓸 수 있게 됐습니다.

과금 모델을 요금제 화면에 적힌 숫자와 같은 것으로 읽는 경우가 가장 많습니다. 고객이 눈으로 보는 건 등급 이름과 금액뿐이라 그 화면이 전부처럼 보입니다. 하지만 화면은 결과를 보여 줄 뿐이고, 모델은 그 숫자를 만들어 내는 규칙 쪽에 있습니다. 한 자리에 1만 원이라고 적힌 화면 뒤에는 자리를 언제 센 것으로 치는지, 달 중간에 사람이 들어오면 며칠치를 받는지, 자리를 줄이면 남은 기간 돈을 돌려주는지 같은 규칙이 붙어 있습니다. 이걸 안 정해 두면 화면은 멀쩡한데 청구서마다 금액이 다르게 나오고, 고객 문의가 들어올 때마다 담당자가 그 자리에서 규칙을 만들어 답하게 됩니다. 그렇게 만들어진 답이 쌓이면 나중에는 어느 것이 정한 규칙이고 어느 것이 그때그때 봐준 예외인지 아무도 구분하지 못합니다.

한 번 정하면 나중에 바꾸면 된다고 생각하는 것도 자주 어긋납니다. 숫자 하나 고치는 일처럼 보이니 그렇게 여기기 쉽습니다. 실제로는 단위를 바꾸는 순간 그 위에 얹힌 것이 전부 따라 움직입니다. 청구 계산과 결제 연동을 다시 짜야 하고, 이미 맺어 둔 계약서의 문구가 새 단위와 어긋나고, 지난 2년치 매출 기록이 새 기준과 맞물리지 않아 성장 추이를 이어 볼 수 없게 됩니다. 기존 고객에게는 이번 달과 다음 달 청구서가 왜 다른지를 한 사람씩 설명해야 합니다. 그래서 모델 변경은 대개 분기를 통째로 쓰는 일이 되고, 그동안 다른 기능 개발이 멈춥니다. 초기에 대충 정하고 넘어간 팀이 2년 뒤에 치르는 값이 이것입니다.