💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

원문 렌더가 준비되기 전까지 텍스트 가이드로 표시합니다.

프롤로그 — 결제는 코드가 아니라 회계다

1인 개발자가 SaaS를 만들 때 가장 많이 과소평가하는 작업이 **결제**다. 코드 자체는 어렵지 않다. Stripe Checkout 한 줄, 웹훅 핸들러 50줄, 끝. 진짜 문제는 그 뒤에 줄지어 오는 것들이다. 부가가치세(VAT)·소비세(Sales Tax)·청구서(Invoice)·환불·실패한 결제 재시도(dunning)·디스퓨트(chargeback)·세무 신고·매출 인식(revenue recognition). 이 모든 것이 합쳐져 "결제"라는 한 단어가 된다.

2026년의 좋은 소식은 이걸 다 직접 만들 필요가 없다는 점이다. **Merchant of Record(MoR)** 라고 불리는 한 부류의 서비스 — Lemon Squeezy, Polar, Paddle, Creem, Gumroad — 가 부가세 신고·세금·법적 매도자 책임까지 다 떠안고, 대신 거래액의 4 ~ 6%를 가져간다. 반면 **Stripe·Adyen·Braintree** 같은 결제 게이트웨이(Payment Service Provider, PSP)는 신용카드 처리에만 책임을 진다. 부가세 신고, 회사 등록, 환불 정책은 당신 일이다.

이 글은 그 선택을 다룬다. 어떤 상황에서 Stripe로 직접 만들고, 어떤 상황에서 MoR에게 5%를 더 내는 게 합리적인가. 2026년 5월 기준 각 플랫폼의 실제 상태 — 가격, 한계, 누가 누구에게 인수됐는지 — 도 함께 정리한다. 끝에는 매출 단계별 의사결정 매트릭스를 남긴다.

1장 · Stripe vs MoR — 책임의 분기선

1.1 Merchant of Record란 정확히 무엇인가

법적으로 "Merchant of Record"는 **당신의 고객에게 상품·서비스를 판매한 법적 매도자**다. 영수증·인보이스 상단에 적히는 이름이 그것이다. MoR을 쓰면 고객 입장에서 결제 명세서에 `LEMON SQUEEZY*` 또는 `PADDLE.NET*` 같은 이름이 찍힌다. 당신 회사 이름이 아니다.

법적 매도자라는 건 무엇을 떠안는다는 뜻인가. 다음을 떠안는다.

- **부가세·소비세 신고 의무**. 독일에 판매했으면 19% MwSt(부가세) 신고를, 캘리포니아 판매면 7.25%+의 sales tax를, 영국이면 20% VAT를 — 매 분기 각 나라·주에 신고해야 한다.

- **환불 정책의 법적 책임**. EU 소비자 보호법의 14일 철회권(right of withdrawal), 일본 특정상거래법 등.

- **디스퓨트·차지백 대응**. 카드사 분쟁이 들어오면 증거 수집과 응답을 MoR이 한다.

- **무역 제재·KYC**. 러시아·이란·북한 제재 대상국 차단도 MoR 몫이다.

이걸 직접 하려면 진짜로 시간이 든다. 미국 한 곳만 보아도 2018년 South Dakota v. Wayfair 판결 이후 각 주가 sales tax nexus를 매출/거래 건수 임계로 따로 정의한다. EU는 OSS(One Stop Shop)·IOSS 제도가 있지만 등록·신고는 여전히 분기마다 한다.

1.2 Stripe는 PSP다 — MoR이 아니다

Stripe는 본질적으로 **결제 처리(payment processing) 인프라**다. 신용카드 결제를 받고 정산해주는 것까지가 본업이다. 그 위에 다음을 부가 서비스로 판다.

- **Stripe Tax** — 세율 계산·세금 등록 안내(미국 일부 주 한정). 단, **신고·납부는 사용자 책임**이다. 계산만 해준다.

- **Stripe Billing** — 구독 모델·인보이스·웹훅.

- **Stripe Invoicing** — B2B 인보이스 발행.

- **Stripe Connect** — 마켓플레이스용 분할 정산.

- **Stripe Workflows** (2025년 후반 GA) — 결제 이벤트 기반 자동화. 노코드 룰 엔진으로 "결제 실패 후 3일 뒤 이메일 → 7일 뒤 다운그레이드" 같은 시나리오를 GUI로 짠다.

핵심은 이거다. **Stripe는 강력하지만 부가세 신고를 대신 안 해준다.** Stripe Tax는 세율을 계산하고 시점별 보고서까지 만들어주지만, 각국 세무당국에 "이번 분기 매출은 이렇습니다" 신고하는 행위는 당신이 직접 또는 회계사/세무 대리 서비스(예: Hands-off Tax, TaxJar)를 끼고 한다. **Stripe Tax는 가이드 + 데이터 추출이지, 신고 대행이 아니다.**

1.3 MoR vs DIY — 책임 분기선 표

| 영역 | Stripe (DIY) | MoR (Lemon Squeezy·Polar·Paddle 등) |

| --- | --- | --- |

| 카드 처리 수수료 | 2.9% + `$0.30` (US) | 포함 |

| 부가세 계산 | Stripe Tax (추가 비용) | 포함 |

| 부가세 신고·납부 | **당신 책임** | **MoR이 대행** |

| 인보이스 발행 (B2B EU) | Stripe Invoicing | 포함 |

| 환불·차지백 처리 | 당신이 응답 | MoR이 응답 |

| 법인 등록 (각국) | 각국에 직접 등록 필요 시 | MoR 명의로 판매 |

| 결제 명세서에 표시되는 이름 | 당신 회사 이름 | MoR 이름 |

