기존 ML 플랫폼에 LLM 서빙을 통합하는 설계

기존 서빙 체계에 생성형 추론을 붙이는 이유

Netflix AI Platform의 Model Runtime 팀은 사내 LLM 서빙을 별도 스택으로 만들지 않고 기존 Model Scoring Service(MSS)에 통합한 구조를 공개했다. 추천과 랭킹을 위한 전통 ML 서빙 인프라에 생성형 추론을 함께 수용하는 접근이다.

이 선택은 호스팅 API 의존과는 다른 방향이다. 추론 스택을 사내에서 운영하면서 낮은 지연, 깊은 커스터마이징, 기존 프로덕션 인프라와의 결합을 근거로 삼았다. MSS에는 vLLM을 추론 엔진으로 연결하고 NVIDIA Triton Inference Server를 결합했다. 인터페이스는 gRPC와 OpenAI 호환 HTTP API를 함께 제공한다.

기존 JVM 서빙 계층은 라우팅, 피처 조회, 후보 생성, 후처리, 로깅을 계속 맡는다. 작은 모델은 CPU 인프로세스에서 실행하고, 큰 요청은 MSS로 넘긴다. MSS에서는 Triton이 모델 적재, 배칭, GPU 스케줄링, 멀티프레임워크 서빙을 담당한다.

초기 구성은 TensorRT-LLM 기반이었다. 그러나 2025년 여름 시점에는 오픈소스 엔진과 전용 스택의 성능 격차가 상당 부분 좁혀졌고, 워크로드도 임베딩 생성, 랭킹용 프리필 전용 추론, 자기회귀 디코딩, 커스텀 제약 로직 모델로 넓어졌다. 이 변화가 엔진 선택을 다시 검토하게 한 배경이다.

공통 운영 계층은 유지하고 추론 계층만 바꾼다

전통 ML 모델과 LLM을 같은 모델 레지스트리에 등록하면 버전, 메타데이터, 소유자를 한 흐름으로 관리할 수 있다. 모델 유형에 따라 달라지는 것은 배포 대상 런타임이다. 어떤 모델이 어느 위치에 배포됐는지 확인할 수 있어 감사와 계보 추적에도 유리하다.

배포와 롤아웃도 기존 ML 모델의 절차를 재사용한다. LLM 전용 절차를 별도로 만들지 않는 것이 운영 표면적을 줄이는 핵심이다. 다만 아티팩트 크기와 워밍업 시간은 달라질 수 있으므로 파이프라인의 타임아웃과 준비 프로브 설정은 조정해야 한다.

라우팅은 JVM 서빙 계층에서 처리한다. 요청 특성에 맞춰 CPU 인프로세스 실행과 MSS 위임을 가르고, 소형 모델을 인프로세스로 실행해 네트워크 왕복을 제거한다. 모든 추론을 원격 서비스로 보내는 구성이 항상 맞는 것은 아니다.

Triton의 백엔드 구조는 추론 엔진을 바꾸는 경계를 제공한다. vLLM을 백엔드로 두면 LLM 특유의 배치 전략을 유지하면서도 상위의 배포와 관측 체계를 공유할 수 있다. TensorRT-LLM에서 vLLM으로 이동하는 일도 플랫폼 전체를 다시 만드는 대신 백엔드를 교체하는 문제가 된다.

⤢✕

GPU와 관측성에서 달라지는 운영 기준

Triton이 모델 적재와 GPU 스케줄링을 맡으면 여러 모델을 같은 GPU에 배치할 수 있다. 이때 오토스케일링은 CPU 사용률보다 큐 대기 시간과 GPU 메모리 여유율을 기준으로 삼아야 의미가 있다.

추천·랭킹 모델과 LLM이 동일 GPU를 공유할 때는 지연 간섭이 생길 수 있다. 지연에 민감한 워크로드는 전용 인스턴스 그룹으로 분리하고, 격리는 GPU 단위로 두는 편이 현실적이다. 단일 GPU 안에서의 분할 공유는 관리 복잡도에 비해 이득이 작을 수 있다.

기존 ML 플랫폼의 메트릭, 로깅, 트레이싱은 그대로 쓸 수 있다. LLM에는 토큰 처리량, TTFT, 캐시 적중률 같은 지표를 추가한다. A/B 트래픽 분기 역시 기존 실험 체계에서 재사용하면 모델 교체 실험을 새로운 운영 경로로 분리하지 않아도 된다.

플랫폼 팀은 런타임, 엔진, GPU 스케줄링을 맡고 제품 팀은 모델 선택, 프롬프트, 평가를 담당하는 경계가 실무적이다. 이 경계가 흐려지면 성능 문제의 책임 소재가 불분명해져 대응이 늦어진다.

통합 범위는 기존 플랫폼의 한계부터 확인한다

재사용 가능한 영역은 모델 레지스트리, 배포 파이프라인, 트래픽 관리, 관측성, A/B 실험 체계다. 이들은 대체로 모델 유형에 의존하지 않는다. 반면 추론 엔진, 배치 전략, GPU 메모리 관리는 LLM 고유 요구가 강해 별도 계층이 필요하다.

