[AI] 블루/그린 배포 전략을 AI 모델 업데이트에 적용하는 방법

블루/그린 배포 전략은 웹 애플리케이션 배포에서 익숙한 방식이지만, AI 모델 업데이트에 가져오면 확인해야 할 기준이 조금 달라집니다. 단순히 새 버전이 뜨는지만 보는 것이 아니라, 예측 품질, 응답 형식, 다운스트림 호환성, 롤백 속도까지 함께 봐야 하기 때문입니다. 

블루/그린 배포 전략을 AI 모델 업데이트에 적용할 때 먼저 달라지는 점

블루/그린 배포 전략을 AI 모델 업데이트에 적용할 때는 기존 서비스 배포와 같은 방식으로만 보면 부족합니다. 일반 애플리케이션은 새 버전이 기능적으로 동일하게 동작하는지 확인하는 경우가 많지만, 모델은 같은 입력에도 출력 품질과 응답 분포가 달라질 수 있습니다. 그래서 배포 성공 기준을 서버 정상 기동이 아니라 모델 품질과 서비스 적합성까지 포함해서 정의해야 합니다. 

실무에서는 이 차이를 자주 놓칩니다. 컨테이너는 정상 배포됐고 헬스체크도 통과했는데, 실제로는 분류 경계가 달라지거나 추천 순서가 바뀌어서 운영 결과가 달라지는 경우가 있습니다. 그래서 모델 배포에서는 인프라 관점의 안정성과 모델 관점의 검증을 분리해서 보는 편이 좋습니다. 

 

블루/그린 배포 전략의 핵심은 새 모델을 별도 환경으로 올리고 트래픽 전환을 제어하는 것입니다

블루/그린의 핵심은 운영 중인 기존 환경을 블루, 새 모델이 올라간 환경을 그린으로 분리하고, 실제 사용자 트래픽을 어느 시점에 어떤 비율로 넘길지 통제하는 데 있습니다. Amazon SageMaker는 엔드포인트 업데이트 시 새 플릿을 만들고 기존 플릿을 유지한 채 트래픽을 옮기는 방식을 기본 개념으로 설명하며, 평가 기간이 끝나면 기존 플릿을 종료합니다. 즉, AI 모델 업데이트에서도 본질은 동일하지만, 전환 전에 무엇을 검증할지를 더 엄격하게 잡아야 합니다.

여기서 중요한 점은 블루/그린이 곧바로 100% 스위치만 의미하지는 않는다는 것입니다. 실제 플랫폼들은 전량 전환뿐 아니라 canary, linear 같은 점진 전환도 함께 제공합니다. 새 모델을 별도 환경에 올려 두고 일부만 흘려보낸 뒤 지표를 본 후 확장하는 식입니다. 이런 구조가 있어야 롤백도 단순해집니다. 문제가 생기면 라우팅만 다시 블루로 돌리면 되기 때문입니다. 

 

서비스 배포와 모델 배포를 분리해서 생각해야 하는 이유

모델 업데이트는 보통 세 가지가 한꺼번에 바뀝니다. 모델 아티팩트 자체, 전처리와 후처리 로직, 그리고 응답을 해석하는 서비스 코드입니다. 이 셋이 같이 바뀌면 원인 분리가 어려워집니다. 그래서 배포 단위는 가능한 한 나누는 편이 좋습니다. 모델만 바뀌는지, 피처 전처리까지 바뀌는지, 응답 스키마도 바뀌는지를 먼저 구분해야 합니다.

blue  = model:v1 + preprocessor:v1 + response-schema:v1
green = model:v2 + preprocessor:v1 + response-schema:v1

좋은 첫 배포:
- 모델만 교체
- 입력/출력 계약은 유지
- 성능과 품질 차이만 비교

위험한 첫 배포:
- 모델 교체
- 전처리 변경
- 응답 필드 구조 변경
- 클라이언트 해석 로직까지 동시 변경

AI 모델 업데이트에서 블루/그린 설계를 할 때 꼭 정해야 할 4가지

1. 라우팅 기준

트래픽을 어떻게 나눌지부터 정해야 합니다. 전체 요청 중 일부 비율을 새 모델에 보내는 방식이 가장 일반적이지만, 사용자 그룹별로 나누거나 특정 국가, 특정 모델 버전 헤더 기준으로 나누는 방식도 많이 씁니다. 추천이나 검색처럼 사용자 경험의 일관성이 중요한 경우에는 사용자 해시 기준 고정 라우팅이 더 낫습니다. 같은 사용자가 요청할 때마다 모델이 바뀌면 비교 자체가 흐려질 수 있기 때문입니다. 

2. 성공 기준

