결제#RevenueCat#구독#인앱결제#모바일#iOS#Android#1인개발

RevenueCat 실전 가이드: 1인 개발자를 위한 인앱 구독 관리의 표준

2026년 3월 17일·15분 읽기

TL;DR

RevenueCat은 iOS/Android 인앱 구독을 단일 SDK로 통합 관리하는 플랫폼 — 앱스토어마다 다른 구독 로직을 추상화
Pro 플랜은 월 MTR $2,500를 넘기기 전까지 무료, 임계치를 넘긴 달에는 그 달 MTR의 1% 과금
Paywalls v2(2025.6 GA): 노코드로 페이월 디자인, 앱 재심사 없이 원격 변경 가능
RevenueCat Web Billing은 Stripe를 결제 게이트웨이로 쓰는 자체 웹 빌링 엔진 — Stripe Billing import와는 다르다
Experiments는 원격 설정 기반 A/B 테스트 도구이고, 2026년부터는 조건 충족 시 12개월 LTV 예측 우승안도 보여준다

ℹ️INFO

이 글은 2026-04-05 기준 RevenueCat 공식 pricing/docs, Paywalls v2 GA 공지, Web Billing 문서, SOSA 2026 보고서를 기준으로 다시 확인해 정리했다. 요금, 지원 범위, 스토어 정책은 바뀔 수 있으니 배포 직전에 공식 문서를 다시 확인하는 것이 안전하다.

RevenueCat 대시보드 개요 — RevenueCat Paywalls v2 GA — 노코드 페이월 빌더로 앱 재심사 없이 즉시 반영

구독 연동, 직접 구현하면 어떻게 되나

앱에 구독 기능을 넣는다고 결심하는 순간, 예상치 못한 복잡성이 기다리고 있다.

iOS부터 시작해보자. StoreKit 2 API를 배워야 하고, 영수증 검증 서버를 따로 구축해야 한다. 구독 갱신, 업그레이드, 다운그레이드, 환불 처리, 만료 감지 — 각각 다른 로직이 필요하다. 거기에 샌드박스 환경 테스트가 생각보다 까다롭다.

Android도 마찬가지다. Play Billing Library가 따로 있고, 상태 관리 방식이 iOS와 다르다. 두 플랫폼을 동시에 지원한다면 사실상 구독 로직을 두 번 구현해야 한다.

그리고 제일 무서운 건 엣지 케이스다. 구독 중에 앱을 삭제하면? 기기를 바꾸면? 가족 공유를 쓰면? 환불 후 재구독하면? 이런 케이스들을 전부 처리하다 보면 핵심 기능 개발 시간이 구독 로직에 잡아먹힌다.

RevenueCat은 이 모든 것을 대신 처리한다.

RevenueCat이 뭔가

RevenueCat은 모바일 인앱 구독 인프라와 성장 도구를 함께 제공하는 플랫폼이다. 공식 사이트는 89,000개 앱이 RevenueCat을 신뢰한다고 말하고, State of Subscription Apps 2026 보고서는 RevenueCat이 통합된 115,000+ 앱, $16B+ 매출, 10억+ 트랜잭션을 분석 대상으로 사용했다.

핵심 철학은 간단하다. 플랫폼마다 다른 구독 API를 단일 인터페이스로 추상화하고, 그 위에 페이월/실험/분석 툴을 붙인다. 개발자는 RevenueCat SDK와 대시보드 중심으로 iOS, Android, Flutter, React Native, Unity, Kotlin Multiplatform 같은 대표 플랫폼의 구독 흐름을 더 적은 코드로 다룰 수 있다.

RevenueCat의 핵심 가치는 "결제 API 래퍼"에만 있지 않다. 페이월 원격 설정, 실험, 코호트 기반 수익/리텐션 분석, 웹 구매 연동까지 한 번에 붙는다는 점이 실제 운영 시간을 크게 줄인다.

핵심 기능 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를 동시에 개발할 때 구독 로직을 두 번 설계하는 부담이 줄어든다.

RevenueCat 크로스 플랫폼 아키텍처 — iOS와 Android 구독 흐름을 공통 엔타이틀먼트 모델로 다루고, 웹 구매도 별도 경로로 연결할 수 있다

2. Paywalls v2 — 노코드 페이월 빌더

2025년 6월 GA(Generally Available)된 Paywalls v2는 RevenueCat의 게임 체인저다.

