데이터베이스 브랜칭: Postgres DB에 Git 워크플로우를 적용하는 법 (2026 완전 가이드)

다들 한 번쯤 겪어봤을 거예요. 팀에서 하루에 PR을 15개씩 올려요. PR마다 Vercel이나 Netlify에서 멋진 프리뷰 배포가 만들어져요. 프론트 코드는 격리되어 있고, API 라우트도 잘 동작해요. 그런데 누군가가 마이그레이션 테스트를 하다가 모두가 공유하는 스테이징 DB를 날려버려요. 다른 프리뷰 환경이 전부 동시에 터져요. 슬랙이 불타기 시작해요.

문제는 배포 파이프라인이 아니에요. git branch는 코드에만 되고 데이터에는 안 된다는 거예요. 애플리케이션은 몇 년째 브랜치를 나눠서 개발해왔는데, 데이터베이스는 여전히 모놀리스예요. 모든 개발자, 모든 프리뷰, 모든 CI 실행이 하나의 스테이징 인스턴스를 두고 경쟁하는 구조요.

데이터베이스 브랜칭이 바로 이 문제를 해결하는 기술이에요. PR마다, CI 실행마다, 개발자마다 프로덕션 스키마와 데이터가 담긴 격리된 DB 인스턴스를 제공해요. 1초 이내에 생성되고, 비용은 거의 0에 가까워요. 공유 스테이징은 이제 끝. "내 마이그레이션 끝날 때까지 기다려줘"도 끝. 깨진 프리뷰 환경도 끝.

이 가이드에서는 2026년 기준 데이터베이스 브랜칭을 완전히 파헤쳐요. 기반 기술인 Copy-on-Write(CoW)가 어떻게 동작하는지, 어떤 프로바이더가 뭘 제공하는지, 그리고 가장 중요한 것, 모든 PR이 자동으로 자기만의 DB 브랜치를 갖도록 CI/CD 파이프라인에 연결하는 방법까지요.

---

기존 데이터베이스 환경이 망가져 있는 이유

전통적인 DB 환경 구조를 보면 이래요:

프로덕션 DB → 스테이징 DB → 로컬 DB (docker-compose)
                   ↑
             모두가 공유하는 지점

이 구조에서 세 가지 근본적인 문제가 생겨요:

1. 스키마 드리프트

스테이징 DB가 프로덕션과 6개월 전에 갈라졌어요. 누군가 수동으로 마이그레이션을 돌렸고, 다른 누군가는 하드코딩된 ID로 테스트 데이터를 넣었고, 이제 스테이징에는 프로덕션에 없는 칼럼이 14개나 있어요. 마이그레이션이 "스테이징에서는 잘 돌아갔는데" 프로덕션에서 터진다면, 이게 원인이에요.

2. 경합(Contention)

개발자 A는 NOT NULL 칼럼을 기본값과 함께 추가하는 마이그레이션을 테스트 중이에요. 개발자 B는 테이블을 드롭하는 마이그레이션을 테스트 중이에요. 둘 다 같은 스테이징 DB를 바라보고 있어요. 둘 중 하나는 끔찍한 오후를 보내게 돼요.

3. 데이터 불일치

로컬 docker-compose DB에는 시드 데이터가 50행 있어요. 프로덕션에는 users 테이블에만 200개 이상의 엣지 케이스를 포함한 470만 행이 있어요. 로컬에서 2ms인 쿼리가 프로덕션에서는 45초 걸려요. 실제 데이터 볼륨에서는 쿼리 플래너가 완전히 다른 실행 경로를 선택하거든요.

DB 브랜칭은 이 세 가지를 한 방에 해결해요. 각 환경이 프로덕션에서 포크된 자기만의 DB를 갖게 되거든요. 진짜 데이터, 진짜 스케일.

---

데이터베이스 브랜칭의 작동 원리

즉시 DB 브랜치를 만들 수 있는 비결은 Copy-on-Write(CoW) 스토리지예요. 이 메커니즘을 이해하면 안심하고 쓸 수 있어요.

Copy-on-Write: 스토리지 레이어에서의 마법

기존 DB 복사는 데이터를 통째로 복제해요. 100GB짜리 프로덕션이면 100GB 복사본이 떠요. 정작 브랜치에서 건드리는 데이터는 1%도 안 되는데, 느리고 비싸고 낭비가 심해요.

Copy-on-Write은 이 모델을 뒤집어요:

