Having worked with numerous MLOps platform teams—those responsible for centrally standardizing internal ML functions within their companies—I have observed several common patterns in how MLOps adoption typically unfolds over time. Having seen Uber write about the evolution of their ML platform recently, it inspired me to write my thoughts on what I’ve seen out in the wild:
회사 내부의 머신러닝 기능을 중앙에서 표준화하는 역할을 담당하는 수많은 머신러닝 플랫폼 팀과 함께 일하면서, 시간이 지남에 따라 머신러닝 도입이 일반적으로 어떻게 전개되는지에 대한 몇 가지 공통된 패턴을 관찰했습니다. 최근 Uber가 ML 플랫폼의 진화에 대해 쓴 글을 보고 제가 현장에서 본 것에 대한 제 생각을 적어보려고 했습니다:

🧱 Throw-it-over-the-wall → Self-serve data science
🧱 벽에 던져 넣기 → 셀프 서비스 데이터 과학

Usually, teams start with one or two people who are good at the ops part, so they are tasked with deploying models individually. This often involves a lot of direct communication and knowledge transfer. This pattern often forms silos, and over time teams tend to break them and give more power to data scientists to own production. IMO, the earlier this is done, the better. But you’re going to need a central platform to enable this.
일반적으로 팀은 운영 파트에 능숙한 한두 명으로 시작하기 때문에 개별적으로 모델을 배포하는 임무를 맡게 됩니다. 여기에는 종종 많은 직접적인 커뮤니케이션과 지식 전달이 수반됩니다. 이러한 패턴은 종종 사일로를 형성하며, 시간이 지남에 따라 팀은 사일로를 깨고 데이터 과학자에게 더 많은 권한을 부여하여 프로덕션을 소유하게 되는 경향이 있습니다. 이러한 작업은 빠르면 빠를수록 좋습니다. 하지만 이를 가능하게 하려면 중앙 플랫폼이 필요합니다.

Tools you could use: ZenML, AWS Sagemaker, Google Vertex AI
사용할 수 있는 도구: ZenML, AWS Sagemaker, Google Vertex AI

📈 Manual experiments → Centralized tracking
📈 수동 실험 → 중앙 집중식 추적

This is perhaps the simplest possible step a data science team can take to 10x their productivity → Add an experiment tracking tool into the mix and you go from non-centralized, manual experiment tracking and logs to a central place where metrics and metadata live.
데이터 과학 팀이 생산성을 10배로 높이기 위해 취할 수 있는 가장 간단한 단계 → 실험 추적 도구를 추가하면 비중앙 집중식 수동 실험 추적 및 로그에서 메트릭과 메타데이터가 있는 중앙 위치로 이동할 수 있습니다.

Tools you could use: MLflow, CometML, Neptune
사용할 수 있는 도구: MLflow, CometML, Neptune

🚝 Mono-repo → Shared internal library
🚝 모노 리포 → 공유 내부 라이브러리

It’s natural to start with one big repo and throw all data science-related code in it. However, as teams mature, they tend to abstract commonly used patterns into an internal (pip) library that is maintained by a central function and in another repo. Also, a repo per project or model can also be introduced at this point (see shared templates).
하나의 큰 리포지토리에서 시작하여 모든 데이터 과학 관련 코드를 그 안에 넣는 것은 자연스러운 일입니다. 하지만 팀이 성숙해지면 일반적으로 사용되는 패턴을 중앙 기능과 다른 리포지토리에 의해 유지 관리되는 내부(pip) 라이브러리로 추상화하는 경향이 있습니다. 또한, 이 시점에서 프로젝트 또는 모델별 리포지토리를 도입할 수도 있습니다(공유 템플릿 참조).

Tools you could use: Pip, Poetry
사용할 수 있는 도구: Pip, Poetry

🪣 Manual merges → Automated CI/CD
🪣 수동 병합 → 자동화된 CI/CD

I’ve often seen a CI pattern emerge quickly, even in smaller startups. However, a proper CI/CD system with integration tests and automated model deployments is still hard to reach for most people. This is usually the end state → However, writing a few GitHub workflows or Gitlab pipelines can get most teams starting very far in the process.
저는 소규모 스타트업에서도 CI 패턴이 빠르게 나타나는 것을 종종 보았습니다. 하지만 통합 테스트와 자동화된 모델 배포를 갖춘 적절한 CI/CD 시스템은 아직 대부분의 사람들에게 도달하기 어렵습니다. 이것이 보통 최종 상태 → 하지만 몇 가지 GitHub 워크플로 또는 Gitlab 파이프라인을 작성하면 대부분의 팀이 프로세스의 시작 단계에 도달할 수 있습니다.

Tools you could use: GitHub, Gitlab, Circle CI
사용할 수 있는 도구: GitHub, Gitlab, Circle CI

👉 Manually triggered scripts → Automated workflows
👉 수동 트리거 스크립트 → 자동화된 워크플로

