ML 협업 플랫폼 도입 비교 2026, DS·MLE 실험관리·피처스토어·권한 기준

ML 협업 플랫폼 도입 비교를 검토하는 DS와 MLE 협업 회의 장면 — DS와 MLE 협업은 도구 이름보다 모델 인수인계 계약, 피처 책임, 권한 경계가 먼저다.

ML 협업 플랫폼 도입 비교는 노트북을 어느 SaaS에 올릴지 고르는 문제가 아니다.

DS가 만든 실험 결과를 MLE가 재현 가능한 서비스 패키지로 넘겨받고, 장애가 났을 때 누가 어떤 근거로 되돌릴지 정하는 문제다.

토스 기술 글의 사례처럼 노트북에서는 모델이 잘 돌았는데 서빙 환경에서 파일과 설정을 다시 달라고 주고받는 순간 협업 비용이 드러난다.

그래서 도구 평가는 실험관리, 모델 레지스트리, 피처스토어, CI 러너, Kubernetes 권한을 하나의 운영 흐름으로 묶어서 봐야 한다.

핵심 요약

처음 볼 기준은 화면이 예쁜 SaaS가 아니라 DS와 MLE 사이의 모델 인수인계 계약이다.
MLflow Tracking과 Model Registry는 run, artifact, lineage, alias 같은 증거를 남기는 기준점으로 삼기 좋다.
Feast 같은 피처스토어를 붙이면 학습용 offline store와 운영용 online store의 책임 경계가 별도 비용 항목이 된다.
GitHub Actions, SageMaker, Kubernetes RBAC 비용과 권한을 같이 보지 않으면 협업 플랫폼이 자동화 비용 폭탄이나 보안 우회로가 된다.

도입 전 30분 판단 기준

먼저 지금 팀의 병목이 실험 기록인지, 피처 재사용인지, 배포 승인인지, 운영 권한인지 분리한다.

병목을 나누지 않으면 비싼 플랫폼을 사도 DS는 노트북을 계속 보내고 MLE는 서빙 코드를 계속 다시 쓴다.

병목	증상	우선 도입 축	보류 신호
실험 재현	같은 모델 성능을 다시 만들 수 없고 파라미터와 데이터 버전이 흩어진다	MLflow Tracking, 실험 run 규칙, artifact 저장소	metric 이름과 dataset version 규칙이 없는데 UI부터 산다
모델 승격	candidate, staging, production 기준이 구두 승인으로만 남는다	Model Registry, alias, reviewer, rollback 규칙	운영 alias 변경 권한이 모든 개발자에게 열려 있다
피처 공유	학습 피처와 온라인 피처가 다르고 데이터 누수 논쟁이 반복된다	Feast, offline store, online store, freshness alert	피처 owner와 SLA 없이 저장소만 만든다
배포 자동화	모델 패키지 테스트가 느리고 러너 비용이 누가 썼는지 안 보인다	CI 러너, 캐시, artifact 보존, 비용 경보	private repository 사용량과 cache 정책을 보지 않는다
운영 보안	DS 계정이 운영 namespace를 직접 만지거나 MLE 계정이 학습 데이터까지 넓게 본다	Kubernetes RBAC, service account, CODEOWNER 승인	RoleBinding 없이 cluster-admin 편의 권한으로 시작한다

이 조건이면 실험 기록이 먼저 깨진 팀은 MLflow Tracking부터 작게 붙인다.

이 경우는 피처 최신성이나 데이터 누수가 잦다면 피처스토어 책임 경계를 먼저 세운다.

반대로 모델 수가 2개 이하이고 배포 주기가 분기 1회라면 플랫폼 구매보다 handoff 계약서와 체크리스트가 먼저다.

Toss 사례에서 가져올 것은 도구명이 아니라 경계선이다

Toss Tech 글은 DS와 MLE가 일을 사람 사이에서 나누다가 파일로 내리고, 다시 인터페이스 계약으로 옮긴 과정을 보여준다.

핵심은 DS가 전처리, 추론, 후처리 구현체를 만들고 MLE가 그 패키지를 서비스에 설치할 수 있게 경계를 고정했다는 점이다.

이 관점으로 보면 ML 협업 플랫폼은 노트북 공유 서비스가 아니라 인터페이스와 증거를 강제하는 운영 장치다.

DS 산출물은 notebook 하나가 아니라 package, run id, dataset version, metric, artifact uri로 남아야 한다.
MLE 산출물은 서빙 코드 재작성본이 아니라 배포 가능한 wrapper, observability hook, rollback path로 남아야 한다.
공통 계약은 Python class, YAML manifest, model registry alias, feature definition 중 하나로 버전 관리돼야 한다.
코드 리뷰는 모델 성능 숫자만 보지 말고 입력 스키마, 전역 상태, 외부 파일 의존성, 운영 로그를 같이 봐야 한다.

