개념 · 옵션별 동작 · 실전 사용 시나리오 · 주의할 점 총정리
Spring Data JPA(Hibernate)가 애플리케이션 시작/종료 시점에 데이터베이스 스키마를 어떻게 다룰지 결정하는 설정이 spring.jpa.hibernate.ddl-auto 입니다.
application.yml(또는 properties)에 딱 한 줄로 넣지만, 선택에 따라 데이터 유실부터 배포 사고까지 좌우될 수 있으니 옵션별 특성을 확실히 이해해야 합니다.
1. 옵션 목록과 핵심 동작
1) none
- 동작: 스키마에 전혀 손대지 않음.
- 주요 용도: 운영(Production) 환경.
- 포인트: Flyway·Liquibase 같은 마이그레이션 도구가 스키마를 책임질 때 가장 안전한 선택.
2) validate
- 동작: 애플리케이션 시작 시 엔티티 매핑과 실제 스키마를 비교해 불일치하면 즉시 실패.
- 주요 용도: 운영 및 스테이징.
- 포인트:
none보다 한 단계 안전장치 추가—“코드 ↔ DB” 정합성 보증.
3) update
- 동작: 시작 시 엔티티 모델을 기준으로 스키마를 수정(추가/변경 위주).
- 주요 용도: 로컬 개발 초중반.
- 주의:
- 컬럼 삭제·타입 변경·제약 조건 변경을 완벽히 처리하지 못함.
- 예기치 않은 DDL 실행이나 데이터 손상이 발생할 수 있어 운영 환경 금지.
4) create
- 동작: 시작 시 기존 스키마를 전부 Drop 후 새로 Create.
- 주요 용도: 초기 개발, 자동화 테스트.
- 주의: 재시작마다 데이터 사라짐. 운영에서는 절대 사용 금지.
5) create-drop
- 동작:
create와 동일하게 시작 시 새로 생성 + 애플리케이션 정상 종료 시 Drop. - 주요 용도: JUnit 통합 테스트 등 1회성 DB가 필요한 환경.
- 주의: 운영 금지.
2. 프로덕션 스키마는 이렇게 관리하자
-
마이그레이션 도구
- Flyway / Liquibase로 스키마 버전을 명시적으로 관리.
- 롤백·이력 추적이 가능해 배포 사고를 최소화.
-
ddl-auto권장 값none: Hibernate가 스키마에 일절 관여하지 않음.validate: 마이그레이션 완료 후 추가 검증 레이어로 사용.
3. 꼬리질문
Q. update가 운영에서 특히 위험한 이유는?
A. Hibernate는 추가 작업엔 강하지만 컬럼 삭제·이름/타입 변경, 복잡한 제약 조건엔 취약합니다.
DB별 DDL 차이를 해석하지 못해 데이터 손실이나 알 수 없는 오류를 일으킬 수 있으므로 운영 사용은 피해야 합니다.
Q. 로컬 개발에서 create와 update 중 무엇이 좋을까?
- 프로젝트 초기 →
create로 빠르게 구조 잡기. - DB 데이터 유지 필요 →
update로 전환하되, 위험성 인지 & 수시 백업. - 팀 규모가 크거나 장기 프로젝트 → 애초에 Flyway/Liquibase +
none/validate로 운영과 동일한 흐름 유지.
Q. Flyway를 쓰는데 ddl-auto는 어떻게?
- 가장 안전 ➜
none - 추가 검증 층 ➜
validate
create,create-drop,update는 마이그레이션 도구와 충돌 위험이 커서 사용하지 않습니다.
4. 실전 체크리스트
- 운영 프로파일에
ddl-auto: none(또는validate) 설정했는가? - 로컬·테스트 환경에서
create/update사용 시 데이터 백업과 Git DDL 이력을 남기고 있는가? - Flyway/Liquibase를 도입했다면 CI 파이프라인에 마이그레이션 검증 단계를 추가했는가?
5. 더 탐구해 보기
- 동일 프로젝트에서
create,update, Flyway 조합별 시작 로그와 실제 DDL 비교하기 - 컬럼 타입 변경(예:
VARCHAR(255)→VARCHAR(50)) 시update가 어떤 DDL을 생성하는지 실험 create-drop+ Testcontainers 로 격리된 통합 테스트 환경 구축하기
마치며
ddl-auto는 편리하지만 양날의 검입니다. 개발 효율과 데이터 안정성 사이에서 옳은 옵션을 선택해 보세요. 궁금한 점은 댓글로 남겨 주세요!
