클라우드

'모델옵스'가 예방할 수 있는 ML 모델의 '패착' 5가지

Isaac Sacolick | CIO 2022.12.01
기업 내 데이터 과학 팀이 비즈니스 목표를 설정했다고 가정해보자. 데이터 애널리틱스 및 머신러닝 모델을 활용해 비즈니스 가치를 창출할 수 있는 영역에 초점을 맞췄다. 데이터 세트 태깅, 사용할 머신러닝 기술, 머신러닝 모델 생성을 위한 프로세스까지 모든 준비가 끝났다. 확장 가능한 클라우드 인프라도 마음껏 쓸 수 있다. 이제 정말 머신러닝 모델을 만들어 현장에 적용하면 되는 걸까? 
 
ⓒ Getty Images Bank 

회사의 데이터 과학 팀이 비즈니스 목표를 설정했다고 가정해보자. 데이터 애널리틱스 및 머신러닝 모델을 활용해 비즈니스 가치를 창출할 수 있는 영역에 초점을 맞췄다. 데이터 세트 태깅, 사용할 머신러닝 기술, 머신러닝 모델 생성을 위한 프로세스까지 모든 준비가 끝났다. 확장 가능한 클라우드 인프라도 마음껏 쓸 수 있다. 이제 정말 머신러닝 모델을 만들어 현장에 적용하면 되는 걸까? 

몇몇 전문가는 아니라고 말한다. 모든 혁신과 새로운 소프트웨어 배포는 위험 요소를 수반하므로 재차 검토해 예방할 수 있는 전략을 세워야 한다. 데이터 과학 프로세스를 개발할 때 처음부터 위험 관리 수칙을 수립하는 것이 중요하다. 오딧보드(AuditBoard)의 위험 및 기술 선임 고문 존 윌러는 “데이터 과학이든 다른 사업 요소이든 혁신과 위험 관리는 늘 함께 가야 한다”라고 말했다. 

소프트웨어 개발은 단지 코드를 쓰고 출시한다고 끝이 아니다. 소프트웨어 개발자는 항상 잠재 위험 요소를 고려하고 그에 따른 모범 수칙을 따르려 한다. 그래서 나온 것이 소프트웨어 개발 주기(software development life cycle, SDLC), 원점 회귀(shift-left) 데브옵스 수칙, 관찰가능성 기준이다. 모두 잠재적 위험을 탐지하고 예방하기 위한 노력이다. 새 소프트웨어를 배포한 뒤에 개발팀이 계속 코드를 유지하고 수정할 수 있는 환경을 제공하는 것도 목표 중 하나다.

머신러닝 모델 관리에서 소프트웨어 개발 주기와 같은 역할을 개념이 바로 모델옵스(ModelOps)다. 모델옵스는 머신러닝 모델의 주기를 관리하기 위한 방법론이다. 이 방법론은 데이터 과학자가 머신러닝 모델을 어떻게 생성, 테스트, 배포해야 알지 안내한다. 그리고 배포한 머신러닝 모델이 계획대로 작동하는지 확인하고자 지속해서 모니터링하고 개선하는 방법도 제시한다. 

하지만 머신러닝 모델을 배포하는 과정에서 여러 실패 요인이 간과된다. 다음은 모델옵스가 예방할 수 있는 데이터 모델의 실패 요인 5가지다. 
 

실패 요인 1 : 관리 전략 부재 

데이터 과학 분야의 글로벌 임원 커뮤니티 코리니움(Corinium)이 최근 실시한 ‘2022년 모델옵스 현황 보고서(State of Modelops Report)’에 따르면 AI 기업 리더 중 60% 이상이 위험 요소를 관리하고 규제를 준수하는 데 애를 먹고 있다. 데이터 과학자는 위험 관리에 능숙하지 않으므로 기업은 우선 위험 관리 리더를 불러와 모델옵스 주기에 적합한 전략을 수립하도록 해야 한다. 

