한빛출판네트워크

2010년 후반부터 머신러닝이 널리 사용되면서 머신러닝 시스템을 체계적이고 효율적으로 구축할 수 있는 접근법의 필요성이 대두되었습니다. 이에 따라 2020년경에는 머신러닝 엔지니어에 대한 수요가 급증했습니다. 머신러닝 엔지니어는 잘 정립된 DevOps 모범 사례를 머신러닝 기술에 적용합니다. 주요 클라우드 공급 업체들은 이러한 실무 엔지니어들을 대상으로 교육 프로그램과 인증 프로그램을 운영하고 있죠. 

구글이 발급하는 전문 머신러닝 엔지니어 자격증에 따르면 머신러닝 엔지니어는 ‘비즈니스 문제를 해결하기 위해 모델을 설계하고 구축하는 사람’으로 정의됩니다. 그 외에도 마이크로소프트와 아마존은 각각 애저 데이터 과학자 자격증, AWS 공인 머신러닝 전문가 자격증을 발급하며 자격증을 보유한 전문가를 ‘머신러닝 워크로드를 구현하고 동작하도록 만들기 위해 데이터 과학 및 머신러닝에 대한 지식을 활용하는 사람’과 ‘비즈니스 문제를 해결하는 머신러닝 솔루션을 설계, 구현, 배포, 유지 보수하는 사람' 등으로 설명합니다.

머신러닝 엔지니어와 MLOps의 부상

데이터 과학과 머신러닝 엔지니어링을 비교할 때 과학과 엔지니어링의 차이가 무일까요? 과학은 연구에 초점을 맞추고, 엔지니어링은 상품을 통해 가치를 만드는 일에 집중합니다. 이전과 달리 기업들은 머신러닝을 단순히 연구 대상으로 보지 않고, 머신러닝을 통해 가치를 만들기 시작했습니다. 동시에 직원 고용 및 기술 투자에 따른 수익(ROI)도 기대하고 있죠. 

페이스케일과 글래스도어에 따르면 2020년 4분기 데이터 과학자, 데이터 엔지니어, 머신러닝 엔지니어의 연봉 중간값이 비슷했습니다. 또한 구인구직 플랫폼 링크드인에 따르면 2020년 4분기 구인공고 조사 결과에서 클라우드라는 단어가 19만 개, 데이터 엔지니어링이 7만 개, 머신러닝 엔지니어링이 5만 5천 개, 데이터 과학이 2만 개 수준으로, 연구자에 대한 수요보다 엔지니어의 수요가 더 많다는 사실을 확인할 수 있습니다.

이러한 직업 트렌드가 기술의 하이프 사이클Hype Cycle*을 따르고 있다고도 해석할 수 있습니다. 회사들은 ROI를 높이기 위해 클라우드 컴퓨팅, 데이터 엔지니어링, 머신러닝 같은 하드 스킬을 갖춘 직원이 필요하다는 것을 알고 있습니다. 그리고 이런 직원들이 데이터 과학자보다 훨씬 더 많이 필요하다는 것도 알고 있죠. 앞으로 10년간은 데이터 과학자라는 직업 타이틀과 상관없이 데이터 과학은 문제를 해결하거나 가치를 만들어내는 행위라는 본질에 집중하게 될 것입니다.

* 하이프 사이클(Hype Cycle): IT 분야 전문 리서치 그룹 가트너가 제안한 개념으로 기술의 성숙도를 표현하기 위한 그래프를 뜻한다. Hype는 ‘과장되거나 부풀려진 것’을 의미한다. 하이프 사이클에 따르면 대부분의 기술은 관심을 받기 시작하여 부풀려진 기대의 정점에 도달하게 되고, 이후 관심이 시들해졌다가 점차 시장의 주류에서 성과를 거두게 된다고 생각한다.

DevOps의 계보를 잇는 MLOps

머신러닝이라는 강력한 기술을 사용한 시스템이 때로는 고전적인 소프트웨어 시스템만큼도 효용을 내지 못하는 이유가 무엇일까요? 머신러닝 시스템에서 문제를 일으키는 요소는 머신러닝 모델링이 아닙니다. 머신러닝을 이용해서 문제를 해결하는 것이 합리적인 생각인지 따져보는 일부터 비즈니스 문제를 정의하는 일이나 데이터 엔지니어링까지도 관련 있기 때문이기도 합니다.

머신러닝 기술을 이용해 비즈니스 문제를 해결하는 것에는 크게 관심이 없고 세부적인 기술에만 초점을 맞추려고 하기 때문일지도 모릅니다. 상사가 높은 의사 결정력을 갖는 데서 발생하는 오류Highest Paid Person’s Opinion(HiPPO)와 자동화 부족 문제도 빼놓을 수 없죠. 그뿐만이 아닙니다. 지금까지 개발된 머신러닝 시스템의 상당 부분은 클라우드 환경에서 구동하기 어려운 구조로 개발되었을 뿐 아니라 현실의 대규모 문제에 어울리지 않는 학술 데이터셋을 사용했고, 문제 해결을 위해 학술 연구용 소프트웨어 패키지를 사용하기 때문이라고도 할 수 있습니니다.

