한빛출판네트워크

오픈 소스 소프트웨어로 구축된 올인원 플랫폼(all-in-one platform)은 특정 워크플로우를 쉽게 해주지만, 이런 경계선을 넘어 탐색하고 성장하기 어렵게 만든다.

회사의 데이터 인프라를 당신이 재설계해야한다 치자.

IBM, Cloudera 또는 Amazon과 같은 대형 통합 기업에게 솔루션을 돈 주고 위탁할 것인가? 소규모 스타트업들에게 한 문제씩 맡게 시킬 것인가? 아니면 둘 다 조금씩? 우리는 트렌드가 “Best-of-Breed”(이하 BoB) 플랫폼에 초점을 두는 쪽으로 변화되는 걸 볼 수 있다. 즉 데이터 워크플로우의 모든 공간을 해결하는 올인원(all-in-one) 플랫폼과 달리 데이터 과학(data science)과 머신 러닝(machine learning)의 한 가지 측면에 초집중하는 것이다. 

이러한 변화를 보다 심도 있게 연구한 이 글은 현대 데이터 과학 워크플로우에서 데이터 과학자들과 그들의 니즈에 대해 수없이 많은 대화를 나눈 결과라고 할 수 있다.

데이터 툴링의 2가지 문화

오늘날 시장에서 두 가지 다른 종류의 제품을 만나볼 수 있다.

1. Amazon Sagemaker, AzureML, Cloudera Data Science Workbench 및 Databricks(현재 통합된 분석 플랫폼)와 같은 올인원 플랫폼.
2. Snowflake, Confluent/Kafka, MongoDB/Atlas, Coiled/Dask 및 Plotly*와 같이 데이터 과학이나 머신 러닝 과정의 한 측면에 초집중한 BoB 제품들^[1].

[1] OSS 기술 자체보다는 OSS 기술 기반 데이터 플랫폼에 대해 말하고자 함을 참고하자. 이 글에서는 또다시 Dask랑 Spark비교해보려는게 아닌 현대 데이터 플랫폼의 상반되는 두 가지 종류의 효용성을 저울질해볼 것이다.

통합된 올인원 플랫폼은 다양한 툴들을 통틀어 사용(assemble)하므로 공통 워크플로우에 대한 완전한 솔루션을 제공할 수 있다. 신뢰성도 높고 안정적이지만, 워크플로우의 어느 한 부분에서도 제외되지 않으며 느리게 진행되는 경향이 있다. 이러한 이유로 딱히 이렇다할 플랫폼 관련 문화나 스킬이 없는 회사들에게는 이런 플랫폼이 좋은 선택이 될 수 있을 것이다. 

반면에 BoB 제품은 공예가 장인과 같다. 한 가지 일을 확실히 끝내고 바로 넘긴다(가끔 이 중 하나는 기술적 혁신을 이끌만한 것이다). 이 공예가 장인들은 보통 최종 사용자의 니즈를 보다 효과적이게 대응해주고, 더 저렴하며, 함께 작업하기 쉽다. 그러나 완전한 솔루션을 내기 위해서는 다른 제품과도 함께 사용되야하므로 일부 어셈블리(assembly)가 필요하다. BoB 제품들은 천천히 나아가는 회사들에게 적절하지 않을 수 있는 DIY 정신이 필요하기 마련이다.

어떤 게 더 좋은 길인 것인가? 해답이 없는 질문이지만 우리는 BoB 제품에 돈을 투자하고 있다. 그 이유에 대해서는 잠시 후에 알려주겠지만 먼저 데이터 웨어하우스(data warehouse)와 데이터 엔지니어링 플랫폼(data engineering platform)에 어떤 일이 일어났었는지에 대해 역사적인 관점으로 살펴보려한다. 

데이터 웨어하우스와 데이터 엔지니어링 플랫폼에서 얻은 교훈

역사적으로 기업들은 오라클(Oracle), SAS, 테라데이타(Teradata), 또는 기타 데이터 올인원 웨어하우징 솔루션을 구입해왔다. 이들은 (회계와 같은 회사 다른 부분에 가치 있는 패키지를 제공하는 걸 포함한)그들이 한 일에는 확고했지만 이용자 고객들이 시간이 지남에 따라 새로운 워크로드에 적응해나가는 것은 어려웠다.

