RevenueCat 실전 가이드: 1인 개발자를 위한 인앱 구독 관리의 표준
- RevenueCat은 iOS/Android 인앱 구독을 단일 SDK로 통합 관리하는 플랫폼 — 앱스토어마다 다른 구독 로직을 추상화
- MTR $2,500까지 완전 무료, 초과분 1% — 처음 수익이 날 때까지 비용 제로
- Paywalls v2(2025.6 GA): 노코드로 페이월 디자인, 앱 재심사 없이 원격 변경 가능
- Web Billing: Stripe 기반 웹 결제로 앱스토어 30% 수수료 우회 가능
- Experiments: 코드 배포 없이 가격·페이월 A/B 테스트 — 구독 최적화의 핵심 무기
구독 연동, 직접 구현하면 어떻게 되나
앱에 구독 기능을 넣는다고 결심하는 순간, 예상치 못한 복잡성이 기다리고 있다.
iOS부터 시작해보자. StoreKit 2 API를 배워야 하고, 영수증 검증 서버를 따로 구축해야 한다. 구독 갱신, 업그레이드, 다운그레이드, 환불 처리, 만료 감지 — 각각 다른 로직이 필요하다. 거기에 샌드박스 환경 테스트가 생각보다 까다롭다.
Android도 마찬가지다. Play Billing Library가 따로 있고, 상태 관리 방식이 iOS와 다르다. 두 플랫폼을 동시에 지원한다면 사실상 구독 로직을 두 번 구현해야 한다.
그리고 제일 무서운 건 엣지 케이스다. 구독 중에 앱을 삭제하면? 기기를 바꾸면? 가족 공유를 쓰면? 환불 후 재구독하면? 이런 케이스들을 전부 처리하다 보면 핵심 기능 개발 시간이 구독 로직에 잡아먹힌다.
RevenueCat은 이 모든 것을 대신 처리한다.
RevenueCat이 뭔가
RevenueCat은 2018년 런칭한 모바일 인앱 구독 관리 플랫폼이다. 현재 83,000개 이상의 앱이 사용하고 있고, 업계 표준으로 자리잡았다.
핵심 철학은 간단하다: 플랫폼마다 다른 구독 API를 단일 인터페이스로 추상화한다. 개발자는 RevenueCat SDK 하나만 알면 iOS, Android, 웹, Flutter, React Native 등 어디서든 동일한 방식으로 구독을 다룰 수 있다.
RevenueCat 내부 데이터에 따르면 개발자들이 구독 인프라를 직접 구축할 때 평균 50시간을 쓴다. RevenueCat을 쓰면 그 시간을 제품 개발에 돌릴 수 있다.
핵심 기능 5가지
1. 통합 구독 SDK
RevenueCat의 가장 큰 가치는 플랫폼 통합이다. 지원하는 플랫폼이 광범위하다:
- iOS (Swift/Objective-C)
- Android (Kotlin/Java)
- Flutter
- React Native
- Unity
- Kotlin Multiplatform
어떤 플랫폼을 쓰든 구독 상태 확인 방법은 동일하다:
// iOS Swift 예시
let customerInfo = try await Purchases.shared.customerInfo()
if customerInfo.entitlements["premium"]?.isActive == true {
// 프리미엄 기능 활성화
}
// Android Kotlin 예시
val customerInfo = Purchases.sharedInstance.awaitCustomerInfo()
if (customerInfo.entitlements["premium"]?.isActive == true) {
// 프리미엄 기능 활성화
}
같은 논리, 같은 구조다. iOS와 Android를 동시에 개발할 때 구독 로직을 두 번 생각할 필요가 없다.
2. Paywalls v2 — 노코드 페이월 빌더
2025년 6월 GA(Generally Available)된 Paywalls v2는 RevenueCat의 게임 체인저다.
기존에는 페이월 UI를 직접 코드로 짰다. 가격을 바꾸려면 코드 수정 → 빌드 → 앱스토어 심사(보통 1-3일) → 배포 과정을 거쳐야 했다. 실험하기가 너무 번거로웠다.
Paywalls v2는 이 흐름을 완전히 바꾼다:
- RevenueCat 대시보드에서 드래그앤드롭으로 페이월 디자인
- 가격, 혜택 목록, 버튼 텍스트, 색상 전부 노코드로 설정
- 저장하면 즉시 반영 — 앱스토어 재심사 불필요
앱을 한 번 배포하고 나면 그 이후의 페이월 변경은 전부 대시보드에서 처리한다. 가격 실험, UI 테스트, 할인 프로모션을 앱 배포 없이 실행할 수 있다.
Paywalls v2는 RevenueCat SDK가 설치된 앱에서만 동작한다. 기존 앱에 SDK를 추가하고 페이월 컴포넌트를 삽입하는 작업은 몇 시간이면 충분하다. 그 이후로는 코드 한 줄 없이 페이월을 완전히 제어할 수 있다.
3. Experiments — 코드 없는 A/B 테스트
구독 비즈니스에서 가장 중요한 질문은 "어떤 가격이 맞는가"다. $9.99가 맞는가, $14.99가 맞는가, 아니면 연간 플랜을 더 강조해야 하는가.
Experiments 기능은 이 질문에 데이터로 답한다.
- 가격 변경 실험: $9.99 vs $14.99 — 어느 쪽이 전환율이 높은가
- 페이월 레이아웃 실험: 기능 목록 강조 vs 가격 강조
- 구독 기간 실험: 월간 vs 연간 플랜 버튼 순서
- 무료 체험 기간 실험: 7일 vs 14일
실험은 사용자를 A/B 그룹으로 나눠서 각각 다른 페이월을 보여준다. 결과는 RevenueCat 대시보드에서 전환율, MRR 기여도, LTV 기준으로 분석할 수 있다.
코드를 한 줄도 바꾸지 않고 가격 전략을 최적화한다. 1인 개발자에게 이건 엄청난 레버리지다.
4. 구독 분석 대시보드
RevenueCat은 구독 비즈니스 핵심 지표를 전부 제공한다:
| 지표 | 설명 |
|---|---|
| MRR | 월간 반복 수익 |
| ARR | 연간 반복 수익 예측 |
| Churn Rate | 구독 취소율 |
| Trial Conversion | 무료 체험 → 유료 전환율 |
| LTV | 고객 생애 가치 |
| Cohort Retention | 코호트별 구독 유지율 |
특히 Cohort Retention은 장기 지표다. 특정 달에 구독을 시작한 유저들이 3개월 후, 6개월 후에 얼마나 남아있는지 추적한다. 제품이 진짜로 가치를 전달하고 있는지 판단하는 핵심 신호다.
앱스토어 커넥트의 기본 분석보다 훨씬 세분화된 데이터를 제공한다.
5. Web Billing — 앱스토어 수수료 우회
2024년 출시된 Web Billing은 전략적으로 중요한 기능이다.
앱스토어 인앱결제를 쓰면 Apple/Google이 15-30%를 가져간다. 웹에서 직접 결제를 받으면 이 수수료를 피할 수 있다. RevenueCat Web Billing은 Stripe 기반의 웹 결제 흐름을 구독 생태계에 통합한다.
- 앱에서 "웹에서 구독하기" 링크 제공
- Stripe 결제 페이지로 이동
- 구독 완료 후 앱으로 돌아오면 자동으로 구독 상태 동기화
비용 구조가 바뀐다:
- 앱스토어 경로: 수익의 15-30% 수수료
- Web Billing 경로: RevenueCat 1% + Stripe 2.9% + 30¢
가격대가 높은 구독이라면 Web Billing 경로가 유의미하게 유리하다.
Web Billing은 현재 Stripe만 지원한다. 한국 KRW 결제의 경우 Stripe가 지원하지만, 토스페이먼츠나 다른 국내 PG사는 연동되지 않는다. 국내 앱이 주 타깃이라면 앱스토어 인앱결제 + RevenueCat 기본 플로우를 유지하는 게 더 현실적이다.
가격 구조
RevenueCat의 가격 모델은 1인 개발자 친화적으로 설계되어 있다.
| 플랜 | 비용 | 조건 |
|---|---|---|
| Free | $0 | MTR $2,500까지 |
| Starter | 수익의 1% | MTR $2,500 초과분 |
| Pro | 수익의 1% + 고급 기능 | 팀 기능, 우선 지원 |
| Enterprise | 협의 | 대형 앱 전용 |
**MTR(Monthly Tracked Revenue)**이 $2,500를 넘기 전까지는 완전 무료다. 국내 앱 기준으로 월 수익 약 350만원까지는 비용이 없다. 처음 앱을 출시하고 첫 수익이 날 때까지 구독 인프라에 돈을 쓰지 않아도 된다.
$2,500를 초과하면 초과분에 대해 1%가 붙는다. 월 수익 $5,000이면 RevenueCat에 내는 비용은 ($5,000 - $2,500) × 1% = $25다.
1%는 앱스토어 수수료와 별도다. 앱스토어가 이미 15-30%를 가져가고, 그 위에 RevenueCat이 1%를 더 가져간다. 규모가 커지면 절대 금액도 커지지만, 그 수준이면 RevenueCat이 제공하는 인프라 가치가 더 크다는 게 업계 공통 의견이다.
장단점
잘하는 것
빠른 통합: 공식 문서가 잘 되어 있고 SDK가 잘 추상화되어 있다. iOS 기준으로 기본 구독 플로우를 1일 안에 완성할 수 있다.
멀티플랫폼 통일: iOS, Android를 동시에 개발하면 구독 로직을 한 번만 설계하면 된다. React Native나 Flutter라면 더욱 강력하다.
무료 티어: MTR $2,500까지 무료라는 건 초기 단계에서 진입 장벽이 없다는 뜻이다. 아직 수익이 없을 때 인프라를 먼저 구축하고 수익이 나기 시작하면 자연스럽게 유료로 전환된다.
Experiments: 가격 A/B 테스트가 앱 배포 없이 가능하다는 것 자체가 큰 장점이다. 구독 전환율을 10%만 올려도 LTV가 크게 달라진다.
업계 표준: 83,000개 앱이 쓰는 플랫폼이다 보니 커뮤니티가 크고, Stack Overflow 답변도 많고, 서드파티 통합(Mixpanel, Amplitude, Braze 등)도 풍부하다.
아쉬운 것
1% 누적: 규모가 커지면 절대 금액이 올라간다. 월 수익 $50,000이면 RevenueCat 비용이 $475/월이다. 이 수준에서는 자체 구현의 비용-편익을 다시 계산해볼 수 있다.
Web Billing Stripe 전용: 국내 결제 생태계와의 연동이 아쉽다. 토스페이먼츠, 카카오페이 같은 국내 PG사를 Web Billing으로 연결할 수 없다. 국내 정기결제가 필요하다면 페이플 같은 전용 솔루션을 별도로 검토해야 한다.
엣지케이스 디버깅: 구독 로직이 추상화되어 있다 보니, 문제가 생겼을 때 원인을 추적하기가 까다로울 수 있다. RevenueCat 쪽 문제인지 앱스토어 쪽 문제인지 판단하는 데 시간이 걸린다.
오프라인 사용: RevenueCat SDK는 서버 통신이 필요하다. 오프라인 환경에서의 구독 상태 처리는 직접 캐싱 로직을 추가해야 한다.
실제 사용 사례
Widgetsmith: App Store 1위를 기록한 위젯 앱. RevenueCat으로 구독 인프라를 빠르게 구축하고 제품에 집중했다.
HabitKit: 습관 추적 앱. RevenueCat Experiments로 가격 A/B 테스트를 반복하면서 월 MRR $30,000에 도달했다. 코드 배포 없이 가격 전략만 최적화한 결과다.
두 사례의 공통점: 구독 인프라 직접 구현에 시간을 쓰지 않고, 그 시간을 제품과 마케팅에 투자했다.
RevenueCat을 선택해야 할 때
아래 조건 중 하나라도 해당되면 RevenueCat이 맞다:
- 모바일 앱에 구독 기능을 추가하려는데 구독 연동 경험이 없다
- iOS와 Android를 동시에 지원해야 한다
- 가격 실험을 해보고 싶지만 앱스토어 재심사 사이클이 너무 길다
- 구독 분석(MRR, Churn, LTV)을 제대로 보고 싶다
- 웹 결제로 앱스토어 수수료를 줄이는 방안을 탐색 중이다
반대로, 이런 경우라면 다른 선택지를 고려해볼 수 있다:
- 순수 웹 SaaS만 운영하고 모바일 앱이 없다 (Paddle 같은 웹 전용 구독 플랫폼이 더 적합)
- 이미 자체 구독 인프라가 안정적으로 운영 중이고 이전 비용이 크다
- MTR이 높아서 1% 비용이 자체 구현 인건비보다 커진 경우
시작하는 법
- revenuecat.com에서 무료 계정 생성
- 앱스토어 커넥트 / Google Play Console에서 상품 생성
- RevenueCat에서 프로젝트 생성 → API Key 발급
- SDK 설치 후 초기화:
// iOS AppDelegate 또는 App Entry Point
Purchases.configure(withAPIKey: "your_api_key")
- Entitlements 설정 (어떤 기능을 어떤 구독 플랜에 연결할지)
- 페이월 UI 구현 또는 Paywalls v2로 노코드 제작
공식 문서(production-docs.revenuecat.com)가 플랫폼별로 잘 정리되어 있다. iOS 퀵스타트 가이드를 따라가면 1-2시간 안에 기본 구독 플로우를 완성할 수 있다.
시작 전에 RevenueCat 대시보드에서 Sandbox 환경을 먼저 설정하라. 앱스토어 샌드박스 계정으로 결제 테스트를 충분히 한 다음 프로덕션으로 전환하는 게 안전하다. 실제 결제가 발생하기 전에 구독 갱신, 취소, 복원 플로우를 전부 테스트해보는 게 좋다.
구독 결제 플랫폼 비교
| 항목 | RevenueCat | Paddle | 페이플 | 토스페이먼츠 |
|---|---|---|---|---|
| 주요 대상 | 모바일 앱 | 웹 SaaS | 한국 SaaS | 한국 전반 |
| 수수료 | MTR 1% (+ 앱스토어) | 5% + $0.50 | 1.0~2.9% | 0.8~2.8% |
| 무료 티어 | $2,500 MTR | 없음 | 없음 | 없음 |
| Web Billing | Stripe 기반 | MoR 내장 | 미지원 | 미지원 |
| 앱스토어 30% 우회 | 가능 (Web) | 해당 없음 | 해당 없음 | 해당 없음 |
| 페이월 A/B 테스트 | 내장 (노코드) | 미지원 | 미지원 | 미지원 |
| 크로스 플랫폼 | iOS/Android/Web | 웹 전용 | 웹 전용 | 웹 전용 |
| MoR (세금 대리) | 앱스토어가 대리 | MoR 제공 | 미제공 | 미제공 |
언제 무엇을 선택할까
- 모바일 앱 구독 (iOS/Android) → RevenueCat
- 웹 SaaS + 글로벌 세금 자동화 → Paddle
- 한국 원화 정기결제 (카드+계좌) → 페이플
- 한국 단일 PG + 빠른 정산 → 토스페이먼츠
마치며
모바일 구독 연동은 "해봐야 알아" 영역이다. 처음 해보면 생각보다 복잡하고, 엣지 케이스가 생각보다 많다는 걸 몸으로 배운다.
RevenueCat은 그 학습 비용과 개발 시간을 대신 지불해주는 플랫폼이다. $2,500 MTR까지 무료라는 건 첫 수익이 날 때까지 인프라 비용 없이 시작할 수 있다는 뜻이다. 83,000개 앱이 선택한 데는 이유가 있다.
1인 개발자로 모바일 구독 앱을 만든다면, 구독 연동에 2주를 쓰는 것보다 RevenueCat에 올인하고 그 시간을 제품에 쓰는 게 낫다. 스케일이 커지고 1% 비용이 유의미해지는 시점은, 그때 고민해도 늦지 않다.
함께 읽으면 좋은 글
- Paddle 실전 가이드 — 웹 SaaS 구독을 위한 Merchant of Record 방식
- 토스페이먼츠 실전 가이드 — 한국 원화 결제 연동의 표준
- 페이플 실전 가이드 — 한국 정기결제 전용 솔루션
- Polar 실전 가이드 — 개발자 도구·오픈소스 프로젝트의 구독 수익화