blog

Flyway 실전 적용기

NEXTREE.

01 9월 2026 • 24 min read

- 다운로드 및 업데이트 가능한 애플리케이션의 DB Migration 관리 -

1. 들어가며

애플리케이션을 개발하다 보면 기능 변경과 함께 데이터베이스 스키마도 계속 변경됩니다. 새로운 테이블을 추가하거나 기존 컬럼의 타입을 변경하기도 하고, 데이터 구조 자체를 바꾸면서 기존 데이터를 새로운 구조로 옮겨야 하는 경우도 있습니다.

일반적인 웹 서비스라면 이러한 데이터베이스 변경을 배포 파이프라인의 일부로 관리할 수 있습니다. 개발팀이 서버와 데이터베이스 환경을 모두 관리하고 있다면, 애플리케이션 배포와 함께 필요한 SQL을 실행하는 방식도 사용할 수 있습니다.

하지만 제가 참여하고 있는 Vizend Platform은 조금 다른 요구사항을 가지고 있습니다.

Vizend의 Application은 하나의 중앙 서버에서만 운영되는 형태가 아니라, 사용자가 자신의 환경에 다운로드하여 설치할 수 있습니다. 설치 이후에는 새로운 버전의 Application을 다시 다운로드하거나 업데이트하여 사용할 수도 있습니다.

즉, Application이 Downloadable하고 동시에 Updatable합니다.

이 구조에서는 Application 코드만 업데이트해서는 충분하지 않습니다. 새로운 버전의 코드가 새로운 Database Schema를 필요로 한다면, Application이 업데이트되는 과정에서 Database Schema 역시 함께 변경되어야 합니다.

예를 들어 7.1 버전의 Application이 다음과 같은 테이블을 사용하고 있다고 가정하겠습니다.

user

├─ id

└─ name

7.2 버전에서 새로운 기능을 추가하면서 status 컬럼을 사용하도록 변경했다면 다음과 같은 Schema가 필요합니다.

user

├─ id

├─ name

└─ status

Application만 7.2 버전으로 업데이트되고 Database가 7.1의 상태로 남아 있다면, Application은 실행되더라도 정상적으로 동작할 수 없습니다.

결국 저희에게 Application Update는 다음 두 가지를 함께 의미했습니다.

Application Update

│

├─ Application Version Update

│

└─ Database Schema Update

더 중요한 것은 사용자가 설치한 모든 환경의 Database에 개발자가 직접 접근해서 SQL을 실행할 수 없다는 점입니다.

따라서 Application이 스스로 업데이트될 수 있다면 해당 Application이 필요로 하는 Database Schema 역시 Runtime에 자동으로 업데이트될 수 있어야 했습니다.

이 문제를 해결하기 위해 Flyway를 도입하여 Database Migration을 Application Runtime에 포함시켰습니다.

이번 글에서는 Flyway 자체의 사용 방법보다는 실제 프로젝트에 Flyway를 적용하면서 겪었던 문제와 그 과정에서 정리하게 된 Migration 원칙을 중심으로 작성해보려고 합니다.

2. Flyway 도입

Flyway를 처음 적용했을 때 기대했던 역할은 비교적 단순했습니다.

각 Database 변경에 Version을 부여한 Migration Script를 작성하고, Application이 실행될 때 아직 실행되지 않은 Migration을 자동으로 적용하는 것입니다.

예를 들어 다음과 같이 Migration Script를 작성합니다.

V7_1_1__Create_User.sql
V7_1_2__Modify_User.sql
V7_1_3__Create_Position.sql

Flyway는 Database의 flyway_schema_history를 확인하여 이미 실행된 Migration과 아직 실행되지 않은 Migration을 구분합니다.

따라서 새로운 버전의 Application이 실행되면 필요한 Schema 변경도 함께 실행할 수 있습니다.

저희는 Spring Boot Application에서 Flyway를 활성화하고 Hibernate는 Schema를 직접 변경하지 않고 검증만 수행하도록 구성했습니다.

spring:
  flyway:
    enabled: true
  jpa:
    hibernate:
      ddl-auto: validate

이렇게 하면 Database Schema 변경의 책임은 Flyway가 담당하고, Hibernate는 Entity와 실제 Database Schema의 정합성을 확인하게 됩니다.

초기에는 이것만으로도 DB Migration 문제가 대부분 해결될 것이라고 생각했습니다.