기존에는 페이월 UI를 직접 코드로 짰다. 가격을 바꾸려면 코드 수정 → 빌드 → 앱스토어 심사(보통 1-3일) → 배포 과정을 거쳐야 했다. 실험하기가 너무 번거로웠다.

Paywalls v2는 이 흐름을 완전히 바꾼다:

RevenueCat 대시보드에서 드래그앤드롭으로 페이월 디자인
가격, 혜택 목록, 버튼 텍스트, 색상 전부 노코드로 설정
저장하면 즉시 반영 — 앱스토어 재심사 불필요

앱을 한 번 배포하고 나면 그 이후의 페이월 변경은 전부 대시보드에서 처리한다. 가격 실험, UI 테스트, 할인 프로모션을 앱 배포 없이 실행할 수 있다.

💡TIP

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 대시보드에서 전환, 수익 지표, 코호트 단위 결과로 분석할 수 있다. 2026년 2월부터는 revenue primary metric 실험에서 조건을 만족하면 predicted 12-month LTV winner도 함께 보여준다.

코드를 한 줄도 바꾸지 않고 가격 전략을 최적화한다. 1인 개발자에게 이건 엄청난 레버리지다.

RevenueCat Experiments A/B 테스트 결과 — Experiments 결과 화면 — 변형별 전환과 수익 지표를 대시보드에서 비교

4. 구독 분석 대시보드

RevenueCat 구독 분석 대시보드 — RevenueCat Overview — MRR, Active Subscriptions, New Customers 등 핵심 지표를 실시간으로 추적

RevenueCat은 구독 비즈니스 핵심 지표를 전부 제공한다:

지표	설명
MRR	월간 반복 수익
ARR	연간 반복 수익 예측
Churn Rate	구독 취소율
Trial Conversion	무료 체험 → 유료 전환율
LTV	고객 생애 가치
Cohort Retention	코호트별 구독 유지율

특히 Cohort Retention은 장기 지표다. 특정 달에 구독을 시작한 유저들이 3개월 후, 6개월 후에 얼마나 남아있는지 추적한다. 제품이 진짜로 가치를 전달하고 있는지 판단하는 핵심 신호다.

앱스토어 커넥트의 기본 분석보다 훨씬 세분화된 데이터를 제공한다.

5. Web Billing — 웹 구매 플로우를 붙일 때

RevenueCat의 Web Billing은 자체 웹 빌링 엔진이다. 여기서 중요한 점은, "RevenueCat이 Stripe Billing을 그냥 래핑한다"가 아니라 RevenueCat이 구독 수명주기를 관리하고 Stripe는 결제 게이트웨이로 사용된다는 점이다.

공식 문서 기준 RevenueCat Web Billing은:

RevenueCat이 구매 UI와 구독 수명주기를 관리
Stripe를 결제 게이트웨이로 사용
제품/가격/통화/체험/오퍼/청구 동작을 RevenueCat 대시보드에서 설정
고객 포털을 통해 구독 관리 기능 제공
앱에서 "웹에서 구독하기" 링크 제공
RevenueCat이 구성한 웹 구매 흐름으로 이동
구독 완료 후 앱으로 돌아오면 자동으로 구독 상태 동기화

여기서 흔히 "앱스토어 수수료 우회"라고 표현하지만, 그 말은 너무 단순하다. 정확히는 앱 구조와 스토어 정책이 허용하는 범위 안에서 웹 구매 플로우를 설계해 수수료 구조를 개선할 여지가 생긴다는 쪽이 맞다. RevenueCat 공식 사례 중 CardPointers는 Stripe 연동으로 앱스토어 수수료를 약 27% 절감했다고 공개했다.

RevenueCat Web Billing 고객 포털 — Web Billing 고객 포털 — 구독 관리 경험을 RevenueCat 쪽에서 구성할 수 있다

가격대가 높은 구독일수록 웹 구매 경로의 경제성이 커질 수 있다. 다만 심사 가이드, 유저 경험, 웹 전환 퍼널을 함께 봐야 한다.

Web Billing 수수료 구조 비교 — 앱스토어 경로와 웹 구매 경로는 수수료 구조가 다르다. 실제 절감폭은 앱 구조와 결제 구성에 따라 달라진다

⚠️WARNING

