ADR-0024: Supabase 개발·운영 프로젝트 격리

맥락#

초기 구현은 빠른 검증을 위해 개발·운영 웹이 하나의 validation 프로젝트를 임시 공유할 수 있게 열어뒀다. 프로젝트 오너는 개발용과 운영용 Supabase가 격리된 환경으로 구축되기를 요청했다. ^[1]

같은 프로젝트를 공유하면 개발 중 migration, 테스트 사용자와 데이터 정리가 운영 화면에 바로 영향을 준다. 앱 코드와 migration은 같게 유지하되 실행 데이터와 인증 경계는 처음부터 분리한다.

결정#

• 두 환경은 Postgres 데이터베이스, Auth 사용자, Storage, Realtime과 프로젝트 자격증명을 공유하지 않는다.
• services/backend/supabase/migrations/의 같은 migration을 각 프로젝트에 독립적으로 적용한다.
• 개발 환경에는 테스트 계정과 seed를 사용할 수 있다. 운영 환경에는 seed와 개발 fixture를 적용하지 않는다.
• 운영 환경이 unavailable이어도 개발 프로젝트로 자동 대체하지 않는다. 반대 방향도 허용하지 않는다.
• Vercel Production 변수는 운영 프로젝트만 가리키고 Preview·Development 변수는 개발 프로젝트만 가리킨다.
• 로컬 .env.local은 개발 프로젝트만 사용한다.
• 개발 웹도 목데이터가 아니라 실제 offtable-dev의 Auth·Postgres·RLS·Realtime을 사용하며, 운영 웹과 같은 제품 코드와 migration을 실행한다. ^[2]
• project ref, 데이터베이스 비밀번호, service role key는 저장소에 기록하지 않는다.
• 카카오·Google·Apple의 OAuth 앱, client ID·secret, callback과 테스트 사용자를 개발·운영별로 분리한다. ^[3] Google은 개발·테스트와 운영·게시 Cloud 프로젝트 분리를 권장한다. ^[4]

검증#

1. 두 프로젝트에 migration 이력이 각각 존재한다.
2. 같은 이메일도 각 환경의 별도 Auth 사용자로 취급된다.
3. 개발 환경에서 만든 프로필·대화방·메시지가 운영 환경 조회에 나타나지 않는다.
4. dev.offtable.kr과 offtable.kr에서 각각 로그인·프로필·채팅·Realtime을 확인한다.
5. Vercel 환경별 URL과 publishable key가 서로 다른 project ref를 가리키는지 확인한다.

결과#

검증 단계에서도 개발 변경과 운영 검증 데이터를 분리할 수 있다. 실제 고객 대상 서비스 전환 시에는 보안 전환 게이트에서 운영 프로젝트 요금제, 백업, 복구와 자격증명 회전을 추가로 확정한다.

관련 문서: 기본 웹과 Supabase 기반, 도메인·배포 주소, 인증 기반과 소셜 로그인, 환경 역할과 승격, 프로젝트 오너 요구