MLOps (MLOps)

#개념

MLOps(Machine Learning Operations)는 소프트웨어 공학의 DevOps 원칙을 머신러닝(Machine Learning) 시스템에 확장한 것으로, 데이터 준비와 모델 학습부터 배포, 모니터링, 재학습에 이르는 전체 생애주기를 자동화·표준화하여 모델을 프로덕션 환경에서 신뢰성 있게 운영하기 위한 원칙과 도구, 조직 문화의 집합이다. 일반 소프트웨어는 코드만 변하지만 머신러닝 시스템은 코드, 데이터, 모델이라는 세 가지 축이 독립적으로 변하며, 학습 데이터의 분포가 바뀌면 코드를 한 줄도 고치지 않아도 시스템의 품질이 저하될 수 있다. Sculley 등(2015)은 이러한 특성을 "머신러닝 시스템의 숨겨진 기술 부채(Hidden Technical Debt)"로 정리하면서, 실제 시스템에서 모델 코드는 전체의 극히 일부이며 데이터 수집, 특징 추출, 서빙 인프라, 모니터링 같은 주변 요소가 대부분을 차지한다고 지적했다. MLOps는 바로 이 주변 요소를 체계적으로 관리하기 위한 접근이며, 노트북에서 만든 실험 결과가 프로덕션까지 이어지지 못하는 문제를 해결하는 데 초점을 둔다.

MLOps의 첫 번째 축은 실험 추적(Experiment Tracking)과 모델 레지스트리(Model Registry)다. 실험 추적은 각 학습 실행(run)의 코드 버전, 하이퍼파라미터(Hyperparameter), 데이터셋 버전, 평가 지표, 산출물(artifact)을 자동으로 기록하여 어떤 설정이 어떤 결과를 냈는지 비교하고 재현할 수 있게 한다. 모델 레지스트리는 학습된 모델을 버전과 함께 중앙에 등록하고 "스테이징", "프로덕션", "보관" 같은 단계(stage) 또는 별칭(alias)을 부여하여 어떤 모델이 현재 서비스 중인지 명확히 하고, 승인 절차와 롤백을 지원한다. 두 번째 축은 파이프라인 자동화다. 소프트웨어의 지속적 통합(Continuous Integration, CI)과 지속적 배포(Continuous Delivery/Deployment, CD)에 더해, MLOps는 새로운 데이터가 도착하거나 성능이 저하되면 모델을 자동으로 다시 학습하는 지속적 학습(Continuous Training, CT)을 추가한다. CI 단계에서는 코드뿐 아니라 데이터 스키마 검증, 특징 계산 로직 테스트, 모델 품질 테스트가 수행되고, CD 단계에서는 학습 파이프라인 자체와 예측 서비스가 배포된다. 학습 파이프라인은 데이터 추출, 검증, 전처리, 학습, 평가, 검증(validation)의 단계로 구성되며, 각 단계가 컨테이너화된 컴포넌트로 정의되어 오케스트레이터가 실행한다. 세 번째 축은 피처 스토어(Feature Store)다. 피처 스토어는 특징 엔지니어링(Feature Engineering)의 결과를 중앙에서 정의·저장·제공하는 저장소로, 대량의 과거 데이터를 다루는 오프라인 스토어와 밀리초 단위로 조회하는 온라인 스토어를 함께 제공한다. 학습과 서빙에서 동일한 특징 정의를 사용하게 하여 학습-서빙 편차(Training-Serving Skew)를 방지하고, 학습 데이터셋을 만들 때 각 레코드의 시점 이전의 특징 값만 결합하는 시점 정합성(point-in-time correctness) 조회로 미래 정보 누출(data leakage)을 막는다.

