How are MLOps Frameworks Used in Open Source Projects? An Empirical Characterization

기술 요약: 오픈 소스 프로젝트에서 MLOps 프레임워크는 어떻게 사용되는가? 실증적 특성 분석

문제 정의
머신러닝 운영(MLOps) 프레임워크는 ML 모델의 라이프사이클을 관리하고 파일럿 프로젝트와 프로덕션 사이의 간극을 메우기 위해 설계되었으나, 오픈 소스 생태계에서의 실제 채택 양상은 여전히 명확히 이해되지 않고 있습니다. 산업 보고서에 따르면, 운영 및 재현성 문제로 인해 분석 프로젝트의 상당수가 프로덕션 단계로 전환되지 못하고 실패합니다. 수많은 오픈 소스 MLOps 프레임워크가 존재함에도 불구하고, 이들의 실제 사용 패턴에 관한 학술적 문헌은 제한적입니다. 개발자들이 이러한 도구들을 실제 프로젝트에서 어떻게 활용하는지, 어떤 특정 기능이 활용되는지, 그리고 커뮤니티가 원하는 개선 사항은 무엇인지에 대한 실증적 근거가 부족한 실정입니다.

연구 방법론
저자들은 BentoML, Deepchecks, Evidently AI, Kedro, Metaflow, MLFlow, Prefect, Wandb라는 8개의 인기 있는 오픈 소스 MLOps 프레임워크를 대상으로 실증 연구를 수행했습니다. 이들은 워크플로 관리, 모델 배포, 프로덕션 모니터링과 같은 핵심 MLOps 구성 요소를 포괄하도록 선정되었습니다.

본 연구는 위 프레임워크 중 적어도 하나를 의존성으로 갖는 969개의 Python 기반 GitHub 저장소를 분석했습니다. 데이터 수집 및 분석 과정은 다음과 같이 세 가지 주요 단계로 진행되었습니다:

1. 데이터셋 수집: GitHub 의존성 그래프를 통해 프로젝트를 식별하였으며, 튜토리얼, 토이 프로젝트(별점 10개 미만), 비-Python 저장소를 제외하여 필터링했습니다.
2. 사용량 추출 (RQ1 & RQ2): 저자들은 Python AST(추상 구문 트리)를 통해 프레임워크 사용을 탐지하기 위해 소스 코드(Jupyter Notebook을 Python 스크립트로 변환)를 분석했습니다. 이를 통해 함수 호출, 객체 인스턴스화, 속성 접근 등을 식별했습니다. 또한, 프로젝트가 CLI를 통해 호출되는지 또는 CI/CD 파이프라인의 일부로 실행되는지 확인하기 위해 GitHub Workflow(.yaml 파일)를 조사했습니다. 사용 패턴은 ML 워크플로 단계(예: 데이터 준비, 학습, 배포, 거버넌스)에 따라 수동으로 분류되었습니다.
3. 기능 요청 분석 (RQ3): 프레임워크의 이슈 트래커에서 4,386개의 종료/해결된 이슈를 마이닝하여 기능 요청(feature requests)을 필터링했습니다. 인간 전문가가 통계적으로 유의미한 샘양인 311개의 이슈를 수동으로 주석 처리하여 분류 체계(taxonomy)를 구축했습니다. 이후 이 분류 체계를 Gemini 2.5 Pro(LLM)를 사용하여 전체 데이터셋에 적용하였으며, Cohen's $\kappa$ 값 0.78을 달로 달성했습니다.

주요 기여

1. 사용량 분석: 969개의 클라이언트 프로젝트가 8개의 MLOps 프레임워크를 어떻게 활용하는지 API 사용, CLI 사용, CI/CD 통합 측면에서 종합적으로 분석했습니다.
2. 기능 요청 분류 체계: 커뮤니티의 요구사항을 특정 MLOps 파이프라인 단계 및 거버넌스 관심사와 매핑하는 14개의 상위 카테고리 및 37개의 하위 카테고리로 구성된 계층적 기능 요청 분류 체계를 개발했습니다.
3. 사용과 수요의 상관관계: 실제로 프로덕션 코드에서 사용되는 기능과 커뮤니티에서 요청되는 기능 간의 관계를 매핑하여, 그 사이의 격차와 정렬 상태를 밝혀냈습니다.
4. 재현 패키지: 분석에 사용된 데이터셋과 스크립트를 공개적으로 제공합니다.

