솔로 파운더의 최소 실행 시스템: 웹사이트, 제품, 결제, 데이터, 자동화

launch-checklist.md를 열어 봅니다. /pricing 페이지는 있지만 Stripe Product가 없습니다. 로그인은 되지만 구독 상태가 동기화되지 않습니다. GA4에는 page_view가 들어오지만 결제 버튼 클릭 이벤트가 없습니다. 피드백 폼은 이메일을 보내지만 작업을 만들지 않습니다.

많은 인디 개발자는 “작동한다”를 출시 기준으로 삼습니다. 하지만 유료 고객의 권한을 여전히 수동으로 열어 줘야 하거나 무료 한도를 넘은 뒤에야 사용량을 확인하면 빠진 연결 고리가 드러납니다.

솔로 파운더의 최소 실행 시스템은 도구가 적다고 실행 가능한 것이 아닙니다. 사용자가 들어오고, 제품을 받고, 결제하고, 권한을 얻고, 유용한 데이터를 만들고, 피드백을 보내며, 문제가 생겼을 때 도움을 받는 데까지 사업 동작이 이어져야 합니다.

먼저 아래 표로 전달이 끊긴 지점을 찾습니다. 그런 다음 최소 버전이 필요한 계층과 나중으로 미룰 계층을 결정합니다.

출시 전에 닫아야 할 인터페이스 검수표

기능이 모두 존재하는지가 아니라 각 사업 동작이 끝까지 실행되는지가 검수 기준입니다. 출시 전날에 Stripe webhook, Supabase RLS, GA4 이벤트를 추가하는 경우가 많은 이유는 초기에 “페이지가 보이는가”만 확인하고 결제, 권한, 데이터, 피드백의 연결을 설계하지 않았기 때문입니다.

출시 전에 다음 인터페이스를 실제로 검증해야 합니다.

검수 모듈	닫아야 할 인터페이스	자주 빠지는 항목	검수 동작
웹사이트 진입	페이지 접근, 404 없는 경로, 정적 자산 로딩, 빌드 횟수 모니터링	Cloudflare Free 빌드 한도 초과, 읽는 사람이 없는 오류 로그	실제 기기로 홈과 가격 페이지를 열고 Cloudflare Pages 빌드 기록 확인
제품 형태	콘텐츠, 도구, SaaS 중 형태가 명확하고 가격 페이지에 가격 표시	소개만 있고 가격이나 구매 진입점이 없음, Stripe Product 미생성	Stripe Dashboard의 Products/Prices와 /pricing의 가격 확인
결제 흐름	Checkout Session, webhook, 결제 후 권한, 실패와 취소 처리, 구독 동기화	webhook 없음, 결제 후 권한 미부여, 환불 후 상태 미갱신	테스트 결제 후 webhook 로그와 구독 테이블 확인
사용자 시스템	로그인, RLS, 사용자 테이블의 구독 상태, 무료·유료 권한 구분	로그인 버튼만 있고 RLS 없음, 모든 사용자가 유료 콘텐츠 접근	로그인 후 Supabase subscriptions를 확인하고 무료 계정으로 RLS 검증
데이터 이벤트	GA4/GSC, 5–8개 사업 이벤트, 결제·가입·체험 추적, 오류 알림	page_view만 있고 결제 버튼과 가입 완료 이벤트 없음	GA4 DebugView에서 이벤트를, GSC Performance에서 검색어와 페이지를 확인
피드백 회수	피드백 제출, 작업 전환, 고객지원 응답	이메일만 보내고 작업 보드나 후속 흐름이 없음	피드백을 제출해 작업 보드 또는 이메일 대기열에 들어가는지 확인
자동화 경계	Webhook/API/Cron 사용량 경계, 오류 알림, 롤백	자동 작업이 조용히 실패하고 한도 초과 뒤에야 발견	Workers 사용량을 확인하고 경계값과 오류 모니터링 설정
비용 모니터링	Cloudflare/Supabase 사용량 기록, 무료 한도, 초과 계획	비활성 Supabase 프로젝트 일시 중지, Workers 한도 사후 발견	사용량과 프로젝트 활동을 확인하고 업그레이드 조건 기록

