맥락#
프로토타입, 개발 웹과 운영 웹의 주소와 Supabase 프로젝트는 분리돼 있었지만 배포 순서는 main 운영 반영 뒤 develop을 자동 동기화하는 구조였다. 제품 웹도 실제 기능이 없는 자리를 프로토타입 링크로 대신해 두 환경의 역할이 섞였다.
프로젝트 오너는 프로토타입을 데이터베이스 없는 빠른 예시로 한정하고, 개발 웹을 운영 웹과 같은 제품 코드·migration을 실제 개발 전용 DB로 검증하는 운영 전 마지막 관문으로 사용하기로 했다. [1]
환경 역할#
표는 좌우로 이동할 수 있습니다.
| 환경 | 코드 | 데이터 | 목적 |
|---|---|---|---|
| 프로토타입 | apps/prototype |
TypeScript·JSON·Markdown fixture와 브라우저 저장소 | 기획·사용자 흐름을 빠르게 예시하고 수정 |
| 개발 웹 | apps/web의 develop |
실제 offtable-dev Supabase |
운영과 같은 기능을 테스트 계정·개발 데이터로 최종 검증 |
| 운영 웹 | apps/web의 main |
실제 offtable-prod Supabase |
개발 검증을 통과한 버전만 제공 |
- 프로토타입에는 Supabase SDK, 실제 Auth, 원격 DB와 운영 API를 연결하지 않는다.
- 개발 웹과 운영 웹은 같은
apps/web코드와services/backend/supabase/migrations/계약을 사용한다. - 두 제품 환경의 차이는 URL, Supabase 프로젝트, OAuth 자격증명, 테스트 데이터 허용 여부처럼 환경 설정에 필요한 값으로 제한한다.
- 개발 웹은 fixture나 프로토타입 데이터를 제품 기능의 대체값으로 읽지 않는다. 운영 웹도 동일하다.
- 제품 웹에서 프로토타입 주소를 실제 기능의 진입 경로로 사용하지 않는다. 프로토타입에서 합의한 흐름은 제품 코드와 실제 DB 모델로 구현한 뒤 개발 웹에서 다시 검증한다.
제품 웹 승격 순서#
- 제품 변경은 기능 브랜치에서 구현하고
develop대상 PR로 코드 검사를 통과시킨다. develop병합 뒤dev.offtable.kr이offtable-dev로 동작하는지 확인한다.- 새 migration은 먼저
offtable-dev에 적용하고 실제 가입·권한·데이터 흐름을 검증한다. - 개발 검증을 통과한
develop에서main으로 release PR을 만든다. - 호환 가능한 migration을
offtable-prod에 적용하고 release PR을 병합한다. offtable.kr의 핵심 흐름과 환경 교차 연결이 없는지 확인한다.
main → develop 자동 동기화는 사용하지 않는다. 평소에는 develop이 다음 운영 후보이고, 운영 승격 뒤 두 브랜치가 같은 커밋으로 수렴한다. 긴급 수정도 가능한 한 같은 개발 검증 경로를 거치며, 검증을 생략했다면 이유와 후속 검증을 로그에 남긴다.
최소 승격 확인#
- 개발·운영 빌드가 같은 코드와 migration 목록을 사용한다.
dev.offtable.kr은offtable-dev,offtable.kr은offtable-prod만 참조한다.- 개발 테스트 계정과 데이터가 운영에 나타나지 않는다.
- 제품 웹 소스와 내비게이션이
prototype.offtable.kr을 기능 대체 경로로 참조하지 않는다. - lint, typecheck, test, production build와 개발 웹 핵심 사용자 흐름을 통과한다.
결과#
프로토타입은 빠른 예시라는 장점을 유지하고, 제품 개발은 실제 DB·Auth·RLS를 포함한 운영과 같은 조건에서 검증된다. 운영 배포는 개발 검증보다 앞서지 않는다.
관련 문서: 프로토타입 단일 배포, 도메인과 배포 주소, Supabase 환경 격리, 환경 분리 인증, 프로젝트 오너 결정