MLOps에 대해 100명 이상의 ML 전문가와 이야기를 나누면서 배운 내용

그래서 저는 모든 마케팅 광고의 이면에 있는 진실을 밝혀내고 저의 모든 지식을 저와 제 팀과 아낌없이 공유해 주신 모든 분들께 감사하는 마음으로 전달하는 것을 제 사명으로 삼았습니다. 이 목표를 달성하기 위해 NAT은 빠르게 성장하는 신생 기업의 풀스택 데이터 과학자부터 잘 구축된 기업의 소프트웨어 엔지니어, 머신 러닝 운영의 기초를 닦는 경험 많은 MLOps 직원까지 100명 이상의 머신 러닝 실무자들과 이야기를 나눴습니다. 시간을 내어 기꺼이 공유해 주신 모든 전문가분들께 “감사합니다”라고 진심으로 감사드립니다!

더 이상 설명하지 않고, 이 환상적인 여정에서 저희 팀이 발견한 일상적인 MLOps 당면 과제에 대해 알아낸 핵심 사항 중 일부를 소개합니다.

“저는 모델을 구축할 때라고 결정하기 전까지는 행복한 데이터 과학자였습니다.”

NLP와 Computer Vision의 문제를 해결하는 데이터 과학자 Ale Solano는 2020년 11월 MLOps 커뮤니티에 자신을 소개했습니다. 당시 그의 회사는 몇 명의 데이터 사이언티스트만으로 모델을 프로덕션 환경에 구축하기 시작했습니다. 그의 팀은 문제를 해결하는 데 열정을 가지고 있었지만, 지금까지 그들은 단지 과학적인 방법으로 그것을 해왔습니다. 공학적 배경은 없습니다. MLOps 노하우가 없습니다.

그리고 다른 데이터 과학자들과의 대화를 통해 많은 기업들이 소수의 데이터 과학자들에게만 동일한 방식으로 머신 러닝을 도입하려 하고 있다는 것을 알 수 있었습니다. 본격적인 머신 러닝 제품을 구축하기 위해 리소스에 너무 많은 노력을 투자하기 전에 먼저 개념 증명(PoC)을 수행하는 것이 매우 이치에 맞는다. 그러나 모델을 훈련시키고 일정 수준의 정확도에 도달한다고 해서 모델이 실제 환경에서 구현될 수 있고 구현되어야 한다는 것을 입증하지는 못한다. 그리고 솔루션을 실제 운영 환경에서 테스트하지 않으면 비즈니스 문제를 해결하거나 투자를 회수할 수 없습니다. 당연히 데이터 과학자에게는 PoC를 마무리하고 모델을 프로덕션 환경에 배포하는 또 다른 과제가 주어집니다.

이게 얼마나 어렵겠어? 모델을 성공적으로 배포하고 규모에 맞게 서비스를 제공할 수 있으려면 소프트웨어 엔지니어링 및 DevOps 팀에서 더 흔히 볼 수 있는 기술과 지식이 필요합니다. 인프라, 하드웨어 조정, 컨테이너 관리, 확장, 로드 밸런싱, 이중화, 가용성, 성능, 보안, 인증, 권한 부여, 통합, 버전 관리, 재현성, 모니터링, 모델 재교육 등을 고려하여 CI/CD 파이프라인을 구축해야 합니다. 안전하고 비용 효율적이며 유지 가능한 방식으로 모델을 제작할 수 있습니다. 너무 많은 데이터 과학자 중 한 명에게서 들은 짧은 대답은 “매우 어렵다”입니다. 곧 구현이 작업이 아니라 프로세스라는 것을 깨닫게 됩니다.

결론적으로, 머신 러닝을 조직에 도입하는 이 접근법은 데이터 사이언티스트가 일반적으로 위에서 언급한 광범위한 지식을 가진 사람들이 아니기 때문에 개념 이후 다소 결함이 있다. 반면에, 여러 분야에 걸쳐 이렇게 다양한 노하우를 습득하는 것은 많은 시간과 연습이 필요하다. 이 설정에서는 신뢰할 수 있는 구축 솔루션을 구축할 가능성이 희박하고 실패의 위험이 높습니다.

건설과 구매의 딜레마

티처블 이후로,허브는 ML 배포 시장에 진출하여 솔루션을 제공하고 있습니다. 이 시장에 어떤 제품이 있는지, 누가 사용하고 있으며 문제를 충분히 해결하는지를 정확히 이해하는 것이 중요합니다.

관리형 솔루션을 구매하는 대부분의 기업이 AWS, GCP 또는 Azure를 사용하고 있다는 사실은 놀라운 일이 아닙니다. 대부분의 조직은 이러한 중요한 의사 결정과 관련하여 “안전한 선택”을 모색하고 있으며, 이러한 선택의 주된 이유는 툴의 채택 수준이라고 지적하고 있습니다. 가장 많이 채택된 것들은 대개 잘 문서화되어 있고 C-level에서 승인을 받기 쉽습니다. 그것은 대기업과 기업들 사이에서 흔한 추론이다.

