TensorFlow Serving편집자 확인

TensorFlow Serving의 핵심 목표는 프로덕션 환경에서 낮은 지연 시간과 높은 처리량을 보장하는 고성능 추론 서비스를 제공하는 것이다. 이를 위해 시스템은 효율적인 리소스 관리와 최적화된 추론 엔진을 내장하고 있다. 특히, GPU나 TPU와 같은 가속 하드웨어를 활용하여 병렬 처리를 극대화하고, 배치 처리를 지원하여 단일 요청당 비용을 줄이는 동시에 시스템 전체의 처리 효율을 높인다.

고성능을 달성하는 또 다른 요소는 메모리 사용의 최적화에 있다. TensorFlow Serving은 서버에 로드된 머신러닝 모델을 효율적으로 관리하며, 여러 모델 버전이 동시에 메모리에 상주하더라도 불필요한 중복을 제거하고 필요한 자원만 할당한다. 또한, 예측 요청에 대한 지연 시간을 최소화하기 위해 요청 큐 관리와 스레드 풀을 세밀하게 조정할 수 있는 설정을 제공한다.

이러한 설계는 대규모 실시간 추론이 필요한 서비스, 예를 들어 추천 시스템, 실시간 번역, 이미지 인식 API 등에서 필수적인 요소이다. TensorFlow Serving은 단일 서버 인스턴스에서도 높은 성능을 발휘하도록 구축되었으며, 로드 밸런싱과 클러스터링을 통해 수평 확장이 가능하여 트래픽이 급증하는 상황에서도 안정적인 서비스 수준을 유지할 수 있게 한다.

TensorFlow Serving의 모델 버전 관리 기능은 동일한 모델의 여러 버전을 동시에 서빙하고, 새로운 버전을 무중단으로 롤아웃하거나 이전 버전으로 롤백할 수 있도록 지원한다. 이는 프로덕션 환경에서 머신러닝 모델을 지속적으로 업데이트해야 할 때 필수적인 기능이다. 시스템은 지정된 디렉터리를 모니터링하며, 새로운 모델 버전이 배포되면 자동으로 로드하여 서비스를 시작한다.

버전 관리는 A/B 테스트나 카나리 릴리스와 같은 배포 전략을 구현하는 데 핵심적이다. 예를 들어, 트래픽의 일부만 새 버전의 모델로 라우팅하여 성능을 비교 평가할 수 있다. 또한 특정 버전의 모델이 문제를 일으킬 경우, 즉시 이전의 안정적인 버전으로 트래픽을 되돌리는 롤백이 가능하여 서비스의 가용성을 유지한다.

이러한 관리는 모델 서버의 핵심 구성 요소 중 하나인 모델 라이프사이클 관리자에 의해 수행된다. 관리자는 디스크에 저장된 각 모델 버전의 상태를 추적하고, 메모리 로드 정책을 적용하며, 클라이언트 요청에 따라 적절한 모델 버전을 선택하여 추론을 실행한다. 이를 통해 MLOps 파이프라인에서 모델의 배포와 운영을 효율적으로 자동화할 수 있다.

TensorFlow Serving은 SavedModel 형식을 기본적으로 지원한다. SavedModel은 텐서플로 모델의 표준 직렬화 형식으로, 모델의 계산 그래프, 가중치, 서명, 자산 파일 등을 하나의 디렉토리 구조로 패키징한다. 이는 모델의 훈련과 서빙을 분리하는 데 핵심적인 역할을 한다.

또한 TensorFlow Serving은 TensorFlow Hub 모듈, Keras 모델을 SavedModel으로 변환한 형식, 그리고 TensorFlow Lite 모델의 일부 사용 사례를 지원한다. 이를 통해 연구 단계에서 개발된 다양한 스타일의 모델을 비교적 쉽게 프로덕션 환경에 통합할 수 있다.

서버는 지정된 모델 디렉토리를 지속적으로 모니터링하며, 새로운 버전의 모델이 SavedModel 형식으로 추가되면 자동으로 로드하여 서빙을 시작한다. 이러한 유연한 형식 지원은 MLOps 파이프라인에서 모델의 지속적인 통합과 배포를 원활하게 만드는 기반이 된다.

