2019.05.21

"실패 가능성 85%" 빅데이터 프로젝트의 문제와 해법

Andy Patrizio | InfoWorld
빅데이터 프로젝트는 규모가 크고 목표가 웅대하다. 그리고 완전히 실패하는 경우가 많다. 2016년 가트너는 빅데이터 프로젝트의 60%가 실패한 것으로 추산했다. 1년 뒤 가트너의 애널리스트 닉 휴데커는 60%의 추정치가 “지나치게 보수적”이었다며 실패 비율이 85%에 근접한다고 말했다. 휴데커는 이러한 상황이 지금도 바뀌지 않았다고 본다.

가트너만 이렇게 평가하는 것은 아니다. 최근까지 오랜 기간 마이크로소프트의 고위 임원을 지낸 스노우플레이크 컴퓨팅(Snowflake Computing)의 CEO 밥 무글리아는 분석 사이트 데이터나미(Datanami)와의 인터뷰에서 “나는 행복한 하둡 고객을 본 적이 없다. 그것만으로 상황을 알 수 있다. 지금까지 하둡을 성공적으로 구축한 기업은 20개 미만, 어쩌면 10개 미만일 수도 있다. 제품과 기술이 얼마나 오래 전부터 시장에 존재했으며, 업계가 전반적으로 이 기술에 얼마나 힘을 쏟았는지 생각하면 말도 안 되는 수치”라고 말했다. 물론 하둡은 빅데이터 바람을 일으킨 엔진이다.

다른 빅데이터 전문가의 의견도 비슷하다. 실제로 심각한 수준의 문제가 있으며 전적으로 기술 문제만은 아니라는 것이다. 사실 진짜 실패의 원인에 비하면 기술은 부차적인 문제에 속한다. 빅데이터 프로젝트가 실패하는 4가지 주요 원인과 성공할 수 있는 4가지 주요 방법을 알아보자.
 
ⓒ GettyImagesBank
 

빅데이터 문제 1 : 부실한 통합

휴데커는 빅데이터 실패의 한 가지 중요한 기술적 문제는 서로 분리된 여러 소스의 데이터를 통합해 원하는 통찰력을 얻는 데 있다고 말했다. 격리된 레거시 시스템을 연결하기란 쉽지 않은 일이다. 휴데커는 통합 비용이 소프트웨어 비용의 5~10배에 이른다면서 “가장 큰 문제는 간단한 통합이다. 여러 데이터 소스를 연결해서 결과를 얻으려면 어떻게 해야 하는가? 많은 기업이 데이터 레이크를 선택하고, 이 기술이 마술처럼 모든 것을 연결해줄 것이라고 생각하지만 그건 착각”이라고 말했다.

격리된 데이터는 문제의 일부분일 뿐이다. 휴데커의 고객들은 각 시스템에서 데이터 레이크와 같은 공통 환경으로 데이터를 가져와도 그 값이 무엇을 의미하는지 알 수 없다고 말했다. 휴데커는 “데이터를 데이터 레이크로 가져올 때, 그 데이터의 값인 3이 무엇을 의미하는지 어떻게 알 수 있는가?”라고 물었다.

PwC의 선임 연구원 앨런 모리슨은 기업이 사일로에서 작업하거나 데이터 레이크를 만들었지만, 실상은 데이터 늪에 불과한 탓에 잠재력의 극히 일부만 활용된다고 지적했다. 모리슨은 “기계가 데이터를 충분히 해석할 수 있도록 하는 데 필요한 데이터의 모든 관계를 파악하지 못하고 있다. 안에서 매핑되는 모든 인스턴스 데이터를 기계가 해석할 수 있도록 지식 그래프 계층을 만들어야 한다. 그렇지 않으면 데이터 호수가 아닌 데이터 늪에 불과하다”고 설명했다.
 

빅데이터 문제 2 : 불분명한 목표

