티스토리 뷰

파일과 RDBMS(이후 DB). 몇 년 전까지만 해도 데이터를 저장하는 가장 일반적인 방법이었다. 우선 파일은 관리 비용이 저렴하지만 파일을 처리하기 위해서는 파일 전체를 메모리에 올려야하는 단점이 있다. 다시 말해 1GB 파일에서 1KB를 읽어오려면 메모리에 1GB 전체를 올려야 한다. 게다가 동시에 두 사람 이상 변경할 수 없다.

DB는 이러한 단점을 해결해 주었다. 데이터가 몇 백 GB가 있다고 해서 1KB의 데이터를 찾아오거나 변경하는 데 아무 문제가 없다. DB가 보유한 트랜잭션 처리 메커니즘은 두 사람 이상이 동시에 변경을 가해도 순차적으로 처리해 주는 동시성, 적합성을 보장해 주었다. 이러한 장점에 힘입어 RDBMS는 근 10년 동안 전성기를 구가해 왔다.

그러나 2010년대를 지나 하둡의 부상은 이러한 미묘한 평형에 파문을 일으키기 시작했다. 파일을 잘게 분산하여 저장 처리하는 방식을 가진 하둡은 대용량의 데이터를 손쉽게 처리할 수 있게 해 주었다. 1GB의 데이터를 파일에 저장해도 내부적으로는 여러 파일로 나뉘어져 저장된다. 1KB의 데이터를 처리하려할 때 1KB의 데이터가 들어가 있는 작은 파일만 메모리에 올리면 되기 때문에 파일은 용량의 제약을 벗어던 질 수 있게 되었다.

하둡이 탄생한 이면에는 SNS, 모바일의 트렌드 속에서 사람들은 초 거대 용량의 데이터가 주변에 있다는 것을 실감하게 되었고, 이를 통해 할 수 있는 일이 더 많을 것이라는 기대가 싹트고 있었다. 이러한 기대는 빅데이터라는 용어에 응축되어 급속히 번져나가게 되었다.

하둡을 경험한 사람들은 DB를 다시보기 시작했다. 지금까지 기업에서 사용하는 거의 모든 데이터는 DB에 저장, 관리하는 것이 상식이 되어 있었다. 이는 계정정보와 같은 예민한 정보는 물론 설비에서 나온 로그도 DB에 저장하는 것이 가장 보편적인 방식이었다. 그러나 로그와 같은 머신 데이터는 하루에 테라에 가까운 양으로 쏟아져 들어온다. DB의 처리량은 이를 충족시키지 못하기 때문에 DB에 저장하기 위해 1분에 한 건으로 데이터를 선별해 저장하는 등 처리량을 조절해 왔다.

양의 문제 뿐만 아니었다. DB는 스키마를 전제하고 있다는 점도 빅데이터와 약간 핀트가 맞지 않는 부분이다. DB에 데이터를 저장하기 위해서는 이미 정의된 형태대로 데이터를 잘 맞추어 저장해야 한다. 뒤집어 말하면 데이터를 맞추지 않으면 저장할 수 없다는 얘기가 된다. 머신 데이터의 경우 특정 장비에서 발생하는 경우가 많다. 펌웨어 업그레이드 등의 이유로 로그의 형태가 약간 틀어질 경우 이 형태를 감안하여 DB 스키마에 맞춰주지 않으면 저장할 수 없다.

빅데이터에서 비정형에 대해 강조하는 부분은 이런 것이다. 스키마가 전제되어 있지 않은 경우는 데이터가 이전과 다르더라도 저장에는 문제가 없다. 데이터를 볼때 이 데이터에 맞는 형태로 가공해서 보면 되기 때문이다. 그러나 DB의 경우 데이터를 스키마에 맞추기 전까지는 데이터를 저장할 수 없다.

이러한 문제들로 인데 빅데이터 솔루션으로 DB를 그대로 사용하자는 것은 상식이 아닌 것이 되어 버렸다. 아예 DB를 개발하는 업체들도 아예 하둡을 내장하거나 내세우는 것으로 이를  인정하고 있다. DB가 빅데이터 앞에서 작아지게 된 이유는 DB가 이제 구시대의 유물이라서가 아니라 DB는 그 나름의 용도가 확실한 솔루션이기 때문이다.

엄밀하게 정의를 내리면 DB(RDBMS)는 트랜잭션 데이터 처리 솔루션이다. 사용자 정보, 금융사의 원장과 같이 성능이나 대용량 보다 정합성이 최우선인 분야가 DB의 본래 영역이다. 그러나 DB만큼 데이터를 관리하고 처리할 수 있는 솔루션이 없었기 때문에 DB를 남발하여 사용한  측면이 있다.