피드백 루프(카이젠* 개념을 참고)가 빠를수록 머신러닝 기반의 코로나19 감염 의심자 검출, 마스크 미착용자를 식별하는 비전 솔루션, 마약 탐지 따위의 비즈니스 문제에 집중할 시간이 많아집니다. 애초에 머신러닝 기술도 이러한 문제를 해결하기 위해 존재합니다. 그런데 왜 아직도 현실 문제에는 머신러닝 기술을 훌륭하게 사용할 수 없는걸까요?

* NOTE_카이젠

일본어에서 유래된 용어로 '발전'을 의미합니다. 소프트웨어 관리 철학으로 카이젠을 사용하는 문화의 기원은 제2차 세계 대전 이후 일본 자동차 산업에서 찾아볼 수 있습니다. 카이젠은 칸반, 근본 원인 분석(RCA)의 5 why 접근법, 6 시그마 등 다양한 기법에 영향을 미쳤습니다. 카이젠을 실천하기 위해서는 세계정세를 단번에 완벽히 파악하려고 노력하기보다는 점진적으로 이해의 지평을 넓혀 나가야 합니다. 카이젠 철학에 대해서는 『MLOps 실전 가이드』 5장에서 더욱 자세히 다룹니다.

머신러닝 모델이 실제 문제를 해결하는 단계로 자연스럽게 이동하지 못한다는 것은 업계에서 산업 표준으로 MLOps의 필요성을 요구하게 된 계기가 되었습니다. DevOps 철학이 자동화를 중요하게 여긴다는 측면으로 볼 때 MLOps는 DevOps의 계보를 잇는거죠.

DevOps의 자동화 철학을 잘 대변하는 표현으로 ‘자동화되지 않은 것은 고장난 것이다’가 있습니다. MLOps의 경우에도 마찬가지입니다. 시스템의 구성 요소로서 단순히 버튼을 누르는 일에 인간이 힘쓰고 있으면 안 됩니다. 자동화의 역사는 인간이 반복적인 작업을 수행하는 단순 노동자로서 일하는 것보다 시스템 설계자로서 일하는 것이 훨씬 가치 있다는 것을 증명해왔습니다. 마찬가지로 개발자, 머신러닝 모델, 서비스 운영 사이의 작업 흐름 또한 투명한 팀워크와 건전한 협업을 통해 설계되어야 합니다. MLOps는 DevOps 방법론을 사용하여 머신러닝을 자동화하는 프로세스라고 생각하면 됩니다.

소프트웨어 엔지니어링 프로세스뿐만 아니라 데이터나 모델링까지 자동화하는 행위를 MLOps라고 합니다. 모델 학습과 모델 배포는 기존 DevOps 라이프 사이클에 새롭게 추가된 작업입니다. 이렇게 새롭게 추가된 구성 요소들은 끊임없이 문제를 일으킬 수 있습니다. 예를 들어, 마지막으로 모델 학습을 진행했던 시점에서 시간이 흐르며 데이터가 변화하는 현상을 일컫는 데이터 드리프트data drift도 고려해야 합니다. 이렇게 새롭게 추가된 작업들이 정상적으로 동작하는지 감시하는 일을 책임질 새로운 모니터링 도구들이 필요할 수 있습니다.머신러닝 모델이 실제 운영에 투입되기 어려운 근본적인 이유는 데이터 과학 산업이 아직 충분히 성숙하지 못했기 때문이라고 정리할 수 있습니다. 소프트웨어 업계가 서비스 운영의 미성숙성을 타파하기 위해 DevOps를 채택했듯이 이제는 머신러닝 커뮤니티가 MLOps를 수용하고 있습니다.

DevOps와 MLOps가 결합된 모범 사례

머신러닝 엔지니어링의 기반이 되는 DevOps부터 데이터 자동화, 플랫폼 자동화까지를 모두 구축해야 비로소 MLOps를 다룰 자격이 생깁니다. DevOps 방법론을 사용하여 머신러닝을 자동화하는 프로세스가 MLOps라는 것을 명심해야 합니다. 데이터 수집, 피처 엔지니어링, 모델 평가, 배포, 유지보수 전반에 걸친 머신러닝 시스템을 구축하는 방법을 머신러닝 엔지니어링이라고 부릅니다.

DevOps를 단순한 직무가 아닌 서비스 배포 및 운영을 위한 행위로 보는 것처럼 MLOps도 어떠한 목표 달성을 위한 행위로 보는 것이 옳습니다. 몇몇 사람들이 DevOps 엔지니어라는 직군으로 근무하고 있음에도 불구하고 대부분의 소프트웨어 엔지니어들도 DevOps 모범 사례를 끊임없이 고려합니다. 마찬가지로 머신러닝 엔지니어도 MLOps 모범 사례에 따라 머신러닝 시스템을 구축해야 합니다.

MLOps 피드백 루프는 다음과 같은 요소들을 포함합니다.