TensorFlow Serving은 클라우드 컴퓨팅 환경과 온프레미스 환경 모두에서 원활하게 확장될 수 있도록 설계되었다. 시스템은 도커 컨테이너를 통한 배포를 공식적으로 지원하며, 쿠버네티스와 같은 오케스트레이션 도구와의 통합을 통해 대규모 마이크로서비스 아키텍처에서도 효율적으로 운영될 수 있다. 이는 부하 분산과 자원 관리가 필요한 프로덕션 환경에서 필수적인 특성이다.

또한 이 시스템은 높은 유연성을 제공한다. 사용자는 gRPC와 REST API 중에서 추론 요청을 위한 인터페이스를 선택할 수 있어, 다양한 클라이언트 애플리케이션과의 통합이 용이하다. 내부적으로는 바젤 빌드 시스템을 사용하여 필요에 따라 커스텀 빌드를 생성할 수 있으며, 모니터링을 위한 프로메테우스 지표 노출과 같은 기능도 지원한다.

이러한 확장성과 유연성은 TensorFlow Serving이 단순한 추론 엔진을 넘어, MLOps 파이프라인의 핵심 구성 요소로서 복잡한 머신러닝 시스템을 구축하고 유지 관리하는 데 기여한다. 개발팀은 변화하는 비즈니스 요구사항과 모델 업데이트 주기에 맞춰 서빙 인프라를 유연하게 조정할 수 있다.

TensorFlow Serving의 서버 코어는 시스템의 핵심 엔진으로, 추론 요청을 효율적으로 처리하고 모델을 메모리에 로드하여 관리하는 역할을 담당한다. 이는 C++로 작성되어 높은 성능과 낮은 지연 시간을 보장하며, gRPC와 REST API를 통해 외부 클라이언트와 통신할 수 있는 인터페이스를 제공한다. 서버 코어는 다중 모델 버전을 동시에 메모리에 유지하고, 들어오는 요청을 적절한 모델 버전으로 라우팅하는 책임을 진다.

서버 코어의 중요한 구성 요소로는 모델 서버와 서빙 배처가 있다. 모델 서버는 실제 모델 파일을 로드하고 실행하는 주체이며, 서빙 배처는 여러 클라이언트 요청을 자동으로 배치 처리하여 하드웨어 가속기(GPU, TPU)의 활용률을 극대화하고 처리량을 향상시킨다. 이 배처는 동적 배칭을 지원하여 요청이 들어오는 대로 지연 시간을 희생하지 않으면서도 효율적인 배치 크기를 유지한다.

서버 코어는 또한 모델 라이프사이클의 핵심 단계를 관리한다. 이는 파일 시스템을 모니터링하여 새로운 모델 버전이 배포되면 기존 버전과의 무중단 전환을 보장하며, 모델의 로드, 언로드, 버전 스위칭을 원활하게 수행한다. 이러한 설계는 프로덕션 환경에서 서비스의 가용성과 신뢰성을 유지하는 데 필수적이다.

TensorFlow Serving의 모델 라이프사이클 관리는 서버가 배포된 머신러닝 모델을 동적으로 관리하고 업데이트하는 핵심 기능이다. 이 시스템은 모델의 버전을 추적하고, 새로운 버전을 자동으로 감지하여 로드하며, 이전 버전을 안전하게 언로드하는 과정을 자동화한다. 이를 통해 서비스 중단 없이 모델을 지속적으로 배포하고 A/B 테스트를 수행하는 것이 가능해진다. 모델의 라이프사이클은 서버가 모델 데이터를 모니터링하는 디렉토리에서 시작되며, 새로운 모델 버전이 감지되면 비동기적으로 로딩 절차를 진행한다.

모델 라이프사이클 관리의 주요 구성 요소로는 모델 버전 정책과 서빙 세션이 있다. 모델 버전 정책을 통해 관리자는 특정 버전만 서빙하거나, 최신 버전을 자동으로 서빙하도록 설정할 수 있다. 서빙 세션은 로드된 모델 버전을 메모리에 유지하고, 클라이언트 요청이 들어오면 해당 세션을 통해 효율적인 추론을 실행한다. 이 아키텍처는 롤링 업데이트와 같은 DevOps 관행을 MLOps 환경에 적용할 수 있게 해준다.

