빅데이터 시대의 정보시스템, 데이터 중심으로 패러다임 쉬프트를 생각할 때

오늘은 오래 전 얘기로 시작해볼까 합니다. 제가 처음 회사 생활을 시작한 것이 90년이니까 벌써 23년이 훌쩍되어 가는 것 같네요. 당시에 제가 들어간 부서는 CAD/CAM 연구소라는 곳이였습니다. 말이 CAD/CAM이 였지만 이외에도 CAE(Computer Aided Engineering) 이라고 해서 컴퓨터를 이용해서 다양한 기계, 전자회로등에 대한 시뮬레이션 역시 하는 부서였었죠. 지금도 당시의 선배들이 여전히 그 회사에 열심히 다니시고 계시죠. 물론 하는 일들은 조금씩 달라졌지만요.

각설하고 처음 제가 하던 일은 캐드파일을 변환하고 관리하는 소프트웨어를 개발하는 것이였습니다. 실제 제품 설계를 하고 있는 엔지니어들을 지원하는 소프트웨어 지원과 구축을 도맡아 할 때였습니다. 그 때 제가 하던 말이 지금도 생각이 납니다. 당시에 여전히 제도기를 이용해서 종이에 설계도를 그리고 소위 블루프린터를 만들어서 배포하고 그러던 때였는데 그 분들한테 어떻게든 캐드 시스템으로 작성해서 컴퓨에 저장만 해놓으면 잘 정리해서 쉽게 찾고 설계변경등이 용이하게 해주겠다고 말하고 다녔습니다. 네, 여기서 핵심은 바로 “캐드 파일 형태로 만들어 컴퓨터에 제발 넣어주세요!”  이렇게 시작한 일이 도면을 관리하고 관련 정보를 데이터베이스에 저장하고 (기억에 오라클 5 인가 6인가 부터 썼던 것 같은데 암튼.) 변경관리를 하고 워크플로우를 만들고 결재 시스템과 연동하고 등등 이러한 일들을 하게 되었죠. 이게 요즘 업계에서 말하는 PLM (Product Lifecycle Management) 의 시초라 할 수 있었던 것 같습니다. ERP 하면 SAP/R3 라는 것이 등장한 것도 한참 뒤의 일입니다.

이것이 불과 20여년 전에 기업에서 일어나고 있었던 일입니다. 당시에는 대부분의 정보들이 여전히 수기로 기록되고 워드프로세스들이 사용되기는 했으나 결재시스템과 연계가 제대로 되지 못하고 있었지요. 하지만 지금은 어떤가요? 너무나도 많은 정보, 데이터들이 기업에서 만들어지고 있습니다. 웹서비스가 만들어내는 데이터에 비해서 상대적으로 작다고 말할 순 있겠지만 이미 전세계의 기업들이 온갖 IT 시스템에 의해서 만들어지는 데이터들은 어마어마하고 국내의 대기업들이 내부에서 사용하고 있는 시스템들은 수백, 수천가지에 이르고 있죠. 생산설비에서부터 마케팅, 세일즈, 고객 정보 , 제품 정보 등등해서요.

그런데 이러한 데이터들의 특징은 기업 내부의 다양한 업무 프로세스나 생산 공정 그리고 체계적인 보고와 예측을 위해서 사전에 잘 정의된 체계 아래에서 저장되고 관리된다는 점입니다. 다시 말하면 각 시스템 자체가 분명한 목적과 틀을 가지고 만들어 졌으며 그 목적에 부합되도록 꾸준히 업그레이드 되거나 유지보수가 되는 그러한 시스템들이 만들어내는 데이터들이라는 것입니다. 이러한 시스템 통합을 위해서도 역시 잘 정의한 프로세스와 규약 아래에서 데이터베이스의 스키마가 정의되고 비지니스 로직이 적용되고 이를 위한 다양한 프레임워크나 플랫폼등이 도입되고 적용되는 것이죠. 그렇기 때문에 사전에 기존 업무를 분석하거나 이를 바탕으로 프로세스를 시스템 하기도 하고 새로운 업무 프로세스나 혁신 업무를 지원(보통 PI , Process Innovation 라고도 하죠) 하기 위해서 시스템이 함께 고려되고 구축되는 경우가 많습니다. 참고로 EP(Enterprise Portal),  메세징 허브 , SOA (Service Oriented Architecture) 이러한 것들은 바로 기업내의 복잡한 시합과 연동을 위해서 제안된 기술 또는 아키텍처라고 할 수있습니다.

소위 레거시 시스템이라고 하는 이러한 정보 시스템에 빅데이터라고 하는 것을 도입하고자하면 어떻게 해야 할까요? 하둡을 적용해서 ? NoSQL 을 적용해서? 이미 이러한 시스템들이 다루고 있는 많은 데이터들은 RDBMS 에 잘 저장되고 관리되고 있는데 여기에 어떤 여지가 있을까요? 여기서 무언가를 해야 할까요? 아무튼 데이터가 무지무지 많으니까 빅데이터 아니냐 할 사람도 있을 것 같고. 빅데이터이고 머고 다 과장된 마케팅 용어라 말하고 이미 우리는 어마어마한 데이터를 이러한 시스템에 담고 있다고 말하는 분들도 있을테지요. 머 간혹 CRM 을 하는 분들이 이거 예전에 한 거랑 머가 다른데 하는 분들도 당연히 계실 것 같네요. (이 말은 G사 대표님이 늘 해주시던 말이라서 살짝 인용하겠습니다. ^^)

사실 많은 기업, 특히 대기업들이 빅데이터를 도입할 때의 딜레마는 이러한 점에서 오지 않을까 생각해봅니다. 즉 체계적인 업무 정의와 이를 바탕으로 구현된 시스템이 만들어내는 데이터를 기반으로 요즘 말하는 빅데이터의 가치를 찾아 낼 수 있을 것인가 하는 것이죠.

단적으로 말하면 사실상 어려울 것입니다. 단순히 대용량 데이터를 처리하는 기술을 도입해서 이를 통해서 찾을 수 있는 비용절감 이 외의 부가 가치를 만들어낼 수 있느냐 하는 질문에 자신있게 답을 할 수 없다는 얘기입니다. 제가 왜  장황하게 제 과거의 한 일들과 기업의 정보 시스템에 대해서 간단히 언급을 한 것은 이 점을 강조하기 위해서 입니다. 기존의 정보시스템이라는 프레임 안에서 교육을 받고 개발을 하고 운영을 하던 많은 사람들의 사고체계와 시스템 체계 안에서는 쉽사리 빅데이터라는 것을 제대로 받아들이고 수용해서 새로운 가치를 찾기가 어렵다는 말입니다. 이 점에 있어서는 저 역시 이러한 관성을 크게 가지고 있는 사람이여서 마찬가지라고 생각이 듭니다만…

다시한번 간단히 정리하면 이렇습니다. 대부분의 기업 데이터들은 필요한 업무 프로세스를 지원하기 위해서 정의된 정보 시스템에서 만들어진것이다. 데이터가 어떻게 생성되고 어떤 프로세스에 의해서 만들어지는가가 명확합니다. 그 만들어지는 데이터의 범위와 양도 충분히 예측이 가능하죠.

