개요

효율적인 DB 스키마 관리 : JPA와 Flyway를 활용한 최적의 솔루션
실무에서는 다양한 팀과 많은 팀원들이 협력하여 업무를 합니다. 혼자 프로젝트를 할 때와 다르게 실무를 하면서 데이터베이스 스키마 관리의 중요성을 깨닫게 되었습니다. JPA를 사용하면 자동으로 DB가 마이그레이션 되지만 ,이력이 남지 않아 관리가 어려웠기 때문입니다. 누군가 변경한 내용을 공유하지 않아 예기치 못한 문제에 봉착하기도 하고, 잘못된 스키마가 운영 환경에 적용되어 혼란이 발생했으며, 수동으로 변경 사항을 관리해야 하는 불편함도 존재했습니다.

이러한 문제를 해결하는 방안을 찾기 위해 다른 기업들의 운영 방식에 대해 찾아보게 되었습니다. 궁금증에 찾아보던 중 DB 형상 관리 도구로 Flyway를 접하게 되었습니다. Flyway는 마이그레이션 버전 관리를 자동화하여 복잡한 수동 작업을 단순하게 만들어 주었습니다. 이를 프로젝트에 적용하여 스키마 변경 이력 관리를 체계화하였고, 문제 발생시 해결 속도를 개선하였습니다. 새로운 도구를 도입하는 과정이 쉽지는 않았지만 이는 결국 시스템의 안정성을 높이는데 큰 도움이 되었습니다.

1. JPA의 DB 스키마 관리 기능과 한계

JPA 데이터베이스 초기화 전략

  • JPA의 구현체 중 하나인 하이버네이트는 다양한 기능을 제공
  • JPA 하이버네이트에서 제공하는 ddl-auto의 종류와 기능, 그리고 주의 사항에 대해서 정리

(1) JPA의 자동 DDL 생성 기능

  • JPA는 DB 스키마를 자동으로 관리해주는 편리한 도구
  • JPA의 구현체 중 하나인 하이버네이트에서 제공하는 ddl-auto 설정을 통해 테이블을 생성하거나 수정할 수 있음
    • spring.jpa.hibernate.ddl-auto 옵션을 통해 애플리케이션 구동 시 JPA의 DB 초기화 전략을 설정할 수 있음
    • Entity만 등록해놓으면 DDL을 자동으로 작성하여 테이블을 생성하거나 수정해 줌
  • 이 설정은 개발 초기 단계에서 유용하지만, 운영 환경에서 사용할 경우 치명적인 오류를 일으킬 수 있음

(2) DDL AUTO 옵션

  • ddl-auto 옵션 종류
    • create : 기존 테이블 삭제하고 새로 생성함 (DROP + CREATE)
    • create-drop : create와 같으나 종료시점에 테이블 삭제하는 추가 기능 있음 (종료 시점 DROP)
    • update : 테이블을 수정 → 변경분만 반영됨
    • validate : 엔티티와 테이블이 정상 매핑되었는지 검증할 뿐, 실제 변경은 하지 않음
    • none : 어떤 작업도 하지 않음
ddl-auto 옵션 종류 세부 설명
  • create
    • 엔티티로 등록된 클래스와 매핑되는 테이블을 자동으로 생성(create)해줌
    • 이 과정에서 기존에 해당 클래스와 매핑되는 테이블이 존재한다면, 기존 테이블을 삭제(drop)하고 테이블을 생성

ddl-auto 설정 create 일때 생성되는 DDL

  • create-drop
    • create와 같으나 종료시점에 테이블 DROP
    • create와 비슷하게 Entity로 등록된 클래스와 매핑되는 테이블이 존재한다면 기존 테이블을 삭제하고 자동으로 테이블을 생성해주는 것은 동일함
    • 하지만, 애플리케이션 종료될 때 테이블을 삭제한다는 차이가 있음

애플리케이션 실행시 create 쿼리 작성됨

