Supabase 브랜치 도입을 보류한 이유 — 코드 한 줄

PR마다 테스트용 DB가 자동으로 생기고 Preview 배포가 그걸 보게 만드는 흐름은, 공식 문서에도 나오는 정석이다. 2026-08-24에 nodnod(아트페어 서비스) 로컬 개발 환경을 정비하다가 그쪽으로 가려고 했다. 로컬·테스트 환경을 전부 Supabase 브랜치로 붙이고 싶었다.

브랜치는 운영과 분리된 임시 DB 복제본이다. 좋은 방향이라고 판단했고, 먼저 비용을 확인했다. Pro 플랜은 이미 쓰고 있는데 컴퓨트 요금이 추가로 붙는다. 가장 작은 사양인 Micro가 시간당 $0.01344, 계속 켜두면 월 10달러 안팎이었다.

비용이 나가는 건 대표님 컨펌이 필요해서 잠깐 멈췄다. 멈춘 사이에 다른 길이 떠올랐다 — 로컬 도커를 Vercel Preview에 직접 연결하면 승인 없이 되지 않을까.

코드를 열었더니 제안 자체가 충돌하고 있었다

그 질문에 답하려고 실제 코드를 열었다. packages/supabase/src/dev-auto-login.ts에 로그인 자동화 코드가 있고, 조건이 이렇게 박혀 있었다.

if (!supabaseUrl.includes("127.0.0.1") && !supabaseUrl.includes("localhost")) return null;

로컬이 아닌 주소를 보고 있으면 자동 로그인이 꺼진다. 브랜치는 진짜 URL(https://<branch-ref>.supabase.co)을 쓴다. 즉 로컬 개발 서버를 브랜치에 연결하는 순간 로그인 화면부터 막힌다. 브랜치로 옮기자는 제안이 이미 있는 코드와 정면으로 부딪히고 있었다.

「브랜치 = 정석, 도커 = 구식」이라는 프레임도 틀렸다

처음엔 브랜치가 정석이고 로컬 도커는 구식이라는 식으로 생각했다. 공식 문서를 검색해보니 이것도 틀렸다. Supabase 공식 가이드는 브랜치가 로컬 워크플로를 대체하는 게 아니라 그 위에 얹는 것이라고 명시하고 있었다. 로컬 도커를 버리고 브랜치만 쓰는 패턴은 문서 어디에도 없었다.

하나 더 확인했다. Vercel Preview 배포는 NODE_ENV=production으로 빌드된다. Preview든 운영이든 Next.js는 항상 production 모드로 빌드하니, "로컬에서만 되는 로그인" 코드는 애초에 Preview에서 통하지 않는다. 브랜치를 쓰든 안 쓰든 이 문제는 그대로 남는다.

그래서 뭘 바꿨나

브랜치 도입은 보류했다. 대신 두 가지를 했다.

브랜치가 필요해질 때를 대비해 최소한의 테스트 데이터(supabase/seed.sql)만 미리 만들어뒀다. 실제로 버그가 났던 케이스 — 영문명만 있는 조직, 참가 이력 없는 조직 — 를 일부러 넣었다
로컬 도커 워크플로를 계속 쓰기로 하면서 package.json 스크립트 이름을 정리했다. dev:prod는 로컬인데 이름이 위험하게 읽혀서, dev:prod-db처럼 동작이 드러나는 이름으로 바꿨다

비용 승인을 기다리는 동안 코드를 열어본 게 순서상 이득이었다. 승인이 났어도 로그인 화면에서 막혔을 것이다.

원자료 — 2026-08-24, nodnod Supabase 브랜치 도입 검토. packages/supabase/src/dev-auto-login.ts · Supabase 공식 브랜치 가이드 · Micro 컴퓨트 시간당 $0.01344