모델의 로드와 언로드는 서비스 가용성에 영향을 주지 않도록 설계되었다. 새로운 버전의 모델이 준비되면, 기존 서빙 세션은 유지된 상태에서 새 버전에 대한 세션이 백그라운드에서 초기화된다. 초기화가 완료되면 트래픽을 점진적으로 새 버전으로 전환할 수 있으며, 문제 발생 시 즉시 이전 안정적인 버전으로 롤백하는 것도 가능하다. 이러한 체계적인 관리는 프로덕션 환경에서 모델의 지속적인 개선과 유지보수를 용이하게 한다.

TensorFlow Serving은 REST API와 gRPC 기반의 두 가지 주요 API 엔드포인트를 제공하여 클라이언트 애플리케이션이 서버와 통신할 수 있게 한다. REST API는 HTTP/1.1 프로토콜을 사용하며, JSON 형식의 데이터를 주고받는 표준적인 웹 요청 방식으로, 웹 브라우저나 curl과 같은 간단한 도구로도 쉽게 테스트할 수 있다는 장점이 있다. 반면, gRPC 엔드포인트는 HTTP/2 프로토콜을 기반으로 한 고성능 RPC 프레임워크를 사용하여, 이진 프로토콜 버퍼를 통해 데이터를 직렬화하므로 지연 시간이 낮고 처리량이 높다. 이는 대규모 프로덕션 환경에서 실시간 추론이 필요한 경우에 특히 유리하다.

이러한 API 엔드포인트를 통해 클라이언트는 특정 모델의 특정 버전을 대상으로 예측 요청을 보내거나, 서버에 로드된 모델의 메타데이터를 조회할 수 있다. 예를 들어, 모델의 서명, 입력/출력 텐서의 형태와 데이터 타입 등의 정보를 얻을 수 있어 클라이언트 측에서 요청 데이터를 올바르게 구성하는 데 도움을 준다. 또한, 모델 상태 확인을 위한 헬스 체크 엔드포인트도 제공되어 DevOps 관점에서 서비스의 가용성을 모니터링하기 용이하다.

TensorFlow Serving의 아키텍처는 이러한 API 요청을 효율적으로 처리하도록 설계되었다. 들어오는 요청은 먼저 서버 코어에 의해 수신되고, 해당 모델의 버전이 지정되어 있지 않으면 기본적으로 최신 버전의 모델을 사용하여 추론을 수행한다. 이 과정에서 모델 버전 관리 시스템과 통합되어 원활하게 작동하며, 다중 모델 서빙이나 A/B 테스트와 같은 고급 시나리오를 지원하는 기반이 된다.

TensorFlow Serving에서의 모델 배포는 학습이 완료된 머신 러닝 모델을 서비스 가능한 형태로 준비하여 서빙 시스템에 등록하는 과정을 의미한다. 배포를 위해서는 먼저 TensorFlow로 학습된 모델을 SavedModel 형식으로 내보내야 한다. SavedModel은 모델의 계산 그래프, 가중치, 시그니처 등 서빙에 필요한 모든 정보를 포함하는 표준 포맷이다.

배포 과정은 크게 모델 준비와 서버에 모델 제공으로 나눌 수 있다. 개발자는 로컬 환경에서 모델을 SavedModel로 저장한 후, 이를 TensorFlow Serving 서버가 접근할 수 있는 파일 시스템 경로에 배치한다. 서버는 지정된 경로를 주기적으로 모니터링하며, 새 모델 버전이 감지되면 자동으로 로드하여 서비스를 시작한다. 이는 롤링 업데이트 없이도 모델의 신규 버전을 실시간으로 교체할 수 있게 해준다.

모델은 버전 번호가 붙은 디렉토리 하위에 저장되며, 서버는 여러 버전의 모델을 동시에 메모리에 유지할 수 있다. 이를 통해 A/B 테스트를 수행하거나, 새 모델에 문제가 발생했을 경우 이전 버전으로 즉시 롤백하는 것이 가능하다. 배포 설정은 gRPC 또는 REST API를 통해 모델의 로드 여부를 확인하거나, 특정 버전을 명시적으로 로드하도록 지시하는 방식으로 관리할 수 있다.

TensorFlow Serving의 요청 처리 과정은 클라이언트가 API를 통해 추론 요청을 보내고, 시스템이 이를 효율적으로 처리하여 결과를 반환하는 일련의 흐름을 말한다. 주로 gRPC 또는 RESTful API 엔드포인트를 통해 요청을 받으며, 이는 HTTP 프로토콜을 사용한다. 서버는 들어오는 요청을 적절한 모델 버전으로 라우팅하고, 입력 데이터를 모델이 기대하는 텐서 형식으로 변환하는 전처리를 수행한다.

