빅데이터

big data.

말 그대로 '큰 데이터'다. 그런데 도대체 얼마나 큰 데이터여야 빅데이터인가? 단지 크기의 문제가 아니라, 기존의 데이터 처리 방법으로는 더 이상 감당이 안될 만큼 거대하고, 다양한 데이터라고 할 수 있다.

빅데이터의 3V

빅데이터라는 개념을 정의하기 위해서 다양한 시도가 있었고, 다양한 정의 및 분류가 있었으나, 가트너의 애널리스트 더그 레이니가 제시한 3V가 널리 통용되는 편이다. 3V는 크기(volume), 속도(velocity), 다양성(variant)을 뜻한다.

크기

크기(volume)는 말할 것도 없다. 하루에도 어마어마한 양의 정보가 쏟아지고 축적되고 있다. IBM은 전 세계에서 날마다 생산되는 데이터의 양을 2.3조 기가바이트로 추정했다. (2.3조 바이트가 아니다.) 2012년 기준으로 페이스북은 하루에 500 테라바이트(51만2천 기가바이트)의 데이터를 처리하는 것으로 알려졌다. 유튜브에 1분마다 올라오는 동영상의 분량은 300시간이다. 하루에 49.3년 분량의 동영상이 업로드되고 있는 것이다. 현상은 자연스럽다. 과거에는 올릴 수 있는 건 글뿐이었다. 이제는 사진, 음악, 동영상도 오갈 수 있다. 사진 파일보다는 동영상 파일의 용량이 훨씬 크고, 저화질 동영상보다 HD 동영상의 용량이 훨씬 크다. 요즘은 야동도 풀HD 시대. 시간이 지날수록 네트워크를 오가는 데이터의 양은 급속하게 늘어날 수밖에 없다.

사용자가 주고 받는 데이터만이 전부는 아니다. 옛날에는 인터넷 서비스는 지역 장벽이 있었다. 인터넷은 장벽이 없지만 인터넷 서비스는 그렇지 않았다. 예를 들어, 검색엔진 초창기에는 검색엔진의 범위가 국가, 또는 언어권으로 국한되어 있었다. 야후는 각국별로 특화된 서비스를 제공했고 그에 따라서 서버도 분리되어 있었다. 브랜드는 글로벌이었지만 서비스는 글로벌로 통합되어 있었던 것은 아니었다. 그러나 이제는 글로벌 통합된 서비스가 대세다. 구글은 각국별로 도메인이 있지만 검색을 해보면 전 세계 웹사이트가 검색 범위다. 다만 국가별로 우선 순위가 다를 뿐이다. 페이스북이나 트위터도 전세계 어디서든 똑같은 서비스를 제공 받는다.

페이스북 본사는 미국에 있지만 서버는 그렇지 않다. 인터넷의 속도는 물리적인 거리에 영향을 받는다. 특히 대양을 건너려면 해저 케이블을 통해야 하는데, 이 용량을 증설하는 것은 쉬운 일이 아니다. 어느 나라에서 접속해도 빠른 속도를 제공하려면 서버가 미국에만 있어서는 안 된다. 모든 나라에 서버를 두지는 않더라도 최소한 권역별로 서버를 두어야 한다. 그렇다면 이 서버끼리도 동기화시켜야 한다. 나는 한국에 살고 있고, 친구는 미국에 살고 있다. 내가 올린 페이스북 글에 친구가 좋아요를 누르고 댓글을 달았다. 아마도 내 글은 한국의 페이스북 서버로 먼저 전송되었을 것이고, 친구의 댓글은 미국 페이스북 서버 쪽으르 전송되었을 텐데, 이 둘을 어떻게 짜맞춰야 할까? 내 글을 볼 때마다 미국 페이스북 서버에서 친구의 댓글을 끌어와야 한다면 낭비다. 결국 서버끼리 동기화가 필요하다.

사실 페이스북 같은 서비스는 실시간 동기화가 치명적인 것은 아니다. 친구가 올린 댓글이 실제 올린 시간보다 나에게 10초 쯤 늦게 보인다고 해서 그게 큰 문제인가? 따라서 동기화는 실시간이 아니라 일정한 시간 간격을 두고 한 번에 이루어질 것이다 같은 용량의 도로라고 했을 때, 자가용에 한 사람씩 타고 가는 것보다는 일정 간격으로 버스로 한꺼번에 실어나라는 게 교통체증이 훨씬 적을 것이다.

크기는 단지 양의 문제가 아니다. 그냥 하드디스크 용량 키우고 스토리지 서버 열나게 늘리면 되는 그런 문제가 아니다. 빅데이터 시대의 크기는 데이터의 처리 및 저장 방법, 그리고 서비스 구조에도 근본적인 개혁을 요구하고 있다. 이제는 한 대의 고성능 대형 서버가 모든 것을 처리하는 것이 불가능해졌다. 서버의 분산이 필요하다. 글로벌 서비스라면 세계 각지에 분산해야 한다. 과거의 데이터베이스 개념은 중앙집중식에 바탕을 두는 것이었기 때문에 지금과 같은 시대에는 맞지 않는다. 게다가 예전에는 데이터베이스 안에 모든 정보를 집어넣었다. 모든 데이터는 텍스트, 또는 인코딩된 텍스트로 데이터베이스 안에 저장되었다. 새로운 정보를 넣든, 있던 정보를 바꾸거나 지우든 반드시 데이터베이스를 거치지 않으면 안 된다. 데이터베이스는 모든 것을 알고 있고, 관리를 한다. 이제 넘쳐나는 대용량 바이너리 파일은 대체 어쩔 것인가? 과거에는 바이너리 파일은 따로 디렉터리 구조 안에 저장해 놓고 데이터베이스에는 그 파일이 있는 경로만을 저장해 두었다. 아주 간단한 방법인 것 같다. 과연 그러한 방식이 앞으로도 유효할 것인가? 수십억 개의 바이너리 파일이 넘쳐나는 상황에서도 과연? 데이터베이스와 파일시스템은 분리되어 있다. 즉, 파일을 옮길 때 데이터베이스에게 반드시 신고해야 할 필요가 없다. 데이터베이스가 모르는 상태에서 파일이 다른 곳으로 이사 갔다면 데이터베이스와 파일 사이의 연결고리가 끊어지고 파일은 미아가 될 수 있다. 텍스트보다 용량이 큰 바이너리가 주요한 정보인 경우에는 예전과 갈은 데이터베이스는 비효율의 극치가 될 수 있다. NoSQL로 대별되는 새로운 형태의 데이터베이스가 속속 등장하는 이유도 여기에서 찾을 수 있다.

다양성

빅데이터의 중요한 특징 가운데 하나는 데이터의 비정형성이다. 과거에는 데이터베이스화 하기 좋도록 데이터를 내놓으라고 사용자를 윽박질렀다면 이제는 사용자가 토해내는 별의별 데이터 속에서 의미 있는 정보를 찾아내야 한다. 백사장에서 바늘찾기를 시시각각으로 해야 하는 것이다.