빌링 vs 구독

핵심 요약

빌링(자동결제)은 기술 원자예요. 고객 카드를 등록해 빌링키를 만들고, 이후 서버가 그 키로 청구할 수 있는 권한만 제공해요.
구독관리는 플랜 단위 라이프사이클이에요. 계약 · 자동 과금 · 회차 조정 · 일시정지 · 해지까지 전체를 상태 머신으로 관리해요.
둘 다 내부적으로는 빌링키를 써요. 차이는 "상태 관리를 우리 서버가 짜느냐, PG의 구독 API가 대신 해주느냐"예요.
빌링 직접 구현이 맞는 경우: 단일 플랜, 매달 같은 금액, 상태 복잡도 낮음. 구독 API가 맞는 경우: 복수 플랜, 할인·회차 조정, 일시정지·업다운그레이드, 환불 정책 복잡.

이런 상황이라면

SaaS 프로덕트를 만드는 3인 팀이 있어요. 월 구독이 핵심 비즈니스 모델이에요. 처음에는 "매달 1일에 카드에서 9,900원 빼면 되는 거 아닌가?"로 출발했어요. 개발자분이 "빌링키 연동으로 충분한가요, 아니면 구독 API를 써야 하나요?"라고 물어요.
찾아보니 빌링키는 결제 기능이고, 구독관리는 그 위에 플랜·해지·재시도·일시정지 같은 라이프사이클을 얹은 개념이라고 해요. 우리 팀은 지금 플랜이 하나고 가격도 하나인데, 앞으로 연간 할인·무료체험·플랜 업그레이드가 추가될 거예요. 지금부터 구독 API로 가야 할지, 빌링키로 시작해서 나중에 바꿀지 판단이 안 돼요.

이 글은 빌링과 구독관리가 개념적으로 어떻게 분리되는지, 어느 단계에서 뭘 선택해야 하는지 실무 기준으로 정리해요.

1빌링은 "카드 다시 쓸 수 있는 권한", 구독은 "플랜 상태 기계"

빌링키 — 기술 원자

고객이 첫 결제에서 카드를 등록하면 빌링키(billing_key) 라는 재사용 식별자가 발급돼요. 이 키로 서버가 원하는 시점에 결제를 요청할 수 있어요.

빌링키 자체는 매우 단순해요. 다음 3가지만 해요.

발급: 고객 동의 + 카드 등록
저장: 가맹점 서버가 빌링키와 고객·결제수단 메타데이터를 저장
청구: 서버가 빌링키로 금액을 지정해 과금 요청

빌링키만 있으면 "고객이 카드를 다시 입력하지 않아도 과금할 수 있어요"까지 돼요. 그 이상은 없어요.

구독관리 — 플랜 상태 기계

구독관리는 빌링키 위에 플랜·라이프사이클·정책을 얹은 개념이에요. 플랜을 정의하고, 계약을 생성하고, 매 회차 청구를 실행하고, 실패 시 재시도하고, 고객이 일시정지·해지·업그레이드를 요청하면 상태를 바꿔요.

구독 API가 담당하는 것:

계약(Contract): 어떤 고객이 어떤 플랜을 언제 시작했는가
회차(Bill): 매달/매주 청구 실행, 회차 금액 조정(할인·추가 요금)
상태 전이: 신규 → 활성 → 일시정지 → 재개 → 해지 → 만료
정책: 재시도 간격, 유예 기간, 일할 계산, 무료체험 자동전환
요청 처리: 고객이 해지·업그레이드 요청 시 승인·반려 흐름

이 전부를 우리가 서버에 직접 구현하느냐, PG의 구독 API에 위임하느냐가 빌링과 구독관리의 핵심 차예요.

2같은 빌링키로 뭐가 달라지나 — 비교표

항목	빌링 API 직접	구독 API
빌링키 발급	✅	✅ (내부적으로 동일)
과금 실행	❌ 서버가 직접 cron·스케줄러로	✅ PG가 주기에 맞춰 자동 실행
결제 실패 재시도	❌ 직접 구현	✅ 정책 기반 자동 재시도
플랜 정의	❌ 자체 DB로 관리	✅ PG 관리
회차 금액 조정 (할인·추가 요금)	❌ 매 회차 금액 계산 로직 직접	✅ API로 조정
일시정지·재개	❌ 자체 상태 관리	✅ API 제공
업그레이드·다운그레이드	❌ 일할 계산·정산 직접	✅ 플랜 변경 API
해지·만료	❌ 자체 상태 관리 + 취소 API 조합	✅ 종료 API
웹훅 이벤트	결제 성공/실패만	계약/회차/상태 전이 전부
개발 공수	많음 (상태 기계 전부 자체)	적음 (API 호출 + 웹훅 수신)
유연성	무제한 (원하는 대로 커스터마이징)	PG가 지원하는 범위 내

핵심은 "상태 관리를 누가 책임지느냐"예요. 빌링은 우리가, 구독 API는 PG가 해요.

