구독·결제 시스템을 붙일 때 놓치기 쉬운 것 | 정기결제 체크리스트
정기결제를 붙이면 결제 실패 재시도, 구독 해지 처리, 개인정보 보유기간까지 한꺼번에 챙겨야 해요. 결제 실패로 인한 구독 이탈이 20～40%에 달한다는 자료도 있어요. 자체 SaaS 4종을 운영해온 개발사 기준으로 놓치기 쉬운 지점을 정리했어요.
핵심 요약 — 구독·정기결제 시스템은 결제창 하나만 붙이면 끝나는 일이 아니에요. 결제가 실패했을 때 다시 시도하는 방식, 해지 요청을 처리하는 순서, 해지 후 개인정보를 얼마나 보관할지까지 미리 정해둬야 나중에 사고가 안 나요. 실제로 결제 실패가 구독 이탈의 20～40%를 차지한다는 자료도 있어요. 직접 만들고 운영해본 개발사 기준으로 정리했어요.
“결제 붙이는 거 얼마 안 걸리죠?” 정기결제를 처음 붙이는 팀에서 자주 듣는 말이에요. 결제창 하나 붙이는 일이라면 맞는 말이지만 구독형 서비스는 그 뒤가 더 길어요. 카드가 만료돼서 결제가 실패하면 언제 다시 시도할지, 해지를 누르면 그날 바로 끝낼지 다음 결제일까지 쓰게 할지 — 이 질문들에 답이 없으면 결제창은 붙었는데 서비스는 여전히 불완전해요.
1. 구독·정기결제는 일반 결제와 무엇이 다를까요
일반 결제(단건결제)는 그 순간 한 번 승인받고 끝나요. 반면 정기결제는 사용자가 최초 한 번만 카드를 등록·인증하면, 이후엔 그 등록 정보(흔히 ‘빌링키’라고 불러요)로 매달 또는 매주 알아서 다시 결제가 일어나야 해요. 결제 주기를 관리하는 스케줄러, 실패 시 재시도 로직, 해지·환불 처리까지 전부 별도로 설계해야 해서 손이 생각보다 많이 가요. 참고로 매장의 무인결제시스템이나 셀프 주문대의 키오스크결제는 성격이 달라요. 그때그때 한 번 승인받고 끝나는 단건 흐름이라 승인·정산 방식도 따로예요. “결제 붙인다”는 말을 들으면 먼저 어떤 결제인지부터 확인하는 게 순서예요.
2. PG사·빌링키, 무엇을 먼저 정해야 할까요
국내에서는 KG이니시스·NHN KCP·토스페이먼츠·나이스페이먼츠 상위 4개 PG사가 시장의 65～70%가량을 차지한다고 알려져 있어요. 어느 곳을 골라도 정기결제(빌링) 자체는 지원하지만 세부 방식이 달라요. 예를 들어 토스페이먼츠는 빌링키로 승인하는 구조는 제공해도 “매달 며칠에 결제한다” 같은 결제 주기 스케줄러는 제공하지 않아서 그 부분은 운영사가 직접 만들어야 해요. 여러 PG사를 한 번에 연동해주는 결제 대행 서비스를 쓰면 특정 PG사에 장애가 나거나 수수료가 바뀌어도 다른 곳으로 갈아탈 여지가 생기고요. 어느 쪽을 택하든 계약 전에 “결제 주기는 누가 관리하나”부터 확인하는 게 먼저예요.
3. 결제가 실패하면 왜 그냥 다시 시도하면 안 될까요
카드 만료로 실패한 결제와 잔액 부족으로 실패한 결제는 다시 시도하는 방식이 달라야 해요. 만료된 카드는 곧바로 재시도해봐야 소용없고 잔액 부족은 4～7일 지난 뒤 다시 시도하면 회복률이 눈에 띄게 올라가요. 해외 사례를 보면 요일·시간·거절 코드에 맞춰 재시도 간격을 조정하는 ‘스마트 재시도’가 고정 일정 재시도보다 2～3배 더 많은 결제를 되살린다고 해요. 국내 한 사례는 3일·7일 뒤 재시도와 7일 유예 기간으로 400건 중 280건, 즉 70%를 복구했어요. 결제 실패가 통상 구독 이탈의 20～40%를 차지한다는 걸 감안하면, 이 재시도 로직 하나가 매출에 그대로 영향을 줘요.
4. 구독 해지 요청, 어디까지 자동으로 처리해야 할까요
해지 요청이 오면 “그 순간 바로 끝낼지” 아니면 “이미 낸 금액만큼은 남은 기간까지 쓰게 할지”부터 정해야 해요. 대부분의 구독 서비스는 후자를 택해요. 이번 결제 주기가 끝나는 날까지 서비스를 유지하고 그 이후 다음 결제를 걸지 않는 방식이에요. 여기에 중간에 요금제를 바꾸는 경우까지 생기면, 남은 기간을 비율로 계산해 돌려주거나 다음 결제에 반영하는 처리(흔히 ‘프로레이션’이라고 불러요)도 필요해져요. 이 로직을 미리 안 짜두면 해지했는데 다음 달에 또 결제가 나가서 문의가 몰리는 상황이 생겨요.
5. 해지한 뒤 결제 정보는 언제까지 남겨둬야 할까요
해지했다고 결제 정보를 바로 다 지우면 안 되는 경우가 있어요. 결제와 관련된 기록은 법령상 5년, 소비자 분쟁 처리와 관련된 기록은 3년 정도 보관해야 하는 항목이 있거든요. 반대로 그 목적을 다한 개인정보를 계속 들고 있는 것도 문제예요. 원칙은 “약속한 보유 기간이 끝나면 지체 없이 파기”예요. 서비스 이용약관에서 이용자와 합의한 보유 기간과, 법령이 별도로 요구하는 보관 기간을 각각 확인해서 둘 중 더 긴 쪽을 기준으로 설계하는 게 안전해요.
6. 해외 결제·다중 통화까지 지원하려면 무엇이 달라질까요
챗지피티 같은 해외 SaaS 구독료를 카드로 달러 결제하는 방법을 찾아본 적이 있다면, 이미 다중 통화 결제가 무엇인지 체감해본 거예요. 원화 결제만 지원하다가 해외 사용자가 늘면서 달러 결제까지 붙이는 경우가 흔한데, 이건 결제 화면에 통화 선택란 하나 추가하는 일이 아니에요. 해외 카드를 받는 PG사인지, 환율을 어느 시점 기준으로 적용할지, 국가별 부가세를 어떻게 처리할지까지 다시 설계해야 해요. 처음부터 해외 사용자를 염두에 둔 서비스라면 PG사 선정 단계에서부터 이 부분을 같이 확인하는 편이 손이 덜 가요.
7. 자체 개발과 턴키 솔루션, 비용은 얼마나 다를까요
정기결제 로직을 처음부터 다 만드는 자체 개발은 주기 관리·재시도·해지·정산까지 전부 설계해야 해서 개발 기간이 몇 달 단위로 늘어나고 인건비도 그만큼 커져요. 정기결제 기능을 갖춘 턴키형 솔루션을 붙이면 초기 비용은 훨씬 가볍게 시작할 수 있어요(공개 자료 기준 추정치라 편차가 커요). 다만 턴키 솔루션은 사용자 수·결제 건수에 따라 매달 사용료가 붙는 구조가 많아서 서비스가 커질수록 누적 비용이 자체 개발과 비슷해지는 지점(손익분기)이 생겨요. 처음 규모만 보고 고르기보다 1～2년 뒤 예상 결제 건수까지 계산해보는 걸 권해요.
데이터로 보는 정기결제 체크포인트
자사 운영 기준(사내 설계 점검표 — 실거래 통계가 아니에요)
정기결제를 새로 붙일 때 저희가 착수 전에 반드시 확인하는 항목이에요.
| 점검 항목 | 놓치면 생기는 문제 | 확인 시점 |
|---|---|---|
| 결제 실패 재시도 규칙 | 회복 가능한 결제까지 놓쳐 매출 손실 | 설계 단계 |
| 해지 시점 처리(즉시/기간만료) | 해지했는데 또 결제되는 문의 발생 | 설계 단계 |
| 요금제 변경 시 정산(프로레이션) | 환불·추가청구 오류로 CS 부담 | 설계 단계 |
| 개인정보 보관·파기 주기 | 법령 위반 또는 불필요한 정보 장기 보관 | 계약·약관 확정 시 |
| 해외 결제·다중 통화 지원 여부 | 서비스 확장 시 PG사 재선정 필요 | 초기 PG 선정 단계 |
공식 외부 기준(참고용 — 해외·국내 공개 자료 종합)
| 지표 | 내용 |
|---|---|
| 결제 실패로 인한 구독 이탈 비중 | 전체 이탈의 20～40%(해외 업계 자료) |
| 스마트 재시도 회복률 | 최대 70%, 고정 일정 재시도보다 2～3배(해외 업계 자료) |
| 국내 재시도 사례(3일·7일 뒤 재시도, 유예 7일) | 400건 중 280건 복구, 70%(국내 사례) |
| 결제·분쟁 관련 기록 보관 | 결제기록 5년, 분쟁처리기록 3년 안팎(관행, 서비스별 확인 필요) |
⚠️ 위 공식 외부 기준은 해외·국내 공개 자료를 종합한 참고 수치예요. 저희 실거래 통계가 아니고 서비스 성격·이용약관에 따라 실제 값은 달라져요.
헷갈리는 용어부터 정리해볼까요
빌링키: 최초 한 번 카드를 등록·인증하면 발급되는 고유 키예요. 이후 결제는 카드 정보를 다시 받지 않고 이 키로 승인해요. PG(Payment Gateway, 결제 대행사): 가맹점과 카드사·은행 사이에서 결제 승인을 중계하는 사업자예요. 던닝(Dunning): 결제 실패 시 다시 시도하고 사용자에게 알리는 절차예요. 프로레이션(Proration): 요금제를 중간에 바꿀 때 남은 기간을 비율로 계산해 환불하거나 추가 청구하는 처리예요. 실무에서는 “던닝 로직이 있으면 재시도가 돌고 프로레이션이 없으면 요금제 변경 때 수동 계산이 필요하다”는 식으로 함께 써요.
운영해보니 다르게 보이는 것
저희는 D:VALUEUP·Likepro·Globing·Linkmix 자체 SaaS 4종을 직접 운영하면서 결제 화면을 만드는 일보다 결제 뒤에 벌어지는 일을 설계하는 데 더 많은 시간을 썼어요. 결제창은 하루 이틀이면 붙지만 실패한 결제를 다시 시도하고 해지 문의가 들어왔을 때 언제까지 서비스를 유지해줘야 하는지 판단하는 로직은 운영을 직접 해봐야 어디서 막히는지가 보여요. 저희는 같은 기능 수보다, 결제 하나가 실패했을 때 그 뒤로 무슨 일이 벌어지는지부터 먼저 그려봐요.
흔히 하는 실수
정기결제를 붙일 때 자주 보는 실수예요.
- 결제 실패를 딱 한 번만 재시도하고 끝내서, 며칠만 지나면 회복됐을 결제를 이탈로 흘려보내는 경우
- 해지 처리를 “결제 중단”으로만 만들어서 이미 낸 금액에 대한 이용 기간·환불 안내를 빠뜨리는 경우
- PG사 견적만 비교하고 재시도 로직 개발비를 별도로 계산하지 않아서 착수 뒤에 견적이 늘어나는 경우
결제창이 잘 붙었는지와는 별개로 서비스를 몇 달 운영해봐야 드러나는 문제라서, 착수 전 요구사항 정의 단계에서 미리 짚어두는 걸 권해요.
방향이 아직 명확하지 않아도 괜찮아요. 지금 검토 중인 결제 구조를 같이 짚어보고 싶으시면 편하게 문의해보세요 →
저희는 10년 넘게 50개 이상의 프로젝트를 진행하고 자체 SaaS 4종을 직접 운영해온 개발사예요. 롯데·캐논 같은 곳과도 함께해 왔고요.
자주 묻는 질문
정기결제 시스템을 자체 개발하면 비용이 얼마나 드나요?
범위에 따라 크게 갈려요. 결제창만 붙이는 수준이면 PG사 표준 API로 가볍게 시작할 수 있고 재시도·해지·정산까지 자체 로직으로 다 만들면 개발 기간과 인건비가 몇 배로 늘어나요. 턴키형 결제 솔루션은 초기 비용이 훨씬 낮게 시작되는 경우도 있어요(공개 자료 기준 추정치, 프로젝트마다 편차가 커요).
PG사 정기결제(빌링) 연동에는 보통 얼마나 걸리나요?
결제창 연동만이면 2～4주 안에도 끝나요. 다만 재시도, 해지·환불, 정산 화면까지 포함하면 저희 경험상 6～10주 정도를 잡는 게 안전해요. PG사마다 정기결제 스케줄러를 제공하지 않는 경우가 있어서 그 부분은 자체 개발로 채워야 하기 때문이에요.
구독 해지 후 결제 정보는 언제 삭제해야 하나요?
원칙은 목적을 다하면 바로 파기하는 거예요. 다만 결제 기록은 법령상 5년, 소비자 분쟁 처리 기록은 3년 정도 보관해야 하는 경우가 있어서 그 기간이 지난 뒤 삭제하도록 설계해요. 정확한 보관 기간은 약관에 합의한 기간과 관련 법령을 함께 확인해야 해요.
정리하며
정기결제는 결제창을 붙이는 순간이 아니라, 그 뒤에 실패·해지·보관이 어떻게 흘러가는지를 정해두는 순간부터 완성돼요. 재시도 로직 하나로 회복되는 매출이 있고 해지 처리 순서 하나로 줄어드는 문의가 있어요. 착수 전에 이 흐름들을 먼저 그려보면, 결제창을 붙인 뒤에 뒤늦게 손대는 일이 줄어들어요.
관련해서 함께 보면 좋은 글이에요.