💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

원문 렌더가 준비되기 전까지 텍스트 가이드로 표시합니다.

들어가며 — 2026년 5월, 왜 또 마이그레이션 이야기인가

데이터베이스 스키마 마이그레이션은 십 년 넘게 풀리지 않은 문제다. 코드는 Git으로 버전 관리하고 PR로 리뷰하지만, 스키마는 여전히 누가 언제 어떻게 바꾼 건지 추적이 어렵다. 한 줄짜리 ALTER TABLE이 4시간 락을 잡아 서비스를 멈추고, 잘못된 인덱스가 야간에 디스크를 채우고, 외래키 한 줄이 슬레이브 복제를 망가뜨린다.

2026년 5월 시점에서 이 문제는 두 갈래로 발전했다. 하나는 **선언형 스키마 도구의 부상**이다. Atlas, pgroll, Reshape 같은 도구가 "원하는 최종 상태"를 선언하면 도구가 diff를 만들고 안전한 순서로 적용한다. 또 하나는 **DB 브랜칭의 보편화**다. Neon, PlanetScale, Supabase, Atlas Cloud가 모든 PR에 격리된 preview DB를 제공해 마이그레이션을 실제 데이터로 검증한다.

이 글은 단일 정답을 제시하지 않는다. 대신 2026년 5월 현재 프로덕션에서 쓰이는 거의 모든 도구를 카테고리별로 분해하고, 어떤 워크로드에 어떤 조합이 적합한지 정리한다.

마이그레이션이 어려운 진짜 이유

코드 배포와 스키마 마이그레이션은 본질적으로 다르다. 코드는 새 컨테이너를 띄우고 트래픽을 옮긴 뒤 옛 컨테이너를 죽이면 끝이다. 스키마는 그렇지 않다.

- **상태성**: 데이터베이스는 상태를 가진다. 잘못된 마이그레이션은 데이터 손실이다.

- **락**: ALTER TABLE은 테이블 락 또는 메타데이터 락을 잡는다. 10GB 테이블의 컬럼 추가가 4시간씩 걸리기도 한다.

- **호환성**: 옛 코드와 새 코드가 동시에 같은 DB를 본다. 컬럼을 그냥 지우면 옛 컨테이너가 깨진다.

- **복제 지연**: MySQL 비동기 복제, Postgres 스트리밍 복제에 큰 DDL은 큰 부담이다.

- **롤백**: 코드는 이전 이미지로 돌리면 끝이지만, DROP COLUMN을 한 뒤에는 컬럼이 사라졌다.

- **멀티 리전**: 동남아, 미국, 유럽 리전에서 동시에 같은 스키마를 보장해야 한다.

이 모든 제약을 자동화로 흡수하는 것이 2026년 마이그레이션 도구의 목표다.

한눈에 보기 — 2026년 5월 도구 라인업

| 카테고리 | 도구 | 1차 언어 | 핵심 모델 |

| --- | --- | --- | --- |

| 선언형 | Atlas (Ariga) | Go | HCL/SQL diff |

| 선언형 | pgroll | Go | Postgres 다단계 |

| 플랫폼 | Bytebase | Go | DBA 워크플로 |

| 플랫폼 | Atlas Cloud | Go | 클라우드 SaaS |

이 도표는 마케팅 문구가 아니라 실제 채택 시그널을 기준으로 정리한 것이다.

Atlas (Ariga.io) — 모던 선언형 + GitOps 노선

Atlas는 Ariga가 2022년 공개한 도구로, 2026년 5월 시점에서 가장 빠르게 성장하는 마이그레이션 플랫폼이다. 핵심은 세 가지다.

- **선언형 HCL 또는 SQL**: 원하는 최종 스키마를 선언하면 Atlas가 자동으로 diff를 만든다.

- **명령형 마이그레이션도 지원**: 기존 Flyway 스타일 버전 SQL 파일도 그대로 관리.

- **CI/CD 통합**: GitHub Actions, GitLab CI, CircleCI 플러그인 제공. PR마다 diff 시각화.

Postgres 스키마를 HCL로 선언하는 예시는 다음과 같다.

schema "public" {}

