김진철의 How-to-Big Data | 빅데이터와 클라우드 기술 (5)

LHC 가속기와 검출기 실험 장치의 규모가 크다 보니, LHC 모든 서브 시스템이 하나의 시스템으로 통합되어 동작하려면 필연적으로 각 모듈이 네트워크를 통해 정보를 주고받으면서 데이터를 처리하는 분산 컴퓨팅 시스템으로 개발될 수밖에 없다. 분산 컴퓨팅 시스템이 하나의 시스템으로 통합되기 위해서는 시스템내의 각 서브 시스템의 동작을 표준화된 프로그래밍 모델과 통신 방식으로 프로그램할 수 있는 소프트웨어 기술이 필요하다.



LHC 검출기별로 실험의 목적과 동작 특성, 요구 사항이 다르고, 네 대의 검출기에 필요한 요구사항을 모두 만족시킬 수 있는 소프트웨어를 만들기에는 LHC 검출기 시스템이 너무 복잡하기 때문에 LHC의 물리학자와 컴퓨터 과학자들은 검출기마다 고유의 분산 컴퓨팅 소프트웨어를 개발하여 검출기 기능을 통합하였다. 검출기 기능 통합에 사용된 분산 컴퓨팅 소프트웨어는 여러 대의 노드로 기능이 분산되어 네트워크 통신을 통해 이들 기능에서 처리된 데이터를 통합하는 미들웨어의 형태로 개발되었다.

필자가 건설에 참여하였던 CMS 검출기의 경우 XDAQ이라는 미들웨어를 사용하였다. XDAQ은 크로스 플랫폼 분산 데이터 수집, 처리 미들웨어(Cr운영체제(OS)s-platform(X) Distributed Data Acquisition and Processing middleware)의 줄인 말이다. 검출기 서브 시스템의 기반 플랫폼 종류에 상관없이 XDAQ의 핵심 API(Coretools API)를 이용해 프로그래밍하면 HTTP/1.1과 I2O 프로토콜을 통해서 고속으로 데이터를 주고받는 분산 컴퓨팅 응용 프로그램을 손쉽게 작성할 수 있도록 개발되어 있다.



그림 2에 나타난 XDAQ 미들웨어의 기본적인 구성을 같이 한번 살펴보자. XDAQ의 핵심 기능에 해당하는 Coretools 모듈에는 XDAQ 프로그래밍 모델의 가장 중요한 핵심 기능이 응용 프로그램 인터페이스(Application Programming Interface; API)로 정의되어 있다.

가장 먼저 눈에 띄는 모듈이 OS 추상화 모듈이다. XDAQ으로 통합되는 시스템을 구성하는 각 노드는 필요에 따라 다양한 하드웨어와 OS를 사용하게 된다. 이 때문에 다양한 OS의 기능을 XDAQ의 요구사항과 이에 따르는 표준 동작(operation)에 따라 추상화, 표준화할 수 있는 인터페이스와 이를 구현하는 모듈이 먼저 만들어진 것이다.

그다음에 눈에 띄는 것이 실행 환경 프레임워크(Execution Framework)이다. 다양한 OS에서 동작하는 응용 프로그램이 OS마다 의존성을 만족시키게끔 응용 프로그램 개발자가 일일이 신경을 쓴다면 CMS 검출기의 복잡한 시스템을 완성하는데 필요한 노력과 시간이 엄청나게 들어가 LHC 건설 프로젝트의 일정에 맞게 CMS 검출기 시스템을 통합하기 어려울 것이다. 이렇게 이기종(heterogeneous) 하드웨어와 OS 환경을 극복하고, XDAQ 응용 프로그램을 위한 표준 실행 환경을 제공하기 위해 응용 프로그래밍 인터페이스(API)를 제공한다.

검출기 하드웨어의 많은 장비와 부품들이 임베디드 시스템이기 때문에 하드웨어에 접근하는 데 각 장비와 부품별로 다양한 방식의 소프트웨어를 써야 한다. 각 하드웨어 자원의 특성을 감추고 표준화된 방식으로 접근, 제어하며, 원격으로 하드웨어에 접근하고 제어 파라미터를 주고받을 수 있는 추상화된 하드웨어 접근(Hardware Access) 모듈이 기본 모듈로 정의되어 있다.

