MLOps

케이스 1Uber — 사내 ML 플랫폼으로 데이터·학습·배포·모니터링을 한 줄에 묶은 사례

Uber는 2015년부터 사내 머신러닝 플랫폼 Michelangelo를 구축했고 2017년 9월 공개했습니다 ^[2]. 데이터 관리, 학습, 평가, 배포, 예측, 예측 모니터링의 6단계를 하나의 워크플로로 표준화했습니다 ^[2]. 각 팀이 만든 피처를 공유 저장소에 올려 재사용하는 피처 스토어를 함께 만들었습니다 ^[2]. 2018년 11월 후속 글에서는 상시 수백 개 활용 사례와 수천 개 모델이 운영 환경에 배포돼 있다고 밝혔습니다 ^[3].
도입효과: 고객지원 티켓 처리 시간 첫 모델 10% 단축, 후속 버전 추가 6% 단축(2018년 11월 발표 기준) ^[3]

케이스 2우아한형제들 — AI 서빙 배포와 복구를 자동화한 사내 플랫폼 국내 사례

우아한형제들은 2024년 11월 기술블로그에서 AI 모델 서빙 자동화 사례를 공개했습니다 ^[4]. GitLab CI로 컨테이너 이미지를 만들고 ArgoCD Image Updater로 배포하며, 마이너와 패치는 롤링 업데이트로, 메이저는 블루그린 방식으로 나눕니다 ^[4]. 서빙 프레임워크는 BentoML, 노드 관리는 Kubernetes와 Karpenter를 씁니다 ^[4]. 모니터링은 Grafana·Prometheus·Sentry로, 서비스별 비용 가시성은 Kubecost로 확보했습니다 ^[4].
도입효과: 플랫폼 처리량 월 20억 건 요청(2024년 11월 발표 기준) ^[4]

케이스 3MLflow — 모델 레지스트리를 오픈소스 표준으로 자리잡게 한 도구

MLflow 모델 레지스트리는 모델 수명주기를 함께 관리하는 중앙 저장소와 API, UI입니다 ^[5]. 등록 모델, 모델 버전, 별칭, 태그 개념으로 어떤 버전이 운영에 올라가 있는지 추적합니다 ^[5]. 별칭을 쓰면 champion 같은 이름을 특정 버전에 붙였다가 옮기는 방식으로 배포 대상을 바꿀 수 있습니다 ^[5]. 계보 추적과 재현성, 거버넌스 확보가 목적입니다 ^[5].
도입효과: 월간 다운로드 1,000만 건 달성(2022년 11월 Linux Foundation 발표 기준) ^[6]

케이스 4Google Cloud — MLOps 성숙도를 레벨 0~2로 나눈 참조 문서

Google Cloud 아키텍처 센터 문서는 MLOps를 ML 시스템 개발과 운영을 통합하려는 공학 문화이자 실천으로 정의합니다 ^[1]. 레벨 0은 노트북에서 만든 모델을 수작업으로 넘기는 단계이고 배포가 드물며 성능 저하를 감지하지 못합니다 ^[1]. 레벨 1은 데이터·모델 검증, 메타데이터 관리, 지속 학습을 자동화합니다 ^[1]. 레벨 2는 여기에 CI/CD를 더해 새 아이디어를 빠르게 실험하고 배포합니다 ^[1].
도입효과: 공개된 정량 수치는 없습니다(참조 아키텍처 문서 성격). 확인된 내용은 레벨 0~2 구분과 피처 스토어·모델 레지스트리·ML 메타데이터 저장소·모델 모니터링을 구성요소로 제시한 점입니다 ^[1]

오늘 바로 해보기
01. 운영 중인 모델 목록과 각 모델의 마지막 학습 시점을 표로 적어봅니다.
02. 모델 하나를 골라 학습 데이터, 코드 버전, 평가 지표가 각각 어디에 남아 있는지 추적해봅니다.
03. MLflow 모델 레지스트리 문서의 등록 모델·버전·별칭 개념을 읽고 현재 배포 중인 버전을 어떻게 부를지 정합니다 ^[5].
04. Google Cloud 문서의 레벨 0~2 기준에 팀 현재 상태를 대조해 한 단계만 올릴 항목을 고릅니다 ^[1].
05. 입력 데이터 분포와 예측 결과를 매일 기록하는 대시보드를 하나 만들어 드리프트 감지의 출발점을 둡니다.

한계와 진화
한계는 범위입니다. Google Cloud 문서는 실제 ML 시스템에서 ML 코드가 차지하는 비중은 작고 설정, 데이터 수집·검증, 테스트, 자원 관리, 모델 분석, 서빙 인프라, 모니터링이 훨씬 크다고 설명합니다 ^[1]. 도구를 도입하는 일과 조직이 레벨 1이나 레벨 2로 올라가는 일은 다른 문제입니다. 레벨 1은 데이터·모델 검증과 지속 학습을, 레벨 2는 자동 테스트와 CI/CD를 전제하므로 사람과 절차가 함께 바뀌어야 합니다 ^[1]. 성숙도 레벨은 도달할 목표라기보다 현재 위치를 재는 자로 쓰는 편이 맞습니다.
진화 방향은 LLMOps와 에이전트 운영입니다. Google Cloud는 생성형 AI 운영에서 모델과 프롬프트를 묶은 프롬프트 모델 컴포넌트를 기본 단위로 보고, 프롬프트를 데이터이자 코드로 나눠 버전 관리와 승인 절차에 태우라고 제시합니다 ^[8]. 전면 재학습 대신 지속 튜닝, 단일 모델 대신 RAG·에이전트·외부 도구가 엮인 체인의 종단 평가, 입출력과 중간 상태까지 남기는 관측성이 새 요구 항목으로 붙습니다 ^[8]. 국내에서도 우아한형제들이 2025년 9월 기존 MLOps 기반 플랫폼을 AI 플랫폼 2.0으로 확장하며 프롬프트 버전 관리와 트레이스 로깅을 맡는 구성을 만든 과정을 공개했습니다 ^[7].