모델 서빙: 프로덕션을 지원하는 런타임 계층

프로덕션 머신러닝에서 모델은 시스템에서 가장 작은 부분인 경우가 많습니다. 연구자 David Sculley 외 연구진은 논문 Hidden Technical Debt in Machine Learning Systems에서 이러한 점을 지적하며, 실제 환경의 많은 ML 시스템에서 학습 또는 예측에 사용되는 부분은 극히 일부에 불과하다고 설명했습니다. 나머지는 데이터 수집, 피처 추출, 검증, 구성, 모니터링, 리소스 관리, 프로세스 관리, 서빙 인프라 및 구성 요소를 서로 연결하는 접착 코드로 이루어진 주변 프로덕션 시스템입니다. 저자들은 성숙한 시스템에서는 그 비중이 머신러닝 코드 5%와 지원 시스템 코드 95%까지 기울 수 있다고 밝혔습니다.

모델 서빙은 이러한 프로덕션 아키텍처 안에 직접 자리합니다. 모델을 엔드포인트를 통해 노출하는 것만을 의미하지는 않습니다. 온라인 추론, 배치 스코어링 및 스트리밍 워크플로우 전반에서 예측을 사용할 수 있고 안정적이며 거버넌스가 적용된 상태로 유지하는 런타임 계층입니다. 실제로 서빙은 라우팅, 지연 시간, 확장, 버전 관리, 피처 일관성 및 거버넌스도 관리해야 합니다. 이러한 운영상의 요소가 모델이 프로덕션 의사 결정을 안정적으로 지원할 수 있는지를 결정합니다.

적절한 서빙 아키텍처가 없으면 모델 배포에 사용자 지정 인프라가 쌓이기 시작할 수 있습니다. 엔지니어는 별도의 엔드포인트, 피처 파이프라인, 레지스트리, 자격 증명, 모니터링 시스템 및 컴퓨팅 환경을 관리합니다. 시간이 지나면 서빙 경로는 ML 시스템에 운영 부채가 누적되는 또 하나의 영역이 됩니다.

모델 서빙은 프로덕션에서 훈련된 모델을 추론에 사용할 수 있도록 만드는 런타임 계층입니다. 프로덕션 데이터를 수신하고 해당 데이터를 올바른 모델 버전으로 전달한 다음, 생성된 예측을 애플리케이션, 워크플로우 또는 다운스트림 시스템으로 반환합니다.

안정적인 서빙 경로가 없는 배포된 모델은 팀에 해결되지 않은 프로덕션 관련 질문을 남깁니다. 요청이 모델에 도달하게 하려면 어떻게 해야 할까요? 수요가 급증하면 어떻게 될까요? 프로덕션 트래픽을 어느 버전으로 전달해야 할까요? 챌린저 모델의 성능이 낮을 경우 시스템을 어떻게 롤백할 수 있을까요? 피처 로직은 어디에 있으며, 훈련과 추론에서 일관되게 적용되고 있을까요?

모델 서빙의 목표는 이러한 질문에 답하고 훈련된 모델을 프로덕션에서 사용할 수 있도록 만드는 것입니다. 이를 위해 서빙 계층은 추론과 관련된 운영 작업을 처리합니다. 올바른 모델 버전으로 요청을 라우팅하고, 수요에 맞게 용량을 확장하며, 지연 시간 요구 사항 내에 예측을 반환하고, 런타임에 필요한 데이터 및 피처 로직에 모델을 연결합니다.

프로덕션 시스템에서는 서빙 계층이 지연 시간 SLA, 처리량 목표 및 런타임 효율성도 고려해야 합니다. 예를 들어 비활성 상태 이후에도 모델이 빠르게 응답할 수 있도록 콜드 스타트 시간을 줄이거나, 우선순위가 높은 워크로드에 사용할 컴퓨팅 웜 풀을 유지하거나, 여러 모델 또는 버전이 동일한 인프라를 공유할 때 멀티 모델 서빙을 지원해야 할 수 있습니다.

모델 배포와 모델 서빙은 밀접하게 관련되어 있지만 프로덕션 수명 주기의 서로 다른 부분을 의미합니다.

• 모델 배포는 훈련된 모델을 프로덕션 환경으로 이동하는 작업입니다. 여기에는 모델 패키징, 등록, 릴리스 승인 및 애플리케이션이나 스코어링 워크플로우에서 모델을 사용할 수 있도록 만드는 작업이 포함될 수 있습니다.
• 모델 서빙은 배포 후에도 모델을 사용할 수 있도록 유지하는 런타임 인프라입니다.

이러한 관점에서 배포는 전환입니다. 서빙은 그 뒤를 따르는 운영 모델입니다.

