데이터 이야기 #7: 기타 데이터 직군 - MLOps 엔지니어

ML 모델 개발 과정에서 자주 발생하는 공통적인 문제점들은 다양하다. 처음 한번은 어떻게 전체 프로세스를 돌리고 모델을 만들고 배포할 수 있지만 다음 번에 모델을 다시 빌드해야 한다면 얼마나 빠르게 실수없이 할 수 있느냐가 정말 중요한 포인트가 되며 여기서 경쟁력이 달라진다.

왜 모델을 다시 빌드할 필요가 있느냐고 반문할지도 모르겠다. 그 이유는 데이터의 패턴이 달라지는 경우 옛날 데이터로 빌드된 모델의 성능이 떨어지기 시작하기 때문이다. 이를 Data Drift라고 부른다. 실제로 야후 때 경험을 놓고 보면 검색 랭킹을 ML 모델로 만들고 이걸 1년 동안 방치(?)해보니 결과의 클릭률이 30%가 떨어지는 걸 관찰한 적이 있었는데 그 이유는 웹에 만들어지는 문서의 패턴이 바뀌고 쿼리의 패턴이 바뀌면서 모델을 훈련할 때 사용했던 훈련 데이터와 지금 모델로 들어오는 데이터가 달라졌기 때문이었다. 즉 머신 러닝 모델의 중요 피처의 데이터 분포(평균, 표준편차 등등)를 계속해서 모니터링하다가 달라지면 모델을 다시 빌드할 필요가 있다.

그러면 모델의 재빌딩이란 측면에서 어떤 문제들이 있는지 이야기해보자. 몇 가지만 이야기해봐도 다음과 같은 것들이 있다.

• 훈련용 데이터셋의 관리가 큰 문제로 작용할 수 있다. 데이터의 품질, 양, 그리고 다양한 조건에 따라 모델 성능이 크게 달라지기 때문에 데이터를 체계적으로 관리하고 업데이트하는 것이 중요하다. 무엇보다 마지막 모델 빌드시 사용했던 훈련용 데이터셋이 무엇인지 알고 다시 사용할 수 있게 관리해야 한다.

• 피처를 계산하는 방법, 즉 피처 엔지니어링 과정에서 사용되는 코드의 관리도 중요한 이슈다. 이 코드를 GitHub 등에 관리하면서 유닛 테스트등을 도입해야 일관성 있는 결과를 도출할 수 있다. 이는 소프트웨어 개발자에게는 당연하게 받아들여지는 과정일 수 있지만 데이터 과학자들에게는 익숙하지 않은 과정인 경우가 많고 여기서 생기는 이유가 생각보다 많다.

• 모델을 처음 빌딩할 때 어떤 머신러닝 알고리즘을 사용하고 이와 함께 사용한 하이퍼 파라미터들이 무엇인지, 그리고 이들을 어떻게 조정했는지도 중요한 문제이며 이 모든 것들이 문서화가 되고 기록이 되어야 나중에 모델을 다시 만들 때 시간 낭비를 하지 않는다.

• 초기 개발 단계에서는 노트북에서 수동으로 모델을 빌딩하는데, 이러한 과정을 체계화하거나 자동화하지 않으면 나중에 재현하기 어렵고, 팀 간의 협업이 어려워질 수 있다.

• 만들어진 모델을 배포하는 것도 중요하다. 보통 API 형태로 배포하는 것이 일반적인데 이 경우 백엔드 엔지니어링 팀이나 데브옵스 엔지니어링 팀과 밀접한 협업이 필요하다. 배포할 때마다 긴밀하게 협업을 해야한다면 이는 배포의 주기가 잦은 경우 큰 문제가 된다. 즉, 이 부분은 최대한 자동화하고 프로세스(monitoring & troubleshooting)를 만들 필요가 있다. 모니터링이란 측면에서는 data drift와 API의 수행시간 (latency) 등이 중요한 포인트가 된다.

• 마지막으로, 모델의 성능을 평가하기 위한 AB 테스트 프로세스도 매우 중요하다. 실제 사용자에게 제공하기 전에 모델이 제대로 작동하는지 확인하고, 새로운 모델이 기존 모델보다 나은 성능을 보이는지를 평가하는 것이 필수적이다.

즉 위의 일은 머신 러닝 모델만 빌드하던 데이터 과학자나, 데이터 파이프라인만 관리하던 데이터 엔지니어나, 온라인 시스템을 모니터링하고 트러블슈팅을 하던 데브옵스 엔지니어가 혼자 하기에는 벅찬 일이다. 그래서 생긴 직군이 바로 MLOps 직군이며 다음 3가지 역할을 수행하게 된다. 즉 주니어가 하기에는 많은 경험을 필요로 하는 일이라 할 수 있다.

1. 데이터 과학자 (혹은 ML 엔지니어)

2. 데이터 엔지니어

3. 데브옵스 엔지니어

그렇다고 MLOps 엔지니어가 머신 러닝 모델을 직접 빌드하는 역할은 하지는 않는다. 그런 관점에서는 데브옵스 엔지니어와 비슷한 부분이 있는데 데브옵스 엔지니어의 경우 서비스 코드를 직접 작성하지는 않지만 다른 개발자들이 만든 코드를 테스트하고 패키지하고 배포하고 모니터링하고 트러블슈팅을 하며 이 과정을 최대한 자동화하게 된다. MLOps 엔지니어의 경우에는 다른 사람들(보통 데이터 과학자)이 만든 모델을 대상으로 동일한 일을 수행하게 된다.

머신 러닝 모델이 점점더 많은 영역에서 사용되다보니 MLOps와 같은 직군이 중요해지고 그러다보니 관련한 툴/프레임웍들이 많이 나오고 있다. 개인적으로 많이 사용해본 것은 AWS의 SageMaker이고 가볍게 사용해본 것으로는 Databricks에서 만든 MLflow가 있다.

다음 포스팅에서 프라이버시 엔지니어에 대해 이야기해보고자 한다.