SaaS 제품을 출시하고 첫 10명의 유료 고객을 확보한 지금, 실제보다 훨씬 크게 느껴지는 결정 앞에 서 있습니다. 바로 어떤 구독 결제 플랫폼 위에 서비스를 구축할 것인가 하는 문제입니다. 잘못 선택하면 18개월 후 어느 날 수천 건의 활성 구독을 정신없이 마이그레이션하며 아무것도 망가지지 않기를 기도하는 한 주를 보내게 될 것입니다. 제대로 선택하면 결제는 다시는 신경 쓸 필요 없는, 눈에 띄지 않는 인프라가 됩니다.
이는 결코 가벼운 문제가 아닙니다. 전체 구독 이탈의 약 20~40%는 비자발적 이탈입니다. 즉 고객이 해지할 의도는 없었지만 카드가 만료되거나 결제가 거부되었는데 아무도 제때 알아차리지 못한 경우입니다. 이 단 하나의 실패 유형만으로도 업계 전반에서 월간 반복 매출(MRR)의 약 9%가 새어 나가며, 만료된 카드만으로도 전체 결제 실패의 42%를 차지합니다. 어떤 결제 플랫폼을 선택하든, 그것을 인식하고 있든 아니든, 그 플랫폼은 매달 조용히 매출을 잃는 것을 막아주는 1차 방어선이기도 합니다.
성장하는 SaaS 기업들 사이에서 논의를 주도하는 플랫폼은 세 가지입니다. Stripe Billing, Chargebee, Recurly입니다. 각각은 서로 다른 유형의 기업에 최적화되어 있습니다. 어떤 것이 당신의 회사에 맞는지 알아보는 방법을 소개합니다.
빠른 답변
- 개발자가 만든 제품이고, 팀 규모가 작으며, 빠르게 움직이고 싶다면? → Stripe Billing
- 비개발자가 티켓을 발행하지 않고도 가격을 변경해야 한다면? → Chargebee
- 복잡한 계약과 미터링이 있는 엔터프라이즈 B2B이거나, 결제 복구가 가장 큰 레버리지라면? → Recurly
이제 그 이유를 하나씩 살펴보겠습니다.
Stripe Billing: 개발자의 기본 선택
이미 엔지니어들이 일회성 결제를 위해 Stripe를 연동해 두었다면, Stripe Billing은 가장 저항이 적은 길입니다. 이는 덧붙여진 서드파티 도구가 아니라, 이미 운영 중일 가능성이 높은 결제 인프라의 네이티브 확장입니다.
강점:
- API 일관성. Stripe의 API는 문서화가 잘 되어 있기로 유명하며, CLI 덕분에 웹훅과 구독 이벤트를 로컬에서 테스트하는 일이 정말 수월해집니다. 2~3명 규모의 엔지니어링 팀에게는 실질적인 시간 절약입니다.
- 직접 만들 필요 없는 고객 포털. Stripe는 브랜딩이 가능한 사전 제작된 고객 포털을 제공하여, 구독자가 지원팀에 이메일을 보내지 않고도 업그레이드, 다운그레이드, 결제 수단 변경을 할 수 있습니다.
- 투명한 사용량 기반 가격 정책. 별도의 플랫폼 구독료가 없으며, 처리된 반복 매출의 약 0.5%만 지불하면 됩니다. 다만 Stripe Tax(거래당 +0.5%)나 Stripe Revenue Recognition(+0.25%) 같은 추가 모듈이 필요하다면 비용이 누적될 수 있습니다.
약점: Stripe Billing은 강력하지만 코드 중심입니다. 가격 모델이 복잡해지면, 예를 들어 계층형에 사용량과 초과분이 더해지고 주기 중간 업그레이드와 연간 계약 비례 정산까지 얽히면, 결국 플랫폼이 기본적으로 모델링하지 않는 예외 상황을 처리하기 위한 커스텀 로직을 직접 작성하고 유지보수하게 될 가능성이 높습니다. 또한 개발자를 위해 만들어졌기 때문에, 마케팅이나 재무 담당자가 엔지니어링 팀 없이 안전하게 플랜을 수정하기는 어렵습니다.
가장 적합한 대상: MRR 약 50만 달러 미만의 초기 단계 개발자 주도 SaaS 기업 중, '결제를 받는다'에서 '구독을 운영한다'로 가장 빠르게 넘어가고 싶고, 일부 결제 로직을 코드로 직접 관리하는 데 거부감이 없는 팀입니다.
Chargebee: 가격 실험을 위해 설계된 플랫폼
Chargebee가 존재하는 이유는 오직 유연성 때문입니다. 가격 모델을 바꿀 것으로 예상되는 팀들이 선택하는 플랫폼이며, 창업 1~2년 차 SaaS 창업자라면 아마 그렇게 될 것입니다. 성공한 SaaS 기업 거의 모두가 고객이 실제로 무엇에 가치를 두는지 파악하면서 최소 한 번은 가격 정책을 다시 조정합니다.
강점:
- 노코드 플랜 관리. 제품팀과 재무팀이 풀 리퀘스트를 열지 않고도 가격 등급, 애드온, 쿠폰, 사용량과 정액제를 혼합한 모델을 만들고 테스트하고 수정할 수 있습니다.
- 복잡성을 실제로 처리합니다. 사용량 초과가 있는 계층형 가격, 중간 업그레이드가 있는 연간 계약, 다중 법인 청구 등 세 플랫폼 중 우회 방법 없이 이를 네이티브로 처리하는 것은 종종 Chargebee뿐입니다.
- 강력한 회계 연동. 수익 인식 및 회계/ERP 시스템으로의 내보내기 기능이 Stripe Billing의 기본 도구보다 더 성숙한 경향이 있으며, 이는 컨트롤러나 외부 기장 담당자가 매월 장부를 마감하게 되는 시점부터 중요해집니다.
약점: 무료 등급을 벗어나면(누적 청구액이 약 10만 달러를 넘으면 수백 달러에서 천 달러 이상에 이르는 월 정액 요금이 적용되기 시작) Chargebee의 가격은 상당히 올라갑니다. 따라서 매출 이전 단계이거나 막 서비스를 시작한 경우에는 순수 매출 비율 모델보다 더 큰 부담이 됩니다.
가장 적합한 대상: 첫 가격 모델을 넘어 확장하는 SaaS 기업, 특히 그로스 헤드나 재무 리더 같은 비개발자가 결제 설정을 직접 관리해야 하는 경우입니다.
Recurly: 매출 손실을 막기 위해 설계된 플랫폼
Recurly의 포지셔닝은 더 좁지만, 적합한 기업에게는 다른 두 경쟁사보다 더 가치 있습니다. 실패한 결제로 조용히 새어 나가는 돈을 줄이기 위해 존재하기 때문입니다.
강점:
- 핵심 제품으로서의 스마트 던닝. Recurly의 머신러닝 기반 재시도 로직은 거부된 결제를 언제, 몇 번 다시 시도할지를 결정합니다. 너무 일찍 포기하거나 너무 자주 시도해 고객을 짜증나게 하는 고정된 일정으로 재시도하는 대신 말입니다.
- 이탈 예측. Recurly의 분석 기능은 이상 사용량 감소나 반복적인 결제 실패 직전 상황 등 위험 계정을 해지 전에 표시해 주어, 팀이 개입할 기회를 제공합니다.
- 플랫폼 수수료 없는 매출 비율 가격 정책으로 Stripe Billing과 유사하며, 소규모 기업도 접근하기 쉬우면서 동시에 엔터프라이즈급 계약을 두고 경쟁할 수 있게 해줍니다.
약점: Recurly의 핵심 강점인 던닝과 복구는 실제 거래량이 어느 정도 쌓였을 때 가장 큰 의미를 갖습니다. 고객 40명을 보유한 5인 스타트업은 차이를 체감하지 못하겠지만, 매월 수만 건의 결제를 처리하는 기업은 즉시 체감할 것입니다. 숫자가 이를 뒷받침합니다. 자동화된 던닝은 그대로 두면 사라졌을 실패한 결제의 40~70%를 복구하는 반면, 아무런 개입이 없을 때는 약 15%만 복구됩니다.
가장 적합한 대상: 결제 실패가 측정 가능하고 계속 늘어나는 비용 항목인 구독 기반 사업, 특히 B2C나 대량 거래 B2B, 또는 복잡한 미터링과 계약 조건을 가진 엔터프라이즈 B2B SaaS입니다.
한눈에 비교하기
| Stripe Billing | Chargebee | Recurly | |
|---|---|---|---|
| 가격 모델 | 반복 매출의 약 0.5% | 누적 청구액 약 10만 달러까지 무료, 이후 월 $599~$1,199 이상 | 반복 매출의 약 0.5%, 플랫폼 수수료 없음 |
| 적합 대상 | 이미 Stripe를 사용 중인 개발자 주도 팀 | 가격을 관리하는 비개발자, 복잡한 플랜 구조 | 결제 실패로 인한 이탈과 싸우는 대량 거래 기업 |
| 대표 기능 | 사전 제작된 고객 포털, 깔끔한 API/CLI | 노코드 플랜 빌더, 계층형+사용량+계약 네이티브 지원 | ML 기반 던닝, 이탈 위험 분석 |
| 약점 | 복잡한 가격 정책에는 커스텀 코드 필요 | 무료 등급을 넘으면 상당한 월 요금 발생 | 매우 커스텀한 가격 로직에는 유연성이 떨어짐 |
| 일반적인 기업 단계 | 프리시드~시리즈 A | 시리즈 A 이후, 또는 가격 정책을 자주 조정하는 경우 | 결제 실패가 측정 가능한 비용이 되는 모든 단계 |
전환 비용은 실재합니다 — 미리 계획하세요
이 결정을 대수롭지 않게 여기고 싶은 유혹이 있습니다. '나중에 규모가 커지면 그때 바꾸면 되지'라고 생각하기 쉽지만, 실제로 운영 중인 구독 기반을 다른 결제 플랫폼으로 마이그레이션하는 일은 성장하는 SaaS 기업이 겪을 수 있는 가장 고통스러운 프로젝트 중 하나입니다. 단순히 데이터베이스 테이블 하나를 옮기는 것이 아니라, 다음을 함께 옮기는 것입니다.
- 활성 결제 수단. 관련된 플랫폼에 따라 저장된 카드 정보를 프로그램적으로 이전할 수 없는 경우가 있어, 일정 비율의 고객이 전환 과정에서 결제 정보를 다시 입력해야 하거나 이탈 위험에 노출될 수 있습니다.
- 비례 정산과 계약 상태. 주기 중간의 구독, 미사용 크레딧이 남은 연간 계약, 각종 맞춤 할인은 정확히 재현되어야 하며, 그렇지 않으면 고객이 잘못 청구받고 고객지원 대기열이 순식간에 쌓입니다.
- 과거 리포팅의 연속성. 결제 플랫폼의 데이터 모델에 의존하는 MRR, 이탈률, 코호트 대시보드는 과거 데이터 백필을 세심하게 계획하지 않으면 마이그레이션 전후로 데이터 단절이 나타날 수 있습니다.
- 던닝 및 복구 로직. 예를 들어 비용 문제로 Recurly에서 다른 플랫폼으로 이전한다면, 그동안 스마트 재시도가 조용히 지켜주던 복구율을 처음부터 다시 구축해야 하는 책임을 떠안게 됩니다.
그렇다고 영원히 갇혀 있어야 한다는 뜻은 아닙니다. 실제로 많은 기업이 마이그레이션에 성공합니다. 다만 '지금은 가장 저렴한 옵션을 고르고 나중에 바꾸면 된다'는 사고방식은 '나중'이 실제로 얼마나 비싼지를 과소평가한다는 뜻입니다. 오늘 청구서만을 최적화하기보다, 12~18개월 후 자신의 모델에 맞는 플랫폼을 위해 약간 여유 있게 투자하는 편이 대개 더 저렴합니다.
간단한 결정 방법
다음 세 가지 질문을 순서대로 스스로에게 던져 보세요.
- 엔지니어링 팀이 작고 결제 로직이 단순한가요? 그렇다면 Stripe Billing이 가장 빠르게 출시할 수 있게 해줍니다.
- 비개발자가 가격을 변경해야 하거나, 이미 모델이 복잡한가요(계층+사용량+계약)? 그렇다면 Chargebee는 더 높은 가격을 지불할 가치가 있습니다.
- 실패한 카드 결제와 비자발적 이탈로 측정 가능한 규모의 매출을 잃고 있나요? 결제 실패가 늘어나는 비용 요인이라면, Recurly의 전문성은 그 비용을 스스로 상쇄합니다. 흔히 처음 복구된 몇 건의 거래만으로도 그렇습니다.
MRR 약 10만 달러 미만의 창업자는 '설정의 용이성'에 큰 비중을 두어야 합니다. MRR 50만 달러를 넘어서면 계산의 중심은 결제 성과와 복구 쪽으로 옮겨갑니다. 규모가 커지면 던닝 복구율의 작은 퍼센트 포인트 개선조차 실제 큰 금액으로 이어지기 때문입니다.
어떤 플랫폼을 선택하든, 이 점을 놓치지 마세요
어떤 결제 플랫폼을 선택하든, 저절로 해결되지 않는 문제가 하나 있습니다. 구독 매출은 단순히 수금되는 것이 아니라 정확하게 기록되어야 한다는 점입니다. Stripe, Chargebee, Recurly에서 성공한 결제가 은행 계좌에 입금되는 순간 자동으로 장부상 '매출'이 되는 것은 아닙니다. 이연 매출, 환불, 비례 정산 크레딧, 실패했다가 복구된 결제는 모두 결제 플랫폼이 보고하는 내용과 대조하여 조정되어야 합니다. 결제 처리업체의 대시보드를 재무 진실의 원천으로 취급하는 창업자들은 대개 첫 투자 유치나 세금 신고를 앞두고 엉망이 된 장부 정리에 놀라게 되는 사람들입니다.
바로 이 지점에서 좋은 기장 습관이 일찍부터 빛을 발합니다. 모든 구독 결제, 환불, 던닝 복구, 플랜 변경은 결제 플랫폼의 리포팅 UI에만 머물러야 할 것이 아니라 원장에 기록되어야 할 거래입니다. 그 UI는 애초에 회계 시스템을 겸하도록 만들어지지 않았습니다.
결제 스택만큼 장부도 깔끔하게 유지하세요
올바른 구독 결제 플랫폼을 선택하는 것은 문제의 절반을 해결할 뿐입니다. 그 매출을 정확하게 기록하는 것이 나머지 절반입니다. Beancount.io는 SaaS 창업자에게 투명하고 버전 관리가 가능하며 Stripe, Chargebee, Recurly에서 내보낸 데이터와 손쉽게 대조할 수 있는 플레인 텍스트 회계를 제공합니다. 벤더 종속도 없고 블랙박스 원장도 없습니다. 반복 매출을 어떻게 처리하는지 문서에서 확인하거나, 원장을 시각적 대시보드로 살펴볼 수 있는 Fava를 둘러보세요. 그런 다음 무료로 시작해서 코드베이스만큼 감사 가능한 재무 기록을 유지하세요.