💬 DB 마이그레이션 도구 비교: Flyway vs Liquibase

[Jin409]

안전한 엔티티의 변경 및 유지를 위해 DB 마이그레이션 도구를 도입하고자 합니다.

저는 flyway 가 더 적합할 것이라는 결론을 내렸어요! 다른 의견이나 반박 환영해요 🤗
다음 글을 읽어보고, 자유롭게 의견 주시면 감사하겠습니다~!

📌 비교 대상

Flyway vs Liquibase

---

🔎 선정 기준

• 실무에서 가장 널리 쓰이는 마이그레이션 도구
• 두 도구를 중심으로 비교한 블로그나 문서가 다수 존재함

---

1. 선언 방식 차이

✅ Liquibase 예시 (XML DSL)

<databaseChangeLog
  xmlns="http://www.liquibase.org/xml/ns/dbchangelog"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://www.liquibase.org/xml/ns/dbchangelog
                      http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-3.8.xsd">

  <changeSet id="1" author="jinseunghui">
    <createTable tableName="member">
      <column name="id" type="BIGINT" autoIncrement="true">
        <constraints primaryKey="true"/>
      </column>
      <column name="nickname" type="VARCHAR(50)">
        <constraints nullable="false"/>
      </column>
      <column name="gender" type="VARCHAR(10)">
        <constraints nullable="false"/>
      </column>
      <column name="weight" type="DOUBLE"/>
    </createTable>
  </changeSet>
</databaseChangeLog>