실무 시나리오 1은 DS가 신용평가 보조 모델을 노트북에서 완성하고 MLE가 API 서비스로 올리는 경우다.

이 조건이면 노트북 전달을 금지하고 pre_process, inference, post_process 메서드를 가진 패키지와 MLflow run id를 같이 넘겨야 한다.

실무 시나리오 2는 추천 모델이 매주 바뀌고 피처 생성 쿼리도 계속 바뀌는 팀이다.

이 경우는 모델 레지스트리만으로 부족하고 offline store, online store, point-in-time join 기준까지 문서화해야 한다.

MLflow는 실험 화면보다 증거 사슬로 평가한다

MLflow Tracking 문서는 run이 파라미터, 코드 버전, metric, output file을 기록하는 실행 단위라고 설명한다.

이 설명을 도입 기준으로 바꾸면 DS의 실험 run이 운영 배포까지 추적되는지 확인해야 한다.

MLflow Model Registry 문서는 model version, lineage, alias, metadata tag, annotation을 통해 모델 생명주기를 관리한다고 설명한다.

그래서 레지스트리를 쓴다면 champion alias 변경, rollback alias, reviewer, 운영 환경 승격 로그를 별도 규칙으로 둬야 한다.

확인 항목	DS 관점	MLE 관점	플랫폼 게이트
Run 기록	학습 파라미터와 metric을 run에 남긴다	서빙 artifact가 어떤 run에서 왔는지 본다	run id 없는 모델은 staging 승격 금지
Artifact	모델 파일, tokenizer, schema, 전처리 산출물을 묶는다	패키지 설치와 로딩 경로를 재현한다	local path 의존성이 있으면 배포 금지
Model version	후보 모델을 등록하고 설명을 남긴다	version별 container image와 config를 연결한다	production alias 변경은 승인 기록 필요
Lineage	dataset version과 code commit을 같이 남긴다	장애 시 이전 run과 diff를 본다	데이터 버전 누락 시 운영 반영 보류
Rollback	이전 champion metric을 보관한다	alias를 되돌릴 절차를 문서화한다	rollback 담당자와 시간 목표 지정

이 정도 기준이 없으면 MLflow UI를 켜도 협업 플랫폼이 아니라 예쁜 실험 일지가 된다.

먼저 작은 모델 1개를 골라 run 기록, artifact, registry, alias, rollback을 끝까지 연결해 본 뒤 유료 관리형 플랫폼을 검토한다.

Feast 피처스토어는 DS 편의가 아니라 운영 책임 분리다

Feast 문서는 feature store가 production ML system을 운영하기 위해 feature를 정의, 관리, 검증, serving하는 시스템이라고 설명한다.

또 offline store는 학습용 historical feature extraction에 쓰이고, online store는 운영 시스템의 low-latency serving에 쓰인다고 구분한다.

이 구분은 DS와 MLE가 자주 싸우는 지점을 줄인다.

학습 데이터가 맞았는지, 운영 피처가 최신인지, 온라인 조회 latency가 예산 안에 있는지 서로 다른 책임으로 나눌 수 있기 때문이다.

offline store owner는 학습 데이터 재현과 point-in-time join 정확성을 책임진다.
online store owner는 운영 조회 latency, freshness, 장애 알림, 용량 계획을 책임진다.
feature definition은 코드 리뷰 대상이며 모델 코드 안에 숨은 임시 SQL을 허용하지 않는다.
feature server를 쓰면 Python이 아닌 서비스에서도 조회 가능하지만 인증, rate limit, latency 예산을 따로 둔다.

이 조건이면 실시간 예측이 없고 batch scoring만 하는 팀은 피처스토어를 바로 운영계에 붙이지 않아도 된다.

이 경우는 온라인 조회가 초당 트래픽을 받거나 freshness가 매출과 연결되면 online store 비용과 장애 대응을 별도 설계해야 한다.

공식 비용 숫자로 보는 예산 항목

ML 협업 플랫폼은 오픈소스 도구를 쓰더라도 compute, CI, storage, feature serving 비용이 따로 붙는다.

아래 숫자는 공식 문서에서 확인한 과금 단위이며, 실제 금액은 리전, 플랜, 약정, 사용량에 따라 달라진다.