각 항목은 저장소의 설정 파일만 보는 것이 아니라 실제로 실행해야 합니다. 출시 전에는 최소 한 번의 전체 결제, 로그인과 권한 검증, 이벤트 추적, 피드백 제출을 완료합니다.

웹사이트 진입 계층: 최소 배포 스택과 경계

첫 계층은 정적 사이트나 가벼운 프레임워크로 시작할 수 있지만 빌드 수, 파일 수, 동적 함수는 비용표에 포함해야 합니다. Cloudflare Pages와 Astro는 초기 유지보수를 줄여 주지만 무료 한도는 아키텍처 보장이 아닙니다.

기술 스택 선택표

제품 형태	권장 스택	빌드 비용	동적 함수 비용	적합한 경우
콘텐츠 사이트	Astro / Hugo / Hexo	Cloudflare Pages Free: 500 builds/month, 20,000 files, 25 MiB asset	Pages Functions는 Workers에 포함	블로그, 문서, SEO 콘텐츠, 제품 소개
도구 사이트	Astro + API 호출	위와 동일	API 호출은 Workers에 포함: 100,000 requests/day	단일 페이지 도구, 조회, 계산, 시각화
SaaS	Astro + Supabase	위와 동일	Workers + Supabase Edge Functions	다중 사용자, 구독, 권한, 데이터 읽기와 쓰기

2026년 7월 26일 기준 Cloudflare Pages 공식 제한은 Free 플랜에서 월 500회 빌드, 빌드당 20분 timeout, 최대 20,000개 파일, 자산당 최대 25 MiB입니다. Pages Functions 요청은 Workers 한도에 포함되며 Workers Free는 하루 100,000회 요청과 호출당 10 ms CPU를 제공합니다.

정적 자산 요청이 무료라고 전체 시스템의 비용이 사라지는 것은 아닙니다. 이미지, 동영상, 다운로드 파일이 많다면 오브젝트 스토리지, CDN, 변환, 송신 트래픽도 따로 계산해야 합니다.

AI 대량 생성에만 의존하면 안 되는 이유

Google Search의 생성형 AI 콘텐츠 가이드는 AI를 독창적인 콘텐츠의 조사와 구성에 활용할 수 있다고 설명합니다. 그러나 사용자에게 추가 가치가 없는 페이지를 대량 생성하면 scaled content abuse에 해당할 수 있습니다. 실제 제품, 실제 피드백, 실제 분석 없이 SEO 페이지 수백 개만 자동 생성해서는 안 됩니다.

성능 최적화는 Astro 5 성능 최적화 실전을 참고할 수 있습니다. 최소 시스템은 Lighthouse 100점부터 목표로 할 필요가 없습니다. 페이지 접근, 자산 로딩, CTA 동작, 빌드 실패 알림부터 보장합니다.

제품 계층: 콘텐츠, 도구, SaaS 중 첫 버전의 선택

제품 형태는 결제, 사용자, 데이터, 자동화의 복잡도를 결정합니다. 콘텐츠, 도구, SaaS는 같은 수준의 선택지가 아니라 복잡도가 점차 높아지는 단계입니다. 첫 버전은 익숙한 기술, 단순한 결제, 적은 사용자 데이터가 필요한 형태를 우선합니다.

제품 형태 판단표

제품 형태	기술 복잡도	결제 복잡도	사용자 데이터	첫 버전 적합도
콘텐츠	낮음: 정적 + CMS + SEO	낮음: 일회성 결제 또는 무료	낮음: 이메일, RSS, 댓글	높음: SEO 유입, 콘텐츠 수익화, 수요 검증
도구	중간: 정적 + API + 경량 백엔드	중간: 일회성 또는 구독	중간: 가벼운 사용자 시스템과 사용 기록	중간: 핵심 기능과 과금 방식 검증
SaaS	높음: 인증 + 데이터베이스 + 구독 + RLS	높음: 구독, 사용량 과금, 환불	높음: 다중 사용자, 권한, 구독, 데이터 격리	낮음: 유료 수요와 익숙한 기술 스택이 이미 존재할 때

