1인 창업자가 운영하는 정확한 4-API 백엔드—Stripe, Beehiiv, Resend, 그리고 Supabase—의 실제 월간 비용, 각 API의 역할, 그리고 어떤 것을 가장 먼저 결제해야 하는지에 대해 다룹니다.

대부분의 1인 창업자들은 백엔드를 과하게 구축합니다. 첫 고객이 나타나기도 전에 9개의 도구를 연결해 두고, 제품을 출시하는 시간보다 서비스들을 서로 이어 붙이는 데 더 많은 시간을 소비합니다. 진실은 더 단순합니다. 1인 SaaS를 운영하는 4-API 스택은 무엇일까요? 그것은 네 가지 작업—결제 받기, 오디언스에게 이메일 보내기, 개별 사용자에게 이메일 보내기, 그리고 로그인 기능과 함께 데이터 저장하기—으로 요약되며, 각 작업에 잘 선택된 하나의 API가 필요합니다. 이것은 대안들을 테스트하고 자리를 차지할 가치가 없는 모든 것을 쳐낸 후 선택된 500k.io의 실제 스택입니다. 가격은 2026년 중반 기준이며, 모든 벤더는 가격을 재조정하므로 결제하기 전에 실제 가격 페이지를 확인하십시오.

이 글을 끝까지 읽으면 네 가지 작업이 네 개의 API에 어떻게 매핑되는지, 세 가지 성장 단계에서의 실제 월간 비용, 작업을 재수행하지 않기 위해 연결해야 하는 순서, 그리고 운영 환경에서 창업자들을 괴롭히는 실패 모드(failure modes)를 알게 될 것입니다.

1인 SaaS 백엔드가 수행해야 하는 네 가지 작업
1인 소프트웨어 비즈니스를 해체해 보면 백엔드는 네 가지 책임으로 나뉩니다. 이 범위를 넘어 필수적이라고 마케팅되는 모든 것은 매출 발생 전이나 초기 매출 단계의 창업자에게는 시기상조입니다.

수익 창출: Stripe
Stripe는 결제 계층 (payments layer)이며, 1인 창업자에게 있어 이 선택에는 논쟁의 여지가 없습니다. Stripe의 가격 정책에 따르면, 미국 내 성공적인 카드 결제 건당 2.9% + $0.30의 수수료가 부과되며 월간 플랜 비용은 없습니다. 월 $20 구독 서비스의 경우 수수료는 $0.88, 즉 약 4.4%가 됩니다. 가격대가 낮을수록 퍼센트 비중이 크게 느껴지며, 이는 요금제 (tiers)를 설정할 때 중요한 요소가 됩니다. 창업자들이 과소평가하는 부분은 반나절이면 끝나는 체크아웃 (checkout) 과정이 아니라, 바로 웹훅 (webhooks)입니다. Stripe는 여러분이 구축하고 검증해야 하는 엔드포인트 (endpoint)로 이벤트를 전송함으로써 앱에 어떤 일이 일어났는지(결제 성공, 구독 취소, 카드 결제 실패 등)를 알려줍니다. 이 과정을 생략하면 데이터베이스는 실제 결제 중인 사용자와의 동기화가 소리 없이 어긋나게 됩니다. 체크아웃 구현에 하루를 할애했다면, 그다음 날은 웹훅 처리와 Stripe에서 'dunning'이라고 부르는 결제 실패 재시도 흐름 (failed-payment retry flow)을 구현하는 데 사용하세요. 그 두 번째 날의 작업이 바로 매출을 보호하는 작업입니다.

청중에게 이메일 발송: Beehiiv

개별 사용자에게 이메일 발송: Resend
Resend는 트랜잭션 계층 (transactional layer)입니다. 즉, 환영 이메일, 매직 링크 (magic links), 비밀번호 재설정, 영수증과 같이 여러분의 코드에 의해 트리거되는 '한 명의 사용자에게 보내는 한 통의 메시지'를 담당합니다. Resend의 가격 정책에 따르면, 무료 티어는 월 3,000통의 이메일을 제공하되 일일 100통으로 제한되며, Pro 플랜은 월 $20에 50,000통의 이메일을 제공합니다. 여기서 일일 100통 제한이 함정입니다. 사이드 프로젝트에는 관대하지만, 실제 가입자가 발생하는 주간에는 즉시 너무 적은 양이 되므로, 출시 도중이 아니라 출시 전에 업그레이드할 계획을 세워야 합니다. 타협할 수 없는 필수 설정 단계는 도메인 인증 (domain authentication)입니다. 즉, 발송 도메인에 SPF, DKIM, DMARC 레코드를 설정하는 것입니다. 이를 생략하면 매직 링크가 스팸함으로 들어가게 되며, 이는 사용자에게 "이 제품은 고장 났다"라는 인상을 줍니다. Resend가 1인 개발자들에게 선택받는 이유는 개발자 경험 (developer experience) 때문입니다. React 기반의 템플릿, 깔끔한 API, 그리고 이메일 반송 (bounce) 발생 시 실제로 읽을 수 있는 로그를 제공합니다.