하지만 실제 서비스를 개발하고 여러 번의 Version Update를 진행하면서 단순히 “SQL을 순서대로 자동 실행한다”는 것만으로는 안전한 Migration을 만들기 어렵다는 것을 경험했습니다.

그 과정에서 현재는 Migration을 작성할 때 다음 세 가지를 가장 중요하게 확인하고 있습니다.

동일한 Migration이 다시 실행되더라도 안전한가?

문제가 발생하면 이전 상태로 되돌릴 수 있는가?

이전 상태로 돌아가기 위해 필요한 데이터가 보존되어 있는가?

각각 멱등성, Rollback, Backup에 대한 문제입니다.

3. Migration의 첫 번째 원칙: 멱등성

Flyway의 Versioned Migration은 정상적으로 실행이 완료되면 동일한 Migration을 다시 실행하지 않습니다.

그렇다면 Migration SQL을 굳이 멱등하게 작성해야 할 필요가 있을까 하는 의문이 생길 수 있습니다.

실제 운영에서는 Flyway가 항상 완벽한 상태에서만 실행된다고 가정하기 어렵습니다.

Migration 과정에서 일부 SQL이 실행된 후 오류가 발생할 수도 있고, 장애를 복구하는 과정에서 특정 SQL을 수동으로 다시 실행해야 할 수도 있습니다. 또한 Downloadable Application 특성상 서로 다른 설치 환경의 Database가 예상과 조금 다른 상태를 가지고 있을 가능성도 고려해야 했습니다.

이러한 상황에서 동일한 SQL을 다시 실행했을 때 또 다른 오류가 발생하면 복구 과정이 더 어려워집니다.

따라서 저희는 가능한 모든 Migration에 대해 멱등성을 보장하는 것을 기본 원칙으로 정했습니다.

가장 기본적으로 사용하는 방법은 IF EXISTS, IF NOT EXISTS입니다.

테이블을 생성할 때는 다음과 같이 작성합니다.

CREATE TABLE IF NOT EXISTS user_history (
    id BIGINT PRIMARY KEY,
    user_id BIGINT NOT NULL
);

컬럼을 추가할 때도 가능하면 다음과 같이 작성합니다.

ALTER TABLE user
ADD COLUMN IF NOT EXISTS status VARCHAR(20);

삭제 작업에서는 반대로 IF EXISTS를 사용합니다.

DROP TABLE IF EXISTS user_history;

Database에서 직접 IF EXISTS 또는 IF NOT EXISTS를 제공하지 않는 DDL에 대해서는 별도의 Function을 만들어 동일한 방식으로 처리할 수 있도록 했습니다.

하지만 적용하면서 한 가지 주의해야 할 점도 알게 되었습니다.

IF NOT EXISTS가 있다고 해서 해당 Migration의 멱등성이 완전히 보장되는 것은 아닙니다.

예를 들어 다음 SQL이 있다고 가정하겠습니다.

ALTER TABLE user
ADD COLUMN IF NOT EXISTS status VARCHAR(20);

Database에 이미 status 컬럼이 존재하면 SQL은 오류 없이 종료됩니다.

하지만 실제 컬럼이 다음과 같이 생성되어 있을 수도 있습니다.

기대 상태
status VARCHAR(20)
실제 상태
status INTEGER

SQL은 성공했지만 Database는 Application이 기대하는 상태가 아닙니다.

따라서 저희는 단순히 SQL이 두 번 실행되어도 오류가 발생하지 않는 것만을 멱등성이라고 판단하지 않습니다.

Migration을 한 번 실행하든 여러 번 실행하든 최종 Database 상태가 동일한가를 기준으로 판단하려고 합니다.

IF EXISTS, IF NOT EXISTS는 이를 구현하기 위한 도구 중 하나입니다.

4. Forward Migration만으로는 충분하지 않았습니다

Migration을 처음 작성할 때는 주로 새로운 버전으로 Database를 변경하는 방법에 집중했습니다.

하지만 Application을 운영하다 보면 새로운 버전에 문제가 있어서 이전 버전으로 Rollback해야 하는 경우를 고려하지 않을 수 없습니다.

Application만 이전 버전으로 되돌렸는데 Database Schema가 새로운 버전의 상태로 남아 있다면 이전 Application이 정상적으로 동작하지 않을 수도 있습니다.

따라서 Forward Migration을 작성하는 것만으로는 충분하지 않았습니다.