주요 결과

• 사용 패턴 (RQ1): MLOps 프레임워크는 명령줄 인터페이스(CLI)나 GitHub Workflow 내에서 "기본 설정 그대로(out-of-the-box)" 사용되는 경우가 드뭅니다. 대신, 개발자들은 주로 맞춤형 기능을 구현하기 위해 Python 스크립트 내에서 프레임워크의 API를 활용합니다. GitHub Workflow의 명시적인 단계로 이 프레임워크들을 사용하는 프로젝트는 단 24개에 불 불과했습니다.
• 기능 활용도 (RQ2):
  • MLFlow와 Wandb는 가장 널리 채택되었으며, 주로 실험 추적(파라미터, 메트릭, 아티팩트 로깅) 및 인프라 거버넌스를 위해 사용됩니다.
  • BentoML은 거의 독점적으로 모델 배포(모델을 컨테이너로 패키징)를 위해 사용됩니다.
  • Kedro, Metaflow, Prefress는 ML 파이프라인을 정의하고 오케스트레이션하는 데 사용되지만, 추적 도구들에 비해 채택률은 낮습니다.
  • Deepchecks와 Evidently AI(검증 및 모니터링 중심)는 매우 적은 프로젝트에서만 사용되었으며, 이는 오픈 소스 프로젝트의 프로덕션 모니터링에 대한 성숙도 격차를 시사합니다.
  • 공동 사용(Co-usage): 개발자들은 보완적인 기능을 활용하기 위해 여러 프레임워크를 빈번하게 결합합니다(29개 프로젝트에서 발견, 예: MLFlow로 추적하고 Prefess로 오케스트레이션).
• 희망 개선 사항 (RQ3): 기능 요청 분류 체계에 따르면, 사용자들은 완전히 새로운 기능보다는 핵심 기능에 대한 개선을 주로 요구합니다. 주요 요청 사항은 다음과 같습니다:
  • API 노출: 기존 기능에 대한 더 나은 인터페이스 및 문서화.
  • CI/CD 통합: 파이프라인에 프레임워크를 통합하기 위한 개선된 훅(hook) 및 자동화.
  • 모니터링: 더 나은 런타임 관측성(observability) 및 파이프라인 상태 추적.
  • 보안 및 개인정보 보호: 인증 및 데이터 보안 기능.

의의 및 주장
본 논문은 현재 오픈 소스의 MLOps 상태가 표준화된 기본 솔루션이나 CI/CD 통합에 의존하기보다, 프레임워크 API를 사용하여 독자적인 워크플로를 구축하는 맞춤형 중심(customization-heavy) 접근 방식으로 특징지어진다고 주장합니다. 본 연구는 고급 MLOps 기능(예: 실시간 모니터링)의 가용성과 오픈 소스 프로젝트에서의 실제 채택 사이에 존재하는 괴리를 강조합니다.

저자들은 본 연구의 결과가 다음을 위한 기초를 제공한다고 제안합니다:

• 실무자: 전형적인 사용 패턴을 이해하고 도구를 효과적으로 결합하는 방법 파악.
• 도구 제작자: 경험적 수요에 기반하여 API 개선, 문서화 및 CI/CD 통합의 우선순위 결정.
• 연구자: 프레임워크 설정에 대한 추천 시스템 개발.

본 논문은 자신의 연구 범위가 오픈 소스 Python 프로젝트에 국한되어 있으며, 폐쇄형 산업용 애플리케이션의 성숙도를 완전히 반영하지 못할 수 있음을 인정하며 겸허한 범위를 유지합니다. 또한 이러한 패턴을 검증하기 위해 산업 환경에 대한 추가 조사가 필요함을 명시합니다.