CI/CD 환경 DB 스키마 변경, Flyway vs Liquibase 비교 및 구현 가이드

CI/CD 파이프라인에서 DB 스키마 변경, 코드로 관리하는 완벽 가이드 (Flyway vs Liquibase)

"이번 기능 추가를 위해 DB 스키마를 수정해야 하는데, 누가 이 변경 사항을 반영할지, 테스트는 어떻게 돌릴지..."

혹시 이런 말로 인해 개발 속도가 늦춰지거나, 배포 직전에 예상치 못한 데이터 불일치 문제로 밤샘을 경험해 보신 적이 있나요? 수동으로 진행되는 데이터베이스 스키마 변경(DB Migration)은 현대 소프트웨어 개발 프로세스에서 가장 취약하고 위험도가 높은 지점 중 하나입니다. 코드는 Git에 커밋되고, 애플리케이션은 컨테이너 이미지로 빌드되지만, 데이터베이스는 여전히 '마법의 영역'처럼 취급되는 경우가 많습니다.

하지만 이제는 그럴 필요가 없습니다. 인프라스트럭처를 코드로 관리하는 IaC(Infrastructure as Code) 트렌드가 서버 OS나 네트워크 설정에만 국한되지 않습니다. 데이터베이스 스키마까지 코드로 관리하는 **Database as Code (DBaC)**가 업계의 표준이 되고 있습니다. 이 글에서는 DBaC의 개념부터 Flyway와 Liquibase를 이용한 실제 CI/CD 통합 시나리오까지, 실무자가 당장 적용할 수 있는 완벽 가이드를 제공합니다.

데이터베이스 변경의 위험성, 왜 코드로 관리해야 하는가?

데이터베이스 변경을 수동으로 진행할 때 발생하는 핵심적인 위험 요소는 **'불일치성(Inconsistency)'**과 **'비반복성(Non-repeatability)'**입니다.

1. 휴먼 에러: DBA의 실수, 혹은 변경 스크립트의 누락은 운영 환경에 치명적입니다.
2. 버전 관리의 어려움: 누가, 언제, 어떤 순서로 스키마를 변경했는지 추적이 어렵습니다.
3. 롤백의 복잡성: 문제가 생겼을 때, 이전 상태로 되돌리는 과정(Rollback) 자체가 또 다른 복잡한 수동 작업을 요구합니다.

DBaC는 이 모든 과정을 Git의 원칙(버전 관리, 코드 리뷰)에 따라 관리함으로써, 데이터베이스 변경을 **'배포 가능한 아티팩트'**로 취급하게 만듭니다.

핵심 마이그레이션 툴 비교: Flyway vs Liquibase

DBaC를 구현하기 위해 가장 널리 사용되는 두 가지 툴이 바로 Flyway와 Liquibase입니다. 둘 다 목적은 같지만, 작동 방식과 철학에 차이가 있어 팀의 성향에 맞춰 선택하는 것이 중요합니다.

💡 실전 비교: 작동 원리 이해하기

Flyway의 방식 (스크립트 중심): Flyway는 V1, V2, V3와 같이 버전이 붙은 SQL 파일들을 순서대로 실행합니다. 이 방식은 "이 버전에서는 이 SQL을 실행해라"라는 명확한 명령 구조를 가집니다.

-- V1__initial_schema.sql
CREATE TABLE users (
    id BIGINT PRIMARY KEY,
    username VARCHAR(100) NOT NULL
);

-- V2__add_email_column.sql
ALTER TABLE users ADD COLUMN email VARCHAR(255);

Liquibase의 방식 (변경셋 중심): Liquibase는 SQL 자체보다는 '무엇을 변경할지'에 대한 정의(ChangeSet)를 선호합니다.

# changesets/20240101_add_email.yaml
databaseChangeLog:
  - changeSet:
      id: add_email
      author: devops
      changes:
        - addColumn:
            tableName: users
            columnName: email
            type: varchar

실무적 의견: 많은 팀이 처음에는 Flyway의 단순한 SQL 구조가 직관적이라 선호하지만, 백엔드 서비스가 PostgreSQL과 MySQL을 동시에 지원해야 하는 상황에 놓이자, 플랫폼 간의 차이를 추상화해주는 Liquibase의 유연성이 결국 더 큰 장점으로 작용했습니다. 프로젝트의 복잡도와 다중 DB 지원 여부를 고려하여 툴을 선택하는 것이 중요합니다.

CI/CD 파이프라인에 DB 마이그레이션 통합하기

DBaC의 진정한 가치는 CI/CD 파이프라인에 통합될 때 발휘됩니다. 단순히 배포 단계에서 실행하는 것을 넘어, 테스트 단계부터 고려해야 합니다.

다음은 일반적인 CI/CD 파이프라인 단계별 통합 시나리오입니다.

