구독 상품 유형별로 뭐가 다른가요?

핵심 요약

자동결제는 결제수단을 한 번 등록해 두고 원하는 시점과 금액을 청구하는 결제 구조예요. 하지만 구독 상품은 그 위에서 어떤 서비스를 제공하느냐에 따라 운영 정책이 달라져요.
콘텐츠는 권한 회수, SaaS는 일할 계산, 정기배송은 물류 마감이 핵심 변수예요. 같은 구독처럼 보여도 해지·환불·재시도·상태 전이가 다르게 설계돼요.
결제 상태와 서비스 이용 상태를 분리한 상태 전이도를 미리 확정해야 운영 중 데이터 불일치와 대량 CS를 피할 수 있어요.

어떤 구독 상품을 운영하느냐에 따라 개발에 넘길 명세와 상태 관리 로직이 달라져요. 우리 서비스가 세 유형 중 어디에 가까운지부터 정해요.

무형 콘텐츠의 접근 권한을 제공하는 모델이에요. 영상, 강의, 뉴스레터, 프리미엄 커뮤니티가 여기에 가까워요.

특징: 상품 원가가 낮고 복제 비용이 거의 없어요. 결제 성공 즉시 권한을 열어주는 구조가 많아요.
정할 것: 해지 시점과 권한 종료 시점을 맞춰야 해요. 대부분의 콘텐츠 구독은 중도 해지해도 이번 결제 기간이 끝날 때까지 권한을 유지하는 기간 만료형 해지를 택해요. 이미 제공된 콘텐츠 가치를 회수하기 어렵기 때문이에요.

도구·기능을 빌려주는 모델이에요. B2B 생산성 도구, 협업 툴, 업무 자동화 서비스가 여기에 가까워요.

특징: 사용자 수, 플랜, 사용량에 따라 금액이 달라질 수 있어요. 업그레이드·다운그레이드도 자주 발생해요.
정할 것: 플랜 변경과 사용자 수 변경 시 프로레이션(Proration, 일할 계산)을 할지 정해야 해요. 구독 회차 중간에 사용자를 추가했을 때 남은 기간만큼만 추가 결제할지, 다음 회차 결제일에 합산할지 같은 정책을 수치 예시로 정리해야 해요.

실물 상품을 정해진 주기로 보내는 모델이에요. 식품, 화장품, 생활용품, 굿즈 박스가 여기에 가까워요.

특징: 재고와 배송이 있어요. 결제 성공 여부가 물류 출고와 연결돼요.
정할 것: 결제일과 배송지 수정 마감일을 연결해야 해요. 결제 직전 배송지 변경, 이번 회차 건너뛰기, 출고 후 취소 불가 시점을 정하지 않으면 CS가 크게 늘어나요.

'해지' 버튼 하나를 만드는 것이 아니라, 서비스의 원가 구조와 제공 방식에 따라 환불 시점과 권한 회수 로직을 다르게 설계해야 해요.

비교 항목	콘텐츠 구독	SaaS 구독	정기배송
기본 해지 정책	기간 만료형 해지	즉시 중단 또는 기간 만료형	배송 준비 전 취소 / 배송 후 반품
환불 처리 기준	미사용 또는 시청 전 기준	일할 계산 또는 크레딧	출고 전 취소, 반품 확인 후 환불
핵심 판단 지점	이용권을 '사용'했다고 볼 기준	사용량·시트·플랜 변경 기준	물류센터 출고 지시 시점

콘텐츠: 영상 1회 이상 시청하면 중도 환불 불가처럼, 사용 기준을 명확히 해야 해요. 그렇지 않으면 하루 만에 콘텐츠를 소비하고 환불하는 어뷰징을 막기 어려워요.
SaaS: 플랜 변경, 사용자 추가, 연간 결제 중도 해지처럼 금액 계산 이슈가 많아요. 일할 계산을 할지, 다음 결제일부터 반영할지 정해야 해요.
정기배송: 결제 취소와 물류 취소가 함께 움직여야 해요. 출고 지시가 나간 뒤에는 카드 취소만으로 끝나지 않고 반품·회수·재고 처리까지 이어져요.

자동결제에서는 카드 한도 부족, 유효기간 만료, 분실 재발급 등으로 결제가 실패할 수 있어요. 이때 모든 구독 상품을 똑같이 처리하면 안 돼요.

콘텐츠·SaaS: 결제 실패 즉시 권한을 끊기보다 3~7일 유예 기간(Grace Period) 을 두는 편이 나아요. 이 기간에 결제수단 변경 안내를 보내면 비자발적 이탈을 줄일 수 있어요.
정기배송: 결제가 실패했는데 배송을 보내면 안 돼요. 재시도는 하되, 물류 마감 시간 전까지 결제가 안 되면 이번 회차를 자동 취소하는 로직이 필요해요.

여기서 중요한 건 결제 실패가 곧바로 서비스 종료를 뜻하지 않는다는 점이에요. 결제 상태는 실패일 수 있지만, 서비스 상태는 유예 중일 수 있어요. 이 둘을 분리해야 운영 사고가 줄어들어요.

일시정지와 건너뛰기는 구독 상품 유형에 따라 필요성이 크게 달라져요.

기능	콘텐츠 구독	SaaS 구독	정기배송
일시정지	낮음	중간	중간
이번 회차 건너뛰기	낮음	낮음	높음
데이터 보존	낮음	높음	낮음
배송지 변경	해당 없음	해당 없음	높음

기획자가 서비스 상태를 명확히 정의하지 않으면, 결제는 실패했는데 서비스는 계속 제공되거나, 해지했는데도 돈이 나가는 사고가 발생해요.

"구독 중"이라는 상태 하나로는 부족해요. 결제는 성공했지만 계정은 정지된 상태, 결제는 실패했지만 유예 기간이라 서비스는 제공되는 상태, 해지는 예약했지만 아직 권한은 남은 상태를 구분해야 해요.

상태 전이도(State Machine)를 먼저 그리지 않으면, 결제 실패 시 권한이 바로 회수되거나 환불된 고객이 계속 서비스를 쓰는 등 데이터 무결성이 깨져요.

정기배송에서 가장 큰 사고는 결제일을 고객이 마음대로 바꾸게 방치하는 거예요. 결제일이 바뀌면 물류 출고 스케줄이 꼬여요.

예를 들어 “매월 5일 결제, 7일 도착”처럼 결제일과 배송 주기를 패키지로 묶거나, 변경 시 물류 리드타임을 고려해 최소 3일 전 변경 같은 제약을 둬야 해요.

빌링키 인프라는 payments, 구독 플랜 계약은 commerce 쪽에서 분리해 봐요.