수익화 포트폴리오
one-time product, subscription, base plan, offer 조합을 운영 관점에서 설계하는 기준
기준일
2026년 3월 13일. 상품 카탈로그, subscription, base plan, offer 구조는 Play Console Help와 Google Play Billing 공식 문서를 기준으로 작성했습니다.
Android 운영에서 중요한 것은 상품 수를 늘리는 것이 아니라 카탈로그를 통제 가능한 구조로 유지하는 것입니다. 구독 상품을 여러 개로 쪼개기보다 하나의 subscription 아래에서 base plan과 offer를
운영하는 편이 보고서와 교체 흐름을 훨씬 안정적으로 만듭니다.
수익모델 선택 기준
| 모델 | 적합한 앱 | 장점 | 운영 리스크 |
|---|---|---|---|
| Paid app | 진입 자체가 가치인 도구형 앱 | 구조가 단순함 | 실험과 업셀이 제한적 |
| One-time product | 영구 잠금 해제, 크레딧 번들 | 가격 메시지가 명확함 | SKU 난립 시 운영 복잡도 증가 |
| Subscription + base plans | 지속 서비스, 콘텐츠, 멤버십 | 교체와 할인 구조가 유연함 | base plan/offer 설계가 복잡해질 수 있음 |
| Offers | 체험, 이탈 복귀, 지역별 프로모션 | 전환/복귀 캠페인용 | 기준 가격이 약하면 장기적으로 왜곡 |
운영 총괄형 앱의 권장 믹스
핵심 가치는 subscription product 아래 base plan으로 묶습니다.프로모션 가격은 offer로 처리하고 subscription product를 추가 생성하지 않습니다.영구 잠금형 기능만 one-time product로 분리합니다.- 카탈로그는 적게 만들고, eligibility와 country 설정으로 운영합니다.
연속 사례: FocusFlow Android 카탈로그
| 상품 | 역할 | 운영 포인트 |
|---|---|---|
| focusflow_premium | 핵심 subscription product | 하나의 상품 아래 monthly/annual base plan 운영 |
| monthly_base | 월 구독 | onboarding 최적화용 기본 진입 |
| annual_base | 연 구독 | LTV 확대, 가격 메시지 분리 |
| winback_offer_30d | 이탈 30일 코호트 offer | 복귀 캠페인 태깅 |
| focus_pack_unlock | one-time product | 구독 가치와 겹치지 않도록 분리 |
카탈로그 설계 체크
- 같은 혜택인데 subscription product를 여러 개로 쪼개지 않습니다.
- 할인은 가능하면 offer로 처리합니다.
- country availability는 launch 우선순위와 같이 설계합니다.
- offer ID와 reporting tag 규칙을 미리 정합니다.
카탈로그 규모 메모
Play Console은 앱당 기본 1,000개 상품 한도를 두고, subscription product마다 동시에 활성인 base
plans와 offers 수를 제한합니다. 운영 관점에서는 한도보다 상품 구조의 단순성이 더 중요합니다.
2025~2026 수익화 신기능
Subscription with Add-Ons (I/O 2025)
여러 구독 상품을 하나의 결제 흐름으로 번들할 수 있습니다. 하나의 가격, 하나의 거래, 하나의 갱신일로 관리됩니다.
- 동일 결제 주기만 묶을 수 있음 (월간+연간 혼합 불가)
- 최대 50개 상품까지 번들 가능
- 자동 갱신 base plan만 지원
- 운영 관점: 카탈로그 구조 설계 시 번들 가능 상품과 독립 상품을 미리 분류해야 합니다
Installment Subscriptions (BL7+)
브라질, 프랑스, 이탈리아, 스페인에서 분할 결제로 구독을 판매할 수 있습니다. 해당 국가에서 연간 구독의 진입 장벽을 낮추는 전략으로 활용 가능합니다.
One-Time Product 다중 구매 옵션 (BL8)
Play Billing Library 8부터 하나의 일회성 상품에 여러 구매 옵션과 offer를 설정할 수 있습니다. 기존에 SKU를 분리하던 패턴을 줄일 수 있어 카탈로그 단순화에 유리합니다.
흔한 안티패턴
- 월 구독과 연 구독을 별도 subscription product로 나누는 경우
- 지역 프로모션마다 새 subscription product를 만드는 경우
- one-time product와 subscription 가치를 중복시켜 CS 문의가 늘어나는 경우
- offer eligibility를 문서화하지 않아 운영팀이 다시 해석해야 하는 경우
실무 팁
운영팀은 상품 개수보다 교체 흐름이 단순한가를 먼저 봐야 합니다. base plan과 offer 안에서 해결할
수 있는 문제를 새 상품 생성으로 풀기 시작하면 리포트와 CS가 빠르게 복잡해집니다.