마지막으로 XDAQ에서 가장 중요하게 여겨진 기능 중 하나인 네트워크 프로토콜 중립 통신(network protocol-independent communication) 방식을 지원하기 위한 통신 모듈(communication subsystem)이다. CMS 검출기의 영역별로 네트워크 요구 사항과 장비의 특성이 다르기 때문에, 장비의 데이터 처리 요구사항을 만족시키기 위해 다양한 네트워크 프로토콜이 쓰이게 된다. Level-1 트리거내 각 모듈과 장비 간의 통신을 위해서는 이더넷이 쓰이지만, 고수준 트리거의 초반부에 요구되는 매우 높은 처리량(throughput)의 요구사항을 만족하는 컴퓨팅 성능을 내기 위해서는 미리넷(Myrinet), 인피니밴드(Infiniband) 등의 고성능 네트워크 프로토콜을 써야 한다.



고성능 네트워크 장비에서 사용하는 프로토콜은 기술이 발전하면서 내용과 종류가 변화하기 때문에, LHC 실험이 수행되는 30~40여 년의 긴 시간 동안 일어나는 이런 네트워크 프로토콜의 변화에 XDAQ 응용 프로그램이 영향을 받지 않아야 한다. XDAQ으로 프로그램된 응용 프로그램들이 네트워크 프로토콜 변화에 영향을 받지 않도록 네트워크 프로토콜 수준의 통신 기능이 먼저 추상화되고 표준화될 필요가 있었다. 이런 이유로 과거에 많이 쓰였던 고성능 네트워크 프로토콜인 미리넷(Myrinet)과 최근 고성능 컴퓨팅 시스템에서 많이 쓰이고 있는 고성능 네트워크 프로토콜인 인피니밴드(Infiniband)와 같은 네트워크 프로토콜을 직접 다루는 어려움을 겪지 않고 XDAQ 응용 프로그램을 프로그램할 수 있도록 프로그래밍 모델을 정의할 필요가 있었다.

글을 읽는 독자들은 위와 같은 네트워크 프로토콜 추상화는 유닉스나 리눅스의 소켓 라이브러리와 네트워크 라이브러리 인터페이스, 인피니밴드(Infiniband) 프로토콜의 표준 동작을 정의하는 OFED 라이브러리등으로 이미 추상화되어 있지 않느냐고 생각할 수도 있다. 더군다나 비즈니스 분산 컴퓨팅 시스템 개발을 위해 훌륭한 Java 미들웨어들이 많이 있지 않느냐고 반문할 수 있다.

필자가 XDAQ 개발에 참여했던 당시의 상황은 CMS 검출기의 고성능 데이터 처리 요구사항을 만족할 만큼 Java 기술이 발전하지 않았던 때였다. 더군다나 CMS 검출기가 개발되던 1990년대에서 2000년대까지의 기간에는 미들웨어 기술이 막 태동하여 발전하던 시기였다. 현재 독자 여러분들이 사용하고 있는 많은 훌륭한 소프트웨어 기술들이 당시에는 존재하지 않았거나 충분히 성숙하지 않았다. CMS 검출기의 데이터 처리 요구사항이 당시 기술로는 극한의 요구사항이었기 때문에 가능한 모든 방법을 동원해서 컴퓨팅 하드웨어의 성능을 최대한 활용해야 했었다는 점을 염두에 두고 필자의 글을 읽을 필요가 있다.

CMS 검출기 부품 대부분은 임베디드 시스템이기 때문에, 하드웨어 자원의 제약이 현재보다 훨씬 더 심했다. 이렇게 자원의 제약이 심한 임베디드 컴퓨팅 시스템에서 시스템의 자원을 최대한 절약하기 위해 장비별로 다양한 바이너리 데이터 표현과 프로토콜을 사용하였는데, 이렇게 다양한 데이터 표현과 프로토콜을 직접 다루는 어려움을 줄이기 위해 XDAQ 미들웨어와 같은 표준화된 인터페이스가 꼭 필요하였다. XDAQ 표준 응용 프로그램 인터페이스(API)가 없었다면 모든 검출기 시스템 개발자들이 직접 저수준 네트워크 라이브러리를 다뤄야 했기 때문에 개발 작업의 생산성이 크게 떨어졌을 것이고, 일정에 맞추어 CMS 검출기가 건설되기 어려웠을 것이다.
 