현재는 Incremental Migration을 작성할 때 이에 대응하는 Rollback Script를 함께 작성하는 것을 원칙으로 하고 있습니다.

예를 들어 다음과 같은 Migration이 있다면,

postgresql/V7_1/
└─ V7_1_3__Modify_User.sql

대응하는 Rollback Script를 별도의 디렉터리에 함께 관리합니다.

rollback/postgresql/V7_1/
└─ V7_1_3__Modify_User_Rollback.sql

Rollback Script는 Flyway에 의해 자동으로 실행되는 대상이 아닙니다.

Application Rollback이나 장애 복구가 필요한 상황에서 담당자가 변경 내용을 확인하고 실행할 수 있도록 별도로 관리합니다.

간단한 컬럼 추가라면 다음과 같은 Forward Migration을 작성할 수 있습니다.

ALTER TABLE user
ADD COLUMN IF NOT EXISTS status VARCHAR(20);

Rollback Script에서는 반대로 해당 컬럼을 제거합니다.

ALTER TABLE user
DROP COLUMN IF EXISTS status;

처음에는 이 정도면 Rollback을 충분히 준비했다고 생각할 수 있습니다.

하지만 실제 데이터가 변경되는 Migration에서는 Schema만 되돌린다고 해서 이전 상태로 돌아가는 것이 아니라는 문제가 있습니다.

5. Rollback을 만들기 전에 Backup을 생각합니다

가장 중요하게 정리하게 된 원칙 중 하나가 Backup과 Rollback을 하나의 작업으로 생각하는 것입니다.

예를 들어 기존 컬럼을 삭제했다고 가정하겠습니다.

ALTER TABLE user
DROP COLUMN legacy_code;

Application에 문제가 발생하여 이전 버전으로 Rollback해야 한다면 다음과 같이 컬럼을 다시 만들 수 있습니다.

ALTER TABLE user
ADD COLUMN legacy_code VARCHAR(100);

Database Schema만 보면 원래 상태로 돌아온 것처럼 보입니다.

하지만 기존 legacy_code 컬럼에 저장되어 있던 데이터는 이미 사라졌습니다.

즉,

Schema Rollback과 Data Rollback은 서로 다른 문제입니다.

이 경험 때문에 기존 데이터가 변경되거나 삭제될 가능성이 있는 Migration에서는 반드시 Backup을 함께 고려하도록 했습니다.

예를 들어 기존 컬럼을 변경해야 한다면 기존 컬럼을 바로 삭제하지 않고 Backup 컬럼으로 남겨둘 수 있습니다.

ALTER TABLE sample
RENAME COLUMN A TO A_7_1_3;

ALTER TABLE sample
ADD COLUMN A VARCHAR(255);

UPDATE sample
SET A = A_7_1_3;

기존 A 컬럼은 A_7_1_3이라는 이름으로 보존됩니다.

새로운 버전에서 문제가 발생하면 새로 생성한 컬럼을 제거하고 기존 컬럼을 다시 복원합니다.

ALTER TABLE sample
DROP COLUMN IF EXISTS A;

ALTER TABLE sample
RENAME COLUMN A_7_1_3 TO A;

테이블 전체에 대한 Backup이 필요한 경우에는 Backup Table을 생성합니다.

CREATE TABLE user_7_1_3 AS
SELECT *
FROM user;

Rollback 시에는 이를 이용하여 원래 테이블을 복원할 수 있습니다.

DROP TABLE IF EXISTS user;

ALTER TABLE user_7_1_3
RENAME TO user;

저희는 Backup Object의 이름에도 Migration Version을 포함하는 규칙을 사용하고 있습니다.

예를 들면 다음과 같습니다.

email_7_1_3
user_7_1_3

이를 통해 어떤 Migration을 위해 생성된 Backup인지 확인할 수 있습니다.

결국 현재는 하나의 Migration 작업을 다음 세 가지로 보고 있습니다.

Migration

│

├─ Backup

├─ Forward Migration

└─ Rollback

특히 Forward Migration을 먼저 만든 뒤 Rollback 방법을 생각하는 것이 아니라, Migration을 작성하는 시점에 Rollback과 Backup을 같이 설계해야 한다는 점이 중요했습니다.

Migration을 완료한 뒤에 Rollback 방법을 고민하기 시작하면 이미 필요한 데이터가 삭제된 이후일 수도 있기 때문입니다.

