B2B SaaS 가격 변경·기존 고객 grandfathering·proration 정책 비교 2026, 플랜 변경 시 적용 시점을 고르는 기준

B2B SaaS의 가격을 올리거나 내릴 때 가장 어려운 부분은 새 가격 자체가 아닙니다. 새 고객에게만 새 가격을 보여줄지, 기존 고객도 다음 갱신부터 바꿀지, 중간에 플랜을 바꾸는 고객에게 남은 기간을 어떻게 계산할지를 함께 정해야 합니다.

가격표에 새 금액을 등록하는 일과 기존 구독에 새 금액을 적용하는 일도 분리해야 합니다. 이 글은 B2B SaaS 다중 통화 가격표시·청구·정산 비교에서 다룬 환율·정산 통화가 아니라, 가격 버전·고객 cohort·적용 시점·proration 결과를 운영 정책으로 연결하는 방법에 초점을 둡니다.

Stripe·Chargebee·Paddle·Recurly의 공식 문서를 바탕으로 비교하지만, 계정·계약·gateway·플랜 구조에 따라 지원 범위가 달라질 수 있습니다. 가격 변경 고지나 계약 해석에 관한 법률·세무 자문이 아니며, 실제 변경 전에는 사용하는 provider의 최신 문서와 계정 설정을 다시 확인해야 합니다.

가격 변경은 네 가지 사건으로 나눠 기록합니다

가격을 바꿨다라는 한 문장만 저장하면 나중에 어느 고객이 왜 다른 금액을 냈는지 설명하기 어렵습니다. 최소한 다음 사건을 분리하십시오.

이 구조를 쓰면 같은 새 가격이라도 신규 고객은 즉시 적용하고, 기존 고객은 다음 갱신에 적용하는 정책을 표현할 수 있습니다. 반대로 기존 고객에게 계속 예전 가격을 유지한다면 가격표가 바뀌었는지와 구독의 실제 price reference가 무엇인지 분리해서 확인할 수 있습니다.

grandfathering은 가격 유지와 기능 유지가 다릅니다

grandfathering이라는 단어는 문서마다 의미가 다를 수 있습니다. 이 글에서 말하는 가격 grandfathering은 특정 고객 cohort가 새 가격이 아닌 기존 가격을 일정 조건까지 계속 사용하는 정책입니다. 기능 접근권한을 예전 플랜 수준으로 유지하는 entitlement grandfathering과는 별개입니다.

예를 들어 다음은 서로 다른 정책입니다.

가격 grandfathering과 entitlement를 하나의 plan 문자열로 처리하면 예외가 생겼을 때 원인을 추적하기 어렵습니다. 가격의 적용 규칙과 기능 접근 규칙을 별도 필드로 관리하고, 고객에게 보이는 가격·invoice·entitlement 결과를 각각 검증하십시오.

적용 시점은 즉시·다음 invoice·다음 renewal로 비교합니다

가격 변경은 언제 적용하느냐에 따라 고객 경험과 회계 증거가 달라집니다.

공개 가격표를 먼저 바꿨다고 해서 모든 기존 구독의 청구 가격이 자동으로 바뀐다고 가정하면 안 됩니다. 실제 적용은 provider의 subscription item, price reference, schedule 또는 변경 API에 의해 결정됩니다. 변경 전에는 고객별 preview를 만들고, 변경 후에는 실제 invoice와 subscription 상태가 정책표와 맞는지 확인해야 합니다.

provider별 가격 변경과 proration 접근 방식

아래 표는 provider의 기능을 동일한 제품처럼 평가하는 표가 아닙니다. 같은 즉시 변경이라는 표현도 credit 생성, 추가 청구, 다음 청구서 반영 방식이 달라질 수 있으므로 실제 API 응답과 공식 문서의 조건을 함께 확인해야 합니다.

Stripe의 가격 변경 문서는 새 Price를 만들고 기존 구독에 어떤 price를 연결할지 확인하는 출발점입니다. proration 문서와 가격 관리 문서에서 preview·credit·schedule 조건을 함께 확인하십시오.

Chargebee는 구독 변경, proration, price override를 함께 봐야 합니다. Grandfathering Entitlements는 가격 grandfathering이 아니라 기능 접근권한의 개념일 수 있으므로 두 용어를 분리해 읽어야 합니다.

