모델 서빙 (Model Serving)

#개념

모델 서빙(Model Serving)은 학습이 끝난 머신러닝(Machine Learning) 모델을 실제 애플리케이션이 호출할 수 있는 형태로 배포하여 예측(추론) 결과를 제공하는 과정과 그 인프라를 뜻한다. 서빙 방식은 예측이 필요한 시점과 데이터가 도착하는 방식에 따라 크게 세 가지로 나뉜다. 배치 추론(Batch Inference)은 일정 주기(매시간, 매일)마다 전체 대상에 대해 예측을 미리 계산하여 데이터 웨어하우스(Data Warehouse)나 키-값 저장소에 적재해 두고 애플리케이션이 그 결과를 읽어 가는 방식으로, Spark 같은 분산 처리 엔진으로 높은 처리량을 얻을 수 있고 운영이 단순하지만 계산 시점 이후의 입력 변화를 반영하지 못한다. 온라인 추론(Online Inference)은 요청이 올 때마다 모델을 실행하여 수십에서 수백 밀리초 안에 응답하는 방식으로, 검색 랭킹이나 실시간 사기 탐지처럼 요청 시점의 맥락이 중요한 경우에 필수적이며 항상 켜져 있는 서버와 저지연 특징 조회, 확장성이 요구된다. 스트리밍 추론(Streaming Inference)은 Kafka·Flink 같은 스트림 처리 파이프라인에서 이벤트가 도착할 때마다 예측을 수행하여 결과를 다시 스트림이나 저장소로 내보내는 준실시간 방식으로, 사용자가 응답을 기다리지는 않지만 신선도가 중요한 이상 탐지나 알림에 적합하다. 이 밖에 모바일 기기나 브라우저, IoT 장치에 모델을 내장하는 엣지(edge) 서빙은 네트워크 왕복 없이 추론하고 개인정보를 기기 밖으로 내보내지 않는 대신 모델 크기와 연산량에 제약을 받는다. 어떤 방식을 택할지는 허용 가능한 지연 시간(Latency), 예측 대상의 수, 입력의 변동성, 비용을 함께 고려해 결정하며, 실무에서는 배치로 후보를 미리 계산해 두고 온라인에서 재정렬하는 식으로 여러 방식을 조합하는 경우가 많다.

온라인 서빙은 일반적으로 모델을 네트워크 서비스로 감싸는 모델 서버(Model Server) 위에서 이루어진다. 클라이언트와의 통신에는 JSON 기반의 REST API가 널리 쓰이며, 더 낮은 오버헤드가 필요할 때는 HTTP/2와 Protocol Buffers 직렬화를 사용하는 gRPC가 선호된다. 모델 서버는 모델 파일 로딩, 버전 관리, 요청 배칭, 다중 모델 동시 실행, 지표 노출을 표준화한다. Google이 2016년 공개한 TensorFlow Serving은 SavedModel 형식을 gRPC/REST로 서빙하는 초기 대표 사례이고, TorchServe는 PyTorch 모델을 핸들러와 함께 아카이브(.mar)로 패키징하여 서빙한다. NVIDIA Triton Inference Server는 TensorRT·ONNX·PyTorch·TensorFlow·Python 등 여러 백엔드를 하나의 서버에서 실행하며 동적 배칭, 모델 앙상블, GPU 위의 다중 모델 동시 실행을 지원한다. KServe는 Kubernetes 위에서 InferenceService라는 표준 리소스로 다양한 프레임워크의 모델을 배포하고 오토스케일링(0까지 축소 포함), 카나리 롤아웃, 전처리·후처리 트랜스포머를 제공하는 플랫폼이며, Open Inference Protocol(V2)로 서버 간 요청 형식을 표준화했다. 이 밖에 BentoML, Ray Serve, Seldon Core 같은 도구가 파이썬 중심의 패키징과 복합 추론 그래프를 지원한다. 학술적으로는 Crankshaw 등(2017)의 Clipper가 프레임워크에 독립적인 모델 추상화 계층을 두고 적응형 배칭과 캐싱으로 지연 시간 목표를 맞추면서 처리량을 높이는 설계를 제시하여 이후 모델 서버 설계에 영향을 주었다.

