IT 수익모델: 서비스 설계가 먼저 정하는 한계

2017년 8월, 무비패스는 월 9.95달러에 극장 티켓을 무제한으로 볼 수 있는 구독 서비스를 내놓았습니다. 당시 미국 평균 영화 티켓 가격이 9.11달러였습니다. 발표 24시간 만에 신규 가입자 15만 명이 몰렸고, 1년 안에 300만 명을 넘었습니다. 그리고 2019년 9월, 회사는 서비스를 종료했습니다. 한 달 현금 소진액이 2,170만 달러까지 치솟은 뒤였습니다(The Ringer).

무비패스가 틀린 것은 가격이 아니라 순서였다

무비패스의 실수를 "가격을 너무 낮게 잡았다"로 읽으면 다음 교훈이 안 나옵니다. 진짜 문제는 구독이라는 모델을 먼저 정하고 나서 서비스에 끼워 맞췄다는 데 있습니다. 구독 모델은 회사가 부담하는 원가가 사용자의 이용 빈도와 무관하게 낮고 예측 가능할 때 성립합니다. 넷플릭스가 구독으로 성립하는 이유는 한 사람이 한 편을 더 본다고 넷플릭스의 비용이 거의 늘지 않기 때문입니다. 반대로 무비패스는 사용자가 영화를 한 편 더 볼 때마다 극장에 정가를 그대로 지불했습니다. 이용자가 한 달에 세 편만 봐도 회사는 적자였습니다.

저는 이 순서가 뒤바뀌는 일이 무비패스만의 문제가 아니라고 봅니다. "구독이 안정적인 수익을 만든다"는 말은 구독 모델 자체의 성질이 아니라, 그 서비스의 한계 원가가 낮을 때만 성립하는 조건부 사실입니다. 그 조건을 먼저 확인하지 않고 구독을 고르면, 서비스가 잘될수록 회사가 더 빨리 망하는 구조가 됩니다.

참고용 정리표

수익모델을 고를 때 "그 모델이 통하려면 서비스가 무엇을 갖추고 있어야 하는가"를 같이 적어 두면 나중에 다시 볼 때 쓸모가 있습니다.

유형	통하려면 서비스가 갖춰야 할 조건	안 맞을 때 나타나는 신호
구독(Subscription)	이용 빈도가 늘어도 원가가 거의 안 오른다	헤비 유저 비율이 늘수록 적자가 커진다
사용량 기반(Usage-based)	사용자가 자기 사용량을 스스로 예측할 수 있다	예상 밖의 고액 청구로 항의가 들어온다
프리미엄(Freemium)	무료와 유료를 가르는 자연스러운 사용량 한계가 있다	무료 사용자 대부분이 그 한계 근처에서 멈춘다
거래 수수료	플랫폼이 그 거래에서 없으면 안 되는 위치에 있다	판매자와 구매자가 플랫폼 밖에서 직거래한다
마켓플레이스 수수료	공급자를 직접 찾는 탐색 비용이 크다	한번 연결된 뒤 재구매는 플랫폼 밖에서 일어난다
광고	사용자 체류 시간이 길고 무료 사용에 대한 저항이 낮다	광고 차단 도구 사용률이 높다
라이선스 판매	사용자가 설치 후 소유·통제를 직접 원한다	불법 복제나 크랙 유통이 잦다
SI/용역(수주형)	요구사항이 고객마다 달라 표준화가 어렵다	비슷한 프로젝트를 매번 처음부터 다시 짠다
유지보수(SM) 계약	구축한 시스템이 계속 손볼 일이 생긴다	계약 갱신 시점마다 가격 협상이 반복된다
오픈소스 + 엔터프라이즈	무료 버전만으로는 못 하는 실사용 요구(보안, 지원)가 있다	무료 버전 포크가 유료 기능을 따라잡는다
API/개발자 생태계 과금	개발자가 직접 만들기보다 사는 편이 확실히 싸다	대체 오픈소스 라이브러리로 이탈이 잦다
인앱 결제	가상재화가 실제 경험을 바꾼다는 확신이 있다	결제 전환율이 게임 재화 기대치보다 낮다
데이터 판매/라이선싱	그 데이터가 제3자에게 독립적인 가치를 가진다	프라이버시·규제 리스크가 매출보다 크게 부각된다
하드웨어 + 부속 서비스	소모품이나 생태계 구매가 반복해서 일어난다	호환 소모품 시장이 정품 시장보다 커진다
제휴/추천 수수료	추천이 실제 구매 결정에 영향을 준다	클릭은 많은데 전환 기여를 증명하지 못한다
임베디드 금융	플랫폼 안에서 결제·대출 흐름이 이미 일어나고 있다	사용자가 외부 결제·대출 수단을 따로 쓴다
인증/보증 서비스	그 인증이 없으면 신뢰가 성립하지 않는 시장이다	인증 없이도 거래가 문제없이 일어난다
번들링/크로스셀	묶인 상품들이 실제로 같이 쓰일 때 가치가 커진다	번들 중 일부만 쓰고 나머지는 방치된다