애플리케이션 종료시 drop 쿼리가 작성됨

  • update
    • Entity로 등록된 클래스와 매핑되는 테이블이 없으면 새로 생성하는 것은 create와 동일함
    • 하지만, 기존 테이블이 존재한다면 위의 두 경우와 달리 테이블의 컬럼을 변경하게 됨
    • ⚠️ 주의 : 모든 변경사항을 반영하는 것은 아님
      • 기존에 존재하는 컬럼의 속성(nullable, 크기, 데이터 타입 등)은 건드리지 않음
      • 새로운 컬럼이 추가되는 변경사항만 반영됨!!
    • EX ) 어떤 엔티티 클래스의 String 필드를 Int로 변경하더라도, 해당 테이블의 컬럼은 숫자타입으로 바뀌지 않고 문자열 타입으로 유지됨
  • validate

    • 다른 속성들과는 다르게 DDL을 작성하여 테이블을 생성하거나 수정하지 않음

    • 엔티티 클래스와 테이블이 정상적으로 매핑되는지만 검사함

    • 만약 테이블이 아예 존재하지 않거나, 테이블에 엔티티의 필드에 매핑되는 컬럼이 존재하지 않으면 예외를 발생시키면서 애플리케이션을 종료함

      image.png

    • ⚠️ 주의 : Entity의 필드가 매핑되는 테이블에 모두 존재하기만 한다면, 테이블의 컬럼이 더 많더라도 아무 일도 일어나지 않음

  • none (default)
    • 사실 속성이 존재하는 것이 아니라 위의 4가지 경우를 제외한 모든 경우에 해당함
    • 단, 스프링부트에서는 none이라고 명시하거나 아예 ddl-auto 속성을 명시하지 않아야 함
    • 이 경우에는 아무 일도 일어나지 않는다.

(3) DDL AUTO 옵션 주의 사항

  • ddl-auto 옵션의 설정이 편리하지만 잘못 다루면 돌이킬 수 없는 결과를 가져오는 아주 위험한 기능임
  • 상황에 따른 설정 방법
    • 운영 장비에서는 절대 crate, create-drop, update 사용하면 안됨
    • 개발 초기 단계는 create 또는 update
    • 테스트 서버는 update 또는 validate
    • 스테이징과 운영 서버는 validate 또는 none
  • 로컬 환경을 제외한 나머지 서버에서는 최대한 직접 쿼리를 날려서 적용하는 것이 가장 좋음

2. ddl-auto 사용으로 문제 발생

(1) 운영DB에서 ddl-auto 사용하면 안되는 이유?

  • JPA의 자동 DDL 생성 기능을 잘못 사용하면 돌이킬 수 없는 결과를 초래할 수 있음
  • 특히 운영 환경에서 테이블이 삭제되거나 잘못된 스키마가 적용되면 문제가 발생할 가능성이 높음
    • EX ) update 옵션을 사용할 경우 새로 추가된 컬럼은 반영되지만, 기존의 컬럼 속성 변경은 반영되지 않아 예기치 않은 오류가 발생할 수 있음
    • EX ) create나 create-drop으로 설정한 채로 운영 DB에 연결하여 애플리케이션을 실행해버리면 운영 DB의 테이블이 몽땅 삭제되는 대참사가 일어남
  • 스테이징, 운영환경 설정
    • 문제가 발생할 소지가 있으므로 절대로 create, create-drop, update를 사용하면 안됨
    • 테이블 생성 및 컬럼 추가, 삭제, 변경은 DB에서 직접하며, none을 사용하거나 validate를 이용해 정상적인 매핑 관계만 확인해야 함

(2) DDL- Auto : Update 옵션 실제 사용시 겪은 문제

ddl-auto의 update 옵션에 대한 이해 부족
개발 초기에는 프로젝트 기획이 자주 변경되고 설계도 확정되지 않은 상태였기 때문에, DB 스키마 변경이 빈번하게 발생했습니다. 이를 반영하기 위해 모든 팀원이 ddl-auto 옵션을 update로 설정하여 사용하고 있었지만, 이 옵션에 대한 충분한 이해 없이 사용한 점이 문제가 되었습니다.

