되돌아갈 수 있는가? 롤백(Rollback) 가능성 검토

마이그레이션의 양방향성: Up과 Down

좋은 데이터베이스 마이그레이션 도구들은 항상 '적용(Up)'과 '취소(Down)'라는 두 가지 방향을 지원합니다.

마이그레이션을 적용하여 데이터베이스를 최신 상태로 만드는 과정을 보통 Up 스크립트라고 부릅니다. 반대로, 문제가 생겼을 때 직전 상태로 스키마를 되돌리는 과정을 Down 스크립트라고 합니다.

Down 스크립트 작성의 중요성

일반적으로 개발할 때는 Up 스크립트 작성에만 집중하기 쉽습니다. "테이블을 만들면 그만이지, 왜 지우는 쿼리까지 미리 짜야 해?"라고 생각할 수 있죠.

하지만 마이그레이션은 버전을 관리하는 시스템입니다. 코드 버전 관리 도구인 Git에서 `git revert`로 이전 커밋으로 되돌리듯이, DB 스키마도 이전 버전으로 깨끗하게 되돌아갈 수 있어야 합니다.

```sql
-- 001_create_users_table.up.sql
CREATE TABLE users (
    id SERIAL PRIMARY KEY,
    name VARCHAR(50)
);

-- 001_create_users_table.down.sql
DROP TABLE users;
```

Down 스크립트를 작성해두면, 배포 실패 시 `migrate down` 명령어 하나로 DB 스키마를 이전 버전으로 즉시 롤백할 수 있습니다. 수작업으로 어떤 테이블을 지워야 하는지 당황하며 찾을 필요가 없습니다.

모든 롤백이 완벽한 것은 아니다

여기서 한 가지 매우 중요한 딜레마가 발생합니다. 스키마 구조는 되돌릴 수 있지만, 삭제된 데이터는 되돌릴 수 없다는 점입니다.

예를 들어, `phone_number` 컬럼을 지우는 마이그레이션(Up)을 실행했다고 가정해봅시다. 나중에 아차 싶어서 롤백(Down)을 실행하면, 테이블에 `phone_number` 컬럼이 다시 생기긴 합니다. 하지만 그 안에 들어있던 고객들의 실제 전화번호 데이터는 이미 날아가고 텅 빈 상태로 복구됩니다.

데이터 보존을 위한 방어적 마이그레이션

이러한 문제 때문에, 실무에서는 롤백 시 데이터가 유실될 수 있는 파괴적인 마이그레이션(DROP, ALTER)을 최대한 뒤로 미루는 전략을 사용합니다.

1. 컬럼 추가/테이블 생성: 마음껏 합니다. 롤백해도 빈 껍데기만 지워지니 안전합니다.
2. 데이터 복사/변환: 기존 컬럼을 둔 채, 새로운 컬럼에 데이터를 복사합니다. 롤백하면 새 컬럼만 지우면 됩니다. 기존 데이터는 안전합니다.
3. 컬럼 삭제: 구버전 컬럼을 지우는 것은 충분한 시간(며칠~몇 주)이 지나고, 앱이 완벽하게 안정화된 후에 가장 마지막 마이그레이션으로 독립시켜 실행합니다.

이렇게 하면 배포 직후 장애가 발생해 긴급 롤백을 하더라도, 삭제된 데이터가 없기 때문에 100% 완벽한 원상 복구가 가능합니다.