구독 업그레이드/다운그레이드, 비례 정산(Proration)은 언제 필요할까

구독자가 월 중간에 요금제를 바꾸면 "남은 기간 요금은 어떻게 처리할까"라는 문제가 생깁니다. 이 계산을 비례 정산(Proration)이라고 부릅니다. 화려하게 구현하면 끝없이 정교해질 수 있지만, 실무에서는 원칙 하나만 정해두면 대부분 해결됩니다.

업그레이드와 다운그레이드는 다르게 처리한다

업그레이드(더 비싼 요금제로 변경)는 즉시 서비스 혜택이 늘어나므로, 남은 기간에 대한 차액을 바로 청구하는 게 자연스럽습니다. 반대로 다운그레이드는 이미 결제한 금액을 환불해줄 필요까지는 없는 경우가 많습니다 — 대신 현재 결제 주기가 끝난 뒤부터 새 요금제를 적용하는 방식이 고객 입장에서도, 운영 입장에서도 가장 단순합니다.

• 업그레이드: 즉시 전환 + 차액 즉시 청구
• 다운그레이드: 현재 주기 종료 시점에 전환 예약 (환불 없음)

이 비대칭 규칙 하나로 "환불 처리"라는 훨씬 복잡한 문제(PG사 환불 API, 부분 환불 가능 여부, 회계 처리)를 아예 피할 수 있습니다.

차액 계산 공식

즉시 전환하는 업그레이드의 경우, 남은 일수 비율로 차액을 계산합니다.

남은일수 = 다음결제일 - 오늘
차액 = (새요금 - 기존요금) × (남은일수 / 결제주기일수)

여기서 실무 함정은 "결제주기일수"를 28~31일로 매달 다르게 계산하면 반올림 오차가 누적된다는 점입니다. 슈퍼빌링은 월 구독을 30일 고정 기준으로 정산해, 소액 오차가 사용자에게 불이익으로 느껴지지 않는 방향(오차는 항상 서비스 제공자가 흡수)으로 반올림합니다.

다운그레이드 예약을 어떻게 저장할까

다운그레이드는 즉시 반영하지 않으므로, pending_plan_id 같은 필드에 "다음 결제일에 적용될 요금제"를 저장해두고, 결제 배치가 도는 시점에 실제 요금제를 교체하면서 청구합니다. 이렇게 하면 별도의 예약 잡(cron)을 새로 만들 필요 없이 기존 정기결제 배치 로직에 자연스럽게 얹을 수 있습니다.

티어 상한을 넘는 다운그레이드는 막아야 한다

활성 구독자 수 기반으로 요금제를 운영한다면, 다운그레이드 시점에 하위 티어의 상한을 넘는지 검증이 필요합니다. 예를 들어 활성 구독자 300명인 테넌트가 200명 상한의 Starter로 다운그레이드를 시도하면, 예약 자체를 거부하거나 최소한 경고를 보여줘야 합니다. 이 검증을 빼먹으면 결제일에 배치가 실패하거나, 더 나쁘게는 상한을 무시한 채로 조용히 넘어가버립니다.

관련해서 요금제를 아예 없애는 대신 판매 중단으로 처리하는 이유는 요금제, 삭제 대신 "판매 중단" 해야 하는 이유에서 다룹니다. 구독결제 연동을 처음부터 정리하고 싶다면 구독결제 연동 완전 가이드를 참고하세요.