실무에서 ddl-auto를 사용하는가..?

✅ 실무에서 ddl-auto를 사용할까?

실무에서는 ddl-auto를 거의 사용하지 않습니다.
대신 DB 마이그레이션 도구(예: Flyway, Liquibase)를 사용하여 스키마를 관리하는 것이 일반적입니다.

---

🔹 ddl-auto란?

JPA에서 hibernate.hbm2ddl.auto (또는 spring.jpa.hibernate.ddl-auto)는 데이터베이스 테이블을 자동으로 생성·수정하는 설정입니다.

옵션 값	설명	실무 사용 여부
none	DDL을 실행하지 않음	✅ (실무 기본값)
create	기존 테이블 삭제 후, 새로 생성	❌ (데이터 삭제 위험)
create-drop	create와 동일 + 애플리케이션 종료 시 테이블 삭제	❌ (테스트 환경에서만)
update	변경된 필드만 수정 (제약 조건 변경 X)	⚠️ (초기 개발 단계에서만)
validate	매핑 정보와 DB 스키마를 검증 (불일치 시 예외 발생)	✅ (실무에서 검증용)

---

🔹 실무에서 ddl-auto를 사용하지 않는 이유

1. 데이터 손실 위험 (create, update)

   • create 사용 시, 기존 테이블이 삭제되므로 데이터가 날아갈 위험이 큼
   • update는 필드 추가는 가능하지만, 제약 조건 변경, 컬럼 삭제는 반영되지 않음

2. DB 구조 변경 관리 문제

   • update는 일부 필드만 변경하므로, 테이블 구조 변경 시 예측이 어려움
   • 실무에서는 DB 마이그레이션 도구(Flyway, Liquibase)로 버전별 관리하는 것이 일반적

3. 테스트 환경과 실무 환경의 차이

   • 개발 환경에서는 편리하지만, 실무에서는 운영 DB를 보호하는 것이 중요
   • 운영 환경에서는 보통 DDL 자동 실행 없이, 수동으로 스키마 적용

---

🔹 실무에서는 어떻게 할까?

✔ ddl-auto=none을 설정하여 자동 변경을 막고, 명시적으로 SQL 관리
✔ Flyway 또는 Liquibase 같은 마이그레이션 도구를 사용하여 DB 변경 이력을 관리

📌 실무용 application.yml 예시

spring:
  jpa:
    hibernate:
      ddl-auto: none  # 실무에서는 자동 변경 금지

📌 대신 Flyway를 사용한 마이그레이션 예시

-- V1__Create_users_table.sql
CREATE TABLE users (
    id BIGINT PRIMARY KEY AUTO_INCREMENT,
    name VARCHAR(255) NOT NULL,
    email VARCHAR(255) UNIQUE
);

• Flyway를 사용하면 DB 변경 사항을 명확하게 버전 관리할 수 있음

---

🔹 결론

✅ 실무에서는 ddl-auto=none을 사용하고, Flyway 또는 Liquibase로 DB를 관리
✅ update, create는 초기 개발 단계에서만 제한적으로 사용
✅ 운영 환경에서는 DB 변경 사항을 직접 SQL로 적용하는 것이 안전

즉, 실무에서는 ddl-auto를 거의 사용하지 않으며, 체계적인 DB 변경 관리가 필요합니다!
더 궁금한 점이 있으면 질문 주세요! 😊