적절한 서빙 모드는 예측 결과를 사용하는 방식에 따라 달라집니다. 일부 워크로드에는 개별 요청에 대한 짧은 지연 시간의 응답이 필요합니다. 다른 워크로드에는 대규모 데이터 세트에 대한 높은 처리량의 스코어링이 필요합니다. 일부 애플리케이션에서는 서빙 계층이 이벤트의 연속 스트림을 소비하고, 다른 애플리케이션에서는 모델이 디바이스 또는 네트워크 엣지에서 실행됩니다.

온라인 추론은 일반적으로 모델 엔드포인트와 연결되는 서빙 모드입니다. 애플리케이션이 일반적으로 REST 또는 gRPC를 통해 요청을 보내면, 모델은 응답을 기다리는 사용자나 시스템이 사용할 수 있을 만큼 빠르게 예측을 반환합니다. 사기 감지, 추천, 개인화 및 검색 순위 지정에서는 예측이 즉각적인 의사 결정에 영향을 미치므로 이 패턴을 흔히 사용합니다.

배치 스코어링은 이와 다르게 작동합니다. 한 번에 하나의 요청에 응답하는 대신 모델이 일정에 따라 데이터 세트 전체에 대해 추론을 실행합니다. 예를 들어 고객 이탈 모델은 매일 밤 계정을 스코어링하거나, 수요 Forecasting 모델은 매일 아침 예측을 새로 고칠 수 있습니다. 응답을 기다리는 사용자가 없으므로 일반적으로 1초 미만의 지연 시간보다 처리량과 비용 효율성이 더 중요합니다.

스트리밍 추론에서는 모델이 스트림에서 이벤트를 소비하고 새로운 데이터가 도착할 때마다 예측을 반환합니다. 예를 들어 IoT 이상 감지 모델은 야간 배치 작업을 기다리는 대신 센서 데이터가 들어오는 즉시 이를 평가할 수 있습니다.

엣지 배포는 모델을 활동 소스에 더 가깝게 배치합니다. 디바이스가 오프라인으로 작동해야 하거나, 왕복 지연 시간을 피하거나, 데이터를 로컬에 유지해야 하는 경우 중앙 집중식 엔드포인트를 통한 서빙은 적합하지 않습니다. 이러한 경우 모델은 디바이스 또는 네트워크 엣지에서 실행되며, 패키징, 배포, 업데이트 및 모니터링을 위한 별도의 프로세스가 사용됩니다.

이러한 모드는 함께 사용되는 경우가 많습니다. 기업은 광범위한 고객 세분화에 배치 스코어링을, 실시간 오퍼에 온라인 추론을, 운영 알림에 스트리밍 추론을 사용할 수 있습니다. 서빙 아키텍처 선택이 중요한 이유는 각 방식이 지연 시간, 컴퓨팅, 거버넌스 및 운영 요구 사항을 서로 다르게 조합하기 때문입니다.

가장 해결하기 어려운 서빙 문제 중 하나는 모델이 프로덕션 트래픽을 처리하기 훨씬 전에 시작됩니다. 트레이닝 서빙 불일치는 트레이닝 중 사용한 피처 로직과 추론에 적용한 로직이 서로 다를 때 발생합니다. 모델은 데이터의 한 가지 표현으로 평가된 후 다른 표현으로 서빙됩니다. 엔드포인트는 여전히 트레이닝 중 모델이 접한 것과 동일한 종류의 데이터를 받는 것처럼 응답합니다. 그러나 예측은 모델이 이해하도록 트레이닝된 적이 없는 입력을 기반으로 이루어집니다.

Google’s Rules of Machine Learning에서는 트레이닝 및 서빙 파이프라인 간 불일치, 트레이닝과 서빙 사이의 데이터 변경, 시스템 자체에서 발생하는 피드백 루프 등을 포함하여 트레이닝 서빙 불일치를 실제 프로덕션 문제로 규정합니다. 이 가이드에서는 시스템과 데이터 변경으로 인해 불일치가 발생하더라도 이를 인지하지 못하는 일이 없도록 불일치를 측정해야 한다고 명확히 설명합니다.

많은 스택에서 근본 원인은 아키텍처에 있습니다. 트레이닝에는 배치 파이프라인을 사용하는 경우가 많지만 서빙에는 실시간 파이프라인을 사용하는 경우가 많습니다. 서로 다른 팀이 이를 관리하고, 서로 다른 코드가 피처 변환을 구현합니다. 시간이 지나면 작은 변경만으로도 오프라인 모델 개발 환경과 온라인 추론 경로 사이에 드리프트가 발생합니다.

피처 스토어는 트레이닝과 추론 전반에서 피처 로직을 재사용할 수 있도록 하여 이러한 분리를 해결합니다. 트레이닝 파이프라인에서 피처의 한 버전을 정의하고 서빙 애플리케이션에서 다른 버전을 정의하는 대신, 팀은 피처를 한 번만 정의하고 두 컨텍스트 모두에서 사용합니다.