최고의 해결책은 실제로 Sagemaker였고, 놀라운 것은 그것이 첫 번째 선택임에도 불구하고 꽤 많은 부정적인 진술이 있었다는 것이다.

“저는 세이지메이커를 사용하지만, 별로 좋아하지 않아요. 제가 지금 그것을 사용하기로 선택한 이유는 제가 AWS에 대한 경험이 있고 현재 배치를 다루는 사람은 저뿐이기 때문입니다. 그러나 향후 Sagemaker의 워크플로우가 단순하지 않고, 지원이 좋지 않으며, Data Scientists에게 직관적이지 않기 때문에 대안을 생각해야 합니다. 벤더 lock-in도 걱정입니다.”

“만약 제가 DS팀에 Sagemaker를 사용하게 한다면, 상황이 너무 혼란스러울 것입니다. 좀 더 간소화된 솔루션이 필요합니다.”

“AWS는 기술에 가장 익숙하고 설명서도 많지만, 여전히 직관적이지 않은 것도 많고, 솔루션도 비용 효율적이지도 않습니다.”

“나는 Sagemaker를 사용하지만, 그것은 너무 복잡합니다. 너무 비싸요!”

“세이지메이커는 학습 곡선이 매우 커서 이 곡선으로 작업하는 것이 짜증나고 짜증납니다.”

“Sagemaker와 함께 배치하는 시간이 DIY 솔루션보다 낫지만, 다르게 할 수 있었다면 Kubernetes를 사용하는 모든 모델에 사용할 수 있는 내부 파이프라인을 미리 구축했을 것입니다.”

회사 규모와 관련해서는 규모가 크고 비활성(레거시 기술이 너무 많음) 회사일수록 즉시 사용 가능 솔루션이나 클라우드 솔루션으로 전환할 가능성이 커진다는 사실을 알게 되었습니다. 은행과 금융 산업은 그러한 사용 사례의 좋은 예이다.

반면, 중소기업과 스타트업은 대개 더 많은 유연성을 위해 “자신의 힘으로 빌트인” 방식을 선택합니다. 그러한 DIY 솔루션은 보통 쿠베르네스와 도커 컨테이너 위에 구축된다. 이러한 기업의 초기 ML 시대에는 값비싼 기성 플랫폼을 사용하지 않는 것이 좋습니다. 여기서 중요한 질문은 이러한 솔루션이 얼마나 확장 가능하고, 안정적이며, 유지 보수 가능한지에 대한 것입니다. 일반적으로 이러한 기업들이 비즈니스 성장의 특정 지점에 도달하면 이 솔루션은 관리가 불가능하거나 비용이 너무 많이 들기 때문에 대안을 찾기 시작합니다.

보너스: MLOps Community의 “You build it, you run it”이라는 주제 아래, ML 솔루션을 구축하는 ML 팀 내 소유권과 책임에 관한 몇 가지 문제를 논의하는 매우 확실한 게시물이 있습니다.

그리고 시장에 출시되는 모든 새로운 MLOps 도구에 관한 한, 그 확산은 엄청나고 대부분의 실무자들은 상당히 보수적입니다. 그들 중 대부분은 이러한 도구들을 사용하기 전에 “무엇이 장기적으로 지속될 것인가”를 보기 위해 기다리고 있다. 또 다른 이유는 이러한 구축, 서비스 및 모니터링 툴의 대부분이 주로 기업을 대상으로 하기 때문에 너무 복잡하고 비용이 많이 든다는 점입니다. 이러한 도구를 사용하여 시작하는 것도 상당한 시간이 걸립니다.

이러한 툴링에 대한 또 다른 공통적인 우려 사항은 벤더 lock-in입니다. 따라서 규모에 관계없이 대부분의 기업은 일반적으로 엔드 투 엔드 플랫폼보다는 동종 최고의 솔루션 조합을 선택합니다. 그 배경에는 작은 툴이 대개 문제를 잘 해결하고 조직의 요구에 더 적합하다는 것이 있습니다. 반대로, 이 모든 것을 한다고 주장하는 한 가지 도구는, 대개 특정 작업을 잘 하지 못하고, 너무 복잡하고, 종종 훨씬 더 비쌉니다.

그리고 마지막으로, MLOps 분야의 새로운 참여자들이 사용하는 마케팅 메시지에 대해 회의 중에 몇 가지 흥미로운 발언이 있었습니다.

“ML 툴 제공업체들은 마케팅에 능숙하지 않고 그들이 제공하는 것에 대해 잘 설명하지 못하는 것 같습니다. 내가 그들의 웹사이트 대부분을 방문할 때 나는 “이게 대체 뭐야?”라고 생각한다. “

“제가 살펴본 바로 사용할 수 있는 MLOps 플랫폼은 너무 복잡하거나 툴을 사용하여 무엇을 해야 할지 잘 모르겠습니다. 그들의 웹사이트와 문서들은 꽤 지저분합니다.”