프로덕션 브랜치 (100 GB)
    ├── 데이터 페이지: [A] [B] [C] [D] [E] ... [N]
    │
    ├── PR 브랜치 #1 (오버헤드: ~50 KB)
    │   └── 프로덕션과 모든 페이지 공유
    │   └── 수정된 페이지: [C'] ← 이 페이지만 복사됨
    │
    └── PR 브랜치 #2 (오버헤드: ~50 KB)
        └── 프로덕션과 모든 페이지 공유
        └── 수정된 페이지: [A'] [D'] ← 수정된 페이지만 복사

브랜치가 만들어질 때 데이터는 복사되지 않아요. 브랜치는 부모와 같은 스토리지 페이지를 가리키는 포인터일 뿐이에요. 데이터가 실제로 수정될 때만 해당 페이지의 복사본이 만들어져요. 그래서:

• 브랜치 생성이 즉시(DB 크기와 무관하게 보통 1초 이내)
• 스토리지 비용은 변경량에 비례, DB 크기에 비례하지 않음
• 500GB DB 브랜치 생성 비용이 5MB 브랜치와 동일

Write Amplification 트레이드오프

CoW도 공짜는 아니에요. 공유 페이지에 처음 쓸 때 페이지 복사가 일어나면서 살짝 레이턴시가 붙어요. 테스트나 프리뷰 용도에서는 신경 안 써도 되지만, 쓰기가 빡센 장기 브랜치에서는 주의가 필요해요.

공유 페이지에 대한 첫 번째 쓰기:
  1. 공유 스토리지에서 원본 페이지 읽기
  2. 브랜치 로컬 스토리지에 페이지 복사
  3. 복사된 페이지에 쓰기 적용
  오버헤드: 페이지당 첫 쓰기 시 ~2-5ms

같은 페이지에 대한 이후 쓰기:
  1. 브랜치 로컬 페이지에 직접 쓰기
  오버헤드: 0 (일반 DB와 동일)

PR에서 만들어지고 머지 시 삭제되는 일시적 브랜치가 CoW에 완벽한 이유가 이거예요. 삭제 전에 수정하는 데이터가 거의 없으니까요.

---

프로바이더 비교: 2026년 누가 뭘 제공하나

각자 다른 트레이드오프를 가진 여러 프로바이더가 DB 브랜칭을 제공하고 있어요:

Neon (PostgreSQL)

Neon은 가장 성숙한 DB 브랜칭 솔루션이에요. 브랜칭을 핵심 기능으로 처음부터 설계한 유일한 솔루션이기도 하고요.

아키텍처: Neon은 컴퓨트(Postgres)와 스토리지(커스텀 분산 페이지 서버)를 분리해요. 브랜칭이 스토리지 레이어에서 일어나기 때문에 즉시, 제로 비용이에요.

# Neon CLI로 브랜치 생성
neonctl branches create \
  --project-id my-project \
  --name pr-${PR_NUMBER} \
  --parent main

# 결과:
# Branch "pr-142" created in 0.8s
# Connection string: postgres://user:[email protected]/mydb

주요 기능:

• 특정 시점에서의 즉시 브랜칭 (PITR을 브랜치로 활용)
• Scale-to-zero 컴퓨트 (유휴 브랜치 비용 $0)
• 브랜치 간 스키마 비교 (내장 마이그레이션 시각화)
• Vercel 네이티브 통합 (프리뷰 배포마다 자동 브랜치)
• 브랜치 리셋 (재생성 없이 부모와 동기화)

제한 사항:

• PostgreSQL만 지원
• Scale-to-zero 상태에서 복귀 시 콜드 스타트 ~500ms
• 쓰기 집약 브랜치에서는 스토리지 기반 요금이 예상보다 높을 수 있음

PlanetScale (MySQL + PostgreSQL)

PlanetScale은 "DB를 위한 GitHub"이라는 컨셉으로 deploy request 워크플로우를 처음 들고 나왔어요. 원래 Vitess 기반 MySQL만 지원했는데, 이제 매니지드 PostgreSQL도 추가됐어요.

아키텍처: Vitess 쪽은 스키마 레벨 격리를 써요. 새로 나온 Postgres는 FK, 트리거, 스토어드 프로시저까지 다 지원하는 완전한 Postgres예요.

# PlanetScale 브랜치 생성 (Vitess/MySQL)
pscale branch create my-database pr-142

# Deploy request (스키마 변경을 위한 PR 같은 것)
pscale deploy-request create my-database pr-142 \
  --into main

주요 기능:

• Deploy requests: 스키마 변경에 대한 PR 같은 리뷰 프로세스 (Vitess)
• 프로덕션에서 논블로킹 스키마 마이그레이션 (Vitess)
• 스키마 롤백 (배포된 마이그레이션 되돌리기)
• Postgres 오퍼링에서 FK, 트리거, 확장 완전 지원

제한 사항:

• Vitess 브랜치는 스키마만 공유, 데이터 기본값은 빈 상태
• Hobby 티어 폐지, 최소 비용 $5/월 (Postgres) 또는 리소스 기반 (Vitess)
• 특정 시점 브랜치 생성 미지원
• Postgres 브랜치의 스키마 변경은 수동 적용 (아직 deploy request 미지원)

Supabase (PostgreSQL)

Supabase 브랜칭은 **2026년 3월 GA(정식 출시)**되었어요. Git 기반 마이그레이션 워크플로우와 긴밀히 통합되어 있어요.

아키텍처: 각 브랜치가 격리된 Postgres 인스턴스와 Edge Functions를 받아요. 단, Auth와 Storage는 메인 프로젝트에 연결된 상태로 브랜치별로 독립 복제되지 않아요.

# Supabase 브랜칭 (GitHub 통합 경유)
# GitHub 저장소에 연결하면 PR마다 자동으로 프리뷰 브랜치 생성

supabase branches create pr-142 \
  --project-ref my-project \
  --region us-east-1

주요 기능:

• Edge Functions 지원이 포함된 DB 브랜칭
• supabase/migrations/에서 Git 기반 마이그레이션 추적
• 프리뷰 브랜치가 프로덕션 Postgres 버전과 일치
• Supabase Studio에서 시각적 스키마 비교
• PR 종료 시 브랜치 자동 정리

제한 사항:

• 브랜치가 빈 데이터로 시작 (seed.sql로 시딩, CoW 복제 없음)
• Auth와 Storage는 메인 프로젝트와 공유 (브랜치별 독립 복제 안 됨)
• 브랜치 생성에 2-4분 소요 (Neon의 1초 미만 대비 풀 인스턴스 구동)
• 브랜치는 main 브랜치로만 머지 가능

Turso (libSQL/SQLite)

Turso는 다른 모델을 적용해요: 엣지에서의 임베디드 DB 브랜칭이에요.

아키텍처: libSQL(SQLite 포크) 기반. 각 브랜치는 엣지에서 실행 가능한 경량 레플리카예요.

# Turso 브랜치 생성
turso db create pr-142 --from-db production

# 브랜치를 애플리케이션 프로세스에 직접 임베드 가능
# 외부 DB 연결 불필요

주요 기능:

• 100ms 이내 브랜치 생성
• 임베디드 모드 (DB가 애플리케이션 프로세스 안에서 실행)
• 내장 멀티 리전 복제
• 극도로 저렴 (Hobby 티어 무료, 9GB 스토리지)

제한 사항:

• SQLite 호환 레이어 (PostgreSQL/MySQL 전체 기능 미지원)
• 고동시성 쓰기 워크로드에 부적합
• 생태계와 통합이 적은 편

비교 매트릭스

기능	Neon	PlanetScale	Supabase	Turso
엔진	PostgreSQL	MySQL (Vitess) + PostgreSQL	PostgreSQL	libSQL (SQLite)
브랜치 생성	< 1초	~5초	2-4분	< 100ms
데이터 복제	✅ Copy-on-Write	❌ 스키마만 (Vitess)	❌ 빈 데이터 (seed.sql)	✅ 전체 복사
Scale-to-Zero	✅	❌	❌	✅
시점 브랜칭	✅	❌	❌	❌
Auth/Storage 브랜칭	❌ DB만	❌ DB만	⚠️ 공유 (브랜치별 독립 X)	❌ DB만
Vercel 통합	✅ 네이티브	✅ 네이티브	✅ 네이티브	✅ 커뮤니티
최소 비용	무료 티어	$5/월 (Postgres)	무료 티어	무료 티어
Deploy Request	❌	✅ (Vitess만)	❌	❌

---

프로덕션 CI/CD 통합: 완전 셋업

PR마다 DB 브랜치를 만들고, 마이그레이션을 실행하고, 머지 시 정리하는 프로덕션 레디 GitHub Actions 워크플로우예요.

Step 1: GitHub Actions 워크플로우

# .github/workflows/preview-db.yml
name: Preview Database Branch

on:
  pull_request:
    types: [opened, synchronize, reopened, closed]

env:
  NEON_PROJECT_ID: ${{ secrets.NEON_PROJECT_ID }}
  NEON_API_KEY: ${{ secrets.NEON_API_KEY }}

jobs:
  create-branch:
    if: github.event.action != 'closed'
    runs-on: ubuntu-latest
    outputs:
      db_url: ${{ steps.create.outputs.db_url }}
    steps:
      - uses: actions/checkout@v4

      - name: Create Neon Branch
        id: create
        uses: neondatabase/create-branch-action@v5
        with:
          project_id: ${{ env.NEON_PROJECT_ID }}
          api_key: ${{ env.NEON_API_KEY }}
          branch_name: pr-${{ github.event.number }}
          parent: main

      - name: Run Migrations
        env:
          DATABASE_URL: ${{ steps.create.outputs.db_url }}
        run: |
          npx drizzle-kit push
          echo "✅ Migrations applied to branch pr-${{ github.event.number }}"

      - name: Comment PR with Database URL
        uses: actions/github-script@v7
        with:
          script: |
            github.rest.issues.createComment({
              owner: context.repo.owner,
              repo: context.repo.repo,
              issue_number: context.issue.number,
              body: `🗄️ **프리뷰 DB 브랜치 생성 완료**\n\n브랜치: \`pr-${context.issue.number}\`\n연결 정보: 프리뷰 배포 환경변수에서 확인 가능합니다.`
            });

  cleanup-branch:
    if: github.event.action == 'closed'
    runs-on: ubuntu-latest
    steps:
      - name: Delete Neon Branch
        uses: neondatabase/delete-branch-action@v3
        with:
          project_id: ${{ env.NEON_PROJECT_ID }}
          api_key: ${{ env.NEON_API_KEY }}
          branch: pr-${{ github.event.number }}

Step 2: Vercel 통합

Vercel 배포에서 Neon은 프리뷰 배포마다 자동으로 브랜치를 만드는 네이티브 통합을 제공해요:

// vercel.json — Neon Vercel 통합 사용 시 변경 불필요
// 통합이 자동으로:
// 1. Vercel 프리뷰 배포 생성 시 Neon 브랜치 생성
// 2. 프리뷰 배포 환경에 DATABASE_URL 주입
// 3. 프리뷰 배포 삭제 시 Neon 브랜치도 삭제

// 애플리케이션 코드는 동일하게 동작:
import { neon } from '@neondatabase/serverless';

const sql = neon(process.env.DATABASE_URL!);

export async function getUsers() {
  const users = await sql`SELECT * FROM users LIMIT 10`;
  return users;
}

Step 3: 스키마 마이그레이션 전략

가장 일반적인 패턴은 브랜치 생성 시 마이그레이션을 실행하는 거예요:

// drizzle.config.ts
import { defineConfig } from 'drizzle-kit';

export default defineConfig({
  schema: './src/db/schema.ts',
  out: './drizzle',
  dialect: 'postgresql',
  dbCredentials: {
    url: process.env.DATABASE_URL!,
  },
});

// src/db/schema.ts — 스키마 변경이 PR의 일부
import { pgTable, text, timestamp, integer } from 'drizzle-orm/pg-core';

export const users = pgTable('users', {
  id: text('id').primaryKey(),
  name: text('name').notNull(),
  email: text('email').notNull().unique(),
  // 이 PR에서 추가된 새 칼럼:
  avatarUrl: text('avatar_url'),
  createdAt: timestamp('created_at').defaultNow(),
});

개발자의 워크플로우는 이렇게 돼요:

1. 코드 변경 + 스키마 변경을 포함한 PR 생성
2. GitHub Actions가 프로덕션에서 DB 브랜치 생성
3. 브랜치에서 마이그레이션 실행 (avatar_url 칼럼 추가)
4. Vercel이 브랜치 DATABASE_URL로 프리뷰 배포
5. 실제 프로덕션 데이터 대상으로 기능 테스트 (새 칼럼 포함)
6. PR 머지 → 브랜치 삭제, 프로덕션에서 마이그레이션 실행

---

고급 패턴

패턴 1: 디버깅을 위한 시점 브랜칭

고객이 버그를 신고하면 버그가 발생한 정확한 시점의 브랜치를 만들 수 있어요:

# 2시간 전 시점의 브랜치 생성
neonctl branches create \
  --project-id my-project \
  --name debug-issue-1234 \
  --parent main \
  --timestamp "2026-04-09T06:00:00Z"

# 2시간 전의 정확한 DB 상태를 갖게 됨
# 쿼리하고, 분석하고, 버그를 재현할 수 있음

백업을 별도 인스턴스에 복원하는 것보다 훨씬 낫죠. 브랜치는 즉시 만들어지고, 비용이 들지 않고, 프로덕션에 영향을 주지 않아요.

패턴 2: 장기 환경을 위한 브랜치 리셋

일부 팀은 주기적으로 새로고침이 필요한 영구 개발 브랜치를 운영해요:

# dev 브랜치를 현재 프로덕션 상태와 동기화
neonctl branches reset dev-environment \
  --parent main

# 이제 브랜치에 최신 프로덕션 데이터가 반영됨
# 삭제 후 재생성할 필요 없음

패턴 3: 스키마 드리프트 감지

브랜치를 사용해서 스키마 드리프트가 프로덕션 장애로 발전하기 전에 감지할 수 있어요:

// CI 잡: 브랜치 스키마와 프로덕션 비교
import { neon } from '@neondatabase/serverless';

async function detectSchemaDrift() {
  const prodDb = neon(process.env.PRODUCTION_DATABASE_URL!);
  const branchDb = neon(process.env.BRANCH_DATABASE_URL!);

  const prodSchema = await prodDb`
    SELECT table_name, column_name, data_type, is_nullable
    FROM information_schema.columns
    WHERE table_schema = 'public'
    ORDER BY table_name, ordinal_position
  `;

  const branchSchema = await branchDb`
    SELECT table_name, column_name, data_type, is_nullable
    FROM information_schema.columns
    WHERE table_schema = 'public'
    ORDER BY table_name, ordinal_position
  `;

  const drift = findDifferences(prodSchema, branchSchema);

  if (drift.length > 0) {
    console.error('⚠️ 스키마 드리프트 감지:', drift);
    process.exit(1);
  }

  console.log('✅ 스키마 드리프트 없음');
}

패턴 4: 프로덕션 데이터로 부하 테스트

기존 부하 테스트는 합성 데이터를 사용하는데, 실제 데이터 분포와 같은 쿼리 플래너 동작을 유발하지 못해요:

# 부하 테스트용 브랜치 생성
neonctl branches create \
  --project-id my-project \
  --name load-test-$(date +%Y%m%d)  \
  --parent main

# 브랜치 대상으로 부하 테스트 실행
# 진짜 인덱스, 진짜 데이터 분포, 진짜 쿼리 플랜
k6 run load-test.js --env DB_URL=$BRANCH_URL

# 끝나면 브랜치 삭제
neonctl branches delete load-test-$(date +%Y%m%d)

---

비용 분석: 진짜로 더 저렴할까?

의외일 수 있는데, DB 브랜칭이 기존 스테이징 환경보다 오히려 싸게 먹히는 경우가 많아요.

기존 방식

프로덕션 RDS 인스턴스:    $200/월
스테이징 RDS 인스턴스:    $200/월 (항상 실행)
개발 RDS 인스턴스:        $100/월 (항상 실행)
합계:                     $500/월

스테이징 인스턴스는 업무 시간에만 활발히 사용되는데 24/7 돌아가요. 개발 인스턴스는 한 번에 한 명만 써요.

데이터베이스 브랜칭 방식

프로덕션 Neon 인스턴스:   $19/월  (워크로드에 맞게 스케일링)
프리뷰 브랜치:            ~$2/월  (Scale-to-Zero, 일시적)
개발 브랜치:              ~$1/월  (Scale-to-Zero)
합계:                     ~$22/월

Neon 브랜치는 미사용 시 제로로 스케일 다운돼요. 3시간 활성화된 PR의 프리뷰 브랜치 비용은 푼돈이에요. 95% 이상의 비용 절감은 유휴 리소스에 돈을 안 쓰는 데서 나와요.

비용이 급등할 수 있는 경우

주의할 점:

• 쓰기 집약 브랜치: CoW는 쓰기 시 추가 스토리지를 생성해요
• 장기 브랜치: 부모와 크게 분기된 브랜치는 스토리지가 누적돼요
• 컴퓨트 시간: 브랜치에서 비싼 쿼리를 계속 실행하면 컴퓨트 비용이 올라가요

---

마이그레이션 전략: 기존 환경에서 전환하기

지금 RDS나 Cloud SQL, 셀프호스팅 PostgreSQL 쓰고 있다면 이 순서로 갈아타면 돼요:

Phase 1: 섀도우 모드 (1-2주)

기존 DB 옆에 Neon을 같이 돌려요. 프로덕션은 현재 프로바이더에 유지하면서 CI/CD와 프리뷰 환경에서만 브랜칭을 사용해요.

# .env.production — 그대로 유지
DATABASE_URL=postgres://user:pass@your-rds-instance.amazonaws.com/mydb

# .env.preview — Neon 브랜치 사용
DATABASE_URL=${{ NEON_BRANCH_URL }}

Phase 2: 듀얼 라이트 검증 (3-4주)

프로덕션 쓰기를 Neon에 미러링해서 데이터 일관성과 성능을 검증해요.

Phase 3: 프로덕션 전환 (5주)

프로덕션 트래픽을 Neon으로 전환해요. 기존 DB는 2주 동안 읽기 전용 폴백으로 유지해요.

Phase 4: 완전 브랜칭 워크플로우 (6주~)

전체 브랜칭 워크플로우를 활성화해요. 모든 PR이 브랜치를 갖고, 마이그레이션이 브랜치에서 실행되고, 머지 시 브랜치가 정리돼요.

---

흔한 함정과 피하는 법

함정 1: 오래된 브랜치

월요일에 프로덕션에서 만든 브랜치에는 금요일의 데이터가 반영 안 돼요. 몇 시간 이상 유지되는 브랜치는:

• 브랜치 리셋으로 부모와 다시 동기화하거나
• 영구 개발 환경은 야간 자동 재생성을 구성하세요

함정 2: 커넥션 문자열 관리

가장 많이 보이는 실수가 환경 변수 안 쓰고 커넥션 문자열을 하드코딩하는 거예요:

// ❌ 절대 이렇게 하지 마세요
const db = new Pool({ connectionString: 'postgres://...' });

// ✅ 항상 환경 변수를 사용하세요
const db = new Pool({ connectionString: process.env.DATABASE_URL });

함정 3: 고아 브랜치

자동 정리 없이는 브랜치가 쌓여요. 항상 생성과 삭제를 쌍으로 구성하세요:

# PR open/sync → 브랜치 생성
# PR close → 브랜치 삭제
# 주간 cron → 고아 브랜치 정리

  cleanup-orphans:
    runs-on: ubuntu-latest
    schedule:
      - cron: '0 3 * * 0'  # 매주 일요일 오전 3시
    steps:
      - name: 오래된 브랜치 조회 및 삭제
        run: |
          BRANCHES=$(neonctl branches list --project-id $NEON_PROJECT_ID --output json)
          echo "$BRANCHES" | jq -r '.[] | select(.name | startswith("pr-")) | .id' | while read id; do
            neonctl branches delete $id --project-id $NEON_PROJECT_ID
          done

함정 4: 브랜치의 민감 데이터

브랜치에는 프로덕션 데이터의 복사본이 포함돼요. 프로덕션 DB에 PII가 있으면 브랜치에도 PII가 있어요. 해결책:

• 브랜치 생성 시 데이터 마스킹 적용
• 실제 데이터가 필요 없는 환경에는 스키마 전용 브랜칭(데이터 없음) 사용
• Row-Level Security(RLS) 정책 적용 (브랜치에도 전파됨)

함정 5: 마이그레이션 순서

두 개의 PR이 동시에 마이그레이션을 추가하면 머지 순서가 중요해요. 순차 번호 대신 타임스탬프 기반 마이그레이션 파일을 사용하세요 (Drizzle과 Prisma가 기본적으로 생성하는 방식).

---

정리

DB 브랜칭은 팀의 DB 운영 방식 자체를 뒤집어요. 다 같이 살살 건드리던 공유 자원이 아니라, 코드처럼 브랜치 따고, 테스트하고, 날려버리는 아티팩트가 되는 거예요.

기술은 이미 검증됐어요. Neon의 CoW 스토리지는 2024년부터 프로덕션에서 안정적으로 돌아가고 있고, CI/CD 통합도 잘 되고, 비용 모델도 합리적이에요. 지금 안 쓸 이유가 있다면 그건 그냥 관성이에요.

아직 팀이 스테이징 DB를 공유하고 있다면, 이미 해결된 문제에 돈을 내고 있는 거예요. 프리뷰 터짐, 마이그레이션 충돌, "스테이징에서는 됐는데" 이 모든 게 안 내도 되는 세금이에요.

DB를 브랜치하세요. 코드를 브랜치하는 것처럼. 모든 PR에. 매번.