LLM을 위한 섀도 트래픽(Shadow Traffic), 카나리 배포(Canary Rollout), 점진적 배포(Progressive Deployment)

LLM 출시(rollout)는 소프트웨어 배포(deployment)에서 가장 어려운 부분들을 한꺼번에 모아 놓은 것과 같습니다. 단위 테스트(unit test)가 사실상 존재하지 않고, 실패 양상(failure mode)이 한 곳에 모이지 않고 흩어져 있으며(diffuse), 문제를 알려주는 신호(signal)는 늦게 도착합니다. 그래서 일반적으로 다음 세 단계를 순서대로 밟습니다. (1) 섀도 모드(shadow mode) — 운영(production)에 들어오는 요청을 후보 모델(candidate model)에 그대로 복제(duplicate)해 보내고, 출력은 사용자에게 돌려주지 않은 채 로그로만 남겨 운영 모델과 비교(compare)합니다. 사용자 영향은 0이므로 분포(distribution)에 명백한 이상이 생긴 경우는 잡아낼 수 있지만, 품질을 보장(quality guarantee)해 주지는 않습니다. (2) 카나리 배포(canary rollout) — 10% → 25% → 50% → 75% → 100%처럼 트래픽을 점진적으로(progressive) 옮기되, 각 단계마다 통과 기준(gate)을 둡니다. 추적해야 할 지표는 지연 시간 백분위(latency percentile), 요청당 비용(cost/request), 오류·거절률(error/refusal rate), 출력 길이 분포(output length distribution), 사용자 피드백 비율(user-feedback rate)입니다. (3) 카나리에서 안정성(stability)이 확인된 뒤, 서로 명확히 다른 대안(distinct alternative)이 있다면 A/B 테스트(A/B testing)를 합니다. 비결정성(non-determinism)은 제거할 수 없습니다. GPU 부동소수점 연산의 비결합성(GPU FP non-associativity)과 배치 크기 차이(batch-size variance) 때문에, 동일한 입력을 주어도 실행마다 정확도(accuracy)가 최대 15%까지 흔들릴 수 있습니다. 비용은 상수가 아니라 변수입니다. 20% 더 우수한 모델이 호출 한 번당 3배 비쌀 수 있습니다. 롤백(rollback) 속도가 승부를 가릅니다. 만약 롤백에 재배포(redeploy)가 필요하다면 이미 너무 느린 것입니다. 정책(policy)은 설정·플래그(config/flag)에 두고, 모델은 다이제스트(digest)가 고정(pinned)된 레지스트리(registry)에 두어야 합니다. 그러면 롤백은 "정책 전환(policy flip) + 임계값 되돌리기(threshold revert) + 이전 모델 고정(old model pin)"을 몇 초 안에 수행하는 것이 됩니다.

유형: Learn 언어: Python (표준 라이브러리, 간단한 카나리 진행 시뮬레이터 — toy canary-progression simulator) 선수 지식: Phase 17 · 13 (Observability), Phase 17 · 21 (A/B Testing) 예상 시간: 약 60분

학습 목표

• 섀도 모드(shadow mode; 사용자 영향 없는 비교), 카나리(canary; 실 트래픽 점진 노출), A/B(안정성이 확인된 뒤의 비교)를 구분합니다.
• LLM에 특화된 다섯 가지 카나리 지표(지연 시간(latency), 요청당 비용(cost/request), 오류·거절률(error/refusal), 출력 길이 분포(output-length distribution), 사용자 피드백(user feedback))를 나열할 수 있습니다.
• LLM의 비결정성(최대 15%)이 출시 과정에서 "안정(stable)"이라는 단어의 의미를 어떻게 바꾸는지 설명합니다.
• 몇 시간이 아니라 몇 초 만에 완료되는 롤백 경로(정책 플래그 전환)를 설계합니다.

문제

새 모델을 출시합니다. 오프라인 평가(offline eval)는 정확도가 3% 올라간다고 말해 줍니다. 그래서 운영 환경에서 바로 켭니다. 24시간이 지나자 비용이 40% 늘어났고, 사용자의 "부정 피드백(thumbs-down)"이 8% 증가했으며, "이상한 답변(weird answers)"이라는 고객 티켓이 세 건 들어옵니다. 결국 롤백합니다. 그런데 재배포에 3시간이 걸립니다. 그렇게 주말이 망가집니다.