table "users" {

schema = schema.public

column "id" {

type = bigint

null = false

}

column "email" {

type = varchar(255)

null = false

}

column "created_at" {

type = timestamptz

null = false

default = sql("now()")

}

primary_key {

columns = [column.id]

}

index "users_email_idx" {

columns = [column.email]

unique = true

}

CLI로 diff를 만들어 보면 다음과 같이 동작한다.

atlas schema diff \

--from "postgres://user:pass@localhost:5432/app?sslmode=disable" \

--to "file://schema.hcl" \

--dev-url "docker://postgres/15/dev"

atlas migrate diff add_users \

--dir "file://migrations" \

--to "file://schema.hcl" \

--dev-url "docker://postgres/15/dev"

Atlas의 핵심 차별점은 **dev-url 컨테이너**다. 임시 컨테이너에서 모든 마이그레이션을 적용하고 diff를 계산하므로, 로컬 DB 상태에 의존하지 않는다. 또한 `atlas migrate lint`로 마이그레이션 안전성을 정적 분석한다. 예를 들어 `DROP COLUMN`, `NOT NULL 추가`, `대용량 백필이 일어나는 변경` 같은 위험 작업을 PR 단계에서 차단한다.

Atlas Cloud는 SaaS 형태로 시각적 스키마 탐색기, 자동 백필, RBAC, 감사 로그를 제공한다.

Flyway 10 — JVM 생태계의 사실상 표준

Flyway는 2010년대부터 Spring Boot 진영의 디폴트였다. 2026년 5월 기준 10.x 라인업의 특징은 다음과 같다.

- **SQL-first**: V1__create_users.sql, V2__add_email_index.sql 같은 버전 SQL 파일.

- **자바 마이그레이션도 가능**: 동적 데이터 변환이 필요할 때 Java 코드 작성.

- **체크섬 검증**: 이미 적용된 마이그레이션의 체크섬이 바뀌면 즉시 실패.

- **Flyway Hub**: 원격 메타 저장과 팀 협업.

- **70개 이상의 DBMS 지원**: Postgres, MySQL, Oracle, SQL Server, Snowflake, BigQuery 등.

전형적인 Flyway 워크플로는 다음과 같다.

mkdir -p db/migration

cat > db/migration/V1__create_users.sql <<'SQL'

CREATE TABLE users (

id BIGSERIAL PRIMARY KEY,

email VARCHAR(255) NOT NULL UNIQUE,

created_at TIMESTAMPTZ NOT NULL DEFAULT now()

);

SQL

flyway -url=jdbc:postgresql://localhost:5432/app \

-user=app -password=secret \

-locations=filesystem:db/migration migrate

Flyway 10의 진짜 강점은 **Spring Boot 통합**이다. `spring-boot-starter-data-jpa`에 `flyway-core`를 의존성에 넣으면 부팅 시 자동으로 마이그레이션이 실행된다. Java/Kotlin 백엔드에서는 거의 무조건 이걸 쓴다고 봐도 된다.

단점은 **선언형 모드가 없다**는 점이다. 항상 명시적 ALTER TABLE을 적어야 하고, 다양한 환경 간 동기화는 별도 도구가 필요하다. Atlas 같은 선언형 도구와 결합해 쓰는 팀이 늘고 있다.

Liquibase 4.x — XML/YAML 진영의 강자

Liquibase는 Flyway보다 더 추상화된 모델을 제공한다. SQL을 직접 적는 대신 changeset이라는 단위로 변경을 기술한다. XML, YAML, JSON, SQL 포맷을 모두 지원한다.

databaseChangeLog:

- changeSet:

id: 1

author: youngju

changes:

- createTable:

tableName: users

columns:

- column:

type: bigint

autoIncrement: true

constraints:

primaryKey: true

- column:

type: varchar(255)

constraints:

nullable: false

unique: true

- column:

type: timestamptz

defaultValueComputed: NOW()

constraints:

nullable: false

Liquibase의 장점은 다음과 같다.

- **DB 무관성**: 같은 changeset이 Postgres, MySQL, Oracle, SQL Server 모두에서 동작.

- **롤백 자동 생성**: 많은 변경 유형에서 자동 롤백 SQL 생성.

- **Pro 기능**: 정책 검사, 데이터 마이그레이션, Snowflake/Redshift 통합.

- **Liquibase Hub**: 클라우드 대시보드와 변경 이력.

단점은 **장황함**이다. 단순한 컬럼 추가 하나에도 YAML 10줄을 적어야 한다. 그래서 최근 4.x 라인은 SQL 포맷도 강화해 Flyway 스타일에 가까워졌다.

Bytebase — DBA + 마이그레이션 플랫폼

Bytebase는 2022년 공개된 오픈소스 DBA 플랫폼이다. Liquibase/Flyway가 "도구"라면 Bytebase는 "플랫폼"이다. 핵심 기능은 다음과 같다.

- **SQL 리뷰**: 100+ 룰셋. NOT NULL 추가 차단, 인덱스 누락 경고, 대용량 UPDATE 감지.

- **PR 기반 워크플로**: GitHub/GitLab/Bitbucket 연동. SQL 파일을 PR로 제출하면 자동 리뷰.

- **RBAC**: DBA, 개발자, 릴리스 매니저 역할 분리.

- **다단계 배포**: 개발 → 스테이징 → 프로덕션 파이프라인.

- **GitOps 모드**: Git 저장소가 진실의 원천. Bytebase가 자동 적용.

- **AI SQL 리뷰**: 2025년 말 GA. 생성 AI가 위험 패턴을 검출하고 개선안 제시.

Bytebase는 단일 바이너리로 실행 가능하다.

docker run --rm --init \

--name bytebase \

--publish 8080:8080 \

--volume ~/.bytebase/data:/var/opt/bytebase \

bytebase/bytebase:latest

쿠팡, 토스, NCsoft 같은 한국 대기업 DBA 팀이 Bytebase를 도입했다는 보고가 있다. 일본에서는 메르카리, LINE Yahoo가 자체 평가를 진행했다.

dbmate — 언어 무관 CLI

dbmate는 amacneil/dbmate가 만든 단순한 CLI 도구다. Go로 작성됐고 단일 바이너리다. 핵심 철학은 "도구는 단순해야 한다"는 것이다.

- **언어 무관**: Node, Python, Ruby, Go 어디서든 사용.

- **다중 DB**: Postgres, MySQL, SQLite, ClickHouse.

- **표준 SQL 파일**: -- migrate:up / -- migrate:down 주석으로 구분.

- **상태 추적**: `schema_migrations` 테이블에 적용 이력.

dbmate new create_users

db/migrations/20260516120000_create_users.sql 생성

dbmate up

dbmate down

dbmate dump # 현재 스키마 → db/schema.sql

생성된 마이그레이션 파일은 다음과 같다.

-- migrate:up

CREATE TABLE users (

id BIGSERIAL PRIMARY KEY,

email VARCHAR(255) NOT NULL UNIQUE,

created_at TIMESTAMPTZ NOT NULL DEFAULT now()

);

-- migrate:down

DROP TABLE users;

dbmate는 명시적이고 디버깅이 쉽다. ORM 없는 Go/Node 백엔드에서 자주 쓴다.

golang-migrate — Go 표준 라이브러리에 가까운 위상

golang-migrate는 Go 진영의 사실상 표준 마이그레이션 도구다. 라이브러리로 임베드할 수도, CLI로 실행할 수도 있다.

migrate create -ext sql -dir db/migrations -seq create_users

migrate -path db/migrations -database "postgres://localhost:5432/app?sslmode=disable" up

Go 코드에서 임베드한 예시는 다음과 같다.

package main

"github.com/golang-migrate/migrate/v4"

_ "github.com/golang-migrate/migrate/v4/database/postgres"

_ "github.com/golang-migrate/migrate/v4/source/file"

)