모델 배포에서 성공 기준은 CPU나 메모리보다 먼저 예측 품질과 계약 호환성입니다. 예를 들어 분류 모델이면 정확도, 정밀도, 재현율 같은 지표를 볼 수 있고, 생성형 모델이면 응답 길이, 금칙어 비율, 구조화 출력 파싱 성공률, 사용자 피드백 등을 별도로 봐야 합니다. 오프라인 평가가 좋아도 실제 환경과 차이가 날 수 있어서, 온라인 평가 결과를 다시 오프라인 평가 기준에 반영하라는 가이드는 충분히 참고할 만합니다. 

3. 롤백 조건

배포 전에 롤백 조건을 숫자로 적어 두는 것이 좋습니다. 예를 들어 파싱 실패율이 일정 기준을 넘거나, 특정 비즈니스 이벤트 전환율이 기준 이하로 떨어지면 즉시 블루로 복귀하는 식입니다. SageMaker 문서도 블루/그린 배포에서 CloudWatch 알람을 통한 자동 롤백 가드레일을 강조합니다. 실무에서는 이 부분을 늦게 넣으면 사람이 수동으로 판단하다가 전환 시점을 놓치기 쉽습니다. 

4. 상태 보존 방식

모델 서버가 상태를 갖지 않는다면 블루/그린이 비교적 단순합니다. 하지만 세션 캐시, 피처 캐시, 사용자 개인화 상태가 걸려 있으면 이야기가 달라집니다. 예를 들어 모델 응답이 다음 요청에 영향을 주는 구조라면, 블루와 그린이 서로 다른 상태를 참조해 결과가 흔들릴 수 있습니다. 이런 경우에는 모델 추론 경로와 상태 저장 경로를 분리하거나, 최소한 동일한 피처 스냅샷을 참조하게 맞춰야 비교가 가능합니다. 이 부분은 겉보기보다 중요합니다.

블루/그린 배포 전에 Shadow 배포를 먼저 두면 더 안정적으로 볼 수 있습니다

새 모델을 곧바로 사용자 응답에 쓰기 부담스럽다면 shadow 배포를 먼저 두는 방법이 좋습니다. shadow 배포는 실제 요청을 새 모델에도 복제해서 보내되, 사용자에게는 기존 블루 결과만 응답하는 방식입니다. 새 모델은 실트래픽을 받지만 실제 서비스 응답에는 관여하지 않기 때문에, 품질과 성능을 먼저 관찰하기에 적합합니다. SageMaker도 shadow variant를 통해 새 후보 구성을 실요청으로 검증할 수 있다고 설명합니다. 

개인적으로는 모델 업데이트를 세 단계로 보는 편이 낫다고 생각합니다. shadow로 관찰하고, 그다음 소량 canary로 실제 응답에 사용해 보고, 마지막에 블루/그린 전환을 완료하는 흐름입니다. 이름만 보면 블루/그린 하나로 끝낼 수 있을 것 같지만, 모델은 출력 품질 검증이 필요해서 이런 중간 단계를 두는 편이 훨씬 관리하기 쉽습니다. 

1) Shadow
- 요청 복제
- 사용자 응답은 기존 모델만 사용
- 품질 로그 수집

2) Canary
- 1% ~ 5% 실제 사용자 응답에 새 모델 반영
- 핵심 지표 확인

3) Blue/Green 완료
- 그린 100% 전환
- 베이킹 기간 운영
- 블루 종료

실무에서 많이 쓰는 AI 모델 블루/그린 배포 흐름

구조는 복잡하게 보일 수 있지만 흐름은 생각보다 단순하게 정리할 수 있습니다. 모델 레지스트리에서 승격된 아티팩트를 가져오고, 그린 환경에 배포한 뒤, 고정된 검증 세트와 shadow 로그를 비교합니다. 그 다음 일부 트래픽만 열고 지표를 본 뒤 최종 스위치를 수행합니다. Kubernetes에서는 Deployment와 Service 조합으로 이런 패턴을 구성할 수 있고, 관리형 추론 플랫폼에서는 트래픽 시프팅 기능으로 같은 목적을 달성할 수 있습니다.

Model Registry
   ↓
Deploy Green Endpoint
   ↓
Offline Validation
   - 기준 데이터셋 재평가
   - 응답 스키마 검사
   - 안전성 규칙 검사
   ↓
Shadow Validation
   - 실요청 복제
   - 블루 결과와 비교
   ↓
Canary Release
   - 5% → 20% → 50%
   ↓
Blue/Green Switch
   ↓
Baking Period
   ↓
Blue 종료

TypeScript 기준으로 보면 라우터 계층이 핵심입니다

사용자께서 TypeScript 기준 설명을 선호하시는 점을 고려하면, 실제 구현은 추론 서버보다 라우팅 계층이 더 중요합니다. 모델 버전을 직접 애플리케이션 코드에 하드코딩하기보다, 라우터가 활성 모델과 실험 비율을 읽어서 분기하도록 만드는 편이 관리가 쉽습니다. 그래야 긴급 전환도 배포 없이 제어할 수 있습니다.