모델 서빙(Model Serving)은 학습된 모델을 실제 예측 요청에 노출하는 방식이며 크게 두 가지로 나뉜다. 배치 추론(Batch Inference)은 일정 주기마다 전체 대상에 대해 예측을 미리 계산하여 데이터 웨어하우스(Data Warehouse)나 키-값 저장소에 적재하는 방식으로, 구현이 단순하고 처리량이 높지만 최신 입력을 즉시 반영하지 못한다. 온라인 추론(Online Inference)은 REST나 gRPC 엔드포인트로 요청마다 실시간 예측을 반환하는 방식으로, 낮은 지연 시간(Latency)과 오토스케일링, 로드 밸런싱이 필요하며, 스트리밍 파이프라인과 결합한 준실시간(near real-time) 추론도 자주 사용된다. 새 모델을 배포할 때는 위험을 줄이기 위해 일부 트래픽만 새 모델로 보내는 카나리 배포(Canary Deployment), 실제 트래픽을 복제하여 새 모델의 출력을 기록만 하는 섀도 배포(Shadow Deployment), 두 모델의 비즈니스 지표를 비교하는 A/B 테스트가 활용된다. 배포 이후에는 모니터링(Monitoring)이 핵심이다. 시스템 수준에서는 지연 시간, 처리량, 오류율, 자원 사용량을 감시하고, 모델 수준에서는 입력 데이터의 통계적 분포가 학습 시점과 달라지는 데이터 드리프트(Data Drift)와, 입력과 정답 사이의 관계 자체가 변하는 개념 드리프트(Concept Drift)를 탐지한다. 데이터 드리프트는 특징별 분포를 PSI(Population Stability Index), KL 발산, 콜모고로프-스미르노프 검정 등으로 비교하여 즉시 감지할 수 있지만, 개념 드리프트는 정답 레이블이 지연되어 도착하는 경우가 많아 예측 분포 변화나 대리 지표를 함께 감시해야 한다. 드리프트나 성능 저하가 임계치를 넘으면 경보를 발생시키거나 재학습 파이프라인을 자동으로 트리거하는 것이 MLOps 자동화의 완성이다.

재현성(Reproducibility)과 리니지(Lineage)는 MLOps의 신뢰성을 뒷받침하는 기반이다. 재현성은 같은 코드, 같은 데이터, 같은 환경으로 같은 모델을 다시 만들 수 있는 능력으로, 코드는 Git으로, 데이터와 모델 산출물은 DVC나 오브젝트 스토리지의 버전 관리로, 실행 환경은 컨테이너 이미지와 의존성 고정(lock file)으로, 무작위성은 시드 고정으로 통제한다. 리니지는 특정 프로덕션 모델이 어떤 데이터셋 버전과 코드 커밋, 파이프라인 실행으로부터 만들어졌는지를 그래프로 추적하는 것으로, 장애 원인 분석과 규제 감사에 필수적이며 데이터 거버넌스(Data Governance)와 직접 연결된다. Google은 MLOps 성숙도를 세 단계로 구분한다. 레벨 0(수동 프로세스)은 데이터 과학자가 노트북에서 실험하고 모델 파일을 수작업으로 엔지니어에게 넘겨 배포하는 단계로, 배포가 드물고 모니터링이 거의 없으며 배포된 모델이 조용히 낡아간다. 레벨 1(ML 파이프라인 자동화)은 학습 파이프라인을 자동화하여 새 데이터로 모델을 지속적으로 학습(CT)하는 단계로, 실험 환경과 프로덕션 환경에서 동일한 파이프라인을 사용하고 데이터·모델 검증 단계, 메타데이터 저장소, 피처 스토어가 도입된다. 레벨 2(CI/CD 파이프라인 자동화)는 파이프라인 구현 자체를 CI/CD로 빠르게 배포하는 단계로, 새로운 특징이나 모델 구조를 실험한 뒤 자동 테스트를 거쳐 프로덕션 파이프라인에 반영하는 주기가 수일에서 수시간으로 단축된다. Kreuzberger 등(2022)은 문헌과 실무자 인터뷰를 종합하여 MLOps를 CI/CD 자동화, 워크플로 오케스트레이션, 재현성, 버전 관리, 협업, 지속적 학습·평가, 메타데이터 추적, 모니터링, 피드백 루프라는 아홉 가지 원칙으로 정리했다.

