데이터베이스 스키마 Expand-Contract 적용 가이드

운영 데이터베이스에서 위험한 순간은 새 기능 배포보다 스키마 변경일 때가 많습니다. 컬럼 이름 하나 바꾸는 일도 애플리케이션, 배치, 리포트, 외부 적재 파이프라인까지 동시에 흔들 수 있기 때문입니다. 그래서 실전에서는 한 번에 바꾸기보다 expand-contract 방식으로 나눠서 움직입니다.

expand 단계에서 하는 일

• 새 컬럼이나 새 테이블을 먼저 추가
• 읽기는 구버전과 신버전을 모두 허용
• 쓰기는 이중 기록 여부를 결정
• 백필과 검증 작업을 분리

이 단계의 목표는 “새 구조를 도입해도 시스템이 아직 깨지지 않는 상태”를 만드는 것입니다.

contract 단계에서 하는 일

• 구컬럼 읽기 제거
• 오래된 쓰기 경로 차단
• 백필 완료 검증
• 최종 삭제 전 모니터링 기간 확보

삭제를 서두르면 가장 늦게 남아 있던 숨은 소비자가 사고를 냅니다.

결론

스키마 변경의 핵심은 DDL 문법이 아니라 순서입니다. expand-contract를 습관으로 만들면 배포는 조금 느려 보여도, 복구 비용과 장애 위험은 훨씬 작아집니다.

Continue Reading

다음으로 읽기 좋은 글

🗄️ Database

Idempotent Backfill 체크포인트 설계

백필은 한 번에 끝나지 않는 경우가 많습니다. 중단과 재시작을 견디는 체크포인트 설계가 데이터 작업의 안정성을 좌우합니다.

🗄️ Database

무중단 스키마 마이그레이션 설계 가이드

운영 중인 서비스에서 데이터베이스 스키마를 끊김 없이 변경하기 위한 확장-이행-정리 패턴과 실무 체크포인트를 정리합니다.

💬 Language

런타임 스키마 경계 실전 설계

TypeScript, Python, Java 같은 언어에서 정적 타입만으로 막기 어려운 외부 입력을 런타임 스키마로 보호하는 방법을 정리합니다.

📈 최신 동향

플랫폼 엔지니어링을 제품 지표로 운영하기

내부 플랫폼을 인프라 묶음이 아니라 개발자 제품으로 보고 활성도, 성공률, 리드타임, 만족도를 측정하는 방법을 정리합니다.