MLOps란 무엇인가?

MLOps TIME!

01. [Why] MLOps가 왜 필요한가?

MLOps는 ML + Operations가 결합된 단어라는 것은 이미 많이들 알고 있는 사실이지만, 도대체 왜! MLOps가 필요한지, MLOps를 위해선 무엇이 필요한지 아는 사람은 정작 많이 없는 것 같다. 아마 그 이유는 MLOps라는 개념이 아직 널리 퍼지지 않았을뿐더러, 대표적인 프레임워크로 제안되는 Kubeflow, Airflow, MLflow와 같은 툴이 완벽하게 MLOps를 구현했다고 보기 어렵기 때문으로 보이기도 한다.

MLOps가 왜 필요한지 한 장의 이미지로 표현하면 다음과 같다.

MLOps가 필요한 배경

ML Project를 연구/개발하는 단계에선 실질적으로 MLOps에 대한 필요성을 크게 느끼지 못한다. 그 필요성을 느끼는 것은 해당 Project가 Service화되고, Service화되었으니 지속적으로 업데이트해야하고, 성능 개선과 기능 추가가 이뤄지는 과정에서 여러 직군의 개입이 필요해졌다. 또 동시에 Project Cycle 주기는 짧아져야 하는 필요성은 높아진다.

 

하지만 여러 직군의 개입은 필연적으로 작은 테스트 하나를 위해서도 여러 번의 소통과 협업을 전제로 하기에, 필요성과는 반대로 프로젝트는 점점 무거워진다.

 

다음의 구글의 ML 프로젝트의 기술부채에 관련한 논문에서 소개된 이미지를 보면, 왜 우리가 MLOps라는 방법론에 집중해야 하는지 확인할 수 있다.

ML Project에서 각 작업별 투입되는 자원의 양(출처 : Hidden Technical Debt in Machine Learning Systems, google, 2015 )

위의 그림은 실제 ML 프로젝트에 있어 ML code에 투입되는 자원(시간, 인력, 코드)이 다른 기타 작업에 비해 훨씬 적음을 시사한다. 이는 결코 ML code가 중요하지 않다거나, 다른 기타 작업이 더 중요하니 그곳에 집중해야 한다는 뜻이 아니다!

 

해당 논문에선 ML project가 초기 개발과 배포에 있어선 적은 비용으로 가능하지만, 해당 서비스가 유지되면서 늘어나는 다양한 종류의 기술부채(데이터, 모델, 환경설정, 안티패턴 등)를 경고한다. 즉, 명백하게 더 중요한 작업인 ML code에 적은 시간이 들어가는 것이 문제이기에 다른 작업에 들어가는 시간을 최소화/최적화할 방법을 찾으라는 것.

 

때문에 MLOps는 Data Scientist가 본연의 업무에 집중할 수 있도록 하는 대전제를 두고, 이를 해결할 수 있는 방법론들을 모아놓은 형태에 가깝다.

 

02. [How] MLOps를 어떻게 이뤄낼 수 있는가?

구체적으로 MLOps는 다음과 같이 크게 네 가지 핵심 과제를 달성하는 과정에서 완성되어 간다고 할 수 있다.

MLOps를 달성을 위한 과제

1) 최적화된 환경, 버전 관리

- ML Project는 필연적으로 여러 버전에 대한 관리를 요구한다. 안정화된 배포 환경부터, 누적되는 데이터, 학습된 모델, 그리고 그 모델을 학습하기 위한 메타데이터부터, 파이프라인 단위의 배포까지 버전별 관리와 배포가 필요해진다.

- 주요 도구로는 git, gitlab, docker, kubernetes 등이 존재한다.

 

2) 프로젝트 목적에 맞는 파이프라인 단위 관리, 배포

- MLOps를 구성하는 과정에선 각 작업을 독립적으로 구분하고, 각 작업을 유기적으로 연결시키며, 이 전체 작업을 대상으로 관리하고, 수정하고, 배포하게 된다.

