배포 · 서빙 · 모니터링: 지연 시간 · 카나리 · 드리프트 · LLM 앱 운영

배포 · 서빙 · 모니터링: 지연 시간 · 카나리 · 드리프트 · LLM 앱 운영

모델을 배포하는 순간부터 세상은 학습 데이터와 조금씩 달라집니다. 이 수업은 배포 방식(배치 · 실시간 · 엣지), 서빙 성능을 재는 지연 시간 백분위와 처리량, 안전하게 바꾸는 방법(섀도 · 카나리 · A/B), 그리고 배포 뒤 모델이 낡아 가는 것을 잡아내는 데이터 드리프트(PSI · KS 검정) · 개념 드리프트를 손계산으로 익힙니다. 마지막으로 LLM 앱에서 평가 세트 · 비용 · 품질을 어떻게 지켜보는지 정리합니다.

들어가기 전에

• ML 프로젝트 수명 주기: 데이터 · 실험 관리 · 재현성 — 같은 트랙의 앞 수업. 학습/서빙 불일치와 ML Test Score
• 정보 이론 최소한: 엔트로피 · 교차 엔트로피 · KL 발산 — PSI는 KL 발산을 양방향으로 더한 값입니다.
• 확률과 통계 최소한 — 분포 · 누적 분포 · 백분위

한눈에 보기

• 배치 · 실시간 · 엣지 추론 중 무엇을 고를지 기준을 압니다.
• 평균 지연 시간이 왜 속이는지, p95 · p99를 직접 계산해 봅니다.
• 새 모델을 섀도 → 카나리 → 전체 순서로 안전하게 올리는 방법을 압니다.
• PSI와 KS 통계량을 손으로 계산하고, 경험칙 문턱값의 한계를 압니다.
• 데이터 드리프트와 개념 드리프트를 구분하고 재학습 트리거를 설계합니다.

1. 어떻게 예측을 내보낼까: 배치 · 실시간 · 엣지

직관(해설용 비유). 빵집은 아침에 하루치 빵을 미리 구워 둘 수도 있고(배치), 주문이 들어올 때마다 구울 수도 있고(실시간), 손님 집에 제빵기를 보내 줄 수도 있습니다(엣지).

구글 MLCC의 Production ML 모듈도 정적 · 동적 추론을 이렇게 나누어 비교합니다. 실시간 추론에서는 같은 특징을 학습 때와 똑같이 계산 하는 것이 특히 중요합니다(학습/서빙 불일치).

2. 서빙 성능: 지연 시간 백분위와 처리량

직관. 엘리베이터를 기다리는 시간의 평균이 30초여도, 열 번에 한 번 5분을 기다리면 사람들은 그 5분을 기억합니다. 서비스 품질은 꼬리(tail) 로 결정됩니다.

백분위 지연 시간. 요청 $n$ 개의 지연 시간을 작은 순서로 정렬했을 때 $p$ 백분위는 $\lceil p/100\times n\rceil$ 번째 값입니다(최근접 순위 방식; 도구마다 보간 방식이 조금 다릅니다).

숫자로 해 보기(해설용, 파이썬으로 검산). 요청 20개의 지연 시간(ms)이 다음과 같습니다.

42, 45, 47, 48, 50, 51, 52, 53, 55, 56, 58, 60, 61, 63, 65, 70, 80, 95, 180, 420

• 평균: 82.55 ms
• p50: $\lceil0.5\times20\rceil = 10$ 번째 → 56 ms
• p95: $\lceil0.95\times20\rceil = 19$ 번째 → 180 ms
• p99: $\lceil0.99\times20\rceil = 20$ 번째 → 420 ms

평균 82 ms는 "대부분 빠르다"는 사실도, "20번에 한 번은 0.4초가 걸린다"는 사실도 보여 주지 못합니다. 그래서 서비스 목표는 보통 "p95 < 200 ms"처럼 백분위로 정합니다. (넘파이 기본 선형 보간으로 구하면 p50 = 57, p95 = 192로 조금 다릅니다. 같은 방식으로 꾸준히 재는 것이 중요합니다.)

