스키마 드리프트(schema drift)는 "있어야 할 스키마의 정의"와 "실제 스키마"가 조금씩 어긋나는 현상이다. 한쪽이 바뀌었는데 다른 쪽이 따라가지 못해 생긴다. 기준선에서 서서히 떠내려간다는 뉘앙스로 drift라는 말을 쓴다.
대표적인 세 맥락
- 모델 ↔ 마이그레이션: ORM(Object-Relational Mapping) 모델을 고치고 마이그레이션을 만들지 않았거나, 누군가 DB에 직접
ALTER TABLE을 쳐서 마이그레이션 기록과 실제 테이블이 달라진다 - 백엔드 모델 ↔ 프론트엔드 생성 타입: 백엔드 스키마에서 TypeScript 타입을 생성하는 구조에서, 모델만 바꾸고 타입을 다시 생성하지 않으면 응답 형태와 프론트엔드의 기대가 어긋난다. 타입 검사는 통과하는데 런타임에서 깨진다
- 환경 간: 운영·QA·로컬 DB의 스키마가 서로 달라진다. 운영에만 적용된 마이그레이션이 로컬에 없는 경우
막는 방법
- 모델 변경, 마이그레이션 파일, 생성된 타입을 한 커밋에 세트로 넣는다(원자적 커밋)
- CI에서 드리프트를 검사한다. Django는
manage.py makemigrations --check가 모델과 마이그레이션의 차이를 찾으면 실패한다. 생성 타입도 CI에서 다시 생성해 diff가 없는지 본다 - DB를 손으로 고치지 않는다. 모든 변경은 마이그레이션으로
- 스키마 변경은 확장 → 이전 → 축소(expand-migrate-contract) 순서로 나눠 배포해 구버전·신버전이 공존하게 한다(병렬 수정 (팽창-수축))
python manage.py makemigrations --check --dry-run인프라 설정이 기록과 어긋나는 같은 현상을 설정 드리프트(configuration drift)라고 하고, GitOps가 이를 막는다. 타입이 런타임 데이터와 맞는지 경계에서 검증하는 일은 타입 추론과 타입 검사과 이어진다. 컬럼 구조와 제약 조건도 같은 방식으로 관리한다.