모델 서빙에서 이는 단순한 데이터 엔지니어링 문제가 아닙니다. 피처 일관성에 따라 서빙 계층이 팀에서 평가한 모델의 예측을 반환하는지, 아니면 프로덕션 파이프라인이 우연히 생성한 변형 모델의 예측을 반환하는지가 결정됩니다.

모델이 프로덕션에 배포할 준비가 되면 서빙 계층은 사용할 버전, 모델의 출처, 승격 또는 롤백 조건을 파악해야 합니다.

모델 레지스트리는 이러한 제어점을 제공합니다. 모델 레지스트리는 트레이닝된 모델 아티팩트를 버전 기록, 평가 지표, 배포 상태 및 Lineage와 함께 저장합니다. 레지스트리는 모델을 프로덕션에 복사되는 파일로 취급하는 대신, 정의된 수명 주기 상태를 가진 거버넌스 적용 자산으로 취급합니다.

활성 상태이거나 릴리스할 수 있는 버전이 둘 이상일 때 이러한 차이가 중요합니다. 모델은 Registered 상태로 시작해 검증 후 스테이징으로 이동하고, 정확도, 지연 시간, 공정성 또는 비용 임계값을 충족한 경우에만 프로덕션으로 승격될 수 있습니다. 이러한 승격 게이트를 통해 배포는 수동 인계보다 정책에 더 의존하게 됩니다.

Lineage는 또 다른 제어 계층을 추가합니다. 배포된 모델 버전에 대해 레지스트리에는 해당 모델을 생성한 트레이닝 데이터, 코드, 매개변수 및 평가 결과가 표시되어야 합니다. 성능이 변하거나 감사 요청이 접수되거나 롤백이 필요해질 때 이러한 기록은 단순한 관리 정보를 넘어 운영에 유용하게 활용됩니다.

레지스트리는 챔피언-챌린저 서빙 패턴도 지원합니다. 프로덕션 모델이 대부분의 트래픽을 계속 처리하는 동안 챌린저 모델에는 더 적은 비율의 트래픽이 할당될 수 있습니다. 챌린저 모델의 성능이 더 우수하면 트래픽을 전환할 수 있습니다. 성능이 저조하면 서빙 계층이 버전 관리 및 배포 상태에 연결되어 있으므로 간단하게 롤백할 수 있습니다.

대규모 언어 모델(LLM)은 서빙에 필요한 제약 조건을 새롭게 추가합니다. 기본 개념은 여전히 추론입니다. 모델이 입력을 받아 출력을 반환합니다. 그러나 런타임 메커니즘은 기존 ML 서빙과 중요한 측면에서 다릅니다.

LLM 서빙 계층은 토큰 처리량, 컨텍스트 길이, GPU 메모리, 배칭 전략, KV 캐시 관리 및 디코딩 동작을 고려해야 합니다. 대용량 애플리케이션에서는 시스템이 요청을 얼마나 효율적으로 예약하고 계산을 재사용하는지에 따라 성능이 달라집니다. 추측 디코딩, 연속 배칭, 모델 양자화와 같은 기법이 존재하는 이유는 대규모 모델을 사용 가능한 지연 시간과 비용으로 서빙하는 일이 모델링만큼이나 시스템의 문제이기 때문입니다.

최신 LLM 서빙 스택은 점점 추론 최적화에 집중하고 있습니다. GPU 메모리를 효율적으로 사용하고, 요청을 예약하고, 캐시된 계산을 재사용하며, 지연 시간이나 비용을 프로덕션 한도 이상으로 늘리지 않고 처리량을 개선하는 방법이 핵심입니다.

프롬프트 버전 관리도 서빙 관리의 일부가 됩니다. 기존 ML에서는 모델 동작을 변경하려면 일반적으로 재트레이닝, 파인튜닝 또는 모델 버전 교체가 필요합니다. LLM 애플리케이션에서는 모델 가중치를 변경하지 않고도 프롬프트를 변경하여 동작을 바꿀 수 있습니다. 따라서 프롬프트, 시스템 지침 및 검색 템플릿에도 다른 프로덕션 아티팩트와 유사한 버전 관리, 테스트 및 롤백 방식이 필요합니다.

RAG 파이프라인은 서빙 경로를 더욱 복잡하게 만듭니다. 사용자 요청은 벡터 인덱스에서 검색을 수행하고, 컨텍스트를 구성하고, 모델로 출력을 생성하고, 애플리케이션에 응답이 전달되기 전에 출력을 평가하는 작업을 트리거할 수 있습니다. 검색과 생성이 운영 측면이나 물리적 측면에서 너무 멀리 떨어져 있으면 지연 시간이 증가합니다. 버전 관리 없이 검색 로직이 변경되면 모델이 동일하게 유지되더라도 출력 동작이 달라집니다.

