책에 포함된 노트AI 교육 7권 : 재현 가능한 AI 시스템 운영: 데이터 엔지니어링·MLOps·LLM 운영 실무

모델 서빙

2026-05-20Views 24약 8분생성형 AI 활용

Summary

이 장에서 배울 것

이 장에서는 학습이 끝난 모델을 실제 사용자가 호출할 수 있는 서비스로 만드는 방법을 배운다. 모델 파일을 저장소에 올리는 것과 사용자가 안정적으로 예측 결과를 받는 것은 전혀 다른 문제다.

이번 장의 목표는 다음과 같다.

온라인, 배치, 스트리밍 서빙의 차이를 이해한다.
REST API와 gRPC 기반 실시간 추론 서비스를 설계한다.
지연 시간, 처리량, 동시성, 오토스케일링을 운영 지표로 바라본다.
FastAPI, MLflow Models, BentoML, TorchServe 같은 선택지를 비교한다.
카나리 배포, 섀도우 배포, A/B 테스트로 새 모델을 안전하게 검증한다.
LLM 서빙에서 토큰 지연 시간, 프롬프트 버전, 캐싱, 비용 폭증을 고려한다.

모델 서빙

왜 이 주제가 중요한가

6장에서 CI/CD/CT를 통해 배포 후보 모델을 만들었다. 하지만 후보 모델이 승인되었다고 해서 곧바로 운영 가치가 생기는 것은 아니다. 사용자의 요청이 들어오고, 필요한 피처를 조회하고, 모델이 추론을 수행하고, 결과를 정해진 시간 안에 반환해야 비로소 서비스가 된다.

운영에서 자주 발생하는 문제는 모델 정확도보다 주변 시스템에서 나온다. 예를 들어 추천 모델 자체는 빠르지만 사용자 프로필을 조회하는 데이터베이스가 느리면 전체 응답은 느려진다. 이미지 모델은 정확하지만 첫 요청 때 모델을 메모리에 올리느라 10초가 걸리면 사용자는 실패로 느낀다. LLM 서비스는 답변 품질이 좋아도 토큰 생성이 느리거나 사용량이 폭증하면 비용 장애가 된다.

따라서 모델 서빙은 "모델을 실행하는 코드"가 아니라 "예측을 안정적으로 제공하는 운영 시스템"으로 봐야 한다. Azure Machine Learning도 엔드포인트를 안정적인 호출 URL과 인증, 배포, 라우팅을 포함한 운영 단위로 설명한다.¹

핵심 개념 설명

온라인 서빙: 요청이 오면 바로 예측한다

온라인 서빙은 사용자의 요청에 즉시 응답하는 방식이다. 보통 다음 흐름을 따른다.

클라이언트가 API Gateway 또는 모델 서버에 요청을 보낸다.
서버가 입력 스키마를 검증한다.
필요한 피처를 피처 스토어, 캐시, 데이터베이스에서 조회한다.
모델이 추론을 수행한다.
후처리와 비즈니스 규칙을 적용한 뒤 응답한다.

외부 서비스와 쉽게 연결하려면 REST API가 편하다. REST는 HTTP와 JSON을 주로 사용하므로 웹 개발자가 이해하기 쉽다. 반면 내부 서비스 간 고성능 통신이 필요하면 gRPC를 고려할 수 있다. gRPC는 프로토콜 버퍼라는 이진 형식을 사용해 직렬화 비용과 네트워크 비용을 줄일 수 있지만, 스키마 관리와 클라이언트 생성 과정이 더 복잡하다.

온라인 서빙에서 반드시 봐야 할 지표는 네 가지다.

지연 시간(latency): 요청 후 응답까지 걸린 시간이다.
처리량(throughput): 초당 처리 가능한 요청 수다.
동시성(concurrency): 동시에 처리 중인 요청 수다.
오류율(error rate): 실패한 요청의 비율이다.

여기서 중요한 점은 모델 추론 시간만 재면 안 된다는 것이다. 전체 지연 시간은 네트워크, 입력 검증, 피처 조회, 모델 추론, 후처리, 응답 직렬화를 모두 포함한다. 운영에서는 보통 평균보다 p95, p99 지연 시간을 더 중요하게 본다. p99가 2초라면 100명 중 1명은 2초 이상 기다린다는 뜻이다.

오토스케일링은 요청량이 늘 때 서버 인스턴스를 자동으로 늘리는 방식이다. 하지만 모델 서버는 일반 웹 서버보다 스케일링이 어렵다. 모델 파일이 크면 새 인스턴스가 준비되는 데 오래 걸린다. GPU를 쓰면 노드 확보가 늦어질 수 있다. 그래서 운영 환경에서는 최소 인스턴스를 유지하거나, 모델을 미리 로드하는 warm-up 요청을 보내거나, 트래픽 급증 시간 전에 용량을 미리 늘린다.

