[Flyway] Spring Boot에서 Flyway와 Hibernate 초기화 순서가 중요한 이유

은서·2026년 1월 18일

Springboot - Flyway

목록 보기
2/7

1. 들어가며: 실제로 겪은 문제

Spring Boot 애플리케이션을 처음 실행했을 때 이런 에러를 본 적 있나요?

Table 'mydb.users' doesn't exist

분명 Flyway 마이그레이션 스크립트에 CREATE TABLE users ... 구문을 작성했는데 왜 테이블이 없다고 할까요?

이 문제의 핵심은 초기화 순서에 있습니다. Hibernate가 Flyway보다 먼저 실행되면서 아직 생성되지 않은 테이블을 검증하려다 실패하는 것이죠.

2. ddl-auto: validate를 사용하는 이유

- 프로덕션 환경에서 권장되는 설정

spring:
  jpa:
    hibernate:
      ddl-auto: validate  # ⭐ 엔티티와 DB 스키마가 일치하는지만 검증

- ddl-auto 옵션 비교

옵션동작프로덕션 사용
validateDB 스키마와 엔티티 일치 여부만 검증 (변경 없음)✅ 권장
update엔티티에 맞춰 DB 스키마 자동 수정⚠️ 위험 (컬럼 삭제 안됨)
create매번 테이블 DROP 후 재생성❌ 절대 사용 금지
create-drop애플리케이션 종료 시 테이블 삭제❌ 테스트 용도만
none아무것도 안 함✅ Flyway 사용 시

- validate를 선택하는 이유

1. 안전성

  • DB 스키마를 절대 변경하지 않음
  • 실수로 테이블이 삭제되거나 수정될 위험 없음

2. 명확한 책임 분리

  • 스키마 관리: Flyway (버전 관리, 롤백 가능)
  • 스키마 검증: Hibernate (엔티티와 DB 일치 여부 확인)

3. 배포 안정성
개발자 A: User 엔티티에 email 컬럼 추가
개발자 B: Flyway 마이그레이션 스크립트 작성 (V2__add_email_column.sql)

❌ update 사용 시: 개발자 B가 마이그레이션 스크립트를 안 만들어도 동작함
→ 배포 시 스크립트 누락 → 프로덕션 장애

✅ validate 사용 시: 마이그레이션 스크립트 없으면 즉시 에러 발생
→ 배포 전에 문제 발견 가능

3. 순서가 왜 중요한가?

❌ 잘못된 순서 (Hibernate → Flyway)

1️⃣ Hibernate 초기화 시작
→ "User 엔티티가 있네? DB에 users 테이블이 있는지 확인해야지!"

2️⃣ DB 확인
→ "어? users 테이블이 없는데요? 🚨"

💥 org.hibernate.tool.schema.spi.SchemaManagementException:
Schema-validation: missing table [users]

3️⃣ 애플리케이션 시작 실패
→ Flyway는 실행조차 못함

✅ 올바른 순서 (Flyway → Hibernate)

1️⃣ Flyway 마이그레이션 실행
→ V1__create_users_table.sql 실행
→ CREATE TABLE users (...) ✅

2️⃣ Hibernate 초기화
→ "User 엔티티가 있네? DB에 users 테이블이 있는지 확인해야지!"
→ "있네! 컬럼도 일치하고! ✅"

3️⃣ 애플리케이션 정상 시작 🎉

4. 실제 실행 로그로 확인하기

순서 확인을 위한 로거 작성

실제 콘솔 로그

핵심 포인트

  1. Flyway가 먼저 실행됨
  2. 마이그레이션 완료 후 Hibernate 시작
  3. Hibernate는 이미 존재하는 테이블을 검증만 함

5. SpringBoot의 해결 방법 미리보기

🤔 그럼 개발자가 직접 순서를 관리해야 하나?

아닙니다! Spring Boot는 이미 자동으로 순서를 보장합니다.

시각적 플로우

  • 핵심 메커니즘 요약

    Spring Boot 2.5+ 부터는 DatabaseInitializationDependencyConfigurer가:
  1. @DependsOnDatabaseInitialization 애노테이션이 붙은 Bean 찾기
  2. 자동으로 dependsOn = ["flywayInitializer"] 주입
  3. Spring Container가 Bean 생성 순서 보장
// EntityManagerFactory는 이 애노테이션이 붙어있음
@DependsOnDatabaseInitialization
public class LocalContainerEntityManagerFactoryBean { ... }
  • 결과: 개발자는 아무것도 안 해도 Flyway가 먼저 실행된다.

6. 마무리&다음편 예고

✅ 이번 편에서 배운 것

1. ddl-auto: validate를 사용하는 이유

  • 프로덕션 환경에서 안전
  • Flyway와 명확한 책임 분리
    2. 초기화 순서가 중요한 이유
  • Hibernate가 먼저 실행되면 테이블 없다고 에러
  • Flyway → Hibernate 순서가 필수
    3. Spring Boot의 자동 순서 보장
  • DatabaseInitializationDependencyConfigurer
  • dependsOn 자동 주입으로 순서 보장

📖 다음 편 예고 - 3. Spring Boot DatabaseInitializationDependencyConfigurer 동작 원리 - 소스 코드 분석

다음 편에서는:

  • BeanFactoryPostProcessor가 언제 어떻게 동작하는지
  • dependsOn이 어떻게 자동으로 주입되는지
  • Spring Framework 소스 코드를 직접 분석
  • LocalContainerEntityManagerFactoryBean 내부 동작
    을 알아보겠습니다!
profile
개발자 대학생🌱

0개의 댓글