---
kind: REFERENCE
slug: an-applied-checksum-is-a-promise
title: 적용된 마이그레이션의 checksum은 그것을 돌린 모든 배포에 대한 약속이다
topic: schema-ownership-and-capability-streams
project: clean-architecture-backend-template
status: 게시 전
sourceRevision: 21234e38cdb9a926cbc92bb97a2aee2e4a7d2916
rootTreeNode: reference:an-applied-checksum-is-a-promise
verifiedOn:            # 이 기록은 이번 회차에 실행 확인을 하지 않았다
---

# 적용된 마이그레이션의 checksum은 그것을 돌린 모든 배포에 대한 약속이다

## 목적

이미 적용된 마이그레이션 파일을 수정해, 그것을 적용한 배포와 앞으로 적용할 배포가 서로 다른 스키마를 갖게 되는 것을 막는다.

## 규칙

1. 적용된 파일은 수정하지 않는다
   체크섬이 바뀌면 그 파일을 이미 적용한 배포에서 검증이 실패한다.

2. 고쳐야 할 것은 새 마이그레이션으로 고친다
   앞의 것을 되돌리거나 보정하는 마이그레이션을 새로 만든다.

3. 새 마이그레이션은 순서에 무관하게 동작하도록 가드한다
   여러 스트림이 같은 대상을 만들 수 있으면, 어느 쪽이 먼저 돌든 올바르게 끝나야 한다.

4. 반복 비용을 두 번 내지 않는다
   이미 처리된 대상은 건너뛴다. 테이블 재작성 같은 비싼 작업일수록 중요하다.

5. 수정 이력을 헤더에 남긴다
   왜 새 번호가 필요했는지가 그 파일에 있어야 다음 사람이 앞의 것을 고치려 하지 않는다.

## 적용 조건

버전 기반 마이그레이션을 쓰는 모든 스키마 관리

여러 배포가 서로 다른 시점에 마이그레이션을 적용하는 환경

## 예외

아직 어떤 환경에도 적용되지 않은 마이그레이션은 수정할 수 있다. 그 판단에는 모든 환경을 확인했다는 근거가 필요하다.

## 예시

컬럼 타입을 바꾸는 마이그레이션이 앞의 마이그레이션을 고치는 대신 새 번호로 추가되었고, 두 스트림의 순서가 고정되어 있지 않아 아직 옛 타입인 컬럼만 변환하도록 가드했다.

컬럼을 넓히는 마이그레이션이 두 위치 모두에 필요했다. 한쪽만 적용한 배포는 옛 제약을 유지한다.

## 관계

- **char(64)와 varchar(64) 불일치를 H2가 가리고 있었다**
  이 규칙을 따른 수정의 사례다.
- **레지스트리 컬럼이 38자 경로에서 짧아 더 짧은 경로를 적는 우회를 유혹했다**
  다섯 번째 규칙의 사례다.
- **Repair는 모드가 아니라 운영자가 호출하는 작업이다**
  체크섬 불일치를 다루는 결정이다.