💡 위 XML은 아래 SQL과 동일
```sql
CREATE TABLE member (
  id BIGINT AUTO_INCREMENT PRIMARY KEY,
  nickname VARCHAR(50) NOT NULL,
  gender VARCHAR(10) NOT NULL,
  weight DOUBLE
);

Liquibase XML	대응되는 SQL
<createTable>	CREATE TABLE ...
<column name="x" type="..."/>	각 컬럼 정의
<constraints primaryKey="true"/>	PRIMARY KEY, NOT NULL, UNIQUE 등 제약조건
<changeSet id="1">...</changeSet>	하나의 버전 단위. Git 커밋처럼 관리됨

✅ Flyway 예시 (SQL 기반)

-- V1__create_member.sql
CREATE TABLE member (
  id BIGINT AUTO_INCREMENT PRIMARY KEY,
  nickname VARCHAR(50) NOT NULL,
  gender VARCHAR(10) NOT NULL,
  weight DOUBLE
);

📌 정리

• Flyway: SQL 직접 작성 → 학습 비용 낮음, 직관적
• Liquibase: DSL 형태 → 도메인 언어에 가까움 (추상화 높음), 러닝커브 존재

2. 롤백 지원 여부

✅ Liquibase

<changeSet id="2" author="jin">
  <addColumn tableName="member">
    <column name="age" type="int"/>
  </addColumn>
  <rollback>
    <dropColumn tableName="member" columnName="age"/>
  </rollback>
</changeSet>

• Liquibase는 롤백이 가능

❌ Flyway

-- V3__remove_age.sql
ALTER TABLE member DROP COLUMN age;

• 직접 DROP COLUMN SQL 스크립트를 새 파일로 작성해야 함
• 버전을 “되돌리는 것”은 불가능 → 새로운 버전으로 덮는 방식

📌 정리

• Liquibase는 rollback 문법 내장
• Flyway는 롤백 시 새로운 스크립트를 추가해야 함 (되돌림이 아니라 ‘덮어쓰기’)

3. Java API 제공 여부

✅ Flyway (직접 실행 가능)

Flyway flyway = Flyway.configure()
    .dataSource("jdbc:mysql://localhost:3306/test", "user", "pw")
    .locations("classpath:db/migration")
    .load();

flyway.clean();
flyway.migrate();

Java 코드를 통해서도 마이그레이션 사용 가능

다음과 같은 상황에서 사용하기 용이

• 테스트에서 직접 DB 초기화/재적용
• 다중 DB 마이그레이션을 동적으로 수행할 때
• 특정 조건/환경에 따라 동적 실행할 때

테스트 시에 특히 용이

@BeforeEach
void setUp() {
    flyway.clean();
    flyway.migrate();
}

위와 같은 형태로 테스트 시 필요하면 사용 가능

✅ Liquibase (SpringLiquibase 사용)

@Configuration
public class LiquibaseConfig {
  @Bean
  public SpringLiquibase liquibase(DataSource dataSource) {
    SpringLiquibase liquibase = new SpringLiquibase();
    liquibase.setDataSource(dataSource);
    liquibase.setChangeLog("classpath:db/changelog/db.changelog-master.yaml");
    liquibase.setContexts("dev,test");
    return liquibase;
  }
}

LiquiBase 는 Java API 는 제공되지 않지만, Spring 과 통합된 상황에서는 용이하게 사용 가능

@LisuiBaseBean 이 존재

Spring Boot 환경에서 Liquibase를 Java Bean으로 수동 구성할 때 사용하는 Spring용 설정 클래스

• 보통은 application.yml로 Liquibase를 자동 실행하지만, 특별한 설정이 필요할 때 직접 SpringLiquibase 빈을 등록해 제어 가능
• 상황에 따라서 다른 SpringLiquibase 빈을 주입해 유연하게 사용 가능

다양한 데이터베이스 형태 제공

❌ flyway 는 RDBMS 만 제공
✅ LiquiBase 는 NoSQL 중 MongoDB 만 공식적으로 지원

Spring Boot 통합

✅ 두 도구 모두 Spring Boot 에서 공식적으로 지원

항목	설명
자동 실행	Spring Boot 시작 시 자동으로 마이그레이션 수행
JDBC 연동	DB URL, username/password 지정 가능
Profile에 따라 분기 가능	예: application-dev.yml, application-prod.yml로 분리
테스트 시 유용	H2 등 내장 DB 테스트에서도 자동 반영 가능

spring:
  flyway:
    enabled: true
    locations: classpath:db/migration
    baseline-on-migrate: true
    user: myuser
    password: secret
    url: jdbc:mysql://localhost:3306/mydb

spring:
  liquibase:
    enabled: true
    change-log: classpath:db/changelog/db.changelog-master.yaml
    contexts: test
    default-schema: public
    user: myuser
    password: secret
    url: jdbc:postgresql://localhost:5432/mydb

스키마 자동 생성

flyway 와 LiquiBase 모두 불가능
수동으로 사용자가 정의해줘야 함

그러나 flyway 는 직접 쿼리를 작성하지만, Liquibase 는 DSL 과 같이 도메인에 더 가깝게 정의하면 이를 SQL 로 변환해준다는 차이점은 존재.

조금 더 LiquiBase 가 도메인 측면에 가까운 추상화된 형태

databaseChangeLog:
  - changeSet:
      id: 1
      author: jin
      changes:
        - createTable:
            tableName: member
            columns:
              - column:
                  name: id
                  type: bigint
                  autoIncrement: true
                  constraints:
                    primaryKey: true
              - column:
                  name: name
                  type: varchar(255)

위와 같이 조금 더 '언어'에 가까워 비개발자도 이해하기 용이할 수 있음

🔚 최종 판단

✅ Flyway
• SQL 친숙하고 직관적인 방식
• 러닝커브 적음
• 테스트 시 유연하게 활용 가능

✅ Liquibase
• DSL 기반 선언 → 비개발자도 접근 가능
• 롤백 기능 등 풍부한 기능 제공
• 단, DSL 학습이 필요 → 팀 상황 고려

💬 현재 물깜 프로젝트 팀 상황에서는
→ 러닝커브가 적고, SQL 기반의 Flyway가 적합하다고 판단됨

[CheChe903]

1. 롤백 기능이 꼭 필요할까 ?

덮어쓰기가 가능하다면 롤백이 굳이 필요할 것 같다는 생각이 들지 않네요!

2. DSL 기반 선언은 분명 비개발자에게 좋지만, 현재 상황에는 저희밖에 보지 않을 것이라 판단하기 때문에,

이 두 기능이 필요해진 시점에 Liquibase로 바꾸는 것이 맞다는 생각이 드네요 !

고생하셨습니다.

[2Jin1031]

와우 ~ 깔끔한 정리 감사합니다 ㅎㅎ
덕분에 빠르게 이해하기 수월했어요! 😊

이 글에서 flyway와 liquibase의 비교 대상은 크게 3가지 (선언 방식, 롤백 지원, JAVA API 적용) 이었는데요
세번째인, JAVA API는 둘 다 충족하고 있으니 넘기고

선언 방식에서는 flyway, 롤백 지원에서는 liquibase 가 이점을 갖고 있는 것으로 이해했습니다 :)
둘 다 각기 다른 부분에서의 확실한 이점인 것 같아 좀 더 depth를 더 들어가서 토의를 진행하기 위해 질문을 해보려고 합니다.

1. liquibase의 선언 방식은 러닝 커브가 얼마나 높을까?
2. 롤백은 얼마나 자주 일어날까?

저의 경우 1번은 그리 높지 않아 보였습니다. Liquibase는 XML 기반이라 초기 진입 장벽이 있어 보일 수 있으나, 패턴이 일정해 템플릿화 가능하여 러닝 커브가 그리 높지는 않다는 판단이 들었습니다.
2번의 경우 피드백 기반의 애자일 구조에서 스키마 변경이 빈번할 경우, 롤백 기능의 중요성이 커지기에 실수나 장애 발생 시 빠른 대응이 가능하다는 점에서 liquibase가 우위를 갖는다는 생각이 들었습니다.

---

아래의 블로그에서 좀 더 많은 기능비교표를 찾아볼 수 있어서 첨부합니다

(출처: https://shiba-holic.tistory.com/26)

여기서 프로젝트에 적용할 수 있는 항목을 정리해본 결과 다음과 같습니다.

1. DB 상태에 대한 스냅샷 제공 여부
   -> 로직 변경 시, 어떤 상태에서 어떤 변경이 발생했는 지 추적할 수 있음

2. 롤백 기능
   -> 배포 오류 시 빠르게 롤백할 수 있음

3. 저장된 논리와 함께 작동
   -> 버전 상태 추적을 통합할 수 있음

이러한 기능들이 개발 이후 유지보수 및 실시간 대응 측면에서 결정적일 거라고 생각도 들었던 것 같습니다.

하지만, liquibase가 많은 기능을 지원하고 있지만, 좀 더 수월하게 개발할 수 있다는 장점에서 flyway를 선택하는 분들도 계신 것 같아서
(출처: https://341123.tistory.com/20)
다른 분들의 의견도 들어보고 싶습니다 🙌

[Jin409]

칼리! 우선 의견 주셔서 감사합니다 (__)

✅ 러닝 커브 관련

오 칼리는 러닝 커브가 그리 높지 않다고 판단했군요 ㅎㅎ
저와 칼리의 판단이 다른 것처럼 러닝 커브는 지극히 개인적인 의견이라고 생각해요. 그래서 이건 팀원들의 이야기를 들어 참고해봐도 좋을 것 같습니다!

---

저도 칼리가 제공해준 블로그를 이미 봤었는데도 칼리의 코멘트를 보고 한 뎁스 더 깊게 들어가서 고려해봤더니, Liquibase 가 더 좋은 선택지일수도 있으려나..? 하는 생각을 하게 됐네요! 다양하게 고민해볼 수 있는 여지를 주셔서 고마워요 칼리 💘

다음은 생각이 바뀐 사고의 과정을 다시 정리해봤습니다.

✅ 데이터베이스와 에자일

칼리의 에자일 이라는 말에 주목해서 관련된 글을 읽어봤어요!
글에서 작성자 2인은 애플리케이션 상의 코드뿐만 아니라 데이터베이스 역시도 애자일하게 관리되어야 한다고 주장해요.

그래서 해당 버전으로 롤백을 하게 된다면, 코드 뿐만 아니라 데이터베이스도 이에 맞춰 애플리케이션이 돌아갈 수 있는 환경이 갖춰져야 한다는 요지인 것 같아요.

그렇기에 임시 sql 을 절대로 실행하면 안되고, flyway 와 Liquibase 에서 제공하는 스크립트로만 구동되어야 한다고 이야기해요.
임시로 각각의 개발자가 실행한 스크립트는 버저닝이 되지 않기 때문이죠! 그렇기에 CI 환경에서 누군가가 임시 스크립트를 돌리지는 않았는지 확인하고 검증해줘야 한다고 해요.

✅ Lqiuibase 와 애자일

DB 상태에 대한 스냅샷 제공

저는 굳이 우리가 스냅샷을 알아야 할까? 라는 생각이 처음에는 강했어요. 어차피 스크립트로 관리가 되는 걸 뻔히 아는데 스냅샷을 둬서 좋을 게 뭐지? 만약 저장이 되는거라면 괜한 리소스 낭비를 하는 게 아닐까? 하는 의심을 했었어요.

그러나 앞서 언급한 DB 상의 에자일을 알고 나니, 스냅샷을 통해 매번 누군가가 임시로 스크립트를 실행하지는 않았는지, 그리고 이로 인해 버저닝이 제대로 되지 않지는 않을지에 대한 고려가 필요하다는 생각을 하게 됐어요.

# Step 1: 현재 운영 DB 상태 스냅샷 저장
liquibase snapshot \
  --url=jdbc:mysql://prod-db \
  --username=prod_user \
  --password=secret \
  --outputFile=current-prod-snapshot.json

# Step 2: 최신 changelog 기반 이론상 구조 생성
liquibase snapshotReference \
  --changelogFile=changelog-master.xml \
  --outputFile=expected-snapshot.json

# Step 3: 두 스냅샷 비교
liquibase diff \
  --referenceFile=expected-snapshot.json \
  --targetFile=current-prod-snapshot.json

이런 식으로 스냅샷 비교를 해서 임시 스크립트 실행 여부를 검증해 데이터의 정합성을 유지할 수 있다고 하네요!

롤백 관련

사실 저는 롤백 관련해서는 본문에 언급한 것과 같이, 사용되는 개념이 다를 뿐(flyway 는 새로운 스크립트 작성해서 DROP / Liquibase 는 롤백 스크립트를 작성해서 롤백) 결과는 동일하다고 생각해서 별다른 장점을 느끼지 못하긴 했어요..!

그러나 Liquibase 는 명시적으로 '롤백'인 반면, flyway 는 롤백을 가장한 또 다른 스크립트를 작성하는 것이니 작성하는 개발자 입장에서는 또 다르게 느낄 수도 있을 것 같아요 ㅎㅎ

저장된 논리와 함께 작동

이 부분도 사실 저는 Liquibase 만의 장점이라고 명확하게 느끼지 못하긴 했어요.

논리 라는 말이 모호한 것 같아서 찾아보니 프로시저, 트리거, View 에 대한 것들이더라구요!
아직 제가 경험이 적고, 큰 데이터베이스를 다뤄보지 않은 상태이기에 느끼는 바가 다를 수도 있지만 이는 저희가 지양하는 방식이라는 생각이 들기는 했어요.

결론적으로 데이터베이스 레벨에서 해당 논리들이 적용되면, 코드 상으로 드러나지 않기 때문에 오히려 가독성과 안정성을 해칠 수 있다고 생각해 저는 '논리'를 저장할 수 있단 것에 대한 큰 이점을 느끼지 못했어요.

부가적으로 flyway 역시도 sql 스크립트로만 작성하면 해당 논리들을 적용할 수 있다고 하네요..!

🧞‍♂️ 세줄요약

• 에자일 관점에서는 Liquibase 가 개념상으로 더 좋은 도구인 것 같다.
• Liquibase 가 다양한 기능들을 제공한다.
• 그러나 flyway 역시도 이들 중 대부분을 sql 상으로 제공 가능하다.

그래서?

고민이 된다 🤔 더 의견을 나눠보고 결정해보는 게 좋겠다!

[minSsan]

히로가 남긴 글과 코멘트들도 잘 읽었어요.

프로젝트 상황 고려

개인적으로 비교적 많은 기능을 지원하는 Liquibase가 더 매력적이긴 하지만, 현실적으로 생각했을 때 지금은 Flyway를 적용하는게 더 나을 것 같아요.

저희 프로젝트 목표가 일단 MVP를 빠르게 뽑아내는 것인데, '이 상황에서 DB 마이그레이션 도구에 대해서 따로 학습을 진행하는 것이 현실적으로 가능할까?' 의구심이 들었습니다.

특히나 배포 이전 단계에서는 기술적/기능적인 욕심보다는, 일단 빠르게 적용 가능한 것을 선택하는 것이 좋다는 의견이에요.

실제로 기술적인 욕심 때문에 배포 날짜가 차일피일 미뤄진 경험이 있어서, 이러한 입장을 가지게 된 것도 있어요

정리 / 결론

따라서 낮은 러닝커브 뿐만 아니라 히로가 이미 Flyway 적용 경험이 있기 때문에, 지금 저희 프로젝트 상황에서는 일단 빠르게 적용해볼 수 있는 Flyway가 좋다는 의견입니다.
그리고 적용 과정에서 Flyway에서 제공하지 않는 기능 때문에 불편함을 느끼게 되면, 그때 Liquibase로 변경하는 것을 고려해도 괜찮다고 생각해요.

[Jin409]

@minSsan @2Jin1031 @CheChe903

밍곰은 Liquibase 의 러닝 커브가 높다고 느껴진 것으로 보이고, 칼리는 러닝 커브가 그렇게 높지 않을 것으로 예상한 것처럼 보입니다.
체체는 Liquibase 가 제공하는 기능들을 현시점에 굳이 다 사용할 필요 없다고 느껴지는 것 같네요!

또한 밍곰과 체체 모두 필요해지는 시점에 바꾸어도 될 것 같다는 의견인 것 같습니다.

저 역시도 Liquibase 의 러닝 커브가 어느 정도 높다고 느껴졌어요. 사실 저는 오히려 DSL 기반의 선언 방식보다 현재 SQL 이 더 직관적이라는 생각을 했습니다. 그리고 flyway 에 대한 동작 방식을 어느 정도 제가 익히고 있어, 밍곰의 말대로 현실적인 속도와 타협해 현재는 flyway 를 통해 툴을 세팅해볼까 싶습니다.

다른 의견 있으면 코멘트 부탁해요!

[2Jin1031]

완전 동의합니다~~

현재 Liquibase의 다양한 기능들을 적극적으로 활용하고 있지는 않으며,
지금 상황에서 Flyway 도입은 DB 마이그레이션 목적에 충분히 부합하고,
무엇보다 빠르게 적용할 수 있다는 점에서 큰 장점이 있다고 느꼈습니다.

빠르게 구현해야 하는 상황에서
이미 익숙하게 사용해본 도구가 매력적으로 다가오는 건 자연스러운 일이고,
그 방향 역시 충분히 설득력 있는 선택이라고 생각합니다.

다만, 기술 스택을 결정하는 과정에서는
처음부터 방향을 정해두기보다는
다른 선택지들에 대해서도 함께 이야기해보고 싶었습니다.
Flyway 자체보다도, 어떤 기준으로 도구를 선택할지에 대해 고민을 나눠보고 싶었던 바람이 있었습니다.

그래서 처음 댓글을 달 때,
조금은 다른 입장에서 코멘트를 남겨보았고,
이 논의에 함께 적극적으로 참여해주신 덕분에
저도 더 다양한 관점과 인사이트를 얻을 수 있었습니다. 감사합니다!

Flyway 가시죠~~ㅎㅎ

[CheChe903]

동의합니다 !

가만히 있어도 정보가 들어오는 기분은 참 좋네요

[minSsan]

확인했습니다~

[CheChe903]

해당 부분을 고려한 이유: 컵 엔티티의 칼럼인 amount를 cupAmount로 변경했는데, ddl을 update로 두었더니 칼럼이 지워지지 않고 생기기만 하는 현상 발생 -> 찾는데 시간 걸렸음. ddl을 꼭 믿어야할까 라는 의심에서 시작