XDAQ Coretools API에는 XDAQ 응용 프로그램의 기반이 되는 애플리케이션이라고 하는 클래스가 정의되어 있다. 이 애플리케이션 클래스는 자바 서블릿 개발의 기본이 되는 javax.servlet.http.HttpServlet과 비슷한 역할을 하는 클래스이다. 이 베이스 클래스에는 동기 전송 플러그인(Peer Transport Plugin)이라고 하는 데이터 구조가 있어 XDAQ 응용 프로그램의 특성에 따라 메시지를 전달하는 네트워크 프로토콜을 손쉽게 바꿀 수 있다. 성능이 우선시되어 네트워크 지연이 최소화되어야 할 경우 Intel이 고속 데이터 버스 통신용으로 개발한 I2O 프로토콜로 데이터를 전송하며, 일반적인 XDAQ 응용 프로그램의 제어 및 데이터베이스 접근의 경우에는 HTTP 프로토콜을 이용해 SOAP 메시지 형태로 통신하게 된다.

위와 같은 Coretools 모듈의 핵심 기능을 이용해 P2P(Peer-to-Peer) 형태로 통신하는 확장성 있는 분산 애플리케이션을 쉽게 만들 수 있다. Coretools 모듈 위에는 개발자들의 분산 응용 프로그램 개발을 돕는 도구상자인 Powerpack 모듈이 있는데, 이 Powerpack 모듈에는 분산 시스템 소프트웨어를 개발하는 데 필요한 데이터 모니터링, 오류(error)와 알람(alarm)의 분산 전파 및 통신, 웹 기반의 사용자 인터페이스 도구, 작업 제어 모듈 등이 있다. 특히 작업 제어 모듈은 요즘 빅데이터 분야에서 많이 쓰이는 하둡의 작업 스케줄러와 비슷하게 원격 XDAQ 노드에 작업을 분산하여 실행시킬 수 있으며, 조금만 응용하면 하둡과 유사한 분산 병렬 처리도 가능하다.

위와 같은 Coretools 모듈과 Powerpack 모듈을 이용해서 그림 1의 CMS 검출기 고수준 트리거를 구성하는 이벤트 빌더(Event Builder), 빌더 유닛(Builder Unit; BU), 리드아웃 유닛(Readout Unit) 등의 분산 응용 프로그램을 손쉽게 작성하고 통합할 수 있었다. XDAQ이 없었다면 CMS 검출기에서 수집되는 초당 1TB의 데이터를 적절하게 필터링하고 자동 메타데이터를 처리할 수 없었을 것이고, CMS 실험을 수행하는 물리학자들이 힉스 입자를 발견하는데 더 많은 시간과 노력이 필요했을 것이다.

빅데이터 인프라를 완성하는 기술 – 빅데이터 미들웨어와 분산 컴퓨팅 소프트웨어
아홉 번째 글에서 최근 빅데이터 기술은 단일 프로세서 단위의 성능을 높이는 방향보다는 네트워크 또는 통신 패브릭(communication fabric)을 이용해 여러 대의 노드, 또는 프로세서 코어를 묶어 확장하여 빅데이터 문제를 해결하려는 방향으로 기술이 발전하고 있다고 언급한 바 있다. 이렇게 자원 확장성을 높이는 과정에서 부딪히는 문제 중 하나가 자원 이종성 문제인데, 이 자원 이종성 문제를 해결하는 데 가상화 기술을 도입하기 시작하면서 현대의 클라우드 컴퓨팅이 시작되었다고 얘기하였다.

빅데이터를 다루기 위해 계산, 저장 장치 확장성을 서버 노드의 수에 구애받지 않고 선형에 가깝게 확장할 수 있는 소프트웨어 기술을 만드는 것이 빅데이터 기술의 하나의 큰 방향이었다면, 또 다른 한 방향은 빅데이터를 활용하는 응용 프로그램이 많은 수의 노드로 구성된 복잡한 분산 컴퓨팅 시스템에서 어떻게 빠른 속도로 쉽게 개발될 수 있는지 문제를 해결하는 과정이었다. 분산 컴퓨팅 시스템의 자원을 성능 저하 없이 원하는 대로 끌어오는 자원 확장성 문제가 중요하기는 하지만, 자원을 무한히 끌어온다고 해서 빅데이터 처리를 위한 작업 분산 및 스케줄링, 작업 생애주기(life-cycle) 관리 등의 소프트웨어적인 모든 문제를 해결해주지는 못한다.

