개발 slecs

구독 티어를 Free·Premium·Family로 재편하며 결제와

목차

구독 서비스의 tier를 기존 구조에서 Free/Premium/Family 세 가지로 재편했다. 간단한 변경처럼 보이지만 실제로는 권한 관리 모델부터 결제 로직, 다국어 처리까지 여러 계층을 함께 조정해야 하는 구조적 작업이었다.

왜 tier를 재정렬했나

구독 서비스를 운영하면서 가장 흔한 결정 중 하나가 "tier 경계를 어디에 그을 것인가"다. 우리 팀도 비슷한 고민을 했다. 초반에는 다양한 구독 옵션으로 시작했거나, 아니면 단순한 구조로 출발했을 텐데, 실제 사용 데이터와 비즈니스 목표가 맞아떨어지면서 새 구조가 필요해졌을 것이다.

Free/Premium/Family는 꽤 표준적인 구성이다:
- Free: 진입장벽 없이 핵심 기능 체험
- Premium: 개인 사용자 대상의 강화된 기능
- Family: 가족 공유 중심의 다중 사용자 지원

이 구조로 가면서 얻는 이점은:
- 사용자 세그먼테이션이 명확해짐 (개인 vs 가족 단위)
- 각 tier별 가치 제안(value proposition)이 차별화됨
- 비즈니스 관점에서 모니터링할 메트릭이 명확해짐 (전환율, ARPU 등)

데이터 모델과 결제 로직의 재구성

이 변경의 핵심은 두 개 파일에 집중되어 있다. entitlement.dart는 사용자의 권한 정보를 관리하는 데이터 모델인데, tier 정의가 바뀌면 여기서 가장 먼저 영향을 받는다. 예를 들어:

// 기존 구조에서의 권한 체크 로직이 있었다면
// 새로운 tier 정의에 맞게 매핑 재구성
enum SubscriptionTier {
  free,
  premium,
  family
}

iap_repository.dart는 인앱 결제(In-App Purchase) 처리를 담당한다. 여기서 중요한 건 "구매 후 어떤 권한이 부여되는가"라는 매핑이다. 기존 tier 체계에서 새로운 체계로 옮아갈 때, 특히 주의해야 할 부분들이 있다:

  • 레거시 사용자들의 구독 상태를 어떻게 마이그레이션할 것인가
  • 새 tier로 업그레이드/다운그레이드 시나리오
  • 결제 제공자(App Store, Google Play)와의 상품 ID 매핑

이 부분은 팀 내에서도 많은 논의가 있었을 것 같다. 데이터 마이그레이션 전략, 하위 호환성(backward compatibility) 유지 같은 문제들이다. 특히 이미 결제를 완료한 사용자들의 권한이 손상되지 않도록 하는 것이 중요하다.

다국어 지원의 일관성

app_en.arb, app_ko.arb와 생성된 app_localizations.dart 파일들이 함께 변경된 점도 눈여겨볼 부분이다. 새로운 tier 이름들이 UI 곳곳에서 표시될 텐데, 영문과 한문 모두에서 일관되게 표현되어야 한다.

이건 단순히 텍스트를 번역하는 것 이상의 작업이다:
- 각 언어에서 tier의 의미가 제대로 전달되는가
- UI 레이아웃에서 서로 다른 길이의 텍스트가 깨지지 않는가
- tier 설명(예: "최대 6명 공유")이 각 언어에서 자연스러운가

특히 Family 같은 개념은 문화권마다 그 의미가 약간씩 다를 수 있다. 한국에서 "가족"이 정확히 몇 명까지를 의미하는지도 명확히 해야 한다. 이런 식으로 다국어 파일 변경은 단순한 문자열 추가가 아니라 "우리 사용자들이 어떻게 이해할까"라는 로컬라이제이션 관점이 필요하다.

구조 변경할 때 배운 점

이런 작업을 하면서 팀 내에서 공유하면 좋은 패턴들이 있다. 첫째, 변경의 범위를 명확히 하기다. tier 구조 변경은 데이터 모델에만 그치지 않고, 결제, UI 텍스트, 분석 이벤트, 고객 커뮤니케이션까지 파급된다. 초반에 "여기까지만 건드린다"는 명확한 경계를 그으면 리뷰할 때도, 테스트할 때도 수월하다.

둘째, 마이그레이션 경로 설계가 선행되어야 한다는 점이다. 기존 사용자의 구독 상태를 새 tier로 어떻게 매핑할 것인가. "Premium으로 업그레이드한 사용자는 새 Premium으로, Family는 Family로" 같은 것이 명확해야 버그가 줄어든다. 때로는 과도기(transition period)를 거치면서 구 tier와 신 tier를 동시에 지원하기도 한다.

셋째, 코드리뷰 체크리스트를 구체적으로. 이런 큰 구조 변경은 "데이터 모델 일관성", "결제 흐름 테스트", "다국어 누락 확인", "권한 체크 로직 테스트" 같은 항목들을 명시적으로 리뷰해야 한다. 한두 항목 빠뜨리면 운영 중에 뒤늦게 발견되는 버그가 생길 수 있다.

이 커밋은 비즈니스 요구사항(tier 세분화)과 기술적 구현(데이터 모델, 로직, 다국어)이 어떻게 맞물려가는지 보여주는 좋은 예다. 단순히 "Free/Premium/Family로 바뀌었다"를 넘어, 그 뒤에 있는 설계 결정과 구현 과정을 함께 고려하는 것이 팀 관점에서 중요하다.

🛒 이 글과 어울리는 추천 상품

*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.

이어보기

댓글 0

첫 댓글 달아줘.