type ModelTarget = 'blue' | 'green';

interface RoutingPolicy {
  greenRatio: number;       // 0.0 ~ 1.0
  stickyByUser: boolean;
  forceTarget?: ModelTarget;
}

function chooseTarget(userId: string, policy: RoutingPolicy): ModelTarget {
  if (policy.forceTarget) return policy.forceTarget;

  if (policy.stickyByUser) {
    const bucket = hash(userId) % 100;
    return bucket < policy.greenRatio * 100 ? 'green' : 'blue';
  }

  return Math.random() < policy.greenRatio ? 'green' : 'blue';
}

이 정도만 있어도 운영 방식이 많이 단순해집니다. 모델 서버는 추론만 담당하고, 전환 책임은 라우팅 정책이 갖는 구조가 되기 때문입니다. 협업할 때도 데이터 사이언스 팀은 모델 승격 기준에 집중하고, 백엔드 팀은 라우팅과 롤백 자동화에 집중하기 쉬워집니다.

 

AI 모델 업데이트에서 자주 놓치는 포인트

응답 품질만 보고 계약 변경을 놓치는 경우

모델 품질이 좋아졌더라도 응답 스키마가 달라지면 서비스는 쉽게 깨집니다. 특히 생성형 모델에서 JSON 모드나 함수 호출 결과를 쓰는 경우, 필드 이름 하나만 달라져도 장애처럼 보일 수 있습니다. 모델 평가와 별도로 계약 테스트를 두는 이유가 여기에 있습니다.

오프라인 점수만 믿고 전환하는 경우

문서에서도 온라인 평가와 오프라인 평가 차이를 계속 경고합니다. 오프라인 데이터셋은 통제되어 있지만 실제 요청은 훨씬 지저분합니다. 입력 분포가 다르고, 사용자의 행동 피드백도 다르게 나타납니다. 그래서 오프라인에서 좋아 보였던 모델이 실제 서비스에서는 기대만큼 좋지 않은 경우가 생깁니다.

A/B 테스트와 블루/그린을 같은 의미로 쓰는 경우

둘은 닮아 보이지만 목적이 다릅니다. 블루/그린은 안전한 전환과 빠른 롤백에 더 가깝고, A/B 테스트는 어느 모델이 더 나은지 비교하는 실험에 가깝습니다. AWS Well-Architected와 SageMaker 문서도 A/B 테스트는 실트래픽으로 모델 성능을 비교하는 최종 검증 단계로 설명합니다. 새 모델이 확실히 더 좋은지 판단해야 한다면 A/B가 맞고, 이미 승격 결론이 났고 안전하게 바꾸는 것이 목적이면 블루/그린이 더 맞습니다.

어떤 상황에서 블루/그린이 특히 잘 맞는가

응답 계약은 유지되지만 모델 내부만 바뀌는 경우에 특히 잘 맞습니다. 예를 들어 추천 모델 재학습 버전 교체, 랭킹 모델 업데이트, 분류기 개선처럼 인터페이스는 그대로인데 품질이 달라지는 경우입니다. 이럴 때는 기존 블루와 새 그린을 나란히 두고 품질과 서비스 지표를 비교한 뒤 전환하면 됩니다.

반대로 피처 스키마가 크게 바뀌거나, 모델 결과를 해석하는 다운스트림 로직이 함께 변경되거나, 사용자별 장기 상태를 강하게 참조하는 시스템이라면 단순 블루/그린만으로는 부족할 수 있습니다. 그럴 때는 데이터 파이프라인 버전, 피처 스토어 버전, 서빙 계약 버전까지 묶어서 설계해야 합니다. 이런 상황에서는 블루/그린이 아니라 전체 서빙 스택의 버전 전환 문제로 보는 편이 더 정확합니다. 

 

블루/그린 배포 전략을 AI 모델 업데이트에 적용할 때의 정리

블루/그린 배포 전략을 AI 모델 업데이트에 적용하는 핵심은 새 모델을 안전하게 올리는 것이 아니라, 새 모델을 기존 서비스 맥락 안에서 검증 가능한 형태로 올리는 데 있습니다. 그래서 배포 설계의 중심은 컨테이너 교체가 아니라 라우팅, 검증 지표, 자동 롤백, 계약 호환성에 있어야 합니다.

먼저 shadow로 실제 요청을 관찰하고, 다음에 canary로 제한된 실제 응답을 검증하고, 마지막에 블루/그린 전환을 완료합니다. 그리고 전환 성공 기준은 서버 정상 기동이 아니라 모델 품질과 서비스 적합성까지 포함해서 잡아야 합니다. 이 기준만 분명하면 모델 업데이트도 일반 서비스 배포처럼 예측 가능한 작업으로 가져갈 수 있습니다.