핵심 요약
- 플랜 수 · 가격보다 먼저 정할 것은 중도 해지 처리와 업·다운그레이드 반영 시점이에요. 이걸 미루면 DB 스키마를 다시 뜯어요.
- 플랜 수는 타깃 세그먼트와 운영 복잡도를 정하는 결정이에요. 초기에는 2~3개로 시작하는 편이 유리해요.
- 업그레이드는 즉시 반영, 다운그레이드는 다음 결제일 반영이 가장 안전해요. 프로레이션(Proration)은 가능하지만, 선불성 크레딧·포인트로 처리하면 PG 심사 이슈가 생길 수 있어 초기에는 깊게 다루지 않는 편이 나아요.
1플랜 개수는 세그먼트와 운영 복잡도를 정하는 결정이에요
플랜 개수는 선택지를 늘리는 문제가 아니라, 집중할 타깃 고객층과 운영 효율성을 함께 정하는 의사결정이에요.
2개 플랜 (Basic vs Pro)
초기 스타트업이나 기능이 명확한 단일 도구 서비스에 적합해요. 관리가 쉽고 고객 고민 시간을 줄여요. "무료로 써보거나, 제대로 쓰거나"의 이분법을 유도해 전환 속도를 높여요.
3개 플랜 (Basic vs Standard vs Premium)
가장 보편적인 구조예요. 가장 비싼 Premium이 앵커(Anchor) 역할을 하고, 대부분의 고객이 Standard를 선택하도록 유도해요. 넷플릭스와 대부분의 B2B SaaS가 이 구조를 써요.
무료 플랜(Freemium) 도입 여부
무료 플랜은 가입자는 빠르게 늘리지만 서버 비용과 CS 인력이 기하급수적으로 늘어나요. 네트워크 효과가 중요한 경우(슬랙·노션)가 아니라면 무료 플랜 대신 "결제 수단 등록 후 기간 한정 무료 체험(Free Trial)"을 우선 검토해요.
2연간 결제 중도 해지 처리가 먼저예요
연간 결제 할인율을 정하기 전에 중도 해지 시 잔여 금액 계산 방식을 확정해야 DB 구조 재작업과 출시 지연을 막아요.
고객이 연간 결제 후 6개월 뒤에 해지를 요청했을 때 처리 방식은 크게 셋 중 하나예요.
- 방법 A. 기간 만료 해지, 환불 없음: 중도 환불은 하지 않고, 이미 결제한 연간 회차 끝까지 계속 이용하게 해요. 해지 요청은 다음 회차 결제를 막는 예약 처리에 가까워요. 운영은 가장 단순하지만, 고객에게 “해지해도 남은 기간 환불은 없어요”는 점을 명확히 고지해야 해요.
- 방법 B. 사용 기간 차감 후 부분 취소: 사용한 달만큼 월 결제 정가 기준으로 차감하고 남은 금액을 되돌려줘요. 고객 친화적이지만 원 결제 금액, 할인 전 월 정가, 사용 개월 수, 부분 취소 가능 기간을 모두 계산해야 해요.
- 방법 C. 중도 취소 위약금 차감 후 환불: 렌탈형 구독처럼 약정 기간·설치비·회수 비용이 있는 상품은 중도 취소 위약금이나 회수 수수료를 차감할 수 있어요. 사용 기간, 남은 약정, 상품 회수 상태에 따라 위약금을 차등 적용하면 정책과 DB가 더 복잡해져요.
방법 B 예시: 연 12만 원(월 1만 원꼴) 결제 고객이 3개월 쓰고 해지 요청 시, 월 정가(1.5만 원) × 3개월 = 4.5만 원을 제외한 7.5만 원을 카드 부분 취소 처리해요.
방법 C 예시: 정수기·가전 렌탈처럼 36개월 약정이 있는 상품에서 12개월 만에 해지하면, 남은 약정 기간이나 회수 비용 기준으로 위약금을 차감한 뒤 환불해요. 이 경우 “몇 개월차 해지인지”, “제품 회수가 완료됐는지”, “설치비 면제분을 돌려받을지” 같은 조건이 모두 정책값이 돼요.
주의: 매월 자동결제라면 보통 해당 월의 결제 건을 취소하면 되므로 비교적 단순해요. 복잡해지는 건 연간 결제나 렌탈 선결제처럼 첫 결제 건 하나에 긴 이용 기간이 묶여 있는 경우예요. 이때 중도 해지로 일부 금액을 돌려줘야 하면 카드 부분 취소 가능 기간(보통 6개월~1년), 휴대폰 결제 익월 취소 제한, 계좌 환불 프로세스를 따로 고려해야 해요.
이 로직이 확정돼야 개발팀이 결제 테이블에 원 결제 금액, 할인 전 정가, 위약금·수수료 정책값을 별도로 저장할지 결정할 수 있어요. 정책 없이 시작하면 나중에 취소 로직을 넣을 때 스키마 전체를 수정해야 해요.
3플랜 변경 반영 시점: 업그레이드는 즉시, 다운그레이드는 다음 결제일
반영 시점을 먼저 못 박아야 개발 설계가 꼬이지 않아요. 업그레이드와 다운그레이드는 서로 다른 우선순위를 가져요.
업그레이드: 즉시 반영 (Immediate Change)
고객이 더 비싼 플랜으로 상향하는 경우예요. 고민 없이 즉시 반영을 택해요.
- 이유: 상위 기능을 쓰기 위해 결제 버튼을 누른 고객에게 "다음 결제일까지 기다리라"고 하는 것은 매출 기회를 스스로 포기하는 행위예요.
- 처리: 결제 시점에 차액을 결제받고 즉시 기능을 열어요.
다운그레이드: 다음 결제일 반영 (Delayed Change)
고객이 더 저렴한 플랜으로 하향하는 경우예요. 초기 서비스라면 다음 결제일 반영이 정답이에요.
- 이유: 중도 다운그레이드를 즉시 반영하면 이미 낸 돈 중 남은 기간만큼의 차액을 돌려줘야 해요. 카드는 부분 취소 기한(보통 매입 후 1년 이내, 카드사별 상이)이 있고, 가상계좌는 직접 계좌 송금 절차가 필요해 운영 부하가 급증해요.
- 처리: 이번 구독 회차까지는 현재 플랜을 쓰게 하고, 다음 회차 결제일부터 변경된 저렴한 가격으로 결제되도록 예약 상태로 둬요. 시스템적으로 가장 깔끔하고 CS 발생 소지가 적어요.
4프로레이션(Proration)은 예외 정책으로만 다뤄요
프로레이션은 구독 회차 중간에 플랜이나 사용자 수가 바뀌었을 때, 남은 기간만큼 차액을 계산하는 방식이에요. 예를 들어 30,000원 플랜을 10일 쓰고 남은 20일 시점에 60,000원 플랜으로 업그레이드하면, 남은 기간 기준 차액만 추가로 청구할 수 있어요.
다만 초기 서비스라면 프로레이션을 너무 정교하게 설계하지 않는 편이 나아요. 다운그레이드 잔액을 내부 크레딧이나 포인트처럼 쌓아두는 방식은 선불성 포인트 업종으로 해석될 수 있어 PG 심사에서 반려될 수 있어요. 카드 부분 취소도 카드사 정책과 결제 후 경과 시간에 따라 실패할 수 있어요.
그래서 기본값은 단순하게 잡아요.
- 업그레이드: 차액을 즉시 결제받고 바로 반영
- 다운그레이드: 이번 구독 회차까지 기존 플랜 유지, 다음 회차 결제일부터 반영
- 사용자 수 추가: 필요하면 다음 회차 금액에 합산하거나 별도 추가 결제로 처리
프로레이션은 “꼭 필요한 고급 정책”으로 남겨두고, 실제 도입 전에는 PG 심사·약관·회계 처리까지 함께 확인하는 편이 안전해요.
5예외 케이스 정책
회차 기준일 변경·결제 실패·중복 변경 시나리오를 미리 확정해야 데이터 구조 설계 단계에서 재작업이 없어요.
① 월간에서 연간으로 바꾸는 경우
월간 베이직 고객이 연간 프로로 바꾸면 결제 기준일이 꼬이기 쉬워요. 예를 들어 매월 10일에 결제하던 고객이 23일에 연간 플랜으로 바꾸면, “이번 달 남은 17일은 어떻게 계산할지”, “연간 결제 시작일은 10일인지 23일인지”를 정해야 해요.
초기에는 단순하게 가는 편이 안전해요. 바꾸는 날 기존 월간 플랜을 끝내고, 그날부터 연간 플랜을 새로 시작한다고 정하면 돼요. 그러면 결제일도 새 플랜 시작일 기준으로 다시 잡히고, DB에서도 이전 회차와 새 회차를 분리해서 관리하기 쉬워요.
② 결제 실패 시 먼저 재시도 정책을 태운이에요
업그레이드 차액 결제나 다음 회차 결제가 실패했다고 바로 결제수단 재등록부터 요구하면 고객 이탈이 커질 수 있어요. 카드 한도 부족, 일시적인 승인 실패, 카드사 장애처럼 같은 빌링키로 다시 시도하면 성공하는 경우도 있기 때문이에요.
그래서 기본 순서는 재시도가 먼저예요.
- 1순위: 재시도 정책으로 기존 빌링키 결제 재시도
- 2순위: 실패가 반복되면 결제수단 재등록 유도 → 새 빌링키 발급 → 구독 유지
- 보조 수단: 링크페이 등으로 해당 실패 건만 단건 결제 유도
결제수단 재등록은 카드 만료, 분실 재발급, 반복 실패처럼 기존 빌링키로 더 이상 결제가 어렵다고 판단될 때 유도해요. 재등록이 성공하면 새 빌링키가 발급되고 이후 회차 결제가 이어지므로, 구독 상태와 다음 달 결제 지표를 유지하는 데 유리해요.
링크페이로 해당 건만 결제받는 것도 돈을 회수하는 방법은 돼요. 하지만 구독에 저장된 결제수단이 바뀌는 것은 아니므로, 다음 회차에 같은 문제가 다시 생길 수 있어요. 그래서 링크페이는 보조 수단으로 두고, 기본 흐름은 재시도 → 결제수단 재등록 순서로 잡는 편이 나아요.
③ 중복 변경 제약
오늘 업그레이드하고 1시간 뒤에 다시 다운그레이드하는 '변심 고객'은 반드시 존재해요. 일 단위 프로레이션이 정교하게 구현되지 않은 상태에서 무제한 변경을 허용하면 DB 값이 꼬여요.
- "플랜 변경은 구독 회차당 1회만 가능" 또는 "업그레이드 후 24시간 이내에는 다운그레이드 불가" 같은 최소한의 안전장치를 기획 단계에서 확정해요.
실제로 붙이려면
플랜 금액 청구는 payments, 결제 정책 설계는 commerce 쪽에서 함께 확인해요.
- 즉시 청구 — /billing/charge-request
- 구독 결제 정책 — /subscription/plan/billing-policy