그 다음으로는 오픈 소스 툴링으로 오라클(Oracle)과 SAS의 주도권을 깼던 클라우데라(Cloudera), 호튼웍스(Hortonworks)나 MapR 같은 데이터 엔지니어링 플랫폼이 등장했다. 이는 하둡(Hadoop), 하이브(Hive) 및 스파크(Spark)와 함께 보다 높은 수준의 적응성을 제공했다. 

반면에 클라우데라, 호튼웍스과 MapR은 공통적인 데이터 엔지니어링 작업에서 세트 메뉴로 잘 맞았지만 새로운 자연어(natural language) 모델과 딥 러닝을 포함한 맵리듀스(MapReduce) 패러다임에 맞지 않는 작업을 제대로 통괄하지 못했다. 기업들이 클라우드(cloud)로 옮겨가고, 대화형인 파이썬(Python)을 도입하고, GPU를 통합하고 데이터 과학이나 머신 러닝 사용 사례들의 다양성으로 눈을 옮기는 동안, 이런 데이터 엔지니어링 플랫폼은 딱히 이상적이지 못했다. 데이터 과학자들은 이런 플랫폼들에 반대했고 새로운 라이브러리와 하드웨어를 자신들 마음대로 가지고 놀고 실험해볼 수 있는 원래 하던 노트북 컴퓨터로 다시 눈을 돌렸다.

데이터 엔지니어링 플랫폼은 기업이 데이터 자산 구축을 시작할 수 있는 좋은 장소를 제공했다. 여기서 기업에서 데이터 과학과 머신러닝을 수용하면서 그 경직성(rigidity)을 잘 다뤄야하는데, 이 데이터 과학과 머신러닝은 관련성 유지를 위한 더 많은 유연성을 요구하는 무거운 짐을 지닌 아주 다이내믹한 분야라고 할 수 있다. 올인원 플랫폼은 쉽게 시작할 수 있도록 해주지만 데이터 과학 작업이 이보다 커질 때 문제가 될 수 있다.

클라우데라같은 데이터 엔지니어링 플랫폼이 SAS나 오라클과 같은 데이터 웨어하우징 플랫폼을 대체했다고 치자. 그렇다면 데이터 과학/머신 러닝 시대로 접어들면서 무엇이 클라우데라를 대체할 것인가?

BoB가 잘 다져진 기존 플랫폼을 대체할 것이라고 생각하는 이유

데이터 과학과 머신 러닝의 세계는 데이터 웨어하우징과 엔지니어링보다 훨씬 더 빠른 속도로 나아간다. 올인원 플랫폼은 너무 크고 단단해서 따라갈 수 없다. 게다가 ‘통합’의 이점은 오늘날 쿠버네티스(Kubernetes)와 같은 기술과 관련이 더 없다는 것이다. 이러한 이유를 조금 더 심층적으로 살펴보자.

데이터 과학과 머신 러닝은 유연성이 필요하다

“데이터 과학”은 ETL, 머신 러닝, 모델 관리, 유저 인터페이스와 같은 수십 가지의 활동을 포괄하는 엄청나게 광범위한 용어로서, 각각 빠르게 발전되는 선택지들이 많다. 데이터 과학자의 워크플로우 중 일부만이 가장 상위의 데이터 과학 플랫폼에 의해 지원된다. 일원화된 통합 플랫폼을 구축하려는 그 어떤 시도는 광범위한 특징들과 선택사항들을 각 선택사항마다 포함해야하므로 최신 상태를 유지하고 따라가는데 있어 극히 어려울 것이다. 실시간 데이터 피드(real-time data feed)를 통합하려면 어떻게 해야 하고 시계열 데이터(time series data)를 분석하려면 어떻게 해야 하는가? 그렇다, 올인원 플랫폼은 이런 니즈를 위한 툴이 있을 것이다. 하지만 당신이 진정 원하는 툴이 맞는 가? 기회가 생겼을 때 당신이 선택할 만한 툴인 가?

유저 인터페이스를 생각해보자. 데이터 과학자들은 주피터 노트북(Jupyter notebook), IDE, 사용자 지정 대시보드, 텍스트 에디터 등과 같은 많은 툴을 하루 종일 사용한다. “클라우드 내 주피터 노트북”만 제공하는 플랫폼은 실제 데이터 과학자들이 하루 동안 실제 사용하는 것 중 극히 일부에 불과하다. 이로 인해 데이터 과학자들은 절반의 시간을 플랫폼에서 보내고, 또 다른 절반은 플랫폼 밖에서 보내고, 추가적으로 같은 절반의 시간을 두 환경 사이를 오가는데 보내게 된다.

