DB 변경 감지 (flyway)

프로젝트를 진행하다 보면 데이터베이스 컬럼이나 스키마에 변경이 생기는 경우가 많다. 나 역시 이런 변경 사항을 체계적으로 관리하고, 누락이나 충돌 없이 적용하기 위해 Flyway를 도입한 적이 있다(현재는 제거했지만). 이번 글에서는 Flyway가 DB 변경을 어떻게 감지하고 관리하는지, 그리고 실제로 적용하면서 느꼈던 점들을 정리해본다.

Flyway를 도입한 이유

처음엔 단순히 "누가, 언제, 어떤 변경을 했는지"를 추적하고 싶어서 Flyway를 도입했다. 기존에는 개발자가 직접 SQL을 실행하거나, 변경 내역을 별도로 관리하다 보니 누락이나 충돌이 자주 발생했다. Flyway는 이런 문제를 해결해주는 대표적인 DB 마이그레이션 도구이다.

적용방법

1. 의존성 추가

implementation 'org.flywaydb:flyway-core'
implementation 'org.flywaydb:flyway-mysql'

2. .yml 설정

spring:
  flyway:
    enabled: true # Flyway 활성화
    baseline-on-migrate: true # Flyway가 제공하는 변경 이력 테이블 자동 생성
    baseline-version: 0 # 초기 버전 설정
    locations:
    - 파일 위치

3. 마이그레이션 파일 작성 (src/main/resources/db/migration 에 작성해야함)

Flyway의 핵심 원리

• 버전 관리
  Flyway는 버전이 명시된 SQL 마이그레이션 스크립트를 순서대로 실행해서 DB 스키마를 관리한다. 각 스크립트는 데이터베이스를 한 버전에서 다음 버전으로 이동시킨다.
• Schema History Table
  Flyway는 각 데이터베이스에 flyway_schema_history라는 테이블을 자동으로 만든다. 이 테이블에는 언제, 누가, 어떤 마이그레이션을 적용했는지, 성공 여부와 체크섬까지 기록된다. 덕분에 어떤 변경이 언제 적용됐는지 한눈에 파악할 수 있다.
• 변경 감지
  Flyway는 이미 적용된 마이그레이션과 새로 추가된 마이그레이션을 비교해, 아직 적용되지 않은 스크립트만 실행한다. 만약 스크립트 내용이 바뀌면 체크섬이 달라져서 경고를 띄워준다.

DB 변경 감지의 한계와 Drift

Flyway는 스크립트를 통한 변경만 추적한다. 즉, Flyway 외부에서 직접 DB를 수정하면(예: DB관리자가 직접 ALTER TABLE 실행) Flyway는 이를 감지하지 못한다. 이런 상황을 스키마 드리프트(drift)라고 부른다.

• 드리프트 감지
  Flyway의 엔터프라이즈 버전에서는 drift check 기능이 있어서, 실제 DB와 마이그레이션 스크립트가 일치하는지 비교할 수 있다. 하지만 커뮤니티 버전에서는 이런 기능이 제한적이다.
  드리프트를 방지하려면, 모든 스키마 변경을 반드시 Flyway 스크립트로 관리하는 습관이 필요하다.

Flyway의 장점

• 일관된 버전 관리
  모든 변경 사항이 스크립트로 남아서, 언제든지 이력을 추적할 수 있다.
• 자동화와 통합
  Spring 등 다양한 프레임워크와 연동이 쉽고, CI/CD 파이프라인에도 자연스럽게 녹아든다.
• 백업 및 롤백
  마이그레이션 전 자동 백업 설정이 가능해, 실수로 인한 데이터 손실 위험을 줄일 수 있다.

실제 적용하면서 느낀 점

Flyway를 쓰면 DB 변경 이력이 투명하게 남고, 여러 개발자가 동시에 작업해도 충돌이나 누락이 줄어든다. 다만, 모든 변경을 반드시 스크립트로 남겨야 하고, 직접 DB를 수정하면 drift가 발생할 수 있으니 주의가 필요하다.

결론

Flyway는 DB 변경 이력 관리와 감지에 강력한 도구다. 다만, 완벽한 변경 감지를 위해서는 모든 스키마 변경을 반드시 Flyway 스크립트로 관리하는 개발 문화가 뒷받침되어야 한다.
DB 변경 사항을 투명하게 추적하고 싶다면, Flyway 도입을 고려하는것을 추천한다.