RevenueCat Web Billing 자체는 Stripe를 결제 게이트웨이로 사용한다. 별도로 RevenueCat Web SDK 문서에는 Paddle Billing 연동 경로도 보이지만, 이 글에서 말하는 "RevenueCat Web Billing"은 Stripe gateway 기준이다. 한국 원화 결제와 국내 PG 중심 운영이 핵심이라면 토스페이먼츠 같은 국내 플로우와의 역할 분리를 먼저 설계하는 편이 현실적이다.

가격 구조

RevenueCat의 가격 모델은 1인 개발자 친화적으로 설계되어 있다.

플랜	비용	조건
Pro	월 MTR $2,500 이하 무료, 초과 달은 MTR의 1%	대부분의 앱에 해당
Enterprise	커스텀	대형 앱, 복잡한 운영
Just Paywalls	커스텀	기존 purchase code 위에 Paywalls / Experiments만 언번들 사용

공식 pricing 페이지의 핵심은 이거다:

월 MTR(Monthly Tracked Revenue)이 $2,500 미만인 달은 무료
$2,500 이상이 되는 달에는 그 달 MTR 전체에 대해 1% 과금
MTR은 플랫폼 컷 전, RevenueCat이 추적한 구독/갱신/일회성 구매 매출 기준

여기서 많이 헷갈리는 지점이 하나 있다. 초과분에만 1%가 붙는 구조가 아니다. 예를 들어 그 달 MTR이:

$2,500이면 RevenueCat 비용은 $25
$5,000이면 RevenueCat 비용은 $50

ℹ️INFO

1%는 앱스토어 수수료와 별도다. 그리고 RevenueCat은 결제대행사가 아니라 결제 인프라/성장 툴이다. 실제 정산은 Apple, Google, Stripe 같은 결제 제공자가 계속 맡는다.

장단점

잘하는 것

빠른 통합: 공식 문서가 잘 되어 있고 SDK가 잘 추상화되어 있다. 직접 구현 대비 훨씬 빠르게 기본 구독 플로우를 올릴 수 있다.

멀티플랫폼 통일: iOS, Android를 동시에 개발하면 구독 로직을 한 번만 설계하면 된다. React Native나 Flutter라면 더욱 강력하다.

무료 티어: MTR $2,500까지 무료라는 건 초기 단계에서 진입 장벽이 없다는 뜻이다. 아직 수익이 없을 때 인프라를 먼저 구축하고 수익이 나기 시작하면 자연스럽게 유료로 전환된다.

Experiments: 가격 A/B 테스트가 앱 배포 없이 가능하다는 것 자체가 큰 장점이다. 구독 전환율을 10%만 올려도 LTV가 크게 달라진다.

업계 표준성: 공식 사이트 기준 89,000개 앱이 RevenueCat을 신뢰한다고 밝히고 있고, 문서/통합/사례가 풍부하다.

아쉬운 것

1% 누적: 규모가 커지면 절대 금액이 올라간다. 월 MTR이 $50,000이면 RevenueCat 비용은 약 $500/월이다. 이 수준에서는 자체 구현과 비교한 비용-편익을 다시 계산해볼 만하다.

Web Billing Stripe 전용: 국내 결제 생태계와의 연동이 아쉽다. 토스페이먼츠, 카카오페이 같은 국내 PG사를 Web Billing으로 연결할 수 없다. 국내 정기결제가 필요하다면 페이플 같은 전용 솔루션을 별도로 검토해야 한다.

추상화의 대가: 문제가 생겼을 때 원인이 RevenueCat인지, 앱스토어인지, 웹 결제 게이트웨이인지 레이어를 따라가며 디버깅해야 한다.

실제 사용 사례

Widgetsmith: RevenueCat 공식 고객 사례. 직접 만들면 몇 주 걸릴 구독 시스템 대신 RevenueCat을 붙였고, 앱이 미국 App Store 1위를 찍으며 수천만 다운로드로 커졌을 때도 결제 인프라가 버텼다고 밝혔다.

CardPointers: RevenueCat 공식 사례. Stripe 연동으로 앱스토어 수수료를 약 27% 절감했다고 공개했다. 웹 구매와 모바일 구독을 함께 운영할 때 RevenueCat이 왜 전략적 레버인지 보여준다.

Pixery / The Tapping Solution: RevenueCat 공식 pricing 페이지에 따르면 Pixery는 실험 속도가 6배 빨라졌고, The Tapping Solution은 backend engineering hours를 50% 줄였다고 공개했다.