Bash scripts that are hastily thrown together to trigger a train.py are probably the starting point for most teams, but very quickly teams can outgrow these. It’s hard to maintain, intransparent, and flaky. A common pattern is to transition to ML pipelines, where steps are combined together to create workflows that are orchestrated locally or on the cloud.
대부분의 팀에서 train.py를 트리거하기 위해 급하게 만든 Bash 스크립트가 시작점일 수 있지만, 팀들은 금방 이보다 더 큰 스크립트를 만들 수 있습니다. 유지 관리가 어렵고 투명하지 않으며 불안정하기 때문입니다. 일반적인 패턴은 여러 단계를 결합하여 로컬 또는 클라우드에서 오케스트레이션되는 워크플로를 만드는 ML 파이프라인으로 전환하는 것입니다.

Tools you could use: Airflow, ZenML, Kubeflow
사용할 수 있는 도구: Airflow, ZenML, Kubeflow

🏠 Non-structured repos → Shared templates
🏠 비정형 리포지토리 → 공유 템플릿

The first repo tends to evolve organically and contains a whole bunch of stuff that will be pruned later. Ultimately, a shared pattern is introduced and a tool like cookie-cutter or copier can be used to distribute a single standard way of doing things. This makes onboarding new team members and projects way easier.
첫 번째 리포지토리는 유기적으로 진화하는 경향이 있으며 나중에 정리될 많은 내용을 담고 있습니다. 궁극적으로 공유 패턴이 도입되고 쿠키 커터나 복사기와 같은 도구를 사용하여 하나의 표준 작업 방식을 배포할 수 있습니다. 이렇게 하면 새로운 팀원과 프로젝트를 훨씬 쉽게 온보딩할 수 있습니다.

Tools you could use: Cookiecutter, Copier
사용할 수 있는 도구: 쿠키 커터, 복사기

🖲️ Non-reproducible artifacts → Lineage and provenance
🖲️ 재현할 수 없는 아티팩트 → 계보 및 출처

At first, no artifacts are tracked in the ML processes, including the machine learning models. Then the models start getting tracked, along with experiments and metrics. This might be in the form of a model registry. The last step in this is to also track data artifacts alongside model artifacts, to see a complete lineage of how a ML model was developed.
처음에는 머신 러닝 모델을 포함하여 ML 프로세스에서 아티팩트가 추적되지 않습니다. 그런 다음 모델이 실험 및 메트릭과 함께 추적되기 시작합니다. 이는 모델 레지스트리의 형태일 수 있습니다. 마지막 단계는 모델 아티팩트와 함께 데이터 아티팩트도 추적하여 ML 모델이 어떻게 개발되었는지에 대한 전체 계보를 확인하는 것입니다.

Tools you could use: DVC, LakeFS, ZenML
사용할 수 있는 도구: DVC, LakeFS, ZenML

💻 Unmonitored deployments → Advanced model & data monitoring
💻 모니터링되지 않는 배포 → 고급 모델 및 데이터 모니터링

Models are notoriously hard to monitor - Whether its watching for spikes in the inputs or seeing deviations in the outputs. Therefore, detecting things like data and concept drift is usually the last puzzle piece to fall as teams mature into full MLOps maturity. If you’re automatically detecting drift and taking action, you are in the top 1% of ML teams.
모델은 입력의 급격한 증가를 감시하거나 출력의 편차를 확인하는 등 모니터링하기 어려운 것으로 악명이 높습니다. 따라서 데이터 및 개념의 편차와 같은 것을 감지하는 것은 일반적으로 팀이 완전한 MLOps 성숙 단계에 접어들면서 마지막으로 해결해야 할 퍼즐 조각입니다. 드리프트를 자동으로 감지하고 조치를 취하고 있다면 상위 1%의 ML 팀에 속하는 것입니다.

Tools you could use: Evidently, Great Expectations
사용할 수 있는 도구: 분명히 큰 기대가 있습니다.

Have I missed something? Please share other common patterns, I think its useful to establish a baseline of this journey from various angles.
제가 놓친 것이 있나요? 다른 일반적인 패턴을 공유해 주세요. 다양한 각도에서 이 여정의 기준을 설정하는 것이 유용하다고 생각합니다.

Disclaimer: This was originally a post on the ZenML blog but I thought it was useful to share here and was not sure whether posting a company affiliated link would break the rules. See original blog here: https://www.zenml.io/blog/reflections-on-working-with-100s-of-ml-platform-teams
면책 조항: 원래 ZenML 블로그에 게시된 글이었으나, 회사 제휴 링크를 게시하는 것이 규칙을 위반하는 것인지 확실하지 않아 여기서 공유하는 것이 유용할 것 같아서 공유하게 되었습니다. 여기에서 원본 블로그를 참조하세요: https://www.zenml.io/blog/reflections-on-working-with-100s-of-ml-platform-teams