Skip to content
Published on

오픈소스 ML 플랫폼 & MLOps 2026 완벽 가이드 - Kubeflow · Metaflow · Flyte · ZenML · MLflow · BentoML · ClearML · DVC · Weights & Biases 심층 분석

🇰🇷KO🇺🇸EN🇯🇵JA
Split View필사 모드
Authors

들어가며 — 2026년 5월, MLOps는 "표준 레이어"가 굳어졌다

2023년까지만 해도 MLOps 스택은 "여러분 회사에 맞는 거 골라 쓰세요"의 영역이었다. 2026년 5월 현재, 그 모호함은 상당 부분 걷혔다. 실험 추적은 MLflow와 Weights & Biases가 양분하고, K8s 네이티브 오케스트레이션은 Kubeflow Pipelines와 Flyte가, 파이썬 우선 워크플로는 Metaflow와 ZenML이, 서빙은 BentoML 1.4, KServe, Triton이, 데이터 버저닝은 DVC와 lakeFS가 각자 영역을 굳혔다.

이 글은 마케팅 매트릭스가 아니라 "지금 프로덕션에서 무엇이 어떤 자리에 들어가는가"를 정직하게 짚는다. MLflow 3.0의 변화, Kubeflow 1.10 라인업, Flyte의 Union.ai 상용화, ZenML 클라우드, BentoML 1.4의 LLM 서빙 모드까지 실제 API 형태와 함께 비교한다.

MLOps 2026 스택 — 7개 레이어로 분해하기

먼저 큰 그림이다. 2026년 표준 MLOps 스택은 다음 7개 레이어로 나뉜다.

  1. 실험 추적(experiment tracking): 런(run), 파라미터, 메트릭, 아티팩트 기록
  2. 파이프라인 오케스트레이션(orchestration): DAG 실행, 분산, 캐싱
  3. 모델 레지스트리(model registry): 모델 버전, 스테이지, 메타데이터
  4. 모델 서빙(serving): 온라인/배치/스트리밍 추론
  5. 피처 스토어(feature store): 학습/추론 간 일관된 피처
  6. 데이터/실험 버저닝(versioning): 데이터셋과 코드 동기화
  7. ML 모니터링(monitoring): 드리프트, 성능 저하, 데이터 품질

각 레이어를 한 두 도구가 담당하면 됐던 시대는 끝났다. 지금은 레이어 안에서도 LLM-specific 트랙과 클래식 ML 트랙이 갈라진다. 아래부터 한 레이어씩 본다.

실험 추적 — MLflow 3.0과 Weights & Biases가 양분하는 시장

실험 추적 레이어의 90%는 두 도구가 차지한다.

  • MLflow 3.0: Databricks가 만들고 Linux Foundation 산하로 옮긴 OSS. 2026년 1분기 3.0 라인업이 GA. GenAI 트레이싱, 평가(eval), 프롬프트 레지스트리가 1급 시민이 됐다.
  • Weights & Biases: SaaS 우선이지만 SDK는 오픈. UX/시각화에서 압도적 우위. W&B Models, W&B Weave(LLM 트레이싱), W&B Launch까지 한 묶음.

대안군도 적지 않다.

  • Comet ML: ML + LLM 실험 + 프로덕션 모니터링까지 통합한 SaaS.
  • Neptune.ai: foundation model 학습용 메타데이터 스토어로 포지셔닝 강화.
  • Aim: Apache 2.0 OSS. 자체 호스팅과 빠른 UI가 장점.
  • TensorBoard, PyTorch Lightning Logger: 단독 실험 추적기로는 한계가 있어 위 도구들과 결합해 쓴다.

MLflow 3.0의 전형적 사용 코드는 다음과 같다.

import mlflow
import mlflow.sklearn
from sklearn.ensemble import RandomForestClassifier
from sklearn.datasets import load_iris

mlflow.set_tracking_uri("http://mlflow.internal:5000")
mlflow.set_experiment("iris-rf-2026")

X, y = load_iris(return_X_y=True)

