[물깜] Flyway를 고르기까지 - DB 의 마이그레이션도 에자일해야 해

🤔 왜 DB 스키마 마이그레이션 도구의 도입을 고민하게 되었는가

에자일 한 방식으로 1차 데모데이 / 2차 데모데이를 거치면서 개발에 임하고 있는 현재, 계속해서 엔티티의 구성이 달라지는 것은 당연하다. 우리 팀의 경우에도 기획에 2-3번은 엎어지고, 일부가 조금씩 수정되기도 했다. 뿐만 아니라 팀원 간의 이해가 조금씩 어긋나서 엔티티의 구조가 달라지는 경우도 허다했다. 그렇기에 DB 스키마 마이그레이션 도구가 필요할 것이라는 예상은 하고 있었다. 그러나 생각보다 빨리 필요성을 느끼게 되었다. 배포 환경에서 500 에러가 터졌기 때문이다. 

왜 문제 상황이 발생했을까?

기존에 amount 라는 필드가 존재했다. 그러나 이의 명확성을 위해 cupAmount 라는 필드명으로 변경했다.

그러나 운영 환경의 ddl-auto 가 update 였기에 amount 라는 필드는 사라지지 않고, cupAmount 라는 필드가 추가 됐다.

 

이는 해당 API 가 실제로 실행이 될 때, 런타임에 500 에러를 뱉어냈고 우리는 패닉이 왔었다. 그 때 바로 마이그레이션 도구를 도입해야겠다는 결론을 내렸다!

ddl-auto 로는 충분치 않은가?

create	실행 시 테이블을 모두 제거 후 새로 생성	❌ 운영 데이터 삭제
create-drop	종료 시점에 테이블도 삭제	❌ 테스트 외 불가
update	구조 변경 감지 시 DB에 반영	⚠️ 변경 내역 추적 불가 / 일부 변경 누락 가능
validate	DB와 Entity의 일치 여부만 확인	✅ 안전하지만 변경 반영은 직접 해야 함
none	아무 작업도 수행하지 않음	✅ 마이그레이션 도구 사용 시 적합

 

절대 충분치 않다. ddl-auto 를 아무렇게나 운영 환경에서 사용하면 엄청난 위험이 따른다.

위의 표에 정리한 것과 같이 운영환경에서는 validate 혹은 none 으로 설정해두고, 직접 변경을 반영해줘야 한다.

🤔 Liquibase vs Flyway

새로운 기술을 도입할 때에는 뭐든 이유가 필요하다.

그렇기에 기존에 사용해본 경험이 있는 Flyway 를 적용하기 전에 주로 사용되는 다른 툴과 비교해보았다.

 

가장 많이 사용되는 도구는 Liquibase 와 Flyway 였다. 이를 토대로 비교를 시작했다.

다음은 팀원들과 논의하기 위해 남겨뒀던 discussions 내용의 전문이다.

---

 

https://github.com/woowacourse-teams/2025-mul-kkam/discussions/122

💬 DB 마이그레이션 도구 비교: `Flyway` vs `Liquibase` · woowacourse-teams 2025-mul-kkam · Discussion #122

 

 

🔎 선정 기준

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

---

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가 적합하다고 판단됨

---

🧞‍♂️ DB 도 결국 에자일해야 한다

 

이렇게 올렸던 디스커션에 팀원인 칼리👏🏻 가 위와 같은 코멘트를 남겨주었다. 이 코멘트에서 나는 주목한 단어가 있었다. 에자일! ❇️

DB 도 결국 우리의 서비스를 이루는 주요한 부분 중 하나인데, 왜 에자일해야 한다는 생각을 하지 못했을까? 하는 생각을 하게 됐다.

 

그래서 이런 저런 소스들을 찾아보던 중, 다음 글을 보게 됐다.

 

https://martinfowler.com/articles/evodb.html

Evolutionary Database Design

 

이 글의 주된 요지는 다음과 같다.

• 애플리케이션 상의 코드뿐만 아니라 데이터베이스 역시도 애자일하게 관리되어야 한다
• 해당 버전으로 롤백을 하게 된다면, 코드 뿐만 아니라 데이터베이스도 이에 맞춰 애플리케이션이 돌아갈 수 있는 환경이 갖춰져야 한다
• 임시 sql 을 절대로 실행하면 안되고, 마이그레이션 도구에서 제공해주는 스크립트로만 구동되어야 한다

그렇다면, 에자일하게 관리될 수 있도록 돕는 DB 마이그레이션 도구는 다음과 같아야 한다는 게 내 생각이었다.

 

1. 롤백이 쉬워야 한다. -> 언제든 애플리케이션 도구와 함께 버저닝이 손쉽게 되어야 한다.

2. 누군가 깃허브와 같은 버전으로 관리되는 스크립트 이외에 임의로 실행한 스크립트가 없는지 검증이 되어야 한다.

 

이러한 요소로 따져보았을 때에는, Liquibase 의 다음 요소들을 떠올려봤을 때 가장 적합한 도구라는 생각을 했다.

 

1. Liquibase 는 명시적으로 롤백이 존재한다.

2. diff 를 통해 변경 사항을 추적하는 등 임시 스크립트의 실행을 ci 등을 통해 엄격히 감시할 수 있다.

하지만 결국 Flyway 로..

그럼에도 우리 팀은 Flyway 를 선택하게 됐다. 그 이유는 다음과 같다.

 

1. 러닝 커브가 존재한다.

• MVP 를 빠르게 뽑아내보는 것을 목표로 한 지금, SQL 기반 대신 DSL 기반의 언어를 배워보는 게 효율적인가?
• SQL 이 오히려 우리에게는 직관적일 수도 있다.
• 현재는 에자일이라는 가치나 새로운 툴을 배워보는 것에 대한 가치보다 속도가 생명!

2. Flyway 도 어느 정도 해낸다..

• 내가 중요시했던 롤백은 새로운 스크립트를 작성해 롤백을 '한 것과 같은' 일종의 효과를 낼 수도 있다.
• 체크섬 / 버전 기록 등과 같은 기능으로 '어느 정도는' 의도한 바대로 에자일하고 정합성 있게 활용할 수 있다.

그래서 우선은 Flyway 로 세팅을 해두고, 롤백의 필요성이나 / 더 엄격한 버저닝이 필요하다고 판단이 될 때 도입하는 것으로 결정했다!