빅데이터 프로젝트를 추진하는 기업은 목표가 있을 것이라 생각하겠지만, 놀랍게도 많은 경우 그렇지 않다. 상당수가 일단 프로젝트를 시작하고 목표를 나중에 생각한다.

데이터 통합 소프트웨어 업체 탈렌드(Talend)의 제품 마케팅 관리자인 레이 크리스토퍼는 “문제의 범위를 명확히 규정해야 한다. 보통 구조적 데이터와 비구조적 데이터를 연결해서 필요한 통찰력을 얻을 수 있다고 생각한다. 그러나 미리 문제를 명확하게 정의해야 한다. 어떤 통찰력을 얻고자 하는가? 문제를 사전에 명확히 정의하는 것이 핵심”이라고 말했다.

엔터프라이즈 애플리케이션 컨설팅(Enterprise Application Consulting)의 수석 애널리스트 조슈아 그린바움은 빅데이터와 데이터 웨어하우스 프로젝트의 공통적인 장애물은 프로젝트의 주된 기준이 개별적인 비즈니스 문제 해결이 아닌 대량의 데이터 누적에 있다는 점이라고 지적했다.

그린바움은 “대량의 데이터를 모으기만 한다면 데이터 쓰레기 매립지가 될 뿐이다. 쓰레기장에서는 해결책을 찾을 수 없다”면서 “항상 고객에게 해결해야 할 개별적인 비즈니스 문제가 무엇인지 사전에 결정해서 거기에 집중하고, 비즈니스 문제가 파악된 다음부터 가용한 데이터의 품질을 살피고 데이터 문제를 해결하라고 조언한다”고 말했다. 

PwC의 모리슨은 “대부분의 빅데이터 프로젝트가 실패하는 이유는 무엇보다 대부분의 빅데이터 프로젝트 리더에게 비전이 없기 때문이다. 기업은 빅데이터에 대해 혼동하고 있다. 대부분은 그저 수치 데이터 또는 블랙박스 NLP, 인지 엔진 정도로 여기며 간단한 텍스트 마이닝이나 기타 패턴 인식 기능을 한다고 생각한다”고 말했다.
 

빅데이터 문제 3 : 기술 간극

기업은 데이터 웨어하우스를 구축한 내부 기술이 빅데이터에도 잘 적용될 것이라고 생각하는 경우가 많지만 사실은 그렇지 않다. 무엇보다 데이터 웨어하우스와 빅데이터가 데이터를 다루는 방식은 정반대다. 데이터 웨어하우스는 쓰기 스키마(schema on write)다. 즉, 데이터가 데이터 웨어하우스에 들어가기 전에 정제, 처리, 구조화, 정리된다.

빅데이터의 경우 데이터가 누적되며, 데이터가 읽힘과 동시에 처리되는 읽기 스키마(schema on read)가 적용된다. 결국 방법론에 따라 데이터 처리 순서가 반대라면 기술과 툴 역시 반대일 수밖에 없다. 게다가 이는 한 가지 예시일 뿐이다.

휴데커는 “기술은 항상 과제다. 앞으로 30년 후라 해도 빅데이터에는 여전히 과제가 있을 것”이라면서 “많은 사람이 하둡에 의지한다. 기업은 하둡 자원을 찾기가 어렵다고 말한다. 스파크는 스택이 비교적 작고 교육도 쉽기 때문에 조금 더 상황이 낫다. 하둡에는 수십 개의 소프트웨어 구성 요소가 있다”고 말했다.
 

빅데이터 문제 4 : 기술 세대 차이

빅데이터 프로젝트를 추진하면서 기존의 데이터 사일로를 가져와 센서 또는 웹 트래픽이나 소셜 미디어와 같은 새로운 데이터 소스와 병합하려는 경우가 많다. 사실 기업은 빅데이터 분석이라는 개념이 생기기 전부터 데이터를 수집해왔으니 기업이 잘못한 것은 아니지만 어쨌든 문제가 된다.