두 사례의 공통점: 구독 인프라 직접 구현에 시간을 쓰지 않고, 그 시간을 제품과 마케팅에 투자했다.

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로 노코드 제작

공식 문서(docs.revenuecat.com / revenuecat.com/docs)가 플랫폼별로 잘 정리되어 있다. iOS/Android 퀵스타트를 따라가면 기본 구독 플로우를 빠르게 올릴 수 있다.

💡TIP

시작 전에 RevenueCat 대시보드에서 Sandbox 환경을 먼저 설정하라. 앱스토어 샌드박스 계정으로 결제 테스트를 충분히 한 다음 프로덕션으로 전환하는 게 안전하다. 실제 결제가 발생하기 전에 구독 갱신, 취소, 복원 플로우를 전부 테스트해보는 게 좋다.

구독 결제 플랫폼 비교

항목	RevenueCat	Paddle	페이플	토스페이먼츠
주요 대상	모바일 앱	웹 SaaS	한국 SaaS	한국 전반
수수료	월 MTR $2.5K 초과 달의 MTR 1% (+ 앱스토어)	5% + $0.50	계약형	계약형
무료 티어	$2,500 MTR	없음	없음	없음
Web Billing	RevenueCat 자체 빌링 엔진 + Stripe gateway	MoR 내장	미지원	미지원
앱스토어 수수료 절감 여지	있음 (웹 구매 경로 설계 시)	해당 없음	해당 없음	해당 없음
페이월 A/B 테스트	내장 (노코드)	미지원	미지원	미지원
크로스 플랫폼	iOS/Android/Web	웹 전용	웹 전용	웹 전용
MoR (세금 대리)	앱스토어가 대리	MoR 제공	미제공	미제공

ℹ️INFO

비교표의 Paddle / 페이플 / 토스페이먼츠 수수료와 심사 정책은 자주 바뀔 수 있다. RevenueCat 항목은 이번 검증 패스에서 공식 가격/문서 기준으로 다시 맞췄고, 다른 솔루션은 각 공식 사이트를 한 번 더 확인하는 편이 안전하다.

언제 무엇을 선택할까

모바일 앱 구독 (iOS/Android) → RevenueCat
웹 SaaS + 글로벌 세금 자동화 → Paddle
한국 원화 정기결제 (카드+계좌) → 페이플
한국 단일 PG + 빠른 정산 → 토스페이먼츠

마치며

모바일 구독 연동은 "해봐야 알아" 영역이다. 처음 해보면 생각보다 복잡하고, 엣지 케이스가 생각보다 많다는 걸 몸으로 배운다.

RevenueCat은 구독 인프라의 복잡성을 줄여주는 플랫폼이다. 특히 모바일 앱에서 직접 구현 대비 얻는 시간 절감이 크고, Paywalls / Experiments / Web Billing까지 한 번에 이어진다는 점이 강하다. 공식 가격 구조도 초기에는 부담이 적다.

1인 개발자로 모바일 구독 앱을 만든다면, 직접 구현보다 RevenueCat을 먼저 검토할 가치가 높다. 다만 비용 계산은 "초과분 1%"가 아니라 "임계치를 넘긴 달의 MTR 전체 1%"라는 점을 꼭 기억해야 한다. 그리고 Web Billing은 만능 우회 카드가 아니라, 앱 구조와 정책이 맞을 때 효과가 커지는 옵션으로 이해하는 편이 정확하다.

사업자 없이 첫 매출 만들기

결제 솔루션을 골랐으면 이제 실전입니다. 30일 안에 첫 매출을 만들어보세요.

무료로 시작하기

구독 연동, 직접 구현하면 어떻게 되나

RevenueCat이 뭔가

핵심 기능 5가지

1. 통합 구독 SDK

2. Paywalls v2 — 노코드 페이월 빌더

3. Experiments — 코드 없는 A/B 테스트

4. 구독 분석 대시보드

5. Web Billing — 웹 구매 플로우를 붙일 때

가격 구조

장단점

잘하는 것

아쉬운 것

실제 사용 사례

RevenueCat을 선택해야 할 때

시작하는 법

구독 결제 플랫폼 비교

언제 무엇을 선택할까

마치며

함께 읽으면 좋은 글

사업자 없이 첫 매출 만들기