카페24 정기구독몰, 기본 기능으로 어디까지 가능할까요?

카페24에서 정기구독 쇼핑몰을 만들려고 할 때 가장 먼저 확인해야 할 것은 상품에 ‘구독’이라는 이름을 붙이는 것이 아니라 실제로 반복 결제와 구독 상태를 관리할 수 있는지입니다.

일반적인 카페24 주문은 고객이 상품을 선택하고 한 번 결제하는 구조입니다.

정기구독은 여기에 추가로 다음과 같은 정보가 필요합니다.

따라서 같은 상품을 같은 주기로 반복 결제하는 단순한 정기배송과 회차·해지·건너뛰기·구독 혜택까지 관리하는 정기구독 서비스는 개발 범위가 다릅니다.

카페24의 일반 주문 기능은 기본적으로 1회 구매를 처리하는 흐름입니다.

고객이 상품을 장바구니에 담고 결제하면 주문이 생성되고 배송과 취소 등의 과정이 이어집니다.

반면 정기구독은 한 번의 주문으로 끝나지 않습니다.

예를 들어 고객이 1월에 구독을 시작하면,

1월 결제 → 1회차 배송

2월 자동 결제 → 2회차 배송

3월 자동 결제 → 3회차 배송

처럼 새로운 결제와 주문이 계속 발생해야 합니다.

또한 고객이 중간에 구독을 변경하거나 해지할 수도 있습니다.

따라서 일반 주문 기능만으로는 회원별 구독 상태와 다음 결제일, 회차, 해지 상태를 하나의 구독 정보로 관리하기 어렵습니다.

아닙니다.

상품 상세페이지에

월 1회 정기구독 상품

이라고 표시하는 것은 화면의 문구를 변경하는 것입니다.

실제 정기구독이 되려면 고객의 결제가 정해진 주기에 반복되고, 그 결과가 주문으로 이어져야 합니다.

예를 들어 화면에는 다음 결제일이 10월 10일이라고 표시되어 있는데 실제 카드 결제가 발생하지 않는다면 고객 입장에서는 정기구독 서비스가 정상적으로 작동하지 않는 것입니다.

반대로 고객이 이번 달 구독을 건너뛰었다고 표시했는데 실제 결제가 진행된다면 CS 문제가 발생합니다.

따라서 정기구독은 화면이 아니라 결제·주문·회원 상태가 함께 연결되어야 합니다.

두 기능은 비슷해 보이지만 실제 운영 범위는 다를 수 있습니다.

정기결제는 일정한 주기로 고객에게 결제하는 기능에 가깝습니다.

예를 들어,

매월 10일 29,000원 자동 결제

와 같은 구조입니다.

반면 정기구독은 결제뿐만 아니라 구독 상태까지 관리하는 개념입니다.

예를 들어,

구독 시작 → 결제 → 배송 → 다음 회차 안내 → 건너뛰기 → 재결제 → 해지

와 같은 흐름을 관리해야 합니다.

따라서 단순히 같은 상품을 같은 금액으로 반복 결제하는 서비스라면 정기결제·정기배송 앱과 PG의 정기결제 기능으로 해결할 수 있는 경우가 있습니다.

하지만 회차마다 상품이나 금액이 달라지거나, 건너뛰기와 구독 혜택까지 필요하다면 별도의 구독 관리 구조가 필요할 수 있습니다.

조건이 단순하다면 가능합니다.

예를 들어 다음과 같은 구조입니다.

이런 경우에는 카페24 앱스토어의 정기결제·정기배송 관련 앱과 PG의 정기결제 기능을 먼저 검토하는 것이 합리적입니다.

기성 앱을 사용하면 직접 시스템을 만드는 것보다 개발 기간과 초기 비용을 줄일 수 있는 경우가 있습니다.

다만 앱마다 지원하는 기능과 데이터 관리 방식이 다르기 때문에 설치 전에 확인해야 합니다.

단순히 ‘정기구독 기능 지원’이라는 문구만 보고 선택하는 것은 주의해야 합니다.

다음 항목을 확인하는 것이 좋습니다.

특히 중요한 것은 구독 정보가 어디에 저장되는지입니다.

앱에만 구독 정보가 있고 카페24 관리자에는 일반 주문만 남는다면 나중에 CS나 데이터 관리에서 기준이 달라질 수 있습니다.

정기구독에서 PG는 반복 결제를 처리하는 역할을 담당할 수 있습니다.

예를 들어 고객이 정기결제에 동의하고 등록된 결제수단을 이용해 매월 자동으로 결제하는 구조입니다.

하지만 PG가 쇼핑몰의 모든 구독 규칙을 대신 관리하는 것은 아닙니다.