컨설턴트 그린바움은 “대부분의 경우 가장 부족한 스킬은 복잡한 문제를 함께 해결하도록 두 진영을 혼합하는 방법을 이해하는 스킬”이라며, “데이터 사일로는 아무런 표준도 없으므로 빅데이터 프로젝트를 가로막는 장애물이 될 수 있다. 빅데이터를 계획하면서 데이터 사일로가 데이터를 재사용할 수 있는 방식으로 구현되지 않았음을 알게 된다”고 말했다.

탈렌드의 크리스토퍼는 “다양한 아키텍처가 사용되므로 처리 방법도 각기 달라야 한다. 온프레미스 데이터 웨어하우스를 위한 현재의 툴을 사용해서 이를 빅데이터 프로젝트에 통합하지 못하는 공통적인 이유는 기술적인 특성과 아키텍처의 차이다. 이러한 기술로 새로운 데이터를 처리하려면 너무 큰 비용이 들기 때문이다. 따라서 하둡과 스파크가 필요하고 새로운 언어를 배워야 한다”고 말했다.
 


빅데이터 성공 해법 1 : 사전 계획

가트너의 휴데커는 “흔한 말이지만 ‘계획하지 않으면 실패를 계획하는 것’이라는 말이 여기에도 적용된다. 규모가 작고 달성 가능하며 새로운 것을 선택하라. 제약이 있는 레거시 사용 사례를 선택하면 안 된다”고 말했다. PwC의 모리슨은 “데이터에 대해 먼저 생각하고, 데이터가 그 조직에 유용하도록 기계가 읽을 수 있는 방식으로 조직을 모델링해야 한다”고 말했다.
 

빅데이터 성공 해법 2 : 협력

빅데이터 프로젝트에 이해당사자, 즉 프로젝트의 결과를 사용할 사람이 배제되는 경우가 많다. 휴데커는 모든 이해당사자가 협력하면 많은 걸림돌을 극복할 수 있다면서 “숙련된 기술 담당자들이 상호 협력하고, 또 비즈니스 당사자와 협력하면 실천 가능한 결과를 도출할 수 있다”고 말했다.

휴데커는 빅데이터에서 성공하는 기업은 필요한 스킬에 대대적으로 투자한다는 점을 강조했다. 이런 기업 중에는 금융 서비스나 우버(Uber), 리프트(Lyft), 넷플릭스와 같이 양질의 실질적 가치를 지닌 데이터에 기업의 성패가 좌우되는 데이터 지향 기업이 가장 많다. 탈렌드의 크리스토퍼는 “데이터를 수집하고 정제하는 과정을 팀으로 수행해야 한다. 그러면 데이터의 무결성도 높아진다”고 덧붙였다.
 

빅데이터 성공 해법 3 : 집중

빅데이터 프로젝트는 크고 웅대해야 한다는 선입견을 가진 경우가 많다. 처음 무언가를 배울 때 늘 그렇듯이 성공하기 위한 최선의 방법은 작게 시작한 다음 차츰 목표와 범위를 넓히는 것이다. 휴데커는 “아주 좁게 정의할 필요가 있다. 사기 탐지, 고객 미세 구분, 밀레니얼 시장에 적합한 신제품 찾기와 같은 문제 영역을 선택해서 집중해야 한다”고 지적했다.

크리스토퍼는 “결국 원하는 통찰력 또는 디지털화할 비즈니스 프로세스가 무엇인지를 물어야 한다. 기술이 그냥 비즈니스 문제를 해결해주지는 않는다. 먼저 정의해야 한다. 데이터 레이크는 필요하지만 비즈니스에 사용되지 않을 데이터는 수집하지 말아야 한다”고 말했다.