| 이상거래·KYC | Stripe Radar (추가 비용) | 포함 |

| 통화·로컬 결제 수단 | 직접 구성 | 기본 제공 |

| 총 수수료 (참고치) | 약 2.9 ~ 3.5% | 약 5 ~ 6% |

규칙은 단순하다. **MoR에게 추가로 내는 2 ~ 3%는 "각국 세무 신고를 안 하기 위한 보험료"** 다. 그 보험료의 가치는 당신이 몇 개 나라에 팔지, 매출이 얼마인지에 따라 다르다.

2장 · Stripe — 거인은 여전히 거인이다

2.1 Stripe의 2026년 위치

2026년 5월 기준 Stripe는 여전히 글로벌 결제 PSP의 사실상 표준이다. 매출은 2024년 약 `$1.4T` 결제량을 처리했고, 50개 이상 통화·40개 이상 국가에서 acquiring을 제공한다. 1인 개발자에게 Stripe가 매력적인 이유는 단순하다. **개발자 경험이 압도적이다.**

// Stripe Checkout — 가장 최소 형태의 결제 시작

const stripe = new Stripe(process.env.STRIPE_SECRET_KEY)

const session = await stripe.checkout.sessions.create({

mode: 'subscription',

line_items: [{ price: 'price_1ABC', quantity: 1 }],

success_url: 'https://example.com/success?session_id={CHECKOUT_SESSION_ID}',

cancel_url: 'https://example.com/cancel',

automatic_tax: { enabled: true }, // Stripe Tax on

})

return { url: session.url }

이게 다다. Hosted Checkout, 결제 수단, 카드 정보 보관(PCI-DSS), 3DS·SCA, 영수증 이메일, 모바일 지갑(Apple Pay·Google Pay) 모두 포함이다.

2.2 Stripe Tax — 어디까지 해주는가

Stripe Tax는 2026년 기준 다음을 해준다.

- **세율 자동 계산** — 50개 이상 국가·미국 50개 주.

- **임계 도달 알림** — 미국 economic nexus(주별 매출 `$100k` 또는 200건 등), EU OSS(EU 내 매출 €10,000 초과 등) 기준 도달 시 알림.

- **세금 등록 안내** — Stripe 파트너 네트워크(예: TaxJar·Avalara)로 연결.

- **분기별 신고용 보고서 다운로드** — 각국 신고 양식에 넣을 수 있는 CSV.

Stripe Tax가 **안 해주는 것**:

- 실제 세금 등록 신청을 대신 하지 않는다. 각국 세무당국에 회사를 직접 등록해야 한다.

- 분기별 신고·납부를 대신 하지 않는다. CSV를 들고 당신 또는 세무 대리인이 직접 신고한다.

- 세금 환급(예: 입력 부가세 공제) 처리도 안 한다.

**비용**: Stripe Tax는 거래액의 0.5% 추가, 또는 거래당 `$0.50`(둘 중 큰 쪽이 아니라 둘 중 적절한 모델로 협상 가능). 미국 외 거래는 별도 협상이 일반적이다.

2.3 Stripe Workflows — 2025년 후반의 큰 변화

Stripe Workflows는 2025년 10월쯤 GA가 된 노코드 자동화 빌더다. 기존에 Zapier·Make 같은 서드파티로 풀던 결제 후속 자동화 — 결제 실패 시 슬랙 알림, 구독 갱신 7일 전 이메일, 디스퓨트 들어오면 자동 응답 초안 — 를 Stripe 안에서 그리는 도구다.

Stripe Workflows — 사례: 결제 실패 후 자동 재시도와 다운그레이드

trigger: invoice.payment_failed

actions:

- wait: 24h

- retry_payment

- branch:

if: invoice.attempt_count >= 4

then:

- send_email: dunning_final

- update_subscription: { status: past_due }

else:

- send_email: dunning_reminder

이건 dunning 문제를 상당히 단순화한다. 예전엔 외부 Smart Retries(예: Recover·Baremetrics)나 직접 짠 큐 워커가 필요했다.

2.4 Stripe Connect — 마켓플레이스용

Connect는 1인 개발자가 "마켓플레이스"를 만들 때 필요하다. 예: 강사들이 강의를 팔고 당신이 수수료를 가져간다. 표준 / Express / Custom 계정 모델이 있고, 분할 정산(application_fee_amount)이 핵심이다.

Connect에는 추가 수수료가 있다. Standard는 거래당 `$2` (월간, 미국), Express·Custom은 더 비싸다. 그래서 단순 SaaS면 Connect는 안 쓴다.

2.5 Stripe + Lemon Squeezy — 2024년 인수 이후

2024년 7월 Stripe는 Lemon Squeezy를 인수했다. 그러나 Lemon Squeezy는 별도 브랜드로 계속 운영된다. 핵심 변경 사항:

- Lemon Squeezy는 여전히 Merchant of Record로 작동한다(Stripe가 PSP를 뒤에서 처리).

- 두 제품의 가격은 별개로 유지된다.

- 2025년부터 Stripe는 본진에 MoR 기능을 직접 통합하는 작업을 시작했다(`Stripe Tax` + `Stripe Billing` + 일부 MoR 기능). 단, 2026년 5월 기준 정식 "Stripe MoR" 단일 제품은 아직 시범 단계에 가깝다.

요약: 인수가 작동 방식을 바꾸지는 않았다. Lemon Squeezy를 쓰던 사람은 계속 쓰면 된다.

3장 · Lemon Squeezy — 디지털 제품 SaaS의 MoR 표준

3.1 포지셔닝