항목	공식 숫자 또는 단위	협업 플랫폼에서 비용이 붙는 지점	예산 통제 기준
GitHub Actions runner	Linux 1-core $0.002/min, Linux 2-core $0.006/min, Windows 2-core $0.010/min, macOS 3~4-core $0.062/min	모델 테스트, 패키지 빌드, 보안 스캔, registry publish workflow	private repo runner minutes와 workflow owner를 월별로 본다
GitHub Actions storage	Enterprise plan 예시 50 GB allowance, cache storage 10 GB per repository, 초과 storage $0.25 USD per GB/month, cache $0.07 USD per GB/month	모델 artifact, 테스트 로그, cache, custom image storage	artifact 보존일과 cache key를 모델별로 제한한다
SageMaker Feature Store free tier	10 million write units, 10 million read units, 25 GB storage standard online store	feature group write/read, online store storage	무료 범위가 PoC만 덮는지 운영 트래픽 기준으로 다시 계산한다
SageMaker serverless inference free tier	150,000 seconds of on-demand inference duration	저트래픽 모델 API, batch 전환 전 검증	실제 p95 latency와 cold start를 비용표 옆에 기록한다
SageMaker Feature Store unit	standard write 1 WCU per second up to 1 KB, read 1 RCU per second up to 4 KB, in-memory minimum 5 GiB per hour	고빈도 feature lookup과 in-memory online store	피처 크기와 lookup 빈도를 줄이는 모델 설계를 먼저 검토한다

비용표를 이렇게 쪼개면 SaaS 구독료만 보는 실수를 줄일 수 있다.

실제 검토에서는 GitHub Actions 사용량 화면, AWS Pricing Calculator, cloud budget alert, registry storage report를 같은 월 단위로 맞춰야 한다.

이 경우는 실험 run이 많아진 팀일수록 모델 학습비보다 artifact 보관, CI 재실행, 피처 조회 비용이 먼저 샐 수 있다.

권한과 보안은 Kubernetes RBAC 기준으로 작게 시작한다

Kubernetes RBAC 문서는 Role, ClusterRole, RoleBinding, ClusterRoleBinding으로 권한을 선언한다고 설명한다.

ML 플랫폼에서 이 기준은 DS와 MLE가 같은 cluster를 보더라도 같은 권한을 갖지 않아야 한다는 뜻이다.

DS가 candidate model을 등록할 수는 있어도 production namespace의 deployment를 직접 바꾸면 안 된다.

MLE도 운영 rollout 권한은 가져야 하지만 학습 원천 데이터 전체를 내려받는 권한까지 자동으로 가져서는 안 된다.

역할	허용 권한	차단 권한	검증 방법
DS	experiment create, candidate model register, feature proposal PR	production alias 직접 변경, 운영 secret 조회	run id와 PR이 연결되는지 확인
MLE	staging promote, serving config review, rollout, rollback	학습 원천 데이터 무제한 조회	service account와 namespace scope 확인
Data platform	offline store schema, point-in-time join job, feature freshness rule	운영 모델 alias 단독 변경	feature owner와 alert owner 분리
Security reviewer	secret policy, image scan, RBAC review, audit log 확인	모델 성능 승인 단독 처리	CODEOWNER 또는 승인 기록 보존
Product owner	business metric 승인, launch window 결정	cluster-admin, registry admin	승인 comment와 rollback 기준 확인

권한 설계가 없는 ML 협업 플랫폼은 편한 공유 드라이브와 비슷해진다.

보안팀은 도구 구매 승인 전에 model registry admin, cloud billing admin, Kubernetes namespace admin을 누가 갖는지 먼저 물어야 한다.

도입 순서: 한 모델을 끝까지 통과시킨 뒤 넓힌다

ML 협업 플랫폼 도입 비교에서 가장 위험한 계획은 모든 팀, 모든 모델, 모든 도구를 한 번에 표준화하는 방식이다.

처음에는 장애 영향이 작지만 실제 운영 흐름을 가진 모델 1개를 골라 DS와 MLE가 끝까지 통과시키는 편이 낫다.

후보 모델 1개를 고르고 현재 handoff 시간을 재서 기준선을 만든다.
DS 산출물을 notebook, package, run id, artifact, dataset version으로 분리한다.
MLE는 wrapper, container image, serving config, observability hook, rollback path를 정의한다.
MLflow 또는 동등한 tracker에 run과 artifact를 남기고 registry alias 변경 규칙을 정한다.
Feast 또는 동등한 feature contract가 필요한지 offline, online, freshness 요구로 판단한다.
GitHub Actions 또는 CI에서 unit test, schema test, package build, secret scan을 통과해야 registry 승격이 가능하게 만든다.
Kubernetes RBAC 또는 관리형 플랫폼 권한으로 DS, MLE, reviewer, service account 범위를 나눈다.
30일 뒤 handoff 시간, rollback 시간, CI 비용, feature freshness incident, 운영 장애를 다시 비교한다.