Paddle의 subscription proration, 상품·가격 교체, subscription update preview는 즉시·다음 청구 기간·청구하지 않음의 결과를 비교할 때 유용합니다. Recurly는 subscription 변경, plans, ramp pricing을 기준으로 변경 시점과 가격 구조를 다시 확인하십시오.

proration은 가격 변경 정책의 일부이지 결과 숫자 하나가 아닙니다

중간에 플랜을 바꾸면 남은 기간의 기존 가격을 credit으로 잡고 새 가격을 charge하는 식의 계산이 발생할 수 있습니다. 하지만 provider마다 계산 단위, 적용 시점, credit의 사용처, 즉시 결제 여부가 다르므로 내부에서 임의로 같은 공식으로 재계산하지 않는 편이 안전합니다.

예를 들어 한 고객이 현재 청구 기간의 중간에 기존 플랜에서 새 플랜으로 이동한다고 해보겠습니다. 운영자가 확인할 순서는 다음과 같습니다.

1. 변경 전 subscription item과 old_price_id를 조회합니다.
2. 변경 후 price와 new_price_id, 고객 cohort 규칙을 확정합니다.
3. 즉시 변경인지 다음 invoice인지 다음 renewal인지 effective_at과 함께 기록합니다.
4. provider preview에서 credit·charge·discount·tax line을 확인합니다.
5. 실제 변경 뒤 생성된 invoice·credit·payment 상태를 preview와 비교합니다.
6. 차이가 있으면 자동으로 재시도하지 말고 변경 ID와 원문 응답을 보존한 채 예외 큐로 보냅니다.

가격표가 예전 금액에서 새 금액으로 바뀌었다는 사실만으로 기존 고객에게 환불하거나 추가 청구할 근거가 생기는 것은 아닙니다. credit은 자동 현금 환불과 같은 의미가 아닐 수 있고, 양수 조정도 즉시 결제 성공을 보장하지 않을 수 있습니다. 실제 refund·credit note 연결은 B2B SaaS refund·credit note 추적 체크리스트에서 다룬 사후 대사 범위와 연결하되, 이 글에서는 가격 변경 시점과 preview 검증에 집중합니다.

가격 변경 정책 매트릭스를 먼저 만듭니다

provider API를 호출하기 전에 내부 정책을 표로 고정하면 운영팀·개발팀·고객지원팀의 해석 차이를 줄일 수 있습니다.

여기서 계약 기간이나 공지의 법적 효력을 이 글에서 판단하지 마십시오. 운영 시스템에는 보스가 승인한 내부 정책과 실제 계약·고객 안내 기록의 식별자만 연결하고, 기술 문서가 법률 판단을 대신한다고 표현하지 않는 것이 안전합니다.

가격 변경에서 보존할 증거 필드

가격 변경은 나중에 “왜 이 고객은 다른 금액을 냈는가”를 재현할 수 있어야 합니다. 최소 필드는 다음처럼 나눌 수 있습니다.

change_id
old_price_id
new_price_id
customer_id
subscription_id
cohort_rule
grandfathering_status
effective_at
proration_mode
preview_id
preview_line_items
invoice_id
credit_id
payment_id
change_reason
operator_or_job_id
source_document_version

preview_line_items는 계산 결과만 저장하지 말고 provider가 반환한 원문을 추적할 수 있는 보관 위치와 연결하십시오. 내부 보고용 기준 통화 환산값을 추가하더라도 원 invoice·credit의 통화와 금액을 덮어쓰지 않아야 합니다. 다중 통화와 settlement의 상세 필드는 가격표시·청구·정산 비교 글의 범위로 넘깁니다.

도입 전 테스트 시나리오

다음 테스트는 가격 변경 기능을 켜기 전에 sandbox 또는 provider preview에서 확인할 수 있습니다.

• 신규 고객이 새 price ID를 받고 기존 고객은 예전 price ID를 유지하는가
• grandfathering cohort가 해지 후 재가입하거나 플랜을 바꿀 때 어떤 가격을 받는가
• 즉시 upgrade에서 기존 기간 credit과 새 가격 charge가 예상 line으로 나타나는가
• downgrade를 다음 renewal에 예약했을 때 현재 기간의 기능과 가격이 섞이지 않는가
• 할인·무료 기간·seat 수·usage line이 proration preview에 반영되는가
• 변경 작업이 두 번 실행되어 중복 credit·중복 invoice가 생기지 않는가
• preview와 실제 invoice의 금액·통화·line item·status 차이가 기록되는가
• 결제 실패 또는 past_due 상태에서 가격 변경을 자동 재시도하지 않는가
• rollback 시 기존 subscription, price version, entitlement 결과가 각각 복구되는가