판단 기준

첫 버전의 형태는 세 가지로 결정합니다.

1. 기술 스택 숙련도: Astro나 Hugo에 익숙하면 콘텐츠로 빠르게 검증할 수 있습니다. Supabase나 Postgres에 익숙할수록 도구와 SaaS의 구현 위험이 낮아집니다.
2. 결제 복잡도: 일회성 결제가 구독보다 단순하고, 구독은 사용량 과금보다 단순합니다. 첫 버전은 일회성 결제나 무료 연락처 수집으로 시작할 수 있습니다.
3. 사용자 데이터 필요성: 콘텐츠는 이메일과 RSS만 필요할 수 있습니다. 도구는 사용 기록이, SaaS는 신원, 권한, 구독 상태, 데이터 격리가 필요합니다.

제품 형태는 정체성이 아닙니다. 핵심 동작 하나가 안정적이지 않다면 계정 센터, 팀 공간, 템플릿 마켓부터 만들지 않습니다.

결제 계층: 마지막에 붙이는 버튼이 아니라 데이터 구조를 바꾸는 요소

결제는 최소 시스템에서 위험이 가장 큰 계층입니다. 데이터베이스, 사용자, 권한, 관리자 화면, 이메일 알림까지 거꾸로 영향을 줍니다. Stripe Checkout으로 돈을 받더라도 webhook이 권한을 열지 않거나 환불 뒤 상태가 갱신되지 않거나 구독 종료 뒤 접근이 유지되면 실제 이행 문제가 됩니다.

결제 흐름 단계

Stripe의 최소 폐쇄형 결제 흐름은 다음과 같습니다.

단계	Stripe 객체	닫아야 할 인터페이스	자주 빠지는 항목
1. 제품 생성	Products	Stripe Dashboard에 만들고 가격 페이지에 표시	/pricing에 가격은 있지만 Stripe Product가 없음
2. 가격 생성	Prices	금액, 통화, 주기, 일회성·구독·사용량 모델 설정	구독에 interval이 없고 사용량 과금에 meter가 없음
3. Checkout Session 생성	Checkout Session	line_items, mode, success_url, cancel_url 설정	success_url이 결제 상태 검증 없이 이동만 함
4. webhook 설정	Webhook endpoint	checkout.session.completed, invoice.paid, customer.subscription.deleted 등 수신	webhook이 없고 결제 뒤 권한도 열리지 않음
5. 이행 처리	사용자 정의 로직	결제 뒤 데이터베이스 권한 활성화와 확인 이메일	수동 활성화에 의존하고 추적 기록이 없음
6. 환불 처리	Refunds	구독 상태 갱신, 권한 회수, 환불 알림	환불 뒤에도 상태와 접근이 유지됨
7. 구독 상태 동기화	Subscriptions	갱신, 취소, 만료 시 상태 갱신	만료 확인이 없고 권한도 회수되지 않음

결제 모델 판단표

결제 모델은 데이터 구조를 바꿉니다.

결제 모델	데이터 구조 영향	권한 관리	적합한 경우
일회성 결제	사용자에 paid_at 또는 purchase_id 추가	한 번 열고 영구 또는 기한부 접근	디지털 제품, 강의, 템플릿, 도구 구매
구독	subscriptions 생성: user_id, stripe_subscription_id, status, current_period_end	주기별 활성화와 회수, 상태 동기화	도구, SaaS, 회원 콘텐츠
사용량 과금	usage 생성: user_id, meter, amount, timestamp	사용량에 따라 열고 제한하며 잔액 관리	API, 클라우드 저장 공간, 컴퓨팅