func main() {

m, err := migrate.New(

"file://db/migrations",

"postgres://user:pass@localhost:5432/app?sslmode=disable",

)

if err != nil { panic(err) }

if err := m.Up(); err != nil && err != migrate.ErrNoChange {

panic(err)

}

golang-migrate는 단순하지만 함정이 있다. 디폴트로 한 번에 한 마이그레이션이 적용되며, 트랜잭션을 명시적으로 다뤄야 한다. Postgres 외에서는 idiomatic하지 않은 경우가 있다.

Sqitch — Git 스타일 마이그레이션의 시초

Sqitch는 Perl로 작성된 도구로, "마이그레이션은 Git 커밋처럼 의존성 그래프를 가진다"는 발상이 핵심이다.

- **버전 번호 없음**: 마이그레이션은 이름으로 식별.

- **의존성**: `sqitch add appusers --requires base`처럼 명시적 의존성.

- **`deploy.sql`, `verify.sql`, `revert.sql`**: 세 파일이 한 세트.

sqitch init flipr --uri https://github.com/example/flipr --engine pg

sqitch add appusers --requires base -n "Creates appusers schema"

sqitch deploy db:pg://localhost/flipr

sqitch verify db:pg://localhost/flipr

sqitch revert db:pg://localhost/flipr

Sqitch는 사용자가 많지 않지만 디자인은 영향력이 컸다. Atlas의 직렬화 모델도 부분적으로 Sqitch 영향을 받았다.

Prisma Migrate 6 — TypeScript 진영의 ORM 기반 마이그레이션

Prisma는 TypeScript 백엔드의 디폴트 ORM이다. `schema.prisma` 파일에 모델을 선언하면 `prisma migrate dev`가 SQL을 생성하고 적용한다.

model User {

id Int @id @default(autoincrement())

email String @unique

createdAt DateTime @default(now()) @map("created_at")

posts Post[]

}

model Post {

id Int @id @default(autoincrement())

title String

authorId Int @map("author_id")

author User @relation(fields: [authorId], references: [id])

}

워크플로는 다음과 같다.

npx prisma migrate dev --name init

npx prisma migrate deploy # 프로덕션

npx prisma migrate resolve --rolled-back 20260516120000_init

Prisma Migrate 6의 강점은 **타입 안전성과 schema.prisma의 단일 진실 원천**이다. 단점은 다음과 같다.

- **수평 확장이 어려움**: 다중 스키마, 멀티테넌트는 부족.

- **복잡한 마이그레이션은 SQL 직접 편집**: `prisma migrate diff`로 SQL을 만든 뒤 손으로 다듬는 흐름이 흔하다.

Drizzle Kit — TypeScript 네이티브, SQL에 가까운 ORM

Drizzle ORM은 2024-2025 사이에 빠르게 점유율을 늘린 TypeScript ORM이다. Drizzle Kit이 마이그레이션 도구다.

export const users = pgTable("users", {

id: serial("id").primaryKey(),

email: text("email").notNull().unique(),

createdAt: timestamp("created_at").defaultNow().notNull(),

});

워크플로는 다음과 같다.

npx drizzle-kit generate # TS 스키마 diff → SQL 생성

npx drizzle-kit migrate # 적용

npx drizzle-kit studio # 시각화

Drizzle Kit은 Prisma보다 **SQL에 가깝다**. 생성된 SQL이 사람이 읽기 좋고, 직접 편집해도 다음 generate에서 보존된다. 서버리스/엣지(Cloudflare Workers, Vercel Edge) 환경에서 특히 강하다.

Knex.js — 빌더 + 마이그레이션

Knex.js는 SQL 쿼리 빌더지만 자체 마이그레이션 기능을 갖고 있다. Express/Fastify 진영에서 ORM 없이 가는 팀이 자주 쓴다.

exports.up = async function(knex) {

await knex.schema.createTable("users", (t) => {

t.bigIncrements("id").primary();

t.string("email", 255).notNullable().unique();

t.timestamp("created_at").notNullable().defaultTo(knex.fn.now());

});

};

exports.down = async function(knex) {

await knex.schema.dropTable("users");

};

Knex 마이그레이션의 강점은 **DB 무관 빌더**다. 같은 코드가 Postgres, MySQL, SQLite, MS SQL Server에서 동작한다. 단점은 추상화 누수다. 데이터베이스별 특수 기능을 쓰려면 결국 `knex.raw()`로 빠진다.

Sequelize CLI — JS ORM의 클래식

Sequelize는 Node.js의 클래식 ORM이다. Sequelize CLI가 마이그레이션을 담당한다.

npx sequelize-cli migration:generate --name create-users

생성된 파일은 `up`, `down` 두 함수로 구성된다.

"use strict";

module.exports = {

up: async (queryInterface, Sequelize) => {

await queryInterface.createTable("Users", {

id: { type: Sequelize.BIGINT, primaryKey: true, autoIncrement: true },

email: { type: Sequelize.STRING(255), allowNull: false, unique: true },

createdAt: { type: Sequelize.DATE, allowNull: false },

updatedAt: { type: Sequelize.DATE, allowNull: false },

});

down: async (queryInterface) => {

await queryInterface.dropTable("Users");

};

Sequelize는 더 이상 활발한 신규 도입처는 아니지만, 레거시 코드베이스에는 광범위하게 깔려 있다.

Alembic — Python SQLAlchemy 진영의 표준

Alembic은 SQLAlchemy 저자 Mike Bayer가 만든 마이그레이션 도구다. Python 백엔드(Django 제외)에서 사실상 표준이다.

alembic init alembic

alembic revision --autogenerate -m "create users"

alembic upgrade head

alembic downgrade -1

생성된 마이그레이션 스크립트는 다음과 같다.

from alembic import op

revision = "1a2b3c4d5e6f"

down_revision = None

def upgrade() -> None:

op.create_table(

"users",

sa.Column("id", sa.BigInteger, primary_key=True),

sa.Column("email", sa.String(255), nullable=False),

sa.Column("created_at", sa.DateTime(timezone=True), server_default=sa.func.now()),

sa.UniqueConstraint("email", name="users_email_key"),

)

def downgrade() -> None:

op.drop_table("users")

Alembic의 `--autogenerate`는 SQLAlchemy 모델과 DB를 비교해 diff를 만든다. 강력하지만 완벽하지 않으므로 생성된 스크립트를 반드시 검토해야 한다. FastAPI + SQLAlchemy 조합에서는 거의 무조건 Alembic이다.

Django Migrations — 모델에서 자동 생성

Django는 ORM과 마이그레이션이 완전히 통합되어 있다. `models.py`를 수정하면 `makemigrations`가 자동으로 마이그레이션 파일을 만들고 `migrate`가 적용한다.

from django.db import models

class User(models.Model):

email = models.EmailField(unique=True)

created_at = models.DateTimeField(auto_now_add=True)

python manage.py makemigrations

python manage.py migrate

python manage.py migrate --plan # 적용 예정 변경 미리보기

python manage.py sqlmigrate myapp 0001 # SQL 확인

Django 마이그레이션은 강력하지만 함정도 있다.

- **RunPython**: 데이터 마이그레이션은 명시적으로 작성.

- **AtomicMigration**: Postgres는 트랜잭션 안에서 DDL 실행. 거대한 백필은 `atomic = False`로 비활성화.

- **squashmigrations**: 누적된 마이그레이션을 압축.

Django 진영에서는 거의 100% Django Migrations를 쓴다. Alembic을 끼우는 일은 드물다.

Rails Active Record Migrations — 가장 영향력 있는 마이그레이션 DSL

Rails는 2005년부터 마이그레이션 DSL의 표준을 만들었다. 이후 거의 모든 도구가 영향을 받았다.

class CreateUsers < ActiveRecord::Migration[7.1]

def change

create_table :users do |t|

t.string :email, null: false

t.timestamps

end

add_index :users, :email, unique: true

end

rails generate migration CreateUsers email:string

rails db:migrate

rails db:rollback STEP=1

Rails 마이그레이션의 강점은 **`change` 메소드**다. 한 번 작성하면 up과 down을 자동으로 추론한다. 단점은 강한 컨벤션이다. 비표준적인 변경은 `up`/`down`을 명시적으로 작성해야 한다.

Phoenix Ecto Migrations — Elixir의 함수형 DSL

Elixir/Phoenix 진영은 Ecto를 사용한다. Ecto.Migration은 Rails AR과 비슷한 DSL을 제공한다.

defmodule MyApp.Repo.Migrations.CreateUsers do

use Ecto.Migration

def change do

create table(:users) do

add :email, :string, null: false

timestamps()

end

create unique_index(:users, [:email])

end

mix ecto.gen.migration create_users

mix ecto.migrate

mix ecto.rollback

Elixir 특유의 BEAM 런타임과 함수형 모델 덕분에 마이그레이션 코드가 깔끔하다. 멀티테넌트는 Repo 동적 설정으로 처리한다.

Diesel Migrations — Rust 진영의 컴파일 타임 마이그레이션

Diesel은 Rust의 ORM이자 쿼리 빌더다. 마이그레이션 도구도 함께 제공된다.

diesel migration generate create_users

migrations/<timestamp>_create_users/{up.sql,down.sql} 생성

diesel migration run

diesel migration revert

-- up.sql

CREATE TABLE users (

id BIGSERIAL PRIMARY KEY,

email VARCHAR(255) NOT NULL UNIQUE,

created_at TIMESTAMPTZ NOT NULL DEFAULT now()

);

-- down.sql

DROP TABLE users;

Diesel은 컴파일 타임에 스키마와 쿼리를 검증하는 데 집중한다. `diesel print-schema`로 Rust 타입을 자동 생성하고, 그 타입과 쿼리가 맞지 않으면 컴파일 실패다.

Sea-ORM은 Diesel의 대안으로, 비동기 우선이고 마이그레이션 DSL을 Rust 코드로 작성한다. Sea-ORM Migrate는 다음과 같이 쓴다.

use sea_orm_migration::prelude::*;

#[derive(DeriveMigrationName)]

pub struct Migration;

#[async_trait::async_trait]

impl MigrationTrait for Migration {

async fn up(&self, manager: &SchemaManager) -> Result<(), DbErr> {

manager.create_table(Table::create()

.table(Users::Table)

.col(ColumnDef::new(Users::Id).big_integer().not_null().auto_increment().primary_key())

.col(ColumnDef::new(Users::Email).string().not_null().unique_key())

.to_owned()).await

}

async fn down(&self, manager: &SchemaManager) -> Result<(), DbErr> {

manager.drop_table(Table::drop().table(Users::Table).to_owned()).await

}

EF Core Migrations — .NET의 표준

Entity Framework Core는 .NET 진영의 디폴트 ORM이다. 마이그레이션은 dotnet ef CLI로 관리한다.

dotnet ef migrations add CreateUsers

dotnet ef database update

dotnet ef migrations script

dotnet ef migrations remove

생성된 마이그레이션은 C# 코드다.

public partial class CreateUsers : Migration

{

protected override void Up(MigrationBuilder migrationBuilder)

{

migrationBuilder.CreateTable(

columns: table => new

{

Id = table.Column<long>(nullable: false).Annotation("SqlServer:Identity", "1, 1"),

Email = table.Column<string>(maxLength: 255, nullable: false),

CreatedAt = table.Column<DateTime>(nullable: false, defaultValueSql: "GETUTCDATE()")

constraints: table =>

{

table.PrimaryKey("PK_Users", x => x.Id);

table.UniqueConstraint("UQ_Users_Email", x => x.Email);

});

}

protected override void Down(MigrationBuilder migrationBuilder)

{

migrationBuilder.DropTable(name: "Users");

}

EF Core는 SQL Server 외에 Postgres(Npgsql), MySQL(Pomelo), SQLite도 잘 지원한다.

GORM AutoMigrate — Go ORM의 자동 모드

Go의 GORM은 `AutoMigrate`라는 단순한 API를 제공한다.

type User struct {

ID uint `gorm:"primarykey"`

Email string `gorm:"uniqueIndex;size:255;not null"`

CreatedAt time.Time

}

db.AutoMigrate(&User{})

`AutoMigrate`는 빠르지만 **누락이 많다**. 컬럼 삭제나 타입 변경을 안전하게 수행하지 않는다. 그래서 GORM 사용자도 프로덕션에서는 golang-migrate나 Atlas와 결합해 쓴다.

온라인 스키마 변경 — gh-ost, pt-online-schema-change, pgroll, Reshape

대용량 테이블에서 ALTER TABLE은 락 폭탄이다. 이를 우회하는 도구들이 있다.

**gh-ost** (GitHub Online Schema Transmogrifier)는 GitHub가 MySQL용으로 만든 도구다. 트리거를 쓰지 않고 binlog를 따라가며 그림자 테이블을 만든다.

gh-ost \

--max-load=Threads_running=25 \

--critical-load=Threads_running=1000 \

--chunk-size=1000 \

--max-lag-millis=1500 \

--user="ghost" --password="secret" \

--host=replica.example.com \

--database="myapp" \

--table="users" \

--alter="ADD COLUMN nickname VARCHAR(64)" \

--switch-to-rbr --allow-master-master --cut-over=default \

--exact-rowcount --concurrent-rowcount --default-retries=120 \

--panic-flag-file=/tmp/ghost.panic.flag \

--postpone-cut-over-flag-file=/tmp/ghost.postpone.flag \

--execute

**pt-online-schema-change** (Percona Toolkit)은 트리거 기반이지만 십 년 넘게 검증됐다.

pt-online-schema-change \

--alter "ADD COLUMN nickname VARCHAR(64)" \

D=myapp,t=users \

--execute

**pgroll** (Xata)은 Postgres용 무중단 스키마 변경 도구다. 동일 스키마를 두 가지 버전으로 동시에 노출(뷰)해 점진적 전환을 가능케 한다.

pgroll start migrations/001_add_nickname.json

pgroll complete # 트래픽 전환 후 옛 컬럼 정리

pgroll rollback # 문제가 있으면 옛 버전으로 복귀

**Reshape**는 pgroll과 비슷한 발상의 Rust 도구다. 둘 다 Expand-Contract 패턴을 도구화한 것이다.

**pg_repack**은 마이그레이션 도구는 아니지만, ALTER 후 단편화된 테이블/인덱스를 락 없이 재구성한다.

Expand-Contract 패턴 — 무중단 마이그레이션의 정석

대부분의 무중단 마이그레이션은 Expand-Contract 패턴을 따른다.

1. **Expand**: 새 컬럼/테이블을 추가. 옛 코드도 새 코드도 동작.

2. **Backfill**: 옛 컬럼에서 새 컬럼으로 데이터 복사. 배치로 천천히.

3. **Dual write**: 새 코드는 두 컬럼 모두 쓰기. 점진적 배포.

4. **Read switch**: 트래픽을 새 컬럼 읽기로 전환. 카나리.

5. **Contract**: 옛 컬럼 제거.

코드 배포가 한 단계라면 스키마 변경은 5단계로 분해해야 한다. 이 패턴을 도구가 자동화하는 것이 pgroll, Reshape, Atlas Cloud의 핵심 가치다.

DB 브랜칭 — Neon, PlanetScale, Supabase, Atlas Cloud

2025년 이후 DB 브랜칭이 보편화됐다. PR마다 격리된 DB 브랜치가 만들어지고, 마이그레이션이 실제 데이터로 검증된다.

- **Neon**: Postgres copy-on-write 브랜치. 1초 안에 새 브랜치 생성.

- **PlanetScale**: MySQL/Vitess 기반. 브랜치는 별도 schema 변경 단위.

- **Supabase Branching**: PR 단위 미리보기 DB. Migration이 자동 적용됨.

- **Atlas Cloud**: Atlas로 관리되는 모든 DB에 브랜치 미리보기.

브랜치 DB는 마이그레이션 안전성을 검증하는 가장 강력한 도구다. 프로덕션 데이터의 익명화 복사본에서 마이그레이션을 미리 돌려본 뒤 머지하는 흐름이 사실상 표준이 됐다.

스키마 시각화 — dbdiagram.io, DrawSQL, Mermaid ER

스키마는 시각화될 때 가치가 가장 잘 드러난다. 2026년 5월 기준 주요 도구는 다음과 같다.

- **dbdiagram.io**: DBML이라는 텍스트 DSL로 ER 다이어그램 생성.

- **DrawSQL**: 협업 ER 디자이너. 팀이 동시 편집 가능.

- **Mermaid erDiagram**: GitHub README에 그대로 임베드 가능.

- **DBeaver, DataGrip**: IDE급 클라이언트가 자동으로 ER 생성.

- **SchemaSpy**: 정적 HTML로 스키마 문서를 생성.

- **DBdocs**: dbdiagram의 도큐먼트 호스팅.

- **eraser.io**: 다이어그램 + 노트 + 마크다운 협업 도구.

이 도구들은 마이그레이션을 직접 적용하지는 않지만, 변경 전후의 모습을 시각화해 PR 리뷰를 돕는다.

마이그레이션 테스팅 — testcontainers, schemathesis

마이그레이션도 테스트 대상이다. 2026년 5월 기준 표준 도구는 다음과 같다.

- **testcontainers**: 통합 테스트마다 진짜 Postgres/MySQL 컨테이너를 띄움. 마이그레이션을 적용한 뒤 쿼리 테스트.

- **schemathesis**: OpenAPI 스키마에서 자동 생성된 테스트로 API + DB 일관성 검증.

- **Atlas migrate lint**: 마이그레이션의 정적 안전성 분석.

- **Bytebase SQL Review**: 100+ 룰셋에 의한 정적 검사.

Go에서 testcontainers를 쓰면 다음과 같다.

ctx := context.Background()

pgC, err := postgres.RunContainer(ctx,

testcontainers.WithImage("postgres:15-alpine"),

postgres.WithDatabase("test"),

postgres.WithUsername("test"),

postgres.WithPassword("test"),

)

defer pgC.Terminate(ctx)

dsn, _ := pgC.ConnectionString(ctx, "sslmode=disable")

m, _ := migrate.New("file://./migrations", dsn)

require.NoError(t, m.Up())

멀티 DB 마이그레이션 — Postgres/MySQL/SQLite/MSSQL

여러 DB를 동시에 지원해야 할 때 도구별 호환성을 잘 알아야 한다.

| --- | --- | --- | --- | --- | --- |

| Atlas | ✓ | ✓ | ✓ | ✓ (Cloud) | 일부 |

| Flyway 10 | ✓ | ✓ | ✓ | ✓ | ✓ |

| Liquibase 4.x | ✓ | ✓ | ✓ | ✓ | ✓ |

| Bytebase | ✓ | ✓ | ✓ | ✓ | ✓ |

| dbmate | ✓ | ✓ | ✓ | 일부 | ✗ |

| golang-migrate | ✓ | ✓ | ✓ | ✓ | ✓ |

| Prisma | ✓ | ✓ | ✓ | ✓ | 일부 |

| Alembic | ✓ | ✓ | ✓ | ✓ | ✓ |

DB 무관 추상화가 강한 도구일수록 특수 기능 노출이 약하다. Postgres 전용 기능(`GENERATED ALWAYS AS`, `partitioning`, `BRIN index`)을 쓰려면 raw SQL로 빠지는 일이 많다.

CI/CD 통합 — GitHub Actions, GitLab CI, ArgoCD

마이그레이션은 CI/CD 파이프라인의 1급 시민이어야 한다.

GitHub Actions에 Atlas를 통합하는 예시는 다음과 같다.

on:

push:

branches: [main]

jobs:

migrate:

runs-on: ubuntu-latest

steps:

- uses: actions/checkout@v4

- uses: ariga/setup-atlas@v0

- run: |

atlas migrate apply \

--dir "file://migrations" \

--url "${{ secrets.DATABASE_URL }}" \

--tx-mode all

Flyway를 ArgoCD Hook으로 돌리는 패턴도 자주 보인다. PreSync Hook으로 새 컨테이너 배포 전에 마이그레이션을 적용한다.

apiVersion: batch/v1

kind: Job

metadata:

annotations:

argocd.argoproj.io/hook: PreSync

argocd.argoproj.io/hook-delete-policy: HookSucceeded

spec:

template:

spec:

restartPolicy: Never

containers:

- name: flyway

image: flyway/flyway:10

args: ["migrate"]

envFrom:

- secretRef:

AI 기반 마이그레이션 — Bytebase Copilot, Atlas Copilot

2025년부터 마이그레이션 도구도 AI 기능을 흡수했다.

- **Bytebase SQL Review AI**: 생성 AI가 마이그레이션의 위험 패턴을 한국어/영어로 설명.

- **Atlas Copilot**: 자연어 요구사항에서 HCL 스키마를 생성. SQL diff를 자연어로 설명.

- **CodeRabbit/Greptile**: PR 리뷰에 마이그레이션 안전성 검사 통합.

AI는 두 가지 위치에서 가치를 만든다. 하나는 **위험 신호 자연어 설명**이다. "이 ALTER는 1억 행 테이블에서 4시간 락을 잡을 가능성이 있습니다"라는 식으로 알려준다. 또 하나는 **마이그레이션 패턴 추천**이다. Expand-Contract로 바꾸라는 식의 리팩토링 제안이다.

한국 사례 — NCsoft, 쿠팡, NAVER

한국 IT 기업의 DBA 팀 사례를 보면 다음과 같은 경향이 보인다.

- **NCsoft**: 게임 백엔드의 MySQL 클러스터에 gh-ost를 광범위하게 운영.

- **쿠팡**: 마이크로서비스마다 Flyway 또는 Liquibase. 사내 PR 워크플로에 Bytebase 평가 보고.

- **NAVER**: 대규모 MySQL/MyRocks 환경에서 자체 DBA 도구 + pt-online-schema-change 결합.

- **카카오**: Postgres + Liquibase 워크플로. 일부 팀은 Atlas 평가 단계.

- **토스**: 내부 RDS 운영팀이 자체 GitOps 파이프라인 + Flyway 조합.

전반적으로 일본보다 한국이 Bytebase 같은 한국어 친화 SaaS 도입에 더 적극적인 흐름이 있다.

일본 사례 — メルカリ, LINE Yahoo, CyberAgent, DeNA

일본의 대규모 서비스 운영자들은 다음과 같은 흐름을 보인다.

- **メルカリ (Mercari)**: Atlas, golang-migrate를 평가/도입 보고. 메인 백엔드는 Go.

- **LINE Yahoo**: 통합 후 다양한 마이그레이션 도구가 공존. Flyway, Liquibase, golang-migrate 혼재.

- **CyberAgent**: 게임 백엔드의 MySQL에서 gh-ost를 광범위하게 운영.

- **DeNA**: Mobage 시절부터 대규모 MySQL 운영. gh-ost와 자체 도구 결합.

- **SmartHR**: Rails + ActiveRecord Migrations 표준. Liquibase 일부.

일본 진영은 Go 생태계와 MySQL 운영 노하우가 강해 gh-ost 같은 도구의 채택이 빠르다.

도구 조합 권장 — 워크로드별 베스트 매칭

마지막으로 워크로드별 권장 조합이다.

- **Spring Boot + 단일 Postgres/MySQL**: Flyway 10. 의문의 여지가 없다.

- **Go 백엔드 + 다중 DB**: Atlas + golang-migrate 백엔드.

- **TypeScript + 서버리스/엣지**: Drizzle Kit.

- **TypeScript + 전통적 백엔드**: Prisma Migrate 6 또는 Drizzle Kit.

- **Python FastAPI**: Alembic.

- **Django**: Django Migrations + 부분적으로 pgroll.

- **Rails**: Active Record Migrations.

- **.NET**: EF Core Migrations.

- **대용량 MySQL**: 위 도구 + gh-ost.

- **대용량 Postgres**: 위 도구 + pgroll 또는 Reshape.

- **다중 팀, 강한 거버넌스 필요**: Bytebase 플랫폼 도입.

- **GitOps 강한 워크플로**: Atlas Cloud + GitHub Actions.

마치며 — 도구는 분기하고 패턴은 수렴한다

2026년 5월 시점에서 마이그레이션 도구는 카테고리별로 분기했다. JVM은 Flyway, .NET은 EF Core, Python은 Alembic + Django, TypeScript는 Prisma/Drizzle, Go는 golang-migrate/Atlas로 굳어졌다.

하지만 패턴은 수렴한다. 어떤 도구를 쓰든 다음 원칙이 적용된다.

1. **모든 변경은 PR과 코드 리뷰를 거친다.**

2. **마이그레이션은 자동화된 CI에서 검증된다.**

3. **거대한 변경은 Expand-Contract로 분해한다.**

4. **온라인 스키마 변경 도구로 락을 피한다.**

5. **롤백 계획을 마이그레이션과 함께 작성한다.**

6. **DB 브랜치로 실제 데이터에서 검증한다.**

도구는 이 원칙을 더 적은 비용으로 달성하기 위한 수단이다. 자신의 워크로드와 팀에 맞는 도구를 고르되, 원칙은 흔들지 않는 것이 좋다.

참고 자료

1. [Atlas 공식 문서 (Ariga.io)](https://atlasgo.io/)

2. [Atlas GitHub](https://github.com/ariga/atlas)

3. [Flyway 공식 문서](https://flywaydb.org/documentation/)

4. [Flyway GitHub](https://github.com/flyway/flyway)

5. [Liquibase 공식 문서](https://docs.liquibase.com/)

6. [Liquibase GitHub](https://github.com/liquibase/liquibase)

7. [Bytebase 공식 문서](https://www.bytebase.com/docs/)

8. [Bytebase GitHub](https://github.com/bytebase/bytebase)

9. [dbmate GitHub](https://github.com/amacneil/dbmate)

10. [golang-migrate GitHub](https://github.com/golang-migrate/migrate)

11. [Sqitch 공식 사이트](https://sqitch.org/)

12. [Prisma Migrate 공식 문서](https://www.prisma.io/docs/orm/prisma-migrate)

13. [Drizzle Kit 공식 문서](https://orm.drizzle.team/kit-docs/overview)

14. [TypeORM Migrations 문서](https://typeorm.io/migrations)

15. [Knex.js Migrations 문서](https://knexjs.org/guide/migrations.html)

16. [Sequelize CLI 문서](https://github.com/sequelize/cli)

17. [Alembic 공식 문서](https://alembic.sqlalchemy.org/)

18. [Django Migrations 문서](https://docs.djangoproject.com/en/stable/topics/migrations/)

19. [Rails Active Record Migrations 가이드](https://guides.rubyonrails.org/active_record_migrations.html)

20. [Phoenix Ecto Migrations 문서](https://hexdocs.pm/ecto_sql/Ecto.Migration.html)

21. [Diesel Migrations 문서](https://diesel.rs/guides/getting-started)

22. [Sea-ORM Migrate 문서](https://www.sea-ql.org/SeaORM/docs/migration/setting-up-migration/)

23. [EF Core Migrations 문서](https://learn.microsoft.com/en-us/ef/core/managing-schemas/migrations/)

24. [GORM AutoMigrate 문서](https://gorm.io/docs/migration.html)

25. [gh-ost GitHub](https://github.com/github/gh-ost)

26. [pt-online-schema-change 문서](https://docs.percona.com/percona-toolkit/pt-online-schema-change.html)

27. [pgroll GitHub (Xata)](https://github.com/xataio/pgroll)

28. [Reshape GitHub](https://github.com/fabianlindfors/reshape)

29. [pg_repack GitHub](https://github.com/reorg/pg_repack)

30. [Neon Branching 문서](https://neon.tech/docs/introduction/branching)

31. [PlanetScale Branching 문서](https://planetscale.com/docs/concepts/branching)

32. [Supabase Branching 문서](https://supabase.com/docs/guides/platform/branching)

33. [dbdiagram.io](https://dbdiagram.io/)

34. [DrawSQL](https://drawsql.app/)

35. [Mermaid erDiagram 문서](https://mermaid.js.org/syntax/entityRelationshipDiagram.html)

36. [SchemaSpy](https://schemaspy.org/)

37. [testcontainers Go](https://golang.testcontainers.org/)

38. [schemathesis 공식 문서](https://schemathesis.readthedocs.io/)