온라인 수업, 복잡한 청구, 그리고 비례 배분의 함정

발행: (2026년 6월 7일 AM 12:28 GMT+9)
7 분 소요
원문: Dev.to

출처: Dev.to

온라인 스쿨 프로젝트의 데이터베이스와 제품 요구 사항 문서(PRD)를 설계하던 중, 예상치 못한 문제에 부딪혔습니다.
학교에는 여러 구독 플랜이 있었습니다.
간단히 생각해 보겠습니다.

  • Live Class 플랜: ₦50,000 / 학기
  • Video On Demand 플랜: ₦30,000 / 학기
  • Hybrid 플랜 (Live Class + Video On Demand): ₦70,000 / 학기

처음엔 아주 단순해 보였습니다.

  1. 학생이 구독한다.
  2. 시스템이 결제한다.
  3. 끝.

그런데 나는 물었습니다.

학기 중간에 플랜을 바꾸면 어떻게 될까?

예를 들어,

  • 학생이 이미 결제한 플랜: Live Class ₦50,000
  • 두 달 뒤에 Hybrid 플랜으로 업그레이드하고 싶다고 하면

다시 ₦70,000을 청구해야 할까요?
그렇다면 불공평합니다.

다시 ₦20,000 차액만 청구해야 할까요?
하지만 이미 구독 기간 대부분을 사용했을 수도 있습니다.

이 질문은 **프러레이션(Proration)**이라는 개념으로 나아갔습니다.

프러레이션이란?

고객이 실제로 사용한 부분에 대해서만 청구하는 것을 의미합니다.
구독이 언제나 완벽하게 시작하고 끝난다고 가정하지 않고,

  • “현재 구독에 남아 있는 가치는 얼마인가?”
  • “새 구독에 대해 고객이 얼마를 내야 하는가?”

를 답하려는 시도입니다.

예시를 들어 보겠습니다.

  • 학기 길이: 100일
  • 학생이 Live 플랜을 구매: ₦50,000
  • 40일이 지난 뒤 업그레이드

이 경우

  • 사용한 기간: 40일
  • 남은 기간: 60일

남은 가치(잔여 크레딧)는

남은 기간 / 전체 기간 = 60 / 100 = 60%
잔여 크레딧 = 60% × ₦50,000 = ₦30,000

Hybrid 플랜 가격은 ₦70,000이므로

청구 금액 = 새 플랜 가격 − 잔여 크레딧
          = ₦70,000 − ₦30,000
          = ₦40,000

학생은 ₦70,000이 아니라 ₦40,000을 지불하게 됩니다.
이게 더 공정해 보이죠.

다운그레이드는 어떻게 할까?

예를 들어

  • Hybrid 사용자: ₦70,000
  • ₦30,000 플랜으로 다운그레이드

시스템은

  • 돈을 환불해야 할까?
  • 계정 크레딧을 만들어야 할까?
  • 나중에 할인을 적용해야 할까?
  • 갱신 시점까지 무시해야 할까?

와 같은 프러레이션 규칙을 정해야 합니다.
규칙이 없으면 프러레이션 계산은 의미가 없습니다.
비즈니스는 다음과 같은 옵션을 결정해야 합니다.

  • 일 단위
  • 주 단위
  • 월 단위

예시: 일 단위 프러레이션

보통 더 정밀한 청구가 가능합니다.

예시: 즉시 업그레이드

  • 차액을 즉시 청구

예시: 다음 갱신 시 업그레이드

  • 차액을 다음 결제 시 청구

가능한 규칙들

  • 환불
  • 크레딧 적립
  • 갱신 전까지 무시

복잡해지는 비즈니스 규칙

Hybrid 플랜에는

  • 실시간 수업
  • 녹화된 영상
  • 과제

가 포함됩니다.

만약 학생이 **영상 95%**를 이미 시청했다면,

  • 남은 크레딧을 전액 유지해야 할까?

비즈니스 규칙이 금세 복잡해집니다.

처음엔 단순히 “결제 테이블만 있으면 된다”고 생각했지만

결국 필요하게 된 테이블들은 다음과 같습니다.

Subscription Table

idstudent_idplan_idstart_dateend_datestatus

Plan Change Table

idold_plannew_plancredit_appliedamount_chargedchanged_at

청구 결정을 위해서는 과거 기록이 필수입니다.
역사 없이 프러레이션을 계산할 수 없습니다.

간단히 정리하면

잔여 크레딧 = (남은 기간 / 전체 구독 기간) × 현재 플랜 가격
청구 금액   = 새 플랜 가격 − 잔여 크레딧

하지만 실제 비즈니스 규칙은 훨씬 복잡합니다.

깨달은 점

처음엔 구독이 “사용자가 돈을 내면 → 접근 권한 부여”라고 생각했지만,

실제 구독 시스템은 대부분 비즈니스 규칙 + 예외 상황 + 수많은 질문으로 이루어져 있습니다.

프러레이션을 통해 배운 가장 중요한 교훈은

청구 시스템이 어려운 이유는 수학이 아니라 제품에 얽힌 규칙 때문이다.

이제 구독 시스템을 설계할 때마다 항상 묻습니다.

“학기 중간에 마음을 바꾸면 어떻게 할까?”

왜냐하면 결국 누군가는 반드시 바꾸게 되거든요.

여러분은 구독이나 청구 로직을 구현해 본 적이 있나요?
업그레이드와 다운그레이드를 어떻게 처리하시겠어요?

0 조회
Back to Blog

관련 글

더 보기 »

모바일 한여름 열풍

!Cover image for Mobile Midsommer Madnesshttps://media2.dev.to/dynamic/image/width=1000,height=420,fit=cover,gravity=auto,format=auto/https%3A%2F%2Fdev-to-uploa...