현재 가이드에서도 컬럼명 변경, 데이터 타입 변경, 데이터 수정, 테이블 구조 변경, 삭제 등의 작업에서는 Backup을 필수로 작성하도록 규칙을 두고 있습니다.

6. 첫 번째 시행착오: Baseline 관리

Downloadable Application은 기존 환경의 Update뿐 아니라 새로운 환경에 대한 신규 설치도 지원해야 합니다.

문제는 Application이 오래 운영될수록 Migration Script가 계속 증가한다는 점입니다.

예를 들어 다음과 같이 수십 개의 Migration이 존재할 수 있습니다.

V7_0_1
V7_0_2
V7_0_3
...
V7_1_1
V7_1_2
V7_1_3
...

새로운 환경을 설치할 때 최초 버전부터 모든 Migration을 순서대로 수행하는 것은 불필요한 작업이 많습니다.

어떤 Migration에서는 테이블을 만들고 몇 버전 뒤에 바로 삭제할 수도 있습니다. 신규 설치에서는 이미 최종 구조를 알고 있는데도 이러한 과거의 변경 과정을 모두 거쳐야 합니다.

처음에는 이 문제를 해결하기 위해 Minor Version별 최종 Schema를 표현하는 별도의 Baseline SQL을 관리했습니다.

baseline/

└─ postgresql/

├─ 7.0.sql

└─ 7.1.sql

Baseline에는 해당 Minor Version 시점의 전체 Table, Index, Constraint 등 최종 Schema를 작성했습니다.

Flyway Migration과는 별개의 Snapshot을 하나 더 관리한 것입니다.

처음에는 신규 설치를 단순화할 수 있다는 장점이 있었습니다.

하지만 시간이 지나면서 문제점도 분명해졌습니다.

가장 큰 문제는 동일한 Database Schema를 사실상 두 곳에서 관리해야 한다는 것이었습니다.

Incremental Migration

→ 기존 DB가 어떻게 변경되는가

Baseline

→ 신규 DB가 어떤 상태로 만들어지는가

개발자가 새로운 Migration을 작성했지만 Baseline을 함께 수정하지 않는다면 문제가 발생합니다.

기존 Database를 Update한 결과와 신규 Database를 설치한 결과가 서로 달라질 수 있습니다.

결국 실제 Migration 이력과 Snapshot Baseline 사이의 정합성을 사람이 계속 유지해야 하는 구조였습니다.

Flyway를 사용해 자동화를 하면서 다른 한편에서는 다시 수동 관리 요소를 만들어 놓은 셈이었습니다.

7. Baseline 구조를 Initial Migration으로 변경했습니다

이 문제를 개선하기 위해 Baseline 구조를 다시 정리했습니다.

별도의 Baseline Snapshot 파일을 제거하고, 각 Minor Version의 최초 Migration에 해당 버전의 전체 Schema DDL을 포함하도록 변경했습니다.

예를 들어 7.1이라면 다음 파일이 반드시 존재합니다.

V7_1_0__Initial.sql

Patch Version 0을 해당 Minor Version의 Initial Migration으로 사용합니다.

전체 구조는 다음과 같습니다.

postgresql/

├─ V7_1/

│ ├─ V7_1_0__Initial.sql

│ ├─ V7_1_1__Create_User.sql

│ └─ V7_1_2__Modify_User.sql

│

└─ V7_2/

├─ V7_2_0__Initial.sql

├─ V7_2_1__Create_History.sql

└─ V7_2_2__Modify_User.sql

V7_1_0__Initial.sql에는 7.1 버전을 신규 설치하기 위해 필요한 전체 Schema DDL을 작성합니다.

7.1 개발 과정에서 Incremental Migration이 추가되고 7.2 개발을 시작하게 되면, 7.1의 최종 Database Schema를 기준으로 V7_2_0__Initial.sql을 작성합니다.

V7_1_0__Initial

↓

V7_1_1

↓

V7_1_2

↓

7.1 Final Schema

↓

V7_2_0__Initial

이렇게 하면 각각의 Minor Version이 독립적인 신규 설치 시작점을 가질 수 있습니다.

그리고 별도의 Baseline Snapshot과 Incremental Migration 사이의 정합성을 관리할 필요도 줄어듭니다.

물론 기존 7.1 Database를 7.2로 Update할 때 V7_2_0__Initial.sql 전체를 기존 Schema에 다시 실행해서는 안 됩니다.

따라서 신규 설치와 기존 환경 Update에서 실행 대상을 구분하는 전략은 별도로 필요합니다.