ddl-auto=update는 DB 스키마의 변경 사항을 자동으로 반영하지만, 모든 변경 사항이 항상 제대로 적용되는 것은 아닙니다. 특히 필드의 타입이나 NOT NULL 조건이 변경된 경우, 해당 컬럼에 대한 데이터가 삽입되지 않으면 무결성 오류가 발생해 문제가 생겼습니다. 이런 문제를 파악하고 도메인 담당자와 소통하는 데 많은 시간이 소요되었습니다.

개발자 로컬 환경 간 DB 스키마 불일치 문제
DB 스키마를 직접 DDL 파일로 관리하는 것이 번거롭고, 초기 데이터 설정이나 수정이 필요한 경우 DML 관리까지 추가되어 복잡해졌습니다. 게다가 각 개발자의 로컬 환경마다 DB 스키마와 코드가 일치하지 않는 상황이 자주 발생해 문제가 더욱 심화되었습니다. 이로 인해 개발자 로컬 간의 DB 싱크 불일치 문제를 해결할 방법이 필요하게 되었습니다.

(3) 문제 발생 예시

  • application.properties에 정의해두었던 JPA의 구현체인 Hibernate에 부여한 DB 초기화 전략으로 spring.jpa.hibernate.ddl-auto=update를 사용할 경우
  • [ 예시 상황 1 ] 새로운 NOT NULL 제약 조건 컬럼 추가
    • 결과
      • update 옵션은 테이블을 덮어쓰거나 기존 데이터를 변경하지 않음
      • 새로운 NOT NULL 컬럼이 추가되어도, 기존 데이터에 대해 해당 컬럼에 값을 채워주지 않으면 오류가 발생함
      • 변경 사항이 제대로 반영되지 않은 상태에서 운영 환경에 배포되면, 새로운 레코드를 삽입할 때 NOT NULL 컬럼에 값이 지정되지 않아 무결성 오류가 발생해 데이터 삽입이 실패할 수 있음 → EX. NULL value in column "X" violates not-null constraint
    • 기존 해결 방식 : ALTER TABLE 구문을 사용해 수동으로 DB 스키마를 수정하고, 새로 추가된 NOT NULL 컬럼에 대해 기존 데이터에 기본값을 채워주는 작업을 수행함
  • [ 예시 상황 2 ] Entity의 Boolean finalized 컬럼을 String status로 변경
    • 결과
      • update 옵션은 finalized 컬럼이 status 컬럼으로 변경되지 않음
      • 기존 finalized 컬럼은 삭제 되지 않고 그대로 유지된 채로 status 컬럼만 추가로 생성됨
    • 기존 해결 방식 : 쿼리문 직접 날려 미사용 컬럼이나 테이블을 직접 수정하거나 삭제하는 방식으로 대응
@Entity 
public class Member {
    @Id
    @GeneratedValue
    private Long id;

    private String name;