빅데이터 처리를 위한 분산 컴퓨팅 미들웨어의 중요한 역할 중의 하나는, 빅데이터 처리를 목적으로 구성, 구축된 분산 컴퓨팅 시스템의 각 서버 노드, 하드웨어, 네트워크 등의 저수준 복잡성을 최대한 추상화해서 감추고, 목표로 하는 빅데이터 처리에 적합한 프로그래밍 로직에 소프트웨어 개발자가 집중할 수 있도록 하는 단순화되고 효과적인 프로그래밍 모델(programming model)과 API를 제공하는 것이다.

빅데이터 기술에서 프로그래밍 모델과 API의 중요성을 보여주는 적절한 사례로서 구글의 맵리듀스를 들 수 있다. 하둡의 전신인 구글의 맵리듀스 기술은 구글만의 고유 요구사항에서 출발한 프로그래밍 모델이었다. 사실 맵리듀스 프로그래밍 모델 그 자체는 그 보다 훨씬 전에 알려져 있었지만, 구글의 제프리 딘(Jeffrey Dean)과 샌제이 게마왓(Sanjay Ghemawat)이 구글 검색 서비스를 위한 텍스트 빅데이터 처리를 위해 활용하면서 널리 알려지게 되었다. 구글의 맵리듀스와 하둡은 HTML 및 텍스트 기반의 웹 문서 빅데이터를 대량으로 쉽게 처리할 수 있게 하는 간단하고 효과적인 프로그래밍 모델로서 자리 잡으면서 빅데이터 기술을 대중화하는 데 크게 기여하게 된다.

또 하나의 사례로서 오픈소스 클라우드 컴퓨팅 소프트웨어인 오픈스택(OpenStack)을 들 수 있다. 클라우드 컴퓨팅은 다루는 기술의 범위가 매우 넓고 다양해서 한 회사가 적절한 시간 안에 개발해서 상용화하기가 어려운 분야였다. 아마존의 클라우드 서비스가 시장 1위를 여전히 지킬 수 있는 이유는 바로 이런 이유 때문이다.

오픈스택은 복잡한 클라우드 컴퓨팅 기술을, 기존의 오픈네뷸라(OpenNebula)와 클라우드스택(CloudStack) 등의 클라우드 컴퓨팅 소프트웨어가 가지고 있던 클라이언트-서버 아키텍처가 아니라, 메시지큐(message queue)기반의 서비스 지향 아키텍처를 기반으로 한 확장성 있는 아키텍처와 RESTful API를 이용한 프로그래밍 모델로 새롭게 정의하면서 데이터센터 스케일의 클라우드 컴퓨팅이 가능한 산업 표준 API를 만들어 냈다. 이런 오픈스택만의 아키텍처와 표준화된 API는 클라우드 비즈니스 시장의 진입 장벽을 크게 낮추어 주었다.

오픈스택의 진정한 가치는 소프트웨어 자체에만 있는 것이 아니다. 다양한 클라우드 산업계의 주요 주자들과 오픈소스 개발자들이 만든 오픈스택만의 고유 클라우드 프로그래밍 모델과 API가 진정한 가치다. 이 오픈스택 프로그래밍 모델과 API를 소프트웨어로 구현하는 데 필요했던 시간과 많은 소프트웨어 엔지니어들의 노력, 그리고 클라우드 컴퓨팅의 다양한 기술 요소들을 묶어주는 산업 표준 API의 정의 자체가 결코 구글이나 아마존과 같은 하나의 회사가 따라잡을 수 없는 경쟁 우위로 든든하게 자리 잡고 있다.

빅데이터를 다루기 위한 프로그래밍 모델이 적절하게 설계되어야 하는 이유는 크게 두 가지이다. 첫 번째로 빅데이터 처리, 분석을 위한 시스템을 개발하는 데 결국은 소프트웨어 엔지니어들이 빅데이터 응용 소프트웨어를 개발해야 하는데, 쉽고 효과적인 프로그래밍 모델로 추상화되지 않은 분산 컴퓨팅 시스템을 개발하는 것은 소프트웨어 개발의 생산성과 품질을 크게 떨어뜨려 시스템이 오동작할 위험 요소를 크게 늘이게 된다. 두 번째로, 분산 컴퓨팅 시스템의 특성상 테스트와 디버깅에 많은 노력이 들어가게 되는데, 적절하게 설계된 프로그래밍 모델은 분산 컴퓨팅 소프트웨어의 테스트 및 디버깅을 쉽게 하고 자동화율을 높일 수 있어 소프트웨어 개발의 생산성과 개발된 빅데이터 응용 프로그램의 안전성과 품질을 크게 높이게 된다.