이 부분 역시 단순히 SQL 파일을 만드는 것만으로 Migration 설계가 끝나는 것이 아니라, 신규 설치 경로와 Update 경로를 동시에 고려해야 한다는 점을 알게 된 사례였습니다.

8. 두 번째 시행착오: 여러 개발자가 Migration을 작성할 때

또 하나 예상보다 자주 문제가 되었던 부분은 Migration Version 관리였습니다.

한 명이 순차적으로 모든 Migration을 작성한다면 Version을 관리하는 것이 어렵지 않습니다.

하지만 실제 프로젝트에서는 여러 개발자가 서로 다른 Feature Branch에서 동시에 개발합니다.

예를 들어 현재 최신 Migration이 다음과 같다고 가정하겠습니다.

V7_2_2

Developer A와 Developer B가 각각의 Branch에서 동시에 Schema를 변경합니다.

Developer A는 다음 Migration을 만듭니다.

V7_2_3__Create_User.sql

Developer B 역시 자신이 작업을 시작한 시점에는 최신 Version이 V7_2_2였기 때문에 다음 Migration을 만듭니다.

V7_2_3__Create_Position.sql

각 Branch에서는 아무런 문제가 발생하지 않습니다.

문제는 두 Branch가 Main Branch에 Merge될 때 발생합니다.

V7_2_3__Create_User.sql
V7_2_3__Create_Position.sql

동일한 Version의 Migration이 두 개가 됩니다.

아직 어느 환경에도 Migration이 실행되지 않았다면 비교적 쉽게 해결할 수 있습니다.

Main Branch를 최신 상태로 받은 뒤 나중에 Merge되는 Migration의 Version을 변경하면 됩니다.

하지만 이미 개발 또는 공유 환경에 해당 Migration이 실행된 상태라면 단순한 Rename으로 끝나지 않을 수도 있습니다.

Flyway는 Migration Version과 실행 결과를 flyway_schema_history에 기록하기 때문입니다.

이 문제를 경험한 이후에는 Migration Version은 Script 작성 시점뿐 아니라 Main Branch Merge 시점에 다시 확인해야 한다는 규칙을 두게 되었습니다.

현재는 다음과 같은 흐름을 기준으로 관리하고 있습니다.

Feature 개발

↓

Migration 작성

↓

Main Branch 최신화

↓

최신 Migration 확인

↓

Version 중복 여부 확인

↓

필요 시 Version 재조정

↓

Main Merge

9. 상위 Version이 먼저 실행되는 문제

동일 Version 충돌뿐 아니라 Migration의 실행 순서가 꼬이는 문제도 있었습니다.

예를 들어 두 개의 Migration이 있다고 가정하겠습니다.

V7_2_7
V7_2_8

Version만 보면 당연히 다음 순서를 기대합니다.

V7_2_7

↓

V7_2_8

하지만 두 Migration이 서로 다른 Branch에서 개발되고 배포되는 과정에서는 실제 Merge 또는 Release 순서가 달라질 수 있습니다.

상위 Version인 V7_2_8이 먼저 특정 환경에 적용되는 상황이 발생할 수 있습니다.

V7_2_6

↓

V7_2_8

이후 V7_2_7이 Repository에 추가되면 Repository에서 기대하는 Migration 순서와 실제 Database에 기록된 실행 이력이 달라집니다.

이 상황을 단순히 파일 이름을 바꾸거나 History를 수정해서 해결하는 것은 위험합니다.

이미 실행된 Migration은 실제 Database Schema 변경과 연결되어 있기 때문입니다.

이 경험을 통해 Migration Version을 단순한 파일의 정렬 기준으로 보는 것이 아니라 Database Schema가 변경되는 실제 순서를 나타내는 운영 정보로 봐야 한다는 것을 알게 되었습니다.

따라서 현재는 다음과 같은 원칙으로 관리하고 있습니다.

Migration을 포함한 Branch Merge 전에 최신 Migration Version을 확인합니다.
동일 Version이 존재하는지 확인합니다.
하위 Version이 아직 배포되지 않은 상태에서 상위 Version이 먼저 배포되지 않도록 확인합니다.
이미 실행된 Migration의 Version이나 내용을 임의로 수정하지 않습니다.
배포 전에 Pending Migration과 실행 순서를 확인합니다.
문제가 발생했을 때 repair를 단순한 Version 정리 목적으로 사용하지 않습니다.