    //private Boolean finalized; 삭제
      private String status;
}
추가 문제 발생 상황
  • SpringBoot에서 JPA 쓰면 자동 DB 마이그레이션 되지만 이력은 남지 않음
  • 여러 명이 동시에 테이블 변경, 데이터 추가, 삭제, 변경을 하려고 할 때, 언제 누가 변경하였는지 알 수 없어 당황스러운 순간들이 발생함
    • 누가 바꾼지 모르겠지만 변경되어 있음
    • 너무 많은 DB 스키마 변경점이 있는데 운영 DB에 적용해버림
    • 테스트를 위해 데이터 삽입했으니 건드리지 말라고 메신저 보냄
  • 개발자 로컬에서 구현되어 테스트 되어진 프로그램 소스 코드는 형상 관리 툴 Git을 이용하여 변경 이력 관리 하고 있지만 DB는 왜 하지 않을까?
    • 각 개발자의 Local 환경에서 개발시 사용되는 database의 schema 변경에 대한 마땅한 이력관리 방법 존재하지 않음
    • Local 개발환경의 database 변경사항을 다른 배포 단계의 database에 적용하려면 어쩔 수 없이 배포 전 변경사항을 수동으로 처리해줘야 함
    • 수정 처리하다가 실수 발생함
      • 삭제 되어야 할 테이블이 남아있어서 차후 오류가 갑자기 발생함
      • 초기 데이터가 무조건 삽입되어야 하는데 삽입되지 않아 문제 발생 (DML 관리 되지 않음)
      • 수정되어야 할 필드인데 적용되지 않아 직접 DB 스키마 수정해야 함
      • 배포 단계마다 어떤 변경분이 필요한지 제대로 확인되지 않아 오류 발생할 때까지 잘못되었는지 확인 불가
  • 수동으로 DDL과 DML을 관리하기 어려움
  • 수동 관리의 불편합을 손쉽게 해결해주는 Tool이 필요함
  • 마이그레이션 버전 관리를 자동으로 해주며, 가장 많이 사용하고 있는 도구가 Flyway

3. Flyway를 통한 DB 관리의 최적화

(1) Flyway 도입의 필요성

Flyway : DB 마이그레이션의 해결사
JPA의 자동 마이그레이션 기능만으로는 이력을 관리하는 데 한계가 있었습니다. 실제로 Update 옵션을 사용하면서 다양한 문제가 발생했습니다. 이를 방지하기 위해 수동으로 쿼리를 작성해 DB 스키마를 수정해야 하는 번거로움도 존재했습니다.

Flyway는 이러한 문제를 해결해주는 도구로, 데이터베이스 변경 이력을 관리하고 자동화된 마이그레이션을 지원합니다. 각 버전별로 스키마 변경 사항을 기록하여 추후 변경 내용을 명확하게 파악할 수 있으며, 배포 과정에서 발생할 수 있는 실수를 방지합니다.

실제로 Flyway를 사용하게 되면서 스키마 변경 이력도 관리할 수 있게 되었고, 마이그레이션 작업 자체도 코드로 명시적 관리할 수 있어 더 안전하고 효율적인 작업이 가능해졌습니다. 특히나 Flyway는 각 환경의 스키마 상태를 유지하면서도, 자동화된 마이그레이션을 통해 모든 팀원이 동일한 스키마를 사용할 수 있도록 지원해주었습니다.

(2) Flyway를 통한 스키마 관리의 장점

  • 이력 관리
    • DB 스키마 변경 이력이 남음
    • DB 스키마 변경 이력을 코드로 남겨두면, 나중에 문제 발생시 해결하기 용이해짐
  • 자동화된 마이그레이션
    • 단순히 이력만 남기는 것이 아니라 코드로 DB 마이그레이션 관리를 할 수 있음
    • 수동으로 작업 하지 않고 코드로 실행하기 때문에 실수나 누락할 여지가 줄어듦
    • 배포 시에도 자동화 가능하므로 DB 스키마 작업이 더 안전해짐
  • 협업 효율성 증대
    • 더 많은 사람이 협업하기 수월해짐
    • 코드로 관리되기 때문에 리뷰를 통해 문제를 미리 파악할 수 있음
    • 실제 환경과 동일한 로컬 환경을 구축하기 쉬워짐

4. Flyway 개념 및 적용 방법

(1) Flyway 란?

  • 데이터베이스의 형상관리를 목적으로 하는 툴
    • git을 통해 코드 관리하는 것의 데이터베이스 버전
    • git에서는 코드를 파일 별로 로깅을 통해서 변화의 이력을 추적하는데 flyway는 DB의 DDL의 이력을 쌓아서 DDL이 어떻게 변화되었는지 관리하는 도구로 사용됨
  • DB 스키마 변경에 대한 마이그레이션 작업과 변경에 대한 버전관리(형상관리)를 제공함
  • Flyway 동작 원리 및 DB 형상 관리 예시
    • 버전 관리 목적인 SCHEMA_VERSION 테이블을 통해 SQL스크립트 변화를 추적하면서 자동적 관리함
    • DB 형상 관리 예시

      • Axel과 Christian이 별개로 DDL을 만들고 있음

      • 서버 배포시 자동화 빌드 과정에서 함께 통합하여 DDL이 실행됨

        DB 형상 관리 예시