Stripe의 Products/Prices 모델에서는 새 Price를 만들고 lookup key를 옮길 수 있습니다. 애플리케이션이 lookup key로 가격을 조회하면 여러 위치에 Price ID를 고정하지 않아도 되지만 가격 변경은 공식 절차에 따라 새 가격을 생성하고 활성화해야 합니다.

이행, 환불, 구독 동기화에는 webhook과 데이터베이스 로직이 필요합니다. 프런트엔드 성공 페이지나 Dashboard 수동 작업에 의존하지 않습니다. 더 자세한 설계는 솔로 파운더 결제 시스템 선택에서 확인할 수 있습니다.

테스트 결제 검증 절차

출시 전에 Stripe 테스트 환경에서 전체 결제를 완료합니다.

1. Stripe Dashboard에서 테스트 환경을 사용합니다
2. Stripe의 최신 문서가 안내하는 성공, 실패, 추가 인증 테스트 방식을 사용합니다
3. Checkout에 테스트 정보를 입력하고 결제를 완료합니다
4. Payments와 Events 로그에서 예상 이벤트를 확인합니다
5. 데이터베이스의 subscriptions 또는 권한 기록이 동기화됐는지 확인합니다
6. 권한이 있는 계정으로 로그인한 뒤 권한이 없는 계정으로 접근 경계를 검증합니다

테스트가 끝나면 운영 환경의 키, webhook endpoint, 이벤트 서명, 알림을 별도로 확인합니다.

사용자 계층: 신원, 권한, 구독 상태를 구분해야 합니다

사용자 계층은 로그인 버튼 하나가 아닙니다. 최소 시스템은 신원, 권한, 구독 상태, 데이터 접근 경계를 구분합니다. 로그인이 되는데 모든 사용자가 유료 데이터를 읽을 수 있다면 로그인 컴포넌트가 아니라 인가 설계의 문제입니다.

Supabase Auth는 비밀번호, magic link, OTP, 소셜 로그인, SSO 등을 처리합니다. JWT와 데이터베이스 RLS가 함께 인가 경계를 만듭니다. 인증은 “누구인가”에 답하고 RLS policy는 “어떤 행을 읽고 쓸 수 있는가”를 결정합니다.

최소 사용자 시스템 체크리스트

사용자 기능	Supabase 기능	닫아야 할 인터페이스	자주 빠지는 항목
신원 인증	비밀번호, magic link, OTP, 소셜 로그인, SSO	로그인, JWT, 자기 데이터 접근	로그인 버튼만 있고 인가 경계가 없음
권한 관리	RLS	각 사용자는 자기 데이터만, 유료 사용자는 유료 콘텐츠에 접근	RLS 미활성화 또는 지나치게 넓은 policy
구독 상태 동기화	Stripe webhook → subscriptions	성공, 갱신, 취소, 만료 때 상태 갱신	상태가 Stripe에만 남음
데이터 접근 경계	RLS policy	사용자는 자기 행만, 관리자는 별도 권한 경로 사용	격리를 테스트하지 않아 다른 사용자 데이터가 노출됨

Supabase 프로젝트는 Postgres를 기반으로 Auth, Storage, Realtime, Edge Functions가 함께 작동합니다. 구독 상태는 신뢰할 수 있는 백엔드에서 동기화해야 하며 프런트엔드가 유료 권한을 직접 결정해서는 안 됩니다.

최소 두 계정으로 RLS를 검증합니다. 하나는 권한이 있고 다른 하나는 없어야 합니다. service role이나 다른 고권한 키가 브라우저에 노출되지 않는지도 확인합니다.

데이터 계층: 통계 스크립트 하나가 아니라 5–8개 사업 이벤트

GA4나 통계 스크립트를 설치했다고 데이터 계층이 완성되지는 않습니다. 최소 데이터 계층은 방문, 클릭, 핵심 동작, 가입, 결제, 오류, 피드백을 다루는 5–8개의 의사결정용 이벤트가 필요합니다.