with mlflow.start_run() as run:
    mlflow.log_param("n_estimators", 200)
    model = RandomForestClassifier(n_estimators=200)
    model.fit(X, y)
    mlflow.log_metric("train_acc", model.score(X, y))
    mlflow.sklearn.log_model(model, artifact_path="model", registered_model_name="iris-rf")
    print(run.info.run_id)

같은 흐름을 W&B로 쓰면 다음과 같다.

import wandb
from sklearn.ensemble import RandomForestClassifier
from sklearn.datasets import load_iris

wandb.init(project="iris-rf-2026", config={"n_estimators": 200})
X, y = load_iris(return_X_y=True)
model = RandomForestClassifier(n_estimators=200).fit(X, y)
wandb.log({"train_acc": model.score(X, y)})
wandb.finish()

두 도구 모두 자동 instrumentation(scikit-learn, PyTorch, XGBoost 등)을 가지고 있어서, 명시적 로깅을 안 해도 기본 메트릭은 잡힌다. 차이는 저장 모델과 거버넌스다. MLflow는 자체 호스팅이 기본이고 BSD 라이선스 친화적이고, W&B는 SaaS 우선이지만 협업 UX가 훨씬 매끄럽다.

파이프라인 오케스트레이션 — K8s 네이티브 vs Python 우선

ML 파이프라인은 단순 ETL과 달리 GPU 자원 스케줄링, 캐싱, 재현성을 함께 다뤄야 한다. 2026년 5월 기준 4개 도구가 시장을 갈라 가진다.

  • Kubeflow Pipelines + Kubeflow 1.10: CNCF 인큐베이션 프로젝트. K8s 네이티브 ML 플랫폼의 정석. 컴포넌트는 컨테이너 단위.
  • Metaflow: Netflix가 만들고 Outerbounds가 상용화. Python decorator-first. AWS Batch/Step Functions과 깊이 통합.
  • Flyte: Lyft가 만들고 Union.ai가 상용화. LF AI & Data 산하. K8s 네이티브 + 타입 안전.
  • ZenML: 프레임워크 무관, "추상화 레이어" 포지셔닝. MLflow/W&B/Kubeflow/Airflow를 백엔드로 끼움.

부수적으로 Prefect, Dagster, Airflow도 ML 워크플로에 쓰이지만, ML 특화가 아닌 일반 데이터 오케스트레이션 도구라 별도 글(iter72/53)에서 다룬다.

DSL 친화도는 대체로 ZenML > Metaflow > Flyte > Kubeflow Pipelines 순이다. Python 코드 한 파일로 끝낼 수 있느냐가 기준이다.

Kubeflow 1.10 — K8s 위에 풀스택 ML 플랫폼

Kubeflow는 단일 도구가 아니라 K8s 위에 올린 풀스택 ML 플랫폼이다. 2026년 5월 1.10 라인업의 핵심 컴포넌트는 다음과 같다.

  • Kubeflow Pipelines (KFP): DAG 파이프라인 SDK + UI.
  • Katib: 분산 하이퍼파라미터 튜닝.
  • Training Operator: PyTorchJob, TFJob, MPIJob, PaddleJob 분산 학습 CRD.
  • KServe: 모델 서빙(전 KFServing). 별도 프로젝트로 분리되었으나 통합.
  • Notebook Controller: JupyterHub 스타일 노트북 인스턴스.
  • Spark Operator, Volcano: 배치 스케줄링.

KFP 2.x DSL 예시는 다음과 같다.

from kfp import dsl, compiler

@dsl.component(base_image="python:3.12")
def preprocess(input_path: str, output_path: str):
    import pandas as pd
    df = pd.read_csv(input_path)
    df.dropna().to_csv(output_path, index=False)

@dsl.component(base_image="python:3.12", packages_to_install=["scikit-learn"])
def train(data_path: str) -> float:
    import pandas as pd
    from sklearn.ensemble import RandomForestClassifier
    df = pd.read_csv(data_path)
    X, y = df.drop("label", axis=1), df["label"]
    return RandomForestClassifier().fit(X, y).score(X, y)