머신 데이터나 SNS데이터 등과 같은 분야는 사실 정합성보다는 빅데이터에서 말하는 3V에 해당하는 그러한 분야이다. 이러한 분야는 하둡이나 로그프레소, 스플렁크같은 솔루션들이 더 적합하다. 그렇기 때문에 점차 로그와 같은 머신 데이터를 저장했던 DB는 빅데이터 솔루션에 자리를 내주고 있고 DB는 트랜잭션 처리라는 자신의 영역으로 고착되어 가는 것은 이미 예정된 트렌드로 자리잡아가고 있다.

빅데이터 시장이 점차 성숙할 수록 이러한 구분은 가속화 될 것이고 IoT와 같은 트렌드가 가세하여 향후 머신 데이터는 트랜잭션 데이터의 양을 압도하게 될 것으로 예상된다. 그리고 현재 데이터를 다루는 업무도 빅데이터와 중첩되는 현상이 심화될 것으로 전망한다.



내가 이디엄으로 옮긴지 이제 한 달을 채우게 되었다. 이디엄은 실시간 빅데이터 솔루션인 로그프레소를 개발한 회사이다. 지금까지  Oracle 성능 분석,  ALTIBASE 에서 DB만 파고 살다가 로그프레소를 선택한 이유는 바로 이러한 트렌드 때문이다. 시대가 나를 자극하고 내가 시대에 응답한 방법이라고 할수 있겠다.

로그프레소와 같은 솔루션은 데이터를 다루는 사람에게 있어 미래 그 자체이다. 외산 솔루션을 압도하는 성능과 유연성은 이미 통신, 금융사를 통해 검증이 되었고 나 또한 이를 직접 다뤄보면서 경험하고 있다. 명실공히 이 솔루션은 빅데이터라는 것을 현실로 끄집어 내리는 데 큰 역할을 할 것으로 확신한다.

현재 DB로 처리하는 데이터를 100으로 친다면 머신 데이터가 60을 넘을 것으로 생각된다. 이 60은 지속적으로 빅데이터 솔루션이 다루게 될 것이다. 그러나 여기서 그치지는 않는다. 이 60은 600이 되고 6000이 될 수도 있다. 도로를 만들면 그보다 더 많이 자동차가 생기는 것이 세상의 이치이다. 

경부고속도로도 처음에 개통할 때는 ‘차도 없는데 이렇게 만들어 뭐하나’하는 얘기가 있었다고 한다. 그러나 도로가 좋아지니 차를 탈 맛이 나고 탈 맛이 나니 자동차를 구매하게 되어 결국 고속도로의 이용자가 급증했다고 한다.

데이터 처리에서도 비슷한 현상이 나타나고 있다. 로그프레소로 실시간 빅데이터를 경험해 본 분들 중에는 그동안 하고 싶었지만 포기하고 있었던 것들이 요구사항으로 발전하기도 하고, 하나의 결과를 보니 다른 것과 엮어서 보고 싶어하기도 한다. 이렇게 니즈와 함께 데이터도 확장되고 있다.

빅데이터를 바라보는 관점도 서서히 발전해 나가고 있다. 수집에만 초점을 맞추던 사업들이 이제는 이를 통해 결과를 내는 쪽으로 선회하고 있다. 하둡보다 로그프레소를 선택하는 이유는 바로 이 지점이다. 이 과정이 지나면 데이터의 추이만 보는 것이 아니라 지표와 지표 사이의 관계에 초점을 맞출 것으로 예상된다. 로그프레소가 R을 눈여겨 보는 것은 바로 이 때문이다.

빅데이터라는 말이 하루 아침에 빛을 보기는 했지만 아직도 거친 수준이다. 그렇다고 해서 한갓 유행이 될 것 같지는 않다. 그 이유는 어떤 형태로 까지 성장할지 모르는 것이지 성장을 하지 않는 것은 아니기 때문이다. 

좋은 분위기를 가진 회사에서 그동안 갈망하던 일을 하기 시작한 것에 대해 깊이 감사한다. 글을 쓰는 것이 한결 수월해진 것을 보면 마음 속에 자유의 훈풍이 돌고 있나보다 하는 생각도 가지게 된다. 앞으로 빅데이터 가지고 수다 좀 떨겠구나 하는 예감이 든다. 


저작자 표시 비영리 변경 금지
신고
댓글
댓글쓰기 폼