운영 머신러닝이란 무엇일까요?
작성자: Kevin Stumpf, 공동 창립자 겸 CTO
2015년, 저희가 Uber의 머신러닝 플랫폼인 Michelangelo를 출시하기 시작했을 때 흥미로운 패턴을 발견했습니다. 플랫폼에서 출시된 ML 모델의 80%가 최종 사용자 경험(Uber 탑승객 및 운전자)에 직접적인 영향을 미치는 운영 머신러닝 사용 사례를 지원했다는 것입니다. 단 20%만이 분석적 의사 결정을 지원하는 분석 머신러닝 사용 사례였습니다.
저희가 관찰한 운영 ML/분석 ML의 비율은 대부분의 다른 기업이 실제로 ML을 적용하는 방식과는 정 반대 였습니다. 즉, 분석 ML이 대세였습니다. 돌이켜보면 Uber가 운영 ML을 대대적으로 도입한 것은 그리 놀라운 일이 아닙니다. Michelangelo를 통해 운영 ML을 매우 쉽게 구현할 수 있었고, Uber에는 영향력이 큰 사용 사례가 많았기 때문입니다. 7년이 지난 오늘날, Uber의 운영 ML에 대한 의존도는 더욱 높아졌습니다. 운영 ML이 없었다면 비경제적인 운행 요금, 형편없는 도착예정시간(ETA) 예측, 그리고 수억 달러에 달하는 사기 피해를 보게 될 것입니다. 간단히 말해, 운영 ML이 없었다면 회사는 운영을 멈췄을 것입니다.
운영 ML은 Uber 성공의 핵심이었으며, 오랫동안 거대 기술 기업만이 이룰 수 있는 것처럼 보였습니다. 하지만 좋은 소식은 지난 7년 동안 많은 것이 변했다는 점입니다. 어떤 기업이든 주로 분석 ML을 사용하는 것에서 운영 ML을 사용하는 것으로 전환할 수 있도록 하는 새로운 기술과 트렌드가 있으며, 이를 실행하고자 하는 모든 분을 위해 몇 가지 팁을 준비했습니다. 자세히 살펴보겠습니다.
운영 ML vs. 분석 ML
운영 머신러닝은 애플리케이션이 ML 모델을 사용하여 실시간으로 비즈니스에 영향을 미치는 의사결정을 자율적이고 지속적으로 내리는 것을 의미합니다. 이러한 애플리케이션은 미션 크리티컬하며, 기업의 운영 스택에서 프로덕션으로 '온라인' 실행됩니다.
일반적인 예시로는 추천 시스템, 검색 순위, 동적 가격 책정, 사기 탐지, 대출 신청 승인 등이 있습니다.
운영 ML의 '오프라인' 세계에서의 형제 격은 분석 머신러닝입니다. 이는 비즈니스 사용자가 머신러닝을 통해 더 나은 의사결정을 내릴 수 있도록 돕는 애플리케이션입니다. 분석 ML 애플리케이션은 회사의 분석 스택에 위치하며 일반적으로 보고서, 대시보드 및 비즈니스 인텔리전스 도구에 직접 데이터를 제공합니다.
일반적인 예시로는 판매 예측, 이탈 예측, 고객 세분화 등이 있습니다.
조직은 서로 다른 목적으로 운영 ML과 분석 ML을 사용하며, 각각 기술적 요구사항도 다릅니다.
| 분석 ML | 운영 ML | |
|---|---|---|
| 의사결정 자동화 | 사람 개입 기반 의사결정(Human-in-the-loop) | 완전 자율 |
| 의사결정 속도 | 사람의 속도 | 실시간 |
| 최적화 대상 | 대규모 배치 처리 | 낮은 지연 시간과 높은 가용성 |
| 주요 대상 | 내부 비즈니스 사용자 | 고객 |
| 구동 | 보고서 및 대시보드 | 프로덕션 애플리케이션 |
| 예제 | 판매 예측 리드 스코어링 고객 세분화 이탈 예측 | 제품 추천 사기 탐지 교통량 예측 실시간 가격 책정 |
분석 ML과 운영 ML의 특징
머신러닝 운영 실전 적용
Uber Eats의 실제 운영 머신러닝 사례를 좀 더 구체적으로 살펴보겠습니다. 앱을 열면 레스토랑 목록을 추천하고 주문한 음식이 문 앞에 도착하기까지 얼마나 기다려야 하는지 알려줍니다. 앱에서는 간단해 보여도, 보이지 않는 부분은 꽤 복잡하답니다:
앱에 'Otto’s Tacos'와 '20~30분'을 표시하기 위해 Uber의 ML 플랫폼은 다양한 원시 데이터 소스의 광범위한 데이터를 살펴봐야 합니다:
- 현재 레스토랑 근처에 운전기사가 몇 명이나 있나요? 주문을 배달 중인가요, 아니면 다음 배차를 위해 대기 중인가요?
- 지금 레스토랑 주방은 얼마나 바쁜가요? 레스토랑에서 현재 처리 중인 주문이 많을수록 새 주문에 대한 작업을 시작하는 데 더 오랜 시간이 걸립니다.
- 고객이 과거에 높게 또는 낮게 평가한 레스토랑은 어디인가요?
- 사용자가 현재 적극적으로 검색하고 있는 요리(있는 경우)는 무엇인가요?
- 그리고… 사용자의 현재 위치는 어디인가요?
Michelangelo의 피처 플랫폼 은 이 데이터를 ML 피처 로 변환합니다. 이것은 모델 이 학습하고 실시간으로 예측 하는 데 사용하는 신호입니다. 예를 들어, 'num_orders_last_30_min' 은 배달 시간을 예측하기 위한 입력 피처로 사용되며, 이는 결국 모바일 앱에 표시됩니다.
위에서 설명한, 수많은 다양한 데이터 소스의 가공되지 않은 데이터를 피처로, 피처를 예측으로 전환하는 단계는 모든 운영 머신러닝 사용 사례에서 공통적으로 나타납니다. 시스템이 신용카드 사기를 탐지하거나, 자동차 대출 이자율을 예측하거나, 국제 정세 섹션의 기사를 제안하거나, 2세 아동을 위한 최고의 장난감을 추천하는 등 어떤 경우에도 기술적인 과제는 동일합니다. 그리고 바로 이 근본적인 기술적 공통점 덕분에 저희는 모든 운영 ML 사용 사례를 위한 하나의 중앙 플랫폼을 구축할 수 있었습니다.
운영 머신러닝을 가능하게 하는 트렌드
Uber는 전체 기술 스택을 최신 데이터 아키텍처와 원칙에 기반하여 구축했기 때문에 운영 ML을 활용할 준비가 되어 있었습니다. 지난 몇 년 동안 실리콘 밸리를 넘어선 곳에서도 이와 유사한 현대화가 이루어지는 것을 볼 수 있었습니다.
과거 데이터는 거의 무기한으로 보존됩니다
최근 몇 년간 데이터 저장 비용이 급감했습니다. 그 결과 기업들은 고객과의 모든 접점에 대한 정보를 수집, 구매, 저장할 수 있게 되었습니다. 이는 ML에 매우 중요합니다. 좋은 모델을 훈련하려면 대량의 기록 데이터가 필요하기 때문입니다. 그리고 데이터가 없으면 머신러닝도 없습니다.
데이터 사일로가 허물어지고 있습니다.
Uber는 처음부터 거의 모든 데이터를 Hive 기반 분산 파일 시스템에 중앙 집중화했습니다. 중앙 집중식 데이터 스토리지(또는 대안으로 분산 데이터 스토어에 대한 중앙 집중식 액세스)는 ML 모델을 학습시키는 데이터 사이언티스트가 어떤 데이터 를 사용할 수 있는지, 어디서 찾을 수 있는지, 어떻게 액세스할 수 있는지 알 수 있게 해주기 때문에 중요합니다. 대부분의 기업은 아직 모든 데이터(액세스)를 완전히 중앙 집중화하지는 못했습니다. 하지만 최신 데이터 스택 과 같은 아키텍처 트렌드는 데이터 액세스 민주화라는 데이터 사이언티스트의 꿈을 현실의 중심으로 훨씬 더 가깝게 이끌고 있습니다.
스트리밍을 통해 실시간 데이터를 사용할 수 있습니다
Uber에서는 운 좋게도 데이터 스트림을 위한 '중추 신경계'인 Kafka가 있었습니다. 서비스 및 모바일 앱의 많은 실시간 신호가 Kafka를 통해 스트리밍됩니다. 이는 운영 ML에 매우 중요합니다.
어제 일어난 일만 알고 있다면 사기를 탐지할 수 없 습니다. 지난 30초 동안 어떤 일이 있었는지 알아야 합니다. 데이터 웨어하우스와 데이터 레이크는 과거 데이터의 장기 저장을 위해 구축됩니다. 그리고 지난 몇 년 동안 Kafka나 Kinesis와 같은 스트리밍 인프라가 애플리케이션에 실시간 신호를 제공하기 위해 대규모로 도입되는 것을 보았습니다.
MLOps는 빠른 반복을 가능하게 합니다
Uber에서는 개별 엔지니어가 프로덕션 시스템을 매일 변경할 수 있는 권한을 가집니다. 이 프로세스는 DevOps 원칙을 따르고 자동화함으로써 지원됩니다. Michelangelo를 통해 저희는 MLOps라는 용어가 생기기 전에 이러한 원칙을 운영 ML에 도입했습니다 🙂. 데이터 사이언티스트가 모델을 학습시키고 말 그대로 하루 안에 안전하게 프로덕션에 배포할 수 있도록 하는 것이 저희에게는 중요했습니다.
Uber를 넘어 실리콘 밸리에서 멀리 떨어진 곳에서도 소프트웨어 엔지니어링뿐만 아니라 MLOps를 통해 데이터 사이언스팀에도 DevOps 원칙과 자동화를 도입하는 얼리 어답터들이 점점 더 많아지고 있습니다. 물론 제가 이 블로그에서 설명한 여러 가지 이유로 인해 대부분의 회사에서는 소프트웨어보다 ML이 훨씬 더 까다롭습니다. 하지만 저는 산업이 일반적인 Fortune 500 기업의 일반적인 데이터 사이언티스트가 운영 ML 모델을 하루에 여러 번 반복 개선할 수 있는 미래를 향해 꾸준히 나아가고 있다고 확신합니다.
운영 ML을 지원하는 최신 데이터 아키텍처의 모습은 다음과 같습니다.
귀하의 조직이 위에서 언급한 현대화 과정 중 일부를 거쳤거나(또는 처음부터 시작했다면!) 운영 ML을 시작할 준비가 되었을 수 있습니다.
운영 머신러닝 시작하기
2013년에 Uber는 프로덕션 환경에서 머신러닝을 사용하지 않고 있었습니다. 오늘날 프로덕션 환경에서 수만 개의 모델을 운영하고 있습니다. 그러한 변화는 하룻밤 사이에 이루어지지 않았습니다.
조직에서 운영 ML을 활용하고자 한다면 다음 단계를 따르는 것을 추천합니다:
머신러닝에 적합한 사용 사례를 선택하세요.
모든 문제가 ML로 해결될 수 있는 것은 아닙니다. ML에 적합할 수 있는 문제의 조건:
- 시스템이 매우 유사하고 반복적인 의사결정을 많이 내리고 있습니다(최소 수만 건).
- 올바른 결정을 내리는 것은 간단하지 않습니다
- 결정이 내려진 후 일정 시간이 지나면 해당 결정이 좋은 것이었는지 나쁜 것이었는지 판단할 방법이 생깁니다.
이러한 요소가 사실이라면, 머신러닝 애플리케이션은 의사결정을 내리고, 그 결정으로부터 학습하며, 지속적으로 개선될 수 있습니다.
실제로 중요한 사용 사례를 선택하세요
앞서 언급했듯이 첫 모델을 프로덕션에 배포하는 과정은 어렵습니다. 첫 머신러닝 애플리케이션의 미래 성과가 그다지 유망하지 않다면, 힘든 상황이 닥쳤을 때 너무 쉽게 포기하게 될 것입니다. 우선순위는 바뀔 것이고, 리더십은 조급해질 수 있으며, 노력은 지속되지 않을 것입니다. 잠재력이 높은 사용 사례를 선택하세요.
첫 모델을 위해 소규모 팀에 권한을 부여하고 이해관계자를 최소화하기
프로젝트의 실패 확률은 모델 학습 및 배포에 포함된 인계 작업 수에 따라 증가합니다. 이상적으로는 필요한 모든 데이터에 액세스할 수 있고, 간단한 모델을 학습시키는 방법을 알고 있으며, 프로덕션 스택에 익숙하여 애플리케이션을 프로덕션에 적용할 수 있는 2~3명의 소규모 팀으로 시작하세요.
ML 엔지니어는 일반적으로 데이터 엔지니어링, 소프트웨어 엔지니어링, 데이터 사이언스 기술의 보기 드문 조합을 갖추고 있으므로, 기반을 마련하는 데 가장 적합합니다. 이는 소규모 ML 전문가 그룹을 제품 팀에 포함시켜 머신러닝팀을 확장하는 방법이기도 합니다.