@dsl.pipeline(name="iris-pipeline")
def pipeline(input_path: str = "/data/iris.csv"):
    pre = preprocess(input_path=input_path, output_path="/tmp/clean.csv")
    train_task = train(data_path=pre.outputs["output_path"])

compiler.Compiler().compile(pipeline, "iris.yaml")

Kubeflow는 K8s를 운영할 줄 알면 강력하지만, 진입 비용이 가장 높다. 그래서 매니지드(GCP Vertex AI Pipelines, AWS SageMaker MLOps, Azure ML)로 채택하는 경우가 많다.

Metaflow — Python decorator 한 줄로 시작하는 워크플로

Metaflow는 Netflix가 데이터 사이언티스트 친화적으로 설계한 워크플로 라이브러리다. Outerbounds가 상용 호스팅을 제공하지만 코어는 Apache 2.0이다.

핵심 추상은 단순하다.

  • FlowSpec: 워크플로 클래스.
  • @step: 단계 데코레이터.
  • self.next(...): 명시적 분기.
  • @batch, @kubernetes, @gpu: 단계별 실행 환경 데코레이터.
  • @retry, @timeout, @catch: 신뢰성 데코레이터.

전형적 Metaflow 코드는 다음과 같다.

from metaflow import FlowSpec, step, batch, retry

class IrisFlow(FlowSpec):
    @step
    def start(self):
        from sklearn.datasets import load_iris
        self.X, self.y = load_iris(return_X_y=True)
        self.next(self.train)

    @batch(cpu=4, memory=16000)
    @retry(times=2)
    @step
    def train(self):
        from sklearn.ensemble import RandomForestClassifier
        self.model = RandomForestClassifier(n_estimators=200).fit(self.X, self.y)
        self.acc = self.model.score(self.X, self.y)
        self.next(self.end)

    @step
    def end(self):
        print(f"acc={self.acc:.3f}")

if __name__ == "__main__":
    IrisFlow()

Metaflow의 강점은 로컬-우선이다. 노트북에서 그대로 돌리고, --with batch만 추가하면 AWS Batch로 분산된다. 자동 아티팩트 저장(S3) + 자동 추적이 기본이라 별도 MLflow가 필요 없는 경우도 많다.

Flyte — Kubernetes 네이티브 타입 안전 워크플로

Flyte는 Lyft가 만들고 Union.ai가 상용화한 K8s 네이티브 워크플로다. LF AI & Data Foundation 산하 그라데이션 프로젝트다. 가장 큰 특징은 타입 안전성과 캐싱이다.

  • Python 타입 어노테이션이 곧 입출력 스키마.
  • 자동 캐싱: 같은 입력은 자동으로 캐시 hit. 비용 절감 효과 큼.
  • K8s 네이티브: Pod, Deployment, GPU/TPU 스케줄링 1급 시민.
  • 다중 언어: Python이 1차, Java/Scala도 SDK 있음.

Flyte 코드 예시는 다음과 같다.

from flytekit import task, workflow, Resources

@task(cache=True, cache_version="1.0", requests=Resources(cpu="2", mem="4Gi"))
def preprocess(input_path: str) -> str:
    import pandas as pd
    df = pd.read_csv(input_path).dropna()
    out = "/tmp/clean.csv"
    df.to_csv(out, index=False)
    return out

@task(requests=Resources(cpu="4", mem="16Gi", gpu="1"))
def train(data_path: str) -> float:
    import pandas as pd
    from sklearn.ensemble import RandomForestClassifier
    df = pd.read_csv(data_path)
    X, y = df.drop("label", axis=1), df["label"]
    return RandomForestClassifier().fit(X, y).score(X, y)

@workflow
def iris_wf(input_path: str = "/data/iris.csv") -> float:
    clean = preprocess(input_path=input_path)
    return train(data_path=clean)

