RevenueCat은 누가, 언제, 왜 써야 할까: 앱 구독 결제 도입 판단부터 연동까지
RevenueCat은 앱 안에서 구독이나 유료 기능을 팔려는 개발자에게 필요합니다. 특히 iOS와 Android를 함께 내거나, 서버에서도 유료 회원 여부를 알아야 하거나, 가격과 결제 화면을 바꿔가며 실험하고 싶다면 첫 유료화 전에 붙이는 것이 좋습니다. 영수증 검증, 갱신·환불 추적, 플랫폼 간 구독 상태 동기화를 직접 만들 필요가 없어지고, 앱 코드는 "이 사용자가 pro 권한을 가졌는가"만 확인하면 됩니다. 월 추적 매출 $2,500까지는 무료라서 매출이 없는 단계에서는 비용 부담도 없습니다.
한눈에 보기
| 질문 | 답 |
|---|---|
| 누구에게 필요한가 | 앱 안에서 월·연 구독, 평생 이용권 같은 디지털 상품을 파는 1인 개발자와 소규모 팀 |
| 언제 도입하나 | 첫 유료 기능을 출시하기 전. 늦어도 두 번째 플랫폼을 내기 전 |
| 왜 쓰나 | 결제 이후의 일(검증, 갱신, 환불, 상태 동기화, 스토어 정책 대응)을 직접 만들고 유지하지 않기 위해 |
| 어떻게 쓰나 | 권한(Entitlement)과 상품을 정하고, Test Store로 테스트한 뒤, SDK에서 권한만 확인 |
| 얼마인가 | 월 추적 매출(MTR) $2,500 미만은 무료, 넘으면 MTR 전체의 1% |
누구에게 필요한가
필요한 사람
앱 안에서 디지털 기능이나 콘텐츠를 파는 경우, 대부분은 App Store와 Google Play의 인앱 결제를 써야 합니다. 이때 두 스토어의 결제 API, 영수증 형식, 환불 규칙이 전부 다릅니다. 아래 중 하나라도 해당하면 RevenueCat을 쓰는 편이 빠릅니다.
- iOS와 Android를 둘 다 내거나, 앞으로 낼 계획이 있다
- 앱 밖(내 서버, 웹, n8n 같은 자동화)에서도 "이 사람이 지금 유료 회원인가"를 알아야 한다
- 월 구독, 연 구독, 평생 이용권처럼 상품이 여러 개다
- 가격이나 결제 화면을 앱 업데이트 없이 바꾸고 A/B 테스트하고 싶다
- 결제 백엔드를 맡을 전담 개발자가 없다
바이브코딩으로 앱을 빠르게 만드는 1인 개발자나 소규모 팀이 정확히 여기에 해당합니다. 앱 기능은 AI로 하루 만에 만들어도, 구독 상태를 정확하게 유지하는 서버는 AI가 짜준 코드만으로 운영하기 부담스러운 영역이기 때문입니다.
굳이 필요 없는 사람
모든 앱에 필요한 것은 아닙니다. 아래 경우라면 다른 선택지가 더 단순할 수 있습니다.
- 웹에서만 파는 SaaS: 앱스토어 결제가 끼지 않는다면 Stripe 같은 결제 서비스를 직접 쓰는 편이 구조가 단순합니다.
- iOS 하나, 구독 상품 하나, 서버 연동 없음: StoreKit 2만으로도 충분히 구현할 수 있습니다. 나중에 Android를 추가할 계획이 생기면 그때 다시 판단해도 됩니다.
- 실물 상품이나 오프라인 서비스 결제: 인앱 결제 대상이 아니므로 일반 PG 결제를 씁니다.
언제 도입해야 하나
가장 좋은 시점은 첫 유료 기능을 출시하기 전입니다. 이미 스토어 결제를 직접 구현해서 사용자가 쌓인 뒤에 옮기면, 기존 구독자 데이터를 이전하는 작업이 추가됩니다. RevenueCat이 이전 가이드를 제공하긴 하지만, 처음부터 붙이면 그 일 자체가 없습니다.
도입 시점을 판단하는 신호는 이렇습니다.
| 지금 상황 | 추천 |
|---|---|
| 앱은 만들었고 유료화를 고민 중 | 지금 붙이기. 매출 전이라 무료이고 Test Store로 바로 실험 가능 |
| iOS만 직접 구현해서 팔고 있고 Android 출시 예정 | Android 출시 전에 전환 |
| 구독자가 "결제했는데 권한이 안 열린다"는 문의가 늘어남 | 상태 동기화 문제 신호. 전환 검토 |
| 가격을 바꿔보고 싶은데 매번 앱 심사를 기다림 | Offering·Paywall 원격 설정이 필요한 시점 |
| 유료화 계획이 전혀 없음 | 아직 필요 없음 |
왜 써야 하나: 결제 버튼 뒤에 숨은 일들
결제 버튼 자체는 StoreKit이나 Google Play Billing으로 비교적 쉽게 띄울 수 있습니다. 어려운 건 결제 이후입니다. 직접 만들면 아래 일을 모두 해야 합니다.
| 직접 만들 때 해야 하는 일 | RevenueCat을 쓰면 |
|---|---|
| 결제 영수증이 진짜인지 서버에서 검증 | 자동 검증 |
| 갱신, 해지, 환불, 결제 실패 유예 상태를 계속 추적 | CustomerInfo 하나로 현재 상태 조회 |
| iOS·Android·웹의 구독 상태를 한 사용자로 합치기 | 같은 프로젝트 안에서 권한 공유 |
| 스토어 정책·API 변경에 맞춰 코드 수정 | RevenueCat이 SDK 업데이트로 대응 |
| MRR, 전환율, 이탈률 대시보드 구축 | 기본 제공 |
| 결제 이벤트를 내 서버·자동화로 전달 | Webhook 제공 |
한 문장으로 줄이면, 작은 팀이 "앱 기능"보다 "유료 회원 상태를 맞게 유지하는 인프라"에 시간을 쓰지 않게 해주는 서비스입니다. RevenueCat 공식 사이트도 스스로를 "상자째 제공하는 구독 백엔드"라고 설명합니다.
어떻게 쓰나
글에 들어간 대시보드 화면은 RevenueCat 프로젝트를 새로 만든 직후의 실제 상태입니다. 아직 실제 스토어를 연결하거나 실제 결제를 받은 단계는 아니라서, 동작 방식은 공식 문서를 기준으로 설명했습니다.
먼저 알아야 할 네 가지 개념
| 개념 | 한 줄 정의 | 예시 |
|---|---|---|
| Product | 스토어에 실제로 등록되는 개별 결제 상품 | 월 구독, 연 구독, 평생 이용권 |
| Entitlement | 결제로 얻는 "이용 권한". 앱 코드가 확인하는 대상 | pro (유료 기능 전체) |
| Offering / Package | 결제 화면에 보여줄 상품 묶음. Package는 플랫폼별 같은 상품을 묶은 단위 | 기본 Offering = 월·연·평생 3개 Package |
| CustomerInfo | 한 사용자의 현재 구독·권한 상태 | "pro 활성, 다음 달 만료" |
핵심은 Entitlement입니다. 월 구독이든 연 구독이든 평생 이용권이든 같은 Entitlement에 붙여두면, 앱은 상품 ID를 하나하나 다루지 않고 "datapopcorn_pro가 활성인가"만 확인하면 됩니다. 구독 상품은 구독 기간 동안, 평생 이용권 같은 비소모성 상품은 영구적으로 권한을 엽니다. 공식 문서도 대부분의 앱은 Entitlement 하나면 충분하다고 설명합니다.
출처: 데이터팝콘 RevenueCat 프로젝트 대시보드 (Product catalog > Entitlements). datapopcorn_pro 권한 하나에 상품 3개가 연결되어 있습니다.
1단계: 권한과 상품을 정합니다
새 프로젝트에는 테스트용 Test Store가 함께 만들어집니다. 여기에 Monthly, Yearly, Lifetime 같은 테스트 상품을 만들고 Entitlement에 연결합니다. 실제 스토어를 연결하면 이 목록에 App Store, Google Play 섹션이 추가됩니다.
출처: 데이터팝콘 RevenueCat 프로젝트 대시보드 (Product catalog > Products).
다음으로 결제 화면에 보여줄 상품 묶음인 Offering을 만듭니다. 앱이 특정 상품 ID를 하드코딩하지 않고 current Offering을 불러오게 만들면, 대시보드에서 기본 Offering만 바꿔도 앱 업데이트 없이 결제 화면 구성이 바뀝니다. Paywalls, Experiments(A/B 테스트), Targeting 기능도 모두 Offering을 기준으로 동작합니다.
출처: 데이터팝콘 RevenueCat 프로젝트 대시보드 (Offerings > default). Offering 하나에 Paywall, 웹 구매 링크, Targeting 규칙을 연결하는 구조입니다.
2단계: Test Store로 스토어 설정 없이 테스트합니다
App Store Connect나 Google Play Console 설정을 끝내지 않아도, Test Store API 키로 SDK를 초기화하면 바로 구매 흐름을 시험할 수 있습니다. 테스트 구매도 실제 구매처럼 CustomerInfo를 갱신하고 Entitlement를 열어주며, 대시보드에는 샌드박스 데이터로 기록됩니다.
출처: 데이터팝콘 RevenueCat 프로젝트 대시보드 (Apps). API 키는 기본적으로 가려져 있고, 실제 스토어 연결은 "New app configuration"에서 추가합니다.
Test Store에서는 시스템 결제창 대신 성공, 실패, 취소를 고를 수 있는 모달이 뜹니다. 구독 갱신도 빠르게 돌아가서 월 구독은 5분마다 갱신되고 5번 갱신된 뒤 종료됩니다(총 25분). 결제 실패나 만료 후 화면이 제대로 바뀌는지 한 달을 기다리지 않고 확인할 수 있습니다.
3단계: 앱에서는 권한만 확인합니다
SDK는 Swift, Kotlin, Flutter, React Native, Capacitor, Unity, 웹(JS) 등을 지원합니다. 아래는 React Native 기준 최소 예시입니다.
import { Platform } from 'react-native';
import Purchases from 'react-native-purchases';
// 앱 시작 시 한 번
Purchases.configure({
// 개발 빌드는 Test Store 키, 릴리스 빌드는 플랫폼별 키
apiKey: Platform.OS === 'ios' ? APPLE_API_KEY : GOOGLE_API_KEY,
});
// 화면을 그리기 전, Paywall을 띄우기 전에 확인
export async function isPro(): Promise<boolean> {
const customerInfo = await Purchases.getCustomerInfo();
return typeof customerInfo.entitlements.active['datapopcorn_pro'] !== 'undefined';
}
공식 퀵스타트는 앱 실행 시점과 Paywall을 띄우기 직전에 이 확인을 하라고 안내합니다. 이미 구독한 사람에게 결제 화면을 또 보여주지 않기 위해서입니다.
4단계: 결제 화면은 템플릿으로 만듭니다
결제 화면을 직접 그려도 되지만, RevenueCat Paywalls를 쓰면 대시보드 편집기로 만든 화면을 SDK가 그대로 그려줍니다. 템플릿에서 시작하거나, 빈 화면에서 만들거나, AI 채팅으로 생성할 수 있습니다.
출처: 데이터팝콘 RevenueCat 프로젝트 대시보드 (Paywalls > Select template).
앱 쪽 코드는 한 번의 호출로 끝납니다. 권한이 없는 사용자에게만 현재 Offering의 Paywall을 띄웁니다.
import RevenueCatUI, { PAYWALL_RESULT } from 'react-native-purchases-ui';
const result = await RevenueCatUI.presentPaywallIfNeeded({
requiredEntitlementIdentifier: 'datapopcorn_pro',
});
// PURCHASED 또는 RESTORED면 유료 기능을 연다
Paywall은 Offering에 연결되기 때문에 문구나 가격 구성을 바꿀 때 앱 심사를 다시 받을 필요가 없습니다.
5단계: 출시 전에 실제 스토어 키로 바꿉니다
실제 판매를 하려면 App Store 또는 Google Play 설정을 추가하고 플랫폼 전용 API 키로 SDK를 초기화해야 합니다. 공식 문서는 Test Store API 키가 들어간 앱을 스토어에 제출하지 말라고 강하게 경고합니다. 개발 빌드와 릴리스 빌드의 키를 빌드 설정에서 나눠두는 것이 안전합니다.
더 붙이면 좋은 것: Webhook과 MCP
결제 이벤트를 서버나 자동화로 받고 싶다면 Webhook을 씁니다. 구매, 갱신, 취소, 만료 이벤트가 POST로 오므로 n8n Webhook 노드로 받아 "새 구독자 Slack 알림", "해지 시 설문 메일" 같은 흐름을 만들 수 있습니다. 받는 쪽은 200을 돌려줘야 하고, 실패하면 5·10·20·40·80분 간격으로 최대 5번 재시도합니다. 취소 이벤트는 해지 후 최대 2시간쯤 늦게 올 수 있습니다.
AI 코딩 도구를 쓴다면 RevenueCat MCP 서버(https://mcp.revenuecat.ai/mcp)를 연결해 상품, Offering, Paywall 관리와 지표 분석을 자연어로 요청할 수 있습니다. 조회만 할 때는 읽기 전용 키, 상품을 만들거나 고칠 때만 쓰기 권한 키를 쓰는 편이 안전합니다.
얼마인가
RevenueCat 요금은 MTR(Monthly Tracked Revenue, 월 추적 매출)을 기준으로 합니다. MTR이 $2,500 미만이면 기능 제한 없이 무료이고, 넘으면 MTR의 1%가 청구됩니다.
- MTR은 MRR(월 반복 매출)과 다릅니다. 구독뿐 아니라 평생 이용권 같은 일회성 구매와 갱신까지 포함합니다.
- 스토어 수수료와 세금을 떼기 전 금액이 기준입니다. 실수령액 대비로는 1%보다 조금 더 큰 비중이 됩니다.
- $2,500을 넘으면 넘은 부분이 아니라 MTR 전체에 1%가 붙습니다. 공식 문서 예시로 MTR이 $2,600이면 $26입니다.
- 다시 $2,500 아래로 내려가면 그 기간은 다시 무료가 됩니다.
Apple Developer Program 연회비나 스토어 수수료는 별개로 그대로 나갑니다. 가입 첫 달에 바로 한도를 넘으면 30일 유예가 있지만 그 이후에 넘으면 결제가 완료될 때까지 기능 접근이 곧바로 제한되므로, 매출이 생기기 시작하면 카드를 미리 등록해두는 편이 안전합니다.
출처: 데이터팝콘 RevenueCat 프로젝트 대시보드 (Overview). 판매 전까지 남은 단계가 체크리스트로 나오고, MTR 사용량이 $0 / $2,500으로 표시됩니다.
도입 전에 알아둘 점
Entitlement 이름은 처음에 오래 쓸 이름으로 정합니다
앱에 배포한 Entitlement ID를 바꾸면 기존 버전 앱이 권한을 찾지 못합니다. pro처럼 짧고 오래 쓸 이름으로 정하는 편이 안전합니다.
Test Store 상품은 만든 뒤 가격을 고칠 수 없습니다
가격이나 기간을 바꾸려면 새 상품을 만들어 Offering의 Package를 교체해야 합니다. 테스트 상품이라도 이름과 가격을 처음에 신중하게 정하는 게 좋습니다.
매출이 커지면 1%도 커집니다
무료 구간은 넉넉하지만 수수료는 매출에 비례해 계속 늘어납니다. 월 매출이 $10,000이면 $100, $100,000이면 $1,000입니다. 규모가 커졌을 때의 비용을 직접 구축·운영 비용과 비교해두면 나중에 판단이 쉽습니다.
정리
- 누구: 앱 안에서 구독이나 유료 기능을 파는 1인 개발자와 소규모 팀. 특히 iOS와 Android를 함께 내는 경우
- 언제: 첫 유료 기능을 출시하기 전. 늦어도 두 번째 플랫폼을 내기 전
- 왜: 결제 이후의 검증, 갱신, 환불, 상태 동기화, 정책 대응을 직접 만들고 유지하지 않기 위해
- 어떻게: Entitlement와 상품을 정하고, Test Store로 테스트하고, 앱에서는 권한만 확인
- 얼마: 월 매출 $2,500까지 무료, 넘으면 전체 매출의 1%
직접 확인한 범위는 여기까지입니다. 카드 등록 없이 Entitlement 1개, Test Store 상품 3개, 기본 Offering 1개를 구성하는 데 비용은 들지 않았고, 실제 결제를 받기 전까지 남은 일은 SDK 연동과 스토어 설정뿐입니다. 실제 결제가 들어오기 시작하면 전환율과 이탈 지표를 가지고 후속 글에서 이어서 정리하겠습니다.