파인튜닝 및 어댑터 기반 모델은 또 다른 계층을 추가합니다. LoRA 서빙을 사용하면 여러 작업별 어댑터를 공유 기본 모델에서 실행할 수 있으므로, 모든 사용 사례마다 완전히 별도의 모델을 로드하지 않고도 특화된 동작을 지원할 수 있습니다. INT4 또는 INT8과 같은 양자화는 메모리 및 컴퓨팅 요구 사항을 줄여 비용과 지연 시간 제약하에서도 더 큰 모델을 실용적으로 서빙할 수 있게 합니다.

LLMOps에서 서빙은 더 이상 엔드포인트에 국한된 문제가 아닙니다. 여기에는 프롬프트 관리, 검색 아키텍처, GPU 효율성, 런타임 평가 및 모델 변형 관리가 포함됩니다. LLM 배포를 더 큰 버전의 scikit-learn 워크플로우로 취급하면 생성형 AI 애플리케이션을 프로덕션에서 작동하게 하는 서빙 기본 요소를 놓치게 됩니다.

기존 MLOps 스택은 서빙 책임을 여러 시스템에 분산하는 경우가 많습니다. 팀은 모델 레지스트리에 하나의 도구를 사용하고, 서빙과 모니터링에 각각 다른 도구를 사용하며, 컴퓨팅에는 별도의 Kubernetes 환경을 사용할 수 있습니다. 각 시스템에는 고유한 자격 증명, 구성, 액세스 제어 및 운영 방식이 필요합니다.

이러한 구성도 작동할 수 있지만 일반적으로 운영 범위와 복잡성이 증가합니다. 트레이닝된 모델은 엔지니어가 조립하고 유지 관리해야 하는 더 큰 서빙 환경의 한 구성 요소에 불과해집니다. 앞서 언급한 기술 부채 관련 논문의 표현을 빌리면, 위험은 글루 코드의 증가입니다. 커넥터, 중복 로직, 구성 경로가 늘어나고 프로덕션 동작이 개발 환경의 가정과 달라질 수 있는 지점도 많아집니다.

Snowflake의 접근 방식은 모델 레지스트리, 피처 스토어, Snowpark Container Services를 사용하는 GPU 컴퓨팅 풀, 배치 및 온라인 추론, 모델 모니터링을 하나의 거버넌스 적용 플랫폼으로 통합하여 엔드투엔드 AI/ML 워크플로우를 지원합니다. 이를 통해 레지스트리, 서빙 및 모니터링을 위한 별도 도구를 연결해야 할 필요성을 줄이고, 엔지니어가 지원되는 워크플로우에서 Python과 SQL을 직접 사용할 수 있습니다.

Snowpark Container Services GPU 컴퓨팅 풀을 사용하면 팀은 GPU 가속 추론을 위한 사용자 지정 컨테이너를 가져올 수 있으며, 지원되는 여러 추론 워크플로우에서 거버넌스가 적용된 데이터를 Snowflake 외부로 이동하거나 별도의 Kubernetes 환경을 관리하지 않아도 됩니다. 이러한 워크로드는 액세스 관리를 위한 역할 기반 액세스 제어를 사용하여 Snowflake의 거버넌스 적용 환경에서 실행할 수 있습니다.

배치 추론의 경우 팀은 최소한의 서빙 설정만으로 Snowpark DataFrame에서 Registered 모델을 호출할 수 있습니다. 온라인 추론의 경우 팀은 SPCS REST 엔드포인트를 통해 모델을 배포할 수 있습니다.

그 결과 서빙 경로가 더욱 간결해집니다. 엔지니어는 여전히 워크로드에 적합한 패턴을 선택하고 성능을 조정하며 모델 버전을 관리합니다. 데이터와 예측을 서로 단절된 시스템 간에 이동하기 위해서만 존재하는 인프라를 연결하는 데 드는 시간은 줄어듭니다.

모델 서빙은 트레이닝된 모델을 프로덕션 시스템의 운영 환경으로 가져옵니다. 예측을 요청하는 방식, 컴퓨팅이 실행되는 위치, 응답하는 버전, 피처 적용 방식, 그리고 실제 워크로드에서 지연 시간, 비용 및 거버넌스 요구 사항을 충족하는지를 결정합니다.

강력한 서빙 계층은 이러한 요소를 더욱 긴밀하게 연결합니다. 온라인 추론, 배치 스코어링, 스트리밍 워크플로우 및 LLM 서빙에는 각각 서로 다른 요구 사항이 적용되지만, 근본적인 요구 사항은 동일합니다. 모든 배포가 사용자 지정 인프라 프로젝트가 되지 않도록 모델, 데이터, 피처, 컴퓨팅 및 거버넌스를 연결하는 프로덕션 경로가 필요합니다.