(2) 의존성 및 환경 설정

  • Flyway는 다양한 방법으로 실행할 수 있음 → Gradle, Maven, CLI, Java API 방법 사용 가능

  • SpringBoot로 서버 띄울때 자동으로 DDL이 실행될 수 있도록 Java API 사용 방식 적용

  • Flyway 설치

    • macOS 에서는 brew 로 간단하게 설치할 수 있음

      $ brew install flyway

  • Build.gradle

    • JAVA API 방법 사용하기 위해서는 org.flywaydb:flyway-core 모듈에 대한 의존성 필요
    • 해당 모듈은 현재 8버전 beta 까지 나와있음
    • Spring Boot 2.3.x 버전 사용시 flyway 6 버전, Spring Boot 2.4.x 이상인 경우 7버전 이상 사용
    implementation 'org.flywaydb:flyway-core'

  • application.yml : flyway 관련 설정

    • enabled : flyway를 사용하겠다는 설정 (기본값은 true)
    • baseline-on-migrat
      • flyway는 버전 정보를 flyway_shcema_history 테이블에서 관리하는데 해당 테이블을 자동으로 생성해주는 옵션
      • 기본값은 false로 히스토리 테이블이 이미 존재할 때 사용함
    datasource:
    driver-class-name: com.mysql.cj.jdbc.Driver
    url: jdbc:mysql://localhost:3306/flyway?serverTimezone=UTC&characterEncoding=UTF-8
    username: 아이디
    password: 패스워드
  jpa:
    database: mysql
    database-platform: org.hibernate.dialect.MySQL8Dialect
    show-sql: true
    hibernate:
      ddl-auto: validate
    properties:
      hibernate:
        format_sql: true

  flyway:
    enabled: true
    baseline-on-migrate: true # flyway_schema_history 테이블을 자동으로 생성할지 여부
    url: jdbc:mysql://localhost:3306/flyway?serverTimezone=UTC&characterEncoding=UTF-8
    user: 아이디
    password: 패스워드

logging:
  level:
    org.hibernate.SQL: debug
    org.hibernate.type: trace

(3) Flyway 경로 설정

  • default 경로 : spring.flyway.locations: classpath:db/migration
  • 경로 변경 방법 : spring.flyway.locations: classpath:db/migration/test
  • db 종류를 기준으로 로케이션 나누는 방법
    • h2를 사용하면 db/migration/h2 폴더를 읽도록 설정 → {vendor} 사용
    • locations: classpath:db/migration/{vendor}
  • local, dev, prod 모두 같은 migration 스크립트를 사용하지만 로컬에서만 특정 시드 값을 넣고 싶은 경우
    • locations: classpath:db/migration/{vendor}, classpath:/db/seed

경로 변경

db 종류에 따른 로케이션 분리

로컬에만 특정 시드 적용

5. 예시 : 초기에 DB 데이터 없을 경우

(1) Member 엔티티 구성

  • Member.java

    @Entity
@NoArgsConstructor
@AllArgsConstructor
@Builder
public class Member {

    @Id @GeneratedValue(strategy = GenerationType.IDENTITY)
    @Column(name = "MEMBER_ID")
    private Long id;

    private String name;
}

(2) Flyway 작성

  • 패키지 구조

    패키지 구조 예시

    • 반드시 resources/db/migration 위치에서 작성해야 함
    • 경로 변경하고 싶다면 application.properties 파일에 spring.flyway.location=파일위치 로 수정 가능

(3) sql 네이밍 규칙

