spring.jpa.hibernate.ddl-auto는 Spring Boot가 Hibernate의 스키마 관리 동작을 설정하는 속성입니다. Spring Data JPA 자체의 표준 옵션은 아닙니다. 운영에서는 애플리케이션 매핑과 DB 변경 이력을 별도로 관리하고, Hibernate가 맡을 범위를 명확히 정해야 합니다.
1. 옵션별 동작
| 값 | Hibernate의 주요 동작 | 사용할 환경 |
|---|---|---|
none | 자동 스키마 생성·변경·검증을 수행하지 않음 | 스키마를 별도 도구로 관리하는 환경 |
validate | 기동 시 지원 범위 내에서 매핑과 스키마 검증 | 마이그레이션 후 추가 검증이 필요한 환경 |
update | 매핑을 기준으로 스키마 갱신 시도 | 폐기 가능한 개발 DB 등 제한된 환경 |
create | 기동 시 매핑 대상 객체의 삭제·재생성을 시도 | 데이터 보존이 필요 없는 개발·테스트 |
create-drop | 생성 후 SessionFactory 종료 시 삭제도 시도 | 정상 종료를 전제로 하는 임시 테스트 |
create는 서버에 있는 모든 데이터베이스를 통째로 지우는 명령은 아닙니다. 그렇다고 안전한 것도 아닙니다. 매핑 대상 테이블 등 기존 객체와 데이터가 삭제될 수 있으므로, 보존해야 하는 DB에서 사용하지 않습니다.
create-drop의 종료 시 삭제는 프로세스 강제 종료·충돌 등에서 실행되지 않을 수 있습니다. 테스트 데이터 정리는 전용 DB·컨테이너의 수명 주기까지 포함해 설계합니다.
2. 기본값을 추측하지 않기
Spring Boot는 내장 DB로 판단하고 Flyway·Liquibase 같은 스키마 관리자가 없으면 일반적으로 create-drop을 기본값으로 선택합니다. 그 외에는 none이 기본값입니다. 환경 변경 때 같은 동작을 가정하지 말고, 사용하는 Boot 버전의 문서와 최종 적용 설정을 확인합니다. Spring Boot DB 초기화
운영 프로파일에서 Hibernate 검증을 사용하는 예입니다.
spring:
jpa:
hibernate:
ddl-auto: validate
sql:
init:
mode: neverspring.sql.init.mode: never는 Boot의 기본 SQL 스크립트 초기화를 끄는 설정입니다. Flyway·Liquibase나 직접 작성한 코드의 DB 변경까지 막지는 않습니다. 또한 ddl-auto: none만으로 schema.sql, 별도 마이그레이션, 애플리케이션의 DML이 모두 비활성화되는 것은 아닙니다.
3. validate가 보증하지 않는 것
validate는 지원하는 검증 항목의 불일치를 발견하면 기동 실패로 이어질 수 있습니다. 하지만 모든 인덱스·제약 조건·기본값·트리거·데이터 의미를 완전히 비교하는 도구는 아닙니다. 검증 범위는 Hibernate와 DB 방언의 구현에 따라 달라집니다.
따라서 validate 통과를 코드와 DB의 완전한 정합성 보증으로 해석하지 않습니다. 주요 쿼리의 통합 테스트, 마이그레이션 테스트, 데이터 제약 확인이 별도로 필요합니다.
4. update 대신 변경 의도를 남기기
Hibernate는 매핑의 차이만으로 “컬럼 이름을 바꾼 것인지, 기존 컬럼과 다른 새 컬럼을 추가한 것인지” 같은 의도를 충분히 알 수 없습니다. 데이터 변환·백필·이전 버전 호환·잠금 시간을 모두 고려하는 배포 계획도 대신하지 않습니다.
운영 스키마는 Flyway·Liquibase 등의 변경 파일과 이력으로 관리하고, 로컬에서도 같은 변경 경로를 재현하면 환경 차이를 줄이기 좋습니다. update를 사용한 로컬 DB에 우연히 쌓인 변경이 운영에 재현된다고 가정해서는 안 됩니다.
5. 마이그레이션과 복구
마이그레이션 도구를 도입해도 모든 변경이 자동으로 되돌아가지는 않습니다. 롤백 지원은 도구·에디션·변경 유형에 따라 다르고, 삭제된 데이터는 역방향 DDL만으로 복구되지 않습니다. DBMS의 DDL 트랜잭션 지원 범위도 확인합니다.
배포 전에는 다음을 확인합니다.
- 새 스키마가 배포 중인 이전·새 애플리케이션 버전과 함께 동작하는가?
- 큰 테이블 변경의 잠금·소요 시간·여유 공간을 시험했는가?
- 백필과 제약 강화가 필요한 경우 단계를 분리했는가?
- 실패했을 때 재시도·보정 변경·백업 복원 중 무엇을 사용할 것인가?
- 실제 운영 프로파일·환경 변수·접속 대상이 예상과 같은가?
none과 validate 중 하나만이 언제나 정답인 것은 아닙니다. 스키마 변경은 명시적 마이그레이션이 담당하고, Hibernate 검증을 기동 단계에서 사용할지 팀의 배포 흐름에 맞춰 결정합니다.
