데브옵스보다 데이터 학습 테스팅 배포가 한층 자동화
전체 프로세스가 더 효율적…모델 예측 서비스도 자동 재학습, 배포
[애플경제 이보영 기자] 데브옵스와 유사하지만, 머신러닝을 구심점삼아 앱 개발과 IT운영을 통합한다는 의미의 MLOps가 새삼 주목을 받고 있다. 그러나 데브옵스와는 다른 머신러닝 작동방식과 학습 모델의 검증 모델 구축 등에서 MLOps만의 특장점이 있다는 주장이다. 이를 위한 깊이있는 분석을 가한 한상기 테크프론티어 대표는 최근 한국지능정보사회진흥원 ‘이슈 리포트’에서 “2020년 이후부터 데이터에서 비즈니스 가치를 최대한 추출하기 위해 인공지능과 머신 러닝을 위한 데이터 모델을 추적하고 데이터 셋을 제어하면서 전제 생산 라이프사이클을 최적화하기 위한 자동화 프로세스를 고민한 결과”라고 그 개념과 취지를 설명하고 있다.
이는 데이터옵스나 AI옵스 등과 마찬가지도 소프트웨어를 구축, 관리하고, 유지, 검사, 배포하는 프로세스를 효율적이면서 정확하게 하겠다는 점에서 취지를 같이하고 있다. 다만 데브옵스와는 그 운영과 효율성, 작동 방식에서 차이가 있다. 한 대표는 “데브옵스가 기본적으로 개발의 생산성과 운영의 안정성을 최적화하기 위한 방법 내지 조직 운영 방식의 변화라면, 운영팀과 연구자들 사이에서 머신 러닝 모델의 관리 로지스틱스 배포를 단순화하기 위한 것이 MLOps”라고 설명했다. 가장 큰 차이는 역시 머신 러닝이 작동하는 방식에서 비롯된다.
그에 따르면 MLOps는 머신러닝의 작동 방식, 즉 데브옵스보다 데이터 학습 테스팅 배포가 한층 자동화될 수 있어서 전체 작업 프로세스가 훨씬 더 효율적이 된다. 데이터 과학자나 머신 러닝 연구자들이 더 많은 프로젝트와 모델 개발을 할 수 있게 한다. 이는 “크게 보면 데이터를 수집하는 과정과 데이터를 사용할 수 있게 준비하는 과정, 그리고 모델을 학습 및 평가 후 배포하는 과정으로 볼 수 있다.”는 것이다. 실제로 엔비디아는 머신 러닝 애플리케이션 개발 운영을 결합한 통합적 IT접근 방식으로 이를 정의하고 있다.
엔비디아의 개념에 따르면 데이터는 수집 후 정제하고, 머신 러닝 모델에 사용할 수 있게 라벨링 하고 검수하는 과정이 필요하다. 이렇게 준비된 머신 러닝 대응 데이터셋으로 모델을 학습한 후 평가하고 시스템 검증을 해야 한다 이후 성능 평가를 통해 추가 데이터 수집이 필요할 수 있으며 이를 지속적으로 수행하는 과정이 반복될 수 있다. 곧 MLOps의 기능이 필요한 이유다.
최근에는 이런 기능이 클라우드컴퓨팅 서비스의 일부로 제공되는 경우가 많다. 그렇다보니 아예 자체적으로 인공지능 연구와 함께 MLOps를 개발하고 있는 기업들도 적지 않은 실정이다. 그러나 “머신 러닝을 기업에서 사용하려고 하면 어떤 방법을 통해 효과적으로 MLOps를 구현할 것인가를 고민해야 한다”면서 “그러자면 기업의 입장에서는 머신 러닝 모델이나 코드는 전체 시스템의 극히 .부분이며 전체 시스템을 생각해야 한다”는게 전문가들의 조언이다. 앞서 한 대표는 그래서 “구글은 머신 러닝 코드와 다른 시스템 컴포넌트의 관계를 설명했고 이를 다시 구글 클라우드에서 재해석했다”는 점을 강조하기도 했다.
특히 지속적 통합과 배포의 개념을 갖고 있는 데브옵스와는 달리, MLOps만의 특성과 차이를 잘 이해해야 한다는 지적이다. 이를 이해 데브옵스와는 다른, MLOps만의 특장점에 유의할 것을 주문하고 있다.
이에 따르면 우선 지속적 통합은 코드와 구성 요소만 테스트하고 검증하는 것에 그치지 않는다. 나아가선 데이터의 스키마나, 모델도 테스트해야 하는 것이다. 또 지속적 배포는 모델 예측과 같은 다른 서비스도 자동으로 배포해야 한다는 점이다. 특히 ‘지속적 학습’은 머신 러닝 시스템의 고유한 속성으로 후보 모델을 자동으로 재학습하는 것을 말한다. ‘지속적 모니터링’은 오류를 잡아내는 것뿐 아니라, 프로덕션 추론 데이터나 비즈니스 성과와 관련된 모델 성능 측정 항목을 모니터링하는 것을 포함한다.
이 대목에서 특히 구글이 정의한 데브옵스와의 차이에 주목해야 한다는 주장이다. 즉 “데브옵스와는 달리, 보유한 기술이 탐색적 데이터 분석 모델의 개발이나 실험에 중점을 두는 데이터 과학자나, 머신 러닝 연구원 중심이란 사실이다. 때론 서비스를 빌드하는 소프트웨어 엔지니어가 없을 수도 있다”는 것이다. 한 대표는 특히 “구글은 개발 머신 러닝의 경우 특성 알고리즘 모델링 기법상의 매개 변수 구성을 다양하게 시도해 문제에 가장 적합한 것을 최대한 빨리 찾아내야 한다는 점을 강조한다”면서 “개발 과정에서 도전 과제에 효과가 있었던 것을 추적하고, 코드 재사용성을 극대화하면서 재현성을 유지한다”고 인용했다.
그에 따르면 구글은 또한 테스트 머신 러닝 시스템 테스트가 다른 소프트웨어 시스템 테스트보다 더 복잡하다는 점을 강조한다. 그래서 일반적인 단위나 통합 테스트 외에도 데이터가 검증되고 학습된 모델의 품질을 평가하는 모델의 검증이 필요하다는 것이다. “그 결과 배포 모델을 자동으로 재학습시키고 배포하기 위해 다단계 파이프라인을 배포해야 하는 경우도 많다”면서 “그처럼 복잡한 파이프라인을 사용하면 데이터 과학자가 배포하기 전에 새 모델을 학습시키고 검증하기 위해 수동으로 수행되어야 하는 단계를 자동화해야 한다”고 해석했다.