제 블로그나 기타 빅데이터에 대한 글을 보신 분은 3V(Volume, Velocity, Variaty 또는 4V(+ Value) 이런 얘길 많이 들어보셨을테지만 정말 중요한 것은 바로 데이터가 어디에서 어떻게 만들어지는가입니다. 공교롭게 빅데이터라고 하는 대용량의 데이터들은 앞서 말한 잘 정의된 프로세스와 스키마 안에서 만들어지는 데이터들이 아닙니다. 오히려 구글은 온갖 웹상의 문서를  크롤(자신들이 정의하지도 직접 만들지도 않은) 해서 거대한 빅데이터 플랫폼을 바탕으로 검색 서비스와 검색 광고 시장을 잡고 있습니다. 페이스북이나 트위터 역시 데이터를 만들어내는 플랫폼만을 제공하지 그 안에서 만들어내는 데이터와 친구관계라는 정보는 사용자들에 의해서 생성되고 이를 바탕으로 역시 광고나 새로운 서비스를 선보이고 있구요. 페이스북이나 트위터 역시 사용자들의 행태를 보고 서비스를 바꾸어나가는 것이지 꽉 짜여진 틀안에서만 데이터를 입력하게 하고 있지 않습니다. 오히려 더 다양한 데이터를 담을 수 있도록 노력하고 있다는 것을 알 수 있을 것입니다. 아마존이나 네플릭스와 같은 추천 엔진들 역시 고객들의 거래 정보를 바탕으로 이루어지는 것이고 이 정보 역시 원래 서비스가 제공하는 프로세스와는 별도로 저장되던 고객의 거래 정보를 활용해서 적용된 것입니다. (아마존의 추천 시스템을 적용한 엔지니어에게 제프 베조스가 무릎을 꿇고 경의를 표했다는 얘기도 들리던데..) 그래서 빅데이터에 많이들 강조하는 것이 데이터에서 그 가치를 찾아내는 것이라고 말하기도 하고 ‘오일’ 이라고도 표현하기도 하죠.

미묘하지만 바로 여기서 패러다임의 전환이 필요합니다. 미리 잘 정의된 프로세스와 데이터 스키마에서 만들어지는 데이터라는 것은 이미 그 가치가 프로세스가 잘 돌아가게 만들어진 그 시스템에 부여된 것이지만 빅데이터라고 하는 것은 그게 무엇이든 데이터로 시작해서 그 데이터를 기반으로 가치를 찾아내는 것이라고 생각하면 됩니다.

좀더 쉽게 이해하기 위해서 다른 예를 들어보겠습니다.  전파망원경이나 입자가속기에 대해서 들어보셨을텐데요.  이러한 측정 장비들은 하루에 수PB 의 데이터를 생성하고 있습니다. 그런데 이러한 기기와 데이터를 처리하고 연구하는 50여명의 몇 안되는 과학자들을 위해서 천명이 넘는 소프트웨어 엔지니어들이 이런 데이터를 저장하고 분석할 수 있는 소프트웨어 개발을 합니다. 비록 극단적인 예가 될 수 있겠지만 바로 엄청난 데이터 속에서 가설을 정의하고 이 가설을 뒷받침하는 정보를 찾아내기도 하지만  이제는 더 나아가 이러한 소프트웨어 프레임워크와 도구를 이용 대용량 데이터를 다양하고 빠르게  분석함으로써 새로운 이론을 이끌어내고 있다는  것입니다.

과학계쪽의 기존 방법론은 우선 이론을 정립하고 식을 만들고 이를 뒷받침하는 실험이나 관찰을 통해서 입증하는 것이였다면 이제는 엄청난 측정 장비와 대용량 데이터를 기반으로 거꾸로 새로운 이론이나 가치를 찾아내고 있는 것입니다. 그리고 이를 지원하는 소프트웨어라는 것이 데이터를 잘 수집하고 분석하고 시각화 할 수 있는 도구라는 점이 기존의 프로세스 중심의 시스템과 큰 차이가 있습니다.

여전히 많은 사람들이 빅데이터가 무엇인가에 대해서 혼란스러워하고 각기 다르게 해석하는 큰 이유가 기존의기업시스템이나 정보시스템의  패러다임에 고착되어 있어서가 아닐까 생각됩니다.

이러한 관점에서 본다면 빅데이터라고 하는 (사실 data-driven , data-intensive 라는 말이 더 정확한 표현이 아닐까 생각 합니다만) 것은 이제 시작일지 모릅니다. 하둡(Hadoop_ 이라는 것이 이제 비로소 이러한 패러다임 전환을 뒷받침할 수 있도록 상대적으로 저렴한 비용으로 빅데이터를 처리하는 데이터 플랫폼의 시초가 되는 것은 아닐까 하는 생각이 드는 것이죠.  여전히 대용량 데이터에 대한 분석 도구, 분석 알고리즘,  시각화 도구들이 여전히 부족합니다. 당연하지만 이러한 기술과 전문 인력을 가진 구글, 아휴, 페이스북과 같은 회사들이 이 분야에서 크게 두각을 나타내고 있습니다.

이러다보니 많은  기업들이 이들을 쫒아가려하지만 근본적인 역량 확보와 접근에 있어서 한계를 가질 수 밖에 없다고 봅니다. 또한 고객의 사용 정보나 센서 정보들이 충분히 축적되어 있지 않다보니 플랫폼이나 빅데이터 분석 도구에 대한 니즈에 대해서 깊이 고민할 기회도 없었을 것입니다. 최근 빅데이터의 트랜드에 편승해 서둘러 빅데이터 플랫폼을 구축하지만 분석은 커녕 충분히 저장된  데이터는 하나도 없을 수도 있을 겁니다.

그래서 웹서비스 기업(포털, 게임회사 등) 들 ,  통신회사들은 하둡과 같은 빅데이터 기술 도입을  빠르게 진행하고 나름 수혜를 받고 있는 반면에 전통적인 일반 기업에서의 빅데이터 도입은 쉽지 않을 뿐더러 그 사례를 찾기가 쉽지 않은 이유이기도 합니다.

아무튼 프로세스 중심(Process-Driven)의 정보시스템에서  이제 데이터 중심의(Data-Driven) 정보시스템으로 바뀌는 시대가 되었습니다

여러분들은 갈아 탈 준비되셨나요?

덧,  The Fourth Paradigm 이 책 한번 읽어 보세요. 이번 포스팅을 쓰게 된 동기가 되었는데요.  다 볼 필요는 없고 샘플을 킨들로 받아서 서문만 읽어봐도 좋을 듯 싶습니다.

에버노트에 쓰여져 있던 빅데이터(Big Data) 에 대한 단상…

오늘 에버노트를 정리하다가 적혀 있는 빅데이터에 대한 이것저것 작성해 놓은 것이 있어서 공유합니다.  보통은 제가 경어체를 쓰는데 저 혼자 정리한 것이다 보니 말투가 좀 그렇습니다. 이해해주시길 바랍니다. 제 블로그를 통해서 했었던 말들이고 중언부언이지만. 아마 발표자료 준비를 하다가 생각나는데로 적어 놓았던 것 같은데요.

 

올해 혹시나 빅데이터 프로젝트 하시는 분들 다시 한번 잘 생각해보세요. 정말 해야 하는 프로젝트인지 말이죠. ^^

• 빅 데이터는 솔루션으로 해결할 수 있는가?
  • 기존의 IT 기술과 차이점은 어떤 것이 있는가?
    • 당연히 기업의 가장 은밀하고 중요한 내부 데이터를 함부로 외부에 공개할 수가 없다
    • 외부의 전문가 , 개발자들이 프로젝트로 참여해서 이러한 데이터를 다루고 처리하는 것이 쉬운 일이 아니다.
      • 역량이 쌓이지도 않는다. 기술 내재화가 필요한 것이다.
    • 데이터를 쉽게 수집하고 저장하기 위해서 하둡이라는 것이 규모가 커지기 시작하면 생각보다 그렇게 간단치 않다
    • 끓임없는 시행착오와 최적화 작업이 필요한 것이다. 소프트웨어, 하드웨어, 프레임워크, OS 모두를 고려한 엔지니어링이 필요하다
    • 그래서! 여건이 된다면 잘 알려진 오라클, DB2 등과 같은 고가의 상용 데이터베이스 시스템과 관련 솔루션등을 구매해서 활용한다
    • 매우 잘 표준화되어 있고 관련 기술 교육도 용이하고 인력 확보도 상대적으로 쉽다. 벤더들이 열심히 교육도 시켜준다.
  • 하둡과 빅데이터 기술은
    • 소프트웨어 기술과 시스템 기술이 결합되어서 활용될 수 밖에 없다
    • 이러한 인력이 국내에는 많지 않다
    • 너무나도 잘 분업화되어 있다보니 양쪽을 이해하고 최적화할 수 있는 DevOps 역할을 할 수 있는 인력이 적다
    • 특히 국내에서는 시스템 엔지니어에 대한 대우나 평가가 소프트웨어 엔지니어어 비해서 더욱 좋지 않고
    • 좋은 인력 양성도 되어 있지 않다. 많은 시스템 엔지니어들이 매우 단순한 작업에 매진하고 있다
    • 이러다보니 표준화되어 있는 데이터베이스, 운영체계에 익숙한 인력들만 있고
    • 빅데이터 기술을 최적화하고 엔지니어링할 수 있는 인력 확보는 매우 어려운 것이 현실이다
    • 실제 현업에서 더욱 이러한 문제에 많이 부딪히고 있다
    • 그래서 포털회사나 게임회사에는 이러한 경험과 기술을 가지고 있는 고급 인력들이 있으나 그 외에는 찾기가 쉽지 않다.
    • 최근에 이러한 기술 인력들에 대한 대우들이 좋아지고는 있다.
    • 빅데이터에 대한 기술은 외부에서 가져오는 것이 아니라 내부에서 역량을 쌓고 노하우를 쌓아야 하는 것이다.
    • 대용량 데이터가 없다면 역량이 쌓일리가 없다. 그냥 좋은 컴퓨터와 스토리지로 해결하는 것이 훨씬 낫다.
    • 이러한 점을 간과하면 프로젝트를 실패하기 쉽게 국내의 많은 벤더들이 이러한 기술을 갖추고 있는 엔지니어들을 확보하지 못해서 실제 빅데이터 비지니스를 하지 못하고 있다.
• 국내에 페타급 데이터를 보유하고 처리할 니즈가 있는 곳이 얼마나 될 것인가?
  • 앞으로는 빅데이터 트랜드에 따라서 늘어나겠지만 실제 페타바이트를 처리할 니즈가 있는 곳은 별로 없다
  • 이것이 바로 빅데이터 트랜드에서의 함정이라고 할 수 있다
  • 많은 데이터 분석 솔루션 업체들은 데이터의 크기보다는 데이터의 특성을 잘 활용해서 분석하고 예측하는데 그 노력을 기울이고 있다. 하지만 … 이것 역시 한계가 있다
  • 빅데이터는 역시나 빅데이터이다. 대용량 데이터를 가지고 있고 이를 통해서 가치있는 정보를 찾아내고 이를 이용해서 기업활동에 활용할 수 있어야 하는 것이다
  • 빅데이터는 기존 통계, 예측해서 말하는 샘플링이 아니라 ‘모수’ 그 자체를 다루는 기술이라고 말할 수 있기 때문이다
  • 데이터가 많지 않다면 차라리 기존의 데이터베이스 솔루션과 분석 솔루션을 활용하는 것이 바람직하다
  • 어설프게 빅데이터 기술을 적용하면 오히려 시스템은 복잡해지고 비용만 급증하게 되는 애물단지가 될 수밖에 없다
• 작은 기업에서의 빅데이터 활용
  • MySQL 과 같은 오픈소스 데이터베이스와 함께 운영되는 데이터 분석 플랫폼. 그런데 MySQL 보다 더 큰 규모의 데이터를 가지고 있는 경우 검토.
  • 너무 큰 규모의 클러스터 구축은 피해야 한다. 차라리 클라우드 컴퓨팅 서비스를 이용할 생각해야 한다.
  • 글로벌 서비스를 준비하는 스타트업들에 있어서는 고려해볼 필요가 있다
• 작게 그리고 단계적인 접근이 필요하다
  • 내재화 할 수 있는 인력을 갖추고 있지 않으면 시작하지 마라
  • PILOT 과 실제 적용은 크게 다를 수 있다
  • 시스템의 규모가 커지면 분산컴퓨팅과 규모에 따른 다양한 문제점에 부딪히게 된다.
  • 기술이 아니라 노하우다
  • 그것은 바로 각 기업이 다루는 데이터의 규모와 특성에 따라 달라질 수 밖에 없기 때문이다.
  • RDBMS 와의 연동, 병행을 반드시 생각해야 한다.
  • 레거시 시스템은 늘 고민거리다
• SQL은 영원하다
  • 빅데이터 솔루션들은 그 위에 SQL 을 지원하도록 진화하고 있다
  • TABLE 이라고 하는 로지컬 모델은 여전히 강력한 도구이다
  • 기존의 분석 인력들이 손쉽게 활용이 가능하게 되었다
  • 하지만 호수의 백조처럼 그 아래의 DevOps 의 역할은 최적화를 위해서 더욱 커지게 된다.
  • Tools
    • Apache Hive
    • Cloudera Impala
    • Teradata Aster’s SQL-H
    • EMC Pivotal HD , HAWQ
    • Informatica
    • 이 밖에도 참 많다.

그래서 “빅데이터(Big Data)”가 도대체 뭐냐고…

지난 주에 아시는 지인으로 부터 한 통의 전화를 받았습니다.

“빅데이터를 어떻게 봐야 하는가?”

그때는 전화상이여서 상식적인 선에서 적당히 말씀 드렸지만 이미 그분이 계시는 곳에서도 하루에도 몇 TB의 데이터를 쌓아서 분석하고 예측을 하고 있는 상황에서 도대체 이놈의 “빅데이터” 는 어떻게 받아들이고 계신지 제가 더 궁금했을 정도입니다. 아무튼 나중에 다시 만나 뵈면 구체적으로 여쭈어 볼 생각입니다.

그래서 다시 한번 생각을 해보게 되었습니다.

“정말 빅데이터란 무엇인가?”

저는 여전히 빅데이터라고 하면 대용량의  데이터를 다루는 일이 그 핵심이라고 생각합니다.

오라클과 같은 데이터베이스 시스템에 다소곳이 저장되어 처리가 되기를 기다리는 정형화된 데이터(structued data)보다는 사용자들이 웹이나 앱을 사용하면서 발생하는 각종 로그 데이터나 센서로부터 끓임없이 발생하는 스트리밍 데이터와 같은 비정형적인 대용량 데이터(large scale unstructured data) 를 다루기 위해서 등장한 기술 , 트랜드가 빅데이터라고 믿고 있습니다. 물론 지금은 프레임워크 , 플랫폼, 저장기술, 분석기술 , 인공지능, 데이터 마이닝, 기계학습, 예측 모델, NoSQL, 클라우드 컴퓨팅에 이르기까지 그 의미와 적용 범위가 넓어지고 이로 인해서 사람들에게 혼란을 주고 있지만 여하튼 빅데이터는 “빅” 인것이죠.

물론 단순히 대용량의 데이터만을 다루는 것만이 빅데이터라고 말씀드리는 것은 아닙니다. 이러한 대용량 데이터를 배치 프로세스이든 실시간으로 처리하든 목적을 이루기 위해서 필요한 일련의 기술과 운영능력 등등이 모두 포함된 것을 빅데이터라고 말하는 것입니다.

그렇다면 데이터가 매우 많은 포털, 게임사, 통신사, 연구소, 그리고 글로벌 기업들만 이러한 빅데이터에 대한 기술과 역량을 갖추어야 하는 것일까요? 또는 어느 정도의 데이터가 있는 기업들이 이러한 빅데이터 기술과 역량을 도입하고 적용해야 하는 것일까요? 중소기업들은 빅데이터라는 기술에 대해서 관심을 가질 필요가 없는 걸까요?

아시다시피 하둡이라고 하는 기술은 x86 계열의 범용서버에서 자바만 설치하면 사용할 수 있는 상대적으로 매우 간단(?)한 분산 컴퓨팅 프레임워크를 제공하고 있습니다. 뿐만 아니라 Pig, Hive 을 활용하게 되면 복잡한 자바프로그래밍을 하지 않아도 손쉽게(?) 데이터를 처리하고 분석할 수 있는 환경을 제공하고 있습니다. 뿐만 아니라 HBase 와 같은 것을 프레임워크를 설치하면 어느정도 스키마를 제공하는 대용량 데이터베이스 환경을 갖출 수가 있습니다.

그런데 이미 적당히 성능좋은 서버와 스토리지 서버를 이용해서 MSSQL 또는 오라클을 설치해서 데이터를 저장하고 처리를 하면 별 문제 없는 곳에서 하둡을 도입할 필요가 있냐는 것입니다. 주위에서 빅데이터라고 말하고 하둡이 머고 어쩌고 하지만 살펴보니 그냥 지금 데이터베이스에서 별 문제가 없다면 하둡을 도입할 필요가 없는 것이죠.

표준화되고 최적화된 SQL 언어와 상대적으로 구인하기 쉬운 DBA가 있는데 하둡을 도입해서 드는 개발비, 학습시간, 시행착오, 추가적인 운영비등을 고려하면 하둡이나 몽고DB등과 같은 NoSQL 기술들은 과유불급이 되어서 쓸데없이 돈만 쓰고 효과가 있기는 커녕 시간낭비에 시스템 전반을 불안하게 만들 수 있는 요인만 키우는 꼴이 됩니다.

하지만 대용량의 데이터를 다루는 포털, 게임사, 통신사등은 하둡과 관련된 빅데이터 기술을 통해서 단기적인 효과는 쉽게 얻을 수 없었겠지만 중장기적으로는 비용절감 측면이나 대용량 데이터를 처리할 수 있는 역량을 내재화하기 위해서 몇년전 부터 빅데이터 기술을 도입을 하고 노력을 기울이고  있습니다.

그리고 사실 이미 국내의 할만한 곳은 다, 빅데이터와  환경과 기술 투자, 인력투자를 마치고 열심히 그 실질적인 성과를 높이기 위해서 노력들을 하고 있다고 생각됩니다. 제가 하나하나 구체적인 케이스를 확인할 수는 없지만요 하둡 엔지니어 구해달라는 주변 분들의 얘기나 국내에서 발표되는 사례를 보건데 이미 국내에서는 여러 빅데이터 파일롯 프로젝트들이 규모가 되는 커머스기업이나 대기업을 중심으로 제법 하고 있는 눈치입니다. 사실 눈치밥으로 말씀드리는 거에요. 세세하게 어디 어디가 하고 있는지는 저도 잘 모릅니다만.^^

그런데 흥미로운 부분이 있습니다. 바로 회사의 규모는 작지만 웹이나 모바일 서비스를 하는 기업들이 사용자의 로그데이터를 기반으로 통계를 내거나 행태분석을 위해서 하둡과 같은 빅데이터 기술을 활용하는 예입니다.

이것도 두가지로 나뉠 수가 있는데요.

하나는 돈이 충분하지 않아서 중견기업과 같이 중형급이상의 서버와 오라클과 같은 상용 데이터베이스를 도입할 수 없어서 저가의 x86 범용서버에 MySQL로 어떻게든 해보고 있다가 5대~10규모의 소규모 하둡클러스터를 구축해서 데이터 저장과 통계, 분석을 하는 경우입니다. 하둡이나 NoSQL은 그 특성상 저가의 스토리지를 이용해서 대용량 데이터를 효율적으로 저장할 수 있고 , 전체 데이터를 대상으로 조건에 맞는 데이터를 카운트하는데는  매우 최적화되어 있습니다. 의외로 이렇게 ROI(투자대비 효용)가 맞아떨어지기 때문에 이러한 빅데이터 기술이 요긴해지는 것이죠.

또 하나는 클라우드 컴퓨팅 환경에서 웹이나 앱을 기반으로 서비스를 하는 스타트업이나 중소업체의 경우입니다. 아마존, MS애저, 구글뿐 아니라 여러 PaaS 에서는 사용자 로그를 저장할 수 있는 스토리지 서비스, 대용량 데이터스토어,  데이터를 분석할 수 있는 하둡과 빅데이터 서비스와 함께 제공하고 있습니다. 비록 자체적으로 빅데이터 환경을 갖추고 있지도 않고 개발 인력도 부족하지만 이러한 클라우드 컴퓨팅 환경에서의 빅데이터 기술의 활용은 크게 늘어나고 있고 앞으로 더 늘어날 것입니다.

이러한 논리로 정리하다보니 결국 빅데이터의 도입은 어느 정도의 예산이 있고 운영할 역량이 되는 적당한 규모의  중견기업보다는 어떻든(?) 적용할 분야가 있을 수 밖에 없는 대기업과 정말 돈이 없는 스타트업 또는 중소기업에게나 필요한 것은 아닐까 생각이 듭니다. 결국 주어진 여건(예산)에 따라서 체감하는 “빅” 은 달라질 수 밖에 없는 것이죠. ROI 라는 말이 생각나네요.

그러고보니 빅데이터의 정의를 ”일반적으로 사용하는 방법이나 도구로 수집, 저장, 검색, 분석, 시각화 등을 하기 어려운 정형 또는 비정형 데이터세트” (위키피디아 참조) 가 아니라 “주어진 예산에 따라서  수집, 저장, 검색, 분석, 시각화 등을 하기 어려운 정형 또는 비정형 데이터세트” 라고 바꾸어야 하지 않을까 싶기도 합니다.

여튼저튼 “빅” 을 쏘옥 빼고 “데이터”에 자체에 대해서는 생각들 해보시나요?  ”데이터” 만 이해하기에도 참 어려운 세상입니다.

앞으로 국내의 빅데이터 시장은 성장할 것인가?

여전히 빅데이터에 대한 관심이 뜨겁습니다. 좀처럼 수그러들줄을 모르네요. 작년 첫 포스팅을 할 때만 해도 올해 하반기에 접어들면 빅데이터에 대한 열기가 식을 것 같았습니다. 하지만 빅데이터라는 것이 이제는 기존 관계형 데이터베이스와 데이터웨어하우스 기반으로 구축된 데이터 플랫폼에서 하둡과 NoSQL기술을 기반으로하는 데이터  플랫폼으로 전환해나가면서 필요한 모든 기술과 솔루션을 포함하고 있을뿐 아니라 과학,기업,인터넷,앱 등등에서 엄청나게 발생하고 있는 대용량 데이터에 기반하는 분석시스템,예측시스템 및 관련 기술,솔루션 등등을 망라하게 되면서 더욱 더 빅데이터는 그 영역이 넓어지고 자연히 관심과 기대가 더욱 커지는것 같습니다.

결국 요즘 분위기는 데이터와 관련이 있는것이라면 그것이 무엇이든 모두 빅데이터의 범주에 넣어서 얘기들 하고 있는 것이죠. 이러다보니 기존 데이터 시스템, 데이터 분석 솔루션들은 하나같이 빅데이터 전문 업체로써 그 영역을 넗히고 있고 이제 대부분의 데이터웨어하우스업체나 통계솔루션업체들은 당연하고 심지어 하드웨어 업체들도 하둡 플랫폼에 최적화된 하드웨어를 내놓으면서 홍보하기 바빠 보입니다.

물론 기 투자된 데이터 플랫폼을 유지하면서 이러한 하둡이나 NoSQL시스템과의 연동 및 인프라를 제공해준다면야 기업 입장에서는 더할 나위없이 좋다고 생각이 들겠지만 현실적으로는 상당히 이질적인 두개 이상의 데이터플랫폼이 연계되어 운영된다는 것은 현실적으로 쉬운일이 아닙니다. 레거시 시스템을 당장 버릴 수도 없고 빅데이터 플랫폼을 도입하자면 투자비와 운영비가 되려 크게 늘어날 수밖에 없습니다. 두배가 아니라 그 이상이 될 수도 있는 것입니다. 더불어 필요한 소프트엔지니어와 시스템 엔지니어는 이쪽 분야에는 턱없이 부족한 상황이구요.

사실 기존의 데이터 플랫폼 인력들((DBA, 데이터마이너, 시스템 엔지니어) 이 쉽사리 빅데이터 플랫폼 분야로 올려고도 하지 않습니다. 기존 시장이 충분히 크고 표준화되어 있는 기술기반위에서 엔지니어들은 안정적인 기술 경력를 쌓기가 현실적으로 유리하기 때문입니다. 빅데이터 분야, 하둡, NoSQL은 새로운 분야에 관심이 많은 엔지니어나 향후 소프트웨어 분야중에서 어디를 가야할지를 고민하는 초보 엔지니어들에게 더 관심이 많다고 볼 수 있습니다. 따라서 초기에는 빅데이터 기술을  투자하는 것에 대한 결정도 과제를 추진하는 것도 만만한 문제가 아닙니다. 그래서일까요, 2012년말 현재까지도 관심에 비해서 국내 여러 기업들의 빅데이터 플랫폼 도입이 지지부진한 것도 이러한 이유들도 어느정도 있지 않을까 생각이 듭니다. 잘 운영되고 있는 레거시 데이터 시스템을 두고 새로운 시스템, 플랫폼을 도입한다는 것은 정말 쉽지 않은 것이죠.

이렇듯 빅데이터에 대한 업계의 발빠른 대응과 온갖 마케팅 활동에 비해 실제 실적은 그다지 많지 않은 편이라고 생각됩니다. 모르겠습니다. 어쩌면 빅데이터 프로젝트가 아닌데 빅데이터 프로젝트로 포장되어서 도입이 되고 있을 수도 있을 것 같기도 하구요. 아무튼 업체들은 자신들의 솔루션을 이용해서 실질적인 성공사례를 찾기에 바쁘고 성공사례를 만들기에 바쁘기겠지만 이것 역시 시간이 걸리는 일이기에 2013년도가 되어도 미국의 여러 성공사례들처럼 한국에도 많은 성공사례들이 나오기는 쉽지 않을 것으로 보여집니다. 외국의 사례가 그대로 적용되기도 쉽지 않을테고 많은 POC(Proof of Concept) 과제가 수행되겠지만 몇몇 군데를 제외하고는 성공적인 사례를 찾아보기 힘들 것으로 예상됩니다. (너무 비관적인가요?) . 더불어서  빅데이터 플랫폼이나 과제들이 보통은 고객기반의 사용로그를 활용하는 경우가 많기 때문에 기업들이 드러내놓고 성공사례를 내세워 얘기하기도 쉽지 않은 것도 국내 빅데이터 시장의 기술적인 교류와 협력을 막는 요인중 하나가 아닐까 생각됩니다.

그리고 여러번 언급하긴 했지만 이제 빅데이터 플랫폼, 특히 하둡이나 NoSQL 기술을 도입해서 할 만한 곳들은 이미 내부적으로 시스템을 구축하고 그 조직적 역량과 플랫폼의 고도화에 힘쓰고 있습니다. 그런데 아이러니하게도 예산이 많지 않은 기업에서 기존 MySQL기반으로 처리하지 못했던 규모의 데이터를 5-10대의 소규모 하둡 클러스터를 기반으로 대용량 데이터 시스템을 구축해서 활용하는 사례들이 제법 있다는 것입니다. 이 얘기는 오라클 기반의 데이터 플랫폼을 이미 갖추고 있는 중견 기업들의 경우 오히려 X86기반의 범용서버을 이용한 하둡 클러스터를 도입하는데에는 어려움이 있지만 그조차 예산이 없어 MySQL와 X86/리눅스 기반의 시스템을 가지고 있던 기업들에게는 하둡이나 NoSQL이 매우 매력적인 데이터 플랫폼으로 활용될 수 있음을 얘기해주는 것은 아닐까 보여집니다. 결국은 ROI의 문제겠지요. 투자 대비 이득을 고려했을때 작은 규모의 클러스터는 상대적으로 적은 비용으로 구축, 운영이 가능하지만 어느 규모 이상의 하둡 클러스터, NoSQL등의 빅데이터 플랫폼 도입은 구축, 운영과 더불어 앞서 말한바와 같이 레거시 시스템과의 연동, 마이그레이션이라는 이중 부담을 가지게 되는 것이죠.

다시 말하면 포털회사, 통신회사, 인터넷 커머스 회사, 삼성전자, LG전자와 같은 디바이스와 플랫폼을 이용해서 글로벌서비스를 하고 있는 업체들은 당연히 이러한 빅데이터 플랫폼에 대한 니즈가 있고 이미 많은 역량과 인프라를 가지고 있고 무엇보다 충분한 투자 여력이 있는 반면 대부분의 기업에서는 오히려 이러한 빅데이터 플랫폼의 도입이 앞서 말한 이유로 쉽게 실행될 수 없는 것입니다. 반면 작은 소기업에서 데이터 분석 플랫폼에 대한 니즈가 있는 경우에는 대부분 리눅스기반의 오픈소스로 공개된 빅데이터 기술들을 잘만 활용하면 그 규모는 작겠지만 – 빅데이터라고 말할 수도 없겠지만 – 보다 실용적이고 최적화되어 사용할 수 있음을 의미합니다.

이렇다보니 아무래도 국내에서는 빅데이터 솔루션 업체들이 쉽게 돈을 벌기는 어려울 것 같습니다. 하지만 X86 하드웨어를 판매하고 있는 HP,IBM, Dell과 같은 업체들은 이 분야에서 꾸준히 매출을 올리지 않을까 생각됩니다. 최근엔 델이나 HP가 하둡과 같은 분산 스토리지와 컴퓨팅에 최적화된 하드웨어를 별도로 설계해서 내놓은 것을 보면 역시 돈 벌 수 있는  소프트웨어, 솔루션이 아니라 하드웨어뿐이라는 생각이다. 우리나라는 여전히 빅데이터 솔루션 업체를 SI를 맡기는 외주업체 이상으로 그 가치를 인정하고 대우해줄거라고 생각되지 않기 때문입니다. 솔직히 이 분야에서 꾸준히 투자를 하고 버티고 있는 국내의 토종 빅데이터 솔루션 업체라고 한다면 넥스알, 그루터, 클라우다인 정도가 다가 아닐까 싶습니다.

결국 국내의 빅데이터 시장이 성장하는데에는 한계가 너무나도 명확해보입니다. 클라우드 컴퓨팅이 그랬듯이 국내에서의 빅데이터 시장은 그렇게 낙관적이지 않을 것으로 보이는데도 사람들은 아직도 빅데이터에 대한 얘기를 하고,  advanced analytics, predictive analytics 등등 이런 얘기들을 하고 있죠.안드로이드, 아이폰과 같은 백엔드 플랫폼에서는 이러한 빅데이터 기술과 클라우드 컴퓨팅 기술을 바탕으로 사용자들에게 분명 다양한 가치와 경험을 제공해주고 있고 점점 더 고도화되고 있지만 정작 국내에서는 딱히 주목받는 서비스도 솔루션도 기업들도 보이지 않습니다.  어찌보면 구글, 페이스북, 애플, 트위트등과 같은 글로벌 인터넷 서비스들이 많은 이들에게 착시효과를 주고 있는 것은 아닐까 생각되기도 합니다.

쓰다보니 작년말에 처음 빅데이에 대한 글을 포스팅할 때와 크게 다르지 않게 매우 비관적으로 이쪽 시장에 대해서 전망을 하고 마네요. 그래도 앞으로 새로이 시작하는 데이터 플랫폼 프로젝트들에는 빅 데이터 기술들이 고려되고 하나씩 하나씩 녹아들어가겠죠. 다만, 시장이 원하는 만큼 크게  성장하지 않을 것이라는 겁니다. 리눅스로 돈 벌었다고 하는 사람을 주위에 본적이 없는 것처럼 말이죠.

결국  이러한 빅 데이터나 클라우드 컴퓨팅과 같은 소프트웨어 기술, 시스템 기술을 가진 엔지니어, 솔루션에 대한 가치와 그에 부합하는 대우를 하지 않는 상황에서는 이러한 기술적인 시류와 조류도 큰 임팩트를 국내 시장에 주는 것은 어렵지 않겠습니까?

그래도, 그래도 말이죠. 이 분야에서 공부를 하고 사업을 준비하고 과제를 준비하시는 분들께 새로운 기회와 돈 많이 벌 수 있는 2013년이 되길 기원해봅니다. 새해 복 많이 받으세요.

Happy New Year.

[광고] 플랫폼 전문가 그룹(PAG)과 로아컨설팅이 함께 하는..’플랫폼 세미나’

제가 참여하고 있는 플랫폼 전문가 그룹이 주관하는 “플랫폼 세미나” 가 12월 14일(금), 15일(토) 에 있습니다.  발표중심의 금요일 행사와 업계의 전문가들이 모여서 이야기를 풀어가는 토론형태의 행사로 나뉘어져 진행될 예정인데요.

아무래도 플랫폼이라는 것이 최근 많은 관심을 가지게 되었고 화두가 되고는 있습니다. 하지만 정작  플랫폼이 무엇인지에 대한 정의와 어떻게 이해를 해야 하는지 그리고 각 분야별로 이러한 플랫폼들이 어떤 역할을 하고 있는지 몇마디 말로 단정짓기 힘든 것이 또한 플랫폼이 아닐까 생각이 들기도 합니다. 대신 이러한 자리를 통해서 다양한 분야의 전문가들이 풀어가는 얘기들을 듣다보면 나름의 인사이트를 얻을 수도 있을 것이고 그 현실적인 한계와 앞으로의 기술적인, 비니지스적인 방향들에 대해서도 되집어볼 수 있는 기회도 되지 않을까 생각되네요.

플랫폼, 생태계 이러한 말이 담고 있는 말 자체에는 고정된 모습이 아니라 시장에 따라,  분야에 따라 끓임없이 대응하고 반응하고 진화해나가는 모습을 담고 있기에 책이나 인터넷으로 접하지 못한 보다 적나라하고 현실에 가까운 얘기들을 들을 수 있을 것 같습니다. 특히 토론 형태의 토요일 행사에는 참석하시는 분들도 함께 자유롭게 얘기를 풀어나가는 자리가 되면 어떨까 기대하고 있습니다.

자세한 내용이나 등록은 다음 링크를 쫒아가시면 됩니다.

http://www.onoffmix.com/event/10777

빅데이터에서 다루고 있는 문제들

7월에 포스팅한 컨퍼런스에서 발표한 자료 중에서 빅데이터에서 다루고 있는 문제들에는 어떠한 것들이 있는지를 정리한 장표가 있는데 오늘 오전에 우연히 에버노트 메모를 살펴보다가 발표할 스크립트를 작성 한게 있어서 포스팅을 합니다.

빅데이터에 대해서 관심을 가지고 계신 분들이 모두 전문가이거나 기술자들은 아니시기때문에 이렇게 쉽게 풀어놓은 글들이 이쪽 분야에 대해서 잘 모르시거나 정리가 필요하신 분들에게 작게나마 도움이 된다는 얘길 들어서 좀 지난 글이긴 하지만 포스팅 할려구요.

솔직히 저는 발표자료를 만들고 따로 스크립트 작성이라는 하지 않고 그때 그때 발표하는 분위기에 따라 애드립(무성의?) 으로 발표하는 편인데요. 이 발표 내용은 왜 이리도 자세히 스크립팅을 했는지 기억이 안나네요. ^^

***

최근 빅데이터에 대한 많은 컨퍼런스들도 열리고 있고 나름 괜찮은 문서들도 많이 나오고 있습니다. 그런데 빅데이터 프로젝트를 하게 된다면 어떠한 점들을 고려해야 할지 생각해보는 것은 어떨까 생각됩니다.

잘 아시겠지만 빅데이터에서 다루는 것은 당연히 데이터입니다.

그것도 “빅” 데이터를 다루는 것이죠. 그런데 이 “빅” 이라는 말이 묘하게도 원래의 뜻이 아닌 많은 의미를 담게 되어 버렸습니다. 마치 클라우드 컴퓨팅의 클라우드가 구름이 아니듯이 빅은 “대용량” 데이터만을 얘기하지 않고 다양한 형태의 데이터를 다룬다는 의미도 담고 있고 데이터가 유입되고 처리되는 방식에 대한 의미도 담게 되었습니다.

기존의 데이터들은 대부분 데이터베이스에 일단 데이터가 저장되고 관리된다는 일종의 암묵적인 약속이 있었습니다. 하지만 최근의 데이터를 보면 단순히 데이터베이스에만 있는 것이 아니라 웹의 억세스로그와 같은 텍스트 포맷에서부터, 각종 센서로 오는 바이너리형태의 이벤트 데이터, 음성데이터, 영상데이터등 매우 다양한 데이터들이 웹서비스가만연해지면서 다양해지고 있습니다. 빅데이터에서 다루는 데이터들은 바로 이러한 데이터를 포함한다는 의미에서의  “빅”이라고 생각하면 될 것 같습니다.

또한 데이터를 처리하는 방식이 배치 프로세싱을하는 것에서부터 실시간으로 유입되는 이벤트 데이터 , 좀더 나아가면 끍임없이 흘러드러오는 스트리밍 데이터를 다루는 것까지 요즘에는 빅데이터에서 말하는 데이터의 범주가 되는 것입니다. 아시겠지만 빅데이터분야에서는 이른 3V 라는 말을 붙이고 있고 여기에 Value 을 넣어서 4V 라는 말을 하기도 합니다.

하지만 여전히  빅데이터의 3V중  정말로 중요한 것은 대용량 데이터를 다룬다는 점을 잊어서는 안됩니다. 메가,기가가 아닙니다. 테라바이트, 페타바이트라는 데이터를 다루는 문제는 얘기가 달라집니다. 물리적인 이슈에 시달리게 됩니다. 수십개의 데이터소스로부터 입력되는 다양한 데이터포맷과 데이터 전송속도에 따라서 저장, 분석 이전에 수집, 연동이라는 현실에 부딪히게 됩니다.

두번째로 빅데이터를 하기 위해서 반드시 필요한 것이 바로 분산컴퓨팅에 대한 이해와 이를 지원하는 수십,수백대 또는 그 이상의 서버로 구성된 클러스터 컴퓨터에 대한 기술, 운영 역량입니다.

아시다시피 수십, 수백대 규모의 클러스터를 구성한다는 것은 기존의 시스템 관리 운영 방식에 있어서 매우 큰 차이점이 생기게 됩니다. 특히 클러스터를 구성하는 특정 노드의 장애와 네트워크 장애가 전체 컴퓨팅의 성능과 안정성을 좌우하기 때문에 상시 이에 대한 모니터링 체계와 이를 지원하는 관리시스템 도입이 반드시 필요합니다.

뿐만 아니라 이런 장비에서 실행하게 되는 어플리케이션의 배포와 관리 역시 매우 민감하게 되게 되는 것이죠. 자칫 작은 실수가 큰 재앙(?)을 일으킬 수도 있기 때문입니다. 더욱이 클러스터내의 하드웨어 관리 뿐 아니라 그 위에서 운영되는 소프트웨어 플랫폼이나 프레임워크에 대한 이해가 없게 되면 최적화하는데에도 문제가 있고 문제 발생시 해결하기가 매우 어렵고 많은 시간을 소비할 수 있게 됩니다.

제 개인적인 생각으로는 많은 분들이 빅데이터에 대한 얘기를 하지만 실질적으로 수십대, 수백대 규모의 클러스터환경을 접할 기회가 적기 때문에 이에 대한 운영이나 관리가 매우 힘들고 관련 인력을 확보하기도 힘들다고 생각됩니다.  “어쩌면” 이러한 측면에서 클라우드 컴퓨팅의 활용이 매우 중요해질 수도 있습니다. 물론 현실적으로 클라우드 기반에서 빅데이터 체계를 운영한다는 것은 여러가지 의사결정과 어려움이 있겠지만요.

세번째로  생각해볼 문제는 오픈소스에 대한 것입니다.

왜 빅데이터가 최근에 이렇게 각광을 받는가 한다면 아무래도 하둡을 빼놓을 수 없을텐데요. 하둡은 아시다시피 구글이 자신들의 컴퓨팅 인프라에 대한 내용을  논문으로 공개한 후  이를 바탕으로 야후의 엔지니어들이 공개소프트웨어로 개발을 시작한 것입니다. 물론 초기에는 야후에서 내부적으로 쓰다가 공개되면서 최근 3-4년 사이에 각광을 받게 된 것이죠.

아무튼 이외에도 사실 많은 빅데이터를 다루는 프레임워크들은 대부분 오픈소스들입니다. 이를 실행하는 운영체제는 당연히 리눅스이고 그 위에서 하둡, 카산드라,몽고디비, 등등 아파치 , GPL 라이선스를 가진 다양한 오픈소스들입니다. 문제는 이러한 오픈소스들이 모두  리눅스나 mysql, 톰캣, 아파치웹서버와 같이 안정적인 품질과 성능을 제공하고 있지 않다는 것입니다.

하둡만 해도 0.18, 0.19, 0.20, 0.21, 0.22, 0.23, 1.0, 2.0 이렇게 많은 소스코드 브렌치들이 있습니다. Cloudea, Hortonworks, MapR, IBM, Oracle 등 하둡 솔루션 업체들이 이러한 오픈소스들을 자신들의 제품과 결합해서 빅데이터솔루션으로 만들어서 제공을 하고들 있습니다.

다시 말씀드리지만 오픈소스를 도입해서 사용하기에는 어느정도 위험이 따릅니다. 특히 기업내의 핵심인프라로 바로 사용하기에는 내부에 인력도 별로 없고 기술지원을 하는 업체들도 별로 (거의) 없는 실정입니다. 빅데이터, 빅데이터라고들 말들은 많이 하지만 실제 하둡에 대한 기술 지원을 받을 수 있는 회사가 있을까요? 그렇다고 이러한 정보를 공유할만한 커뮤니티나 모임이 국내에 많지도 않습니다.

솔루션 업체들이 이러한 것을 하겠다고 나서지만 현시점에서 제가 봤을 때 기업내에서 빅데이터플랫폼이나 관련 오픈소스를 이용하는 인력들은 대부분 기업의 내부 개발인력들이 담당하고 있다고 생각합니다. 즉 실제 하둡이나 nosql 과 같은 분야의 전문가를 아직 많이 확보하지 못한 실정입니다.

그래도 우리가 알고 있는 구글, 야후, 페이스북, 트위터,링크드인과 같은 회사의 엔지니어들이 이러한 소프트웨어를 공개함으로써 기존 고가의 하드웨어와 소프트웨어로만 가능했던, 또는 불가능했던 규모의 데이터저장과 분석이 가능해진것입니다. 바로 scale-up 형태의 시스템 확장을 x86기반의 범용서버 장비를 이용해서 scale-out 형태의 시스템 확장이 가능하게 된 것도 이러한 오픈소소 덕분이고 리눅스가 그러했듯이 빅데이터의 여러 분야의 기술들을 지속적으로 발전시키는 원동력이 되고 있습니다.

네번째로 다룰 문제는 역시나 가장 골치 아픈 것중 하나인 기존의 레거시시스템과의 연동문제라고 생각됩니다.

제 경험을 비추어보건데 실제 연동문제는 단순한 기술적인 이슈가 아닙니다. 실제 각 연동할 시스템을 담당하는 부서와 해당 업무 그리고 담당자 모두가  엮어 있는 내부적인 협의가 매우 중요한 일이기도 합니다, 더욱이 시스템을 마이그레션 하는 경우는 기존의 시스템을 포기하고 빅데이터플랫폼으로 옮기는 것이 아니라 기존의 시스템들을 유지하면서 데이터 수집을 통한 분석 플랫폼 역할을 같이 하는 경우에는 더욱 힘들어 지겠죠.

이럴 경우 다양한 데이터 소스로부터 발생하는 여러가지데이터 포맷과 스키마를 수용해서 필요한 형태로 변환을 하는 작업이 반드시 필요하고 연동하는 주기라던가 하는 문제… 하지만 더욱 큰 문제는 기존 레거시시스템을 이용해서 잘 활용하고 있는 상황에서 어떻게 하면 빅데이터 기술이 필요하고 앞으로 이러한 부분을 꼭 추진해야 한다고 설득하는 부분이라고 생각됩니다.

“가장 간단한 대답은 잘 하고 있다면 빅데이터 플랫폼 쓰지 마라 “ 입니다. 자칫 더 많은 시간과 비용을 낭비 할 수도 있을수 있습니다.

최근 몇몇 빅데이터 컨퍼런스에 가면 강조하는 것이 있습니다. 바로 예측을 위한 데이터 분석이라는 부분입니다.

기존의 데이터 플랫폼이 주로 과거 데이터를 기반으로 통계, 마이닝을 통해서 현상을 이해하고 고객을 이해하고 이를 기반으로 전략과 기획을 수립하는 거였다면 앞으로 빅데이터에서 말하는 분석은 좀더 적극적으로 미래에 발생할 수 있는 장애나 사건을 예측할 수 있도록 해야 하고 이러한 점이 빅데이터의 한 비전이라고들 많이 얘기합니다.

결국 빅데이터의 궁극적인 목표는 대용량데이터를 쌓아서 단순히 분석하고 통계내고 리포팅을 하는 것이 아니라 고객들에게 추천목록을 제시하거나 검색 결과를 좀더 정확하게 예측해서 보여준다던가 기상예측을 좀더 정확하게 할 수 있는 쪽이라고 생각됩니다. 즉, 기존의 데이터 기반에서 찾아내었던 예측모델보다 좀더 정교하고 의미있는 것을 찾아내는 것이 그것이겠죠. 모두들 구글과 같은 분석, 예측 시스템을 가지고 싶기 때문이 아닐까요?

기존의 병렬프로세싱은 HPC(High PerformaceComputing) 이라고 해서 MPI 와 같은 프레임워크를 사용해 왔습니다. 주로 수치해석과 같은 빠른 계산에 집중했었고 빅데이터에서 말하는 “대용량 데이터” 중심의 분석방법하고는 접근 방법이 다소 틀립니다. 물론 엄밀히 말하면 겹치는 부분도 많지만요. 다시 말하면 고속의 계산성능에 집중했다면 하둡은 대용량의 데이터를 처리하는 것에 집중하는 형태라고나 할까요.

그런데 여기서 제가 말씀드리고 싶은 것은 기존의 데이터마이닝이나 머신러닝알고리즘들은 대부분 싱글머신 기반에서 동작하던 것들이라는 것입니다. 그래서 성능에 문제가 있으면 하드웨어의 사양을 높이는 방향으로 문제를 해결해왔습니다. 그러다보니 새로운 장비를 구매해서 새로 셋업하고 튜닝하고 그러다보면 가격도 점점 비싸지게 되었죠.  하지만 여전히 고사양의 싱글머신이 필요합니다. 가장 큰 이유는 분석알고리즘이나 통계알고리즘들은 여전히 병렬처리보다는 싱글머신의 싱글코어, 멀티코어에 최적화되어 있기 때문입니다.

이제는 Apache Mahout이라는 프로젝트를 통해서 하둡기반의(MapReduce) 다양한 머신러닝, 데이터마이닝 알고리즘들이 소개되고 있지만 이쪽 분야는 여전히 많은 연구개발이 필요한 분야라고 생각됩니다.

마지막으로 말씀드릴 내용은 결국 대용량 데이터를 저장하고 분석하다보면 기업에 있어서 데이터 유출에 따른 치명적인 위험이 따를 수 있습니다.

알다시피 이런 경우에는 데이터를 한곳에 집중해서 저장하기 보다는 분산하는 것이 더 안전하니까요.더불어 클라우드 컴퓨팅쪽에서 이슈가 되다시피 이러한 정보에 고객의 정보가 함께 따라오고 분석하는 여러 목적중에는 고객의 prefence을 파악해서 추천하는 룰데이터를 만들기도 하는 사실 익명이긴 하지만 고객 프로파일링을 할 수도 있는데 이러한 점들이 거꾸로 기업경영에 치명적인 영향을 줄 수가 있습니다.

사실 이것은 동전의 양면과 같은 사항이라서 매우 애매한 문제이기도 합니다. 제 자신도 데이터 분석하는 프로젝트를 하면서 양쪽 입장(고객 / 회사) 이 되어보니까 고객의 트랜잭션 로그가 많이 있으면 데이터 분석이 정말 좋을텐데 라고도 생각하는 한편 , 내 개인정보가 도대체 어디까지 흘러들어가는지 걱정스럽기도 한 거죠.

***

빅데이터 잡설 , 하둡은 어디로 갈꺼나 …

소소하게 읽은 책이나 잡설등을 올리던 제 블로그에 작년말 빅데이터에 대한 글을 처음 올리고 나서 어느새 일년이 지났습니다. 그 사이에 제 신상에 작은(?) 변화도 있었구요. 하반기가 되면 한풀 꺽일 거라고 했던 제 예측과 다르게 아직도 빅데이터에 대한 얘기가 멈추질 않고 있습니다. 11월에도 다양한 빅데이터 컨퍼런스가 열리고 국내에 빅데이터 포럼도 생겼구요. 빅데이터와 관련된 컨퍼런스에 가보면 여전히 많은 분들이 참석해서 얘길나누고 정보를 찾아 다니고 있는 것 처럼 보입니다.

오늘은 기술적인 얘기보다는 빅데이터와 관련해서 그간 제가 보고 들은 얘기들을 편하게 써볼까 합니다.

솔직히 고백하자면 빅데이터와 관련해서 이제 별로 할말이 없답니다. 제 블로그 포스팅된 날짜를 자세히 보시면 아시겠지만 8월 이후에는 그다지 포스팅을 안했다는 … 아니 못했습니다. ^^

각설하고,

다들 아시다시피 빅데이터를 얘기할 때 하둡을 빼놓을 수가 없습니다. 그러니 하둡 얘기를 다시 해보죠.

기존의 관계형데이터베이스나 데이터웨어하우스 시스템들이 합리적인 가격으로 빅데이터를 처리할 수 없을 때 하둡은 혜성처럼 나타났습니다. 혹자는 리눅스에 빗대어 빅데이터의 커널과도 같다고 하고 혹자는 서비스 프레임워트에 빗대어 빅데이터의 EJB와 같다고 말하는 사람들도 있습니다.

불과 1-2년전까지만 해도 하둡이라는 것이 무엇인지도 잘 알려지지 않았는데 이제는 빅데이터를 얘기할 때 하둡을 얘기하고 맵리듀스(MapReduce) 에 대해서들 얘기하고 있습니다. 많은 프로그래머들도 최근에는 이에 대해서 큰 관심을 가지고 새로운 분야에서의 새로운 경력을 쌓을 수는 없을까 기웃거리는 것 같기도 하구요.

오라클, IBM, HP, 마이크로소프트, 아마존과 같은 IT업계에서는 어느새 하둡을 자신들의 솔루션과 결합을 하거나 클라우드 컴퓨팅의 데이터 플랫폼으로 제공을 하고 있습니다. 국내에서도 클라우드 서비스를 제공하고 있는 SKT, KT 등이 자신들의 클라우드 환경에서 하둡을 사용할 수 있도록 서비스를 제공하거나 준비를 하고 있습니다.

기억하시는 분들도 계시겠지만 마치 지난 90년대말 리눅스의 열풍을 보는 것 같습니다. 수십여가지 리눅스 배포판들이 해외뿐 아니라 국내에서 만들어지고 결국 레드햇이나 우분투와 같은 투자를 받아 그 자본을 바탕으로 상용 리눅스 배포판을 만드는 솔루션 업체들이 등장하기도 하고 웹서비스를 운영하거나, 어플라이언스를 만들거나, 임베디드시스템을 개발하고자 하는 사업자라면 매우 적은 비용을 가지고 자신들만의 시스템, 솔루션등을 만들 수 있게 된 기폭제가 된 것입니다. 아! 국내에서는 와우 리눅스가 기억나네요. 지난 주에 집에 있는 CD을 다 버릴려고 정리를 하는데 정말 수십개의 리눅스설치 CD가 나오더군요.

이제는 너무나도 많이 사용하고 있는 스마트폰 시장의 절반이상이 바로 리눅스 기반의 안드로이드가 없었다면 존재할 수도 없었을 것입니다. 사실상 유닉스에서 리눅스로 이어지면서 현재 우리가 보고 만지고 사용하는 대부분의 시스템, 장비에 리눅스가 사용되지 않는 곳이 없다고 해도 과언이 아닙니다. 맞아요 집에 한대씩은 있는 인터넷 공유기도 바로 리눅스를 사용하고 있죠.

이와 마찬가지로 데이터를 처리하는데 있어서 오라클, MSSQL, DB2와 같은 상용 RDBMS 그리고 오픈소스인 MySQL, PostgreSQL과 더불어 하둡은 필수적인 데이터 플랫폼의 핵심 컴포넌트로 자리잡았다고 생각하시면 됩니다. 이미 다양한 상용 데이터웨어 하우스, 분석 시스템, OLAP 솔루션들은 비록 MapReduce를 사용하지 않더라도 빅데이터 저장소로 HDFS을 사용할 수 있도록 인터페이스를 제공하고 있습니다.

흥미로운 것은 최근 하둡의 발전되는 모습을 보면 철저히 기업이 요구하는 기능으로 채워지기 시작 했고 이미 MapReduce가 가지고 있는 약점을 보완하고 강화시킬 수 있는 방향으로 데이터 프로세싱 프레임워크가 진화하고 있습니다. 전통적인 MPI기반의 고가의 상용 MPP 머신에 비하여 아직 그 성능이나 효율은 상대적으로 좀 떨어진다고 하지만 대용량의 데이터를  저렴한 비용으로 저장할 수 있는 분산스토리지(HDFS)와 함께 상대적으로 개발 용이성이 MPI에 비해서 간단한 MapReduce라는 프로그래밍 모델 그리고 자바라는 언어의 특성을 한층 활용해서 매우 빠르게 그 저변을 확대해나가고 있는 것입니다.

제가 MPI 에 대해서는 잘은 모르지만 아시는 분 얘기를 들어보면 프로그래밍이나 디버깅이 상대적으로 쉽지 않다고들 합니다. 반면에 하둡의 MapReduce 프로그래밍 모델은 MLDM(Machine Learning and Data Mining) 알고리즘을 구현하는데는 약점이 많기는 하지만 상대적으로 개발도 쉽고 잘 구현되기만 하면 장비를 추가할 때마다 선형적인 성능 개선 효과가 있다는 것은 매우 매력적이라고 할 수 있습니다.

[그림: YARN Architecture]

그런 측면에서 아직은 실서비스에서 쓰기에는 부족함이 많지만 하둡 2.0에 해당하는 YARN은 주목할 만하다고 봅니다. 개인적인 생각은 2013년에는 YARN기반의 다양한 분산 컴퓨팅 모델 , 예를 들어MapReduce, MPP, Graphic Processing 등, 이 개발되어 지고 나면 하나하나씩 기존에 연구되고 활용되어 지던 MLDM (Machine Learning and Data Mining) 알고리즘들이 포팅될 것이고 현재 Mahout 정도에 머물고 있는 빅데이터 마이닝 도구들이 크게 늘어나게 될 것으로 예상됩니다.

자연스럽게 싱글머신기반의 알고리즘들이 멀티머쉰, 멀티코어에서 돌아가는 알고리즘들로 포팅되고 개발될 것이기 때문에 아마도 이를 통해서 다양한 산업 분야에서의 활용사례들이 폭발적으로 늘어날 것으로 예상됩니다. 이 시점이 되면 우리는 비로소 빅데이터가 약속하고 있는 가치를 체험하기 시작할 것입니다. 2014년 초가 되면 YARN 기반의 하둡 2.0의 활용이 늘어나면서 더욱더 하둡은 빅데이터의 핵심 컴포넌트로 자리를 잡아나가지 않겠습니까?

그렇게 된다면 현재 구글, 마이크로소프트, 페이스북 같은 회사들만이 할 수 있을 것 같은 대용량 데이터의 저장이나 처리 그리고 데이터 마이닝 기술을 누구나 활용해서 다양한 과학분야, 바이오인포매틱, 의료, 기후예측, 경제 분야에서부터 기업의 인사관리에 이르기까지 매우 다양한 분야에서의 활용이 손쉽게 일어나게 될 것이고 더불어 그 사용이 편리해지고 비용이 내려가고 있는 클라우드 컴퓨팅을 통해서 더욱더 견인되어질 것은 너무나도 분명합니다.

더불어 점점 빅데이터를 다루는 도구들은 많이들 나올 것이고 점점 더 편리해지겠죠. 어느새 하둡을 활용하는 개발자들은 자바로 직접 MapReduce 프로그래밍을 하기보다는 pig 와 hive 을 많이 사용하기 시작했습니다. 이미 많은 사람들이 구글, 아마존, 마이크로소포트의 클라우드 환경에서 데이터를 저장하고 분석하고 있습니다. 클라우드 상에서 웹서비스를 런치해서 글로벌하게 서비스를 하고 이를 통해서 쌓이는 데이터의 저장과 분석 역시 클라우드에서 하기 시작했습니다.

덧붙여 말씀드리고 싶은 것은 이제는 소프트웨어의 개발의 방식과 환경이 크게 바뀌고 있는 것입니다. 저와 같은 사람들은 10년 20년전 기술과 개발 환경이 머리속에 있다보니 이러한 새로운 세대의 개발자들과 환경을 이해하기 힘들게 되었습니다. 이러한 세대들이 다루고 사용하는 데이터의 성격과 도구들이 달라짐에 따라 소프트웨어의 개발 프로세스나 배포의 방식이 더불어 바뀌고 있는 것입니다.

당연한 얘기지만 네트워크 대역폭의 증가와 모바일 네트워크가 점점 더 확대되어가면서 우리는 이제 클라우드 컴퓨팅이 당연히 되는 시대에 살고 있습니다. 전세계의 사람들이 만들어내는 각종 데이터들은 디지털화되어 전세계 어딘지도 모를 데이터 센터에 저장되될 것이고 바로바로 실시간으로 프로세싱되고 분석되어 우리가 의식하든 의식하지 않든 끓임없이 다양한 디바이스를 통해서 여러가지 모습으로 피드백을 주고 우리는 그것에 반응을 하는 하나의 센서처럼 행동하게 되는 시대가 온 것입니다. 이 문장을 쓰다보니 약간 섬찟! 해지기도 하지만 아무튼 우리는 이러한 시대에 성큼 들어서고 말았습니다.

내년에는 또 무엇이 우리를 놀래켜줄까 사뭇 기대됩니다만 … 이러한 시대에 이러한 기술의 끝자락을 잡고 힘겹게 살아가는 저는 운이 좋은 걸까요? 아닐까요? ^^;;;