이 표는 모델을 고르는 순서가 아니라 진단하는 순서로 씁니다. 지금 매출이 안 느는 이유가 모델이 틀려서인지, 실행이 부족해서인지를 가릴 때 오른쪽 열의 신호를 먼저 대조해 보는 식입니다.

사용량 기반 모델이 무너지는 지점

AWS의 S3 외부 전송(egress) 요금이 이 조건을 잘 보여줍니다. GB당 0.09달러라는 단가 자체는 홈페이지에 공개돼 있습니다. 문제는 이 요금이 사용자가 미리 계산해 두기 어려운 방식으로 쌓인다는 데 있습니다. 공개 다운로드 엔드포인트를 하나 열거나 스트리밍 기능을 추가하는 순간, 예상에 없던 수백 달러가 청구서에 나타납니다. 실제로 팀들이 큰 청구서를 받고 가장 먼저 하는 말이 "우리는 몇백 기가바이트밖에 안 쓰는데 이럴 리가 없다"입니다(CloudZero).

사용량 기반 모델은 회사 입장에서는 정확하고 공정한 과금입니다. 쓴 만큼 받으니 논리적으로 흠이 없습니다. 그런데 사용자 입장에서 그 사용량을 미리 예측할 수 없다면, 공정한 과금이 곧 "요금 폭탄"으로 경험됩니다. 저는 이 모델을 고를 때 회사가 계산하기 쉬운지가 아니라 사용자가 예측하기 쉬운지를 먼저 물어야 한다고 봅니다. 예측이 어려운 서비스라면 사용량 기반 위에 상한선이나 알림 같은 안전장치를 반드시 같이 설계해야 합니다.

거래 수수료가 통하지 않는 구조

거래 수수료 모델은 플랫폼이 그 거래에서 없어서는 안 될 존재일 때만 유지됩니다. 배달의민족이 수수료를 받을 수 있는 이유는 주문이 배달의민족을 거쳐야만 성립하기 때문입니다. 반대로 프리랜서 매칭 플랫폼에서 한번 연결된 거래처끼리는 다음부터 플랫폼을 거치지 않고 직접 거래하는 일이 흔합니다. 첫 거래를 성사시키는 것 이상으로는 플랫폼이 필요 없어지기 때문입니다.

이런 구조를 가진 서비스에서 거래 수수료 모델을 그대로 쓰면, 매출이 신규 거래처 확보 속도에만 의존하게 되고 재구매에서는 수익이 새어 나갑니다. 이런 구조에서는 수수료보다 구독료나 리드 제공 건당 과금처럼, 재거래 여부와 무관하게 걷을 수 있는 모델이 낫다고 저는 봅니다.

프리미엄이 자연스러운 경계 없이 만들어질 때

프리미엄 모델의 성패는 무료와 유료를 가르는 경계가 서비스 안에 원래 있었느냐에 달려 있습니다. 드롭박스의 저장 용량 한도는 자연스러운 경계입니다. 파일을 계속 쓰다 보면 누구나 그 한도에 닿습니다. 반대로 아무 기준 없이 "고급 기능"이라는 이름만 붙여 유료 벽을 세우면, 사용자는 그 벽을 우회할 방법을 찾거나 애초에 그 기능이 왜 유료인지 납득하지 못합니다.

저는 프리미엄을 설계할 때 물어야 할 질문이 "무엇을 유료로 만들까"가 아니라 "사용자가 이미 스스로 부딪히고 있는 한계가 무엇인가"라고 봅니다. 후자를 먼저 찾으면 유료 전환은 설득이 아니라 안내가 됩니다.

서비스가 먼저, 모델은 그다음

여기서 다룬 넷 다 모델 자체에 결함이 있는 것이 아닙니다. 구독도, 사용량 기반도, 거래 수수료도, 프리미엄도 조건이 맞으면 잘 작동합니다. 당위성 없이 세운 사업이 무너지는 것과 이 문제는 결이 다릅니다. 당위성은 "이 사업이 왜 돈이 되는가"에 대한 답이고, 여기서 다룬 것은 그 답을 실제로 걷어 들이는 방식이 서비스의 실제 이용 패턴과 맞는지의 문제입니다. 당위성이 있어도 모델을 잘못 고르면 무비패스처럼 사업 자체는 옳았는데 걷는 방식이 사업을 죽이는 일이 벌어집니다.

그래서 저는 수익모델을 표에서 골라 오는 방식에 반대합니다. 표는 후보를 좁히는 데만 씁니다. 실제로 고를 모델은 지금 만들고 있는 서비스의 이용 빈도, 원가 구조, 재구매 패턴, 무료와 유료를 가르는 자연스러운 경계가 무엇인지를 먼저 적어 놓고, 그 조건과 맞는 줄을 표에서 찾아 확인하는 순서라야 합니다.

이 순서를 지켜도 실패할 수 있습니다. 다만 그 실패는 적어도 예측 가능한 실패이지, 무비패스처럼 잘될수록 더 빨리 망하는 실패는 아닙니다.