핵심 인사이트 (3줄 요약)

  1. 본질: Expand and Contract 패턴은 DB 스키마 변경(DDL)을 **확장(Expand) → 병행(Migrate) → 수축(Contract)**의 3단계로 분리하여, 신·구버전 앱이 동시에 운영 DB를 사용해도 서비스 중단 없이(Zero-Downtime) 스키마를 진화시키는 기법이다.
  2. 가치: 컬럼 삭제·이름 변경을 가장 마지막 단계로 미룸으로써, 배포 중 롤백하더라도 DB 데이터가 그대로 남아 장애를 방지하며, 이는 블루/그린 배포의 DB 판 완성형이다.
  3. 판단 포인트: Flyway·Liquibase로 각 단계를 **버전 관리(V1__expand, V2__migrate, V3__contract)**하고 CI/CD에 통합하며, 데이터 마이그레이션은 Lazy Migration 또는 DB 트리거로 실시간 동기화한다.

Ⅰ. 개요 및 필요성

앱은 블루/그린·카나리 배포로 무중단이 가능하지만, DB 스키마(DDL)는 갑자기 바꾸면 구버전 앱이 에러를 뿜는다. "컬럼 이름을 namefull_name으로 바꿔야 하는데, 구버전 앱은 아직 name을 읽고 있다." 이때 점검 페이지를 띄우는 것은 현대 DevOps의 목표가 아니다.

┌───────────────────────────────────────────────────────┐
│       Expand and Contract 3단계 흐름도                 │
├───────────────────────────────────────────────────────┤
│  Phase 1: Expand (확장)                               │
│   DB: full_name 컬럼 추가 (name 그대로 유지)          │
│   App v1: name 읽기/쓰기 (변경 없음)                  │
│                                                       │
│  Phase 2: Migrate (병행)                              │
│   DB: name → full_name 데이터 복사 (트리거/배치)      │
│   App v2: full_name 쓰기 + name에도 동시 기록         │
│   (구버전 앱 호환 유지)                               │
│                                                       │
│  Phase 3: Contract (수축)                             │
│   App v2 전면 배포 확인 후                            │
│   DB: name 컬럼 삭제 (청소)                           │
│   App v2: full_name만 사용                            │
│                                                       │
│  롤백 안전: Phase 1~2에서 문제 시 name 그대로 활용    │
└───────────────────────────────────────────────────────┘
  • 📢 섹션 요약 비유: 레고 성의 빨간 기둥을 파란색으로 바꾸고 싶을 때, 성을 무너뜨리지 않고 파란 기둥을 옆에 세우고(Expand), 사람들을 파란 기둥으로 옮긴 뒤(Migrate), 빨간 기둥을 조용히 빼내는(Contract) 공사법이다.

Ⅱ. 아키텍처 및 핵심 원리

3단계 상세

단계DB 변경앱 변경호환성
Expand새 컬럼 추가 (구 컬럼 유지)변경 없음구버전 100% 호환
Migrate데이터 동기화 (트리거/배치)신버전 배포 (양쪽 쓰기)신·구 동시 호환
Contract구 컬럼 삭제구버전 완전 제거 확인 후신버전 전용

데이터 마이그레이션 전략

전략방식장점단점
배치 마이그레이션일괄 UPDATE SQL간단대량 데이터 시 DB 부하
Lazy Migration앱이 읽을 때 없으면 복사부하 분산완료 시점 불확실
DB 트리거INSERT/UPDATE 시 자동 동기화실시간트리거 관리 복잡
  • 📢 섹션 요약 비유: 배치는 이사할 때 트럭 한 번에 짐을 다 옮기는 것이고, Lazy는 필요할 때만 하나씩 가져오는 것이며, 트리거는 매일 자동으로 짐을 옮기는 로봇이다.

Ⅲ. 비교 및 연결

비교빅뱅 배포Expand & Contract
방식점검 페이지 → 한 번에 변경서비스 유지하며 단계적
호환성고려 안 함구·신버전 동시 호환
복잡도낮음높음 (3단계)
롤백DB 복원 매우 어려움매우 쉬움 (데이터 유실 0)
적합 환경소규모·저위험금융·이커머스·고가용

Ⅳ. 실무 적용 및 기술사 판단

CI/CD 통합 체크리스트

  1. Flyway/Liquibase로 SQL 스크립트를 V1__expand.sql, V2__migrate.sql, V3__contract.sql로 버저닝.
  2. 파이프라인: 앱 배포 전에 Expand, 앱 배포 Migrate, 구버전 제거 확인 후 Contract.
  3. 테스트: "구버전 앱 + 신버전 DB" 조합으로 통합 테스트 필수 실행.

안티패턴

  • Contract 서두르기: 구버전 앱이 아직 남아있는데 구 컬럼 삭제 → 구버전 앱 에러 폭발.
  • 마이그레이션 미완료 확인 누락: 10만 건 중 1천 건만 복사된 상태에서 Contract → 데이터 소실.

Ⅴ. 기대효과 및 결론

지표빅뱅 배포E&C 패턴개선
서비스 중단30분~수시간0분100%
롤백 안전성낮음매우 높음데이터 유실 0
배포 빈도월 1회일 수회DevOps 가속

무중단 DB 스키마 롤아웃은 "진정한 지속적 배포(CD)"를 완성하는 마지막 퍼즐이다. 앱은 자유롭게 배포하면서 DB 때문에 점검을 잡는다면, 그것은 반쪽짜리 DevOps다.


📌 관련 개념 맵

개념연결 포인트
Blue/Green Deployment앱 무중단 배포의 짝꿍
Flyway / LiquibaseDB 마이그레이션 버전 관리 도구
하위 호환성 (Backward Compatibility)Expand 단계에서 반드시 보장해야 할 성질
Canary ReleaseDB 변경 영향도를 조금씩 확인하는 배포 전략
Feature Toggle신·구 로직 전환을 코드 레벨에서 제어

📈 관련 키워드 및 발전 흐름도

[점검 페이지 시대 — DB 변경 시 서비스 전면 중단]
    │
    ▼
[Expand and Contract 패턴 (2010s) — 단계적 스키마 진화]
    │
    ▼
[Flyway/Liquibase CI/CD 통합 (2015~) — 마이그레이션 자동화]
    │
    ▼
[현재: Online DDL + Ghost/pt-osc — 대용량 테이블 무중단 변경]

👶 어린이를 위한 3줄 비유 설명

  1. 레고 성의 빨간 기둥을 파란색으로 바꾸고 싶은데, 성을 무너뜨리기 싫어요.
  2. 먼저 파란 기둥을 옆에 하나 더 세우고, 사람들이 파란 기둥을 쓰게 한 다음에,
  3. 마지막에 쓸모없어진 빨간 기둥을 조용히 빼내는 아주 조심스러운 공사 방법이에요!