안녕하세요, Aiden’s Lab 뉴스레터입니다.
2026년에 들어서면서 MLflow 실습 가이드를 연달아 공유드렸습니다. 제가 MLflow를 학습하고 써보면서 얻은 지식을 저의 관점을 곁들여 이해하기 쉽게 전달해드리고 싶었거든요. 혹시 이전 아티클을 아직 안 보셨다면 꼭 확인해보세요. MLOps와 MLflow에 대해 더 깊이 이해하는 데에 도움이 될 겁니다.
MLflow는 모델 학습 과정에서 나오는 데이터(하이퍼파라미터, 성능지표, 학습된 모델 등)를 기록하고 저장하며 웹 UI로 보기 좋게 표시해줬는데요.
사실 MLOps 관점에서는 여기서 끝이 아닙니다. ML 모델을 개발했다면 실제 사용할 수 있도록 노출시키고 배포해야 진짜 의미가 있으니까요.
MLflow는 자체 기능으로 간단한 모델 서버를 만들어줘서 로컬 테스트를 도와줍니다.
하지만 중요한 건 실제 프로덕션 환경에서는 어떻게 배포하느냐입니다. 이 포인트가 이번 아티클을 작성하게 된 이유이기도 합니다.
본론부터 이야기하자면, MLflow에 저장된 모델을 Kubernetes 환경에 제대로 배포해서 프로덕션 수준으로 사용할 수 있으려면 KServe라는 툴을 활용하는 것이 좋습니다.
KServe는 LLM 모델부터 예측형 ML 모델까지 Kubernetes 환경에 쉽게 배포시켜주는 리소스인데요.
왜 ML 모델을 KServe로 배포하는 것이 좋은지부터 차근차근 알아보겠습니다. 툴을 쓰기 전에 왜 이걸 쓰면 좋은지를 알아야 하기 때문입니다.
모델 서버를 직접 구축하지 않고 KServe를 사용하는 이유?
아까 MLflow는 자체 모델 배포 기능을 제공한다고 했죠. 좀 더 자세히 이야기하자면, 저장된 ML 모델을 FastAPI라는 Python 기반 Rest API 서버로 노출시켜주는 건데요.
mlflow models serve라는 명령어를 실행하기만 하면 쉽게 추론 서버(Inference Server)를 만들 수 있는 거죠. 사용자는 해당 API 서버 URL로 예측을 원하는 데이터를 보내면 모델로부터 예측값을 받을 수 있게 됩니다. 편리하죠?
하지만 이 기능은 프로덕션 환경에서 사용하기엔 부적절합니다.
확장성을 염두에 두고 만들어진 것이 아니기 때문입니다.
사용자가 많지 않다면 ML 모델 추론 서버로 들어오는 요청도 그리 많지 않을 것입니다. 특히 로컬 테스트 환경에서 그러겠죠.
하지만 만약 프로덕션 환경이라면 어떨까요? 갑자기 요청 수가 폭등하는 경우가 비일비재할 겁니다.
이런 경우엔 추론 서버를 자동으로 늘려주는 오토스케일링이 필요한데, MLflow에서 만들어준 추론 서버는 오토스케일링되지 않습니다. 그래서 프로덕션에 맞지 않죠.
그러면 어떻게 해야 하냐고요? Amazon SageMaker와 같은 외부 클라우드 서비스를 이용하거나, Kubernetes 환경에서 KServe를 쓰는 겁니다.
외부 클라우드 서비스든 Kubernetes 클러스터든 핵심은 하나입니다. 추론 서버를 상황에 따라 유연하게 늘릴 수 있는 환경을 만들어주는 거죠.
그리고 저는 특정 클라우드에 종속되지 않는 벤더 중립을 선호하기 때문에, Kubernetes에서 활용할 수 있는 KServe로 여러분들과 함께 예측형 ML 모델을 배포해보려 합니다.
벤더 중립을 고려하는 이유?
어느 한 클라우드 벤더의 서비스를 계속 이용하다보면 문제가 발생합니다.
바로, 인프라를 다른 곳으로 옮기고 싶어도 옮길 수 없는 락인(Lock-in) 상태가 되는 것인데요.
이런 문제를 예방하고자 벤더 중립을 고려하는 것입니다.
KServe처럼 Kubernetes 네이티브한 툴은 나중에 다른 외부 클라우드의 Kubernetes 환경에서도 동일하게 사용할 수 있습니다.
참고로 KServe는 Scale-to-Zero를 지원한다는 점도 큰 특징인데요.
추론 서버로 향하는 트랙픽이 없을 경우 해당 Pod의 수를 0으로 줄일 수 있는 기능이기 때문에 비용에 민감한 프로덕션 환경에서 너무나 중요하겠죠.
마지막으로, KServe로 배포되는 추론 서버는 Kubernetes 클러스터에 리소스로 배포되기 때문에 예기치 못한 문제가 발생하더라도 자동으로 재시작되어 자가 치유(Self-healing)를 시도할 수 있게 됩니다. Kubernetes의 장점을 활용할 수 있는 것입니다.
KServe와 기존의 모델 서버 구축 방식을 비교하면서 알아봤는데요. 이제 KServe가 동작하는 핵심 원리에 대해 살펴보겠습니다.
KServe의 핵심 - InferenceService
KServe가 왜 좋은지 알았으니, 이제 어떻게 ML 모델을 배포해서 사용자에게 노출시켜주는지 알아보겠습니다.
KServe의 InferenceService가 바로 그 주인공인데요. 추론(Inference) + (Kubernetes) Service라는 이름이 직관적이죠?
InferenceService는 ML 모델 유형과 학습된 ML 모델이 저장된 URI만 지정해서 배포하면 ML 모델을 바로 서빙해줘서 편리한데요.
ML 모델 서빙뿐만 아니라 여러 세부 설정을 줘서 오토 스케일링과 트래픽 관리 기능도 지원하는 스마트한 리소스랍니다.
KServe는 Helm으로 편하게 배포할 수 있는데요. 이때 다양한 KServe의 CRD(Custom Resource Definition)가 설치되면서 InferenceService의 CRD도 함께 설치되었기 때문에 원하는 설정의 매니페스트로 InferenceService 리소스를 배포할 수 있는 겁니다.
CRD가 뭐였더라...
CRD(Custom Resource Definition)는 사용자가 정의한 새로운 리소스 타입을 배포해서 사용할 수 있도록 미리 정의해둔 명세서입니다.
Kubernetes는 Pod와 Deployment, Service 등 기본 제공하는 리소스가 여러가지 있는데요.
특수한 상황에 맞춘 새로운 리소스 타입을 누구나 정의할 수 있는 것이 바로 CRD입니다.
KServe가 설치되면서 InferenceService CRD도 함게 배포되었다는 것은, 나중에 이 CRD를 통해 실제 InferenceService 리소스를 생성해서 클러스터에 배포할 수 있다는 뜻입니다.
정의된 CRD는 kubectl get InferenceService와 같은 명령어로 기존 Kubernetes 리소스와 동일하게 관리할 수 있습니다.
ML 모델은 유형에 따라 동작할 수 있는 환경이 모두 다르죠. KServe는 다양한 ML 모델이 동작되는 환경을 Runtime이라는 리소스로 미리 정의해두는데요. Kubernetes 클러스터 안에서 네임스페이스에 상관없이 사용할 수 있는 ClusterServingRuntime 리소스가 배포됩니다.
그래서 KServe가 설치된 클러스터에서 어떤 ML 모델 유형을 지원하는지 알고 싶다면 kubectl 명령어로 직접 확인할 수 있습니다.
KServe가 기본으로 지원하는 ML 모델 유형은 Hugging Face부터 Scikit-Learn(sklearn), Tensorflow까지 다양합니다.
마무리
이번 아티클에서 여러분은...
KServe가 무엇이고
기존의 직접 ML 모델 서버를 구축하는 방식과 KServe가 어떤 차이점이 있고
KServe의 핵심 리소스인 InferenceService가 어떤 역할을 수행하는지까지
이해하셨습니다.
KServe가 다루는 주제가 워낙 방대하지만, 너무나 많은 조직과 회사에서 사용하다보니 소개하지 않을 수 없었습니다. 그래서 KServe의 장점과 동작 원리를 핵심만 간추려서 정리했는데요.
다음 아티클에서는 KServe를 직접 사용해보실 수 있도록 로컬 Kubernetes 환경(Kind)에서 배포해보는 실습 가이드를 공유드리겠습니다.
이번 아티클도 읽어주셔서 감사합니다.
오늘도 행복한 하루 되세요😸
함께 읽어보면 좋은 아티클
✨이번 뉴스레터는 어떠셨나요?
이번 글에서 다룬 주제에 대해 어떻게 생각하는지 알려주세요! 뉴스레터를 더 나은 방향으로 개선하기 위해 아래 폼에서 짧은 피드백을 받고 있어요.
👉 피드백 보내기 (1~2분 소요)
여러분들의 소중한 의견은 Aiden’s Lab 뉴스레터에게 큰 힘이 됩니다!
🔭Aiden’s Lab에서 더 많은 아티클을 만나보세요
발행된 뉴스레터를 아카이빙하고 다양한 정보를 공유하는 기술 블로그를 운영 중입니다.