토큰 단위 스트리밍 응답, KV 캐시 관리, 가변 길이 배치, 프리필·디코드 분리는 기존 ML 서빙에 없던 요구다. 이 요구 목록을 먼저 만들고 기존 플랫폼이 처리하지 못하는 부분을 확인해야 통합 범위를 정할 수 있다.

새 경로는 그림자 트래픽으로 검증한 뒤 소수 비중의 실트래픽을 거쳐 점진적으로 확대하고, 마지막에 구 경로를 제거한다. TensorRT-LLM에서 vLLM으로 옮기는 유형의 엔진 전환은 성능 회귀 위험이 있으므로 벤치마크 기준을 사전에 고정하고 단계별로 비교한다.

LLM의 SLO는 전통 ML과 다른 방식으로 정의한다. 요청당 지연만이 아니라 TTFT, 토큰 간 지연, 동시성 조건부 지연을 포함한다. 모델 버전, 엔진 버전, 양자화 설정은 형상관리 대상으로 등록하고 변경 승인 절차를 명시한다.

통합과 전용 스택의 선택 기준

구분	기존 ML 플랫폼 통합	LLM 전용 스택 신설
초기 구축 속도	빠름 (재사용)	느림
운영 표면적	단일 체계	이중 체계
LLM 고유 최적화	백엔드 계층에 한정	전 계층 자유
조직 학습 비용	낮음	높음
자원 효율	공유로 향상	격리로 안정
적합 상황	성숙한 ML 플랫폼 보유	플랫폼 부재·LLM 전용 조직

기존 ML 플랫폼을 통합 대상으로 삼으면 모델 등록, 배포, 관측 체계를 그대로 활용할 수 있어 구축 속도와 운영 부담에서 앞선다. 반대로 LLM 전용 스택은 LLM 요구에 맞춰 전 계층을 자유롭게 설계할 수 있지만, 조직은 두 개의 배포 및 관측 체계를 관리하게 된다.

성숙한 ML 플랫폼을 이미 가진 조직에는 통합이 명확히 유리하다. 플랫폼 자체가 없는 조직이 같은 형태를 흉내 내면 기존 플랫폼과 LLM 플랫폼을 동시에 만드는 결과가 된다.

자체 서빙은 지연 통제, 커스텀 디코딩 로직, 데이터 경계 유지에서 강점이 있다. 관리형 추론 서비스는 초기 투자와 운영 인력이 필요 없고, 모델 갱신을 벤더가 처리한다. Netflix 사례에서 자체 서빙의 근거는 비용이 아니라 낮은 지연, 깊은 커스터마이징, 기존 인프라 통합이었다.

단일 플랫폼으로 표준화하면 관측, 감사, 자원 배분을 일관되게 운영하고 중복 투자를 줄일 수 있다. 팀별 개별 배포는 초기에는 빠르지만 GPU가 팀 단위로 파편화되어 전체 활용률이 떨어진다. GPU가 희소 자원인 상황에서 파편화 비용은 조직 규모에 비례해 커진다.

표준화가 만드는 운영 거버넌스

신기술을 기존 시스템에 통합할지 대체할지는 재사용 가능한 공통 계층의 크기에 달려 있다. 모델 서빙에서는 레지스트리, 배포, 관측이 그 공통 계층에 해당한다. 통합의 이익은 기술 효율뿐 아니라 운영 인력의 학습 부담을 줄이는 데서도 나온다.

Triton 같은 표준 추론 서버와 OpenAI 호환 HTTP 같은 표준 인터페이스를 채택하면 내부 표준과 외부 도구 생태계를 함께 수용할 수 있다. 표준화에는 최적화 자유도의 일부를 포기하는 대가가 따르며, 백엔드 플러그인 구조는 그 대가를 줄이는 장치다.

모델 유형이 늘어나도 배포, 승인, 감사 절차가 하나로 유지되는 점이 통합 아키텍처의 거버넌스 가치다. GPU 자원 배분 정책도 플랫폼 차원에서 정의해야 팀 간 자원 경쟁을 기술 문제가 아니라 정책 문제로 다룰 수 있다.

2026년에 예상되는 플랫폼 방향

이미 ML 플랫폼을 보유한 대규모 조직에서는 LLM을 별도 스택이 아니라 기존 플랫폼의 확장으로 받아들이는 방식이 표준 경로로 정착할 전망이다. 오픈소스 추론 엔진이 벤더 최적화 런타임과 대등해지면서 엔진 선택 기준도 성능에서 확장성과 디버깅 용이성으로 이동할 전망이다.

OpenAI 호환 HTTP 인터페이스는 사내 플랫폼의 사실상 표준 외부 인터페이스로 자리잡는 흐름이다. GPU 자원 파편화를 막기 위한 중앙 집중 스케줄링과 쿼터 정책도 플랫폼 필수 기능으로 편입될 전망이다.