LabHub

블로그

2026 1인 개발자·마이크로 SaaS 결제 인프라 — Stripe·Lemon Squeezy·Polar·Paddle·Creem 심층 비교

2026-05-14 · 45 분 읽기 · #payments#stripe#lemon-squeezy#polar#paddle#merchant-of-record#saas-billing#solo-dev#micro-saas#international

한국어English日本語

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

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* 같은 이름이 찍힌다. 당신 회사 이름이 아니다.

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

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

1.2 Stripe는 PSP다 — MoR이 아니다

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

핵심은 이거다. 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 이름
이상거래·KYCStripe 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 — 가장 최소 형태의 결제 시작
import Stripe from 'stripe'
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년 기준 다음을 해준다.

Stripe Tax가 안 해주는 것:

비용: 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를 쓰던 사람은 계속 쓰면 된다.

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

3.1 포지셔닝

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

가격(2026년 5월 기준):

// Lemon Squeezy — Checkout 링크 생성
import { lemonSqueezySetup, createCheckout } from '@lemonsqueezy/lemonsqueezy.js'

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 강점

3.3 약점

3.4 언제 쓰나

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

4.1 포지셔닝

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

가격(2026년 5월 기준):

// Polar — Checkout 세션 생성
import { Polar } from '@polar-sh/sdk'

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 강점

4.3 약점

4.4 언제 쓰나

5장 · Paddle — OG Merchant of Record

5.1 포지셔닝

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

가격(2026년 5월 기준):

// Paddle Billing — v2 SDK Checkout 오픈
import { initializePaddle } from '@paddle/paddle-js'

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 강점

5.3 약점

5.4 언제 쓰나

6장 · Creem — 유럽 신생 MoR

6.1 포지셔닝

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

가격(2026년 5월 기준):

6.2 강점

6.3 약점

6.4 언제 쓰나

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

7.1 포지셔닝

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

가격(2026년 5월 기준):

7.2 강점

7.3 약점

7.4 언제 쓰나

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

8.1 안드로이드·iOS의 강제

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

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

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

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

현실 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으로 구독 구매
import 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 가정

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

항목Stripe DIYLemon SqueezyPolarPaddle
결제 수수료$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 에서 다시 보면

항목Stripe DIYLemon SqueezyPolarPaddle
결제 수수료약 $1,950약 $3,335약 $2,667약 $3,335
Stripe Tax$250포함포함포함
세무 운영(전담 직원 일부)약 $1,500000
월 총 비용약 $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 손익분기점 — 한 줄 요약

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

10.1 웹훅은 반드시 멱등하게

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

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

// Next.js Route Handler — Stripe webhook idempotent 처리
import { headers } from 'next/headers'
import Stripe from 'stripe'
import { db } from '@/lib/db'

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%를 넘으면 카드사가 가맹점 자격을 정지할 수 있다.

해법:

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

11.1 한국이 어려운 이유

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

11.2 한국 결제 옵션

PortOne (구 아임포트, NHN KCP)

// PortOne v2 — 결제 요청
import PortOne from '@portone/browser-sdk/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

KakaoPay·NaverPay 직접 연동

11.3 Stripe + 한국

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

11.4 한국 SaaS의 실전 구성

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

// 사용자 지역에 따라 결제 경로 분기
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)엔터프라이즈 B2BPaddle, Stripe Invoicing

12.2 사용량 기반의 함정

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

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

12.3 가격 변경의 안전망

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

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

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

자주 보는 실패들이다.

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일 체크리스트

안티 패턴 (재정리)

다음 글 예고

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

참고 / References

댓글

아직 댓글이 없습니다.

로그인하면 댓글을 쓸 수 있습니다