해지 화면은 마지막 설득 기회예요

핵심 요약

• 해지 화면은 고객을 억지로 붙잡는 곳이 아니라, 떠나기 전 마지막 선택지를 제안하는 곳​​이에요. 가격 부담, 사용 빈도 저하, 기능 불만처럼 이유가 명확하다면 일시정지·다운그레이드·할인 같은 대안을 한 번 제안할 수 있어요.
• 고객이 그래도 해지를 선택하면 절차는 짧고 명확해야 해요. 해지 버튼을 숨기거나 상담을 강제하면 이탈을 막는 게 아니라 다크패턴 리스크와 CS만 키워요.
• 즉시 해지(취소 또는 환불)​​와 기간 만료 해지(다음 회차 결제 중단)​​를 명확히 구분해요. 정책이 모호하면 고객은 돈을 돌려받는 것으로 오해하고, 이는 곧 대량의 CS와 브랜드 신뢰도 하락으로 이어져요.

1즉시 해지와 기간 만료 해지를 먼저 구분해요

구독 해지는 크게 두 가져요. 기획 단계에서 이 용어를 명확히 구분하지 않으면 개발 로직이 꼬이고 고객 안내 문구에서 대혼란이 발생해요.

즉시 해지 (결제 취소 또는 환불)

결제 직후 서비스를 이용하지 않았거나, 남은 기간만큼 돈을 돌려받고 즉시 권한을 회수하는 방식이에요.

• 처리 방식​: 신용카드는 승인 취소​, 가상계좌 입금 후라면 환불​​로 처리해요. 휴대폰 결제는 당월이라면 취소, 익월이라면 환불이 원칙이에요.
• 기획 포인트​: 이용 실적이 있는 경우(콘텐츠 1회 시청, AI 크레딧 소진)는 환불이 불가능하다는 정책을 명시해요. 일할 계산 환불을 지원할지, 결제 후 7일 이내 미사용 시에만 전액 환불할지도 정해요.

기간 만료 해지 (다음 회차 결제 중단)

이번 달 결제한 기간까지는 서비스를 이용하고, 다음 결제일부터 돈이 나가지 않게 막는 방식이에요. 대부분의 SaaS·콘텐츠 구독이 이 방식을 써요.

• 처리 방식​: 다음 구독 회차 결제 예약을 취소​​하는 개념이에요.
• 기획 포인트​: 해지 신청 버튼을 눌러도 남은 기간(~월 ~일)까지는 모든 기능을 사용할 수 있다는 점을 강조해요. 고객은 해지 즉시 서비스가 끊길까 봐 해지를 미루다 결제 직전에 항의하는 경우가 많아요.

2윈백(Win-back) 시나리오: 해지 사유별 대안

해지 화면에서 할 일은 고객을 막는 게 아니라, 떠나는 이유를 확인하고 마지막 선택지를 보여주는 거예요. 고객이 해지 버튼을 눌렀을 때 "정말 해지하시겠어요?"라고만 묻는 것은 효과가 없어요. 대신 해지 사유를 확인하고, 사유에 맞는 대안을 한 번만 제안해요.

여기서 한 번 더 중요한 기준이 있어요. 대안을 본 고객이 그래도 해지하겠다고 하면 바로 해지시켜야 해요. 해지 UX의 목적은 고객을 가두는 것이 아니라, 떠나기 전 마지막으로 맞는 선택지를 보여주는 거예요.

시나리오별 대응

• 가격 부담 고객​: 모든 기능을 다 쓰지 않는 고객에게는 더 저렴한 라이트 플랜 다운그레이드​​를 제안해요. 혹은 "지금 해지를 취소하시면 다음 달 50% 할인" 같은 한시적 프로모션을 제공해요.
• 이용 빈도 저조 고객​: SaaS·정기배송에서 효과적이에요. 해지 대신 1~3개월 동안 결제와 기능을 잠시 멈추는 일시정지(Pause)​​를 제공해요. 구독을 아예 끊는 것보다 심리적 문턱이 낮아 복귀율이 훨씬 높아요.
• 기능 불만족 고객​: 특정 기능을 찾지 못해 떠나는 고객에게는 관련 튜토리얼 영상을 보여주거나, 담당자 미팅(Demo) 세션을 제안해요.

해지 UX 단계

1. 사유 수집​: 3~5개 정도의 핵심 사유 선택지를 제공해요.
2. 맞춤 대안 제시​: 선택한 사유에 따라 할인권·일시정지·상담 요청 중 하나를 한 번만 노출해요.
3. 해지 확정​: 고객이 계속 해지를 선택하면 잃게 되는 혜택을 명확히 보여주고 바로 해지시켜요.