서빙 성능은 지연 시간(Latency)과 처리량(Throughput)의 균형으로 요약된다. 지연 시간은 평균보다 p95·p99 같은 꼬리 지연으로 관리해야 하며, 처리량은 초당 처리 요청 수(QPS)나 초당 생성 토큰 수로 측정한다. GPU는 한 번에 많은 입력을 병렬 처리할 때 효율이 높기 때문에, 요청을 하나씩 처리하면 GPU 사용률이 낮고 무작정 모으면 대기 시간이 늘어난다. 동적 배칭(Dynamic Batching)은 개별 요청을 서버 측 큐에서 짧은 시간(예: 수 밀리초의 최대 큐 지연) 동안 모아 하나의 배치로 실행하는 기법으로, Triton의 dynamic batcher처럼 최대 배치 크기와 최대 대기 시간을 설정하여 지연 시간 예산 안에서 처리량을 극대화한다. 모델 자체를 가볍게 만드는 최적화도 병행된다. 양자화(Quantization)는 FP32 가중치와 활성값을 FP16·BF16·INT8·FP8·INT4 같은 저정밀도로 표현하여 메모리와 연산량을 줄이는 기법으로, 학습 후 보정 데이터로 변환하는 사후 양자화(PTQ)와 학습 중 양자화 효과를 반영하는 양자화 인식 학습(QAT)으로 나뉜다. 지식 증류(Knowledge Distillation)는 큰 교사 모델의 출력을 모방하도록 작은 학생 모델을 학습시켜 정확도를 유지한 채 크기를 줄이고, 가지치기(pruning)는 기여도가 낮은 가중치(Weight)나 채널을 제거한다. 컴파일 단계에서는 모델을 프레임워크 중립적인 ONNX 형식으로 내보내 ONNX Runtime으로 실행하거나, NVIDIA TensorRT로 연산자 융합(operator fusion)·커널 자동 튜닝·정밀도 보정을 거친 엔진을 생성하며, torch.compile이나 XLA 같은 그래프 컴파일러도 같은 목적으로 사용된다. 인프라 측면에서는 요청량에 따라 복제본 수를 조절하는 오토스케일링(Autoscaling)이 핵심으로, CPU 사용률 대신 QPS·큐 길이·GPU 사용률을 지표로 삼고, 유휴 시 0으로 줄였다가 요청이 오면 다시 띄우는 scale-to-zero는 비용을 아끼지만 모델 로딩에 걸리는 콜드 스타트 지연을 감수해야 한다. 값비싼 GPU의 활용률을 높이기 위해 한 GPU에 여러 모델을 함께 올리거나, MIG·MPS로 GPU를 분할하고, 모델 크기가 GPU 메모리를 넘으면 텐서 병렬·파이프라인 병렬로 여러 GPU에 나누어 배치한다.

새 모델을 프로덕션에 반영하는 배포 전략은 위험을 통제하는 장치다. 블루-그린 배포(Blue-Green Deployment)는 현재 버전(블루)과 새 버전(그린)을 동시에 띄워 두고 로드 밸런싱(Load Balancing) 계층에서 트래픽을 한 번에 전환하며 문제가 생기면 즉시 되돌린다. 카나리 배포(Canary Deployment)는 전체 트래픽의 일부(예: 5%)만 새 모델로 보내 오류율·지연 시간·비즈니스 지표를 확인한 뒤 비율을 점진적으로 늘리고, 섀도 배포(Shadow Deployment)는 실제 요청을 복제하여 새 모델에도 보내되 응답은 기존 모델의 것만 사용자에게 돌려주므로 사용자 영향 없이 새 모델의 출력과 성능 특성을 관찰할 수 있다. 두 모델을 사용자 그룹별로 나누어 실제 전환율 같은 성과를 비교하는 A/B 테스트는 모델 품질을 최종 판정하는 수단이다. 배포 후 모니터링(Monitoring)은 두 층위로 이루어진다. 시스템 층위에서는 지연 시간 분포, 처리량, 오류율, GPU·메모리 사용률을 Prometheus 같은 도구로 수집하여 SLO 위반 시 경보하고, 모델 층위에서는 입력 특징과 예측 분포를 기록하여 학습 시점과의 데이터 드리프트(Data Drift)를 탐지하며, 지연되어 도착하는 정답 레이블과 예측을 대조해 실제 정확도를 추적한다. 요청과 예측을 로깅해 두면 재학습 데이터가 되고, 피처 스토어(Feature Store)의 온라인 스토어에서 특징을 조회하도록 서빙을 구성하면 학습-서빙 편차도 함께 통제된다. 이러한 배포·모니터링·재학습의 순환이 MLOps의 운영 단계를 이룬다.