image.png

  • Prefix
    • V, U, R 중 하나를 선택함
    • V(Version) : 버전 마이그레이션(=버전 정보), 정수, 소수, 날짜 등이 가능함
    • U(Undo) : 실행 취소 (유료버전만 사용가능)
    • R(Repeatable) : 반복 가능한 마이그레이션
      • 버전에 상관없이 매번 실행되는 스크립트로 버전 명시가 필요 없습니다.
      • 예시로 테스트를 위해 매번 더미데이터를 넣을 때 사용합니다.
  • Separator : __ (언더바 2개) 로 작성해야 한다는 규칙이 있음
  • Description
    • 추가되는 설명 및 실질적인 파일 명에 해당됨
    • 단어 구분은 space 대신 _(언더바) 사용함
  • Suffix : 접미사로 보통 .sql을 사용함
SQL 네이밍 예시

V0_create_table_user.sql 
V1.1_create_table_game.sql
V20210909_create_table_screenshot.sql

(4) V1_init.sql 파일

CREATE TABLE IF NOT EXISTS `flyway`.`member`(
    `member_id` BIGINT NOT NULL AUTO_INCREMENT,
    `name` VARCHAR(255),
    PRIMARY KEY (`member_id`))
    ENGINE = InnoDB
    DEFAULT CHARACTER SET = utf8mb4
    COLLATE = utf8mb4_0900_ai_ci;

(5) Flyway_schema_history 확인 방법

  • 스프링부트 실행
  • WorkBench를 이용해서 yml에 세팅해준 설정대로 생성된 flyway_schema_history를 확인
  • version 컬럼에 1로 잘 저장된 것을 확인할 수 있음
  • flyway로 등록된 순간 기준으로 flyway가 DB 버전 관리를 하므로 해당 스크립트를 수정, 삭제 하면 안됨

image.png

(6) 버전 업데이트

  • Member 엔티티 수정 : age 필드 추가

    @Entity
@NoArgsConstructor
@AllArgsConstructor
@Builder
public class Member {

    @Id @GeneratedValue(strategy = GenerationType.IDENTITY)
    @Column(name = "MEMBER_ID")
    private Long id;

    private String name;

    @Column(nullable = false)
    private int age;

}

  • 새로운 컬럼 추가 후 바로 스프링 실행시 에러 발생

    • 에러 발생 이유 : flyway에게 업데이트된 정보를 알려주지 않았기 때문

image.png

  • V2 추가
    • V2로 새롭게 버전 정보 생성 후 코드 입력

image.png

ALTER TABLE member ADD COLUMN age integer default 0

6. 예시 : 기존 데이터나 migration 이력 존재는 경우

(1) 기존 테이블 정보, 데이터만 있는 경우

  • application.yml에 설정 추가
spring:
  # ... 생략

  flyway:
    enabled: true
    baseline-on-migrate: true
    url: jdbc:mysql://localhost:3306/flyway?serverTimezone=UTC&characterEncoding=UTF-8
    user: 아이디
    password: 패스워드
  • resources/db/migration 위치에 V1 migration script를 작성
    • 이때 반드시 스크립트 파일이 있어야 함
    • 특별한 버전1 없이, 그냥 기존 테이블과 데이터를 유지하고자 해도 빈 script를 작성해야 함
    • 즉, 파일 자체는 있어야 한다는 의미

(2) flyway_schema_history 테이블이 존재하는 경우

  • 기본 테이블 정보, 데이터, flyway_schema_history 테이블 까지 있는 경우

    • application.yml 설정을 수정
    • baseline-on-migrate 옵션을 false로 해주기 (기본값이 false임 )
    spring:
  # ... 생략

  flyway:
    enabled: true
    baseline-on-migrate: false
    url: jdbc:mysql://localhost:3306/flyway?serverTimezone=UTC&characterEncoding=UTF-8
    user: 아이디
    password: 패스워드

  • migration script가 남아있지 않은 경우

    • 히스토리 내역 최신보다 더 높은 버전으로 빈 스크립트를 추가하고 실행
    • EX) flyway_schema_history 조회했을 때, 가장 최신 버전이 4라면, V5로 시작하는 스크립트 작성
    • 이때도 마찬가지로 비어있더라도 반드시 스크립트 파일이 있어야 함

  • migration script가 남아있는 경우

    • resources/db/migration 위치에 기존 히스토리 내역과 일치하는 스크립트를 그대로 추가하고 실행

  • DB 확인

    • flyway_schema_history 테이블에서 «Flyway Base» 이 표시됨을 확인할 수 있음

    image.png