데이터 및 로그인 저장: Supabase
Supabase는 데이터 및 인증 (auth) 레이어입니다. 하나의 API 뒤에 Postgres, 인증 (authentication), 그리고 파일 스토리지 (file storage)가 통합되어 있습니다. Supabase의 가격 정책에 따르면, 무료 티어(free tier)에는 500MB의 데이터베이스, 50,000명의 월간 활성 사용자 (MAU), 그리고 2개의 프로젝트가 포함됩니다. Pro 플랜은 프로젝트당 월 $25이며, 8GB의 데이터베이스와 100,000명의 MAU를 제공합니다. 1인 창업자에게 이는 세 개의 별도 서비스를 하나로 대체해 주는데, 이것이 바로 핵심입니다. 즉, 연결하고, 모니터링하고, 비용을 지불해야 할 구성 요소가 줄어든다는 것입니다. 시작하기 전에 알아두어야 할 두 가지가 있습니다. 무료 티어는 일주일 동안 활동이 없으면 프로젝트를 일시 중지하므로, 한적한 사이드 프로젝트는 잠들게 되고 첫 방문자는 에러를 마주하게 됩니다. 그리고 행 수준 보안 (Row Level Security, RLS) — 누가 어떤 행을 읽을 수 있는지 결정하는 규칙 레이어 — 은 1인 창업자들이 데이터 유출을 일으키는 가장 흔한 원인입니다. 출시 후가 아니라, 첫날부터 RLS를 설정하세요.

이 스택의 실제 비용, 3단계별 분석
위에서 언급한 주요 수치들은 플랜 가격입니다. 중요한 수치는 당신의 단계에서 실제로 얼마를 지불하느냐, 그리고 어떤 API가 첫 청구서를 발생시키느냐입니다.

0단계 — 수익 발생 전: 월 $0

2단계 — 확장 단계: 월 약 $130의 하한선

각 API가 한계에 부딪히는 지점 (아무도 경고해주지 않는 부분들)
플랜 가격은 비교하기 쉽습니다. 하지만 당신의 주말을 앗아갈 실패 사례들은 그 어떤 가격 페이지에도 나와 있지 않습니다.

트랜잭션 이메일 (transactional email) 대 마케팅 이메일 (marketing email) 실수

Supabase의 두 가지 무료 티어 함정
Supabase의 무료 티어(free tier)는 관대하지만, 두 가지 기본 설정이 창업자들을 함정에 빠뜨립니다. 첫째, 무료 프로젝트는 일주일 동안 활동이 없으면 일시 중지됩니다. 바쁜 앱이라면 괜찮겠지만, 활동이 뜸해진 사이드 프로젝트(side project)에게는 정말 큰 문제입니다. 다음 방문자가 일시 중지된 데이터베이스를 마주하게 되면, 마치 제품이 망한 것처럼 보이는 에러를 보게 되기 때문입니다. 프로젝트가 중요하다면, 월 25달러인 Pro 티어를 통해 일시 중지를 제거할 수 있습니다. 둘째, 더 심각한 문제입니다. 특정 흐름을 통해 생성한 테이블에서는 행 레벨 보안 (Row Level Security, RLS)이 기본적으로 꺼져 있습니다. RLS는 어떤 사용자가 어떤 행을 읽을 수 있는지를 결정하는 핵심 요소입니다. 이를 설정하지 않고 배포하면, 인증된 사용자라면 누구나 다른 모든 사람의 데이터를 쿼리할 수 있는 경우가 많습니다. 이는 다른 누군가가 알아차리기 전까지는 인지하지 못하는 조용한 데이터 유출이 됩니다. 해결책은 초기에 처리하면 비용이 거의 들지 않습니다. 노출될 실제 데이터가 쌓이기 전인 첫날에 RLS를 활성화하고 액세스 정책 (access policies)을 작성하세요.

