모델 배포 고려사항 (Model Deployment Considerations)

핵심 요약: 학습된 모델을 실제 서비스에 올리는 과정이다. 개발 환경의 정확도가 높아도 레이턴시(지연시간)와 처리량(throughput)을 충족하지 못하면 쓸모없다. “충분히 좋은 모델을 빠르게 서빙”이 “완벽한 모델을 느리게 서빙”보다 항상 낫다.

초보자를 위한 핵심 용어

레이턴시(Latency): 요청 하나를 처리하는 데 걸리는 시간. 검색 서비스는 보통 100ms 이내를 요구한다.
처리량(Throughput): 단위 시간당 처리할 수 있는 요청 수. 초당 1,000건 처리 = 1,000 QPS.
양자화(Quantization): 모델의 가중치를 32비트에서 8비트로 줄여 크기와 속도를 개선하는 기법. 정확도 손실은 미미하다.
Training-Serving Skew: 학습 시와 서빙 시의 데이터 전처리가 달라 성능이 떨어지는 현상. 가장 흔한 배포 실패 원인.

개요

모델 배포(Model Deployment)는 학습된 모델을 실제 서비스 환경에서 동작하게 만드는 과정이다. 개발 환경에서 뛰어난 성능을 보이는 모델이 프로덕션에서 실패하는 경우가 많으며, 이는 지연시간(latency), 처리량(throughput), 모델 크기, 서빙 인프라, 모니터링 등을 충분히 고려하지 않기 때문이다.

비유: Training-Serving Skew는 “한국어로 훈련받고 영어로 시험보는 것”과 같다. 학습 환경에서 아무리 뛰어난 성적을 받아도, 시험 환경이 다르면 실력을 발휘할 수 없다. 모델도 마찬가지로, 학습 시의 데이터 전처리와 서빙 시의 전처리가 다르면 성능이 급락한다.

탄생 배경

모델 배포가 독립적인 엔지니어링 분야로 자리 잡기까지, 업계는 학술 연구와 프로덕션 사이의 거대한 간극을 뼈저리게 경험해야 했다.

“모델은 완성됐는데, 배포를 못 한다”:

2010년대 초: 대부분의 ML 팀에서 모델 학습은 데이터 과학자가, 배포는 소프트웨어 엔지니어가 담당했다. 데이터 과학자가 Python/pandas로 만든 전처리 로직을 소프트웨어 엔지니어가 Java/C++로 재구현하는 과정에서 미묘한 차이가 발생했고, 이는 곧 Training-Serving Skew로 이어졌다.
VentureBeat (2019) 보고: “기업에서 개발된 ML 모델의 87%가 프로덕션에 도달하지 못한다”는 충격적인 통계가 발표되었다. 모델의 정확도만으로는 프로덕션 준비가 완료된 것이 아니라는 인식이 확산되었다.
MLOps 문화의 탄생: DevOps가 개발과 운영의 간극을 해소했듯이, MLOps는 모델 개발과 배포/운영의 간극을 해소하기 위해 등장했다. Google의 TFX (2017), Uber의 Michelangelo (2017), Facebook의 FBLearner Flow 등이 초기 MLOps 플랫폼의 선구자 역할을 했다.

이 과정에서 모델 압축(Compression), 서빙 최적화(Serving Optimization), 배포 전략(Deployment Strategy) 등이 체계적인 엔지니어링 분야로 발전했으며, “모델을 만드는 것”과 “모델을 서비스하는 것”은 완전히 다른 역량이라는 인식이 자리 잡았다.

핵심 개념

1. 지연시간과 처리량

지표	정의	중요한 서비스
Latency	단일 요청 처리 시간	실시간 서비스 (검색, 추천)
Throughput	단위 시간당 처리 요청 수	배치 처리, 대량 분석

Batching: 여러 요청을 묶어 GPU 활용도를 극대화한다. 지연시간과 처리량 간 trade-off가 존재한다.

처리량(Throughput)과 지연시간(Latency)의 정량적 정의는 다음과 같다:

$\text{Throughput} = \frac{N_{\text{requests}}}{T_{\text{window}}} \quad (\text{requests/sec})$

$\text{Latency}_{P99} \leq T_{\text{SLA}}$

$N_{\text{requests}}$ : 시간 윈도우 내 처리된 요청 수
$T_{\text{window}}$ : 관측 시간 (초)
$P99$ : 99번째 백분위수 지연시간
$T_{\text{SLA}}$ : SLA에서 정의한 최대 허용 지연시간

배치 크기 $B$ 에 따른 trade-off를 정량적으로 표현하면:

$\text{Latency}(B) \approx t_{\text{wait}}(B) + t_{\text{compute}}(B)$

$\text{Throughput}(B) = \frac{B}{t_{\text{compute}}(B)}$

$t_{\text{wait}}(B)$ 는 배치를 채우기 위한 대기 시간으로 $B$ 가 커질수록 증가하고, $t_{\text{compute}}(B)$ 는 GPU 병렬 처리로 인해 $B$ 에 대해 sub-linear하게 증가한다. 따라서 배치 크기가 커지면 처리량은 증가하지만 지연시간도 증가한다.

2. 모델 압축 (Model Compression)

Pruning (가지치기)