처리 핵심은 추론 실행을 위한 최적화된 경로를 제공하는 것이다. 시스템은 배치 처리나 개별 요청 처리를 지원하며, 내부적으로는 비동기 처리와 멀티스레딩을 활용하여 높은 처리량과 낮은 지연 시간을 달성한다. 요청이 특정 모델의 특정 버전을 지정하지 않을 경우, 기본적으로 서버에 로드된 최신 버전의 모델을 사용하여 추론을 실행한다.

처리된 결과는 다시 프로토콜 버퍼 또는 JSON 형식으로 직렬화되어 클라이언트에게 응답으로 전송된다. 이 과정에서 로깅과 모니터링을 위한 메타데이터를 함께 기록할 수 있으며, 이를 통해 서비스의 성능과 상태를 추적할 수 있다. 이러한 일관된 요청 처리 파이프라인은 프로덕션 환경에서 안정적인 머신러닝 서비스를 제공하는 데 기여한다.

TensorFlow Serving에서 추론 실행은 서버가 배포된 모델을 사용하여 클라이언트 요청에 대한 예측을 생성하는 핵심 과정이다. 이 과정은 서버 코어가 수신한 gRPC 또는 REST API 요청을 특정 모델 버전으로 라우팅하고, 해당 모델의 서명에 맞게 입력 데이터를 전처리한 후, 실제 추론 연산을 실행하는 방식으로 이루어진다. 추론은 CPU와 GPU 자원을 효율적으로 활용하여 지연 시간을 최소화하면서 처리량을 극대화하도록 설계되었다.

실제 추론 연산은 TensorFlow 그래프 실행 엔진에 의해 수행된다. TensorFlow Serving은 배치 처리와 같은 최적화 기법을 지원하여 여러 요청을 묶어 한 번에 처리함으로써 하드웨어 자원 사용 효율을 높이고 처리 속도를 개선한다. 또한, 동적 배치 기능을 통해 요청이 도착하는 대로 실시간으로 배치를 구성하여 지연 시간과 처리량 사이의 균형을 맞출 수 있다.

추론 실행 결과는 모델 서명에 정의된 출력 텐서 형태로 생성되며, 프로토콜 버퍼 형식으로 직렬화되어 클라이언트에게 응답으로 반환된다. 이 전체 과정은 모델의 버전이 전환되더라도 무중단으로 진행되어 서비스의 연속성을 보장한다. 이를 통해 의료 진단, 금융 사기 탐지, 추천 시스템과 같은 실시간 예측이 필요한 다양한 프로덕션 환경에서 안정적인 서비스를 제공할 수 있다.

TensorFlow Serving의 설치 및 설정은 주로 Docker 컨테이너를 활용하는 방법이 가장 일반적이다. 이는 복잡한 의존성 문제를 해결하고 일관된 환경에서 서버를 실행할 수 있게 해준다. 공식 Docker 허브에서 제공하는 tensorflow/serving 이미지를 사용하면 몇 가지 명령어만으로 서버를 빠르게 시작할 수 있다. 또한, Linux 등의 운영체제에 직접 바이너리를 설치하는 방법도 지원되지만, 환경 구성이 상대적으로 복잡할 수 있다.

설정 과정에서는 모델을 서빙하기 위한 기본 디렉토리 구조를 준비하는 것이 중요하다. TensorFlow Serving은 지정된 경로에서 모델 버전을 숫자로 된 하위 디렉토리(예: /1/, /2/)로 인식하고 자동으로 로드한다. 서버를 시작할 때는 --model_name과 --model_base_path와 같은 명령줄 인수를 통해 서비스할 모델의 이름과 경로를 지정해야 한다.

보다 세부적인 설정을 위해서는 gRPC와 REST API 포트를 변경하거나, 모델 구성 파일(models.config)을 사용해 여러 모델을 한 번에 관리하는 고급 옵션을 활용할 수 있다. 이 구성 파일을 통해 각 모델의 이름, 경로, 사용할 모델 플랫폼(예: TensorFlow, TensorFlow Lite)을 정의하고, 모델 버전 정책을 설정할 수 있어 MLOps 환경에서 체계적인 배포와 관리를 가능하게 한다.