Flyte의 강점은 K8s 친화 + 캐싱이 진짜로 잘 동작한다는 것이다. 같은 데이터로 같은 코드를 돌리면 자동으로 캐시 hit가 되어 시간/비용이 절감된다.

ZenML — 프레임워크 무관 추상화 레이어

ZenML은 위 도구들과 직접 경쟁하기보다 그들 위의 추상화 레이어를 자처한다. ZenML Pipelines는 백엔드로 Kubeflow, Airflow, Tekton, Vertex, SageMaker, AWS Step Functions 등을 끼울 수 있다.

핵심 추상은 다음과 같다.

  • @step, @pipeline: Python decorator로 단계와 파이프라인 정의.
  • Stack: orchestrator + artifact_store + container_registry + experiment_tracker를 묶은 환경.
  • Component: 각 레이어의 구현체. MLflow, W&B, Neptune.ai, Kubeflow, Vertex 등을 교체 가능.
  • Materializer: 사용자 타입 직렬화 정의.

ZenML 코드는 다음과 같다.

from zenml import pipeline, step
from typing import Tuple
import pandas as pd

@step
def load() -> pd.DataFrame:
    import pandas as pd
    return pd.read_csv("/data/iris.csv")

@step
def split(df: pd.DataFrame) -> Tuple[pd.DataFrame, pd.DataFrame]:
    return df.iloc[:120], df.iloc[120:]

@step
def train(train_df: pd.DataFrame) -> float:
    from sklearn.ensemble import RandomForestClassifier
    X, y = train_df.drop("label", axis=1), train_df["label"]
    return RandomForestClassifier().fit(X, y).score(X, y)

@pipeline
def iris_pipeline():
    df = load()
    tr, _ = split(df)
    train(tr)

iris_pipeline()

ZenML의 강점은 벤더 락인을 미루는 능력이다. 로컬 → SageMaker → Kubeflow로 점진적으로 옮길 때 코드 변경이 거의 없다. 단점은 추상화 비용 — 백엔드 고유 기능을 100% 사용하려면 결국 백엔드 SDK를 직접 호출하게 된다.

모델 레지스트리 — MLflow Registry vs BentoML Model Store vs Hugging Face Hub

학습된 모델은 어딘가에 저장되어 버전, 스테이지(Staging/Production), 메타데이터를 추적해야 한다. 2026년 5월 기준 세 후보가 자주 등장한다.

  • MLflow Model Registry: MLflow와 묶여 가장 표준에 가깝다. models:/name/Production URI 패턴.
  • BentoML Model Store: BentoML 서빙과 결합. bentoml.transformers.save_model() 흐름.
  • Hugging Face Hub: 공개/비공개 레포로 모델 공유. 트랜스포머/디퓨전 생태계의 사실상 표준.

엔터프라이즈는 보통 MLflow Model Registry + 자체 S3 스토리지 조합을 가장 많이 쓰고, 오픈모델 + LLM 환경은 Hugging Face Hub private repo를, BentoML 운영팀은 BentoML Model Store를 그대로 쓴다.

MLflow Registry 사용은 다음과 같다.

import mlflow.pyfunc

model_uri = "models:/iris-rf/Production"
model = mlflow.pyfunc.load_model(model_uri)
predictions = model.predict([[5.1, 3.5, 1.4, 0.2]])

모델 서빙 — BentoML 1.4, KServe, Triton, Ray Serve의 분담

모델 서빙은 한 도구가 모든 케이스를 커버하지 못한다. 시나리오에 따라 도구가 갈린다.

  • BentoML 1.4 + Yatai: 파이썬 친화 서빙 프레임워크. 모델 + 비즈니스 로직을 하나의 "Bento"로 패키징. 2026년 1분기 1.4에서 LLM 서빙 모드(vLLM, TGI 백엔드 통합)가 GA.
  • Seldon Core 2: K8s 네이티브 서빙. 메시 기반 멀티 모델 라우팅.
  • KServe: 전 KFServing. Kubeflow와 함께 자주 쓰이지만 독립도 가능. 서버리스/오토스케일 + 표준 추론 프로토콜.
  • TorchServe: Meta + AWS 협력. PyTorch 모델 서빙 표준.
  • TensorFlow Serving: TF SavedModel 서빙. C++ 기반 안정.
  • NVIDIA Triton Inference Server: GPU 최적 서빙. TensorRT, ONNX, PyTorch, TF, vLLM 백엔드 통합.
  • Ray Serve: Ray 클러스터 위의 파이썬 서빙. Anyscale 매니지드.