유형	방법	실질적 속도 향상
Unstructured	개별 가중치(값이 작은 것) 제거	어려움 (sparse 연산 필요)
Structured	전체 필터/채널/층 제거	가능 (표준 연산 유지)

Quantization (양자화)

$W_{int8} = \text{round}\left(\frac{W_{fp32}}{s}\right) + z$

방법	시점	정밀도	속도 향상
Post-Training (PTQ)	학습 후	약간 감소	2~4배
Quantization-Aware (QAT)	학습 중 시뮬레이션	거의 유지	2~4배

LLM 양자화: GPTQ, AWQ, GGUF 포맷 등이 LLM에 특화된 양자화를 제공한다.

Knowledge Distillation (지식 증류)

큰 모델(teacher)의 지식을 작은 모델(student)로 전달한다.

$L = \alpha L_{hard} + (1-\alpha) T^2 L_{soft}$

$L_{hard}$ : 정답 라벨과의 손실
$L_{soft}$ : teacher의 soft label과의 손실
$T$ : temperature (높을수록 부드러운 분포)

직관: Teacher의 “어두운 지식(dark knowledge)” — 예를 들어 “이 이미지는 고양이지만, 약간 개와 비슷하다”는 정보가 student에게 전달된다.

3. 서빙 프레임워크

프레임워크	특징	사용처
TorchServe	PyTorch 네이티브	일반 모델 서빙
TF Serving	TensorFlow 네이티브, gRPC	대규모 서비스
ONNX Runtime	프레임워크 호환	프레임워크 전환
TensorRT	NVIDIA GPU 최적화	최대 성능 추론
vLLM	PagedAttention, continuous batching	LLM 서빙
Triton Inference Server	멀티 모델, 멀티 프레임워크	복잡한 파이프라인

4. Edge Deployment (엣지 배포)

모바일, 임베디드 기기에서의 추론이다.

런타임	플랫폼
TFLite	Android, 임베디드
Core ML	iOS, macOS
ONNX Runtime Mobile	크로스 플랫폼

경량 모델: MobileNet, EfficientNet-Lite, SqueezeNet

엣지 배포 시 모델 크기(Model Size)와 추론 비용(FLOPs) 제약을 정량적으로 고려해야 한다:

$\text{Model Size (bytes)} = N_{\text{params}} \times B_{\text{precision}}$

$N_{\text{params}}$ : 전체 파라미터 수
$B_{\text{precision}}$ : 파라미터당 바이트 수 (FP32 = 4, FP16 = 2, INT8 = 1)

예를 들어 MobileNetV2( $N_{\text{params}} \approx 3.4 \times 10^6$ )의 INT8 양자화 모델 크기는 약 $3.4 \times 10^6 \times 1 = 3.4\text{MB}$ 이다.

5. 배포 전략

상세 내용

배포 아키텍처

배포 아키텍처 다이어그램

Training-Serving Skew

학습 시와 배포 시의 데이터 전처리가 불일치하는 문제이다.

원인:

학습: Python/pandas 전처리 → 서빙: Java/C++ 전처리
학습/서빙에서 다른 라이브러리 버전
특성 변환 로직의 미묘한 차이

해결: 전처리 파이프라인을 모델과 함께 직렬화하거나, Feature Store를 사용하여 online/offline 일관성을 보장한다.

언제 사용하는가

상황	핵심 고려사항
실시간 서비스	지연시간 최소화, 양자화/pruning
배치 처리	처리량 최대화, batching
모바일/엣지	모델 크기, 경량화
LLM 서빙	KV-Cache, continuous batching, 양자화
A/B Testing 필요	인프라 구축, 통계적 유의성

실전 사례

단계	기법	레이턴시 변화	정확도 변화
원본	PyTorch 모델 (FP32)	500ms	NDCG@10 = 0.42
1단계	ONNX Runtime 변환	500ms → 200ms	동일
2단계	INT8 양자화 (Post-Training)	200ms → 80ms	0.42 → 0.41
3단계	모델 Pruning (Structured, 30%)	80ms → 55ms	0.41 → 0.40
4단계	결과 캐싱 (인기 상품 Top-1000)	55ms → 50ms (평균)	동일

흔한 오해와 함정

“학습 정확도가 높으면 배포해도 된다”: 프로덕션에서는 지연시간, 처리량, 메모리, 데이터 drift 등을 모두 고려해야 한다.
Training-Serving Skew 무시: 학습과 서빙의 전처리 차이로 모델 성능이 현저히 다를 수 있다.
모니터링 없이 배포: 모델 성능은 시간이 지남에 따라 저하된다 (data/concept drift). 모니터링이 필수적이다.
롤백 계획 없음: 새 모델이 문제를 일으킬 때 즉시 이전 버전으로 돌아갈 수 있어야 한다.
양자화 후 성능 검증 생략: 양자화가 특정 입력 분포에서 성능을 크게 저하시킬 수 있다. 배포 전 충분한 테스트가 필요하다.

다른 주제와의 연결

ML 파이프라인 설계: 배포는 파이프라인의 마지막 단계
실험 추적: Model Registry로 배포 관리
ML 시스템 설계 패턴: A/B Testing, Feature Store
MLOps 기초: CI/CD, 모니터링
전이 학습: PEFT 모델의 효율적 배포
LLM: LLM 추론 최적화