이 과정 하나하나는 모두 피할 수 있었던 일입니다. 섀도 모드를 사용했다면 어떤 사용자도 영향을 받기 전에 40% 비용 폭증(cost spike)을 잡아냈을 것입니다. 카나리 배포를 사용했다면 부정 피드백이 움직이기 시작한 10% 단계에서 진행을 멈출 수 있었을 것입니다. 정책 플래그(policy-flag) 기반의 롤백이었다면 30초 만에 복구가 끝났을 것입니다. 이 일련의 규율(discipline)은 "오프라인 평가는 좋아 보인다"와 "실제 사용자가 만족한다" 사이의 간극을 메우기 위해 존재합니다.

개념

섀도 모드(Shadow mode)

후보 모델은 운영과 동일한 요청을 받습니다. 다만 그 출력은 로그에만 기록되고, 사용자에게는 절대 반환되지 않습니다. 따라서 사용자 영향은 0입니다. 로그로 남기는 항목은 다음과 같습니다.

• 출력 내용(output content) — 운영 모델 출력과의 차이(diff).
• 토큰 수(token counts) — 비용 변화(cost delta).
• 지연 시간(latency).
• 거절(refusal)과 오류(error).

섀도 모드가 잡아낼 수 있는 것: 비용 폭증(cost blow-up), 길이가 크게 길어지거나 짧아지는 회귀(length regression), 명백한 거절 패턴 변화, 강한 오류(hard error). 반대로 잡아내지 못하는 것: 사용자가 실제로 체감하는 품질 차이(quality delta). 섀도는 일종의 스모크 테스트(smoke test)이지 품질 테스트(quality test)가 아닙니다.

카나리 배포(Canary rollout)

카나리는 통과 기준(gate)을 둔 점진적 트래픽 전환입니다. 일반적인 진행 단계는 1% → 10% → 25% → 50% → 75% → 100%입니다. 각 단계에서 다음 다섯 가지 지표로 게이트를 검사합니다.

1. 지연 시간 백분위(Latency percentiles) — P50, P95, P99. 위반 조건: 카나리의 P99가 기준선(baseline)의 1.5배를 넘는 경우.
2. 요청당 비용(Cost per request) — 혼합 단가($, blended). 위반 조건: 기준선 대비 20%를 초과해 비싼 경우.
3. 오류·거절률(Error / refusal rate) — 5xx 오류와 명시적 거절(explicit refusal). 위반 조건: 기준선의 2배.
4. 출력 길이 분포(Output length distribution) — 평균과 P99. 위반 조건: 분포 자체의 이동(distributional shift)이 감지되는 경우.
5. 사용자 피드백 비율(User-feedback rate) — 부정 피드백(thumbs-down) 또는 티켓 접수 비율. 위반 조건: 기준선의 1.5배.

비결정성(Non-determinism)이 새로운 분산입니다

같은 입력을 넣어도 같은 출력이 나오지 않습니다. 이유는 다음과 같습니다.

• GPU 부동소수점 연산의 비결합성(GPU FP non-associativity; 부동소수점 합산 순서가 배치 구성에 따라 달라짐).
• 배치 크기로 인한 변동(batch-size variance; 같은 프롬프트라도 배치 크기 128과 16에서 결과가 다름).
• 샘플링(sampling; 온도(temperature) > 0).

측정 결과, 동일한 평가셋(eval set)에서도 실행 간 정확도 차이가 최대 15%까지 나는 것으로 알려져 있습니다. 따라서 출시 과정에서 "안정"이라는 말은 기준선과 완벽히 동일하다는 뜻이 아니라, 예상 가능한 분산(expected variance) 범위 안에 있다는 뜻입니다. 게이트(gate)는 반드시 이 잡음 바닥(noise floor) 위에 설정해야 합니다.

비용은 변수입니다

20% 더 우수한 모델이 호출 한 번당 3배 비쌀 수 있습니다. 그래서 요청당 비용(cost/request)은 다섯 게이트 중 하나입니다. 사업 단위 경제성(unit economics)을 망가뜨리는 "더 나은" 모델은 그 자체로 롤백 대상(rollback case)입니다.

롤백은 무기입니다

• 정책 플래그(policy flag; 기능 플래그 시스템) — 설정에서 비율(percentage)을 전환(flip)합니다. 몇 초면 끝납니다.
• 모델 고정(model pinning; 레지스트리 다이제스트(registry digest)) — 고정된 모델은 자동으로 업그레이드되지 않습니다.
• 롤백 = 플래그 되돌리기(flag revert) + 고정 다이제스트를 이전 값으로 설정. 몇 시간이 아니라 몇 초입니다.

만약 사용하는 스택이 롤백할 때마다 재배포(redeploy)를 요구한다면, 출시를 시작하기 전에 그 문제부터 먼저 고쳐야 합니다.

도구(Tooling)