BentoML 1.4 LLM 서빙 코드는 다음과 같다.

import bentoml
from transformers import AutoTokenizer

@bentoml.service(resources={"gpu": 1, "memory": "16Gi"})
class LlamaService:
    def __init__(self) -> None:
        from vllm import LLM
        self.llm = LLM(model="meta-llama/Llama-3.3-70B-Instruct")
        self.tokenizer = AutoTokenizer.from_pretrained("meta-llama/Llama-3.3-70B-Instruct")

    @bentoml.api
    def generate(self, prompt: str, max_tokens: int = 256) -> str:
        outputs = self.llm.generate([prompt], sampling_params={"max_tokens": max_tokens})
        return outputs[0].outputs[0].text

LLM이 아닌 클래식 모델은 TF Serving, TorchServe, Triton이 더 빠르고 안정적이다. LLM 추론은 vLLM/SGLang/TGI/TensorRT-LLM(iter69에서 다룬 인퍼런스 엔진)을 BentoML이나 Triton 백엔드로 끼우는 패턴이 표준이다.

피처 스토어 — Feast 0.40, Hopsworks, Featureform, Tecton

피처 스토어는 학습 시점과 추론 시점에 동일한 피처가 나가도록 보장하는 레이어다.

  • Feast 0.40: Apache 2.0 OSS. K8s 또는 로컬 배포. 온라인 스토어로 Redis, DynamoDB, Bigtable 지원.
  • Hopsworks: 오픈 코어. 자체 호스팅과 SaaS 모두 제공. 피처 스토어 + 노트북 + 서빙 통합.
  • Featureform: 가상화 레이어. 기존 데이터 웨어하우스를 피처 스토어처럼 추상화.
  • Tecton: 상용 SaaS. Feast 출신 팀이 만든 동일 계보. 엔터프라이즈에서 자주 채택.

Feast 0.40 정의 예시는 다음과 같다.

from feast import Entity, FeatureView, Field, FileSource
from feast.types import Float32, Int64
from datetime import timedelta

user = Entity(name="user", join_keys=["user_id"])

user_stats_source = FileSource(
    path="s3://feast-data/user_stats.parquet",
    timestamp_field="event_ts",
)

user_stats_view = FeatureView(
    name="user_stats",
    entities=[user],
    ttl=timedelta(days=7),
    schema=[
        Field(name="purchase_count_7d", dtype=Int64),
        Field(name="purchase_value_7d", dtype=Float32),
    ],
    source=user_stats_source,
)

피처 스토어 도입은 항상 마지막 단계로 미루기 쉽다. 그러나 "학습-추론 일관성"이 깨져 사고가 났다면 그때부터는 필수다.

데이터 + 실험 버저닝 — DVC, lakeFS, Pachyderm, Quilt

코드는 Git이 책임지지만 데이터는 그렇지 않다. 데이터 버저닝 도구는 다음 네 가지가 시장을 갈라 가진다.

  • DVC (Data Version Control): Git 위의 데이터/모델 버저닝. .dvc 메타파일로 큰 파일을 추적, 실제 데이터는 S3/GCS/Azure에 저장.
  • lakeFS: 데이터 레이크를 위한 Git 모델. 브랜치, 머지, 커밋이 페타바이트 규모 S3에서도 작동.
  • Pachyderm: 데이터 버저닝 + 데이터 리니지 + 자동 파이프라인 트리거.
  • Quilt Data: 데이터 패키지 카탈로그.

