MLOps 10 - MLOps 플랫폼 구축

조각들을 하나로 모으면

이 시리즈에서 다루어온 구성 요소들 — 데이터 파이프라인, 실험 추적, 모델 레지스트리, 서빙 인프라, 모니터링, 피처 스토어, GPU 인프라 — 은 각각 독립적으로 가치를 제공한다. 그러나 이 구성 요소들이 서로 연결되지 않은 채 개별 도구로만 존재하면, 엔지니어는 도구 사이의 간극을 수작업으로 메워야 한다. 실험에서 배포까지의 경로가 자동화되지 않고, 각 단계의 결과물을 다음 단계에 수동으로 전달하는 상황이 반복되는 것이다.

MLOps 플랫폼은 이 구성 요소들을 하나의 통합된 시스템으로 엮어, 모델의 전체 라이프사이클이 일관된 워크플로우로 운영되게 하는 것이 목표이다.

엔드투엔드 ML 플랫폼

현재 대표적인 ML 플랫폼은 크게 오픈소스와 관리형 서비스로 나뉜다.

Kubeflow는 Kubernetes 위에 구축된 오픈소스 ML 플랫폼이다. 파이프라인 오케스트레이션(Kubeflow Pipelines), 모델 서빙(KServe), 노트북 환경(Jupyter), 하이퍼파라미터 튜닝(Katib) 등의 구성 요소를 제공한다. Kubernetes에 대한 깊은 이해가 필요하고 운영 부담이 크지만, 커스터마이징의 자유도가 높다는 것이 강점이다.

Google의 Vertex AI와 AWS의 SageMaker는 관리형 서비스로, 인프라 운영 부담 없이 ML 파이프라인을 구축할 수 있게 한다. 데이터 전처리부터 모델 배포, 모니터링까지 하나의 서비스 안에서 처리할 수 있다. 다만 특정 클라우드에 종속된다는 점과, 세밀한 커스터마이징이 제한될 수 있다는 점은 고려해야 한다.

구축인가, 구매인가

ML 플랫폼을 자체 구축할 것인지 기존 서비스를 사용할 것인지는 조직마다 다른 답을 가진다. 과연 자체 구축이 항상 우월한 선택인가? 그렇지 않다.

자체 구축은 조직의 워크플로우에 정확히 맞는 플랫폼을 만들 수 있다는 장점이 있지만, 구축과 유지보수에 상당한 엔지니어링 인력이 필요하다. ML 엔지니어 5명으로 구성된 팀이 플랫폼 구축에 절반의 시간을 쓴다면, 정작 모델 개발에 투입할 수 있는 역량이 줄어드는 셈이다.

관리형 서비스는 빠르게 시작할 수 있고 운영 부담이 적지만, 서비스가 지원하지 않는 워크플로우를 구현하기 어렵다. 많은 조직이 초기에는 관리형 서비스로 시작하여 빠르게 가치를 검증하고, 규모가 커지면서 특정 구성 요소만 자체 구축으로 전환하는 점진적 접근을 택하는 것이 이러한 이유에서이다.

핵심은 플랫폼 구축 자체가 목적이 되어서는 안 된다는 것이다. 플랫폼은 ML 엔지니어와 데이터 사이언티스트가 모델을 빠르고 안정적으로 프로덕션에 반영하는 것을 돕기 위한 수단이다.

누가 플랫폼을 소유하는가?

기술적인 아키텍처만큼이나 중요한 것이 조직 구조이다. ML 플랫폼을 누가 구축하고, 누가 운영하며, 누가 사용하는지를 명확히 하지 않으면 책임의 공백이 생긴다.

일반적으로 세 가지 모델이 존재한다. 첫째, 중앙 플랫폼 팀이 플랫폼을 구축하고 운영하며, ML 팀들이 사용자로서 플랫폼을 활용하는 구조이다. 플랫폼의 일관성이 높지만, 중앙 팀이 병목이 될 수 있다. 둘째, 각 ML 팀이 자체 인프라를 관리하는 분산 모델이다. 팀별 자율성이 높지만, 중복 투자와 일관성 부족이라는 대가를 치르게 된다. 셋째, 플랫폼 팀이 공통 기반을 제공하고 각 팀이 그 위에 자신의 워크플로우를 구축하는 하이브리드 모델이다.

이 구조는 플랫폼 엔지니어링에서 다루었던 내부 개발자 플랫폼(IDP)의 개념과 맞닿아 있다. ML 플랫폼 팀도 결국 하나의 제품을 만드는 것이며, 그 제품의 고객은 같은 조직 내의 ML 엔지니어와 데이터 사이언티스트인 것이다. 셀프서비스, 골든 패스, 인지 부하 감소라는 플랫폼 엔지니어링의 원칙이 ML 플랫폼에도 동일하게 적용된다.

성숙도 로드맵

모든 조직이 처음부터 완전한 ML 플랫폼을 필요로 하는 것은 아니다. 성숙도에 따라 단계적으로 구축하는 것이 현실적이다.

첫 번째 단계에서는 버전 관리와 실험 추적부터 시작한다. Git으로 코드를 관리하고, MLflow나 Weights & Biases로 실험을 기록하는 것만으로도 재현성이 크게 향상된다.

두 번째 단계에서는 파이프라인 자동화를 도입한다. 데이터 전처리부터 모델 학습까지의 과정을 Airflow나 Kubeflow Pipelines로 자동화하여, 수동 개입 없이 반복 실행할 수 있게 한다.

세 번째 단계에서는 서빙과 모니터링을 체계화한다. 모델 레지스트리에서 승인된 모델을 자동으로 배포하고, 프로덕션 성능을 실시간으로 모니터링하여 드리프트를 감지하는 구조를 갖춘다.

네 번째 단계에서는 피처 스토어, GPU 스케줄링 최적화, CI/CD for ML 등 고도화된 구성 요소를 추가하여 완전 자동화된 ML 라이프사이클을 운영하게 된다.

Level 1: 실험 추적 + 버전 관리
    ↓
Level 2: 파이프라인 자동화
    ↓
Level 3: 서빙 + 모니터링 체계화
    ↓
Level 4: 완전 자동화 ML 라이프사이클

각 단계는 이전 단계의 기반 위에 쌓이며, 조직의 필요에 따라 속도를 조절하면 된다. 중요한 것은 현재 단계에서 가장 큰 병목이 무엇인지를 파악하고, 그 병목을 해결하는 구성 요소를 우선적으로 도입하는 것이다.

시리즈를 마치며

이 시리즈는 MLOps의 전체 지형을 조망하기 위한 것이었다. ML 라이프사이클의 현실에서 출발하여, 데이터 파이프라인, 실험 관리, 모델 서빙, 모니터링, 피처 스토어, GPU 인프라를 거쳐, 이 모든 것을 하나로 엮는 플랫폼 구축까지 다루었다.

MLOps는 특정 도구나 프레임워크가 아니라, 모델을 프로덕션에서 안정적으로 운영하기 위한 엔지니어링 원칙의 집합이다. 도구는 계속 변하지만, 재현성, 자동화, 모니터링, 협업이라는 근본적인 원칙은 변하지 않는다. 이 시리즈에서 다룬 각 구성 요소를 조직의 상황에 맞게 조합하고 발전시켜 나가는 것이 MLOps 실천의 핵심이다.