배치 추론과 스트리밍 추론

모든 예측이 실시간일 필요는 없다. 예측 결과가 몇 분 또는 몇 시간 늦어도 된다면 배치 추론이 더 단순하고 저렴하다. Google Cloud는 일괄 추론을 즉시 응답이 필요하지 않은 대량 데이터 예측 방식으로 설명하며, 높은 처리량과 비용 효율성을 장점으로 든다.²

배치 추론의 전형적인 흐름은 다음과 같다.

데이터 웨어하우스나 데이터 레이크에 입력 데이터를 모은다.
Airflow, Cron, 관리형 파이프라인이 정해진 시간에 작업을 실행한다.
모델을 로드하고 대량 예측을 수행한다.
결과를 테이블, 파일, 캐시 저장소에 저장한다.
애플리케이션이나 BI 도구가 저장된 예측을 조회한다.

예를 들어 이탈 가능 고객 목록, 일일 상품 추천 후보, 월간 신용 위험 점수는 배치가 잘 맞는다. 반대로 결제 사기 탐지, 실시간 광고 입찰, 대화형 챗봇은 온라인 또는 스트리밍이 필요하다.

스트리밍 추론은 배치와 온라인의 중간에 있다. Kafka, Pub/Sub 같은 메시지 시스템에 이벤트가 들어오면 소비자가 연속적으로 읽고 예측한다. 응답을 사용자의 웹 요청에 즉시 돌려주기보다, 알림 시스템이나 후속 파이프라인으로 보낸다. 초 단위 신선도가 필요하고 이벤트량이 많다면 스트리밍이 적합하다.

선택 기준은 단순하다.

기준	온라인	배치	스트리밍
응답 신선도	밀리초~초	분~시간	초~분
비용	높음	낮음	중간
구현 난이도	높음	낮음	높음
대표 사례	실시간 추천, 챗봇	일일 스코어링	이상 거래 탐지

실무에서는 하이브리드가 많다. 무거운 후보 생성은 배치로 미리 계산하고, 사용자가 접속하면 온라인 서버가 현재 세션 정보로 가볍게 재정렬한다. 이렇게 하면 비용과 신선도 사이에서 균형을 잡을 수 있다.

모델 패키징과 서빙 도구

모델 서빙 도구를 고를 때는 "API를 빨리 만들 수 있는가"보다 "운영 표준을 얼마나 쉽게 지킬 수 있는가"를 봐야 한다.

FastAPI: 파이썬으로 REST API를 빠르게 만들기 좋다. 입력 검증, 문서 자동 생성이 편하다. 대신 모델 버전 관리, 동적 배칭, 다중 모델 라우팅은 직접 설계해야 한다.
MLflow Models: 실험 추적과 모델 레지스트리에서 이어지는 흐름이 좋다. 모델 아티팩트, 환경 정보, 서빙 포맷을 함께 관리할 수 있어 재현성에 유리하다.
BentoML: 모델을 서비스 단위로 패키징하고 컨테이너화하는 데 강점이 있다. 여러 프레임워크 모델을 일관된 방식으로 배포하려는 팀에 적합하다.
TorchServe: PyTorch 모델 서빙에 특화되어 있다. 딥러닝 모델을 API로 제공하고, 모델 핸들러를 통해 전처리와 후처리를 묶을 수 있다.

작은 팀은 FastAPI로 시작해도 괜찮다. 단, 처음부터 다음 항목은 넣어야 한다.

/predict   예측 요청
/health    서버 생존 확인
/ready     모델 로드 완료 확인
/metrics   지연 시간, 요청 수, 오류율 노출

운영 규모가 커지면 모델 서버를 컨테이너로 만들고 Kubernetes, Cloud Run, SageMaker, Vertex AI, Azure ML 같은 실행 환경에 배포한다. MLOps 원칙에서는 모델 예측 서비스를 REST API처럼 운영 시스템에 배포하고, 모니터링 결과가 다시 재학습이나 실험으로 이어지는 흐름을 강조한다.³

쉬운 비유 또는 사례

모델 서빙은 식당 운영과 비슷하다. 모델 파일은 레시피다. 레시피가 좋다고 손님이 제때 음식을 받는 것은 아니다.

온라인 서빙은 손님이 주문하면 즉시 조리하는 식당이다. 맛도 중요하지만 대기 시간이 중요하다. 주문이 몰리면 조리대를 늘리거나, 일부 재료를 미리 준비해야 한다.