아파치 HAMA(Apache HAMA) 등에서 맵리듀스 프로그래밍 모델을 좀더 일반화한 Bulk Synchronous Parallel(BSP) 모델, 최근 딥러닝 프레임워크로 각광받고 있는 텐서플로(TensorFlow)에서 사용하고 있는 데이터 플로우 모델(Dataflow programming model) 등, 빅데이터 시스템을 위한 프로그래밍 모델이 최근 많이 연구되면서 소프트웨어 엔지니어들이 활용할 수 있는 빅데이터 프로그래밍 모델과 이를 지원하는 소프트웨어 기술이 점점 많아지고 있다. 이는 빅데이터 비즈니스에서 부딪힐 수 있는 문제를 점점 더 쉽게 해결할 수 있게 해주기 때문에 빅데이터 비즈니스를 하려는 조직에는 좋은 일이다.

다만 기본으로 다시 돌아가도록 하자. CMS 검출기를 건설, 통합하고자 LHC 연구자들이 CMS 검출기의 독특한 요구사항과 조건을 철저히 분석했고, 이에 맞는 시스템을 구성하다 보니 1,000대 이상의 노드로 구성된 분산 컴퓨팅 시스템을 개발해야 했다. 이런 1,000노드 이상의 확장성이 필요한 분산 컴퓨팅 시스템에서의 이벤트 처리 및 분석 응용 프로그램을 쉽게 만들기 위한 미들웨어를 디자인하고 개발했다. LHC 연구자들이 XDAQ과 같은 미들웨어를 만든 것은 당시에 요구사항에 맞는 소프트웨어가 없었기 때문에 직접 만들었던 것이지, XDAQ 미들웨어와 같은 성능과 기능을 가진 오픈소스 소프트웨어나 상용 소프트웨어가 있었다면 당연히 활용했을 것이다.

빅데이터 비즈니스를 하려는 조직이 LHC 연구자들과 같이 다른 조직이나 회사나 쉽게 따라올 수 없는 빅데이터 수집의 비즈니스 모델을 가지고 이를 지원하기 위한 미들웨어나 프로그래밍 모델을 직접 디자인해서 개발할 수 있다면 완벽한 기술 진입 장벽을 쌓을 수 있을 것이다. 구글의 경우에도 검색 서비스가 본궤도에 오르는 과정이었던 초기 10여 년간은 자체 개발한 맵리듀스 분산 컴퓨팅 소프트웨어가 구글만의 기술적인 경쟁력이 되었다.

최근 구글은 직접 개발하는 소프트웨어도 많지만 다른 플랫폼 회사와 같이 오픈소스 소프트웨어를 많이 활용하거나, 소프트웨어 유지보수의 문제로 보유한 소프트웨어 일부를 오픈소스로 공개하는 추세이다. 구글이 검색 서비스 플랫폼에서 수집한 빅데이터, 지금까지 축적한 빅데이터 처리의 노하우, 최적화한 인프라는 다른 회사가 쉽게 따라와 넘볼 수 없는 핵심 경쟁력으로 자리 잡았다. 그 때문에 굳이 맵리듀스 같은 빅데이터 기술을 핵심 경쟁력으로 삼을 필요가 없어진 것이다.

빅데이터를 위한 소프트웨어는 기본적으로 분산 컴퓨팅 소프트웨어, 또는 미들웨어 형태이기 때문에 개발과 유지 보수에 많은 노력이 들어갈 수밖에 없다. 이런 이유로 어지간한 규모의 수익을 낼 수 있으면서 충분한 수의 고급 소프트웨어 엔지니어들을 보유할 수 없는 회사는 본인들을 위한 고유의 빅데이터 미들웨어와 분산 컴퓨팅 소프트웨어를 직접 개발하여 기술 경쟁력으로 활용하기가 쉽지 않다. 앞에서 언급한 바와 같이 최근에는 빅데이터 문제를 해결하려는 노력이 학계와 산업계에서 많이 진전되어 빅데이터 처리, 분석 과정에서 자주 만나게 되는 패턴에 쉽게 적용할 수 있는 소프트웨어와 솔루션이 많이 나타나고 있기 때문에 굳이 직접 개발할 필요는 없어지고 있다.

