맥락#
프로젝트 오너는 초기 MVP를 빠르게 개발하기 위해 Supabase와 Vercel을 사용하기로 했다. 첫 제품은 웹으로 검증하고 이후 모바일 앱을 추가할 계획이므로, 초기 속도를 확보하면서 핵심 데이터와 권한을 웹 화면에 종속시키지 않아야 한다. [1]
결정#
- 초기 MVP의 백엔드·데이터 플랫폼은 Supabase를 사용한다.
- 초기 MVP의 웹 배포 플랫폼은 Vercel을 사용한다.
- 선택 목적은 초기 MVP의 빠른 개발과 검증이다.
- 모바일 앱이 추가돼도 같은 데이터·인증·권한 경계를 재사용할 수 있도록 핵심 상태를 웹 전용 구현에만 두지 않는다.
- 웹 프레임워크, 인증 방식, Supabase 제품별 사용 범위와 세부 환경 구성은 별도 후속 결정으로 관리한다.
운영 경계#
- 로컬·공유 개발·운영 환경의 데이터와 비밀정보를 분리한다.
- 운영 스키마 변경은 버전 관리되는 migration과 승인 절차를 거친다.
- 브라우저에서 접근하는 데이터는 행 단위 권한을 검증하고 관리자 권한 키는 서버에만 둔다.
- Vercel Preview와 운영 배포를 구분하며 운영 반영은 승인된 변경만 허용한다.
결과#
초기 개발은 관리형 데이터베이스·인증·배포 기반을 활용해 빠르게 시작할 수 있다. 대신 환경 분리, 권한 정책과 migration 규칙을 초기에 두지 않으면 개발 데이터 충돌이나 운영 권한 노출 위험이 생긴다.
재검토 조건#
- 최적화·compute 상향·pool·cache·필요한 read replica 뒤에도 핵심 SLO를 2주 이상 반복 위반한다.
- 향후 6개월 peak 예측이 Realtime 등 계약 한도의 70%를 넘는다.
- 현재 플랫폼으로 충족할 수 없는 RPO·RTO·보안·지역 요구가 확정된다.
- migration·관측·보안·백업·당직 인력을 포함한 AWS TCO가 2개 분기 연속 명확히 유리하다.
React Native 앱 출시는 자체로 재검토 조건이 아니다. 공식 Supabase 클라이언트로 같은 backend 계약을 재사용하고, 실제 병목이 확인되면 Storage·worker·DB·Realtime 중 가장 작은 경계부터 분리한다. [2]
30% 여유, 70% 한도, 2주와 2개 분기는 벤더 한도가 아니라 초기 운영 경보기준이며 실제 트래픽 기초선 뒤 조정한다. 상세 근거와 단계별 이전안은 AWS 이전 판단 기준에서 관리한다.
관련 문서: 프로젝트 개요, 제품·MVP, 프로젝트 오너 결정