안녕 — 오늘 아침에 보낸 메시지 봤어. 앱의 고객 지원 문의함에 누군가 "이거 어떻게 결제하나요"라고 물어본 스크린샷 말이야. 진심으로 축하해. 그 순간이 바로 사이드 프로젝트가 더 이상 데모가 아니게 되는 순간이거든. 동시에, 그동안 미뤄둘 수 있었던 수백 가지 자잘한 결정들이 하필 같은 화요일에 한꺼번에 몰려오는 순간이기도 하고. 그냥 뭘 해야 하는지 알려달라고 했지. 그렇게 할게, 근데 그 이유부터 먼저 짚고 넘어가고 싶어. 그 "이유"를 알아야 3개월 뒤 Stripe 대신 Lemon Squeezy를, 일회성 결제 대신 구독을 쓰게 됐을 때 다시 나한테 물어보지 않아도 되니까.
지금 실제로 내려야 하는 결정
"어떤 결제 제공업체를 써야 하나"로 프레이밍했지만, 사실 이건 두 가지 결정이 겹쳐 있는 거야. 첫째: 네가 판매자(Merchant of Record)가 될 건지, 아니면 다른 누군가가 그 역할을 맡게 할 건지. 둘째: 청구 방식이 뭔지 — 일회성 구매, 구독, 아니면 사용량 기반. 첫 번째를 잘못 정하면 6개월 뒤 어느 주말에 가본 적도 없는 나라에서 VAT 등록을 하게 될 거야. 두 번째를 잘못 정하면 그냥 귀찮은 마이그레이션일 뿐, 법적인 문제는 아니니까 둘 중에서는 덜 무서운 쪽이지.
판매자(Merchant of Record)가 된다는 건 법적으로 네가 그 상품을 판매하는 주체가 된다는 뜻이야. 네가 돈을 받고, 고객이 거주하는 모든 관할권의 판매세와 VAT를 알아서 처리하고 신고할 책임도 네게 있어. Stripe가 그 세금을 계산해주긴 하지만(Stripe Tax), 계산과 납부는 다른 문제야 — 기준을 넘는 지역마다 직접 등록하고 신고해야 해. Lemon Squeezy나 Paddle 같은 Merchant of Record 서비스는 이 문제 전체를 떠맡아줘. 법적으로 그들이 판매자이고, 모든 곳에서 세금을 징수하고 납부한 뒤 순액을 네게 지급하지. 대신 마진의 일부를 내줘야 해.
| 옵션 | 누가 판매자인가 | 일반적인 수수료율 | 세금 처리 | 적합한 경우 |
|---|---|---|---|---|
| Stripe (직접 연동) | 나 | 거래당 약 2.9% + $0.30, Stripe Tax 이용 시 +0.5% | 등록과 신고는 직접, Stripe는 계산만 담당 | 월 수천 건을 넘어설 것으로 예상되고 장기적으로 낮은 수수료를 원하는 경우 |
| Lemon Squeezy | Lemon Squeezy | ~5% + 거래당 $0.50 | 완전 대행, 판매자 등록 주체가 됨 | 1인 개발자, 첫 제품, 세금 문제는 전혀 신경 쓰고 싶지 않은 경우 |
| Paddle | Paddle | ~5% + 지역별 수수료 상이 | 완전 대행, 엔터프라이즈에 더 적합 | 구독과 일부 인보이스 발행이 필요한 SaaS |
| PayPal | 나 | ~3.5-4.5%, 구매자 친화적 분쟁 처리 | 직접 처리 | PayPal을 특별히 신뢰하는 고객, 기본 선택지는 아님 |
지금 상황을 놓고 보면 — 고객 한 명, 단순한 제품, 이게 사업이 될지 아직 모르는 상태라면 — 저는 Stripe를 직접 쓰기보다 Lemon Squeezy나 Paddle을 추천합니다. 수수료 2%포인트 더 내는 건, 한 번도 가본 적 없는 주에서 뜻하지 않게 세금 신고자가 되는 것에 대한 저렴한 보험이라고 보면 됩니다. 나중에 물량이 전환을 정당화할 만큼 늘고 서류 작업을 감당할 마음이 생기면 그때 Stripe로 직접 옮기면 됩니다. 재미로 결제 제공업체를 바꾸는 사람은 없지만, 그건 하루면 해결되는 일이지 1년이 걸릴 일은 아닙니다.
저도 예전 프로젝트에서 이 실수를 직접 저질렀습니다 — "다들 Stripe를 쓰니까"라는 이유로 바로 Stripe로 갔고, 몇몇 유럽 고객들에게서 월 몇백 달러를 받았는데, 18개월 후에 아주 정중하지만 아주 혼란스러운 VAT MOSS 등록 관련 이메일을 받았습니다. 회계사와 오후 시간을 쓰고 "내가 네덜란드에 돈을 빚졌나"를 구글링하며 40분간 순수한 패닉에 빠졌습니다. 치명적이지는 않았지만, 완전히 피할 수 있는 일이기도 했습니다.
실제 키를 건드리기 전에
무엇을 선택하든 프로덕션 모드로 먼저 연결하지 마세요. 이 제공업체들은 전부 특정 결과를 유발하는 가짜 카드 번호로 테스트/샌드박스 모드를 제공합니다 — 결제 성공, 카드 거절, 3D Secure 필요, 잔액 부족 등. 실제 키를 건드리기 전에 이 모든 경로를 다 실행해보세요. 실패 경로야말로 첫 주에 실제로 마주치게 될 것들이며, 진짜 사람의 카드가 연결된 상태에서 라이브로 디버깅하는 건 훨씬 덜 재미있습니다.
빌드 채팅에서 이것을 단계별로 진행하고 싶다고 명확히 말하세요. 먼저 테스트 모드로 결제 연동을 요청하고, 테스트 중에 (미래의 당신을 포함해서) 아무도 실수로 실제 카드에 결제하지 않도록 눈에 띄는 배너나 플래그를 요청하세요. 그런 다음 별도의, 의도적인 단계로 실제 키를 교체하세요. "결제 추가해줘"라고 한 번에 말해서 알아서 모드를 추측하게 하는 게 더 빠르겠지만, 두 번의 프롬프트로 나누세요. 그 마찰이 바로 핵심입니다.
웹훅이 발생했는데 서버가 다운되었거나, 느리거나, 이벤트가 두 번 도착하면 어떻게 할지도 결정해야 합니다. 이건 가정이 아니라 첫 주에 확실히 일어나는 일입니다. 최소한 처리해야 할 이벤트는 다음과 같습니다:
checkout.session.completed(또는 이에 상응하는 것) — 접근 권한 부여, 이 순간이 고객이 진짜 고객이 되는 순간입니다invoice.payment_failed— 구독의 경우, 즉시 접근 차단인지 유예 기간을 둘지 지금 결정하세요. "즉시 차단"은 일시적 문제가 있었던 카드에 대한 첫인상으로는 정말 나쁘니까요customer.subscription.deleted— 누군가 취소하면, 약관에 다르게 명시하지 않는 한 즉시가 아니라 결제 기간 종료 시점에 접근 권한을 회수하세요- 환불 이벤트 — 첫 환불 요청이 실시간으로 결정을 강요하기 전에, 실제 환불 정책이 무엇인지 스스로에게 글로 한 번 정해두세요
멱등성(idempotency)은 앱의 거의 다른 어떤 부분보다 여기서 더 중요합니다. 웹훅이 두 번 도착하면 — 그리고 반드시 그럴 겁니다. 200이 아닌 응답에는 제공업체가 재시도하니까요 — 접근 권한을 두 번 부여하거나, 더 나쁘게는 내부 상태에 이중 청구를 하면 안 됩니다. 이벤트 ID를 저장하고, 처리하기 전에 이미 처리한 적이 없는지 확인하세요.
당신이 피하고 있는 가격 질문
메시지에서 월 $9로 할지 일회성 $49로 할지 확신이 안 선다고 하셨죠. 둘 다 틀린 건 아니라고 생각하지만, 실제로 당신이 무엇을 피하고 있는지 주목해보세요: 지속적인 가치가 무엇인지에 대해 고객과 나눠야 할 대화입니다. 일회성 가격은 고객이 동의하기 쉽고 당신이 만들기도 쉽습니다(연체 관리, 갱신 실패 처리, 취소 흐름이 필요 없음). 구독은 사람들이 이탈하지 않을 만큼 계속 개선해나가겠다는 베팅입니다 — 이건 가격 페이지의 체크박스 하나가 아니라 진짜 약속입니다. 6개월 후에도 이걸 계속 적극적으로 작업하고 있을지 확신이 없다면, 일회성 가격이 더 정직한 제안입니다. 나중에 구독할 만한 지속적인 것이 생기면 그때 구독 등급을 추가하면 됩니다.
한 가지만 더 말씀드리고 넘어가겠습니다: 첫 1달러를 받기 전에 페이지에 실제 환불 및 취소 정책을 올려두세요. 단 세 문장이라도 좋습니다. $9 결제 때문에 누가 고소할 일은 없겠지만, 정책을 써두는 행위 자체가 실제로 그것을 결정하게 만들기 때문입니다. "누가 물어보면 그때 정하지 뭐"라고 하면 결국 차분한 오후가 아니라 화난 이메일 한복판에서 정책을 결정하게 됩니다.
먼저 가서 샌드박스를 연결해보세요. 가짜 거절 카드를 통과시켜 봤을 때 문자 주세요 — 그게 실제로 중요한 "작동한다"의 버전입니다.
