제가 생각하기에 MLOps도 결국 자동화된 파이프라인이 중요하기에, 기존의 GitHub Actions나 GitLab CI 등으로만으로도 충분할 거 같다는 막연하게 생각하고 있습니다만… 막상 구체적으로 MLOps 관련된 기술을 보면 Prefect, Dagster, Airflow, MLflow, KServe, Kubeflow, Kuberay 등 여러가지 오픈소스 기술들이 있는데… 실제 환경에서는 어떻게 사용하는지 궁금해서 문의 남겨봅니다.
1 Like
GitHub Actions나 GitLab CI만으로 MLOps를 시작하겠다는 판단은 충분히 현실적이고 합리적합니다. 실제 현업에서도 대부분은 기존 CI/CD를 기본 골격으로 삼고, 필요해질 때마다 전용 도구를 선택적으로 붙이는 방식으로 운영하고 있습니다.
즉, 처음부터 Kubeflow·KServe·MLflow 같은 도구 풀세트를 도입하는 것이 정답이라기보다는, 지금 겪고 있는 병목이 무엇인지에 따라 도구를 고르는 것이 핵심에 가깝습니다.
다만 MLOps 영역으로 들어오면, 왜 전용 오픈소스들이 계속 등장했는지에 대한 나름의 ‘현실적인 이유’가 분명히 존재합니다. 이는 단순한 유행이라기보다는, 전통적인 소프트웨어 개발과 다른 ML 워크로드의 특성에서 비롯된 경우가 많습니다.
첫째, ML에서는 코드뿐 아니라 데이터 자체가 주요 변경 요인이 됩니다.
코드는 그대로인데 데이터 분포가 바뀌면 모델 성능이 자연스럽게 저하되는 경우가 흔합니다. 이런 상황에서는 단순 배포 자동화보다, 데이터 전처리·학습·재학습 조건을 유연하게 제어할 수 있는 워크플로 오케스트레이션이 중요해지고, 이 지점에서 Airflow·Prefect·Dagster 같은 도구들이 의미를 갖습니다.
둘째, ML 프로젝트에서는 실험의 기록과 모델의 계보 관리가 필수입니다.
“왜 이전 모델보다 성능이 떨어졌는지”, “어떤 데이터와 파라미터를 사용했는지”를 설명하지 못하면 운영 단계에서 곧바로 혼란이 발생합니다. MLflow는 이 문제를 해결하기 위해 실험 로그, 하이퍼파라미터, 모델 아티팩트를 체계적으로 관리하는 역할을 합니다. 이는 일반적인 CI/CD 도구가 의도한 범위를 넘어서는 영역입니다.
셋째, 인프라 자원, 특히 GPU 활용의 효율성 문제입니다.
GitHub Actions Runner 환경에서 대규모 학습이나 서빙을 처리하기에는 구조적·비용적 한계가 있습니다. Kubeflow나 KubeRay는 쿠버네티스 기반 분산 학습을 자연스럽게 지원하고, KServe는 트래픽에 따라 자원을 자동으로 확장·축소하며 서빙 비용을 최적화합니다. 이 부분은 규모가 커질수록 체감 차이가 커집니다.
다만 다시 강조하자면, 실제 환경에서는 이런 도구들을 모두 사용하는 경우는 드뭅니다.
보통은 CI/CD는 GitHub Actions, 학습·전처리 파이프라인은 Airflow 또는 Prefect, 실험 관리는 MLflow, 서빙 단계에서만 KServe를 사용하는 식으로 필요한 부분만 조합합니다.
정리하면,
초기에는 기존 CI/CD 도구로 가볍게 시작하고,
학습 데이터 규모가 커지거나, 실험 관리가 부담되기 시작하거나, GPU 비용과 운영 복잡도가 문제로 떠오를 때,
그 시점에 맞춰 전용 도구를 검토하는 접근이 가장 실패 확률이 낮았습니다.
결국 도구의 수보다 중요한 것은,
모델을 얼마나 빠르고 안전하게 비즈니스 가치로 전환할 수 있느냐라고 생각합니다.
2 Likes