---
type: knowledge
domain: infra
status: active
last-reviewed: 2026-07-07
---

# 배포 전략 실전

> 한 줄 정의
> 배포의 목표는 "빨리 내보내기"가 아니라 **"문제가 생겼을 때 그 문제를 작게 만들기"**다. 실행 형태·CI 최소선은 [[인프라 원리]] — 여기는 내보내는 방법의 선택과 순서를 다룬다.

## 배포 전략 선택표

| 전략 | 방식 | 맞는 경우 | 비용 |
|------|------|----------|------|
| 재생성 (내렸다 올림) | 구버전 종료 → 신버전 시작 | 내부 도구, 다운타임 허용 | 다운타임 |
| 롤링 (기본값) | 인스턴스를 순차 교체 | 대부분의 서비스 | 신구 버전 동시 존재 구간 |
| 블루-그린 | 신버전 전체를 옆에 세우고 트래픽 스위치 | 즉시 롤백이 중요한 서비스 | 인프라 2배 (전환 동안) |
| 카나리 | 일부 트래픽(수 %)만 신버전으로 | 리스크 큰 변경, 대규모 사용자 | 관측 체계 필수 — 지표 없이 카나리는 무의미 |

공통 전제: 롤링·블루그린·카나리 전부 **신구 버전이 동시에 살아 있는 구간**이 생긴다. API·DB·캐시가 두 버전 모두와 호환돼야 한다 — 이것이 아래 expand-contract의 이유다.

## 배포 ≠ 릴리즈 — 피처 플래그

코드를 내보내는 것(배포)과 사용자에게 켜는 것(릴리즈)을 분리하면:

- 가장 싼 카나리: 플래그를 내부 직원 → 1% → 전체로 단계 개방.
- 가장 빠른 롤백: 재배포 없이 플래그 OFF.
- 대가: 플래그는 부채다 — 만들 때 **제거 예정일**을 함께 정하고, 전면 개방 후 코드에서 지운다. 3년 묵은 플래그 수십 개는 분기 지옥이다.

## DB 마이그레이션 — expand-contract

파괴적 변경(컬럼 삭제·이름 변경·타입 변경)을 배포와 한 방에 하면 롤백이 불가능해진다. 항상 3단계로 쪼갠다:

1. **Expand**: 새 컬럼/테이블 추가 (구버전도 무해)
2. **Migrate**: 양쪽에 쓰거나 백필, 신버전 배포·검증 (이 상태로 롤백 가능)
3. **Contract**: 신버전 안정 확인 후 구 컬럼 제거 (별도 배포로)

> [!WARNING] 롤백 가능성 불변식
> "이 배포를 5분 안에 되돌릴 수 있는가"에 No라면 배포 설계가 틀린 것이다. 비가역 마이그레이션과 코드 배포를 한 커밋에 묶는 것이 대표 위반.

## 롤백 우선 원칙

- 배포 직후 이상 신호 → **원인 분석보다 롤백이 먼저**다. 진단은 복구된 후에 한다 → [[장애 대응 실전]].
- 롤백은 배포만큼 쉬워야 하고, 첫 프로덕션 배포 전에 1회 연습한다 ([[인프라 원리]] 재확인).
- "fix-forward(고쳐서 재배포)"는 원인을 정확히 알 때만 — 추측 수정 재배포는 장애를 연장한다.

## 배포 타이밍 — 미신이 아니라 인력 문제

- 금요일 오후·퇴근 직전·연휴 전 배포 회피는 미신이 아니다 — 문제 발생 시 **대응할 사람이 있는 시간**에 배포한다는 원칙이다.
- 배포 직후 10분은 지표(에러율·지연 p95)를 사람이 본다 — 배포하고 자리 뜨지 않는다.

## AI 시스템 특수사항

- **프롬프트 변경도 배포다** — 코드와 동일하게 버전 관리·리뷰·롤백 대상. "프롬프트만 살짝"이 회귀의 단골 원인.
- 배포 게이트에 평가(eval) 회귀 추가 — eval 실패 시 배포 차단 (londonSystemAgent 검증 → [[검증된패턴-인덱스]]).
- 모델 버전 교체는 카나리 대상이다 — 같은 프롬프트도 모델이 바뀌면 다른 시스템이다.

## 사람 게이트

프로덕션 배포 승인은 항상 사람이 한다 — 파이프라인·에이전트·자동화가 최종 버튼을 누르지 않는다. → [[S-skills-하네스-패턴]]

## 관련 문서

- [[인프라 원리]] — CI/CD 최소선·실행 형태
- [[장애 대응 실전]] — 배포가 사고가 됐을 때
- [[SQL 성능과 인덱스 실전]] — 운영 중 ALTER 주의
- [[배포-운영-체크리스트]] — 배포 전 점검 실행