3다크패턴 규제를 피하는 해지 UX 기준

공정거래위원회·방송통신위원회는 구독 서비스의 해지 방해 행위​​를 엄격히 규제하고 있어요. 다음 사항을 어기면 시정명령이나 과징금 대상이 될 수 있으므로 기획 단계에서 반드시 확인해요.

① 해지 절차는 가입보다 어려우면 안 돼요

가입은 버튼 몇 번으로 끝났는데, 해지는 PC 웹사이트에 접속해야 하거나 고객센터 전화 연결을 강제​​하는 것은 전형적인 다크패턴이에요. PG 결제를 붙인 서비스라면 고객이 웹에서 결제했든 앱에서 결제했든 같은 해지 화면이나 안내로 자연스럽게 연결돼야 해요.

예를 들어 웹에서 무료체험을 시작한 고객이 앱만 쓰다가 해지하려고 할 수 있어요. 이때 앱에 아무 안내가 없으면 고객은 “해지 버튼이 안 보여요”고 느끼고 바로 CS를 넣어요.

최소한 아래 흐름은 맞춰둬요.

• 웹에서 가입한 고객: 웹 해지 화면으로 이동
• 앱에서 해지하려는 고객: 같은 해지 화면을 열거나 해지 안내 링크 제공
• 고객센터로 들어온 고객: 가입 경로와 결제수단을 확인한 뒤 동일한 정책으로 처리

인앱 결제를 함께 쓰는 서비스라면 플랫폼별 해지 경로가 따로 생길 수 있지만, PG 자동결제 문서에서는 예외 케이스 정도로만 보면 돼요. 핵심은 고객이 어느 화면에 있든 해지 방법을 찾을 수 있게 만드는 것​​이에요.

② 버튼 위치를 의도적으로 숨기지 않아요

설정 메뉴 하위에 뎁스(Depth)를 너무 깊게 두거나, 배경색과 비슷한 폰트 색상으로 해지 버튼을 잘 안 보이게 만드는 행위는 금지돼요. 적어도 결제 내역이나 계정 설정 같은 상식적인 위치에 버튼이 있어야 해요.

③ 해지 결과를 즉시 확인시켜요

해지 버튼을 누른 뒤 고객이 가장 궁금해하는 것은 두 가져요. 언제까지 쓸 수 있는지​, 다음 회차 결제가 정말 막혔는지​​예요.

그래서 해지 완료 화면과 알림에는 아래 내용을 바로 보여줘요.

• 해지 처리 상태: 즉시 해지인지, 기간 만료 해지인지
• 이용 가능 기간: 언제까지 서비스를 쓸 수 있는지
• 다음 회차 결제 여부: 다음 결제가 예약 취소됐는지
• 다시 이용하는 방법: 해지 취소 또는 재구독 경로

이 안내가 없으면 고객은 해지했는데도 불안해서 고객센터에 다시 확인해요. 해지 UX는 버튼을 누르는 순간보다 해지 후 결과를 명확히 보여주는 것​​까지 포함해요.

4해지 정책에서 자주 빠뜨리는 지점

① 결제 수단별 취소·환불 API 분기

카드는 시스템 취소​, 가상계좌는 환불 계좌 수집 후 직접 송금​. 결제 수단 하나로 통합 처리하면 가상계좌 건에서 운영 사고가 반복돼요.

② 해지 예약 상태 관리

기간 만료 해지 시, DB상 구독 상태가 즉시 종료가 아닌 '해지 예약' 상태로 관리돼야 해요. 해지 예약 상태에서 고객이 "해지 취소"를 누르면 결제 예약이 정상 복구돼야 해요.

③ 일시정지 기간 종료 후 결제 재개

일시정지 기능을 도입한다면, 정지 기간 종료 후 결제가 자동 재개되는 스케줄러​​가 있어야 해요. 없으면 고객이 복귀했는데도 결제가 멈춘 상태로 서비스만 제공되는 미결 건이 쌓여요.

④ 해지 후 데이터 보존 기간

해지 즉시 데이터를 지울지, 30일 보관 후 삭제할지 정해요. 재가입 고객이 많다면 보존 기간을 길게 잡는 편이 복귀 CS를 줄여요.

실제로 붙이려면

빌링키 삭제는 payments, 구독 회차와 해지 이후 처리는 commerce 쪽에서 확인해요.

• 빌링키 삭제 — /billing/key-delete
• 구독 청구 사이클 — /subscription-ops/bill/cycle