사업 이벤트 목록

사업 이벤트	GA4 이벤트 이름	발생 시점	분석 목적
페이지 방문	page_view	페이지 로드	콘텐츠 진입과 SEO 유입 분석
결제 버튼 클릭	begin_checkout 또는 사용자 정의 이벤트	구매 또는 구독 버튼 클릭	전환 퍼널과 가격 페이지 효과
가입 완료	sign_up	사용자 가입 완료	가입 전환율과 유입 효과
체험 시작	사용자 정의 trial_start	무료 체험 시작	체험 전환과 경험 개선
결제 완료	purchase	백엔드가 결제 성공 확인	매출 분석과 결제 흐름 개선
오류와 충돌	사용자 정의 error_occurred	프런트엔드, API, 핵심 동작 실패	오류 모니터링과 안정성
피드백 제출	사용자 정의 feedback_submit	피드백 또는 문제 제출	피드백 비율과 문제 분류

GA4에서는 사업상 중요한 동작을 key event로 지정할 수 있습니다. Realtime과 DebugView는 수집 검증에 쓰며 실제 분석에서는 이벤트 매개변수, 출처, 중복 제거도 확인해야 합니다.

데이터 검토 절차

출시 뒤 적어도 주 1회 검토합니다.

1. GA4: 사업 이벤트 확인: DebugView에서 수집을 검증하고 보고서에서 방문, 가입, 체험, 결제 경로를 확인합니다.
2. GSC: 검색어와 페이지 확인: Performance 보고서에서 클릭, 노출, CTR, 평균 순위, 검색어, 페이지를 봅니다.
3. 제품 분석: 더 세밀한 데이터의 필요성 판단: GA4 집계로 특정 사용자가 무엇을 몇 번 했고 어디서 이탈했는지 알 수 없을 때 PostHog 같은 도구를 추가합니다.

아직 매출이 없어도 GSC, 로그, 오류 알림은 유용합니다. 검색어, 가격 페이지 마찰, 핵심 동작 실패, 반복 오류를 드러냅니다. 유료 사용자가 생긴 뒤 수집을 추가하면 이전 실패 원인은 복원할 수 없습니다.

자동화 계층: 첫날 가치가 있는 것과 위험을 키우는 것

일부 자동화는 안전한 반복을 줄이고, 일부는 실패할 때 피해를 확대합니다. AI 코딩 도구는 개발을 빠르게 하지만 결제, 권한, 보안, 사업 데이터 검수를 대신하지 않습니다.

Codex 같은 coding agent는 저장소 이해, 구현, 리뷰, 디버깅, 테스트, 마이그레이션을 돕습니다. 이는 개발 협업 계층입니다. 결제 이행, 접근 경계, 운영 비밀, 사용량 알림, 피드백은 여전히 담당자가 검수해야 합니다.

자동화 경계 판단표

자동화	첫날의 가치	추가 위험	사용량 경계
배포	Git push 뒤 자동 빌드와 배포	빌드 한도 초과, 실패 알림 없음	Pages 빌드 횟수와 timeout
알림	결제 → 권한 → 확인 메시지	webhook 재시도 없음, 알림과 권한 불일치	Workers 요청, CPU, 재시도
백업	핵심 데이터 내보내기, 유료 플랜의 백업 활성화	Free는 자동 백업 미포함, 내보내기 실패를 발견하지 못함	데이터베이스 크기, 저장 공간, 복원
정기 분석	GA4/GSC 내보내기와 보고서 생성	과도한 빈도, API 한도와 지연 무시	GA4/GSC API quota
복잡한 오케스트레이션	결제 → 권한 → 이메일 → CRM 흐름 관찰 가능	한 단계가 전체를 중단, 멱등성과 롤백 없음	단계별 실패율, 재시도, dead letters
다중 의존성	Webhook, API, Cron, 이메일, CRM 연결	지연이 다르고 통합 로그가 없음	동적 요청, 대기열, 외부 API