많은 경우 이는 지나치게 비대해지면 안 된다는 것을 의미하기도 한다. PwC의 모리슨은 “연구 대상 기업을 살펴보니, 전체 비즈니스가 실행되는 핵심적인 개념과 관계는 수백 개에 불과했다. 이 점을 이해하고 나면 수백만 가지의 구분이 이 수백 가지 중요한 것의 미세한 변형에 불과하다는 것을 알게 된다. 사실 작은 변형의 상당수는 애초에 변형도 아니다. 이름과 구조, 레이블만 다를 뿐 동일한 것”이라고 설명했다.
 

빅데이터 성공 해법 4 : 레거시 폐기

수집해서 데이터 웨어하우스에 저장해 둔 테라바이트 규모의 데이터를 활용하고 싶겠지만, 사일로가 없도록 설계된 빅데이터용 스토리지 시스템에 새롭게 수집한 데이터에만 집중하는 편이 더 나을 수 있다. 컨설턴트 그린바움은 “단순히 라이선스가 있다는 이유만으로 기존 기술 인프라에 묶여 있을 필요는 없다. 복잡한 새 문제에는 복잡한 새 솔루션이 필요한 경우가 많다. 10년 전부터 사용한 오래된 툴을 고수하는 것은 바람직한 방법이 아니다. 많은 기업이 오래된 툴을 사용하며 이로 인해 프로젝트가 실패한다”고 지적했다.

모리슨은 “스스로 발목을 잡지 말아야 한다. 더 많은 사일로를 생성하는 레거시 아키텍처를 버려야 한다”고 강조했다. 또한 모리슨은 기술 업체가 복잡한 시스템 문제를 대신 해결해줄 것이라고 기대하면 안 된다면서 “수십 년 동안 많은 기업이 빅데이터 문제를 해결할 방법을 돈을 주고 살 수 있다고 생각했다. 모든 빅데이터 문제는 시스템 문제다. 복잡한 시스템 변경이 필요한 경우 그 방법을 기업 스스로 만들어야 한다”고 덧붙였다.  editor@itworld.co.kr



2019.05.21

"실패 가능성 85%" 빅데이터 프로젝트의 문제와 해법

Andy Patrizio | InfoWorld
빅데이터 프로젝트는 규모가 크고 목표가 웅대하다. 그리고 완전히 실패하는 경우가 많다. 2016년 가트너는 빅데이터 프로젝트의 60%가 실패한 것으로 추산했다. 1년 뒤 가트너의 애널리스트 닉 휴데커는 60%의 추정치가 “지나치게 보수적”이었다며 실패 비율이 85%에 근접한다고 말했다. 휴데커는 이러한 상황이 지금도 바뀌지 않았다고 본다.

가트너만 이렇게 평가하는 것은 아니다. 최근까지 오랜 기간 마이크로소프트의 고위 임원을 지낸 스노우플레이크 컴퓨팅(Snowflake Computing)의 CEO 밥 무글리아는 분석 사이트 데이터나미(Datanami)와의 인터뷰에서 “나는 행복한 하둡 고객을 본 적이 없다. 그것만으로 상황을 알 수 있다. 지금까지 하둡을 성공적으로 구축한 기업은 20개 미만, 어쩌면 10개 미만일 수도 있다. 제품과 기술이 얼마나 오래 전부터 시장에 존재했으며, 업계가 전반적으로 이 기술에 얼마나 힘을 쏟았는지 생각하면 말도 안 되는 수치”라고 말했다. 물론 하둡은 빅데이터 바람을 일으킨 엔진이다.

다른 빅데이터 전문가의 의견도 비슷하다. 실제로 심각한 수준의 문제가 있으며 전적으로 기술 문제만은 아니라는 것이다. 사실 진짜 실패의 원인에 비하면 기술은 부차적인 문제에 속한다. 빅데이터 프로젝트가 실패하는 4가지 주요 원인과 성공할 수 있는 4가지 주요 방법을 알아보자.
 
ⓒ GettyImagesBank
 