Stripe 웹훅 (webhooks): 모두가 건너뛰는 절반
Stripe Checkout는 창업자들이 완성하는 절반이고, 웹훅 (webhooks)은 그들이 건너뛰는 나머지 절반입니다. 하지만 바로 이 절반이 여러분의 기록을 정확하게 유지해 줍니다. Checkout은 결제를 처리하지만, 앱에 액세스 권한을 부여하거나, 결제 실패를 표시하거나, 취소된 플랜을 회수하도록 명령하는 것은 바로 웹훅 이벤트(webhook events) — checkout.session.completed, invoice.payment_failed, customer.subscription.deleted — 입니다. 검증된 웹훅 처리가 없다면, 여러분의 데이터베이스는 실제로 결제 중인 사람과 서서히 동기화가 어긋나기 시작합니다. 사용자는 구독을 취소한 후에도 액세스 권한을 유지하고, 결제 실패는 인지되지 않으며, 여러분의 매출 수치는 Stripe 대시보드와 일치하지 않게 됩니다. 함정은 테스트 단계에서는 모든 것이 정상적으로 보인다는 점입니다. 왜냐하면 '해피 패스 (happy path, 정상 경로)'만 테스트했기 때문입니다. 문제는 프로덕션 환경의 예외 케이스(edge cases) — 갱신 거절, 차지백 (chargeback), 주기 중간의 취소 — 에서 발생합니다. 결제 시스템 구축 첫날부터 웹훅 처리를 구현하고, 위조된 요청이 무료 액세스를 허용할 수 없도록 모든 이벤트의 서명 (signature)을 검증하세요.

500k.io가 이 스택을 구축한 방식
이것은 우리가 읽기만 한 스택이 아닙니다. 500k.io의 밑단에서 실제로 돌아가고 있는 스택이며, 우리가 구축한 순서 덕분에 실제 재작업을 피할 수 있었습니다.

재작업을 피하는 빌드 순서
우리는 백투프론트(back-to-front) 방식으로 연결했습니다. 데이터와 인증(auth)을 먼저, 결제(payments)를 그다음, 이메일(email)을 마지막으로 배치했습니다. Supabase는 첫날 바로 도입했는데, 다른 모든 구성 요소가 이를 읽어오기 때문입니다. 연결할 사용자 기록이 생성되기도 전에 영수증을 보내거나 유료 기능을 부여하는 것은 의미가 없습니다. 그다음은 Stripe였습니다. 웹훅(webhooks)이 구독 상태를 Supabase에 직접 기록하도록 하여, "누가 결제 중인가"라는 정보가 한 곳에 머물게 했습니다. 이메일은 마지막에 배치했습니다. Beehiiv와 Resend 모두 앞선 두 계층이 생성하는 이벤트에 의해 트리거되기 때문입니다. 예를 들어, 새로운 행(row)이 생성되면 환영 이메일이 트리거되고, Stripe 웹훅이 발생하면 영수증이 트리거됩니다. 이러한 순서로 구축함으로써, 각 계층을 추가할 때마다 연결할 수 있는 실제 대상이 존재하게 되었습니다. 기록 시스템(system of record)을 먼저 연결하고, 돈을 그다음, 메시지를 마지막으로 연결하세요. 이 순서를 거꾸로 하면 연결 작업을 두 번 반복하게 됩니다.

다르게 했을 점
지나고 보니 두 가지가 떠오릅니다. 첫째, Resend의 도메인 인증(domain authentication)을 너무 늦게 설정하여, 매직 링크(magic links)가 스팸함으로 빠지는 대가를 치렀습니다. 이는 실제로는 세 개의 DNS 레코드가 누락된 문제임에도 불구하고, 사용자들에게는 제품이 고장 난 것처럼 보일 수 있는 종류의 버그입니다. Resend 계정을 생성한 직후에 SPF, DKIM, DMARC를 설정해야지, 출시 일주일 뒤로 미루지 마세요. 둘째, 초기에는 데이터베이스 자체가 아닌 애플리케이션 코드에 의존하여 데이터를 제어함으로써 Supabase의 행 수준 보안(Row Level Security, RLS)을 충분히 활용하지 못했습니다. 이는 체크 과정을 하나라도 놓치면 노출되어서는 안 될 행이 드러날 때까지는 작동합니다. 첫날부터 규칙을 RLS로 밀어 넣었다면 코드 양도 줄이고 공격 표면(attack surface)도 더 작게 유지할 수 있었을 것입니다. 두 실수 모두 초기에 수정하는 데 비용이 많이 들지는 않았지만, 데이터 유출 후에 수정하려면 매우 고통스러웠을 것입니다. 여러분의 설정은 다를 것이므로, 이를 절대적인 법칙이 아닌 테스트해야 할 기본값으로 취급하십시오.

