3인 스타트업이 Supabase + Vercel로 8주 만에 MVP를 만들었지만, DAU 12,000 트래픽에서 커넥션 풀 고갈·콜드스타트·Realtime 한도 초과로 72시간 동안 세 번 다운됐다. AWS ECS + RDS로 마이그레이션한 전 과정과 교훈을 정리한다.
2026년 1월, 3인 스타트업 팀이 Supabase + Vercel로 8주 만에 MVP를 만들어 론칭했다. Product Hunt 피처링 후 DAU가 3일 만에 200에서 12,000으로 뛰었고, 그로부터 72시간 동안 서비스가 세 번 다운됐다. 커넥션 풀 고갈, 서버리스 콜드스타트, 예상 못한 비용 폭증—이 글은 그 팀이 Supabase + Vercel 스택을 AWS ECS + RDS로 전환한 전체 과정을 정리한다.
서버리스 스택이 나쁜 선택이었다는 이야기가 아니다. MVP에는 완벽했다. 다만 트래픽이 예상을 넘었을 때 어떤 병목이 먼저 터지는지, 그리고 마이그레이션 과정에서 실제로 어떤 함정에 빠지는지를 기록한다.
※ 이 글은 2026년 4월 기준, Supabase 공식 문서와 Vercel 공식 문서를 교차 참조하여 작성됐습니다. 사례는 실제 스타트업 다수의 경험을 종합한 복합 사례입니다.
이 팀이 만든 서비스는 B2B SaaS로, 기업 고객의 데이터를 시각화하는 대시보드 도구였다. 프론트엔드는 Next.js, 백엔드는 Supabase(PostgreSQL + Auth + Realtime), 호스팅은 Vercel이었다.
선택 이유는 명확했다:
MVP 단계에서는 이 선택이 완벽히 맞았다. 8주 만에 인증, 대시보드 CRUD, 실시간 데이터 동기화까지 완성했다. 문제는 그 다음에 일어났다.
Product Hunt에서 “Product of the Day” 3위를 차지하면서 트래픽이 폭발했다. DAU 200이던 서비스가 3일 만에 12,000으로 뛰었다. 첫날은 버텠다. 둘째 날부터 장애가 시작됐다.
첫 번째 장애 (D+1, 오전 2시): Supabase 대시보드에서 커넥션 풀 고갈 경고. Pro 플랜의 기본 커넥션 풀 크기는 15개였다. Vercel의 서버리스 함수는 요청마다 새 커넥션을 열고 닫는데, 동시 접속자 500명을 넘자 15개 커넥션이 순식간에 소진됐다.
두 번째 장애 (D+2, 오후 3시): Vercel 서버리스 함수 타임아웃. 대시보드의 차트 렌더링에 평균 4초가 걸렸는데, Vercel 서버리스 함수의 기본 타임아웃은 10초이다. 콜드스타트로 시작하면 초기화에 2~3초가 추가되고, DB 쯼리까지 합치면 10초를 초과해 502 에러가 발생했다.
세 번째 장애 (D+3, 오전 9시): Supabase Realtime 구독자 수 한도 초과. Pro 플랜의 동시 Realtime 커넥션 한도는 500개였는데, 대시보드의 실시간 업데이트 기능이 핵심 기능이었기 때문에 거의 모든 사용자가 구독 상태였다.
팀은 마이그레이션 전에 서버리스 스택 내에서 할 수 있는 긴급 조치를 먼저 시도했다.
1) Supabase 커넥션 풀링 최적화: supabase.createClient()를 서버리스 함수 외부에서 한 번만 초기화하도록 변경했다. Vercel의 서버리스 함수는 워킬 인스턴스를 재사용할 수 있으므로, 모듈 스코프에서 클라이언트를 생성하면 커넥션 재사용률이 올라간다.
Supabase 클라이언트 싱글턴 패턴 (Vercel 서버리스 함수용)// lib/supabase-server.ts import { createClient } from '@supabase/supabase-js' // 모듈 스코프에서 생성 → 워킼 인스턴스 간 재사용 const supabase = createClient( process.env.SUPABASE_URL!, process.env.SUPABASE_SERVICE_KEY!, { db: { schema: 'public' }, auth: { persistSession: false } } ) export default supabase
2) Vercel 함수 리전 고정: vercel.json에서 특정 리전을 지정해 콜드스타트를 줄였다. 하지만 트래픽이 특정 리전에 몰리면 해당 리전의 인스턴스 한도에 걸려 역효과가 났다.
3) Supabase 플랜 업그레이드: Team 플랜($599/월)으로 올렸다. 커넥션 풀이 50개로 늘었지만, 동시 접속자 2,000명이 넘으면서 또 같은 문제가 발생할 것이 믭했다.
이 땐질로 1주일을 벌었다. 하지만 근본적인 해결은 아니었다. 커넥션 풀 50개로도 피크 시간대에는 부족했고, 서버리스 함수의 콜드스타트는 구조적 한계였다.
팀은 3가지 옵션을 검토했다:
| 옵션 | 예상 비용 | 커넥션 제어 | 마이그레이션 난이도 |
|---|---|---|---|
| Supabase Enterprise | $2,000+/월 | 전용 커넥션 풀 | 낮음 |
| Railway/Render | $200~500/월 | PgBouncer 직접 설정 | 중간 |
| AWS ECS + RDS | $300~600/월 | 완전 제어 | 높음 |
AWS를 선택한 결정적 이유는 두 가지였다:
마이그레이션은 2주 계획이었지만 4주가 걸렸다. 예상 못한 문제들이 연쇄적으로 터졌다.
문제 1: Supabase Auth → 자체 인증 전환
Supabase Auth는 GoTrue 기반이다. JWT 토큰 형식, 세션 관리 방식, 리프레시 토큰 로직이 모두 Supabase에 종속되어 있었다. Auth0나 NextAuth.js로 전환하려면 기존 사용자의 세션을 모두 무효화해야 했다. 결국 도입한 방법은 듀얼 인증이었다—2주간 Supabase Auth와 NextAuth.js를 병렬하면서 점진적으로 전환했다.
문제 2: Row Level Security(RLS) 정쇁 로직 재구현
Supabase의 RLS는 PostgreSQL 네이티브 기능이지만, Supabase 클라이언트가 자동으로 auth.uid()를 주입해주기 때문에 동작한다. 자체 백엔드에서는 이 로직을 미들웨어 레벨에서 직접 구현해야 했다. RLS 정쇅 23개를 Node.js 미들웨어로 변환하는 데만 5일이 걸렸다.
문제 3: Realtime 구독을 WebSocket으로 대체
Supabase Realtime은 Phoenix Channel 기반이다. 이걸 직접 구현하려면 WebSocket 서버를 따로 띄워야 했다. 팀은 Socket.IO를 ECS의 별도 서비스로 배포하고, Redis Pub/Sub으로 여러 인스턴스 간 메시지를 동기화했다.
문제 4: 데이터 마이그레이션 중 다운타임
Supabase에서 pg_dump로 데이터를 추출하는 동안 데이터베이스 부하가 급증해 서비스가 20분간 다운됐다. 결국 Supabase의 Point-in-Time Recovery(PITR) 백업을 이용해 RDS로 복원하는 방식으로 우회했다.
마이그레이션 후 4주간 운영 데이터를 비교한 결과다:
| 항목 | Supabase + Vercel | AWS ECS + RDS |
|---|---|---|
| 월 비용 | $624 (Team $599 + Vercel $25) | $480 (ECS $220 + RDS $180 + 기타 $80) |
| API 평균 응답 시간 | 320ms (콜드스타트 시 1.8초) | 45ms (ECS 상시 구동) |
| DB 커넥션 한도 | 50개 (Team 플랜) | 300개 (PgBouncer 설정) |
| 동시 접속자 처리 | ~2,000명 | ~15,000명 |
| 마이그레이션 비용 | - | 4주 × 3인 인건비 |
| 운영 복잡도 | 낮음 (관리형) | 높음 (IaC, 모니터링 직접 구성) |
비용은 오히려 $144 줄었다. Supabase Team 플랜이 $599로 비쉘기 때문이다. 다만 진짜 차이는 비용이 아니라 성능과 제어권이었다. 콜드스타트가 사라지고, 커넥션 풀을 직접 튜닝할 수 있게 되면서 장애 빈도가 0으로 떨어졌다.
이 사례에서 서버리스가 문제였던 게 아니다. 성장 속도와 아키텍처의 한계가 어긋나는 시점이 문제였다. 아래는 이 팀의 경험에서 도출한 판단 기준이다:
1. MVP 스택과 스케일업 스택을 처음부터 분리해서 생각해라.
Supabase + Vercel은 MVP에 완벽하다. 하지만 “성공하면 어떻게 되지?”를 미리 그려둘 필요가 있다. Exit plan을 론칭 전에 문서화해둘 것.
2. 커넥션 풀링은 서버리스 + DB 조합에서 가장 먼저 터지는 병목이다.
Vercel 서버리스 함수는 요청마다 커넥션을 열고 닫는다. 트래픽이 늘면 Supabase 커넥션 풀이 먼저 고갈난다. 이건 Supabase만의 문제가 아니라 서버리스 + 매니지드 DB 조합의 구조적 특성이다.
3. Auth와 RLS의 벤더 종속성을 과소평가하지 마라.
Supabase Auth를 떼어내는 것은 단순히 인증 라이브러리를 교체하는 것 이상이다. RLS 정쇅까지 모두 재구현해야 한다.
4. 데이터 마이그레이션은 서비스 중단 없이 수행할 계획을 세워라.pg_dump를 프로덕션 DB에 직접 실행하면 부하가 폭등한다. PITR 백업이나 논리적 레플리케이션을 활용할 것.
5. 마이그레이션 기간은 항상 예상의 2배로 잡아라.
이 팀은 2주를 계획했지만 4주가 걸렸다. 인증, RLS, Realtime 각각이 독립적인 마이그레이션 프로젝트였다.
