마이그레이션: 스키마를 안전하게 바꾸기

당신의 스키마는 변한다 — 컬럼을 추가하고, 테이블 이름을 바꾸고, 인덱스를 추가하게 된다. 공유 문서의 변경 이력 추적처럼 생각하라: 모든 변경이 순서대로 기록되어, 누구의 사본이든 같은 방식으로 최신 상태로 맞출 수 있다. 마이그레이션은 그런 변경 하나를 기술하는 버전 관리되고 반복 가능한 스크립트다. 마이그레이션이 중요한 이유는, 당신의 노트북, 동료의 노트북, 그리고 프로덕션의 스키마가 동일하게 유지되어야 하기 때문이다.

마이그레이션을 안전하게 지키는 규칙:

• 프로덕션에서 데이터베이스를 손으로 절대 수정하지 말라. 마이그레이션을 작성하라.
• 마이그레이션은 앞으로 나아간다. 각각이 새 파일이며, 이미 실행된 옛것을 다시 쓰지 않는다.
• 파괴적 변경은 신중히 하라. 컬럼이나 테이블을 드롭하면 데이터가 영구히 삭제된다. 먼저 백업을 가져라.
• 추가하는 변경이 가장 안전하다. nullable 컬럼을 추가하는 것은 거의 아무것도 깨뜨리지 않지만, 이름을 바꾸거나 제거하는 것은 실행 중인 코드를 깨뜨릴 수 있다.

마이그레이션은 순서가 있는 사슬을 이룬다: 각각은 번호 매겨진 단계로, 데이터베이스의 모든 사본을 한 알려진 상태에서 다음 상태로 옮긴다. 그래서 당신의 노트북, 동료의 노트북, 프로덕션이 모두 동일하게 끝난다:

   빈 DB
      │
      ▼
  ┌────────────┐   ┌────────────┐   ┌────────────┐   ┌────────────┐
  │ 001_생성   │ ▶ │ 002_추가   │ ▶ │ 003_인덱스 │ ▶ │ 004_bio    │
  │ users      │   │ posts      │   │ on author  │   │ 컬럼 추가  │
  └────────────┘   └────────────┘   └────────────┘   └────────────┘
   순서대로 적용 ───────────────────────────────────────▶ 현재
   이미 실행된 단계는 고치지 말 것 — 새 단계를 추가

Prisma, Drizzle, 또는 Rails 마이그레이션 같은 도구가 이것들을 생성하고 추적해준다. 도구에게 맡겨라.

마이그레이션은 두 부분으로 이루어진다: 적용할 변경(up)과 그것을 되돌리는 법(down). 신뢰할 만한 도구는 둘 다 생성해주어, 잘못된 배포가 깔끔하게 롤백될 수 있다:

-- up: 선택적 bio 추가, 라이브에서 적용해도 안전
ALTER TABLE users ADD COLUMN bio TEXT;

-- down: 되돌리기
ALTER TABLE users DROP COLUMN bio;

정말로 위험한 마이그레이션은 이름 변경과 타입 변경인데, 옛 코드와 새 스키마가 잠시 어긋나기 때문이다. 프로페셔널한 패턴은 그것들을 추가적 단계로 쪼개는 것이다: 새 컬럼을 추가하고, 백필하고, 코드가 그것을 읽도록 전환한 다음, 아무것도 참조하지 않게 된 나중의 배포에서야 옛 컬럼을 드롭한다. 느리게 느껴지지만, 매끄러운 릴리스와 배포 도중 모든 사용자에게 터지는 500 에러 급증 사이의 차이다.