처리량과 배칭. 처리량은 초당 처리하는 요청(또는 토큰) 수입니다. 요청 여러 개를 한 번에 묶어(배칭) GPU에 넣으면 처리량은 오르지만, 묶음이 찰 때까지 기다리는 만큼 지연 시간이 늘어납니다. LLM 서빙에서는 이 맞바꿈을 줄이려고 PagedAttention(vLLM) 같은 메모리 관리나 추측 디코딩 같은 기법을 씁니다. 모델 자체를 가볍게 하는 양자화는 QLoRA 수업에서 다룹니다.

3. 자동화 수준: MLOps 0 · 1 · 2단계

Google Cloud 문서는 MLOps 성숙도를 세 단계로 설명합니다.

지속 학습(continuous training) 은 ML에만 있는 개념으로, 새 데이터가 들어오면 모델을 자동으로 다시 학습해 서빙하는 것입니다. 문서가 드는 주요 부품은 학습과 서빙에서 같은 특징 정의를 쓰게 하는 특징 저장소, 실행 · 버전 · 지표를 기록하는 메타데이터 저장소, 배포 전 모델을 보관하는 모델 레지스트리 입니다.

4. 안전하게 바꾸기: 섀도 · 카나리 · A/B

Google SRE Workbook은 카나리를 "서비스 변경을 일부에 한정해 시간을 정해 배포하고 평가하는 것"으로 정의하고, 사실상 A/B 시험 과정이라고 설명합니다. 권고 사항으로는 카나리가 전체 배포를 대표할 만큼 충분히 크고 길어야 하며(요청 몇 개로는 신호가 안 됨), 한 번에 카나리 하나만 돌리고, 성능 결함은 부하가 높을 때 드러나는 경우가 많으니 한가한 시간에만 배포하지 말라는 것 등이 있습니다.

숫자로 해 보기(해설용). 하루 20만 요청 중 5%를 카나리로 보내면 1만 요청입니다. 새 모델의 오류율이 대조군 0.5%보다 0.2%p 높다면 카나리에서 하루 약 20건이 추가로 틀립니다. 전체 배포였다면 약 400건입니다. 작게 시작하는 이유입니다.

5. 모니터링: 무엇을 지켜보나

Google MLCC의 Monitoring pipelines 페이지가 권하는 항목을 정리하면 다음과 같습니다.

정답 라벨이 늦게 오는 경우(대출 상환 여부는 1년 뒤에 앎)가 많아, 입력 분포의 변화 를 먼저 보는 것이 드리프트 감시의 출발점입니다.

6. 데이터 드리프트 재기: PSI와 KS 검정

PSI(Population Stability Index). 신용 평가 분야에서 널리 쓰는 지표입니다. 특징 값을 $k$ 개 구간으로 나누고, 기준 시점(학습 때) 비율 $q_j$ 와 현재 비율 $P_j$ 를 비교합니다(du Pisanie 외 2023의 식 2).

이 값은 $\mathrm{KL}(P\|q) + \mathrm{KL}(q\|P)$ 와 같습니다. 즉 KL 발산을 양쪽 방향으로 더한 것입니다.

숫자로 해 보기(해설용, 파이썬으로 검산). 나이 특징을 4구간으로 나눴습니다. 학습 때는 $(0.25, 0.25, 0.25, 0.25)$, 이번 달은 $(0.10, 0.20, 0.30, 0.40)$ 입니다.

• 구간 1: $(0.10-0.25)\ln(0.10/0.25) = (-0.15)(-0.916) \approx 0.137$
• 구간 2: $(-0.05)\ln(0.8) \approx 0.011$
• 구간 3: $(0.05)\ln(1.2) \approx 0.009$
• 구간 4: $(0.15)\ln(1.6) \approx 0.071$
• 합 PSI $\approx 0.228$

이번 달이 $(0.24, 0.26, 0.25, 0.25)$ 로 거의 같다면 PSI는 약 0.0008입니다.

문턱값의 한계. du Pisanie 외가 소개하는 Lewis의 경험칙은 0.1 미만 "실질적 변화 없음", 0.1~0.25 "작은 변화", 0.25 이상 "상당한 변화"입니다. 위 예의 0.228은 '작은 변화' 구간입니다. 하지만 같은 논문과 Yurdakul · Naranjo의 연구는 이 경험칙이 통계적 근거가 약하고, PSI의 기준값이 표본 크기와 구간 수에 따라 달라지므로 근사 임계값을 쓰자고 주장합니다. 또 어느 한쪽에 0인 구간이 있으면 로그가 정의되지 않으니 구간을 합치거나 작은 값을 더해 다룹니다.