Lemon Squeezy는 2021년 출범, 2024년 Stripe에 인수됐다. **타깃은 디지털 제품 SaaS·인디 해커**다. 결제·구독·세금·인보이스·할인 코드·라이선스 키 발급까지 한 화면에서 한다.

가격(2026년 5월 기준):

- **수수료**: 카드/PayPal 5% + `$0.50` per 거래.

- 추가 비용: 없음. 세금 신고·VAT·인보이스 발급 다 포함.

- 출금: 매월 1일·15일 자동.

// Lemon Squeezy — Checkout 링크 생성

lemonSqueezySetup({ apiKey: process.env.LS_API_KEY })

const { data } = await createCheckout('storeId', 'variantId', {

productOptions: { redirectUrl: 'https://example.com/welcome' },

checkoutOptions: { embed: true },

checkoutData: { email: 'user@example.com' },

})

return data.attributes.url

3.2 강점

- **세금 진짜 다 해준다**. EU VAT, UK VAT, 일본 소비세, 호주 GST, 미국 sales tax 전부 MoR 명의로 신고. 사용자는 매출 보고서만 받는다.

- **라이선스 키 발급** 기본 제공 — 데스크톱 앱·노트 앱 같은 1회성 라이선스 모델에 강하다.

- **App Variants·할인·어필리에이트** 등 인디 해커가 쓰는 기능 묶음이 한 화면에 다 있다.

- **Stripe 인수 이후 안정성**이 더 올라갔다. 정산·KYC가 빨라졌다.

3.3 약점

- **본격 B2B**에는 부족하다. PO 기반 청구, 인보이스 후불결제, 다년 계약 같은 건 약하다.

- **마켓플레이스**는 안 된다. 분할 정산이 없다.

- **고가 거래의 5% + `$0.50`** 은 매출이 커지면 부담이다. `$10,000` 거래에 `$500` 수수료.

3.4 언제 쓰나

- 디지털 다운로드(폰트·테마·코스·플러그인).

- 자그마한 SaaS, 월 `$10 ~ $99` 구독 위주.

- 글로벌 매출(특히 EU 비중 큰 경우)이고, 부가세 신고 안 하고 싶을 때.

4장 · Polar.sh — 오픈소스 친화 신생 MoR

4.1 포지셔닝

Polar는 2023년에 출범했고 Y Combinator W24 출신이다. 2024 ~ 2025년 사이 빠르게 사용자를 모으며 "Lemon Squeezy의 대안"으로 자리 잡았다. **오픈소스 친화** 가 핵심 차별점이다. SDK·문서·자체 인프라가 GitHub에 공개돼 있고, 가격이 더 공격적이다.

가격(2026년 5월 기준):

- **수수료**: 4% + `$0.40` per 거래. Lemon Squeezy의 5% + `$0.50` 보다 약간 저렴.

- 추가 비용: 없음(완전 MoR).

- 출금: 매월 자동(혹은 잔액 임계 도달 시).

// Polar — Checkout 세션 생성

const polar = new Polar({ accessToken: process.env.POLAR_ACCESS_TOKEN })

const checkout = await polar.checkouts.create({

productPriceId: 'price_xyz',

successUrl: 'https://example.com/success?checkout_id={CHECKOUT_ID}',

customerEmail: 'user@example.com',

})

return checkout.url

4.2 강점

- **오픈소스/개발자 친화**. GitHub Sponsors와 연동돼 후원자에게 자동으로 라이선스를 주는 흐름이 1급이다.

- **사용량 기반(usage-based) 청구** 가 1급 시민이다. LLM API 같이 사용량 과금이 필요한 케이스에 강하다.

- **Customer Portal**·**라이선스 키**·**파일 다운로드** 같은 인디 SaaS 필수 기능이 모두 포함.

- **수수료가 더 낮다**. 4% + `$0.40`.

4.3 약점

- **신생 플랫폼**. Lemon Squeezy·Paddle보다 역사가 짧아 long-tail 통화/결제 수단 지원이 좁다.

- **B2B 인보이스** 기능은 아직 단순하다.

- 일부 국가에서는 정산 대기 기간이 길 수 있다.

4.4 언제 쓰나

- 오픈소스 프로젝트의 상업화(예: Pro 티어, 호스팅 버전).

- LLM API 래퍼 등 사용량 기반 과금.

- 작은 인디 SaaS에서 1 ~ 2%의 수수료 차이가 의미 있는 단계.

5장 · Paddle — OG Merchant of Record

5.1 포지셔닝

Paddle은 2012년 출범한 영국 회사로 **SaaS 전용 MoR의 원조**다. 2022년 ProfitWell 인수, 2024 ~ 2025년 사이 대형 SaaS 고객층(예: SyncFusion, Beamer, Krisp 등)을 두텁게 다지면서 엔터프라이즈 영역에서 견고하다.

가격(2026년 5월 기준):

- **수수료**: 5% + `$0.50` per 거래(소액 거래에는 더 높은 단일 요율). 매출 규모에 따라 협상 가능.

- 추가 비용: ProfitMetrics·Retain·인보이스 별도 협상.

- 출금: 격주 또는 월간.

// Paddle Billing — v2 SDK Checkout 오픈

const paddle = await initializePaddle({

environment: 'production',

token: process.env.PADDLE_CLIENT_TOKEN,

})

paddle.Checkout.open({

items: [{ priceId: 'pri_xxx', quantity: 1 }],

customer: { email: 'user@example.com' },

successUrl: 'https://example.com/welcome',

})

5.2 강점

- **엔터프라이즈 SaaS 기능이 깊다**. 다년 계약, 청구서 후불결제(NET-30), 회계 시스템 연동(NetSuite·QuickBooks).

