[Gin] GORM 마이그레이션 전략 - 자동 vs 수동 관리, 안전하게 스키마 관리하기

Go로 백엔드를 개발할 때 GORM의 마이그레이션 기능은 정말 편리하다.
하지만 무턱대고 자동 마이그레이션만 쓰다 보면 데이터 유실, 인덱스 충돌, 운영 장애까지 발생할 수 있다.

이번 글에서는 GORM에서 자동 마이그레이션과 수동 마이그레이션을 언제 어떻게 써야 하는지, 실전 전략을 정리해보자.

 

---

 

 

📌 목차
- GORM AutoMigrate 기본 사용법
- 자동 마이그레이션의 한계와 리스크
- 수동 마이그레이션 관리 전략
- 실전 추천 전략 (개발/운영 구분)
- 마무리 요약

 

 

728x90

 

 

 

1. GORM AutoMigrate 기본 사용법

GORM은 AutoMigrate()로 테이블을 생성하고 컬럼을 자동으로 추가해준다.

db.AutoMigrate(&User{}, &Post{})

 

- 존재하지 않는 테이블이면 생성
- 컬럼이 없으면 추가됨
- 인덱스도 일부 생성됨

✅ 장점: 빠르고 간편함
❌ 단점: "삭제"나 "변경"은 절대 하지 않음

 

 

 

 

2. 자동 마이그레이션의 한계와 리스크

🚨 컬럼 변경 or 삭제 안 됨

type User struct {
	Name string `gorm:"size:100"`
}

 

기존에 size:255로 생성된 name 컬럼이 있어도,
AutoMigrate는 이를 수정하지 않는다. → 스키마와 모델 불일치

 

❌ 인덱스 수정도 안 됨
- 기존 인덱스를 변경하려 해도 무시됨
- 중복 인덱스 발생 위험 있음

🧨 운영환경에서 실수로 실행하면?
- 예상 못한 구조로 테이블이 생성될 수 있음
- 예: 관계 설정이 빠져서 FK 없이 테이블 생성

 

 

 

 

 

3. 수동 마이그레이션 관리 전략

실무에서는 마이그레이션 스크립트를 버전별로 관리하는 게 일반적이다.

📦 golang-migrate 사용 예시

- 설치

brew install golang-migrate

 

- 마이그레이션 생성

migrate create -ext sql -dir db/migrations create_users_table

 

- 스크립트 작성

-- db/migrations/001_create_users_table.up.sql
CREATE TABLE users (
    id SERIAL PRIMARY KEY,
    name VARCHAR(100) NOT NULL
);

 

- 실행

migrate -path db/migrations -database "postgres://user:pass@localhost:5432/dbname?sslmode=disable" up

 

GORM과 별도로 DB 버전을 명확히 관리할 수 있음
실시간 롤백도 가능 (down.sql 사용)

 

 

 

4. 실전 추천 전략 (개발 vs 운영 분리)

환경	추천 방식	이유
개발	AutoMigrate() 사용	빠른 테스트, 초기 테이블 생성에 유용
운영	golang-migrate 등 수동 관리	DB 구조 통제, 검증된 스크립트만 반영 가능

 

💡 개발 단계에서 생성된 모델을 기반으로 SQL을 추출하고, 운영에서는 반드시 수동 반영하자.

 

 

 

 

 

 

5. 마무리 요약

전략	설명
AutoMigrate	빠르게 모델 기반 테이블 생성 (단, 변경/삭제는 안 됨)
수동 마이그레이션	SQL 스크립트 기반 버전 관리, 안정적 운영에 필수
운영환경 적용시	사전 검토된 수동 마이그레이션만 적용 권장