또한 올인원 플랫폼이 지원하는 컴퓨팅 라이브러리와 이러한 라이브러리가 얼마나 빠르게 시대에 뒤처지는 지에 대해 생각해보자. 다들 알다시피 클라우데라는 Spark 2.0가 출시(사실 6개월만에 출시되긴 했다) 된 후에도 몇 년간 Spark 1.6을 사용했다. 빠르게 변하는 오늘날 플랫폼이 앞서 가기엔 확실히 힘들다. 너무 광범위하고 수가 많아서 따라갈 수가 없는 것이다.

쿠버네티스와 클라우드는 ‘통합’을 상품화한다

다양한 데이터 과학으로 인해 올인원 플랫폼이 더 어려워진 반면, 인프라의 발전으로 BoB의 제품 통합이 더 쉬워졌다.

당시 하둡, 하이브, 스파크가 설정하고 조율하기 어려운 것으로 악명 높았기 때문에 클라우데라, 호튼웍스, MapR이 필요했다. 기술력이 부족한 기업들은 통합 솔루션을 돈 주고 위탁해야했다.

그러나 오늘날은 사정이 다르다. 현대 데이터 기술은 설정하고 구성하는데 훨씬 더 간단하다. 또한 쿠버네티스나 클라우드와 같은 기술은 구성(configuration)을 상품화시켜줬고 좁은 범위의 많은 제품으로 통합 문제를 줄여주었다. 쿠버네티스는 현대 기업들이 까다로운 과정 없이 BoB 제품을 필요에 따라 넣고 뺄 수 있도록 하는 신제품 통합에 대한 장벽을 낮춰준다. 예를 들어 Github의 머신 러닝 엔지니어인 Hamel Hussain이 말한 것처럼 쿠버네티스는 데이터 과학자가 모델(머신 러닝 등)에 쓰이는 API를 연동하고, 머신 러닝 워크플로우 시스템을 구축하게 해주며, 또 데이터 과학자가 OSS 기술을 통합할 수 있게 하는 웹 어플리케이션을 위한 흔한 기질이다.

쿠버네티스는 배치(deployment) 문제를 프로그래밍 방식으로 지정할 수 있는 공통적인 프레임워크를 제공한다. 결국 개별 통합자들보다는 라이브러리 작가들에게 손이 더 많이 가게 한다. 결과적으로 통합 작업이 상당히 감소하게되고 종종 일부 구성 값을 지정하고 배포를 시도한다. 여기서 아주 좋은 예시가 <Zero to JupyterHub Guide>이다. 누구든 평범한 컴퓨터 능력을 가진 사람이라면 잘 몰라도 한 시간안에 쿠버네티스에서 JupyterHub를 배치할 수 있다. 이전에는 꽤 깊은 전문지식을 가진 경력 전문가도 며칠이 걸렸을 것이다.

결론

BoB 데이터 플랫폼을 채택하는 기업들이 우리가 알고 있는 기술 변화에 더 잘 적응할 수 있을 것이라고 믿는다. 다년 단위로 모놀리식(monolithic) 데이터 과학 플랫폼을 고집하기 보다는 수요 변화에 따라 제품을 채택, 사용, 스왑할 수 있게 된다. BoB 플랫폼은 기업들이 빠르게 변화하는 오늘날의 환경에 발전하고 대응할 수 있도록 하게 해줄 것이다.

데이터 분석가, 데이터 과학자, 머신 러닝 엔지니어 및 기관들의 의사 결정을 데이터로 연결하는 모든 위성 역할의 증가는 (자동화와 기계 지능이 증가함과 함께) 최종 사용자의 니즈에 따른 툴링이 필수다. 이런 니즈는 빠르게 발전하고 있으며 또 빠르게 발전하는 오픈 소스 툴링과 연계되어 있다. 당사의 강력한 의견(확고했다)은 BoB 플랫폼이 올인원 플랫폼보다 이러한 OSS 툴로 구축함으로써 빠르게 발전하는 니즈들을 충족시킬 수 있는 더 좋은 위치에 있다는 것이다. 어떻게 흘러갈 지 기대 중이다. 

*****

원문 : Why Best-of-Breed is a Better Choice than All-in-One Platforms for Data Science

번역 : 김정욱