3어느 쪽을 선택할까 — 판단 기준

빌링 직접 구현이 맞는 경우

단일 플랜, 매달 같은 금액. 월 9,900원 하나만 있어요.
무료체험·할인·플랜 변경이 없거나 드물이에요.
자체 복잡한 요금제 로직이 이미 있어요. (사용량 기반, 크레딧, 혼합 과금 등)
PG 의존도를 낮추고 싶이에요. 여러 PG를 동시에 쓰거나 향후 교체 가능성이 커요.

빌링 직접 구현의 장점은 자유도예요. 우리 서비스 로직에 맞춰 원하는 대로 짤 수 있어요. 단점은 상태 관리 로직을 전부 자체 구현해야 하고, 시간이 지나면서 엣지 케이스가 누적돼요.

구독 API가 맞는 경우

복수 플랜. 월/연 플랜, 플랜 A/B/C처럼 여러 옵션이 있어요.
플랜 변경이 잦이에요. 업그레이드·다운그레이드가 실제로 일어나요.
무료체험·쿠폰·할인 적용이 필요.
회차별 금액이 달라져요. 설치비 선청구, 약정 할인, 일할 계산 환불.
고객이 일시정지를 요청해요. (여행·휴직 등)
환불 규정이 복잡. 중도 해지 시 일할 계산·잔여 금액 처리.
구독 전담 팀·운영 도구가 없어요. PG의 관리자 콘솔에 위임하고 싶어요.

구독 API의 핵심 이득은 상태 머신과 재시도·유예 정책을 이미 검증된 로직으로 위임한다는 거예요. 자체 구현으로 가면 이 부분 버그가 지속적으로 발생해요.

중간 — 빌링으로 시작했다가 바꾸는 케이스

MVP는 빌링으로 시작하고, 플랜이 복잡해지면 구독 API로 이관하는 패턴이 가장 흔해요. 이 경로를 의도하는 경우 유의점:

빌링키 자체는 그대로 쓸 수 있다 (발급 주체가 같으면).
그러나 자체 DB의 계약·회차 구조가 구독 API 스키마와 다르면 이관 비용이 크예요.
미리 "구독 API 스키마와 유사한 구조"로 자체 DB를 짜두면 이관이 훨씬 쉬워요.

4자주 혼동하는 지점

"빌링 = 구독" 이 아니에요

빌링은 결제 기능이고 구독은 비즈니스 모델 + 상태 관리예요. 구독 모델이라도 빌링 없이 매달 결제창을 띄워 고객이 직접 결제하게 할 수도 있다(전환율이 나빠서 잘 안 쓸 뿐). 반대로 빌링만으로 구독 모델을 구현할 수도 있다(상태 관리를 직접 짜면 됨).

"구독 API = 고정 요금제" 가 아니에요

많은 구독 API는 회차별 금액 조정을 지원해요. 사용량 기반, 할인, 추가 요금을 회차 단위로 반영할 수 있어요. "구독 API는 고정 요금에만 맞다"는 오해가 있지만 실제로는 훨씬 유연해요.

구독 API를 써도 빌링키 관리는 필요해요

구독 API를 써도 고객 카드 만료·재등록·이관은 여전히 발생해요. 빌링키 이관 API, 대체 결제수단 등록 UI, 만료 알림 등은 구독 API 사용 여부와 무관하게 필요해요.

"해지 = 환불" 이 아니에요

구독 해지는 계약을 종료하는 것이고, 해지 시 남은 기간의 환불 여부는 별도 정책이에요. 구독 API는 해지 상태 관리는 해주지만, "일할 계산 환불이 맞나"는 서비스 정책이에요. 이 구분을 초기에 명확히 해야 고객 문의가 줄어들어요.

5우리 팀 판단 플로우

아래 3단계로 좁힐 수 있어요.

① 지금 시점에 플랜이 몇 개인가요

1개 (고정 금액) → 빌링으로 시작 가능.
2개 이상 또는 가격 변동 → 구독 API가 유리.

② 6개월 안에 아래 중 무엇이 추가될 예정인가요

무료체험 / 쿠폰 / 연간 할인 / 플랜 변경 / 일시정지 / 일할 계산 환불

3개 이상 해당되면 처음부터 구독 API를 쓰는 편이 총비용이 낮아요. 빌링으로 시작했다가 다시 짜는 비용이 더 커요.

③ 자체 요금제 로직이 이미 복잡한가

그렇이에요 (사용량 기반, 혼합 과금) → 빌링 직접 + 자체 요금제 엔진.
아니에요 → 구독 API 위임.

실제로 붙이려면

여기서 정한 결정을 코드와 구독 운영으로 옮길 때 다음 문서가 시작점이에요.

빌링키 발급 — /billing/key-issue
구독 플랜 계약 — /subscription/plan/contract

다음 단계

구독을 기획 중이라면 상태·정책 설계를 구독 시리즈에서 다뤄요.

바로 참고할 문서

도입 문의: 도입 문의