이렇게 빅데이터 문제를 해결할 수 있는 기술과 솔루션 선택의 폭이 늘어가는 상황에서 어떤 부분에 초점을 맞추어 비즈니스 경쟁력을 만들어가야 할까? 필자는 앞에서 강조했듯이 데이터 수집 기술과 데이터 수집을 위한 비즈니스 모델을 핵심 경쟁력으로 삼고, 비즈니스 모델과 데이터 수집 과정의 요구사항과 조건을 철저히 분석한 후에 이에 맞는 적절한 오픈소스 도구나 상용 소프트웨어 도구를 도입하여 사용하라고 권하고 싶다.

예를 들자면 구글에는 이미 20여 년에 걸쳐 쌓이고 가공된 빅데이터가 있으며 이는 다른 어떤 회사에서도 단기간에 수집하여 따라잡을 수 없는 자산이다. 물론, 이런 빅데이터를 지속해서 수집하고 가공하는 인프라와 시스템 기술도 대단한 핵심 경쟁력이지만, 이런 빅데이터 기술만을 핵심 경쟁력으로 삼지는 않는다는 것이다. 어떤 빅데이터 기술을 쓴다고 해서 그 회사의 경쟁력이 생기는 것이 아니다. 기업이 하려고 하는 빅데이터 비즈니스에 맞는 기술을 적절하게 사용하고, 이를 통해 오랜 시간 동안 빅데이터를 축적하고 비즈니스 수행에서의 우위를 유지한 상태에서 축적된 각 기업만의 역량이 후발 주자나 경쟁사가 함부로 뛰어넘을 수 없는 시간이라는 요소에 의해 지수함수(exponential function)적으로 그 경쟁력의 격차가 벌어지게 되는 것이다.

하둡이나 스파크(Spark)와 같은 빅데이터 소프트웨어들이 상당히 넓은 범위의 빅데이터 문제를 해결할 수 있는 것은 사실이지만, 모든 빅데이터 문제를 해결하지는 못한다는 것을 다시 상기시키고 싶다. 맵리듀스나 하둡은 원래 검색 엔진의 백엔드에서 대용량 텍스트 데이터 처리의 요구사항에 맞춰 만들어진 병렬 처리 프레임워크이므로, 이런 요구사항에 맞는 문제를 해결하는 데 쓰이는 것이 성능과 효과를 극대화할 방법이다. 이런 측면에서 하드웨어 아키텍처가 계속 발전하고 변화하고 있기 때문에, 미래 비즈니스 모델과 시장의 변화에 따라 요구되는 빅데이터 프로그래밍 모델, 기술과 솔루션을 개발하여 판매하는 기술 스타트업 시장의 가능성은 여전히 크게 열려 있다고 볼 수 있다.

빅데이터 관련 시장에서 가능성이 열려 있는 또 다른 시장의 하나는 빅데이터 엔지니어링 시장이다. 빅데이터 비즈니스는 하나의 소프트웨어 도구를 통해 완성되는 것이 아니라, 데이터 수집 기술과 비즈니스 모델을 핵심으로 하여 빅데이터 스트림 처리, 빅데이터 가공, 처리, 빅데이터 저장, 빅데이터 분석 및 비즈니스 프로세스 자동화 등의 다양한 영역의 시스템이 효과적으로 통합되어야 한다. 이렇게 빅데이터 비즈니스 요구 사항 전반에 대해 산업별, 비즈니스 형태별로 적절한 소프트웨어 제품 포트폴리오를 가지고 빠른 시간에 비즈니스 지원 시스템(BSS)과 운영 지원 시스템(OSS)을 설계, 구현, 통합할 수 있는 시스템 통합 및 엔지니어링 전문 회사는 사업 기회가 많다고 볼 수 있다.

빅데이터를 활용하는 방법이 크게 패턴화되어서 다양한 범용 솔루션이 등장할 수는 있지만, 빅데이터 시스템은 그 규모와 기업마다 다른 요구사항의 다양성을 생각하면 시스템 각각이 다른 고유하고 개성 있는 독특한 시스템이다. 이것은 마치 LHC와 같은 가속기를 여러 대 지을 수 없는 것과 비슷하다. 설사 LHC 가속기를 2대, 3대를 짓는다고 해도 그 규모와 건설하는데 드는 시간, 비용, 건설 기간의 기술 변화 등의 요인으로 오는 여러 가지 현실적인 문제 때문에 완벽하게 똑같을 수는 없다. 가속기 분야에는 머신 스터디(machine study)라 불리는 실험 장치 자체에 대해 연구하는 전문 분야와 연구 개발 절차가 따로 있을 정도이다. 목표로 하는 빔 에너지와 실험 파라미터가 비슷한 가속기를 국가별로 지어 실험했다고 해도 가속기와 검출기별로 각각이 독특하고 다른 장치이다. 이는 빅데이터 시스템에도 똑같이 적용된다.