재사용 가능한 머신러닝 파이프라인을 이용한 모델 생성 및 재학습

모델은 한 번 만들었다고 끝나는 것이 아닙니다. 데이터가 변하거나 고객의 특성이 변할 수 있으며, 심지어 모델을 만드는 사람도 변할 수 있습니다. 따라서 버전화되고 재사용 가능한 머신러닝 파이프라인을 갖춰야 합니다.

머신러닝 모델의 지속적 배포

머신러닝 모델의 지속적 배포는 소프트웨어의 지속적 배포와 유사합니다. 인프라를 포함한 모든 단계가 자동화되면 코드형 인프라를 사용해 모델을 프로덕션에 사용되는 새로운 환경까지 언제든 배포할 수 있게 됩니다.

MLOps 파이프라인에 대한 추적 로그

머신러닝 모델뿐 아니라 파이프라인 전반에 걸친 다양한 사건들을 추적하는 일은 필수적입니다. 머신러닝 시스템에는 보안, 편향, 정확성 등 수많은 문제가 도사리고 있죠죠. 프로덕션 소프트웨어에서 로깅이 중요한 것처럼 머신러닝 엔지니어링에서도 추적 로깅 시스템을 갖추는 것이 매우 중요합니다. 이러한 추적 로그는 문제에 접근하는 방식은 물론, 문제를 해결하는 방식에 대한 피드백 루프의 일부로써 기능할 수도 있습니다.

미래에 대비하기 위한 모델 드리프트 모니터링

프로덕션 환경의 머신러닝 시스템에는 끊임없이 새로운 데이터가 주어집니다. 이때 새롭게 주어지는 데이터의 분포가 기존에 학습된 모델에게 불리하게 작용할 수 있습니다. 이를 달리 말하면 2년 전 고객을 대상으로 유용하게 동작하던 모델이 오늘날에도 문제없이 동작하는 것을 보장할 수 없다는 것입니다. 최종적으로 모델을 학습시킨 이후의 다양한 변화delta를 모니터링하여 모델의 정확도로 인한 제품에 중대한 문제가 발생하기 전에 대응할 수 있습니다.

배포 타깃

클라우드를 이용하면 클라우드 네이티브 플랫폼에서 모델을 만든 후 다양한 타깃에 배포할 수 있도록 만들 수 있습니다(그림1-10). 머신러닝 운영에서 한 번 구축된 모델을 다양한 타깃 플랫폼에 반복적으로 재배포하는 기능은 매우 중요합니다. 탄력적으로 확장 가능한 HTTP 엔드포인트에 모델을 배포하는 것이 일반적인 패턴이지만, 모든 머신러닝 운영 시나리오에서 HTTP 엔드 포인트가 모든 것을 도맡는 것은 불가능합니다. 엣지 머신러닝으로 대두되는 새로운 패러다임은 머신러닝 작업에 특화된 전문 프로세서24를 사용합니다. 대표적으로 구글의 TPU와 애플의 A14가 이에 해당하죠.

 

구글 AutoML 비전25과 같은 고수준 제품들을 포함하고 있는 구글 클라우드 플랫폼GCP은 텐서플로 라이트 TF Lite, 텐서플로.jsTensorFlow.js, 코랄Coral과 같이 다양한 디바이스에 텐서플로TensorFlow 모델을 배포할 수 있도록 제공합니다(그림1-11).

 

25%의 법칙과 성공한 MLOps 기업들의 사례

나무를 키우는 일처럼 성공적인 MLOps를 위해선 여러 재료가 필요합니다. 필자는 이러한 특징을 25%의 법칙이라고 부릅니다. 아래 그림은 소프트웨어 엔지니어링, 데이터 엔지니어링, 모델링, 비즈니스 문제가 균등하게 중요하다는 점을 나타냅니다. 이와 같은 다학제적(여러 전문 분야에 걸친) 특징이 MLOps를 어렵게 만드는 주요한 원인입니다.

25%의 법칙에 따라 성공한 MLOps 기업의 좋은 예로 테슬라가 있습니다. 테슬라는 (1) 반자율주행차 형태로 고객들이 원하는 기능을 제공하고, (2)꾸준히 업데이트를 제공한다는 측면에서 소프트웨어 엔지니어링 모범 사례를 준수한다고 볼 수 있죠. (3)차량으로부터 수신한 새로운 데이터를 기반으로 모델을 지속적으로 재학습하는 점 또한 모범 사례의 이유로 충분합니다. 아마존에서 개발한 인공지능 비서 알렉사 Amazon Alexa도 25%의 법칙을 따르는 제품의 또 다른 예입니다.

이 글은 도서 『MLOps 실전 가이드』 내용에서 일부를 발췌, 작성하였습니다. DevOps와 MLOps의 기본 개념부터 3대 클라우드 플랫폼 (AWS, 애저, GCP)에서의 구성 및 실제 예시, AutoML, 엣지 컴퓨팅까지. MLOps를 실제 업무에 활용하기 위한 지식을 바로 만나보실 수 있습니다.

『MLOps 실전 가이드』