코드에 Git이 있다면, DB에는 Flyway가 있다 (feat. DB Orchestrating)

Step 1. 왜 Flyway인가? (유용성)

과거에 수동으로 SQL 파일을 공유하며 alter table을 날리던 시절의 고충을 언급하며 시작합니다.

• 형상 관리의 자동화: 로컬, 개발, 운영 환경의 DB 상태를 똑같이 동기화합니다.
• 버전 관리: 어떤 스크립트가 언제 실행되었는지 history_table을 통해 추적 가능합니다.
• 휴먼 에러 방지: "앗, 운영 서버에 컬럼 추가 안 했네!" 같은 대참사를 막아줍니다.

Step 2. Flyway의 핵심 동작 원리

Flyway는 프로젝트가 뜰 때 db/migration 폴더의 파일을 읽어 버전 번호순으로 Orchestrating(조율) 하여 실행합니다.

• V1__initial.sql, V2__add_column.sql 처럼 명확한 네이밍 규칙을 따릅니다.
• 이미 실행된 파일은 Checksum을 통해 변경 여부를 감시합니다.

Step 3. 실무 사용법 (Spring Boot 기준)

1. 의존성 추가: spring-boot-starter-data-jpa와 함께 flyway-core를 추가합니다.
2. 설정: application.yml에서 enabled: true 확인.
3. 파일 위치: src/main/resources/db/migration/ 아래에 SQL 작성.

Step 4. 8년 차의 꿀팁 (주의사항)

• Coalescing의 미학: 마이그레이션 파일이 너무 많아지면 관리가 힘듭니다. 특정 시점에 이전 파일들을 하나로 합치는(Baseline) 전략이 필요합니다.
• 이미 운영 중인 DB: baseline-on-migrate: true 옵션을 사용하여 기존 DB 상태를 버전 1로 잡는 법을 공유하세요.

---

3. 마무리 문구 (마치며)

"결국 좋은 아키텍처란 개발자가 비즈니스 로직에만 집중할 수 있게 환경을 Levitating(공중에 띄우듯 마찰 없이) 만드는 것입니다. Flyway는 그 환경을 만드는 가장 기초적인 초석입니다."