위와 같이 각 빅데이터 시스템이 고유하고 독특한 시스템이기 때문에 이런 빅데이터 시스템을 엔지니어링하고 구축해서 제공해주는 회사가 경쟁 우위를 가지고 비즈니스를 할 수 있다. 앞으로 다양한 기술의 지수함수적 발전 때문에 시도할 수 있는 빅데이터 비즈니스 모델의 변화도 다양하고 많을 것이다. 이런 시장의 변화에 따른 기회를 신속하게 분석해서 자체적으로 보유한 빅데이터 기술 포트폴리오를 활용해 짧은 시간에 빅데이터 시스템을 엔지니어링 해줄 수 있는 회사는 큰 비즈니스 기회를 맞을 수 있을 것이다.

[참고문헌]
[1] 김진철, “LHC에서 배우는 빅데이터와 machine learning 활용 방안”, 2016년 9월 28일, A CIO Conversation for Technology Leadership – Breakfast Roundtable 발표 자료
[2] V. Halyo, A. Hunt, P. Jindal, P. LeGresley, P. Lujan, “GPU Enhancement of the Trigger to Extend Physics Reach at the LHC,” arXiv:1305.4855, August 14, 2013. (https://goo.gl/FNkk7a)
[3] XDAQ – CMS Online Software Project Homepage, https://svnweb.cern.ch/trac/cms (OS).
[4] XDAQ User’s Manual, https://goo.gl/8mS2Zx.
[5] XDAQ Developer’s Manual, https://goo.gl/8ENRbd.
[6] XDAQ API Documentation, https://xdaq.web.cern.ch/xdaq/doxygen/baseline14/.
[7] Andrea Petrucci, XDAQ Software Framework for Distributed Trigger and Data Acquisition Systems in Physics Experiments, Legnaro National Laboratories – Istituto Nazionale di Fisica Nucleare (LNL-INFN) – Seminar, 27 November 2014, Ceolin meeting room, Viale dell’Università, 2 – 35020 Legnaro (PD) – ITALY. (https://goo.gl/t7tpcP)
[8] “Data Acquisition in High Energy Physics,” by Johannes Gutleber, 2007.
[9] William Badgett, Juan Antonio Lopez-Perez, Kaori Maeshima, Aron Soha, Balys Sulmanas, Zongru Wan, CMS Web-Based Monitoring, FERMILAB-CONF-10-786-CMS-PPD. (https://goo.gl/XNhmVm)
[10] V. Brigljevic, G. Bruno, E. Cano, A. Csilling, S. Cittolin, D. Gigi, F. Glege, M. Gulmini, J. Gutleber, C. Jacobs, M. Kozlowski, H. Larsen, I. Magrans, F. Meijers, E. Meschi, L. Mirabito, S. Murray, A. Oh, L. Orsini, L. Pollet, A. Racz, D. Samyn, P. Scharff-Hansen, P. Sphicas, C. Schwick, Using XDAQ in Application Scenari Operational System of the CMS Experiment, Proceedings of the Computing in High-Energy and Nuclear Physics, MOGT008, La Jolla CA, March 24-28, 2003. (https://goo.gl/71Nb9t)
 
 * 김진철 박사는 1997년 한국과학기술원에서 물리학 학사, 1999년 포항공과대학교에서 인공신경망에 대한 연구로 석사 학위를, 2005년 레이저-플라즈마 가속기에 대한 연구로 박사 학위를 받았다. 2005년부터 유럽입자물리학연구소(CERN)의 LHC 데이터 그리드 구축, 개발에 참여, LHC 빅데이터 인프라를 위한 미들웨어 및 데이터 분석 기술을 연구하였다. 이후 한국과학기술정보연구원(KISTI), 포항공과대학교, 삼성SDS를 거쳐 2013년부터 SK텔레콤에서 클라우드 컴퓨팅과 인공지능 기술을 연구하고 있다. 빅데이터와 인공지능 기술의 기업 활용 방안에 대해 최근 다수의 초청 강연 및 컨설팅을 수행하였다. dl-ciokorea@foundryco.com