대규모 언어 모델(Large Language Models, LLM)의 서빙은 전통적인 모델 서빙과 다른 특성을 갖는다. LLM은 토큰을 하나씩 순차적으로 생성하는 자기회귀(autoregressive) 방식이므로, 한 요청의 처리는 프롬프트 전체를 한 번에 처리하는 프리필(prefill) 단계와 토큰을 하나씩 생성하는 디코드(decode) 단계로 나뉘고, 디코드 단계는 매 스텝마다 전체 가중치를 읽어야 하므로 연산보다 메모리 대역폭에 의해 제한된다. 트랜스포머(Transformer)의 어텐션 메커니즘(Attention Mechanism)은 이전 토큰들의 키·값 벡터를 반복 계산하지 않도록 KV 캐시(KV Cache)에 보관하는데, 이 캐시는 시퀀스 길이에 비례해 커지며 GPU 메모리의 상당 부분을 차지한다. 요청마다 출력 길이가 달라 기존의 정적 배칭으로는 먼저 끝난 요청의 자리가 배치가 끝날 때까지 비게 되는 문제가 있었고, Yu 등(2022)의 Orca는 토큰 생성 스텝 단위로 스케줄링하여 끝난 요청을 즉시 내보내고 새 요청을 끼워 넣는 연속 배칭(Continuous Batching)을 제안해 처리량을 크게 높였다. Kwon 등(2023)의 PagedAttention은 운영체제의 가상 메모리처럼 KV 캐시를 고정 크기 블록으로 나누어 비연속 메모리에 할당함으로써 단편화와 과잉 예약을 없애고 배치 크기를 늘렸으며, 이를 구현한 vLLM은 OpenAI 호환 API, 양자화, 텐서 병렬, 접두사 캐싱(prefix caching)을 갖춘 대표적인 LLM 서빙 엔진이 되었다. LLM 서빙의 지표로는 첫 토큰까지의 시간(TTFT)과 토큰당 생성 시간(TPOT), 초당 생성 토큰 수가 쓰이며, 작은 초안 모델이 여러 토큰을 미리 제안하고 큰 모델이 한 번에 검증하는 추측 디코딩(speculative decoding), 프리필과 디코드를 서로 다른 GPU 풀에서 처리하는 분리 서빙(disaggregated serving), 공통 시스템 프롬프트의 KV 캐시 공유 같은 기법이 지연 시간과 비용을 줄이는 데 사용된다. Hugging Face의 Text Generation Inference, NVIDIA TensorRT-LLM, SGLang 등이 같은 문제를 다루며, KServe와 Triton도 vLLM을 백엔드로 통합하고 있다. 결론적으로 모델 서빙은 모델을 API 뒤에 두는 단순한 작업이 아니라, 지연 시간·처리량·비용 사이의 절충을 배칭·최적화·확장·배포 전략으로 설계하고 모니터링으로 지속 검증하는 엔지니어링 영역이며, LLM 시대에 들어 그 중요성과 기술적 깊이가 한층 커졌다.

#관련 용어

지연 시간

요청이 들어온 시점부터 예측 응답이 반환되기까지 걸리는 시간으로, 온라인 서빙의 핵심 성능 지표

동적 배칭

개별 요청을 서버에서 짧게 모아 하나의 배치로 추론하여 지연 시간 예산 안에서 처리량을 높이는 기법

양자화

모델의 가중치와 활성값을 저정밀도 숫자 형식으로 표현하여 메모리와 연산량을 줄이는 최적화 기법

KV 캐시

LLM이 이전 토큰의 키·값 벡터를 저장해 두어 토큰 생성 시 어텐션 재계산을 피하는 GPU 메모리 캐시

로드 밸런싱

여러 모델 서버 복제본에 요청을 분산하고 배포 시 트래픽을 전환하는 네트워크 계층의 기능

피처 스토어

온라인 추론 시 저지연으로 특징을 조회하고 학습-서빙 편차를 방지하는 특징 저장소

#직무 연관도

Data Analyst희박

배치 예측 결과 테이블을 분석하거나 카나리·A/B 배포의 비즈니스 지표를 비교하는 수준에서 관련된다

Data Scientist보통

모델을 프로덕션에 전달할 때 지연 시간 제약에 맞는 모델 크기와 최적화 방법을 선택하고, 배포 후 성능 지표를 해석하는 데 필요한 개념

Data Engineer밀접

모델 서버 구축, 배칭·양자화·컴파일 최적화, 오토스케일링과 GPU 활용, 배포 전략과 모니터링 등 서빙 인프라 설계·운영의 핵심 영역

#사용 사례

전자상거래금융인터넷 서비스통신미디어자율주행

개요

모델 서빙은 검색·추천 랭킹, 실시간 사기 탐지, 신용 평가, 광고 클릭률 예측, 이미지·음성 인식 API, 챗봇과 생성형 AI 서비스 등 학습된 모델을 실제 사용자 요청에 연결하는 모든 머신러닝 서비스에 활용된다.

사례

전자상거래 검색 랭킹 모델을 KServe 위에 배포하면서 ONNX Runtime으로 변환하고 INT8 양자화를 적용해 p99 지연 시간을 80ms 이하로 낮추고, 동적 배칭으로 GPU 처리량을 높인다. 새 모델은 카나리로 5% 트래픽부터 열어 클릭률과 오류율을 확인한 뒤 전량 전환하며, 야간에는 오토스케일링으로 복제본을 줄여 비용을 절감한다. 같은 조직의 고객 상담 챗봇은 vLLM으로 LLM을 서빙하여 연속 배칭과 PagedAttention으로 동시 사용자 수를 늘린다.