가트너만 이렇게 평가하는 것은 아니다. 최근까지 오랜 기간 마이크로소프트의 고위 임원을 지낸 스노우플레이크 컴퓨팅(Snowflake Computing)의 CEO 밥 무글리아는 분석 사이트 데이터나미(Datanami)와의 인터뷰에서 “나는 행복한 하둡 고객을 본 적이 없다. 그것만으로 상황을 알 수 있다. 지금까지 하둡을 성공적으로 조련한 기업의 수는 20개 미만, 어쩌면 10개 미만일 수도 있다. 제품과 기술이 얼마나 오래 전부터 시장에 존재했으며, 업계가 전반적으로 이 기술에 얼마나 힘을 쏟았는지를 감안하면 말도 안 되는 수치”라고 말했다. 물론 하둡은 빅데이터 바람을 일으킨 엔진이다.
다른 빅데이터 전문가들의 의견도 비슷하다. 실제로 심각한 수준의 문제가 있으며 전적으로 기술 문제만은 아니라는 것이다. 사실 진짜 실패의 원인에 비하면 기술은 부차적인 문제에 속한다. 빅데이터 프로젝트가 실패하는 4가지 주요 원인과 성공할 수 있는 4가지 주요 방법을 알아보자.
빅데이터 문제 1 : 부실한 통합
휴데커는 빅데이터 실패의 한 가지 중요한 기술적 문제는 서로 분리된 여러 소스의 데이터를 통합해 원하는 통찰력을 얻는 데 있다고 말했다. 격리된 레거시 시스템을 연결하기란 쉽지 않은 일이다. 휴데커는 통합 비용이 소프트웨어 비용의 5~10배에 이른다면서 “가장 큰 문제는 간단한 통합이다. 여러 데이터 소스를 연결해서 결과를 얻으려면 어떻게 해야 하는가? 많은 기업이 데이터 레이크를 선택하고, 이 기술이 마술처럼 모든 것을 연결해줄 것이라고 생각하지만 그건 착각”이라고 말했다.격리된 데이터는 문제의 일부분일 뿐이다. 휴데커의 고객들은 각 시스템에서 데이터 레이크와 같은 공통 환경으로 데이터를 가져와도 그 값이 무엇을 의미하는지 알 수 없다고 말했다. 휴데커는 “데이터를 데이터 레이크로 가져올 때, 그 데이터의 값인 3이 무엇을 의미하는지 어떻게 알 수 있는가?”라고 물었다.
PwC의 선임 연구원 앨런 모리슨은 기업이 사일로에서 작업하거나 데이터 레이크를 만들었지만, 실상은 데이터 늪에 불과한 탓에 잠재력의 극히 일부만 활용된다고 지적했다. 모리슨은 “기계가 데이터를 충분히 해석할 수 있도록 하는 데 필요한 데이터의 모든 관계를 파악하지 못하고 있다. 안에서 매핑되는 모든 인스턴스 데이터를 기계가 해석할 수 있도록 지식 그래프 계층을 만들어야 한다. 그렇지 않으면 데이터 호수가 아닌 데이터 늪에 불과하다”고 설명했다.
빅데이터 문제 2 : 불분명한 목표
빅데이터 프로젝트를 추진하는 기업은 목표가 있을 것이라 생각하겠지만, 놀랍게도 많은 경우 그렇지 않다. 상당수가 일단 프로젝트를 시작하고 목표를 나중에 생각한다.데이터 통합 소프트웨어 업체 탈렌드(Talend)의 제품 마케팅 관리자인 레이 크리스토퍼는 “문제의 범위를 명확히 규정해야 한다. 보통 구조적 데이터와 비구조적 데이터를 연결해서 필요한 통찰력을 얻을 수 있다고 생각한다. 그러나 미리 문제를 명확하게 정의해야 한다. 어떤 통찰력을 얻고자 하는가? 문제를 사전에 명확히 정의하는 것이 핵심”이라고 말했다.
엔터프라이즈 애플리케이션 컨설팅(Enterprise Application Consulting)의 수석 애널리스트 조슈아 그린바움은 빅데이터와 데이터 웨어하우스 프로젝트의 공통적인 장애물은 프로젝트의 주된 기준이 개별적인 비즈니스 문제 해결이 아닌 대량의 데이터 누적에 있다는 점이라고 지적했다.
그린바움은 “대량의 데이터를 모으기만 한다면 데이터 쓰레기 매립지가 될 뿐이다. 쓰레기장에서는 해결책을 찾을 수 없다”면서 “항상 고객에게 해결해야 할 개별적인 비즈니스 문제가 무엇인지 사전에 결정해서 거기에 집중하고, 비즈니스 문제가 파악된 다음부터 가용한 데이터의 품질을 살피고 데이터 문제를 해결하라고 조언한다”고 말했다.
PwC의 모리슨은 “대부분의 빅데이터 프로젝트가 실패하는 이유는 무엇보다 대부분의 빅데이터 프로젝트 리더에게 비전이 없기 때문이다. 기업은 빅데이터에 대해 혼동하고 있다. 대부분은 그저 수치 데이터 또는 블랙박스 NLP, 인지 엔진 정도로 여기며 간단한 텍스트 마이닝이나 기타 패턴 인식 기능을 한다고 생각한다”고 말했다.
빅데이터 문제 3 : 기술 간극
기업은 데이터 웨어하우스를 구축한 내부 기술이 빅데이터에도 잘 적용될 것이라고 생각하는 경우가 많지만 사실은 그렇지 않다. 무엇보다 데이터 웨어하우스와 빅데이터가 데이터를 다루는 방식은 정반대다. 데이터 웨어하우스는 쓰기 스키마(schema on write)다. 즉, 데이터가 데이터 웨어하우스에 들어가기 전에 정제, 처리, 구조화, 정리된다.
빅데이터의 경우 데이터가 누적되며, 데이터가 읽힘과 동시에 처리되는 읽기 스키마(schema on read)가 적용된다. 결국 방법론에 따라 데이터 처리 순서가 반대라면 기술과 툴 역시 반대일 수밖에 없다. 게다가 이는 한 가지 예시일 뿐이다.
휴데커는 “기술은 항상 과제다. 앞으로 30년 후라 해도 빅데이터에는 여전히 과제가 있을 것”이라면서 “많은 사람들이 하둡에 의지한다. 기업은 하둡 자원을 찾기가 어렵다고 말한다. 스파크는 스택이 비교적 작고 교육도 쉽기 때문에 조금 더 상황이 낫다. 하둡에는 수십 개의 소프트웨어 구성 요소가 있다”고 말했다.