좌석 수나 사용량을 가격 변경과 함께 바꾸는 경우에는 가격 변경 자체와 usage 과금의 대사를 섞지 마십시오. B2B SaaS usage-based billing 추적 감사 체크리스트를 별도 참고하고, 하나의 변경 ID 아래에 어떤 이벤트가 포함됐는지 명시하는 편이 좋습니다.

provider를 고르는 질문

어느 provider가 무조건 더 낫다고 결론내리기보다 다음 질문에 답하는 방식으로 비교하십시오.

1. 새 고객 가격과 기존 고객 가격을 price ID 또는 override로 분리할 수 있는가?
2. 다음 invoice·next renewal·즉시 변경을 명시적으로 예약할 수 있는가?
3. 변경 전 preview가 실제 invoice line item과 같은 기준을 사용하는가?
4. proration을 credit·charge·none 중 어떤 방식으로 제어할 수 있는가?
5. credit이 자동 refund인지 invoice 잔액인지 문서와 API 응답으로 확인 가능한가?
6. 기존 가격을 유지하는 고객과 새 가격을 받은 고객을 리포트에서 구분할 수 있는가?
7. 변경 재시도와 중복 실행을 막을 idempotency·change ID가 있는가?
8. 가격 변경 후 customer support가 고객별 effective date와 예상 invoice를 조회할 수 있는가?

구독 플랫폼의 전체 기능 비교가 필요하면 B2B SaaS 구독 관리 플랫폼 비교를 먼저 보고, 가격 변경 정책은 이 글의 cohort·시점·proration 매트릭스로 좁혀서 검토하십시오. 갱신 예외와 고객별 승인 흐름은 B2B SaaS renewal exception follow-up 체크리스트와 연결할 수 있지만, 가격 변경 API의 동작과 동일한 문제로 취급하면 안 됩니다.

WordPress 공개 전 체크리스트

• [ ] 신규 고객 가격, 기존 고객 가격, 예외 cohort를 분리했습니다.
• [ ] 가격 grandfathering과 entitlement grandfathering을 구분했습니다.
• [ ] 즉시·다음 invoice·다음 renewal의 적용 시점을 표로 고정했습니다.
• [ ] provider별 proration·credit·charge·preview 조건을 공식 문서에서 확인했습니다.
• [ ] old_price_id, new_price_id, cohort_rule, effective_at, proration_mode를 저장합니다.
• [ ] preview와 실제 invoice·credit 결과를 같은 change_id로 비교합니다.
• [ ] credit을 자동 현금 환불로 단정하지 않았습니다.
• [ ] 통화·환율·checkout·billing portal·일반 refund 대사는 관련 글로 분리했습니다.
• [ ] 가격 변경 안내와 계약·법률 판단을 직접 지시하는 표현을 넣지 않았습니다.
• [ ] 모든 공식 출처와 내부링크가 실제 HTML <a>로 변환되는지 확인합니다.

마무리

B2B SaaS 가격 변경의 핵심은 새 금액을 등록하는 데 있지 않습니다. 누가, 언제부터, 어떤 price version을 받고, 남은 기간의 credit·charge가 어떤 invoice로 남는지를 정책과 증거로 연결하는 데 있습니다.

신규 고객만 새 가격을 받게 할지, 기존 고객에게 일정 기간 가격을 유지할지, 다음 갱신부터 전환할지는 사업 정책입니다. Stripe·Chargebee·Paddle·Recurly는 그 정책을 구현하는 옵션과 결과 표현이 서로 다르므로, provider의 이름보다 cohort → effective_at → proration → invoice 흐름을 먼저 비교하십시오.

최종 확인일: 2026-08-10. provider의 가격 변경·proration·credit·preview 지원 범위는 계정·국가·gateway·문서 개정에 따라 달라질 수 있으므로 실제 운영 전에 최신 공식 문서와 테스트 결과를 다시 확인하세요.

공식 출처

• Stripe change a subscription
• Stripe prorations
• Stripe manage prices
• Chargebee subscriptions
• Chargebee proration
• Chargebee price override
• Chargebee grandfathering entitlements
• Paddle subscription proration
• Paddle replace products and prices
• Paddle preview subscription update
• Recurly change subscription
• Recurly plans
• Recurly ramp pricing