데이터 분석가가 바라본 빅데이터 현상과 대응을 위한 준비 방법
[출처] http://www.dbguide.net/knowledge.db?cmd=view&boardUid=166186&boardConfigUid=19&boardStep=&categoryUid=574
[저자]> 고태영 이노지에스 고문 tykoh70@innogs.com
빅데이터 활용이 현실로 다가오면서 구축 플랫폼에서 분석 환경까지 다양한 이슈가 쏟아져 나오고 있다. 오랫동안 데이터 분석 업무를 해온 현업 전문가의 시선으로 빅데이터 현상을 알아보고, 기업에서 현실적으로 적용할 만한 분석 환경과 단계별 준비 방법을 소개한다.
빅데이터와 데이터 분석을 소개하는 기술 설명서에 준하는 글은 이미 사방에 넘쳐나고, 매일 빅데이터 관련 기사가 미디어의 IT 섹션을 장식하고 있다. 기술을 주도하는 빅플레이어들은 시장 주도권을 거머쥐기 위해 엄청난 광고?홍보 비용을 쏟아 부으며 경합하고 있다. 빈번하게 빅데이터 혹은 이와 관련한 컨퍼런스가 열리고, 기존의 데이터베이스를 주 업종으로 하던 회사들?분석 서비스를 주로 해오던 컨설팅 회사들?혹은 장비 회사들?이제는 유관성이 없어 보이는 업체들까지 빅데이터를 표방하고 나선 모습이다. 대학입시에서도 이러한 열풍은 여실히 드러난다. 통계학과 등 응용수학 분야와 인접 학과들의 입시 경쟁률이 치솟았다는 기사가 더 이상 놀랍지도 않은 일이 돼버렸다.
빅 데이터 분석(Big Data Analysis)
숲에서 나무들의 무작위 표본을 채집해 그 평균값을 근거로 침엽수림인지 활엽수림인지 구분하고 숲의 생성연대를 가늠하기도 한다. 무작위 표본 채집이 생태학자의 연구조사를 위한 통계학적 접근 방법으로서는 그리 나쁘지 않을지 모른다. 그러나 그것만으로는 숲을 이루는 모든 정보를 파악할 수는 없다. 탐사자에게는 무용한 분포도상의 이상치가 식물학자에게는 아주 중요한 식물 군집정보가 될 수도 있다. 만일 독자가 군대생활 중에 얻은 경험 등 서바이벌 지식을 갖춘 상태에서 깊은 숲에서 조난을 당했다고 가정해보자. 가장 먼저 무엇을 할 것인가? 우선 방위 파악과 숲의 전체적인 형태를 파악하려 할 것이다. 나무 가지가 뻗어나간 방향과 그루터기에 낀 이끼, 태양의 이동 방향, 밤이라면 별의 위치로 방위를 가늠할 것이다. 그러나 숲을 벗어나려면 일단 능선의 형태와 협곡의 위치, 해의 길이, 그림자의 범위, 식수?식량 확보 등 여러 상황 정보를 수집?파악해 대책을 세울 것이다. 목적은 하나다. 조난당한 그 숲으로부터 벗어나는 것이다. 생존에 필요한 각종 정보를 근거로 최대한 명확히 판단할 수밖에 없다. 만약 혼자서 조난당했다면 여러 명이 함께 있을 때보다 불리해질 것이다. 혼자서 얻을 수 있는 정보는 양에서 제한적일 뿐 아니라, 분석?판단 과정에서 자칫 냉철함을 벗어날 수 있기 때문이다.
그러나 여럿이 함께 있다면, 경험 많은 사람이 리더가 돼 팀을 통솔하면서 같은 시간에 여러 일을 처리하려 할 것이다. 팀워크가 발휘되는 순간이다. 서로 흩어져 정보를 찾고 준비 작업을 하는 동안 위기 상황에서 상호 소통하는 방법도 결정할 것이다. 리더는 수집된 정보를 바탕으로 그때그때 결정을 내려야 한다. 이때 팀원들은 리더가 내린 결정이 그 상황을 벗어나기 위한 올바른 판단이었는지를 생각할 것이다. 따라서 혼자일 경우보다 잘못된 판단을 내릴 가능성은 그만큼 줄어들게 된다.
표본 조사에서 전체 조사로
기업에서 데이터 분석도 이처럼 펼쳐진다. 특히 빅데이터 분석은 기술이나 방법의 문제라고 보기에는 기존의 데이터 분석과는 다른 점이 많다. 예전의 분석에서는 표본 데이터를 이용해 분산 분석을 해 필요한 최적화한 결과만 취해왔다. 그러나 이러한 방법은 필요한 정보의 분석 결과만을 취할 뿐 어쩌면 유용할지도 모를 버려지는 이상치 값들을 방치하는 결과를 불러왔다. 또한 표본으로 분석한다는 것은 모델을 아무리 정교하게 만든다 할지라도 전체 데이터를 대상으로 분석한 결과치와 같을 수 없다. 전체 데이터를 대상으로 분석한다는 것은 고려해야 할 이슈가 많음을 의미한다.
기업에서 빅데이터 분석을 위해 고려해야 할 이슈 중에서도 절대적으로 분명히 할 것이 있다. 바로 ‘정책’이다. 정책에는 여러 요소가 필요하지만 필자는 다른 측면에서 정책을 거론한다. 빅데이터를 위한 플랫폼이나 솔루션의 문제는 그리 중요하지 않다. 정책이 결정되지 않는 상태에서 빅데이터 분석은 무의미한 도전이 될 가능성이 높다. 정책은 빅데이터를 분석하려는 조직에서 과연 무엇을 빅데이터라 할지를 정하는 데서부터 시작된다.
‘기존 데이터 웨어하우스(Data Warehouse)에 무수히 많은 정형 데이터와 비정형 데이터가 쌓여 있으니 그것들을 헤집어 뭔가의 패턴을 찾아내고 그 안에서 인사이트를 찾겠다’고 한다면 ‘그건 아니다’ 라고도 할 수 있다. 실례로 제조기업이라면 제조라인에서 발생하는 무수히 많은 데이터를 통해 생산 비용관리, 장애요인 분석관리, 생산량 조정관리 등의 분석 정보를 도출하려 할 것이다. 그러나 정작 사용돼야 할 데이터는 거의 쓸 수 없는 포맷으로 단지 스토리지에 적재된 경우가 대부분이기 때문이다. 이러한 데이터에 대한 분석 요구를 받아 분석하려 했을 때 가장 먼저 부딪치는 문제는 기존 시스템에 대한 접근 경로를 거의 확보할 수 없다는 것이다. VPN(Virtual Private Network)을 열어주는 것부터 시작해 원본 데이터로의 접근을 위한 여러 가지 사내 보안정책 등 말로 할 수 없을 만큼의 장애물이 놓여 있다. 직접 상주해 작업하기 위해 별도의 액티브 디렉터리(Active Directory)를 구성하고 이거저거 하다 보면, 이제는 도저히 가져와 사용할 수 없는 형식으로 쌓여 있는 로그 데이터가 발목을 잡는다. 이러저러한 이유로 포기할 것들은 포기하고 완료한 프로젝트를 고객에게 전달하는 과정에서도 문제에 직면한다. 새로운 방식에 대해 배우기를 귀찮아하고 사용하기를 꺼려하는 사용자들 습성 때문이다. 어렵게 구축된 시스템은 6개월을 넘기지 못하고 방치된다. 제조뿐만 아니라 물류 등 연관 비즈니스 그룹들이 이와 같은 방식으로 저마다의 방식으로 데이터를 쌓고 분석?활용하기 위한 각자의 시스템을 구축?보유하고 있다.
세밀도에 대하여
각 비즈니스 그룹 단위로 다르게 접근하는 각각의 데이터 웨어하우스로부터 데이터를 취합?분석?최적화해서 기업이 원하는 총체적인 전략을 수립하고 시행하게 만들 수 있을까 하는 의문이 든다.
일단 이러한 데이터 취합 문제와 분석에 대한 문제가 해결됐다고 보고 다음 문제를 짚어 보자. 데이터 분석에 대한 ‘방법론’을 결정해야 한다. 현재로선 관심이 주로 빅데이터 분석 플랫폼과 솔루션에 집중된 나머지 잘 드러나지 않고 있을 뿐이지, 이러한 분석 방법론이 정착되면 반드시 발생할 중요한 이슈이다. 분석 방법론에서 거론될 이슈는 빅데이터를 얼마나 세밀하게 분석할 것인가이다. 일반적으로 아주 깊고 정밀하게 분석하려고 한다. 그러나 빅데이터의 분석은 조금 다르게 접근해야 할 수밖에 없다. 빅데이터 분석은 직관과 통찰의 문제이기 때문이다. 앞서 숲을 예로 들었듯이 너무 가까운 현상에만 집중하다 보면 정작 전체를 보지 못하는 패착(敗着)을 두게 마련이다.
인식의 한계치를 넘어선 데이터
빅데이터 분석의 요체는 거대함 속에서 드러나는 하나의 흐름을 파악하는, 즉 직관으로 패턴을 먼저 읽어내는 것이다. 그 패턴이 어떠한 모습을 하고 있으며 무엇을 의미하는지, 우리에게 무엇을 말하려는지를 법의학자가 프로파일링하는 것처럼 대상을 통해 인식하고 받아들이고 말 할 수 있어야 한다. 예전의 데이터 분석의 대상이 미시적 대상이거나 가시적 대상의 범주였다면, 빅데이터는 가시적일 수는 있으나 인식의 한계치를 넘어선 데이터의 범주를 말하는 것이다. 데이터가 크기를 떠나 너무 다양한 형태로 존재하기 때문이기도 하거니와 그 데이터가 쌓여가는 속도가 인간의 보편적 인지??를 분석하기 위해서는 이러한 데이터를 접하는 방법 및 관점에 대한 자세부터 바꿔야 할 필요가 있다. 다양한 빅데이터 플랫폼과 분석방법, 기반 기술들은 무로부터 시작한 것이 아니다. 이론적으로는 수십 년 전부터 존재했으나 최근에 와서야 정보통신 기술의 발달로 구현된 것들이나 기존에 구현됐던 것들이 새로운 개념으로 재정립된 경우가 대부분이다. 클라우드, 가상화, 분산 병렬처리, 맵리듀스 등 현재 이슈화되는 빅데이터를 위한 기술이 그렇다. 이러한 기술을 바탕으로 빅데이터를 분석하기 위한 새로운 인식에 대해 알아보자. 과연 어느 정도까지 ‘느슨하게’ 데이터를 분석해야 할까?
느슨한 분석
‘느슨하게’는 기존의 분석 방법과는 반대의 개념에 가깝다. 인지적 관점으로 해석하자면 전체를 조망하고 개체 단위로만 집중하지 않을 때 하나의 거대한 상으로부터 하나의 패턴을 인식할 수 있다고 한다. 이는 우주항공 분야에서도 위성으로부터 송신되는 지표 데이터 사진을 통해 특이점을 파악할 때 적용되는 방식과 유사하다고 볼 수 있다. 또한 유적지 전체를 조망하고 그 문명의 일관성을 파악하거나 퍼즐같은 복잡하고 유사성이 없는 조각 맞추기 놀이에서도 찾을 수 있는 방법이다. 너무 세밀하게 팩트에 집중하면 중요한 현상을 놓칠 수 있다. 때에 따라 세밀한 집중화가 필요하지만 기본적으로는 ‘느슨한’ 분석이 필요하다.
기업에서 빅데이터 분석을 위해 우선 해야 할 일이 ‘정책 결정’이라면, 이 정책을 토대로 할 일이 ‘느슨한’ 정도를 결정하는 것이다. 두 번째는 어쩌면 가장 중요할 수 있는 이슈이다. 바로 기존의 데이터를 사용할 것인지 아니면 새로 수집할 것인지의 문제다. 기존 데이터 웨어하우스로부터 분석할 데이터를 마이닝?가공?적재하는 방법을 택할 것인지, 이 방법과 병행해 새로운 빅데이터를 위한 새로운 데이터 웨어하우스 운용 시스템을 구축할 것인지를 결정해야 한다. 기존 시스템으로부터 새로운 시스템으로 마이그레이션하는 것은 쉬운 일이 아니다. 특히 기업 규모가 클수록 이것은 중요한 정책적 결정이 요구된다. 최근 빅데이터 분석과 관련해 이 문제에 대한 이슈가 활발히 논의되고 있다. 그 대표적인 것이 하둡(Hadoop) 플랫폼이다. 국내에서도 이 플랫폼을 이용해 기업에 적용한 사례가 있다. SK플래닛이 대표적이라고 할 수 있다. 이 프로젝트는 대략 3여 년의 시스템 마이그레이션 과정이 있었다고 알려졌다. 이 글의 주제를 벗어나기 때문에 하둡 플랫폼의 효용성은 논외로 하자. 대신 이 글의 후반에 하둡이 아닌 다른 솔루션으로 이와 같은 데이터 분석 환경을 구성하는 방법을 개략적으로 소개할 것이다.
빅데이터 분석은 인지 한계를 넘어선 거대하고 다양성을 가진
실시간에 적재되는 데이터를 멀리서 넓게 바라보고
미시적 팩트가 아닌 거시적 패턴을 보고
느슨하게 분석해 원하는 가치를 찾는 것이다.
앞서 소개한 빅데이터 분석을 정리하면 다음과 같다. 인지 한계를 넘어선 거대하고 다양성을 가진 실시간에 적재되는 데이터들을 멀리서 넓게 바라보고 미시적 팩트가 아닌 거시적 패턴을 보고 느슨하게 분석해 원하는 가치를 찾는 것이다.
‘빅데이터가 무엇이냐?’고 질문하면, 상대가 ‘바로 그거구나!’ 하고 이해할 수 있을 만큼의 분명한 답을 주기는 곤란하다. 10여 년이 넘게 분석 업무를 해온 필자도 빅데이터가 무엇인지 잘 모른다. 잘 모르는 사람이 이런 글을 쓰고 있는 아이러니가 현재의 IT 현실과 닮았다고 생각된다. 아래에 기술하는 내용은 빅데이터 관점이라기 보다는 큰 데이터를 분석하는 입장에 관한 개인적인 연구수행의 관점을 기술한 것이다.
분석가가 바라본 빅데이터
빅데이터는 과연 엄청나게 크거나 혹은 엄청나게 많이 쌓여 있는 데이터 더미를 말하는 것일까? 답을 찾다가 결국 필자도 혼란스러워서 그냥 현업 데이터 분석 담당자 입장에서 현재 상황을 정리하는 것으로 대신한다. 우선 무수히 많은 데이터가 쌓일 조건은 다음과 같다. 무수히 많은 업무 트랜잭션과 이를 수용하는 대용량 데이터베이스 처리가 가능한 데이터 웨어하우스(Data Warehouse)가 필요하다. 하지만 기존 방식을 벗어난 유연한 확장(Scalable)성을 보장해야 한다. 하둡 플랫폼이 이에 가장 부합한다고 볼 수 있을 것이다.
일단 이 조건에 부합하려면 무수히 많은 업무 트랜잭션이 발생하는 중견기업 이상의 대기업 정도는 돼야 가능할 것이다. 물류 관련 비즈니스 그룹을 하나의 유닛으로 보고 가늠하자면, 최소한 이와 관련한 인접 비즈니스 유닛들이 다 모여서 유기적으로 데이터를 주고받으면서 최소한 수년 간 적재해야 한다.
물론 여기에는 소비자라는 엄청난 크기의 가변변수도 고려해야 한다. 제조 분야에서는 이보다 더 많은 데이터가 발생한다. 빅데이터라는 트렌드에 가장 부합한 영역은 SNS 같은 소셜 플랫폼도 아니고 바로 제조업 분야다. 현재 필자가 소속된 회사는 파트너들과 협력해 데이터 분석 모델을 만들어 우선 적용할 영역이 제조업이다. 그 이유는 다음과 같다. 데이터 분석이 가장 필요하고 대용량 데이터 분석을 위한 기반 환경이 구축된 분야가 제조업과 방송, 통신, 금융관련 분야다. 공공정보나 IT 플랫폼 기반 분야도 이에 해당한다.
분석을 위한 플랫폼
빅데이터 분석 요건을 살펴봤으므로 빅데이터가 되기 위한 기술적 충족 요건이 무엇인지 살펴보자. 일단 대용량 분석을 가능케 하는 멀티코어 지원 애플리케이션이 있어야 한다. BI(Business Intelligence)같은 OLAP 솔루션들은 프론트엔드에서 작동하기 때문에 웬만한 환경에서는 엔진 성능만 좋다면 싱글 코어만을 지원해도 크게 무리는 없다. 필자는 기업용 분석 최적화 BI 솔루션으로 HiQube(www.hiqube.co.kr)를 주로 쓰고 있다. 이 솔루션은 싱글코어 기준으로도 2억 7000만 개의 레코드, 16개의 칼럼, 30억 개의 데이터 값, 8.5GB 용량의 대용량 데이터셋을 1초 미만으로 내비게이션할 수 있다. HiQube는 글로벌 근사기법을 사용하는 ARSM(Adaptive Response Surface Method), 글로벌 근사기법을 사용한 그래디언트 기반의 다중목적 최적화(GMMO), 검증기법을 사용한 GA(Genetic Algorithms), 다중목적 유전 알고리즘 (MOGA, Muti-Objective Genetic Altorithm), 실현 가능한 방향설정 방법(MFD)와 순차적 프로그래밍(SQP)과 같은 지역 근사화 기법, 순차적 최적화(Sequential Optimization)과 신뢰성 평가(SORA)와 몬테카를로 시뮬레이션과 같은 신뢰성과 활성화를 최적화를 가능케 해주는 활성화 신뢰성 알고리즘 등 공학기반의 수학적 최적화(Optimization) 알고리즘들을 BI레벨에서 지원하는 유일한 솔루션이다. 이는 다른 BI솔루션들이 가지지 못하는 빅데이터를 지향하는 프론트엔드 전문분석 솔루션을 지향하기 때문이다. 오랜 시간 최적화에 관련한 알테어의 공학적 DNA가 녹아있는 제품인 것이다.
[그림 1] HiQube 화면 (출처: 알테어 코리아)
범용으로는 칼럼 기반의 인메모리 데이터 엔진을 채용함으로써 그 미래가 밝아 보이는 마이크로소프트의 오피스2012와 세어포인트 서비스, SQL서버 2012의 분석 환경이 있다. 아직은 HiQube같은 제품에 비해 부족함이 많으나 기반 환경을 오피스 제품군으로 사용하는 기업고객의 환경을 고려할 때 아무래도 친화성에 있어서는 가장 큰 장점을 가지고 있다고 하겠다. 기회가 된다면 이들을 이용한 실무 레벨의 분석에 대한 소개를 하고 싶다.
R나 MatLab, SAS같은 수학적 분석 솔루션도 필요하다. 혹은 여기에 더해 최적화 지원을 하?어를 지원하는 것은 기본이다. 우선 클러스터 분석을 지원하는 것을 기본으로 판단하자면, SAS는 아직 준비 중이 것으로 보인다. R는 기본적으로 분산분석을 멀티코어 레벨에서 지원한다. MatLab 또한 지원한다. 이 외에 좀더 산업공학적인 측면에서 최적화(Optimization)를 지원하는 역학 해석 및 분석용 솔루션인 Hyper Works 제품군 중에 Hyper Math (www.hyperworks.co.kr/Product,50,HyperMath.aspx)가 있다.
기계학습 또한 매우 중요한 요소다. 필자가 생각하는 빅데이터 분석의 기본 요소에서 가장 정점은 바로 이 기계학습을 어떻게 분석로직에 적용하고 활용하게 하는가이다. 필자의 경우는 주로 함수형 언어들을 이용하거나 MatLab을 이용하지만, 아마도 향후에 하둡이 보편화되고 R가 주로 사용되는 시점에서는 Octave(http://www.gnu.org/software/octave)가 주목할 만한 솔루션으로 떠오를 것이라고 본다.
[그림 2] GNU Octave 화면 (출처: www.gnu.org/software/octave/)
앞서 소개한 애플리케이션 혹은 툴처럼 빅데이터 분석에 적합하거나 혹은 적용이 가능한 체질을 갖춰야 활용이 쉬울 것이라고 생각한다. 더불어 운용 플랫폼이 빅데이터를 발생시킬 수 있는 환경을 제공해야 한다. 필자 관점에서라면 HPC(High Performance Computing) 혹은 HAC(High Availability Computing)가 우선 필요하다. 현 시점의 키워드인 클라우드 컴퓨팅(Cloud Computing), 분산병렬처리 시스템(Parallel distributied system), 가상화 시스템(Virtualization System) 들은 모두 클러스터라는 저장 프로세스를 처리하는 논리적인 유닛의 집합체를 개념으로 한 HPC나 HAC를 바탕으로 한다.
아마도 이 대목에서 ‘왜 하둡을 거론하지 않는가?’ 하고 궁금해할지도 모르겠다. 우선 필자는 하둡을 잘 모른다. 그저 하둡이라는 게 있고, 그게 어떻게 운영되는가를 가상 운영환경에서 설치해보고 간단한 스크립트 레벨에서 테스트해 본 것이 전부다. 이런 이유 때문에 하둡을 거론하지 않는 것과 더불어 필자 주변에는 기업의 운영환경 전체를 하둡으로 마이그레이션했던 아주 용감한 이도 있기에 여기서는 필자 나름의 정보 분석에 대해서만 소개한다.
상용 분석 플랫폼
필자는 하둡 시스템이 아닌 다른 방식으로 정보분석이라는 업무의 일을 하고 있다. 필자가 다루는 솔루션은 알테어 코리아(www.altair.co.kr)에서 공급하는 PBS Works(www.pbsworks.co.kr) 이다. HPC를 위한 ‘Enabling on demand computing’를 표방하는 솔루션이다. 이 솔루션은 현재 미국에서는 펜타곤(Pentagon)에서 운영하는 슈퍼컴퓨터와 워크스테이션들의 연구 및 고용량 연산을 수행하기 위한 HPC와 그리드 컴퓨팅(Grid computing) 환경을 지원하기 위해 사용되고 있다. 약 300만 코어(Core)를 컨트롤 하고 있다. 국내에서는 기상청 슈퍼컴퓨터에서 약 10만 코어를 사용하고 있는 것으로 알려졌다. 또한 하이퍼 웍스(Hyper Works)를 지원하기 위한 고연산 분석 솔루션을 위한 스피어 서버 펌(Sphere Server Firm)으로 사용되고 있다. 국내 자동차회사와 중공업사 등 산업현장과 연구기관에서도 다양한 목적으로 사용되고 있다. 필자는 이 솔루션을 기반으로 빅데이터를 분석한다. 물론 이것만으로는 불가능하다. 하둡에도 Hive, Pig, Scribe, Chukwa, Flume 같은 툴들이 있듯이 PBS Works도 분산 컴퓨팅을 위한 툴이 필요하다.
우선 PBS Works에서는 ‘PBS 프로페셔널’이라는 전용 관리 환경과 관리자용 분석환경인 PBS 애널리틱스, 프로트엔드를 위한 PBS 컴퓨트, PBS 데스크톱 등을 지원하고, 내부 운용 스크립트로 파이선과 펄을 지원한다. 이로써 대용량 데이터 분석용 솔루션의 구성도가 그려졌다.
PBS Works는 Parallel Python(www.parallelpython.com) 등 파이선 프레임워크를 기본적으로 지원한다. 이에 따라 필자는 필요할 때마다 IPython(ipython.org)이나 RPy2를 사용한다. Parallel R나 RPy2는 분산분석을 위한 분석 도구이다. R가 갖는 분석 가용치 한계를 벗어나기 위한 방법이지만 나름 사용할 만하다. 기본적으로 SAS같은 솔루션도 처리가용 한계치가 20Gb를 넘지 못한다. R는 이보다 더 취약하다. 그러나 Parallel R를 이용하면 이러한 한계를 극복할 수 있다. 이러한 구성은 빅데이터 분석을 위한 연구 차원의 대안으로서 사용될 뿐이고 전적으로 빅데이터 분석을 위한 대안이 될 수 없음은 미리 밝혀둔다. 아직 오라클이나 마이크로소프트 같은 곳에서 차세대 하둡 통합 환경의 프로토타입으로 검토중인 상태이기 때문에 완전히 빅데이터 플랫폼 실무에 적용할 수 있는 단계는 아니다.
앞의 방법은 PBS Works 같은 상용 솔루션을 사용하지 않고도 빅데이터 분석을 할 수 있는 방법이지만, HPC 운용에 있어서 가장 중요한 퍼포먼스 문제가 남아 있다. 네트워크 스위칭 인터페이스의 처리용량 문제와 디스크 쓰기 문제들로 인해 소규모 연구소에서나 가능한 방법이다. 만일 대용량 고연산 작업을 수행해야 한다면, 내부 스위칭 인터페이스가 40Gb 인피니밴드급을 지원해야 한다. 결국 이러한 HPC 환경을 효율적으로 구성하기 위해서는 각 노드 클라이언트에 해당하는 물리적 워크스테이션들은 PC 사양이어도 상관 없지만, 컴퓨팅 서버와 스위칭 인터페이스는 고가의 장비가 필요하다. 따라서 필자도 개인적인 분석 모델 수립을 연구할 때에는 IPython 라이브러리를 이용한 소규모 분석 플랫폼을 이용하지만, 기업용 대용량 데이터 분석을 할 때에는 PBS Works로 구성된 HPC 기반의 분석 환경을 이용한다. RPy2는 파이선에서 R의 분석 처리용 함수들을 불러다가 사용할 수 있게 구성해 준다. 즉, R에서 사용하는 분산 분석모듈(Cluster analysis module)을 이용해 분석을 처리할 때 발생하는 데이터를, PBS 스피어 서버로 보내 분산 처리하거나 계산 작업에 할당한다.
만일 하둡을 이용한 시스템을 고려한다면 분석운용 환경으로 RHive 사용을 권한다. 필자가 알기로는 하둡에서 이보다 더 효율적인 분석 방법은 없다. 오라클의 빅데이터 제품군이나 마이크로소프트가 진행중인 윈두우 애저(Windows Azure)와 하둡을 결합한 아이소토프(Isotope) 플랫폼이 공식 출시되면 알 수 있지 않을까. 이에 대해서는 기회가 닿는다면 자세히 다뤄보고 싶다.
[그림 3] Splunk 분석 솔루션 (자료 협조: 동양시스템하우스)
더불어 앞서 소개한 처리방식으로 실시간 프로세스 분석을 위한 환경에서 보다 안정성 있는 솔루션을 원한다면 이와 같은 방식을 지향하는 상용 솔루션이 하나 더 있다. Splunk사의 ‘Splunk’라는 솔루션이다. 일반적인 CEP(Complexed Event Processing) 기반과는 다소 다르지만 그 효용 면에서는 나름 제값을 분명히 하는 솔루션이다. 국내 IT 기업들이 이미 도입해 사용 중인 솔루션이기도 하다. 이 솔루션 또한 내부적으로 파이선을 기본 운영 스크립트로 지원한다. 그리고 자체 검색엔진도 지원하는데 구글 엔진과 비슷하다. 가격이 만만치 않은 제품이라는 점을 제외한다면 기업에서 가장 잘 활용할 만한 솔루션으로 보인다. 분석 도구와 함께 하나 더 고려할 사항이 데이터베이스로, 필자는 CouchDB, MongoDB 등을 사용 중이다. 이에 대해서는 김우승 줌닷컴 연구소장의 연재 등 전문가들의 글을 참고 하기 바란다.
현실적인 빅데이터 분석을 위한 제언
빅데이터 분석은 중요하다. 그리고 하둡 시스템은 상당히 매력적이다. 그러나 이러한 매력적인 목적지에 도달하기 위해서는 수많은 어려움을 뛰어 넘어야 한다. 이제 이러한 어려움을 극복하고 초기 시행착오를 줄일 방안을 현실적으로 알아보자. 하둡 같은 시스템 환경이라고 해서 딱히 다를 건 없다고 본다. IT 분야에서 오랫동안 종사한 독자라면 잘 이해하겠지만 문제점은 늘 비슷하다. 다만, 그 규모가 얼마나 더 방대해지고 얼마나 복잡해졌느냐의 차이일 뿐, 기본 구현 원리나 개념은 늘 같기 때문이다.
우선 빅데이터 분석을 위한 기반 환경에 대해 알아보자.
1. 시스템 통합
하둡 시스템이나 유사한 형태로 이전하기 위해서는 사전에 기존 시스템들을 통폐합해야 한다. 하둡으로 마이그레이션은 엄청난 비용과 시간, 인내심을 요구할 것이다. 대략 대기업 기준으로 1년의 준비 기간이 필요할 것으로 예상한다.
2. 자동화 구현
통합된 시스템이 자동 처리될 수 있도록 구현하는 데 집중해야 한다. 아무리 잘 통합된 시스템이라 하더라도 장애 처리를 위한 자동화 처리 공정이 구현되지 않으면, 인력과 시스템 낭비가 그만큼 심해질 것이다. 하둡으로 시스템 이관 시 자동화 부분이 해결되지 않으면 기존 시스템을 사용하는 것과 차이 없거나 오히려 성능이 더 떨어지는 최악의 상황에 봉착할 수 있다. 이것은 시스템 자동화뿐 아니라, 이 일과 관련된 인력에 대한 교육도 포함된다. 대략 이러한 일을 수행하는 데 걸리는 시간은 구현 1~2년, 교육 및 숙달을 병행해 2년 정도 소요될 것으로 예상한다.
4. 하둡 시스템으로 마이그레이션
매우 어려운 단계다. 앞서 하둡으로 마이그레이션하기 위한 통합화와 자동화 교육에 2~3년이 필요하다고 했다. 이제 남은 것은 기업의 중대한 결단뿐이다. 앞서 소개한 지침을 바탕으로 내부 정책을 수립하고 대안 모델로 기업의 체질을 개선해왔다면, 분명이 이 부분에서 고민은 줄어들 것이다. 왜 하둡이나 이와 유사한 시스템 환경으로 이관해야 하는지 충분히 공감하고 있을 테니 말이다. 필자의 관점상, 딱히 이러한 이관 경험이 없어도 이러한 시스템이 주게 될 만족감은 충분히 예측된다. 그러니 여기 저기서 하둡에 대해 거론하면서 하둡이 전부인 것 같은 분위기가 형성되고 있다. 중요한 것은 이러한 시스템으로의 이관이 가져다 줄 이점을 최대로 활용하기 위해서는 반드시 앞서 소개한 과정을 착실히 수행하고 전사적인 전략과 정책에 대한 장고의 과정이 필요하다. ‘정책’이 관건이다. 하둡과 같은 시스템으로 마이그레이션하기 위해서는 ‘정책’을 수립하고 단계적으로 진행하되 반드시 중간 과정에 대체 수단을 통해 체질(?)을 개선한 다음에 이관해야 한다.
5. 팩트가 아닌 패턴
끝으로 하나 더 부연하자면 통계학적 분석이 빅데이터 분석에도 필요하다. 하지만 그 적용 방식은 분명히 다르다. 만일 기존 통계학적 분석에 익숙하다면 관점의 변화를 추구할 것을 권한다. 소개한 것처럼 빅데이터 분석은 플랫폼의 변화만큼이나 인식의 변화도 요구되기 때문에다. 나무가 아닌 숲을 지향하고 미시적 팩트가 아닌 거시적 패턴을 발견하려는 노력이 필요하다.
‘브라질에서 한 나비의 날갯짓이 텍사스의 토네이도를 일으킬 수도 있다’는 혼돈이론이 등장한 당시만 해도 빅데이터를 운용할 수 있는 환경이 아니었기 때문이라고 생각해 본다. 이제 빅데이터 분석이 가능한 환경적?기술적 여건이 갖춰진 만큼, 기존에 존재했던 수많은 분석 모델들이 다른 관점에서 적용될 것으로 예상된다. 예전에는 버려졌던 이상치 데이터에도 주의를 기울이는 예리함이 필요하다.
또한 마치 법의학자가 사자의 마지막 말을 프로파일링을 통해 발견하고 전달하는 것과 같은 직관이 필요하다. 빅데이터 분석은 과학과 인문학의 융합만큼이나 당연한 것 같지만 이질적인 복합성이 존재하는 영역이라는 것을 첨언하며 마친다.
출처 : 한국데이터베이스진흥원
제공 : DB포탈사이트 DBguide.net
1339161268_[ITFIND]주간기술동향 1549호.pdf
특허,실용신안 등록출원의 명세서 심사기준 연구