빅데이터 문제 1 : 부실한 통합

휴데커는 빅데이터 실패의 한 가지 중요한 기술적 문제는 서로 분리된 여러 소스의 데이터를 통합해 원하는 통찰력을 얻는 데 있다고 말했다. 격리된 레거시 시스템을 연결하기란 쉽지 않은 일이다. 휴데커는 통합 비용이 소프트웨어 비용의 5~10배에 이른다면서 “가장 큰 문제는 간단한 통합이다. 여러 데이터 소스를 연결해서 결과를 얻으려면 어떻게 해야 하는가? 많은 기업이 데이터 레이크를 선택하고, 이 기술이 마술처럼 모든 것을 연결해줄 것이라고 생각하지만 그건 착각”이라고 말했다.

격리된 데이터는 문제의 일부분일 뿐이다. 휴데커의 고객들은 각 시스템에서 데이터 레이크와 같은 공통 환경으로 데이터를 가져와도 그 값이 무엇을 의미하는지 알 수 없다고 말했다. 휴데커는 “데이터를 데이터 레이크로 가져올 때, 그 데이터의 값인 3이 무엇을 의미하는지 어떻게 알 수 있는가?”라고 물었다.

PwC의 선임 연구원 앨런 모리슨은 기업이 사일로에서 작업하거나 데이터 레이크를 만들었지만, 실상은 데이터 늪에 불과한 탓에 잠재력의 극히 일부만 활용된다고 지적했다. 모리슨은 “기계가 데이터를 충분히 해석할 수 있도록 하는 데 필요한 데이터의 모든 관계를 파악하지 못하고 있다. 안에서 매핑되는 모든 인스턴스 데이터를 기계가 해석할 수 있도록 지식 그래프 계층을 만들어야 한다. 그렇지 않으면 데이터 호수가 아닌 데이터 늪에 불과하다”고 설명했다.
 

빅데이터 문제 2 : 불분명한 목표

빅데이터 프로젝트를 추진하는 기업은 목표가 있을 것이라 생각하겠지만, 놀랍게도 많은 경우 그렇지 않다. 상당수가 일단 프로젝트를 시작하고 목표를 나중에 생각한다.

데이터 통합 소프트웨어 업체 탈렌드(Talend)의 제품 마케팅 관리자인 레이 크리스토퍼는 “문제의 범위를 명확히 규정해야 한다. 보통 구조적 데이터와 비구조적 데이터를 연결해서 필요한 통찰력을 얻을 수 있다고 생각한다. 그러나 미리 문제를 명확하게 정의해야 한다. 어떤 통찰력을 얻고자 하는가? 문제를 사전에 명확히 정의하는 것이 핵심”이라고 말했다.

엔터프라이즈 애플리케이션 컨설팅(Enterprise Application Consulting)의 수석 애널리스트 조슈아 그린바움은 빅데이터와 데이터 웨어하우스 프로젝트의 공통적인 장애물은 프로젝트의 주된 기준이 개별적인 비즈니스 문제 해결이 아닌 대량의 데이터 누적에 있다는 점이라고 지적했다.

그린바움은 “대량의 데이터를 모으기만 한다면 데이터 쓰레기 매립지가 될 뿐이다. 쓰레기장에서는 해결책을 찾을 수 없다”면서 “항상 고객에게 해결해야 할 개별적인 비즈니스 문제가 무엇인지 사전에 결정해서 거기에 집중하고, 비즈니스 문제가 파악된 다음부터 가용한 데이터의 품질을 살피고 데이터 문제를 해결하라고 조언한다”고 말했다. 

PwC의 모리슨은 “대부분의 빅데이터 프로젝트가 실패하는 이유는 무엇보다 대부분의 빅데이터 프로젝트 리더에게 비전이 없기 때문이다. 기업은 빅데이터에 대해 혼동하고 있다. 대부분은 그저 수치 데이터 또는 블랙박스 NLP, 인지 엔진 정도로 여기며 간단한 텍스트 마이닝이나 기타 패턴 인식 기능을 한다고 생각한다”고 말했다.
 