- **Retain by Paddle** — 결제 실패 복구(dunning) 전문 서비스. SaaS 한정 업계 최강이라 평가받는다.

- **세금·인보이스 100% MoR**. 200개 이상 국가/지역.

- **로컬 결제 수단**이 매우 넓다 — UPI(인도), iDEAL(네덜란드), Giropay(독일), Konbini(일본 편의점 결제) 등.

5.3 약점

- **승인이 까다롭다**. 신생 SaaS는 가입 심사에서 거절되거나 추가 서류를 요구받는 경우가 있다.

- **B2C·디지털 다운로드는 약하다**. Lemon Squeezy/Gumroad가 더 낫다.

- **수수료 협상이 필요**. 표시가만 보면 비싸 보인다. 매출 `$100k`/년 이상부터 가격 협상이 의미 있다.

5.4 언제 쓰나

- B2B SaaS, 평균 `$50 ~ $500/월` 구독.

- 글로벌 매출이 30% 이상이고 dunning이 중요한 시점.

- 회계 시스템 연동·인보이스 후불결제 필요.

6장 · Creem — 유럽 신생 MoR

6.1 포지셔닝

Creem은 2023년 유럽에서 출범한 신생 MoR다. Polar와 비슷한 시기에 등장했고, 마찬가지로 **인디 해커/1인 SaaS** 를 타깃한다. 가격은 Lemon Squeezy 수준이나, UI 단순함과 빠른 정산 주기를 차별점으로 내세운다.

가격(2026년 5월 기준):

- **수수료**: 약 5% + `$0.50` (정확한 요율은 거래 통화·결제 수단별로 다름).

- 정산: 일부 통화는 매주 가능.

- MoR 풀 패키지 — VAT·인보이스·환불 다 포함.

6.2 강점

- **유럽 비즈니스에 친화적**. EU VAT 처리·SEPA Direct Debit·iDEAL 등 유럽 결제 수단이 깊다.

- **UI가 단순**. 가입부터 첫 결제까지 30분 이내.

- **빠른 정산 주기**(주 단위 옵션).

6.3 약점

- **신생이라 한계가 명확**. 라이선스 키·파일 다운로드 같은 인디 기능이 Lemon Squeezy/Polar보다 얕다.

- **북미·아시아 사용자에게는 인지도가 낮다** — 결제 명세서의 `CREEM*` 이름을 본 적 없어 분쟁이 늘 수 있다.

6.4 언제 쓰나

- 주 고객층이 EU/UK인 경우.

- Lemon Squeezy/Polar에서 거절되거나 정책 충돌이 있는 경우의 대안.

7장 · Gumroad — 크리에이터·디지털 다운로드용

7.1 포지셔닝

Gumroad는 2011년 출범한 가장 오래된 크리에이터용 결제 플랫폼이다. **상품 판매에 초점** — eBook, 강좌, 디자인 에셋, 음악, 디지털 다운로드. SaaS 구독은 가능하지만 본업이 아니다.

가격(2026년 5월 기준):

- **수수료**: 10% flat (단순). 결제 수단별 추가 수수료 없음.

- 정산: PayPal·Stripe Connect로 연동, 영업일 기준 정산.

- MoR — VAT/sales tax 포함.

7.2 강점

- **세팅이 5분**. 가장 빠르게 디지털 상품을 팔 수 있는 도구.

- **세금 다 포함**. 신고·납부 안 한다.

- **할인·번들·페이 왓 유 원트(pay-what-you-want)** 같은 인디 기능 풍부.

7.3 약점

- **10%는 비싸다**. 매출이 커지면 다른 MoR이 더 저렴.

- **API·웹훅이 얕다**. 깊은 통합은 어렵다.

- **2022년 이후 회사 운영이 안정적이지 않다는 평**(라이오프, 가격 정책 변경 등).

7.4 언제 쓰나

- 정말 가벼운 디지털 상품 1 ~ 2개를 빠르게 판매하고 싶을 때.

- 매출이 작아서 10%의 절대 금액이 작은 단계.

8장 · 모바일 IAP — 30%의 현실

8.1 안드로이드·iOS의 강제

모바일 앱에서 **디지털 상품/구독**을 팔면 Apple App Store와 Google Play가 자체 결제 시스템(In-App Purchase, IAP) 사용을 강제한다. 위반하면 앱이 거절·삭제된다.

수수료(2026년 5월 기준):

- **Apple IAP**: 표준 30%. Small Business Program(연 매출 `$1M` 미만 개발자) 가입 시 첫해 `$1M` 까지 15%. 구독은 첫해 30%, 1년 이후 갱신 15%.

- **Google Play Billing**: 표준 15%(매출 `$1M` 까지) → 30%(초과분). 구독은 처음부터 15%.

8.2 외부 결제 허용 — 2024 ~ 2025년의 변화

미국·EU·한국·일본에서 규제·소송 결과로 외부 결제 링크 노출이 부분적으로 허용됐다. 2026년 5월 기준 정리:

- **EU(Digital Markets Act)**: iOS·Android에서 외부 결제 사이드 로드 가능. 단, Apple의 Core Technology Fee(CTF)는 별도 — 연간 100만 설치 초과분에 설치당 `€0.50`.

- **미국(Epic v. Apple 판결 후속)**: 앱 안에서 외부 결제 페이지 링크 허용. Apple은 외부 결제도 일부 수수료(첫 7일 27%, 이후 12%)를 부과.

- **한국(전기통신사업법 개정)**: 외부 결제 허용. Apple/Google은 외부 결제분에도 인하된 수수료(약 26%/11%) 부과.