TensorFlow Serving을 사용하기 위해서는 머신 러닝 모델을 서빙 가능한 형태로 준비해야 한다. 이 과정은 학습이 완료된 TensorFlow 모델을 TensorFlow Serving이 인식하고 로드할 수 있는 특정 형식으로 저장하는 것을 핵심으로 한다. 과거에는 SavedModel 형식과 Session Bundle 형식이 모두 지원되었으나, 현재는 SavedModel이 표준 및 권장 형식이다. 모델 개발자는 학습 스크립트에서 tf.saved_model.save() API를 사용하여 모델의 계산 그래프, 가중치, 서명 정의 및 필요한 에셋을 포함하는 SavedModel 번들을 생성한다.

모델을 저장할 때는 서빙 시 사용할 입력과 출력의 형태를 명확히 정의하는 서명(Signature)을 지정하는 것이 중요하다. 이 서명은 클라이언트가 요청을 보내고 응답을 받는 계약 역할을 한다. 또한, 모델 버전 관리를 위해 각 모델은 고유한 버전 번호가 붙은 디렉토리(예: /1/, /2/)에 저장되어야 하며, 이 버전 디렉토리는 상위 모델 이름 디렉토리 아래에 위치시킨다. 이 구조는 TensorFlow Serving이 여러 버전의 모델을 동시에 관리하고 롤링 업데이트를 수행하는 데 기반이 된다.

준비된 SavedModel은 로컬 파일 시스템, 클라우드 스토리지, 또는 모델 저장소에 배치된다. TensorFlow Serving 서버는 시작 시 구성된 모델 경로를 주기적으로 폴링하여 새로운 모델 버전을 감지하고 자동으로 로드한다. 이를 통해 모델을 다시 배포하거나 서버를 재시작하지 않고도 새로운 버전의 모델을 실시간으로 서비스에 투입할 수 있다.

TensorFlow Serving 서버를 실행하는 방법은 크게 두 가지로 나뉜다. 첫 번째는 사전 빌드된 바이너리 실행 파일을 사용하는 방법이다. 공식 Docker 이미지를 활용하거나, APT 저장소를 통해 시스템에 직접 설치한 후 tensorflow_model_server 명령어를 실행하는 것이 일반적이다. 이 방식은 빠르게 서버를 구동하고 테스트하는 데 적합하다. 두 번째 방법은 C++ 소스 코드를 직접 빌드하여 실행하는 것으로, 특정 운영체제나 하드웨어에 맞춘 최적화가 필요할 때 사용된다.

서버를 시작할 때는 필수적으로 --model_name과 --model_base_path와 같은 명령줄 인자를 지정해야 한다. --model_name은 클라이언트가 요청할 때 사용할 모델의 식별자이며, --model_base_path는 서빙할 모델이 저장된 파일 시스템 경로를 가리킨다. 이 경로는 로컬 디스크나 클라우드 스토리지와 같은 원격 저장소를 지원한다. 또한, 서버가 사용할 포트 번호를 --port 인자로 변경할 수 있으며, 기본값은 8500번 포트이다.

서버가 정상적으로 실행되면, 지정된 모델 저장소 경로를 주기적으로 폴링하여 새로운 모델 버전을 감지한다. 이는 모델 버전 관리 기능의 핵심으로, 새 버전의 모델이 배포되면 기존 서비스를 중단하지 않고도 자동으로 로드하여 서빙을 시작한다. 서버의 상태와 로드된 모델 정보는 gRPC 또는 REST API를 통해 확인할 수 있으며, 로그를 통해 서버의 작동 상태와 추론 요청 처리 내역을 모니터링할 수 있다.

클라이언트는 TensorFlow Serving 서버에 배포된 모델에 추론 요청을 보내고 결과를 받기 위해 다양한 방법을 사용한다. 가장 일반적인 방식은 gRPC 또는 REST API를 통해 서버의 엔드포인트에 접근하는 것이다. gRPC는 고성능 RPC 프레임워크로, 낮은 지연 시간과 높은 처리량을 요구하는 프로덕션 환경에서 주로 사용된다. 반면, REST API는 HTTP 프로토콜을 기반으로 하여 더 널리 알려진 표준이며, curl 명령어나 웹 브라우저를 포함한 다양한 클라이언트 도구에서 쉽게 테스트할 수 있다는 장점이 있다.