윌러는 “혁신에는 여러 정의가 있지만 그중 하나는 원하는 사업 성과를 내기 위해 가장 최적화된 방법을 찾는 것이다. 따라서 데이터 과학자에게 혁신이란 더 나은 의사결정을 돕는 새 데이터 모델이다. 하지만 위험 관리 전략을 세우지 않으면 원하는 사업 성과를 이루더라도 큰 비용을 초래할 수 있다. 노력이 헛되지 않으려면 데이터에 잠재한 위험 요소를 파악하고 방책을 마련해야 한다. 그래야 신뢰할만한 데이터 모델을 만들 수 있다”라고 말했다. 

코리니움 외에도 데이터 과학용 SaaS 솔루션을 제공하는 도미노 데이터 랩(Domino Data Lab)과 모델옵(ModelOp)이 데이터 모델 관리에 대해 분석한 화이트 페이퍼를 참고하면 좋다.
 

실패 요인 2 : 중복되거나 특정 도메인에 한정된 데이터 모델

데이터 과학 팀은 어떤 사업 영업에 초점을 맞출지에 대한 기준을 세워야 한다. 또한 여러 사업 영역에 걸쳐 영향을 끼치는 모델을 일반화하는 방법에 대한 기준도 수립해야 한다. 

이렇게 명확한 기준을 세워야만 혹시라도 데이터 모델이 겹치는 일을 방지할 수 있다. 비슷한 문제를 해결하는 데 여러 모델이 있다면 낭비다. 엠파시스(Mphasis)의 최고 솔루션 책임자 스리쿠마 라마나단은 이와 관련된 그의 경험담을 전했다. 라마나단은 “도메인이 바뀔 때마다 ML 모델이 처음부터 다시 훈련돼 낭패가 아닐 수 없었다. 표준 머신러닝 원칙을 기반으로 만들었는데도 말이다”라고 말했다. 

라마나단은 “결국 점진적 학습으로 문제를 개선했다. 모델을 확장하고자 인풋 데이터를 계속 썼다. 그렇게 하자 더 적은 자원을 들이고도 새로운 도메인에 데이터 모델을 학습시킬 수 있었다”라고 전했다. 

점진적 학습(incremental learning)은 데이터 모델을 새로운 데이터에 지속해서, 혹은 정해진 주기에 따라 학습시키는 기법이다. 예로 AWS 세이지메이커(AWS SageMaker), 애저 코그니티브 서치(Azure Cognitive Search), 매트랩(Matlab), 파이썬 리버(Python River) 등이 있다. 
 

실패 요인 3 : 너무 많은 모델을 개발해야 하는 데이터 과학팀 

처음부터 다시 학습시키거나 점진적으로 학습시키는 대책 외에도 데이터 모델을 유지하려면 여전히 신경써야 할 게 많다. 도미노 데이터 랩의 데이터 과학 전략 및 에반젤리즘 책임자 젤 칼슨은 “흔히들 놓치는 위험 요소는 바로 사람이다. 어떤 데이터 팀은 수많은 데이터 모델을 다시 개발하고 다시 배포할 여력이 없다”라고 말했다. 

데브옵스와 비슷하게 데이터 과학자는 특정 모델을 개발하고 적용하는 데 걸리는 시간을 측정하기 위해 모델 속도(model velocity)라는 기준을 쓴다. 칼슨은 “현실이 목표한 모델 속도에 못 미칠 때가 다반사다. 그 결과 데이터팀이 개발해야 하는 데이터 모델은 계속 밀리고 쌓인다. 데이터 모델이 점점 회사 전반에 걸쳐 없어서는 안 될 운영 수단이 되면서 눈덩이처럼 불어나는 재고는 언제 터질지 모르는 시한폭탄과 같다. 고객과 시장의 행태가 너무 빠르게 변하고 있는 상황에서 필요한 데이터 모델이 없으면 큰 손해다”라고 말했다. 

칼슨은 조심스럽게 이런 재고를 ‘데이터 모델 부채(model debt)’라고 부른다고 말했다. 칼슨은 모델 속도와 아직 완성하지 못한 데이터 모델이 사업 성과에 미치는 영향을 정확히 파악하는 것부터 시작해야 한다고 강조했다. 