Argo Rollouts / Flagger — 쿠버네티스(Kubernetes) 환경의 점진적 배포 컨트롤러(progressive delivery controller)입니다. Istio/Linkerd의 가중 라우팅(weighted routing)과 통합됩니다.

Istio 가중 라우팅(Istio weighted routing) — 서비스 메시(service mesh) 수준의 트래픽 분할(traffic split)입니다.

KServe / Seldon Core — 카나리 기능이 내장된 모델 서빙(model serving) 플랫폼입니다.

기능 플래그(Feature flags) — LaunchDarkly, Flagsmith, Unleash 등이 대표적입니다. 재배포 없이 정책 수준에서 즉시 전환(policy-level flip)할 수 있게 해 줍니다.

지표 측정 주기(Metrics cadence)

카나리 게이트는 트래픽 볼륨에 따라 보통 515분마다 점검합니다. 분당 요청 10건(10 req/min) 환경에서 1% 트래픽이라면 한 윈도우(window)당 50150건 정도의 표본이 모입니다. 지연 시간에는 충분하지만, 사용자 피드백을 평가하기에는 잡음이 큽니다. 10% 트래픽이면 약 10배의 표본이 모입니다. 그래서 각 단계는 충분한 표본이 쌓일 때까지 충분히 머물러 있어야 합니다.

A/B 단계는 선택입니다

새 모델이 동작(behavior), 비용 곡선(cost curve), 톤(tone) 등 여러 면에서 분명히 다른 모델이라면, 카나리를 통과한 뒤 50% 비중에서 A/B 테스트를 진행합니다. 단순히 개선판(improved version)에 해당한다면, 카나리 게이트를 모두 통과했을 때 곧바로 100%로 전환해도 됩니다.

기억해 두면 좋은 숫자

• 카나리 진행 단계: 1% → 10% → 25% → 50% → 75% → 100%.
• 비결정성 상한: 동일 입력에서 실행 간 분산 최대 15%.
• 다섯 가지 카나리 지표: 지연 시간(latency), 비용(cost), 오류·거절(error/refusal), 출력 길이(output length), 사용자 피드백(user feedback).
• 비용 게이트: 기준선 대비 20%를 초과하면 위반(breach).
• 롤백: 몇 시간이 아니라 몇 초.

사용해보기

code/main.py는 의도적으로 회귀(regression)를 주입한 카나리 배포를 시뮬레이션합니다. 어느 단계에서 출시가 멈췄는지, 어떤 게이트가 위반되어 멈췄는지를 보고합니다.

산출물 만들기

이 강의는 outputs/skill-rollout-runbook.md를 만듭니다. 후보 모델(candidate model), 기준선(baseline), 위험 허용도(risk tolerance)가 주어지면, 섀도 → 카나리 → 100%까지 이어지는 출시 계획을 설계해 주는 스킬입니다.

연습문제

1. 쉬움: code/main.py를 실행합니다. 비용 회귀(cost regression)를 25%로 주입(inject)하면, 카나리는 어느 단계에서 멈춥니까?
2. 중간: 새 모델이 오프라인에서 정확도 3% 개선을 보이지만, 요청당 비용은 +18%입니다. 출시(ship)해야 합니까? 정책에 따라 달라집니다. 두 경로(출시하는 경우, 출시하지 않는 경우) 모두를 작성해 보세요.
3. 중간: 전체(end-to-end) 60초 미만으로 끝나는 롤백을 설계합니다. 필요한 인프라(infrastructure)를 모두 나열합니다.
4. 어려움: 평가에서 비결정성이 ±7%로 측정되었습니다. 잘못된 경보(false alarm)가 나지 않도록 카나리 게이트를 설정합니다. 어떤 배수(multiplier)를 사용하시겠습니까?
5. 어려움: 카나리에 들어가기 전 섀도 모드에서 40% 비용 폭증을 잡아냈습니다. 섀도 모드에서 발화할 알림 규칙(alert rule)을 작성합니다.

핵심 용어

더 읽을거리

• TianPan — Releasing AI Features Without Breaking Production — 카나리·섀도·A/B를 LLM 출시 관점에서 한 번에 정리한 글.
• MarkTechPost — Safely Deploying ML Models — A/B, 카나리, 인터리브(interleaved), 섀도 테스트의 차이를 비교한 자료.
• APXML — Advanced LLM Deployment Patterns — 대규모 LLMOps 관점에서의 고급 배포 패턴.
• Argo Rollouts docs — 점진적 배포 컨트롤러의 공식 문서.
• Flagger docs — 메시 기반 카나리 도구의 공식 문서.