Supabase를 실제 서비스에 도입할 때 마주치게 되는 핵심 의사결정들을 정리합니다. 무료 플랜에서 Pro로 넘어가야 하는 시점, 사용량 기반 과금이 어떻게 누적되는지, 사용자가 100만 명까지 늘었을 때 실제 청구서가 어떻게 변하는지를 구체적인 숫자로 살펴봅니다. 또한 나중에 다른 인프라로 옮겨야 할 때 어디까지 가능한지, 자체 인증 시스템으로 전환할 수 있는지, 여러 서비스를 한 프로젝트에서 운영해 비용을 최소화하는 방법까지 다룹니다. 결론부터 말하면 일단 Supabase로 시작하고 사용자가 늘어나는 시점에 다시 고민해도 충분합니다.

1. Supabase 유료 결제(Pro 플랜)의 장점

무료 플랜에서 Pro 플랜($25/월)으로 넘어가는 가장 큰 이유는 7일 비활성 시 자동으로 일시정지되는 제약이 사라진다는 점입니다. 프로덕션 서비스라면 사실상 필수입니다.

리소스 측면에서도 차이가 큽니다. DB 용량은 500MB에서 8GB로, MAU는 5만에서 10만으로, Storage는 1GB에서 100GB로 확장됩니다. 운영에 필수적인 일일 백업(7일 보관)이 활성화되고, 월 $10의 컴퓨트 크레딧이 포함되어 Micro 인스턴스 비용을 상쇄해줍니다. 추가로 Read Replica, Branching, Custom Domain 같은 운영 기능들도 사용할 수 있습니다.

2. 사용량 기반 추가 과금 항목

Pro 플랜은 "$25 정액제"가 아니라 사용량 기반 과금이 추가되는 구조입니다.

쿼터 초과 시 과금되는 항목:

  • Database 용량 (8GB 초과)
  • File Storage (100GB 초과, $0.021/GB)
  • Egress 미캐시 (250GB 초과, $0.09/GB)
  • Egress 캐시 ($0.03/GB)
  • MAU (10만 초과, $0.00325/MAU)
  • Edge Function 호출 (200만 초과)
  • Realtime 메시지

항상 과금되는 항목:

  • Compute (인스턴스 시간당 과금, 가장 주의)
  • Disk Size / Throughput / IOPS

Add-on (옵트인 시):

  • PITR (Point-in-Time Recovery)
  • Custom Domain
  • IPv4 Add-on ($4/월)
  • Read Replica
  • Log Drains
  • Image Transformation

실무에서 청구서를 가장 빠르게 부풀리는 3대 영역은 대역폭(Egress), 컴퓨트 스케일링, 다수 프로젝트입니다. 특히 미디어가 많은 앱이라면 미캐시 Egress가 빠르게 누적되니 CDN 캐싱 설계가 필수입니다.

3. 사용자 100만 명일 때 비용 검증

100만 MAU 기준으로 단순 계산하면 MAU 초과분만 약 $2,925(≈$3,000)입니다. 하지만 이 숫자는 인증 비용만 본 낙관적 추정치입니다.

실제로는 컴퓨트가 Micro로는 불가능해 Large/XL 인스턴스가 필요하고, 250GB Egress로는 절대 부족하며, DB와 Storage 용량도 함께 늘어납니다. 또한 이 트래픽이면 Read Replica가 사실상 필수입니다.

현실적인 총액은 월 $4,000 ~ $8,000 이상으로 보는 게 안전합니다. 이 규모에서는 Pro로 가는 건 비효율적이고, Team 플랜($599/월) 또는 Enterprise 협상이 정상적인 경로입니다. Pro 청구서가 매월 $400을 꾸준히 넘기 시작하면 Team 전환 손익분기점으로 봅니다.

4. 사용자 증가 시 마이그레이션 가능 여부

결론부터 말하면 가능합니다. Supabase는 마이그레이션 측면에서 Firebase 같은 NoSQL 대안보다 훨씬 유리합니다. 핵심 이유는 오픈소스이며 표준 PostgreSQL 위에 만들어졌기 때문입니다.

컴포넌트별 난이도를 보면, Database·RLS 정책·Storage는 쉽게 이전 가능합니다. 표준 Postgres라 pg_dump/pg_restore로 그대로 옮길 수 있고, RLS는 그냥 SQL이라 100% 휴대 가능하며, Storage는 S3 호환이라 파일을 옮기고 URL만 교체하면 됩니다. Auth는 중간 난이도로 GoTrue 자체는 오픈소스라 이식 가능하지만 세션 마이그레이션이 까다롭습니다. Realtime과 Edge Functions는 어려운 편으로, 다른 솔루션으로 재구현이 필요합니다.

마이그레이션 경로는 세 가지로 나뉩니다. 첫째는 Self-Hosting(Docker 기반)으로, 클라이언트 코드를 한 줄도 바꾸지 않고 인프라만 옮길 수 있어 가장 안전합니다. 둘째는 Database만 분리해서 RDS, Neon, Render 같은 관리형 Postgres로 옮기는 방법입니다. 셋째는 전체 스택을 AWS/GCP로 이전하는 방법으로, 가장 자유롭지만 가장 많은 일이 필요합니다.

처음부터 락인을 줄이려면 표준 Postgres 패턴 위주로 사용하고, Edge Functions와 Realtime은 핵심 비즈니스 로직이 아닌 부가 기능으로만 한정하며, 가능하면 자체 백엔드를 한 겹 두는 것이 좋습니다.