- 요구되는 MLOps의 수준에 따라 이러한 Workflow의 규모가 결정된다.

 

3) 각 Workflow 독립작업에 대한 시간 최소화

- 병목 작업이 되어버리는 Workflow가 존재한다면 이를 최우선적으로 최적화/최소화시키기 위해 적절한 tool을 사용하거나, 만들어야 한다.

- 이와 관련해 데이터 annotation 작업을 위해 기존 학습한 모델을 이용하는 active learning이나 Auto Labeling과 같은 방법론이 존재하며, 모델링과 관련해서도 널리 알려진 AutoML 등을 사용할 수 있다.

 

4) 각 Workflow 내외의 글루코드/설정작업 등 반복작업 자동화

- 각 Workflow를 세분화시켜 분업화하는 과정은 추후 MSA와의 결합 등을 용이하게 할뿐 아니라, 문제 상황에서의 빠른 해결을 가능하게 하지만 이 과정에서 각 WF 간 호환을 위한 작업이 추가로 필요하다. 보통 주요 작업 단계 혹은 담당한 역할군에 따라 구분되는 Workflow 간 호환을 위한 configuration file 등이 자동으로 수정/업데이트 되도록 사전작업을 해놓는 것이 중요하다.

 

03. 마치며...

아직까지 MLOps를 어떤 것이라 명확히 정의된 것은 존재하지 않으며, 위에서 제시한 바와 같이 각 역할군의 사람들이 본연의 업무에 리소스를 집중시킬 수 있게 하기 위한 사전작업의 개념 정도로 받아들이면 좋을 것 같다.

물론 현재 여러 서비스와 생태계가 제시되고 있지만 엄밀히 말해 그들조차 정확한 MLOps라고 할 수는 없다. 아니 정확히 말하면 그들도 물론 MLOps라 부를 수 있을 것이나, 그들이 제공하는 것이 MLOps의 전부라고 여기면 안된다는 말이 정확할 것 같다.

 

개인적으로 MLOps 개념을 MSA 수준에서 가장 잘 구현한 것은 MathWorks가 아닐까 싶다. 이들은 최근 들어 조명받는 Data-Centric한 Tool들을 여럿 제시한다. 다만 전체 과정을 관리하거나 자동화, 배포하기 어렵다는 한계가 존재하기에 독립적으로 사용할 수는 없다.

 

그렇기에 대안으로 제시되는 것이 Kubeflow나 Airflow와 같은 프레임워크이다. 이들은 Kubernetes, Docker 등을 중심으로 짜여진 일종의 생태계적 플랫폼의 형태에 가까우며, 지금도 빠르게 업데이트되며 수많은 기능들을 추가하고 있다. 전체적인 구조를 짜고, 관리하고, 모니터링하기 위한 여러 툴을 제시함과 동시에 빠르게 업데이트된다는 것은 아주 큰 장점임과 동시에 단점이다.

 

자칫하면 이들을 사용하기 위해 여러 사람들이 협업과 소통을 반복하는 추가적인 병목공정이 생겨날 우려가 존재하는데, 이는 각각의 대표적인 WF 기능을 완전히 지원하는 MSA가 존재하지 않기에, 가능성을 열어두었고 그로 인해 dependency 문제나 보안 문제 등이 추가적으로 발생하며 다시 새로운 문제의 발생, 새로운 전문가의 필요성이 생겨나는 기묘한 Cycle을 그리기도 한다.

 

간단히 말하자면 이들은 MLOps를 위한 Framework이지만, 너무 복잡하고 더욱 복잡해지고 있다!

때문에 각각의 영역에서 소위 진리라 부를만한 MSA가 등장하고, 인정받고, 이에 대한 사용을 위해 기본적인 환경설정부터 시작하지 않아도 되는 시점에서 제대로 된 MLOps가 이뤄질 수 있을 것으로 보인다.

 

그러니 지금은 다소 막막하더라도, 하나하나 다 공부하고 배워가며 진행하는 수밖에 없다.

그게 결론이다.