구독결제, 직접 만들지 SaaS를 쓸지 — 외주개발사 경험담

구독결제(정기결제)를 직접 구현해본 팀은 압니다. "결제 API 붙이면 끝"이 아니라는 걸요. 외주개발사로 여러 프로젝트에서 구독결제를 반복해서 구축해본 경험을 바탕으로, 언제 직접 만들어도 되고 언제 SaaS를 붙이는 게 나은지 정리했습니다.

직접 구현할 때 마주치는 것들

• 정기 청구 스케줄러: 결제일마다 활성 구독을 찾아 청구하는 배치를 직접 짜야 합니다.
• 결제 실패 던닝: 카드가 만료되거나 잔액이 부족하면 언제, 몇 번 재시도할지 정책을 설계하고 구현해야 합니다.
• 요금제 변경의 경직성: 월간→연간 전환, 업그레이드/다운그레이드 시 잔여 기간 처리(프로레이션)를 매번 새로 계산해야 합니다.
• 웹훅 신뢰성: 결제 성공/실패를 우리 서비스에 실시간으로 반영하려면 재시도와 서명 검증까지 직접 만들어야 합니다.

초기 구축이 끝이 아니라는 게 진짜 문제

직접 구현 프로젝트에서 정작 예산을 초과시키는 건 "1차 개발"이 아니라 그 이후입니다. 프로레이션 로직은 처음엔 if문 몇 줄로 시작하지만, 요금제 종류가 늘고 예외 케이스(환불, 부분 결제, 다운그레이드 유예기간)가 쌓일수록 조건문이 기하급수적으로 복잡해집니다. Billing 인프라 SaaS 업체 Schematic도 자사 블로그에서 이 패턴을 "간단한 조건문이 몇 달 안에 다루기 힘든 중첩 로직으로 진화한다"고 설명합니다. 저희가 맡았던 프로젝트들에서도 초기 구축보다 이후 6개월~1년 사이 유지보수 티켓이 더 많은 리소스를 잡아먹는 경우를 여러 번 봤습니다.

청구 SaaS 업체 Zenskar는 자체 리서치에서 사내 개발팀이 청구 시스템을 자체 구축했을 때 "엔지니어링 시간의 상당 부분이 신규 기능이 아니라 기존 청구 로직의 기술부채를 처리하는 데 쓰인다"고 보고합니다(Zenskar 블로그, 출처 자체 조사·미검증 수치이므로 참고용으로만 인용). 저희 경험상으로도 이 방향성 자체는 낯설지 않습니다 — 청구 로직은 "한 번 만들고 끝"이 아니라 서비스가 성장하는 내내 계속 손이 가는 코드베이스가 됩니다.

의사결정 체크리스트

아래 중 2개 이상 해당하면 직접 구현보다 SaaS 연동을 먼저 검토해보길 권합니다.

• [ ] 요금제 변경(업그레이드/다운그레이드/프로레이션)이 자주 발생하거나 앞으로 발생할 예정이다
• [ ] 결제 실패 시 던닝(재시도) 정책을 아직 설계하지 않았다
• [ ] 구독결제 로직이 우리 서비스의 핵심 경쟁력이 아니다 (예: 커머스, SaaS, 콘텐츠 구독 등 결제는 수단일 뿐인 경우)
• [ ] 결제 관련 인력을 전담으로 둘 계획이 없다
• [ ] "3개월 안에 첫 유료 고객을 받아야 한다" 같은 출시 기한이 있다

반대로 결제 로직 자체가 제품의 핵심 차별화 지점이거나(예: 매우 특수한 정산 구조), 이미 자체 결제 인프라 팀이 있다면 직접 구현이 합리적일 수 있습니다.

SaaS로 대체했을 때 줄어드는 작업

Plans/Customers/Subscriptions API만 연동하면 청구 스케줄러, 던닝, 웹훅 재시도·서명검증은 이미 구현돼 있는 걸 그대로 씁니다. 남는 일은 "우리 서비스에 맞는 요금제를 설계하는 것"뿐입니다.

여기서 한 가지 오해하기 쉬운 지점이 있습니다: 슈퍼빌링은 결제대행사(PSP)가 아닙니다. 대시보드에서 여러분 회사가 직접 계약한 PG(페이플, 토스페이먼츠 등) 계정 정보를 등록하면, 슈퍼빌링은 그 계정으로 청구를 대신 실행해줄 뿐 자금은 항상 여러분 회사의 PG 가맹점 계약을 통해 흐릅니다. 그래서 슈퍼빌링은 활성 구독자 수 기반으로만 과금하고(50명까지 무료), 매출(GMV)에서 수수료를 떼지 않습니다 — 국내에서 거래액 기반 수수료를 받으려면 전자금융업 라이선스가 필요한데, 그 라이선스는 PG와 직접 계약하는 여러분 회사가 갖는 것이지 슈퍼빌링이 가질 이유가 없기 때문입니다. 이 구조 덕분에 매출이 커져도 결제 인프라 비용이 매출에 비례해 늘어나지 않습니다.

정리

• 초기 구축 비용만 보고 판단하지 말고, 요금제 변경·던닝 등 계속 발생하는 유지보수 비용까지 함께 고려하세요.
• 구독결제 로직 자체가 우리 서비스의 핵심 경쟁력이 아니라면, 직접 구현보다 이미 검증된 인프라를 붙이는 게 낫습니다.
• 실제로 API Key 발급부터 첫 구독 생성까지 Quickstart 문서로 3분 안에 끝낼 수 있습니다.