시트 기반 과금

소프트웨어를 한 번 사서 설치하던 시절에는 값이 회사 단위로 매겨졌습니다. 한 번 결제하면 그 회사 안에서 몇 명이 쓰는지는 파는 쪽이 알 방법도 없었고 알 이유도 없었습니다.

그 구조에서는 값이 누구에게도 맞지 않았습니다. 다섯 명이 쓰는 회사와 500명이 쓰는 회사가 같은 금액을 내니, 작은 회사는 비싸서 못 사고 큰 회사는 얻는 것에 비해 싸게 썼습니다. 그래서 계약 협상이 매번 규모를 두고 벌이는 흥정이 됐습니다. 우리는 몇 명 안 쓰니 깎아 달라는 말과 얼마나 쓰는지 확인할 수 없다는 말이 오갔고, 같은 제품의 값이 고객마다 달라졌습니다.

설치 없이 웹으로 접속해 쓰는 SaaS 형태가 퍼지면서 이 문제가 풀렸습니다. 누가 몇 개의 계정으로 들어오는지를 파는 쪽 서버가 그대로 알게 됐기 때문입니다. 세는 것이 가능해지자 값을 사람 수에 붙이는 방식이 자리를 잡았습니다. 쓰는 사람이 많을수록 얻는 것이 많다는 직관과도 맞아떨어졌습니다.

계정 하나를 한 자리로 보고, 그 자리의 수에 단가를 곱해 청구합니다. 실제로 정해야 하는 것은 다섯 가지입니다.

1. 무엇을 한 자리로 셀지 정합니다. 초대된 계정 전부를 셀지, 이번 달에 한 번이라도 들어온 계정만 셀지, 읽기만 하는 계정은 빼 줄지가 여기서 갈립니다. 같은 30명짜리 팀이 이 정의에 따라 30자리가 되기도 하고 18자리가 되기도 합니다.
2. 단가와 주기를 정합니다. 자리당 월 1만 원이면 30명 쓰는 회사는 월 30만 원입니다. 1년 치를 미리 받으면서 두 달 치를 깎아 주는 연 결제 할인이 흔히 함께 붙습니다.
3. 중간에 늘고 주는 것을 어떻게 처리할지 정합니다. 15일에 세 명을 추가하면 그 달은 반달치만 받는 식으로 날짜에 비례해 나누는 규칙을 둡니다. 이 규칙이 없으면 월초에만 사람을 추가하는 행동이 생깁니다.
4. 최소 자리 수를 둘지 정합니다. 다섯 자리부터 팔면 작은 팀의 문의와 지원 부담을 줄일 수 있지만, 세 명짜리 팀은 들어오지 못합니다.
5. 등급과 곱할지 정합니다. 기능 묶음별로 등급을 나눈 티어 요금제와 함께 쓰면 청구액은 등급 단가와 자리 수의 곱이 됩니다. 상위 등급으로 올리는 것과 자리를 늘리는 것, 두 방향으로 매출이 오릅니다.

세는 기준이 곧 청구서라서, 1번을 느슨하게 적어 두면 갱신 때마다 같은 논쟁이 반복됩니다. 계약서에 자리의 정의를 한 문장으로 못 박아 두는 이유가 여기 있습니다.

사람이 많을수록 값어치가 커지는 제품에 맞습니다. 여러 명이 같은 문서와 같은 프로젝트를 함께 쓰는 협업 도구가 대표적입니다. 혼자 쓸 때는 쓸모가 절반인데 팀 전체가 들어오면 제자리를 찾는 제품이라면, 청구액이 사람 수를 따라가는 것이 고객에게도 설명됩니다.

파는 쪽이 얻는 것은 고객이 커질 때 따라 커지는 매출입니다. 20명이 쓰던 회사가 채용으로 45명이 되면 아무것도 팔지 않아도 청구액이 두 배가 넘습니다. 이미 들어온 고객에게서 늘어나는 이 매출을 확장 매출이라고 부르고, 이 방식을 고르는 가장 큰 이유가 됩니다.

반대로 맞지 않는 자리도 분명합니다. 쓰는 양이 사람 수와 무관한 제품이 그렇습니다. 계정 세 개로 하루에 100만 건을 처리하는 회사와 계정 서른 개로 하루에 100건을 처리하는 회사가 있다면, 자리 수로 매긴 값은 실제로 주고받는 것과 어긋납니다. 이럴 때는 쓴 만큼 받는 사용량 기반 과금이 맞습니다.

이 방식에는 고객이 계정을 돌려 쓰려는 유인이 따라붙습니다. 자리 하나를 셋이 나눠 쓰면 값이 3분의 1이 되기 때문입니다. 그래서 이 방식을 쓰는 제품은 같은 계정의 동시 접속을 막거나, 누가 무엇을 했는지 계정별로 기록을 남기는 장치를 함께 둡니다. 기능이라기보다 과금을 지탱하는 장치입니다.

"자리당 얼마예요? 서른 명이면 한 달에 얼마죠?"

단가와 인원을 곱해 예산을 잡으려는 계산입니다.

"이번 달에 한 번도 안 들어온 계정 여덟 개는 빼 주세요."

세는 기준을 활성 계정으로 좁혀 달라는 요구입니다.

"읽기 전용 계정은 무료로 열죠. 안 그러면 사내 확산이 거기서 막혀요."

당장의 청구액보다 쓰는 사람 수를 늘리는 쪽을 택하자는 제안입니다.

페이지덱이 팀 요금제를 만들 때 가장 오래 걸린 결정이 자리의 정의였습니다. 지현은 초대된 계정을 전부 세자고 했고, 수아는 그렇게 하면 계약 단계에서 고객이 명단부터 정리하느라 도입이 한 달씩 늦어진다고 반대했습니다.

결론은 그달에 한 번이라도 들어온 계정만 세는 쪽이었습니다. 규원이 판단 근거로 든 것은 매출이 아니라 확산이었습니다. 쓰지 않는 계정에 돈을 물리면 고객사 관리자가 초대를 아끼게 되고, 초대가 줄면 제품이 회사 안에서 퍼지지 않기 때문입니다.

사람이 늘면 매출도 저절로 는다고 보는 경우가 가장 많습니다. 계산식이 그렇게 생겼으니 자연스러운 기대입니다. 하지만 고객사에도 이 비용을 줄이려는 담당자가 있습니다. 갱신 시점이 되면 비활성 계정을 정리하고, 필요한 사람만 남기고, 부서 단위로 쓰던 것을 팀 단위로 줄입니다. 그래서 이 방식에서는 자리 수의 감소가 이탈보다 먼저 오는 신호로 다뤄집니다. 계약이 유지되는데도 매출이 매 분기 조금씩 빠지는 상태가 이 신호를 놓쳤을 때 생깁니다.

셈이 단순하니 운영도 쉽다고 보는 것도 흔합니다. 곱셈 하나로 끝나 보이지만 실제 일은 중간 변경에서 나옵니다. 달 중간에 다섯 명이 들어오고 두 명이 나가면 이번 청구서는 얼마인지, 연 결제 중에 자리를 줄이면 남은 기간을 환불할지 이월할지를 전부 규칙으로 정해 둬야 합니다. 이 규칙을 안 정해 두면 고객마다 다르게 처리되고, 그 차이가 나중에 계약 분쟁으로 돌아옵니다.