요청을 구성할 때 클라이언트는 서빙 중인 특정 모델의 이름과 버전을 지정해야 한다. 서버는 이를 통해 요청을 적절한 모델 인스턴스로 라우팅한다. 전송되는 데이터는 모델이 기대하는 입력 텐서의 형태와 데이터 타입을 따라야 하며, 일반적으로 프로토콜 버퍼 형식으로 직렬화된다. 서버는 이 입력을 받아 추론을 실행한 후, 출력 텐서를 포함한 예측 결과를 동일한 프로토콜을 통해 클라이언트에게 반환한다.

Python과 같은 인기 있는 프로그래밍 언어를 위한 전용 클라이언트 라이브러리가 제공되어, 개발자가 네트워크 통신의 복잡성을 직접 처리하지 않고도 쉽게 서버와 상호작용할 수 있도록 돕는다. 또한, TensorFlow나 Keras로 학습된 모델을 서빙하는 경우, 모델 저장 시 함께 생성된 서명 정의를 참조하여 입력 출력의 구조를 확인할 수 있어 클라이언트 개발이 용이하다.

TensorFlow Serving의 주요 장점은 프로덕션 환경에서 머신러닝 모델을 안정적으로 운영하는 데 필요한 핵심 기능들을 제공한다는 점이다. 첫째, 고성능을 지향하는 설계로, GPU 및 멀티코어 CPU를 효율적으로 활용하여 낮은 지연 시간과 높은 처리량을 달성한다. 이는 실시간 추론이 필요한 추천 시스템이나 이미지 인식 서비스에서 매우 중요하다.

둘째, 모델의 버전 관리를 내장하고 있어 무중단 서비스가 가능하다. 새로운 모델 버전을 배포할 때 서버를 재시작할 필요 없이, 클라이언트 요청은 기존 버전을 계속 사용하면서 새 버전을 점진적으로 롤아웃하거나 A/B 테스트를 수행할 수 있다. 이는 DevOps 및 MLOps 관행에 부합하는 중요한 기능이다.

셋째, TensorFlow 생태계와의 긴밀한 통합이 큰 장점이다. SavedModel 형식을 기본으로 지원하며, TensorFlow Extended(TFX)와 같은 파이프라인 도구와 자연스럽게 연동된다. 또한 Docker 컨테이너를 통한 배포가 용이하고, Kubernetes와 같은 오케스트레이션 플랫폼에서의 확장성을 갖추고 있어 현대적인 클라우드 네이티브 환경에 잘 적합하다.

TensorFlow Serving의 주요 단점은 복잡한 설정과 관리 절차에 있다. 초기 설치와 구성, 특히 다양한 운영 체제나 클라우드 환경에 맞춰 시스템을 세팅하는 과정이 상대적으로 번거롭다. 또한, gRPC 기반의 기본 API는 REST API에 비해 클라이언트 측 구현이 더 복잡할 수 있으며, HTTP/JSON을 통한 직접적인 요청을 위해서는 추가적인 설정이 필요하다.

또 다른 단점은 주로 TensorFlow 생태계에 밀접하게 연결되어 있다는 점이다. PyTorch나 ONNX 같은 다른 주요 머신러닝 프레임워크의 모델을 직접 서빙하기 위해서는 변환 과정이 필수적이며, 이 과정에서 호환성 문제가 발생할 수 있다. 이는 다중 프레임워크 환경을 운영하는 조직에게는 제약으로 작용할 수 있다.

리소스 사용 측면에서도 고려할 점이 있다. 특히 대규모 모델을 여러 버전으로 동시에 로드하여 서빙할 경우, 상당한 양의 메모리와 CPU 자원을 소비할 수 있다. 모델의 수와 크기에 따라 필요한 하드웨어 사양이 급격히 증가할 수 있어, 비용 효율적인 운영을 위해서는 신중한 용량 계획이 필요하다.

마지막으로, 고가용성과 고급 모니터링을 위한 기능은 기본적으로 완벽하게 제공되지 않는다. 프로덕션 환경에서의 안정적인 운영을 위해서는 로드 밸런서, 헬스 체크, 세분화된 메트릭 수집 및 로그 관리 시스템 등을 외부에 구축하여 TensorFlow Serving과 통합해야 하는 경우가 많다. 이는 전체 MLOps 파이프라인의 복잡성을 증가시키는 요인이 된다.