Change Management
Change Management
서비스 장애의 70% 이상은 변경(Change)에서 발생한다. 새 기능 배포, 설정 변경, 인프라 업그레이드 — 전부 변경이다.
Change Management는 변경으로 인한 장애를 최소화하기 위한 프로세스다. 변경을 막는 게 아니라, 변경을 안전하게 하는 것이 목적이다.
변경의 종류
| 종류 | 설명 | 예시 |
|---|---|---|
| Standard Change | 반복적이고 검증된 변경 | 패치 배포, 설정 변경 |
| Normal Change | 사전 검토가 필요한 변경 | 신규 기능 배포, 아키텍처 변경 |
| Emergency Change | 장애 대응을 위한 긴급 변경 | 핫픽스, 롤백 |
배포 전략
변경을 안전하게 하는 핵심은 점진적 배포다.
Canary 배포
전체 트래픽 중 일부(예: 1~5%)에만 먼저 배포한다. 문제가 없으면 점진적으로 확대하고, 문제가 생기면 해당 트래픽만 롤백하면 된다.
Blue/Green 배포
기존 환경(Blue)을 그대로 두고 새 환경(Green)을 별도로 구성한다. 준비되면 트래픽을 한 번에 전환하고, 문제 시 Blue로 즉시 롤백 가능하다.
Feature Flag
코드 배포와 기능 활성화를 분리한다. 코드는 배포됐지만 플래그를 끄면 사용자에게 노출되지 않는다. 특정 사용자 그룹에만 먼저 켤 수도 있다.
DORA 지표
Change Management 수준을 측정하는 4가지 지표다.
| 지표 | 의미 |
|---|---|
| Deployment Frequency | 얼마나 자주 배포하는가 |
| Lead Time for Changes | 코드 커밋 → 프로덕션 배포까지 걸리는 시간 |
| Change Failure Rate | 배포 중 장애 발생 비율 |
| Time to Restore | 장애 발생 후 복구까지 걸리는 시간 |
| 등급 | Change Failure Rate |
|---|---|
| Elite | 0~15% |
| High | 16~30% |
| Medium/Low | 46~60% |
배포를 자주 하면서 Change Failure Rate가 낮은 팀이 잘하는 팀이다.
롤백 전략
배포했는데 문제가 생기면 빠르게 롤백할 수 있어야 한다.
-
롤백 절차가 미리 정의되어 있어야 한다
-
롤백 시간이 길면 그만큼 장애 시간이 늘어난다
-
DB 스키마 변경은 기존 데이터에 영향을 주고 하위 호환을 깨뜨릴 수 있어서 별도 전략이 필요하다
정리
변경을 줄이는 것이 답이 아니다. 오히려 자주 배포하되 안전하게 하는 것이 목표다. Canary, Blue/Green, Feature Flag로 점진적으로 배포하고, DORA 지표로 수준을 측정하고, 롤백 절차를
미리 준비해두는 것이 Change Management의 핵심이다.