Webhook, API, Cron 경계값

Webhook, 가벼운 API, Cron은 Cloudflare Workers에서 실행할 수 있지만 현재 제한을 비용표에 넣어야 합니다.

• Workers Free: 100,000 requests/day, 10 ms CPU/invocation.
• Workers Paid: 계정당 월 US$5부터 시작하며 Standard에 10M requests/month와 30M CPU ms/month가 포함되고 초과분은 사용량에 따라 청구됩니다.

정적 자산과 동적 Worker 요청은 규칙이 다릅니다. “무료 요청 수” 하나가 아니라 요청, CPU, 재시도, 로그, KV, Queues, R2와 연관 제품 비용을 함께 모니터링합니다.

배포 알림, 결제 확인, 피드백 전달, 정기 요약은 좋은 초기 자동화입니다. 자동 환불, 운영 데이터 삭제, 권한 변경, 대량 메시지, 자동 가격 변경은 감사, 멱등성, 롤백을 검증할 때까지 사람의 승인을 유지합니다.

비용 경계값: 무료 한도는 아키텍처 보장이 아닙니다

무료 한도는 초기 예산입니다. Cloudflare와 Supabase의 경계는 동적 요청, CPU, 저장 공간, egress, 빌드, 로그, 사용 패턴에 따라 달라집니다. “영구 무료”나 고정 사용자 수를 보장하지 않습니다.

비용과 제한 비교표

서비스	무료 한도	유료 시작 또는 업그레이드	변경 위험	모니터링할 경계
Cloudflare Pages	500 builds/month, 20,000 files, 25 MiB asset, 빌드 timeout 20분	해당 Cloudflare 계정 플랜으로 Pages 제한 확대	한도와 플랜이 바뀔 수 있음	빌드, 파일, timeout
Cloudflare Workers	100,000 requests/day, 10 ms CPU/invocation, 정적 자산 요청 무료	Paid US$5/account/month부터, 10M requests와 30M CPU ms 포함	가격, CPU, 요청, 연관 제품 변경	요청, CPU, 재시도, 알림
Supabase	50,000 MAU, 500 MB database, 1 GB storage, 5 GB egress, Free 프로젝트 2개, 일주일 비활성 시 일시 중지 가능	Pro US$25/month, US$10 compute credits 포함	프로젝트, 컴퓨팅, 트래픽, 보안 경계 변경	MAU, 데이터베이스, 저장 공간, egress, 활동

이 수치는 2026년 7월 26일 Cloudflare Pages 제한, Workers 가격, Supabase 가격에서 확인했습니다. 플랫폼의 한도와 과금 기준은 바뀔 수 있으므로 출시 때 다시 확인해야 합니다.

비활성 Supabase Free 프로젝트는 일주일 뒤 일시 중지될 수 있고 Free에는 자동 백업이 포함되지 않습니다. “프로젝트가 열린다”는 상태 검사가 아닙니다. 활동, 데이터 내보내기, 복원 방법, 업그레이드 조건을 확인합니다.

Cloudflare 무료 제한 목록과 Cloudflare 플랜 비교도 함께 참고할 수 있습니다.

요약

솔로 파운더의 최소 실행 시스템은 짧은 도구 목록이 아닙니다. 중요한 사업 동작마다 입력, 결과, 실패 경로가 필요합니다. 사용자가 들어오고, 제품을 받고, 결제하고, 권한을 얻고, 데이터를 만들고, 피드백을 보내고, 장애 때 도움을 받아야 합니다.

첫 버전은 완벽할 필요가 없지만 검수할 수 있어야 합니다. launch-checklist.md를 저장소 옆에 두고 실제 사용자처럼 결제, 권한, 이벤트, 피드백, 장애를 통과해 봅니다. 그러면 프런트엔드, 백엔드, 배포, 데이터베이스, 결제, 분석을 키울 때 빠진 전달 하나 때문에 전체 시스템을 다시 만들지 않아도 됩니다.