- **일본**: 2025년 시행된 스마트폰 소프트웨어 경쟁촉진법(Mobile Software Competition Act) 시행으로 사이드 로딩·외부 결제 의무화 단계적 진행.

**현실 1**: 외부 결제로 우회한다고 해서 깔끔하게 30%가 0%가 되지 않는다. Apple/Google은 외부 결제분에도 commission을 부과한다. 절감폭은 보통 5 ~ 10% 정도다.

**현실 2**: 외부 결제 UX는 나쁘다. "앱에서 결제" 한 번이 "앱 → 브라우저 → 결제 → 앱 복귀"가 된다. 전환율이 떨어진다.

**현실 3**: 웹 first면 Stripe/MoR, 모바일 first면 IAP를 받아들이고 가격에 반영하는 게 합리적이다.

8.3 RevenueCat — IAP의 사실상 표준

iOS/Android IAP를 직접 다루지 마라. **RevenueCat** 을 쓴다. 두 스토어의 결제 이벤트를 통합 API로 뽑아주고, 분석/Cohort/실험까지 한 화면이다.

// iOS — RevenueCat으로 구독 구매

Purchases.shared.purchase(package: package) { transaction, customerInfo, error, userCancelled in

if customerInfo?.entitlements["pro"]?.isActive == true {

// 활성화

}

가격: 매출 `$2.5k/월` 까지 무료, 이후 매출의 1%.

9장 · 수수료 수학 — `$5k MRR` 에서 진짜 차이

9.1 가정

- 월 매출(MRR): `$5,000`

- 평균 거래액: `$30/월` 구독 → 약 167건/월

- 매출 구성: 미국 40%, EU 35%, 일본·기타 25%

- Stripe DIY를 고를 때 추가로 부담하는 것: 세무사 비용(분기당 약 `$500`), Stripe Tax 추가 0.5%

9.2 비용 비교 매트릭스 (`$5k MRR`)

| --- | --- | --- | --- | --- |

| 결제 수수료 | `$5,000 × 2.9% + 167 × $0.30` = `$195` | `$5,000 × 5% + 167 × $0.50` = `$334` | `$5,000 × 4% + 167 × $0.40` = `$267` | `$5,000 × 5% + 167 × $0.50` = `$334` |

| Stripe Tax (0.5%) | `$25` | 포함 | 포함 | 포함 |

| 세무사 분기 비용 (월 환산) | 약 `$167` | 없음 | 없음 | 없음 |

| 인보이스/B2B 도구 | 약 `$30` | 포함 | 포함 | 포함 |

| 월 총 비용 | 약 `$417` | `$334` | `$267` | `$334` |

| 매출 대비 | 8.3% | 6.7% | 5.3% | 6.7% |

뜻밖의 결론: **`$5k MRR` 구간에서는 MoR이 오히려 더 저렴**할 수 있다. 세무사·등록·관리에 드는 시간/돈을 합치면 5% 수수료가 보험이 아니라 **할인**이 된다.

9.3 `$50k MRR` 에서 다시 보면

| --- | --- | --- | --- | --- |

| 결제 수수료 | 약 `$1,950` | 약 `$3,335` | 약 `$2,667` | 약 `$3,335` |

| Stripe Tax | `$250` | 포함 | 포함 | 포함 |

| 세무 운영(전담 직원 일부) | 약 `$1,500` | 0 | 0 | 0 |

| 월 총 비용 | 약 `$3,700` | `$3,335` | `$2,667` | `$3,335` |

| 매출 대비 | 7.4% | 6.7% | 5.3% | 6.7% |

`$50k MRR` 단계에서도 Polar/Lemon Squeezy가 비슷하거나 약간 더 저렴하다. 본격적인 손익분기점은 **`$200k ~ $500k MRR`** 즈음으로 보는 게 일반적이다. 그 위에서는 전담 세무·법무 인력으로 직접 운영하는 비용이 5%의 MoR 수수료보다 작아진다.

9.4 손익분기점 — 한 줄 요약

- **`< $5k MRR`** : MoR이 거의 무조건 유리. 시간을 산다.

- **`$5k ~ $50k MRR`** : MoR이 여전히 가성비 좋음. Polar로 약 5%, Lemon Squeezy/Paddle로 6.7%.

- **`$50k ~ $200k MRR`** : 중간 지대. 세무사 + Stripe Tax로 직접 운영 시작해 볼 만함.

- **`> $200k MRR`** : 전담 인력 두고 Stripe DIY가 보통 더 싸다. 단, EU·일본 비중이 매우 크다면 여전히 MoR 유지가 합리적.

10장 · 웹훅과 dunning — 실패하지 않는 결제 시스템

10.1 웹훅은 반드시 멱등하게

결제 시스템에서 **웹훅은 단 한 번 정확히 도착하지 않는다**. Stripe·Polar·Paddle 모두 다음을 보장한다.

- **At-least-once 전달**. 같은 이벤트가 여러 번 올 수 있다.

- **순서 보장 없음**. `invoice.paid` 가 `invoice.created` 보다 먼저 올 수 있다.

- **5초 안에 200을 못 받으면 재시도**. 최대 3일까지 지수 백오프.

해법: **멱등성(idempotency)** 을 코드 안에 박는다.

// Next.js Route Handler — Stripe webhook idempotent 처리

const stripe = new Stripe(process.env.STRIPE_SECRET_KEY!)

export async function POST(req: Request) {

const body = await req.text()

const sig = (await headers()).get('stripe-signature')!

let event: Stripe.Event

try {

event = stripe.webhooks.constructEvent(body, sig, process.env.STRIPE_WEBHOOK_SECRET!)

} catch {

return new Response('Bad signature', { status: 400 })

}

// 멱등 처리: event.id를 PK로 INSERT, 충돌이면 skip

const inserted = await db.webhookEvent.create({

data: { id: event.id, type: event.type, payload: body },

}).catch(() => null)

if (!inserted) return new Response('Already processed', { status: 200 })

switch (event.type) {

case 'checkout.session.completed':

await activateSubscription(event.data.object)

break

case 'invoice.payment_failed':

await enterDunning(event.data.object)

break

// ...

}

return new Response('ok', { status: 200 })

}

핵심: **event.id를 데이터베이스 PK로 저장하고, 중복이면 그냥 200을 돌려준다.** 비즈니스 로직은 그 한 번에만 돈다.

10.2 Dunning — 실패한 결제 회수의 기술

전체 SaaS 매출의 약 **5 ~ 10%가 카드 만료·한도 초과·은행 거절**로 실패한다. 이 매출을 회수하는 게 dunning이다. 회수율을 30%만 올려도 매출이 즉시 2 ~ 3% 늘어난다.

기본 시나리오:

1. 결제 실패(`invoice.payment_failed`) → 즉시 1회 재시도.

2. 24시간 후 카드 재발급 가능한지 확인(Stripe Card Updater 또는 MoR 자동 갱신).

3. 3·5·7일 후 추가 재시도(점점 늦은 시간대로 분산).

4. 7일 차에 사용자에게 이메일 — 결제 정보 갱신 링크.

5. 14일 차에 다운그레이드 또는 일시 정지.

6. 30일 차에 구독 종료.

이걸 직접 짤 수도 있고, **Stripe Smart Retries**·**Stripe Workflows**·**Retain by Paddle** 같은 호스티드 솔루션에 맡길 수도 있다. 솔로 개발자는 일단 호스티드 쪽이 무조건 낫다.

10.3 차지백·디스퓨트

차지백은 카드 소지자가 카드사에 "이 결제는 부정 사용입니다"라고 신고하는 것이다. 카드사는 가맹점(=당신 또는 MoR)에 응답 시한(보통 7 ~ 14일)을 준다.

차지백 1건 비용: 거래 금액 환불 + 디스퓨트 수수료(Stripe `$15`, Paddle 등 MoR은 보통 흡수). 차지백 비율이 1%를 넘으면 카드사가 가맹점 자격을 정지할 수 있다.

해법:

- **Stripe Radar** 또는 MoR 내장 이상거래 탐지 활성화.

- 결제 명세서 이름(statement descriptor)을 명확하게 — `ACME*SAAS` 가 `XYZ123`보다 낫다.

- 환불 정책을 명시(웹사이트·이메일 영수증 모두).

- 디스퓨트가 들어오면 24시간 안에 응답. 증거(이메일 로그·로그인 로그·IP)를 첨부.

11장 · 한국 결제 — 카드 코드 한 줄로 끝나지 않는다

11.1 한국이 어려운 이유

한국 결제는 글로벌 결제 인프라와 별도로 굴러간다. 이유:

- **한국 신용카드는 ISP/3DS 인증 흐름이 다르다**. Stripe·Paddle은 한국 발급 카드를 받지만, 본인 인증(휴대폰·계좌 인증)이 매끄럽지 않다.

- **계좌이체·간편결제** 비중이 매우 높다. 카카오페이·네이버페이·토스가 카드 결제 못지않게 흔하다.

- **현금영수증·전자세금계산서** 등 부가가치세법 요구사항이 있다.

- **VAT 신고**는 국세청 홈택스를 통해 직접 한다(MoR도 한국 VAT는 일부 한정 지원).

11.2 한국 결제 옵션

PortOne (구 아임포트, NHN KCP)

- **PortOne v2** (2024 ~ ): 통합 결제 어그리게이터. 카드·KakaoPay·NaverPay·TossPayments·PayPal·Stripe까지 하나의 API로.

- 수수료: PG사 수수료(보통 3 ~ 3.5%) + PortOne 플랫폼 수수료.

- 한국 외 신용카드도 받고 싶다 → Stripe 어댑터.

- 부가세 신고: 직접 또는 회계사.

// PortOne v2 — 결제 요청

const response = await PortOne.requestPayment({

storeId: 'store-xxx',

channelKey: 'channel-kakaopay',

paymentId: `order-${Date.now()}`,

orderName: 'Pro 플랜 월간 구독',

totalAmount: 11000,

currency: 'KRW',

payMethod: 'EASY_PAY',

easyPay: { easyPayProvider: 'EASY_PAY_PROVIDER_KAKAOPAY' },

})

if (response.code != null) {

// 결제 실패

}

TossPayments

- **단독 PG로도 작동**. 카드·계좌이체·카카오페이·네이버페이·토스결제 다 지원.

- API가 깔끔하고 문서가 좋다. 1인 개발자에게는 PortOne 어그리게이션 없이 TossPayments 단독으로도 충분한 경우가 많다.

- 결제 위젯·자체 호스티드 페이지 제공.

KakaoPay·NaverPay 직접 연동

- 가능하지만 권장되지 않는다. 각 사 가맹점 심사·계약·정산이 별도다.

- PortOne·TossPayments 어그리게이터를 거치는 게 1인 개발자에게 합리적이다.

11.3 Stripe + 한국

Stripe는 2024년 한국에서 acquiring 라이선스를 확장했고, 한국 사업자(개인사업자/법인)도 정식으로 Stripe 계정을 만들 수 있다. 그러나 **한국 카드 결제 흐름은 PortOne/TossPayments가 더 자연스럽다**. Stripe는 글로벌 카드 + USD/EUR 통화 매출에, PortOne/Toss는 한국 카드 + 간편결제에 — 둘을 병행하는 게 흔하다.

11.4 한국 SaaS의 실전 구성

- **글로벌 사용자**: Stripe Checkout 또는 Polar/Lemon Squeezy.

- **한국 사용자**: PortOne 또는 TossPayments + KakaoPay/NaverPay.

- **세금**: 한국 부가세는 직접 신고(국세청 홈택스). 글로벌 매출은 MoR이 대행 또는 Stripe Tax + 세무사.

이중 결제 분기를 코드에 두면 운영이 깔끔하다.

// 사용자 지역에 따라 결제 경로 분기

async function getCheckoutUrl(user: User, plan: Plan) {

if (user.country === 'KR') {

return await createPortOneCheckout(user, plan)

}

return await createStripeCheckout(user, plan)

}

12장 · 구독 vs 일회성 vs 사용량 기반

12.1 모델별 적합도

| 모델 | 적합 시나리오 | 적합 플랫폼 |

| --- | --- | --- |

| 일회성(One-time) | 데스크톱 앱 라이선스, eBook, 코스 | Lemon Squeezy, Gumroad, Polar |

| 구독(Subscription) | SaaS, 콘텐츠, 멤버십 | Stripe, Polar, Paddle, Lemon Squeezy |

| 사용량(Usage-based) | LLM API, 클라우드 인프라, 메시징 | Stripe Billing(meters), Polar |

| 하이브리드(Seat + Usage) | 협업 SaaS, 데이터 분석 | Stripe Billing, Paddle |

| 다년 계약(Annual + commit) | 엔터프라이즈 B2B | Paddle, Stripe Invoicing |

12.2 사용량 기반의 함정

LLM API 같은 사용량 과금은 매혹적이다("실시간으로 토큰 소비량 × 단가"). 그러나 다음 함정이 있다.

- **사용량 집계 지연**. 실시간 집계는 비싸고 1분 ~ 1시간 lag이 일반적이다. 사용자가 한도 초과를 늦게 안다.

- **예측 불가능한 청구서**. 사용자가 "이번 달 청구서가 얼마야?"를 미리 알기 어렵다. → soft limit·prepaid credit·daily cap 같은 가드가 필요.

- **무료 크레딧 어뷰즈**. 신규 가입 `$10` 크레딧 → 자동화된 어뷰즈. → 이메일 + 카드 + 전화 인증, IP rate limit.

Stripe Billing의 meters·Polar의 usage events 둘 다 비슷한 API다. 핵심은 **이벤트 ingestion + aggregation + billing** 의 3단을 어떻게 갈라 두느냐다.

12.3 가격 변경의 안전망

가격을 바꾸려고 할 때 — 이미 있는 구독자를 그대로 둘 것인가, 다음 갱신 시 새 가격으로 옮길 것인가, 즉시 prorate해서 적용할 것인가.

- **Grandfathering**(기존 사용자는 옛 가격 유지): 마음 편하지만 매출 누수.

- **Migration at renewal**(갱신 시점부터 새 가격): 사용자에게 미리 30 ~ 60일 이메일.

- **Immediate proration**(즉시 prorate): 분쟁의 원인. 권장하지 않는다.

Stripe·Polar·Paddle 모두 가격 버전을 따로 관리할 수 있게 돼 있다. 이걸 안 쓰고 가격 한 종류로 다 덮어쓰면 나중에 후회한다.

13장 · 실패 모드와 안티 패턴

자주 보는 실패들이다.

- **세금 신고를 잊는다.** 미국·EU에 매출이 있으면 한도 도달 시점부터 등록 의무가 생긴다. 한참 뒤에 과징금 + 미신고 분 일시 납부. MoR은 이걸 막아준다.

- **차지백 1%를 넘긴다.** 처음에 마케팅 욕심으로 카드 인증 약하게 두면 사기가 들어오고, 누적 1%를 넘으면 카드사가 게이트웨이를 정지한다.

- **결제 명세서 이름이 비밀스럽다.** `XYZ-123`이라고 찍히면 사용자가 차지백을 건다. 회사 도메인을 명시.

- **환불 정책이 모호하다.** "환불 불가"라고 못 박지 마라. EU에서 14일 철회권은 법이고, 미국 카드사도 환불을 강제할 수 있다. 명시적이고 합리적인 정책이 분쟁 시 가장 강한 무기다.

- **웹훅 비멱등.** 같은 결제로 두 번 라이선스를 발급해 본 적이 있는가? `event.id` PK 한 줄로 막힌다.

- **테스트 모드와 운영 모드를 섞는다.** 운영 시크릿이 git에 들어가는 사고. `STRIPE_LIVE_SECRET_KEY` 와 `STRIPE_TEST_SECRET_KEY` 를 환경별로 엄격히 분리.

- **MoR을 쓰면서 인보이스 발행자 이름을 자기 회사로 적는다.** 법적으로 위반이다. MoR을 쓰면 영수증·인보이스 발행자는 MoR이다.

14장 · 의사결정 트리

질문 1: 매출 규모는?

├─ < $5k MRR

│ └─ MoR로 시작 (Lemon Squeezy 또는 Polar)

│

├─ $5k ~ $200k MRR

│ ├─ 주 고객이 한국 → PortOne/Toss + Stripe(글로벌)

│ ├─ 주 고객이 EU/북미 → Polar (가격) 또는 Lemon Squeezy (안정성)

│ ├─ 본격 B2B (NET-30, 다년) → Paddle

│ └─ 오픈소스 후원 → Polar + GitHub Sponsors

│

└─ > $200k MRR

├─ 전담 세무 인력 있음 → Stripe DIY + Stripe Tax

└─ 전담 인력 없음 → Paddle (엔터프라이즈) 유지

질문 2: 모바일 앱인가?

├─ Web first → 위 트리

└─ Mobile first → RevenueCat + IAP. 외부 결제 우회는 신중히.

질문 3: 가격 모델?

├─ 일회성 → Lemon Squeezy/Gumroad

├─ 구독 → Stripe/Polar/Paddle

└─ 사용량 → Stripe Billing meters 또는 Polar usage events

에필로그 — 결제는 한 번 정하면 6개월을 산다

결제 인프라를 바꾸는 일은 진짜로 아프다. 사용자 카드 정보를 재입력 받아야 하고, 만료된 구독을 옮겨야 하고, 인보이스 번호 체계가 흐트러진다. 그래서 **처음 한 번 잘 정하면 1년을 안 건든다**.

좋은 소식은 2026년의 결제 인프라가 한 번도 본 적 없이 좋다는 것이다. Polar 같은 신생 MoR이 4% + `$0.40`으로 들어왔고, Stripe Workflows로 dunning을 노코드로 짠다. Stripe는 Lemon Squeezy를 인수하고도 별도 운영해 인디 해커를 안 버렸다. 한국에서는 PortOne v2가 어그리게이터의 표준이 되었다. 모바일 IAP의 30%는 여전히 아프지만, EU DMA·미국 판결로 외부 결제 통로가 열렸다.

1인 개발자용 30일 체크리스트

- [ ] 1일차: 매출 규모·고객 지역·가격 모델을 한 줄로 정의.

- [ ] 2일차: MoR vs DIY 결정. 매출 < `$5k MRR` 이면 의심 없이 MoR.

- [ ] 3 ~ 4일차: 후보 2개 선택(예: Lemon Squeezy + Polar). 동일 상품을 둘 다에 등록해 비교.

- [ ] 5일차: 결제 명세서 이름(statement descriptor) 명확화.

- [ ] 7일차: 웹훅 핸들러를 `event.id` PK 기반 멱등으로 구현.

- [ ] 10일차: dunning 시나리오 — 결제 실패 → 재시도 → 이메일 → 다운그레이드 — 를 그림으로 정리.

- [ ] 14일차: 환불 정책 페이지·이메일 영수증의 환불 링크.

- [ ] 21일차: 한국 사용자 비중 10% 이상이면 PortOne/Toss 병행.

- [ ] 30일차: 모바일 앱 출시 예정이면 RevenueCat 통합.

안티 패턴 (재정리)

- 처음부터 Stripe DIY로 가서 세무 신고를 3개월 미루다 패널티를 맞는다.

- 웹훅을 멱등하지 않게 짜고 라이선스를 두 번 발급한다.

- 모바일 앱에서 IAP 우회 욕심에 외부 결제만 두다 앱이 거절된다.

- `$50/월` 가격에 처음부터 사용량 기반을 얹어 사용자가 청구서를 못 읽는다.

- MoR 인보이스 발행자 이름을 자기 회사로 적고 EU에서 시정 명령을 받는다.

- 한국 사용자에게 Stripe만 강요해 전환율이 60% 떨어진다.

다음 글 예고

다음 글에서는 **MRR이 자라는 단계별 운영 자동화** — Stripe Workflows로 dunning을 그리고, Slack에 결제 이벤트를 흘리고, 회계 시스템(QuickBooks·Xero)에 인보이스를 동기화하는 — 실전 구성을 다룬다. 결제는 한 번 정하면 6개월을 살지만, 운영 자동화는 매주 손댄다.

참고 / References

- Stripe — https://stripe.com/

- Stripe Tax — https://stripe.com/tax

- Stripe Billing — https://stripe.com/billing

- Stripe Workflows — https://stripe.com/workflows

- Stripe Connect — https://stripe.com/connect

- Stripe Radar — https://stripe.com/radar

- Stripe acquires Lemon Squeezy (2024) — https://stripe.com/newsroom/news/stripe-acquires-lemon-squeezy

- Lemon Squeezy — https://www.lemonsqueezy.com/

- Lemon Squeezy Pricing — https://www.lemonsqueezy.com/pricing

- Polar — https://polar.sh/

- Polar Pricing — https://polar.sh/docs/pricing

- Polar on GitHub — https://github.com/polarsource/polar

- Paddle — https://www.paddle.com/

- Paddle Billing — https://www.paddle.com/billing

- Retain by Paddle — https://www.paddle.com/products/retain

- Creem — https://www.creem.io/

- Gumroad — https://gumroad.com/

- RevenueCat — https://www.revenuecat.com/

- Apple Small Business Program — https://developer.apple.com/app-store/small-business-program/

- Google Play Billing — https://developer.android.com/google/play/billing

- EU Digital Markets Act (DMA) — https://digital-markets-act.ec.europa.eu/

- 한국 전기통신사업법 개정 — https://www.law.go.kr/

- 일본 스마트폰 소프트웨어 경쟁촉진법 — https://www.jftc.go.jp/

- PortOne — https://portone.io/

- PortOne v2 SDK — https://developers.portone.io/

- TossPayments — https://www.tosspayments.com/

- KakaoPay 결제 가맹점 — https://biz.kakaopay.com/

- NaverPay 사업자 센터 — https://admin.pay.naver.com/

- 국세청 홈택스 (부가세 신고) — https://www.hometax.go.kr/

- South Dakota v. Wayfair (sales tax nexus) — https://www.supremecourt.gov/opinions/17pdf/17-494_j4el.pdf

- EU One Stop Shop (OSS) — https://vat-one-stop-shop.ec.europa.eu/