데이터 과학팀은 통일된 데이터 모델 카탈로그나 레지스트리를 만들어 운영해야 한다. 그러면 팀원이 어떤 모델이 어떤 수준으로 갖춰져 있는지, 모델 주기에서 어느 단계쯤 와 있는지, 누가 맡는지 명확히 파악할 수 있다. 모델 카탈로그 및 레지스트리 기능은 데이터 카탈로그 플랫폼, ML 개발 도구, 그리고 ML옵스(MLops)나 모델옵스 기술에서 찾아볼 수 있다. 
 

실패 요인 4 : 병목현상을 일으키는 관료주의적 검토위원회 

이제 데이터 과학팀이 회사의 기준과 데이터 모델 모범 수칙에 따라 데이터 모델을 개발했다고 치자. 정말 배포할 준비가 끝난걸까? 아니다. 어떤 회사는 데이터 과학팀이 정말로 예상 가능한 모든 위험 요소에 대한 대비책을 세웠는지 확인하고자 검토 위원회를 설립하고 싶어한다. 이런 검토 과정은 데이터 과학 팀이 이제 막 새롭게 개발한 데이터 모델을 배포하고 위험 관리 수칙을 수행하려 할 때 정말 필요할 수 있다. 하지만 정확히 언제 이런 검토 위원회가 필요할까? 그리고 어떤 상황에서 오히려 방해가 될까? 

머신러닝 어셔런스(assurance) 플랫폼 모니타우르(Monitaur)의 솔루션 디렉터 그리스 루이즈는 한 가지 대안을 제안했다. 루이즈는 “경영진이 상의하달, 사후 검증 방식으로 엄격하게 검토 위원회를 꾸리는 것보다 명확한 거버넌스 원칙을 토대로 데이터 모델 주기에 적절한 소프트웨어를 개발하고 거버넌스 프로세스 전반에 걸친 이해관계자의 기대치를 일치하는 것이 더 좋지 않을까 하는 생각이다”라고 말했다. 

리스크 관리 기능을 갖춘 모델옵스 솔루션에는 데이터트론(Datatron), 도미노, 피들러(Fiddler), 매스웍스(MathWorks), 모델옵(Modelop), 모니타우르(Monitaur), 래피드마이너(RapidMiner), 사스(SAS), 팁코 소프트웨어(TIBCO software) 플랫폼 등이 있다. 
 

실패 요인 5 : 데이터 드리프트 등의 위험 요소 모니터링 부재  

큰 숲에서 나무 하나가 쓰러지더라도 알아차리기 힘든 법이다. 소프트웨어 분야에서 엔지니어들은 항상 코드 유지보수를 게을리하지 않고 프레임워크, 라이브러리, 인프라 등을 끊임없이 수정하고 개선해야 한다는 점을 안다. 하지만 데이터 과학이라는 숲에서, 한 머신러닝 모델이 계획대로 효과를 내지 못한다면 데이터 과학팀은 이를 알 방법이 있을까?

테라데이터(Teradata)의 부사장 겸 최고 제품 책임자인 힐러리 애쉬튼은 “변화무쌍한 사업 환경의 소용돌이 속에서 모든 AI 및 머신러닝 모델은 가만히 두면 뒤처지는 셈이다”라고 말했다. 

애쉬튼은 “데이터 모델을 배포하면 데이터 과학자는 모델 옵스를 활용해 모델의 성능이 떨어졌거나 떨어질 것으로 예상될 때 알 수 있도록 자동화 시스템을 구축해 놓아야 한다. 그래야 특정 모델에 문제가 없는지 살펴보거나, 다시 학습시키거나, 폐지하거나 할 수 있다. 오보가 울려서 허탕치는 것보다 낫다. 특히 다시 학습시켜야 하는 경우에는 자동화를 적용할 수 있다”라고 말했다. ciokr@idg.co.kr

회사명 : 한국IDG | 제호: ITWorld | 주소 : 서울시 중구 세종대로 23, 4층 우)04512
| 등록번호 : 서울 아00743 등록발행일자 : 2009년 01월 19일

발행인 : 박형미 | 편집인 : 박재곤 | 청소년보호책임자 : 한정규
| 사업자 등록번호 : 214-87-22467 Tel : 02-558-6950

Copyright © 2024 International Data Group. All rights reserved.