예를 들어 다음과 같은 규칙은 별도로 설계해야 할 수 있습니다.

이번 달은 건너뛰기

다음 달부터 다시 결제

3회 결제 실패 시 구독 종료

결제 실패 후 7일 동안 혜택 유지

구독 중인 회원에게만 배송비 무료

즉,

PG = 반복 결제

구독 시스템 = 고객의 구독 상태와 운영 규칙

으로 생각하면 이해하기 쉽습니다.

또한 PG 정기결제는 일반적인 쇼핑몰 스킨 수정과 별개의 계약·심사·연동 절차가 필요할 수 있습니다.

다음과 같은 기능이 필요하다면 기성 앱만으로 해결하기 어려울 수 있습니다.

1. 구독 상품을 고객이 직접 변경하는 경우

예를 들어 고객이 다음 회차부터 다른 상품으로 변경하는 기능입니다.

2. 회차마다 상품이나 가격이 달라지는 경우

1회차와 2회차의 구성 상품이 다르거나, 회차별 가격이 달라지는 경우 별도의 구독 규칙이 필요합니다.

3. 이번 회차만 건너뛰는 경우

고객이 구독 자체를 해지하지 않고 이번 달 배송만 쉬는 기능입니다.

단순히 화면에서 ‘건너뛰기’라고 표시하는 것으로 끝나지 않고 실제 청구와 주문 생성에도 반영되어야 합니다.

4. 결제 실패 후 자동 재시도가 필요한 경우

예를 들어 결제 실패 후

1일 후 재시도 → 3일 후 재시도 → 7일 후 재시도 → 구독 종료

와 같은 정책을 운영할 수 있습니다.

5. 구독 회원에게만 별도의 혜택을 제공하는 경우

예를 들어 구독 중인 회원에게만

등을 제공할 수 있습니다.

이처럼 구독 상태가 쇼핑몰의 다른 기능에 영향을 주기 시작하면 별도의 구독 관리 시스템이 필요해질 가능성이 높아집니다.

복잡한 정기구독 서비스를 개발할 때는 일반적으로 카페24 API + 별도 서버 + 구독 DB 구조를 검토합니다.

예를 들어 다음과 같은 방식입니다.

고객

↓

구독 신청

↓

PG 정기결제

↓

별도 구독 서버

↓

구독 상태 확인

↓

카페24 주문 생성·관리

↓

배송

별도 서버에서는 고객별 구독 정보를 관리할 수 있습니다.

예를 들면 다음과 같습니다.

이 데이터를 기준으로 다음 결제와 주문 생성을 관리합니다.

정기구독은 단순히 결제를 반복하는 것보다 현재 구독 상태를 정확하게 관리하는 것이 중요합니다.

예를 들어 고객이 다음과 같은 상태에 있을 수 있습니다.

구독 중

이번 회차 건너뛰기

결제 실패

재결제 대기

해지 예약

구독 종료

이 상태에 따라 결제와 배송이 달라질 수 있습니다.

예를 들어 고객이 이번 회차를 건너뛰었다면 실제 결제도 발생하지 않아야 하고, 다음 회차의 결제일과 배송일도 그에 맞게 변경되어야 합니다.

따라서 단순한 버튼 하나를 만드는 것보다 구독 상태와 결제·주문 상태를 하나의 규칙으로 연결하는 것이 중요합니다.

스킨만 수정해서 정기구독처럼 보이게 만드는 것은 가능합니다.

예를 들어 마이페이지에

다음 결제일: 10월 15일

구독 회차: 4회차

[이번 회차 건너뛰기]

[구독 해지]

와 같은 화면을 만들 수 있습니다.

하지만 화면에 버튼을 만드는 것과 실제 구독 기능이 작동하는 것은 다른 문제입니다.

‘이번 회차 건너뛰기’ 버튼을 눌렀다면 실제 결제도 중단되어야 합니다.

‘구독 해지’를 했다면 다음 자동 결제가 발생하지 않아야 합니다.

따라서 실제 결제와 주문 생성까지 연결해야 한다면 스킨만으로 해결하기 어렵습니다.

다음 질문에 답해 보면 현재 쇼핑몰에 필요한 개발 범위를 파악하기 쉽습니다.

이 중 필요한 기능이 많아질수록 단순한 정기결제 앱보다 구독 상태를 별도로 관리하는 시스템을 검토할 필요가 있습니다.

반드시 그렇지는 않습니다.

오히려 처음부터 복잡한 시스템을 만드는 것보다 현재 운영 방식에 맞춰 단계적으로 개발하는 방법이 현실적일 수 있습니다.

1단계