Flyway를 사용하면서 기술적인 SQL 작성뿐 아니라 Git Branch와 Release Process도 Database Migration의 일부라는 점을 체감한 사례였습니다.

10. 적용 후 정리한 Migration 원칙

Flyway를 처음 도입했을 당시에는 다음과 같이 생각했습니다.

Migration
    =
Application 실행 시 자동으로 수행할 SQL

실제로 여러 버전을 업데이트하고 시행착오를 겪으면서 현재는 조금 다르게 생각하고 있습니다.

Migration

Database 변경 방법

+ 반복 실행에 대한 안전성

+ 데이터 보존 방법

+ 장애 시 복구 방법

+ Version 및 실행 순서 관리

현재 Migration을 작성할 때는 다음 내용을 확인합니다.

신규 설치

Minor Version의 Initial Migration이 존재하는지 확인합니다.
Initial Migration만으로 해당 버전의 기본 Schema를 생성할 수 있어야 합니다.
신규 설치 후 Application이 정상적으로 실행되어야 합니다.

Incremental Migration

기존 운영 Database 상태를 기준으로 작성합니다.
가능한 한 멱등성을 보장합니다.
이미 실행된 Migration은 수정하지 않습니다.
Database 변경에 의해 기존 데이터가 영향을 받는지 확인합니다.

Backup과 Rollback

Forward Migration을 작성할 때 Rollback Script를 함께 작성합니다.
데이터 변경 또는 삭제가 발생한다면 먼저 Backup 방법을 정합니다.
Rollback 후 Schema뿐 아니라 데이터도 복원 가능한지 확인합니다.

Version 관리

Main Branch 병합 전에 최신 Migration Version을 확인합니다.
Version 중복 여부를 확인합니다.
실제 배포 순서와 Migration Version 순서가 일치하는지 확인합니다.
이미 실행된 Migration Version을 임의로 변경하지 않습니다.

현재 프로젝트에서는 이러한 항목들을 Migration 작성 및 검증 가이드로 정리하여 사용하고 있습니다.

11. 마치며

Flyway를 도입한 직접적인 이유는 Vizend Application의 특성 때문이었습니다.

Application을 사용자가 직접 다운로드하여 설치하고 새로운 버전으로 업데이트할 수 있기 때문에, Application Update와 함께 Database Schema 역시 자동으로 업데이트할 수 있어야 했습니다.

Flyway는 이러한 요구사항을 구현하기 위한 좋은 기반을 제공했습니다.

하지만 실제 적용 과정에서 알게 된 것은 Flyway를 사용한다고 해서 Database Migration이 자동으로 안전해지는 것은 아니라는 점이었습니다.

Flyway는 어떤 Migration이 실행되었는지 기록하고 아직 적용되지 않은 Migration을 정해진 순서에 따라 실행해줍니다.

하지만 해당 Migration이 반복 실행에 안전한지, 변경된 데이터를 복구할 수 있는지, Rollback 방법이 준비되어 있는지까지 Flyway가 대신 판단해주지는 않습니다.

또한 여러 개발자가 동시에 Migration을 작성하는 환경에서는 Git Branch의 Merge 순서와 Release 순서까지 함께 고려해야 했습니다.

결국 실제 프로젝트에서 Flyway를 안정적으로 사용하기 위해 가장 중요했던 것은 도구 자체의 기능보다 Migration을 어떻게 작성하고 관리할 것인지에 대한 팀의 규칙이었습니다.

현재 제가 Migration을 작성할 때 가장 먼저 확인하는 것은 다음 세 가지입니다.

다시 실행해도 안전한가?

문제가 발생하면 되돌릴 수 있는가?

되돌리기 위해 필요한 데이터가 남아 있는가?

처음에는 SQL을 자동으로 실행하기 위해 Flyway를 도입했지만, 실제 적용 경험을 통해 Database 변경 역시 Application 코드와 마찬가지로 변경 방법뿐 아니라 실패와 복구까지 함께 설계해야 하는 대상이라는 점을 배우게 되었습니다.

참고 자료

본 글에서 소개한 Flyway Migration 작성 및 운영 규칙은 실제 프로젝트에서 사용 중인 내부 가이드를 기반으로 정리하였습니다.

Flyway 기반 DB Migration 가이드

https://vizend.notion.site/Flyway-DB-Migration-2e635bc54c138022a9d0f6c6c3b47695?pvs=74

David