이럴 때

불확실한 외부 통합을 붙일 때, 관계의 카디널리티를 정할 때, 인프라를 옮길 때, PoC 를 시작할 때, 그리고 컬럼·인덱스·API 버전 같은 구 경로를 없앨 때. 빨리 구현부터 들어가고 싶어질 때가 이 질문을 할 때다.

이렇게

• 불확실한 통합은 문서가 먼저다. 긴 문서를 버리는 것은 싸고, 짧은 마이그레이션을 버리는 것은 비싸다.
• 쪼개는 단위를 되돌리는 단위와 맞추고, 만들기와 전환은 다른 커밋으로 한다.
• 구 경로는 쓰기 → 읽기 → 제약 순서로 없앤다.
• PoC 는 시작할 때 "버릴 수 있다"고 적어 둔다.

멈출 신호·예외

"구 버전은 이제 안 쓰니까 지우자" 싶으면, 그 경로를 쓰는 소비자가 정말 없는지 먼저 확인한다. 몇 달 전에 빌드된 산출물을 돌리는 프로세스가 아직 살아 있을 수 있다.

설명

틀린 결정의 값은 틀림의 종류가 아니라 틀린 것 위에 무엇이 쌓여 있었는가에서 갈렸다. 코드가 0줄일 때 버린 데이터 계약은 문서 수정으로 끝났고 관계를 "하나일 것"이라 가정한 채 화면까지 쌓은 스키마는 재작성해야 했다. "PoC"라고 이름 붙여 둔 기능은 테이블을 지우는 것조차 되돌리기가 아니라 다음 단계로 읽혔다.

순서도 원칙의 일부다. 단계마다 되돌릴 수 있어도 순서가 틀리면 그 사이에 조용한 데이터 소실이 생긴다. 이 규칙을 "마이그레이션 순서"라는 좁은 말로 적었더니 인덱스 교체에서 같은 실수를 했다. "구 경로를 없애는 순서"처럼 한 층 올려 적어야 한다.

반례

모든 것을 싸게 만들 수는 없다. 뼈대(관계와 카디널리티)는 먼저 굳힌다. 화면과 함께 바꿔 가도 되는 것은 세부뿐이다. 되돌리기 쉽게 만들 수 없는 것은 먼저 정해야 한다.

판별법

"이게 틀렸다면 무엇을 버려야 하나?"

답	할 일
문서	편하게 틀려도 된다
코드	그 위에 코드가 쌓이기 전에 결정한다
재작성	뼈대다. 지금 시간을 더 쓴다

도입 비용은 시간이 아니라 "이미 그렇게 안 한 코드의 양"으로 잰다.