같은 상품을 같은 주기로 반복 배송한다면 정기결제·정기배송 앱과 PG 기능을 먼저 검토합니다.

2단계

운영하면서 필요한 예외 기능을 확인합니다.

예를 들어,

등입니다.

3단계

기성 앱으로 해결하기 어려운 기능만 별도로 개발합니다.

이렇게 하면 필요하지 않은 기능까지 처음부터 개발하는 것을 줄일 수 있습니다.

모든 반복 구매 상품이 정기구독 시스템을 필요로 하는 것은 아닙니다.

예를 들어 고객이 매달 같은 상품을 다시 구매하고, 운영자가 별도의 자동 결제나 건너뛰기 기능을 제공하지 않는다면 일반 상품으로 판매하는 것이 더 간단할 수 있습니다.

반대로 고객이 자동으로 결제되고, 정해진 주기에 배송되며, 구독 상태에 따라 혜택이 달라진다면 정기구독 시스템이 필요할 가능성이 높습니다.

따라서 ‘정기구독 쇼핑몰을 만들고 싶다’는 요구사항을 받았다면 먼저 실제로 어떤 부분을 자동화하려는 것인지를 확인하는 것이 중요합니다.

예를 들어 건강식품이나 소모품을 판매하는 쇼핑몰에서 고객이 매월 상품을 받도록 만들었다고 가정해 보겠습니다.

기성 앱에서는 같은 상품을 매월 자동으로 결제할 수 있지만 운영자는 고객마다 다른 배송 구성이나 건너뛰기를 엑셀로 관리할 수 있습니다.

그러면 다음과 같은 문제가 생길 수 있습니다.

운영 엑셀에서는 이번 달 건너뛰기

하지만

PG에서는 정상 결제

가 발생하는 것입니다.

고객은 이번 달 상품을 받지 않는다고 생각했는데 카드 결제는 발생하게 됩니다.

따라서 정기구독 서비스에서는 화면·운영표·결제·주문이 같은 상태를 바라보는 구조가 중요합니다.

정기구독은 일반 상품보다 결제와 주문 데이터가 반복적으로 발생하기 때문에 예외 상황을 미리 정하는 것이 좋습니다.

특히 다음 항목을 명확하게 해야 합니다.

이 규칙이 정해져 있지 않으면 개발 과정에서 같은 기능을 두고도 서로 다른 해석이 생길 수 있습니다.

따라서 개발 전에 ‘결제 실패하면 어떻게 처리한다’와 같은 운영 규칙을 문장으로 먼저 정하는 것이 중요합니다.

옴니어스24에서는 ‘정기구독 쇼핑몰을 만들어 주세요’라는 요구만으로 바로 전체 시스템을 개발하지 않습니다.

먼저 다음 내용을 확인합니다.

① 일반 상품처럼 1회 결제로 충분한가?

② 같은 상품을 같은 주기로 반복 결제하면 되는가?

③ 정기결제 앱으로 필요한 기능을 모두 처리할 수 있는가?

④ 건너뛰기·상품 변경·결제 실패 재시도 같은 예외가 필요한가?

⑤ 구독 상태를 별도 서버에서 관리해야 하는가?

단순한 정기배송이라면 기존 앱과 PG 기능을 우선 검토하고, 기성 기능으로 해결되지 않는 부분만 커스텀 개발로 연결하는 방법을 사용할 수 있습니다.

반대로 구독 상태가 주문·회원·배송·할인까지 영향을 주는 구조라면 별도 서버와 DB를 이용해 구독 상태를 관리하는 방식으로 범위를 확장할 수 있습니다.

결국 중요한 것은 ‘정기구독 기능을 얼마나 많이 만들 것인가’가 아니라 ‘우리 쇼핑몰에서 실제로 어떤 구독 규칙이 필요한가’를 먼저 정하는 것입니다.

카페24 정기구독 쇼핑몰은 단순히 매월 자동으로 결제하는 기능만으로 완성되지 않습니다.

고객의 구독 상태와 다음 결제일, 회차, 건너뛰기, 해지, 결제 실패 등의 규칙이 실제 주문과 연결되어야 합니다.

같은 상품을 같은 주기로 반복 배송하는 단순한 구조라면 정기결제·정기배송 앱으로 충분할 수 있습니다.

반대로 고객마다 구독 상태가 다르고 회차별 상품 변경, 건너뛰기, 결제 실패 재시도, 구독 전용 혜택 등이 필요하다면 별도 서버와 DB를 이용한 커스텀 개발을 검토하는 것이 좋습니다.

따라서 정기구독 개발은 기본 기능 → 앱·PG → 커스텀 개발 순서로 필요한 범위를 확인하는 것이 가장 현실적인 방법입니다.