MLOps 도구 생태계는 빠르게 성장했다. MLflow는 실험 추적, 모델 패키징, 모델 레지스트리, 배포를 지원하는 대표적인 오픈소스 플랫폼이며, Kubeflow는 Kubernetes 위에서 파이프라인(Kubeflow Pipelines), 분산 학습, 서빙(KServe)을 통합 제공한다. 특징 관리에는 Feast, 데이터·모델 버전 관리에는 DVC, 워크플로 오케스트레이션에는 Airflow·Argo·Prefect, 데이터 검증에는 Great Expectations·TFDV, 서빙에는 KServe·Seldon·BentoML·Triton, 모니터링에는 Evidently·WhyLabs 등이 사용되고, Amazon SageMaker, Google Vertex AI, Azure Machine Learning, Databricks 같은 관리형 플랫폼은 이 구성 요소를 통합하여 제공한다. 최근에는 대규모 언어 모델(Large Language Models, LLM)의 등장으로 MLOps가 LLMOps로 확장되고 있다. LLMOps는 모델을 처음부터 학습하기보다 사전 학습 모델을 활용하므로 프롬프트의 버전 관리와 평가, 검색 증강 생성(RAG) 파이프라인의 임베딩·인덱스 관리, 미세 조정(Fine-tuning) 데이터셋 관리, 토큰 비용과 지연 시간 최적화, 출력 품질을 판정하는 LLM-as-a-judge 기반 평가, 요청 흐름을 추적하는 트레이싱(tracing), 환각과 유해 출력에 대한 가드레일이 새로운 관리 대상이 된다. 정답이 하나로 정해지지 않는 생성 태스크의 특성상 전통적인 정확도 지표 대신 다면적 평가와 사람 피드백 수집이 중요해졌으며, MLflow나 LangSmith 같은 도구가 이러한 기능을 통합하고 있다. 결론적으로 MLOps는 특정 도구가 아니라 "모델을 만드는 것"에서 "모델을 지속적으로 운영하는 것"으로 관점을 옮기는 실천 체계이며, 데이터 과학자와 엔지니어, 운영 조직 사이의 협업 구조와 함께 설계될 때 비로소 효과를 발휘한다.

#관련 용어

지속적 학습(CT)

새로운 데이터 유입이나 성능 저하를 계기로 모델을 자동으로 재학습하여 배포하는 MLOps 고유의 자동화 단계

피처 스토어

학습과 서빙에서 동일한 특징 정의를 공유하도록 특징 값을 중앙에서 저장·제공하는 저장소

특징 엔지니어링

원시 데이터로부터 모델 입력으로 사용할 특징을 설계하고 변환하는 과정

데이터 드리프트

프로덕션 입력 데이터의 통계적 분포가 학습 데이터와 달라져 모델 성능이 저하되는 현상

데이터 파이프라인

데이터를 수집·변환·적재하여 학습과 추론에 공급하는 자동화된 처리 흐름

데이터 거버넌스

데이터의 품질·보안·리니지를 관리하는 체계로, 모델 감사와 재현성의 기반

#직무 연관도

Data Analyst낮음

배치 예측 결과와 모델 성능 대시보드를 해석하고, 드리프트 모니터링 지표를 비즈니스 관점에서 검토하는 데 활용된다

Data Scientist높음

실험을 체계적으로 추적하고 재현 가능한 파이프라인으로 모델을 프로덕션에 전달하며, 배포 후 성능 저하를 진단하는 데 필수적인 실천 체계

Data Engineer밀접

학습·서빙 파이프라인 구축, 모델 레지스트리와 CI/CD/CT 자동화, 서빙 인프라와 모니터링 설계의 핵심 영역

#사용 사례

인터넷 서비스전자상거래금융제조통신의료

개요

MLOps는 추천·검색 랭킹, 이상 거래 탐지, 수요 예측, 예지 정비, 신용 평가처럼 모델을 지속적으로 갱신하며 운영해야 하는 모든 머신러닝 서비스에 적용되며, 최근에는 LLM 기반 챗봇과 RAG 서비스의 프롬프트·평가·비용 관리(LLMOps)로 확장되고 있다.

사례

전자상거래 기업의 추천 모델 운영에서, 매일 새벽 새로운 클릭·구매 로그가 피처 스토어에 적재되면 학습 파이프라인이 자동으로 실행되어 모델을 재학습하고, 검증 지표가 현재 프로덕션 모델보다 높을 때만 모델 레지스트리에 새 버전이 등록되어 카나리 배포된다. 배포 후 입력 특징 분포의 드리프트와 클릭률 변화가 모니터링되며, 임계치를 벗어나면 자동으로 이전 버전으로 롤백된다.