빅데이터 문제 3 : 기술 간극

기업은 데이터 웨어하우스를 구축한 내부 기술이 빅데이터에도 잘 적용될 것이라고 생각하는 경우가 많지만 사실은 그렇지 않다. 무엇보다 데이터 웨어하우스와 빅데이터가 데이터를 다루는 방식은 정반대다. 데이터 웨어하우스는 쓰기 스키마(schema on write)다. 즉, 데이터가 데이터 웨어하우스에 들어가기 전에 정제, 처리, 구조화, 정리된다.

빅데이터의 경우 데이터가 누적되며, 데이터가 읽힘과 동시에 처리되는 읽기 스키마(schema on read)가 적용된다. 결국 방법론에 따라 데이터 처리 순서가 반대라면 기술과 툴 역시 반대일 수밖에 없다. 게다가 이는 한 가지 예시일 뿐이다.

휴데커는 “기술은 항상 과제다. 앞으로 30년 후라 해도 빅데이터에는 여전히 과제가 있을 것”이라면서 “많은 사람이 하둡에 의지한다. 기업은 하둡 자원을 찾기가 어렵다고 말한다. 스파크는 스택이 비교적 작고 교육도 쉽기 때문에 조금 더 상황이 낫다. 하둡에는 수십 개의 소프트웨어 구성 요소가 있다”고 말했다.
 

빅데이터 문제 4 : 기술 세대 차이

빅데이터 프로젝트를 추진하면서 기존의 데이터 사일로를 가져와 센서 또는 웹 트래픽이나 소셜 미디어와 같은 새로운 데이터 소스와 병합하려는 경우가 많다. 사실 기업은 빅데이터 분석이라는 개념이 생기기 전부터 데이터를 수집해왔으니 기업이 잘못한 것은 아니지만 어쨌든 문제가 된다.

컨설턴트 그린바움은 “대부분의 경우 가장 부족한 스킬은 복잡한 문제를 함께 해결하도록 두 진영을 혼합하는 방법을 이해하는 스킬”이라며, “데이터 사일로는 아무런 표준도 없으므로 빅데이터 프로젝트를 가로막는 장애물이 될 수 있다. 빅데이터를 계획하면서 데이터 사일로가 데이터를 재사용할 수 있는 방식으로 구현되지 않았음을 알게 된다”고 말했다.

탈렌드의 크리스토퍼는 “다양한 아키텍처가 사용되므로 처리 방법도 각기 달라야 한다. 온프레미스 데이터 웨어하우스를 위한 현재의 툴을 사용해서 이를 빅데이터 프로젝트에 통합하지 못하는 공통적인 이유는 기술적인 특성과 아키텍처의 차이다. 이러한 기술로 새로운 데이터를 처리하려면 너무 큰 비용이 들기 때문이다. 따라서 하둡과 스파크가 필요하고 새로운 언어를 배워야 한다”고 말했다.
 


빅데이터 성공 해법 1 : 사전 계획

가트너의 휴데커는 “흔한 말이지만 ‘계획하지 않으면 실패를 계획하는 것’이라는 말이 여기에도 적용된다. 규모가 작고 달성 가능하며 새로운 것을 선택하라. 제약이 있는 레거시 사용 사례를 선택하면 안 된다”고 말했다. PwC의 모리슨은 “데이터에 대해 먼저 생각하고, 데이터가 그 조직에 유용하도록 기계가 읽을 수 있는 방식으로 조직을 모델링해야 한다”고 말했다.
 

빅데이터 성공 해법 2 : 협력