이번 주에 직접 구축해 보세요
서두르지 않고도 일반적인 업무 주간 내에 네 가지 API를 모두 구축할 수 있습니다. 그 순서는 다음과 같습니다.

1-2일 차: 데이터 (data), 인증 (auth), 결제 (payments)
Supabase로 시작하세요: 프로젝트를 생성하고, 핵심 테이블을 모델링하며, 실제 데이터가 존재하기 전에 행 레벨 보안 (Row Level Security, RLS)을 활성화하고 액세스 정책 (access policies)을 작성합니다. 그다음 인증 (authentication)을 연결하세요. Supabase의 내장 인증은 이메일, 매직 링크 (magic link), OAuth를 지원하므로 별도의 제공업체가 거의 필요하지 않습니다. 그런 다음 Stripe를 추가합니다: 요금제별로 체크아웃 (Checkout)을 구축한 다음, 즉시 웹훅 (webhook) 엔드포인트를 구축하고 검증하여 주요 이벤트가 구독 상태를 Supabase에 다시 기록하는 함수 (functions)를 가리키도록 설정합니다. 이틀 차가 끝날 때쯤이면 Stripe 대시보드에 접속하지 않고도 사용자를 생성하고, 테스트 결제를 진행하며, 해당 결제가 데이터베이스에 반영되는 것을 확인할 수 있어야 합니다. 가입부터 유료 상태 전환까지 완전히 자동화된 이 왕복 과정 (round-trip)은 제품 전체의 중추이며, 이메일을 단 하나라도 추가하기 전에 제대로 구축할 가치가 있습니다.

3-5일 차: 이메일 (email) 및 출시 (go live)
데이터와 자금이 흐르기 시작하면, 두 가지 이메일 레이어를 추가합니다. Resend 계정을 생성하고, 같은 시간 내에 발송 도메인에 SPF, DKIM, DMARC를 설정하세요. 이 단계는 트랜잭션 메일 (transactional mail)이 받은 편지함에 도착할지 아니면 스팸함으로 갈지를 결정하는 단계입니다. 핵심 트랜잭션 이메일(환영 메일, 매직 링크, 영수증)을 앞선 두 레이어에서 이미 생성되는 이벤트로부터 발송되도록 연결합니다. 그런 다음 오디언스 (audience) 측면을 위해 Beehiiv를 연결하세요: 가입 양식을 삽입하고 신규 사용자를 리스트로 파이프라인 연결하여 첫날부터 오디언스 구축이 시작되도록 합니다. 마지막 날은 실패 경로 (unhappy paths)를 테스트하는 데 시간을 쓰세요. 결제 실패, 구독 취소, 오타가 포함된 주소로의 재설정 요청 등을 테스트해야 합니다. 왜냐하면 바로 그 지점이 프로덕션 환경에서 이 스택이 무너지는 지점이기 때문입니다. 그 후 출시하세요. 이 핵심 스택을 둘러싼 더 넓은 도구 세트에 대해서는, 1인 기업을 위한 최고의 AI 도구 (best AI tools for solopreneurs)와 최소 기능 AI 스택 (minimum viable AI stack)을 참조하세요.

결합된 스택

백엔드를 이토록 작게 유지하는 목적은 비즈니스를 실제로 성장시키는 부분, 즉 제품과 오디언스에 주의를 집중할 수 있도록 하기 위함입니다. 500k.io는 첫 유료 사용자가 발생하여 연간 반복 매출 (ARR) 50만 달러에 도달할 때까지 스택이 스트레스 테스트를 거치는 동안, 실제 인보이스 (invoices)와 함께 실시간으로 구축되는 과정을 기록합니다.