여기서 요약하자면, 구축 및 솔루션 제공에 관한 한 여전히 매우 복잡합니다. 시장에 진출할 수 있는 여지가 상당히 많고, 우리 팀에게는 많은 가치가 있습니다. Teachable허브는 프로세스를 간소화하고 더 저렴하게 함으로써 추가할 수 있습니다.

“우리는 기술 문제가 아니라 사람 문제가 있습니다.”

이 진술은 우리가 배운 가장 어려운 진실 중 하나였습니다.최고의 툴링과 가장 자동화된 솔루션도 MLOps를 조직에 도입하는 데 있어 올바른 사고방식을 채택하지 않은 팀에게는 도움이 되지 않습니다. 도구는 그 차이를 메우는 것을 목표로 하지만, 때때로 필요한 것은 공통의 공간, 공통의 사고방식, 그리고 언어이다.

“가장 중요한 관리 과제는 ML 팀의 커뮤니케이션 + 명확한 역할과 책임 + 우려의 분리입니다.” — Hypergolic의 창립자 Laszlo Sragner

결국, 조직의 확립된 워크플로우 내에서 더 큰 변화가 발생하면 서로 다른 레벨 간에 마찰이 발생합니다. 가장 일반적인 시나리오는 “톱다운” 접근 방식을 사용하고 C 레벨의 누군가가 비즈니스가 성장함에 따라 ML 운영이 다음 단계로 넘어갈 시기를 결정하는 경우입니다.

당연히 누군가는 이러한 과감한 조치를 주도해야 하며 경영진은 대개 팀 내에서 가장 경험이 많은 DS/MLE에 업무를 할당하지만, 특별한 전문 지식을 갖춘 외부 직원을 영입하여 실행하는 경우도 드물지 않습니다. 이런 중요한 변화가 위에서부터 지지를 받는 것은 좋지만, 어떤 변화처럼 항상 낮은 층에서 환영받는 것은 아니다.

MLOps 원칙을 도입한 “운 좋은” 사람은 모든 사용 사례에 쉽게 적용할 수 있는 모범 사례가 없을 뿐만 아니라 팀의 모든 Data Scientist가 완전한 스택을 원하는 것은 아니라는 것을 깨닫습니다. 과학 문제를 열정적으로 해결하는 것에서 도커와 쿠베르네테스 학습으로 초점을 옮기는 것은 종종 팀에 많은 좌절감을 불러일으킬 뿐만 아니라 팀이 만들고 있는 머신 러닝 모델의 품질을 크게 떨어뜨린다.

그러한 지도자들은 그들의 임무가 단지 최고의 MLOps 도구를 찾고 그것을 채택하는 것이 아니기 때문에 매우 유연하고 공감적이며 무엇보다도 인내심이 필요하다. 그들은 마음가짐을 키우고, 팀의 사기를 북돋우며, 조직 내에서 MLOps 성숙도로 가는 길을 이끌어야 합니다.

저는 이 구절을 데메트리오스 브링크만의 “MLOps가 성숙하고 있습니다. 여기 그 증거가 있습니다”라는 글에서 인용한 것으로 마무리 짓고 싶습니다.

“ML의 선봉에 선 사람들은 MLOps의 잠재력을 파악하고, 성공 사례를 공유하고, 모범 사례를 성문화하고, ML이 실질적인 비즈니스 목표를 실현하는 데 어떻게 도움이 되는지 조직에 보여줘야 할 것입니다.”

나는 이러한 지도자들이 지식과 경험을 그들 조직 밖의 지역사회에도 전수할 의무가 있다는 것을 믿는다. 이것이 MLOps 성숙도를 달성하는 유일한 진정한 길이기 때문이다. 이 밝은 미래의 형상이 되는 큰 영광을 받아들이자!

핀

많은 놀라운 사람들을 만난 것은 매우 즐거웠고 위의 모든 것들은 우리가 그 과정에서 배운 귀중한 통찰력의 극히 일부에 불과합니다. 이러한 대화의 대부분은 기업들이 MLOps 원칙을 도입하고 모델을 운영하면서 직면하는 여러 가지 문제가 있음을 확인했습니다. 그럼에도 불구하고, 대부분의 회사들은 천천히 어떤 식으로든 생산에 착수하고 있다. 하지만 ML 시장에 진입조차 하지 않은 기업이 훨씬 더 많다는 것도 사실이다. 운영화 앞에 놓인 많은 장애물과 세계 머신러닝 시장이 2020년 73억 달러에서 2024년 306억 달러로 성장할 것으로 예상된다는 사실이 MLOps를 둘러싼 과대 광고의 주요 원인 중 하나라고 결론짓겠습니다. 당신은 어떻게 생각하나요?

업데이트 : 저희 팀이 MLOps 성공비결 공식을 검색하던 중 수집한 2차 MLOps ‘간판’을 확인하실 수 있습니다. 기사 아래에 있는 여러분의 생각과 의견을 자유롭게 공유하세요!