Flyway vs Liquibase 비교 — DB 마이그레이션 도구, 실무에서 뭘 골랐나

손으로 ALTER TABLE 을 치다가 운영 DB를 한 번이라도 깨뜨려 본 사람은 안다. 스키마 변경을 사람 기억과 메신저 공지에 맡기는 순간, 배포는 복불복이 된다. 누가 어떤 순서로 쿼리를 돌렸는지 아무도 장담 못 하는 상태 말이다.

DB 마이그레이션 도구는 그 혼란을 버전 관리로 바꾼다. 코드에 Git이 있듯, 스키마에도 "몇 번 버전까지 적용됐다"는 기록을 남기고 순서대로 자동 반영한다. 자바·Spring 생태계에서 이 자리를 두고 오래 겨뤄 온 두 도구가 Flyway와 Liquibase다. 둘 다 충분히 성숙했고, 둘 다 무료로 시작할 수 있다. 성격이 정반대라는 게 문제다.

접근 방식부터 갈린다 — SQL이냐, 추상화냐

Flyway는 "그냥 SQL을 써라"는 철학이다. 마이그레이션 파일 하나가 곧 SQL 스크립트고, 파일명으로 버전과 순서를 표현한다.

V1__init_schema.sql
V2__add_user_deleted_at.sql
V3__create_blog_post_table.sql

V 뒤의 숫자가 버전, 더블 언더스코어 뒤가 설명이다. 파일을 열면 실행될 쿼리가 그대로 보인다. PostgreSQL을 쓰면 PostgreSQL 문법을, MySQL을 쓰면 MySQL 문법을 직접 적는다.

Liquibase는 한 겹 위에서 논다. changeSet이라는 단위로 변경을 기술하는데, XML·YAML·JSON 같은 DB 중립 포맷을 쓸 수 있다(원하면 순수 SQL도 가능하다).

databaseChangeLog:
  - changeSet:
      id: add-user-deleted-at
      author: backend
      changes:
        - addColumn:
            tableName: users
            columns:
              - column: { name: deleted_at, type: timestamp }
      rollback:
        - dropColumn: { tableName: users, columnName: deleted_at }

addColumn 같은 추상 명령을 쓰면 Liquibase가 연결된 DB 종류에 맞는 SQL로 번역해 실행한다. 같은 changelog 하나로 PostgreSQL에도 Oracle에도 돌릴 수 있다는 게 핵심이다. 대신 실제로 어떤 쿼리가 나가는지는 한 단계 가려진다.

항목별로 뜯어보면

말로 풀면 추상적이니 기준을 정해 표로 눌러 담았다.

가격은 2026년 기준으로 이렇게 갈린다. Liquibase는 무료 OSS와 유료 Pro(사용자당 연 약 1,499달러), 그리고 기업용 Secure로 나뉜다. Flyway 쪽은 셈법이 최근 바뀌었다. Redgate가 2025년 5월 중간 등급이던 Teams 라이선스를 신규 판매에서 접으면서, 사실상 무료 Community와 견적형 Enterprise 두 갈래로 단순해졌다. 예전에 Teams 가격대에서 쓰던 undo 스크립트·코드 분석·드리프트 감지 같은 기능이 Enterprise 쪽으로 넘어갔다.

롤백, 생각만큼 중요하지 않을 수도 있다

표만 보면 "Flyway는 무료로 롤백도 못 하네"가 제일 눈에 띈다. 맞다. Flyway OSS는 철저히 앞으로만 간다. 되돌리는 undo 마이그레이션은 유료(Enterprise) 기능이다. 반대로 Liquibase는 무료 버전에서도 createTable·addColumn 같은 표준 change라면 롤백 SQL을 자동으로 만들어 준다. 이것만 보면 Liquibase 압승처럼 보인다.

그런데 운영 DB를 자동 롤백으로 되돌리는 일이 실무에서 실제로 얼마나 일어날까. 나는 Spring Boot에 Flyway를 붙여 V1, V2… 식의 버전드 SQL로 스키마를 굴리고 있는데, 무중단(블루그린) 배포를 하다 보니 애초에 "되돌리는 마이그레이션"을 거의 쓰지 않는 쪽으로 설계가 굳었다.

이유가 있다. 블루그린 배포에서는 새 버전과 옛 버전 앱이 잠깐 같은 DB를 동시에 본다. 이때 컬럼을 즉시 삭제하거나 이름을 바꾸면 옛 버전이 그 순간 깨진다. 그래서 파괴적 변경은 두 번에 나눠 한다. 먼저 컬럼을 추가하고 데이터를 백필한 다음(expand), 다음 배포에서야 옛 컬럼을 치운다(contract). 이 패턴을 지키면 롤백은 "옛 컬럼을 지우는 두 번째 배포를 안 하면 그만"이 된다. 자동 undo 스크립트가 끼어들 자리가 별로 없다.

그래서 뭘 고르면 되나

"팀 상황에 따라 다르다"는 맥 빠지는 답 대신, 꽤 명확하게 갈린다.

• SQL을 직접 쓰는 게 편하고 단일 DB를 쓴다면 → Flyway. 파일 열면 돌아갈 쿼리가 그대로 보이고, 코드 리뷰에서 DBA든 주니어든 바로 읽는다. 러닝커브가 사실상 없다.
• 여러 종류의 DB를 하나의 정의로 굴려야 하거나, DB 중립 추상화와 무료 롤백이 필요하다면 → Liquibase. 지원 DB 폭이 넓고 롤백이 무료 버전부터 들어온다.
• 엔터프라이즈급 거버넌스(정책 검사·드리프트 감지·감사)가 필요하다면 양쪽 다 유료 등급에서 제공하니, 그때는 가격과 기존 도구 생태계로 비교하면 된다.

우리가 Flyway를 고른 이유도 결국 첫 번째 줄에 있다. PostgreSQL 한 종류만 쓰고, 팀원 누구나 SQL은 읽을 줄 알지만 changelog 문법을 새로 배우고 싶어 하진 않았다. 마이그레이션 파일이 곧 실행될 쿼리라는 투명함이, 리뷰 때 "이 변경이 운영에서 뭘 할지"를 한눈에 보여 준다는 게 가장 컸다. DB 중립성은 우리에겐 필요 없는 가치였고, 없는 기능(무료 롤백)은 expand/contract라는 운영 규칙으로 메웠다.

반대로 멀티 DB를 다루는 SaaS거나, 고객사마다 다른 DB에 같은 스키마를 배포해야 하는 제품이라면 Liquibase의 추상화가 그대로 생산성이 된다. 도구의 우열 문제가 아니라 내 배포 모델과의 궁합 문제다.

하나 덧붙이면, 어느 쪽을 고르든 "마이그레이션은 하위호환으로, 작게 쪼개서"라는 원칙이 도구 선택보다 훨씬 중요하다. 되돌리기 쉬운 도구를 믿고 큰 변경을 한 방에 밀어 넣는 것보다, 되돌릴 일이 안 생기게 쪼개 배포하는 습관이 운영 사고를 더 많이 막는다.

여러분은 어떤 기준으로 마이그레이션 도구를 고르셨나요? SQL 직접 작성파와 추상화파, 댓글에서 의견이 갈릴 것 같은데요.

참고

• Redgate Flyway editions
• Flyway vs. Liquibase — Bytebase
• Liquibase 5.0 release