이 순서가 통과되면 플랫폼 후보를 Databricks, SageMaker, Vertex AI, 자체 MLflow 조합처럼 넓혀 비교해도 된다.

통과되지 않았다면 도구 문제가 아니라 역할, artifact, 권한, 비용 측정 기준이 아직 없는 상태다.

운영 스켈레톤: 계약을 파일로 고정한다

아래 YAML은 DS와 MLE가 모델을 넘기기 전에 맞춰야 할 계약 항목을 파일로 남기는 예시다.

실제 배포 자동화가 아니라 코드 리뷰와 플랫폼 도입 검토에서 빠진 항목을 찾기 위한 스켈레톤으로 봐야 한다.

# model-handoff-contract.yaml
# 목적: DS가 만든 모델을 MLE가 서비스로 올릴 때 필요한 최소 계약을 코드 리뷰 전에 고정한다.
# 실제 배포 전에는 조직의 모델 레지스트리, 보안 정책, 개인정보 처리 기준을 다시 확인한다.

model_package:
  owner_team: data_science
  service_team: ml_engineering
  runtime: python-3.11
  entrypoint: package.inference:ModelService
  required_methods:
    - pre_process(input_payload)
    - inference(processed_payload)
    - post_process(model_output)
  blocked_patterns:
    - global_mutable_state
    - local_file_path_dependency
    - notebook_only_import
    - unversioned_external_dataset

experiment_tracking:
  required_fields:
    - experiment_name
    - run_id
    - git_commit
    - dataset_version
    - metric_name
    - artifact_uri
  promotion_gate:
    champion_alias_requires_review: true
    rollback_alias_required: true

feature_contract:
  offline_store_owner: data_platform
  online_store_owner: ml_platform
  point_in_time_join_required: true
  online_latency_budget_ms: 80
  feature_freshness_alert_minutes: 30

access_control:
  ds_can_register_candidate: true
  mle_can_promote_staging: true
  production_alias_requires_code_owner: true
  service_account_scope: namespace_limited

아래 Python 형태 점검표는 자동 증거 수집을 흉내 내는 코드가 아니라 사람의 사전 검토 순서를 고정하는 예시다.

#!/usr/bin/env python3
# ml_handoff_precheck.py
# 목적: DS-MLE 인수인계 전에 빠진 계약 항목을 사람이 확인하도록 만드는 점검 스켈레톤이다.
# 실제 MLflow, Feast, Kubernetes API 호출은 조직 환경에 맞게 별도 구현한다.

required = {
    'git_commit': '실험 run과 배포 패키지가 같은 commit을 가리키는가',
    'dataset_version': '학습 데이터 버전과 생성 시각이 기록됐는가',
    'artifact_uri': '모델 가중치와 부속 파일 위치가 레지스트리에 남았는가',
    'feature_freshness': '온라인 피처 최신성 알림 기준이 정해졌는가',
    'rbac_scope': '운영 namespace 권한이 service account 단위로 제한됐는가',
    'rollback_owner': 'champion alias 롤백 담당자가 지정됐는가',
}

missing = []
for key, question in required.items():
    print(f'CHECK {key}: {question}')
    if key.startswith('replace_with_real_failure'):
        missing.append(key)

if missing:
    raise SystemExit('handoff blocked: ' + ','.join(missing))
print('manual review required: this script is a checklist skeleton, not production evidence')

구매 전 체크리스트

상용 MLOps 플랫폼이나 관리형 ML 서비스를 비교할 때도 체크리스트는 도구별 기능표보다 운영 실패 항목으로 써야 한다.

실험 run, model version, feature definition, CI workflow, deployment가 하나의 trace id 또는 commit으로 연결되는가.
candidate, staging, production alias를 누가 바꿀 수 있고 어떤 승인 로그가 남는가.
feature freshness, online lookup latency, artifact storage, CI minutes, cache storage가 월 비용 보고서에 분리되는가.
DS가 운영 secret을 보지 않고도 후보 모델을 등록할 수 있는가.
MLE가 모델 코드를 다시 쓰지 않고 wrapper와 observability만 붙일 수 있는 계약이 있는가.
보안팀이 registry, runner, namespace, data store 권한을 감사 로그로 확인할 수 있는가.
30일 안에 rollback drill을 한 번 실행하고 이전 champion으로 되돌릴 수 있는가.

이 조건이면 기능이 많은 플랫폼보다 로그, 권한, 비용이 하나로 보이는 플랫폼을 우선한다.

이 경우는 무료 오픈소스 조합을 쓰더라도 운영 증거를 모으지 못하면 상용 SaaS보다 더 비쌀 수 있다.