DVC 흐름은 다음과 같다.

git init
dvc init
dvc remote add -d storage s3://my-bucket/dvc

dvc add data/raw/train.csv
git add data/raw/train.csv.dvc .gitignore
git commit -m "track training data"

dvc push   # 데이터는 S3로
git push   # 메타데이터는 Git으로

DVC의 또 다른 강점은 DVC Pipelines다. dvc.yaml로 단계 정의 + 의존성을 명시하면 변경된 단계만 재실행한다. 적은 인프라로 재현 가능한 ML 워크플로를 만들 수 있다.

ML 모니터링 — Evidently, Arize, WhyLabs, Fiddler

모델은 배포 후 데이터가 변하면 성능이 떨어진다(데이터/콘셉트 드리프트). 모니터링은 이를 잡는 레이어다.

  • Evidently AI: Apache 2.0 OSS. 리포트와 대시보드를 파이썬으로 생성. K8s 위 self-host 가능.
  • Arize AI: 상용 SaaS. ML + LLM 관측성 통합. Phoenix가 OSS 분파.
  • WhyLabs: 데이터 품질 + 드리프트 + 이상 탐지. 무료 티어 존재.
  • Fiddler AI: 설명 가능성(XAI) 강조. 엔터프라이즈 컴플라이언스 트랙.

Evidently 사용 예시는 다음과 같다.

import pandas as pd
from evidently.report import Report
from evidently.metric_preset import DataDriftPreset

ref = pd.read_csv("reference.csv")
cur = pd.read_csv("current.csv")

report = Report(metrics=[DataDriftPreset()])
report.run(reference_data=ref, current_data=cur)
report.save_html("drift.html")

모니터링은 "처음에 만들기 쉬운데 운영에서 노이즈가 많아 끄는" 경우가 많다. 알람 임계치 튜닝과 대시보드 사용자 정의가 더 중요해진다.

노트북 & IDE — Jupyter, Marimo, Hex, Deepnote, Quarto

ML 워크플로의 시작점은 여전히 노트북이다.

  • Jupyter / JupyterLab 4 / JupyterHub: 사실상 표준. 멀티 사용자는 JupyterHub. iter27 노트북 심층 분석에서 별도로 다룬다.
  • Marimo: 반응형 노트북. 셀 실행 순서가 의존성 그래프로 결정. 재현성 강함.
  • Hex, Deepnote: 매니지드 협업 노트북.
  • Quarto: 노트북 + Markdown을 보고서/책/사이트로 변환.

Marimo의 차별점은 명확하다. 셀 간 의존성이 코드 분석으로 추출되므로, 순서 의존 버그가 줄어든다. 데이터 사이언티스트가 README를 안 봐도 되도록 만든 노트북이라고 보면 된다.

벡터 DB 통합 — Pinecone, Weaviate, Milvus, Qdrant

RAG와 임베딩 워크플로를 다루려면 벡터 DB가 필수다. iter62에서 벡터 DB 자체를 자세히 다루지만, MLOps 관점에서 핵심은 모델 서빙과의 통합이다. BentoML, Ray Serve, KServe 모두 벡터 DB 클라이언트와 함께 묶어 패키징하는 패턴을 표준화하고 있다.

특히 LangChain/LlamaIndex 같은 LLM 프레임워크와 결합되면 벡터 DB는 더 이상 "별도 인프라"가 아니라 "ML 서비스의 1급 컴포넌트"가 된다.

E2E "MLflow 스타일" 매니지드 플랫폼

자체 호스팅이 부담스러우면 매니지드를 쓴다.

  • Databricks Lakehouse Platform: MLflow 원작자. 노트북 + Spark + MLflow + Unity Catalog 통합.
  • Vertex AI: Google. AutoML, Pipelines, Endpoints, Feature Store 통합.
  • SageMaker: AWS. Studio, Pipelines, Model Registry, Endpoints 통합.
  • Azure ML: Microsoft. Workspace + Designer + Endpoints + Responsible AI 통합.