KS 검정. 연속 특징이라면 구간을 나누지 않고 두 표본의 경험적 누적 분포 함수(ECDF)의 최대 차이 로 비교할 수 있습니다. SciPy의 ks_2samp 가 이 2표본 콜모고로프-스미르노프 검정을 하며, 귀무가설은 "두 분포가 같다"입니다.

숫자로 해 보기(해설용, 파이썬으로 검산). 기준 표본 $1,2,\dots,8$, 현재 표본 $3,4,\dots,10$. $x=2$ 에서 기준 ECDF는 $2/8=0.25$, 현재는 0이라 차이 0.25이고, 이것이 최대라 $D=0.25$ 입니다. ks_2samp 로 계산한 p값은 약 0.98로, 표본이 8개뿐이라 "다르다"고 말할 증거가 없습니다. 반대로 표본이 수십만 개면 아주 작은 차이도 p값이 작게 나옵니다. 통계적 유의성과 실제 중요성은 다르므로 효과 크기(PSI · $D$ 값 자체)와 함께 봅니다.

7. 개념 드리프트와 재학습 트리거

Google Cloud 문서는 두 가지 변화를 구분합니다.

• 데이터 드리프트: 입력 데이터의 통계적 성질이 크게 바뀜(위의 나이 분포 변화).
• 개념 드리프트: 입력과 출력 사이의 관계 가 바뀜. 같은 입력이라도 정답이 달라졌으므로 모델이 낡았고 새 데이터로 재학습이 필요합니다(예: 새 사기 수법이 나와 예전 패턴이 더는 사기를 뜻하지 않음).

입력 분포만 보면 개념 드리프트를 놓칠 수 있어, 늦게라도 들어오는 정답 라벨로 성능 자체 를 추적해야 합니다. 같은 문서가 드는 재학습 트리거는 ① 요청 시 ② 일정 주기 ③ 새 학습 데이터가 쌓였을 때 ④ 성능이 떨어졌을 때 ⑤ 데이터 분포가 바뀌었을 때입니다.

123456789flowchart LR
  A[학습 파이프라인] --> B[모델 레지스트리]
  B --> C[섀도 배포<br/>사용자 영향 없음]
  C --> D[카나리<br/>트래픽 일부]
  D -->|지표 정상| E[전체 배포]
  D -->|악화| R[롤백]
  E --> F[모니터링<br/>p95 · 오류율 · PSI · KS · 성능]
  F -->|드리프트 · 성능 저하 · 주기| G[재학습 트리거]
  G --> A

8. LLM 앱 운영: 평가 세트 · 비용 · 지연

LLM을 쓰는 앱도 같은 원칙을 따르되 지켜볼 것이 조금 다릅니다(해설용 정리).

• 고정 평가 세트(회귀 시험). 프롬프트 · 모델 · RAG 설정을 바꿀 때마다 대표 질문 수십~수백 개의 답을 같은 기준으로 채점해 이전 버전보다 나빠지지 않았는지 봅니다. 이것이 LLM판 오프라인 평가 · 카나리입니다.
• 비용. 요청 비용 = 입력 토큰 × 입력 단가 + 출력 토큰 × 출력 단가입니다.
• 지연. 첫 토큰까지의 시간과 전체 응답 시간을 따로 잽니다.
• 안전. 프롬프트 인젝션 · 민감 정보 노출 시도를 기록하고 표본을 사람이 검토합니다(→ 프라이버시와 보안).

숫자로 해 보기(해설용, 가상의 단가). 입력 100만 토큰당 3달러, 출력 100만 토큰당 15달러라고 가정하고, 요청 하나가 입력 1,500 · 출력 300 토큰이면 $(1500\times3 + 300\times15)/10^6 = 0.009$ 달러입니다. 하루 1만 요청이면 90달러입니다. 검색 결과를 덜 붙여 입력을 절반으로 줄이면 입력 비용이 절반이 됩니다. 단가는 제공사 · 모델마다 다르므로 실제 값은 공식 가격표로 확인합니다.

연습 문제