[Build] → [Test] → [Deploy] 단계별 DB 마이그레이션 흐름

1. Build 단계:
   • 애플리케이션 코드 빌드 및 테스트 실행.
   • DB 마이그레이션 아티팩트 생성: Flyway/Liquibase가 관리하는 모든 스크립트 파일 묶음(버전 관리)을 빌드 결과물에 포함시킵니다.
2. Test 단계 (가장 중요):
   • 목적: 애플리케이션이 새로운 스키마에서 정상 동작하는지 검증.
   • 실행: 임시 테스트 DB를 띄우고, 최신 버전의 마이그레이션 스크립트 전체를 순차적으로 적용합니다. 이후 테스트 코드를 실행하여 쿼리 오류가 없는지 확인합니다.
3. Deploy 단계:
   • 목적: 실제 운영 DB에 변경 사항을 반영.
   • 실행: 애플리케이션 배포 전에 마이그레이션 툴을 실행합니다. 툴은 현재 DB 버전을 확인하고, 아직 적용되지 않은 최신 스크립트만 안전하게 실행합니다.

🛡️ 실패에 대비하는 롤백(Rollback) 전략

만약 배포 과정 중 마이그레이션 스크립트 실행에 실패했다면 어떻게 해야 할까요?

• Flyway/Liquibase의 기본 롤백: 두 툴 모두 rollback 명령을 지원하지만, 스키마 변경의 특성상 완벽한 자동 롤백은 매우 어렵습니다. 예를 들어, 데이터를 삭제하는 DROP TABLE 명령이 실패하면, 툴이 아무리 노력해도 데이터는 사라진 상태로 남습니다.
• 권장되는 전략 (데이터 백업 + 코드 롤백):
  1. 데이터 백업: 마이그레이션 직전에 운영 DB의 스냅샷 또는 핵심 테이블의 데이터를 백업합니다.
  2. 애플리케이션 롤백: 마이그레이션 실패가 감지되면, 애플리케이션 배포 자체를 이전 버전으로 롤백합니다.
  3. 수동 복구: 데이터 손실이 불가피할 경우, 백업된 데이터를 기반으로 수동 복구 작업을 진행합니다.

안정적인 데이터베이스 운영을 위한 체크리스트

DBaC를 성공적으로 도입하기 위해 팀 차원에서 점검해야 할 체크리스트입니다.

• 모든 DB 스키마 변경은 반드시 버전 관리 시스템(Git)에 커밋되는가?
• 개발 환경, 스테이징 환경, 운영 환경의 DB 스키마 버전이 일치하는가?
• 마이그레이션 스크립트 내에 트랜잭션(Transaction) 처리가 명시적으로 되어 있는가?
• 롤백 시나리오에 대한 테스트 케이스가 마련되어 있는가?

이러한 체계적인 접근 방식을 통해, 데이터베이스는 더 이상 '위험한 블랙박스'가 아니라, 코드와 함께 관리되는 안정적인 서비스의 핵심 구성 요소가 될 것입니다.

자주 묻는 질문 (FAQ)

Q1. 마이그레이션 툴을 사용하면 개발 속도가 느려지지 않나요? A1. 초기 설정 및 스크립트 작성에 시간이 걸리지만, 일단 파이프라인이 구축되면 수동 작업에 드는 시간과 휴먼 에러로 인한 재작업 시간이 사라지므로 장기적으로는 개발 속도와 안정성이 극대화됩니다.

Q2. Flyway와 Liquibase 중 어떤 것을 선택해야 할지 모르겠습니다. A2. 팀원들이 SQL에 매우 익숙하고, DB 종류가 비교적 단일하다면 Flyway가 빠르고 직관적입니다. 하지만 여러 종류의 DB를 지원해야 하거나, 비개발 직군도 쉽게 이해할 수 있는 추상화 계층이 필요하다면 Liquibase가 더 적합할 수 있습니다.

Q3. 마이그레이션 스크립트를 실행할 때, 데이터 변경(INSERT/UPDATE)과 스키마 변경(ALTER)을 분리해야 하나요? A3. 네, 원칙적으로 분리하는 것이 가장 안전합니다. 스키마 변경(DDL)은 먼저 실행하여 구조를 만든 후, 데이터 변경(DML)을 실행하는 것이 일반적입니다.

[실무자 Tip] 실제 운영 환경에서 가장 어려웠던 부분은 '데이터 변경(DML)'과 '스키마 변경(DDL)'을 같은 트랜잭션으로 묶으려 할 때 발생했습니다. DDL은 트랜잭션 경계가 모호하거나 DB 엔진에 따라 다르게 동작하는 경우가 많아, DML은 스키마 변경이 완료된 후에 별도의 스크립트로 실행하는 것이 가장 안전한 패턴임을 경험을 통해 배웠습니다.