각 매니지드 플랫폼은 자체 SDK를 강요하지만, 동시에 MLflow/Kubeflow Pipelines/PyTorch/TensorFlow와 호환되는 표준 진입점을 제공한다. 매니지드의 장점은 인프라 부담 0이고, 단점은 벤더 락인이다.

LLM-specific MLOps (LLMOps) — LangSmith, Langfuse, Arize Phoenix, Helicone

2024-2025년에 걸쳐 "LLMOps"라는 하위 카테고리가 형성됐다. 클래식 MLOps와 겹치지만, 다음이 다르다.

  • 트레이스 단위: 메트릭 대신 프롬프트/응답 트레이스가 1차 데이터.
  • 평가(eval): 정답이 모호하므로 LLM-as-judge, 규칙 기반, 사용자 피드백을 조합.
  • 프롬프트 레지스트리: 모델 버전과 별도로 프롬프트 버전을 관리.
  • 비용 추적: 토큰 단위 비용이 ML 비용의 중심.

주요 도구는 다음과 같다.

  • LangSmith: LangChain 진영의 표준. SaaS + self-host.
  • Langfuse: 오픈소스 self-host 트랙. 트레이스/평가/프롬프트 관리.
  • Arize Phoenix: Arize의 OSS 분파. LLM 트레이싱과 평가.
  • Helicone: OpenAI/Anthropic API 게이트웨이 + 트레이스.

iter77(LLM 관측성)과 iter83(파인튜닝)에서 더 깊이 다룬다.

한국 MLOps — 네이버 클라우드, 카카오 엔터프라이즈, NCSOFT, 현대차

한국 MLOps 생태계는 다음 축으로 구성된다.

  • 네이버 클라우드 ML 플랫폼: HyperCLOVA X 기반 파인튜닝 + 자체 MLOps 도구.
  • 카카오 엔터프라이즈: Kakao i Cloud의 ML 트랙. Kubeflow와 자체 도구 혼합.
  • NCSOFT AI 센터: 게임 AI + 캐릭터 AI 중심 자체 파이프라인.
  • 현대차 그룹 AI 랩: 자율주행 데이터 + 모델 자동화에 Flyte/Kubeflow 혼합 사례.
  • 한국 ML 엔지니어 커뮤니티: MLOps Korea, Pseudo Lab, 모두의연구소 트랙 등 정기 밋업.

대기업은 자체 플랫폼 위에 MLflow/Kubeflow를 얹는 패턴이, 스타트업은 SageMaker나 Vertex AI를 그대로 쓰는 패턴이 대세다.

일본 MLOps — PFN, 메르카리, 사이보즈, 리쿠르트

일본 MLOps 생태계는 다음이 두드러진다.

  • PFN(Preferred Networks): Optuna(하이퍼파라미터 최적화) 원작자. 자체 워크플로 Allgo와 함께 사용.
  • 사이보즈(Cybozu): kintone 데이터 기반 ML 파이프라인. Argo Workflows + 자체 도구.
  • 리쿠르트 AI Lab: 광고/리쿠르팅 도메인 ML 파이프라인. Vertex AI + MLflow.
  • 메르카리 ML 플랫폼: 자체 ML 플랫폼 "Merlin" 운영. KServe + Argo + Feast.
  • NTT Communications - PFN 파트너십: 통신 데이터 기반 대규모 학습.

일본에서는 Argo Workflows(클래식)와 Kubeflow + KServe의 채택률이 높다. Qiita/Zenn에는 2026년 들어 Flyte/Metaflow 일본어 튜토리얼이 빠르게 늘었다.

CNCF AI & Data 서브그룹 — 표준화의 흐름

2024년 말 CNCF는 AI & Data 서브그룹을 정식 출범했다. 2026년 5월 기준 다음 프로젝트들이 산하에 정렬되어 있다.

  • Kubeflow Pipelines, Kubeflow Training Operator: ML 파이프라인 + 분산 학습.
  • Flyte: 워크플로(인큐베이션).
  • KServe: 서빙(인큐베이션).
  • Volcano: 배치 스케줄러.
  • Spark Operator: K8s 위 Spark.
  • Argo Workflows: 클래식이지만 ML 워크플로에 자주 등장.

