ID: key_26_14_03_30_14_58_02_41500 Created date: 3월 30 2026 월요일, 14주 14:58
연관 문서
— V3__add_phone_to_users.sql ALTER TABLE auth.users ADD COLUMN phone VARCHAR(20);
### 2단계 — Flyway가 DB에 이력 테이블을 관리
flyway_schema_history 테이블 (Flyway가 자동 생성) ┌─────────────────────────────────────────────────┐ │ version │ description │ installed_on │ ├─────────────────────────────────────────────────┤ │ 1 │ create schemas │ 2026-01-10 9:00 │ │ 2 │ create auth tables │ 2026-01-10 9:00 │ │ 3 │ add phone to users │ 2026-03-15 2:00 │ ← 여기까지 실행됨 └─────────────────────────────────────────────────┘
### 3단계 — 앱 시작할 때 자동으로 "아직 안 실행된 파일만" 실행
팀원 A가 코드 pull 후 앱 시작 → Flyway: “V1, V2는 이미 실행됨. V3은 아직 없네?” → V3__add_phone_to_users.sql 자동 실행 → 팀원 A의 DB에도 phone 컬럼 생김 ✅
---
## 즉, Flyway로 얻는 것
| 없을 때 | 있을 때 |
|---|---|
| "내 DB엔 되는데 니 DB엔 왜 안돼?" | 팀원 모두 동일한 DB 상태 보장 |
| 서버에 배포할 때 SQL 수동으로 실행 | 배포 시 자동으로 DB도 업데이트 |
| "이 테이블 언제 어떻게 바뀌었지?" | Git처럼 DB 변경 이력 추적 가능 |
| 로컬 DB 날리면 다시 만들기 귀찮음 | `docker compose up` 하면 자동 복원 |
---
## Git이랑 비교하면 이해가 쉬워요
Git이 코드 변경 이력을 관리하듯이, Flyway는 DB 구조 변경 이력을 관리해요.
commit: “유저 테이블에 phone 컬럼 추가” → V3__add_phone_to_users.sql 파일 하나 추가하는 것과 같아요
연관 메일