배치 추론은 도시락을 미리 만들어 두는 방식이다. 점심시간 전에 1,000개를 만들어 두면 주문 즉시 건넬 수 있다. 하지만 갑자기 식단이 바뀌거나 새 손님이 오면 미리 만든 도시락이 맞지 않을 수 있다.

스트리밍 추론은 컨베이어 벨트에 계속 올라오는 주문을 처리하는 주방이다. 주문이 들어오는 즉시 처리하지만, 손님이 카운터 앞에서 기다리는 구조는 아니다. 처리 결과는 알림판이나 다음 공정으로 이동한다.

LLM 서빙은 여기에 "요리 시간이 손님마다 크게 다른 코스 요리"가 추가된 상황이다. 짧은 질문은 금방 끝나지만, 긴 문서 요약은 오래 걸린다. 한 손님이 매우 긴 주문을 하면 GPU 자원을 오래 점유할 수 있다. 그래서 토큰 수 제한, 요청 큐, 캐싱, 사용량 제한이 필요하다.

직접 해보는 실습

이번 실습에서는 간단한 모델 서버 설계 문서를 작성한다. 실제 코드를 완성하는 것보다 운영 요구사항을 먼저 정리하는 것이 목적이다.

1단계: 요구사항 정하기

아래 질문에 답하라.

서비스 이름: 상품 추천 API
예측 방식: 온라인 / 배치 / 스트리밍 / 하이브리드
목표 p95 지연 시간: 예) 200ms 이하
예상 평균 QPS: 예) 50
예상 피크 QPS: 예) 500
입력 피처: user_id, current_item_id, device_type
피처 조회 위치: Redis, Feature Store, DB
모델 버전: recommender:1.3.0
롤백 버전: recommender:1.2.4

2단계: API 계약 작성하기

POST /v1/predict
request:
  user_id: string
  item_id: string
  device_type: string
response:
  request_id: string
  model_version: string
  recommendations: list[string]
  latency_ms: number

API 응답에 model_version과 request_id를 넣는 습관을 들이자. 장애가 났을 때 어떤 모델이 어떤 요청에 응답했는지 추적할 수 있다.

3단계: 배포 전략 정하기

다음 순서로 새 모델을 배포한다고 가정하라.

스테이징 환경에서 입력 스키마와 성능 테스트를 통과한다.
운영 트래픽의 0%를 받는 상태로 새 배포를 만든다.
섀도우 배포로 실제 요청을 복제해 새 모델 응답을 기록한다.
이상이 없으면 카나리 배포로 5% 트래픽만 보낸다.
핵심 지표가 기준을 통과하면 25%, 50%, 100%로 늘린다.
오류율 또는 지연 시간이 기준을 넘으면 즉시 이전 모델로 롤백한다.

카나리 배포는 일부 사용자에게만 새 모델을 노출하는 방식이다. 섀도우 배포는 새 모델이 응답을 계산하지만 사용자에게는 기존 모델 결과만 보여주는 방식이다. A/B 테스트는 모델 차이가 실제 비즈니스 지표에 어떤 영향을 주는지 비교하는 실험이다.

흔한 실수와 오류 분석

첫째, 모델 추론 시간만 최적화한다. 실제 병목은 피처 조회일 수 있다. 사용자별 피처를 매번 데이터 웨어하우스에서 조회하면 아무리 빠른 모델도 소용없다. 온라인 서빙에는 낮은 지연 시간의 캐시나 온라인 피처 스토어가 필요하다.

둘째, 입력 스키마 검증을 생략한다. 학습 때는 숫자였던 값이 운영에서 문자열로 들어오면 서버가 실패하거나 더 나쁜 경우 조용히 잘못된 예측을 낸다.

셋째, 모델 로드 시간을 무시한다. 컨테이너는 떴지만 모델이 아직 메모리에 없으면 첫 요청이 실패한다. /health와 /ready를 분리해야 한다. health는 프로세스 생존 여부, ready는 예측 가능 여부를 뜻한다.

넷째, 새 모델을 한 번에 100% 배포한다. 모델 평가지표가 좋아도 운영 입력 분포에서는 다르게 동작할 수 있다. 반드시 카나리, 섀도우, 빠른 롤백 전략을 준비한다.

다섯째, LLM 비용을 평균 요청 수로만 계산한다. LLM 비용은 요청 수보다 토큰 수에 더 민감하다. 긴 프롬프트, 긴 대화 기록, 반복 재시도, 무제한 생성이 비용 폭증의 원인이 된다. 프롬프트 버전, 최대 토큰 수, 캐시 적중률, 사용자별 사용량 제한을 함께 관리해야 한다.