5. Auth를 자체 인증으로 변경

자체 인증으로의 전환은 DB 마이그레이션 다음으로 어렵지만 충분히 현실적입니다.

핵심 사실 세 가지가 있습니다. GoTrue는 오픈소스이고, 비밀번호 해시가 표준 bcrypt와 Argon2라서 다른 시스템으로 그대로 이식 가능하며, 이 덕분에 사용자에게 비밀번호 재설정을 강요하지 않아도 됩니다.

전환 경로는 세 가지입니다. GoTrue만 Self-Hosting(가장 쉬움), 다른 관리형 Auth(Auth0, Clerk, Cognito 등)로 교체, 그리고 Better-Auth, Lucia, NextAuth 같은 라이브러리로 완전 자체 구현입니다.

체크리스트로는 비밀번호 해시·OAuth·MFA·RLS 호환성을 확인하고, RLS와 통합할 때는 JWT 교환 패턴이나 백엔드 경유 패턴 중 선택해야 하며, 점진적 마이그레이션 전략을 통해 사용자 재로그인 부담을 최소화할 수 있습니다.

6. 결론: 일단 Supabase 사용하고 나중에 고민

Supabase로 빠르게 시작하고, 100만 MAU 근처에서 진지하게 고민하면 늦지 않다.

이 결론을 뒷받침하는 근거는 명확합니다. 출구가 막혀 있지 않습니다. Postgres, JWT, bcrypt 모두 산업 표준이라 어디로든 이주 가능합니다. 비용 곡선이 점진적이라 매출 곡선과 함께 올라가는 구간이 매끄럽게 이어집니다. 마이그레이션 시점은 매출이 받쳐줄 때 오기 때문에, 100만 MAU 규모면 엔지니어 2~3명을 6~8주 마이그레이션에 투입할 여유가 있습니다. 무엇보다 조기 최적화의 함정이 더 큽니다. 검증되지 않은 제품에 대한 인프라 최적화는 거의 항상 손해입니다.

다만 미래의 본인이 고마워할 작은 습관 세 가지가 있습니다. DB 스키마는 표준 Postgres 패턴으로 작성하고, Edge Functions와 Realtime은 부가 기능으로만 한정하며, 클라이언트가 Supabase를 직접 호출하는 영역을 최소화하는 것입니다.

재검토 트리거는 월 청구서가 $400을 꾸준히 넘기 시작할 때, MAU가 30만~50만에 도달할 때, 컴플라이언스 요구사항이 등장할 때, 레이턴시·성능 한계가 체감될 때입니다.

7. MAU 10만이 합산 수치인가? (여러 서비스 운영 시)

여러 서비스를 운영할 때 가장 자주 받는 질문입니다. 결론은 Organization(조직) 단위로 합산됩니다. 같은 조직의 모든 프로젝트 사용량이 합쳐져 쿼터에 카운트됩니다.

합산되는 항목은 MAU, Egress, Storage, Edge Function 호출입니다. 반면 Compute는 프로젝트마다 따로 과금됩니다. 즉, 한 조직에 프로젝트 3개를 띄우면 구독료는 한 번만 내지만 컴퓨트는 3개를 각각 부담해야 합니다.

조직을 분리할지 결정하는 기준은 단순합니다. 같은 사업이거나 사용자 풀을 공유한다면 한 조직으로 묶는 게 유리합니다. 반대로 완전히 다른 사업이거나, 법인이 다르거나, 컴플라이언스 요구가 있다면 조직을 분리해야 합니다.

8. 구독료 최소화 - 한 컴퓨트에 여러 서비스 올리기

서비스 3개를 운영할 때 비용 비교를 보면 차이가 명확합니다. 한 프로젝트에 모두 올리면 $25/월, 같은 조직 안에 3개 프로젝트로 분리하면 $45/월, 조직을 3개로 완전 분리하면 $75/월입니다. 같은 트래픽인데도 분리 방식에 따라 비용이 3배 차이가 납니다.

한 프로젝트에 여러 서비스를 올릴 때 분리 패턴은 세 가지입니다. Schema 분리가 가장 권장되며, 단일 schema에서 테이블 prefix로 구분하는 방법은 가장 간단하고, 같은 도메인의 멀티 테넌트라면 컬럼 기반 분리도 가능합니다.

다만 단일 프로젝트의 트레이드오프를 명확히 알아야 합니다. 한 서비스의 문제가 다른 서비스에 영향을 주는 Blast Radius가 공유되고, 무거운 쿼리가 다른 서비스를 느려지게 만드는 리소스 경합이 발생하며, 백업이 통째 단위라 서비스별 부분 복원이 불가능하고, Auth가 공유되어 권한 관리 부담이 커지며, 나중에 마이그레이션 시 분리가 어려워집니다.

단계별 권장 아키텍처는 다음과 같습니다. 시작 단계에서는 한 프로젝트 안에 Schema로 분리해서 운영하고, 성장 단계에서는 가장 무거운 서비스만 같은 조직 내 별도 프로젝트로 떼어내며, 분리 단계에서는 사업이 독립할 때 조직을 분리합니다. 이렇게 하면 $25/월부터 시작해서 필요할 때만 점진적으로 비용을 늘려가는 구조가 됩니다.