1. 지연 시간 10개: 20, 22, 25, 25, 30, 31, 35, 40, 90, 300 ms. 최근접 순위 방식의 p50 · p90은?
   • 풀이: p50은 $\lceil5\rceil = 5$ 번째 30 ms, p90은 $\lceil9\rceil = 9$ 번째 90 ms입니다.
2. 기준 비율 $(0.5, 0.5)$, 현재 $(0.6, 0.4)$ 의 PSI는?
   • 풀이: $0.1\ln1.2 + (-0.1)\ln0.8 = 0.0182 + 0.0223 \approx 0.041$ 입니다.
3. 대출 승인 모델에서 입력 분포는 그대로인데 금리 인상 뒤 연체율이 크게 올랐습니다. 어떤 드리프트인가요?
   • 풀이: 같은 입력에 대한 결과(연체 여부)의 관계가 바뀌었으므로 개념 드리프트입니다. 입력 PSI로는 잡히지 않고 성능 추적이 필요합니다.
4. 하루 50만 요청, 카나리 2%면 카나리 요청 수는?
   • 풀이: 1만 요청입니다.

스스로 점검

1. 평균 지연 시간 대신 p95 · p99를 보는 이유는?
   • 답: 평균은 소수의 매우 느린 요청을 가려 버립니다. 사용자 경험은 꼬리 지연에 크게 좌우되므로 백분위로 목표를 정합니다.
2. 섀도 배포와 카나리의 차이는?
   • 답: 섀도는 새 모델 결과를 사용자에게 보내지 않아 영향이 없고, 카나리는 실제 사용자 일부에게 새 결과를 보내 실제 지표를 비교합니다.
3. PSI 0.1 · 0.25 경험칙을 그대로 믿으면 안 되는 이유는?
   • 답: PSI의 분포가 표본 크기와 구간 수에 따라 달라 고정 문턱값에는 통계적 근거가 약하다는 연구가 있습니다. 표본 크기를 고려한 임계값이나 성능 지표와 함께 판단합니다.

용어 정리

더 깊이 보려면

• Google Cloud, MLOps: Continuous delivery and automation pipelines in ML: docs.cloud.google.com/architecture/mlops-…
• Google MLCC, Monitoring pipelines: developers.google.com/machine-learning/cr…
• Google SRE Workbook, Canarying Releases: sre.google/workbook/canarying-releases
• PagedAttention: LLM 서빙의 메모리 관리 (vLLM)

다음에 볼 것

• 중간 점검: 생성 모델 · 음성 · 그래프 · 시계열 · 해석 가능성 · 안전 · MLOps · 피지컬 AI 15문제 — 응용 트랙 수업들을 15문제로 되짚는 점검
• PagedAttention: LLM 서빙의 메모리 관리 (vLLM) — LLM 서빙 처리량을 끌어올린 핵심 기법
• 추측 디코딩으로 트랜스포머 추론 빠르게 하기 — 지연 시간을 줄이는 디코딩 기법
• 거버넌스와 정책: 사내 AI 사용 지침 · 데이터 분류 · 섀도 AI — 운영 로그 · 감사를 사내 지침과 맞추기(AX)
• 파일럿에서 확산까지: 파일럿 설계 · 성공 기준 · 확산과 운영 — 배포 뒤 조직 전체로 넓히는 단계(AX)

라이선스

본문은 KAITABASE 자체 해설입니다. 각 공식 문서는 개념만 참고했고 문장을 옮기지 않았습니다. 지연 시간 · 비율 · 단가 숫자는 이 수업을 위해 만든 해설용 예이며, 백분위 · PSI · KS 계산은 파이썬(넘파이 · SciPy)으로 검산했습니다.

출처

• Google Cloud Architecture Center, MLOps: Continuous delivery and automation pipelines in machine learning: docs.cloud.google.com/architecture/mlops-…
• Google, Machine Learning Crash Course — Monitoring pipelines: developers.google.com/machine-learning/cr…
• Google SRE Workbook, Canarying Releases: sre.google/workbook/canarying-releases
• du Pisanie · Allison · Budde · Visagie (2023), A critical review of existing and new population stability testing procedures in credit risk scoring: arxiv.org/abs/2303.01227
• Yurdakul (2018), Statistical Properties of Population Stability Index, Western Michigan University: scholarworks.wmich.edu/dissertations/3208
• SciPy, scipy.stats.ks_2samp: docs.scipy.org/doc/scipy/reference/genera…