빅데이터 프로젝트에 이해당사자, 즉 프로젝트의 결과를 사용할 사람이 배제되는 경우가 많다. 휴데커는 모든 이해당사자가 협력하면 많은 걸림돌을 극복할 수 있다면서 “숙련된 기술 담당자들이 상호 협력하고, 또 비즈니스 당사자와 협력하면 실천 가능한 결과를 도출할 수 있다”고 말했다.

휴데커는 빅데이터에서 성공하는 기업은 필요한 스킬에 대대적으로 투자한다는 점을 강조했다. 이런 기업 중에는 금융 서비스나 우버(Uber), 리프트(Lyft), 넷플릭스와 같이 양질의 실질적 가치를 지닌 데이터에 기업의 성패가 좌우되는 데이터 지향 기업이 가장 많다. 탈렌드의 크리스토퍼는 “데이터를 수집하고 정제하는 과정을 팀으로 수행해야 한다. 그러면 데이터의 무결성도 높아진다”고 덧붙였다.
 

빅데이터 성공 해법 3 : 집중

빅데이터 프로젝트는 크고 웅대해야 한다는 선입견을 가진 경우가 많다. 처음 무언가를 배울 때 늘 그렇듯이 성공하기 위한 최선의 방법은 작게 시작한 다음 차츰 목표와 범위를 넓히는 것이다. 휴데커는 “아주 좁게 정의할 필요가 있다. 사기 탐지, 고객 미세 구분, 밀레니얼 시장에 적합한 신제품 찾기와 같은 문제 영역을 선택해서 집중해야 한다”고 지적했다.

크리스토퍼는 “결국 원하는 통찰력 또는 디지털화할 비즈니스 프로세스가 무엇인지를 물어야 한다. 기술이 그냥 비즈니스 문제를 해결해주지는 않는다. 먼저 정의해야 한다. 데이터 레이크는 필요하지만 비즈니스에 사용되지 않을 데이터는 수집하지 말아야 한다”고 말했다.

많은 경우 이는 지나치게 비대해지면 안 된다는 것을 의미하기도 한다. PwC의 모리슨은 “연구 대상 기업을 살펴보니, 전체 비즈니스가 실행되는 핵심적인 개념과 관계는 수백 개에 불과했다. 이 점을 이해하고 나면 수백만 가지의 구분이 이 수백 가지 중요한 것의 미세한 변형에 불과하다는 것을 알게 된다. 사실 작은 변형의 상당수는 애초에 변형도 아니다. 이름과 구조, 레이블만 다를 뿐 동일한 것”이라고 설명했다.
 

빅데이터 성공 해법 4 : 레거시 폐기

수집해서 데이터 웨어하우스에 저장해 둔 테라바이트 규모의 데이터를 활용하고 싶겠지만, 사일로가 없도록 설계된 빅데이터용 스토리지 시스템에 새롭게 수집한 데이터에만 집중하는 편이 더 나을 수 있다. 컨설턴트 그린바움은 “단순히 라이선스가 있다는 이유만으로 기존 기술 인프라에 묶여 있을 필요는 없다. 복잡한 새 문제에는 복잡한 새 솔루션이 필요한 경우가 많다. 10년 전부터 사용한 오래된 툴을 고수하는 것은 바람직한 방법이 아니다. 많은 기업이 오래된 툴을 사용하며 이로 인해 프로젝트가 실패한다”고 지적했다.

모리슨은 “스스로 발목을 잡지 말아야 한다. 더 많은 사일로를 생성하는 레거시 아키텍처를 버려야 한다”고 강조했다. 또한 모리슨은 기술 업체가 복잡한 시스템 문제를 대신 해결해줄 것이라고 기대하면 안 된다면서 “수십 년 동안 많은 기업이 빅데이터 문제를 해결할 방법을 돈을 주고 살 수 있다고 생각했다. 모든 빅데이터 문제는 시스템 문제다. 복잡한 시스템 변경이 필요한 경우 그 방법을 기업 스스로 만들어야 한다”고 덧붙였다.  editor@itworld.co.kr

X