7. Flyway 사용시 주의 사항

  • 주의 : 이미 동일한 버전의 파일이 있을 경우 무시됨
    • flayway_schema_history 테이블의 version1의 로그가 남아있는 상태에서 V1_~.sql 스키파 파일을 다시 생성 후 실행하면 실행되지 않음
  • flyway clean은 사용하지 말자 → 실행 시 경고 문구 없이 바로 삭제됨
  • flyway 마이그레이션 규칙 : 현재 DB에 적용된 버전보다 항상 높은 버전의 파일을 인식해 차례대로 적용
    • 즉 V10이 이미 DB에 마이그레이션 되어있는 상태에서 V9 파일을 만들면 마이그레이션 이뤄지지 않음
    • V10이 이미 DB에 마이그레이션 되어있는 상태에서 V11, V12, V8 스크립트 파일 작성하면 V11, V12만 마이그레이션 이뤄짐

8. Flyway 명령어

  • init : SCHEMA_VERSION 을 baseline과 함께 생성 (이미 테이블 생성되어 있으면 수행되지 않음)
  • migrate : 스키마 정보를 리얼 DB에 마이그레이션함
  • clean : flyway로 생성한 스키마 모두 삭제 (해당 DB의 모든 테이블 삭제)
  • info : DB에 적용된 스키마 정보와, 로컬에 pending 되어있는 변경 정보를 보여줌
  • validate : DB에 적용된 스키마 정보와 로컬의 변경점을 비교하여 보여줌
  • repair : 마이그레이션 실패한 내역을 수정함 (삭제 및 교체)
  • baseline : flyway로 형상 버전관리를 시작 할 baseline 을 설정함

9. Flyway 적용 후 느낀점

Flyway 도입기: 테이블 스키마 관리의 새로운 접근
Flyway 도구를 처음 접했을 때는 Entity 객체의 정보를 수정하고 서버를 실행하기만 하면 테이블이 자동으로 맞춰지는 편리한 도구라는 기대를 가졌습니다. 하지만 Flyway를 실제로 적용해 보면서 깨달은 것은 자동으로 테이블을 변경해 주는 만능 도구가 아니라는 점이었습니다. Flyway를 사용하면서 바뀐 점은 테이블 스키마를 Entity와 맞추기 위해 기존에는 직접 DB에 접속해 쿼리문을 작성해야 했던 것을 이제는 별도의 마이그레이션 파일에 그 기록을 남겨 관리할 수 있게 된 정도였습니다.

결국 테이블 스키마를 Entity와 맞추기 위한 쿼리문은 여전히 직접 작성해야 했습니다. 처음 기대했던 것처럼 눈에 띄게 편리해진 것은 아니었습니다. 그래서 팀원들도 처음에는 너무나도 불편해 했습니다. 하지만 이를 한달간 사용해보니 점점 이점이 생겨났습니다. 소스코드를 Git을 통해 관리하듯, 이제는 테이블 스키마 변경 사항도 체계적으로 관리할 수 있게 된 것입니다. 작은 프로젝트에서는 스키마를 쉽게 관리할 수 있었지만 점점 프로젝트 규모가 커지면서 이력 관리가 필수적이 되었기 때문입니다.

기대한 만큼의 자동화는 아니였지만, 테이블 스키마 변경도 코드와 마찬가지로 형상 관리의 대상이 될 수 있다는 점에서 Flyway는 유용한 도구였습니다. 또한, 오류 발생시 스키마 변경 이력을 통해 문제를 파악하는데 큰 도움이 되었습니다.