CNCF가 표준화 허브가 되면서 K8s 위 ML의 인터페이스가 점점 통일되고 있다. 매니지드 플랫폼들도 KServe v1/v2 인추론 프로토콜을 채택하는 흐름이다.

조합 패턴 — 실제 프로덕션은 어떻게 묶는가

실제 회사들은 한 도구로 끝내지 않는다. 자주 나오는 조합 패턴은 다음과 같다.

  • 스타트업 미니멈: MLflow(추적+레지스트리) + Metaflow(워크플로) + BentoML(서빙) + Evidently(모니터링).
  • K8s 엔터프라이즈: Kubeflow(파이프라인) + MLflow(추적) + KServe(서빙) + Feast(피처) + DVC(데이터).
  • AWS 매니지드 우선: SageMaker Pipelines + SageMaker Model Registry + SageMaker Endpoints + W&B(SaaS 추적) + Evidently(모니터).
  • GCP 매니지드 우선: Vertex AI Pipelines + Vertex Endpoints + W&B + Featureform.
  • LLM 우선 스타트업: Hugging Face Hub(모델) + Langfuse(트레이싱) + BentoML 1.4(서빙) + ZenML(워크플로 추상).

핵심은 **"무엇이 1급 시민이고 무엇이 보조인가"**다. K8s가 1급이면 Kubeflow + KServe, 파이썬 워크플로가 1급이면 Metaflow + BentoML, LLM이 1급이면 HF Hub + Langfuse + vLLM이다.

도입 로드맵 — 0에서 프로덕션까지

처음 MLOps를 도입할 때는 다음 순서가 가장 안전하다.

  1. 실험 추적부터 깔자. MLflow 또는 W&B. 일주일 안에 가능.
  2. 모델 레지스트리를 같은 추적 도구 안에서 시작. 별도 도구는 아직 필요 없다.
  3. 모델 서빙을 최소 BentoML 또는 FastAPI + ONNX/TorchScript로 시작. 매니지드(SageMaker Endpoints, Vertex Endpoints)도 좋다.
  4. 파이프라인 오케스트레이션은 데이터 사이언티스트 1-2명일 때는 cron + Makefile로 충분. 3명 이상이거나 일 단위 학습이 필요해지면 Metaflow/ZenML.
  5. 데이터 버저닝은 데이터셋이 GB 이상이고 변경이 잦아지면 DVC 또는 lakeFS.
  6. 피처 스토어는 학습-추론 일관성 사고가 한 번 나면 도입. 처음부터 깔지 말 것.
  7. 모니터링은 모델이 1개 이상 프로덕션이고 사용자 데이터가 들어오기 시작하면.

8개 다 깔고 시작하면 90%는 실패한다. 한 레이어씩 도입하는 게 정설이다.

마치며 — 2026년 5월, "MLOps는 여전히 모자이크"

이 글의 결론은 "표준이 굳어졌다"였지만, 동시에 "여전히 모자이크"이기도 하다. 한 회사가 7개 레이어를 모두 한 벤더로 묶지는 않는다. MLflow + Metaflow + BentoML + DVC + Evidently 같은 OSS 조합이 여전히 가장 흔하다.

가장 큰 변화는 LLMOps와 클래식 MLOps의 분기다. 같은 회사 안에서도 두 트랙이 별도 도구 스택을 가진다. LLMOps 쪽은 LangSmith/Langfuse/Phoenix가, 클래식은 MLflow/Kubeflow가 굳혀 가는 흐름이다.

도구 선택에 너무 오래 매달리지 말자. 어떤 조합이든 **"코드, 데이터, 모델, 결과의 4중 버전 관리"**만 되면 90%는 해결된다. 나머지는 우선순위 문제다.

References

Discuss on Twitter • View on GitHub