2021.03.29

김진철의 How-to-Big Data | 빅데이터 괴담

김진철 | CIO KR
이번 글은 필자가 지금까지 데이터 과학자로 경력을 쌓아오면서 경험했거나 듣고 읽었던 빅데이터 활용 사례들을 중심으로 빅데이터를 활용하는 과정에서 많은 조직이 흔히 저지르는 실수와 오해, 시행착오에 대해서 살펴보고, 이를 어떻게 개선할 수 있을지 같이 생각해보기로 한다.

소개하는 사례들은 실제 사례들이 아니라 필자가 경험했거나 들은 사례들을 각색하여 만든 가상의 사례들이며, 필자가 전달하고자 하는 메시지를 부각하기 위해 조금 과장했음을 미리 알려 둔다. 지금까지 같이 생각해봤던 빅데이터 활용의 교훈을 되새기고 독자들의 시행착오를 줄이는 것을 돕기 위해 만들 사례들이니 사실이 아닌 것을 염두에 주고 가볍고 즐겁게 읽었으면 좋겠다.
 
ⓒGetty Images


사례 1: 데이터 호수가 너무 넓어서 ROI가 나지 않아 곤란한 A 기업의 CIO 이야기
많은 사람에게 널리 알려진 A 회사에서 빅데이터를 앞세워 승승장구한 C는 요즘 고민이 많다. 문제는 바로 그에게 회사에서 승승장구한 경력을 만들어준 데이터 레이크 시스템 때문이다.

C는 2011년도 빅데이터 붐이 일기 시작할 즈음 승진을 위한 기획 아이템으로 뭘 앞세울까 고민하다가 그 당시 막 떠오르고 있던 빅데이터를 앞세워서 A 회사에 하둡 기반의 빅데이터 시스템을 구축하는 기획안을 만들어 임원의 승인을 받는 데 성공했다. 

당시 NexR과 같이 오픈소스 하둡을 기반으로 빅데이터 솔루션을 상용화하는 스타트업이 막 등장하고 있었다. 이런 스타트업 중에서 괜찮은 회사 하나를 잘 골라서 같이 일하면서 키우면 자신의 승진에 많이 도움이 될 것 같았다. 운이 좋다면 자신의 직속 임원이 이 스타트업을 인수, 합병하여 사업 성과를 낼 수 있도록 하면서 그 회사의 고급 소프트웨어 엔지니어들을 자연스럽게 회사로 영입하여 자신의 세력으로 키울 수 있을 것 같았다.

C는 당시 하둡 기반 빅데이터 스타트업으로서 같이 하둡 시스템 구축 사업을 수행한 D사를 잘 활용하여 예상보다 빠르게 하둡 시스템을 안정적으로 구축할 수 있었다. 이후 프로젝트를 승인해준 임원의 지원으로 빅데이터 시스템을 성공적으로 구축하여 회사가 빅데이터 활용에서 앞서 나갈 수 있게 했다는 공로를 인정받아 승진하여 A사의 빅데이터 그룹을 총괄하는 그룹장이 되었다. A사에서 빅데이터 분야의 전문가로 인정받아 계속해서 승승장구할 수 있을 것 같았다.

그룹장 승진 후 요즘은 데이터가 금맥이라는 세간의 말을 A사의 대표 이사가 회의 석상에서 C에게 자주 읊기 시작했다. 이제 데이터를 많이 모았을 테니 빨리 회사의 수익에 도움이 될 만한 데이터 분석 결과를 보고 싶다는 대표 이사의 은근한 압박은 처음에는 빅데이터 전문가라는 자신감과 승진의 기쁨으로 크게 걱정이 되는 일이 아니었으나, 시간이 지날수록 데이터 분석에서 원래 생각했던 “제대로 된 한 건”이 나오지 않으면서 점차 부담이 커지기 시작했다.

자신보다 학력도 높고 소위 업계 전문가라는 데이터 과학자들을 꽤 많이 채용해서 데이터 과학팀을 운영하고 있었지만, 어찌 된 이유인지 데이터 분석 결과가 영 신통치 않았다. 성과가 전혀 없는 것은 아니었다. 확인되지는 않았지만 회사를 경영하는 과정에서 어렴풋하게 얻었던 직관적인 지식이 데이터로 사실임이 확인된 것들도 꽤 많았다. 그렇지만, 회사의 수익을 크게 개선시켜 줄 만큼 눈에 띄는 성과로 이어질 것 같은 분석 결과는 나오지 않았다.

그룹장 승진 후 3년이 지날 때까지 데이터 분석으로 눈에 띄는 성과가 나지 않자, C는 임원 승진을 위한 또 하나의 승부수를 띄우기로 했다. 당시 막 유행하기 시작했던 “데이터 레이크(Data Lake)”를 하둡을 기반으로 구축하고, 현재 자신을 지원하고 있는 임원의 정치적 영향력을 이용해 전사의 데이터가 모두 이 데이터 레이크에 모이게끔 해서 모든 데이터에 대한 관리 권한을 자신에게 집중시키려는 것이었다.

전사 사업부들의 반발이 왠지 심할 수도 있을 것 같다는 생각이 들었지만, 대표 이사를 설득해서 일단 데이터 레이크로 모든 데이터를 모을 수만 있으면 그토록 바라던 데이터 분석 한방도 노릴 수 있을 것 같았다. C는 대표 이사에게 지금까지 데이터 분석 결과가 회사 수익에 눈에 띄지 않게 도움이 되지 않았던 것은 전사의 데이터를 현재 사업 운영 데이터와 같이 분석하지 않기 때문이라고 설득해서 데이터 레이크 구축을 위한 예산과 인력을 추가로 받는 데 성공했다.

A사의 빅데이터 프로젝트는 이제 데이터 레이크 구축 프로젝트로 바뀌었고, 각 사업부의 모든 데이터를 새로 구축한 데이터 레이크로 모으라는 C의 요청과 협조하라는 대표 이사의 지시에 전사 사업부들의 반발이 예상대로 이어졌다. 그렇지만, 대표이사의 지원으로 각 부서의 협조를 얻어서 일단 데이터 레이크로 데이터를 모으는 시스템을 구축하는 데 성공했다. 전사의 데이터를 속속들이 모으기 시작했으니 똑똑한 데이터 과학자들만 채근하면 이제 기대하던 데이터 분석 한방을 얻는 것은 시간문제일 것 같았다.

데이터 레이크 구축 후 속속 각 사업부의 사업 운영 데이터를 저장하는 데이터베이스와 비정형 데이터들이 데이터 레이크로 수집되기 시작했고, 데이터 과학팀의 데이터 과학자들이 다양한 분석을 시작했지만 여전히 신통한 결과를 보이지 않았다. 데이터 레이크가 구축되어 전사 데이터를 수집하고 분석한 지 3년이 지나기 시작했지만 데이터 레이크를 구축하기 전과 크게 상황이 달라지지 않았다.

뚜렷한 데이터 분석 성과가 6년이 되도록 보이지 않자 대표 이사는 이제는 임원이 된 C에게 노골적으로 불만을 내비치기 시작했다. C는 임원으로 승진한 지 2년이 넘어 계약 만료가 얼마 남지 않았는데, 대표이사가 이번에도 본인을 신뢰해줄지 왠지 자신이 없었다. 더군다나, A사의 지주사인 그룹의 E 회사에서 곧 A사의 대표이사를 새로 선임할 것이라고 하는데, 왠지 새 대표이사가 현재의 빅데이터 그룹장 자리에 본인을 계속 둘 것인지도 알 수 없었다.

이에 더해서 데이터가 점점 수집되다 보니 데이터 레이크 시스템의 꾸준한 증설이 필요했고, 전사의 데이터가 늘어나고 축적되다 보니 해가 갈수록 시스템 증설과 운영에 필요한 비용이 점차 늘어나기 시작했다. 데이터 분석의 성과가 생각보다 신통치 않자 대표이사가 C가 신청하는 데이터 레이크 시스템 증설, 운영 비용에 대해서 재검토하라는 지시를 하였고, 늘어나는 데이터에 비해 예산이 모자라 데이터 레이크 시스템 유지가 어려워지기 시작했다.

데이터 과학팀의 데이터 과학자들의 회의에서 좀 의미 있는 데이터 분석 결과를 만들어 달라고 계속 채근하지만, 데이터 과학자들은 불만 섞인 목소리로 노력하고 있다고만 답할 뿐이다. C의 인내심이 한계에 이른 어느 날 데이터 과학팀 회의 시간에 데이터 과학자들에게 내가 데이터 레이크도 잘 만들어주고 데이터도 다 모아 줬는데 왜 분석을 제대로 못 하는 거냐고 호통을 쳤다.

데이터 과학자들이 분석, 검토해야 할 데이터의 양이 너무 많이 늘어나서, 이 중에서 관련이 있는 정보들을 찾아내기 위한 데이터 정제, 전처리 작업에 드는 시간이 너무 많아 정작 부서 데이터 간 교차 분석을 할 수 있는 시간이 많이 부족하다고 설명했으나 C의 눈에는 이 모든 것들이 변명처럼 보여 화만 계속 났다.

이 일이 있고 난 이후로 데이터 과학팀을 떠나 부서를 이동하거나 이직을 하는 데이터 과학자들이 점점 늘어나기 시작했다. 안 그래도 임원들 사이에서 데이터 레이크가 돈 잡아먹는 하마로 말이 돌기 시작하는 때에 데이터 분석 성과를 내어주어야 할 데이터 과학자들까지 떠나고 있으니 대표이사에게 안 좋은 인상을 줄 것이 분명했다.

결국 C는 그해 정기 임원 인사에서 밀려나 회사를 나와야 했다. 다행히 회사에서 밀려나기 전에 헤드헌터의 연락을 받아 G사에 신설되는 빅데이터 본부의 본부장 자리를 제안받았고, A사에서 빅데이터 그룹장으로 일했던 경력을 인정받아 빅데이터를 활용하고 싶어 하던 G사의 빅데이터 본부 본부장으로 이직하는 데 성공했다.

이직에 성공하기는 했지만, A사에서 있던 동안 빅데이터 프로젝트를 진행하면서 왜 기대했던 성과가 나오지 않았는지 아직도 이해할 수 없었다. 일단은 지난 7년간 A사에서 빅데이터라는 말로 승승장구했던 방식을 다시 써먹으면서 이직한 G사에서도 당분간 버텨볼 생각이다. 

하지만, 뭔가 문제가 있다는 생각이 계속해서 들었고 그게 뭔지 알 수 없어 답답했다. G사에서도 비슷한 방식으로 7년 정도 버티다가 또 적당한 때에 이직을 해볼까하는 생각도 든다. 그것도 나쁘지 않겠지만, 최근 빅데이터 분야에서 더 이상 하둡이 떠오르는 말이 아닌 것이 마음에 걸린다. 스파크(Spark)니, 플링크(Flink)니 새로운 빅데이터 기술이 나온 것도 모자라 이제는 데이터 가공 파이프라인도 자산화해야 하고 에어플로우(Airflow) 같은 새로운 데이터 가공 파이프라인 기술도 써야 한다고 한다.

G사에서 빅데이터 프로젝트를 축포를 터뜨리면서 시작하는 날, C는 자신의 앞날이 어떻게 될지 막연한 불안감이 앞섰다. 뭐가 문제였고 어떻게 해야 할까? 데이터만 모아서 분석만 하면 회사 수익이 쑥쑥 크는 중요한 정보가 쏟아져 나올 것 같았는데, 이번에도 비슷한 상황이면 어떻게 하지라는 걱정이 앞서기 시작했다. C는 이런 고민으로 불면증과 스트레스에 시달리면서 오늘도 불안한 회사 생활을 계속하고 있다.

사례 1의 교훈
지금 소개한 사례 1과 같은 경우가 빅데이터 붐이 인 지난 2011년부터 지금까지 필자가 가장 많이 보아온 경우다. 대개의 경우 기업의 내부 구성원이 승진과 성과를 위한 프로젝트로써 트렌드 분석을 하다가 빅데이터에 관한 자료를 읽게 되고, 빅데이터라는 말을 앞세워서 빅데이터 기술의 대표 격인 하둡(Hadoop)을 이용한 데이터 분석 시스템 구축을 기획, 실행하면서 빅데이터 프로젝트가 시작된다.

이렇게 시작된 빅데이터 프로젝트는 데이터 분석이 왜 필요하고, 현재 기업의 사업과 현안에 어떤 효용이 있으며, 데이터 분석을 통해서 뭘 얻고자 하고, 데이터 분석이 기업의 비즈니스 모델과 어떤 관계가 있는지 구체적이고 실질적인 분석과 고민이 없이 시작하게 된다. 

이렇게 시작되다 보니 겉으로는 빅데이터 프로젝트라는 거창한 이름으로 시작하지만 기업의 비즈니스 모델과 정렬되어 효용이 정의되지 않고, 기업의 어떤 필요에 부응하게 될 것인지 분명하지 않은 상태에서 하둡(Hadoop)과 같은 데이터 처리, 분석용 분산 컴퓨팅 시스템을 구축하는 시스템 통합 프로젝트로 진행되게 된다.

위와 같은 과정을 통해 시스템 통합 프로젝트로 하둡(Hadoop) 시스템을 구축하기는 하지만, 기업의 비즈니스 모델과 연계되지도 않았고 분석할 데이터가 당장 모이지도 않기 때문에, 프로젝트가 끝나게 되면 하둡(Hadoop) 클러스터 하나만 덩그러니 남게 되고 경영진을 통한 많은 구성원이 이제 뭘 해야 할지 고민하기 시작한다.

우선 분석할 데이터를 모아야 하기 때문에 사내에 있는 데이터를 이리저리 끌어다가 하둡(Hadoop) 시스템에 적재하는 일부터 진행하게 된다. 여기까지는 그럴 수 있다고 하지만, 문제는 들이는 노력에 비해서 효과가 크지 않다는 것이다. 사내에 있는 데이터 대부분이 관계형 데이터베이스에 저장된 테이블 형태의 데이터이거나 그렇지 않으면 마이크로소프트 엑셀(Excel)과 같은 형태의 정형 데이터가 우선 눈에 띄게 된다.

이런 데이터베이스 및 정형 데이터를 먼저 끌어다가 ETL 도구와 데이터 정제, 마이그레이션을 위한 솔루션 업체나 용역 업체를 통해서 하둡(Hadoop) 시스템으로 데이터를 옮기기 시작한다. 그다음, 하둡(Hadoop) 생태계에서 쓰이는 데이터 분석 소프트웨어인 HBase나 Hive, Impala와 같은 소프트웨어들을 이용해 데이터를 분석하기 시작한다.

여기까지도 기업에서는 빅데이터 활용을 시작했다는 자부심과 기대감으로 빅데이터 프로젝트에 투자와 지원을 하며, 해당 프로젝트를 기획하고 추진한 구성원은 승진과 같은 보상을 받고, 이와 함께 그 구성원의 프로젝트를 후원하는 임원과 리더들이 같이 승진하면서 사내에서 점점 주목받는 프로젝트로 성장하게 된다.

문제는 이 다음부터 일어난다. 데이터 과학자와 데이터 엔지니어도 열심히 채용해서 데이터 분석을 시키고, 사내에 있는 데이터 소스들을 모두 모아 하둡(Hadoop) 기반의 빅데이터 분석 시스템과 데이터 레이크에 연동하여 데이터를 열심히 모아 쌓지만, 정작 이들 데이터를 열심히 분석해보면 실제 사업화하거나 사업에 크게 도움이 될 수 있는 지식과 통찰을 얻기가 의외로 쉽지 않다는 것을 알게 된다.

이렇게 데이터 분석을 통해서 성과를 내기가 쉽지 않다 보니 다시 기존의 데이터 분석 시스템을 새로운 빅데이터 기술을 들여와 업그레이드하거나, 기존의 빅데이터 시스템을 데이터 레이크로 전환하는 것과 같은 새로운 트렌드 용어를 이용한 정보 시스템 구축 프로젝트로 바꾸어 예산을 받고 성과를 내는 일이 반복된다. 

이렇게 정말 중요한 데이터 과학 업무를 수행하지 않고 예산과 시간의 대부분을 눈에 보이는 성과를 낼 수 있는 빅데이터 정보 시스템 구축 프로젝트 위주로 빅데이터 프로젝트가 돌아가기 시작하면서 데이터 과학을 활용할 수 있는 환경과 무형적 자산을 쌓는 데 소홀하게 돼 데이터 과학의 활용이 더디어지게 된다.

빅데이터 시스템은 구축을 해 놓는다고 해서 자동으로 기업의 비즈니스를 위한 통찰과 지식이 쏟아져 나오는 것이 아니다. 데이터 과학자들이 이 빅데이터 시스템을 잘 이용해서 다루기 어려운 빅데이터들을 효과적으로 다루고 이들을 사업 기획과 운영에 활용할 수 있는 지식과 통찰로 바꾸고 정제해주어야 쓸모가 있는 것이다. 

이런 데이터 과학 활동을 통해 쌓인 소프트웨어들이 쌓이고 모여 자동화된 분석 시스템과 데이터 가시화, 큐레이션 시스템으로 발전해갈 때 비로소 빅데이터 시스템이 자동으로 기업의 비즈니스에 부가가치를 만들어 내기 시작하는 것이다.

데이터 과학자들을 뽑는 과정에서도 필자는 많은 문제점을 확인할 수 있었다. 대개 이런 식으로 기업의 내부 구성원이 자신의 승진과 성과를 위해 빅데이터 프로젝트를 시작하게 된 경우는 해당 구성원이 계속해서 주도권을 쥐고 리더의 역할을 하기를 원하는 경우가 많다. 이런 상황에서는 앞의 사례에서 소개한 것과 같은 시행착오를 겪으면서 본인의 역량을 외부에서 데이터 과학자들을 영입해서 해결하려고 하게 된다.

문제는 데이터 과학자들이 자기조직적으로 능동적으로 팀워크를 발휘할 수 있도록 주니어 데이터 과학자, 시니어 데이터 과학자, 리더급 데이터 과학자를 적절하게 선발해서 지원해주어야 하는데 주니어 데이터 과학자 위주로 편향되어 선발한다는 것이다. 

대개의 경우 기존 빅데이터 프로젝트를 시작한 구성원보다 높은 학력과 경력을 가지고 있는 전문가들이 데이터 과학자로서 검토 대상이 되는 경우가 많기 때문에, 빅데이터 프로젝트를 시작한 내부 구성원은 자신의 승진과 이해관계 때문에 주니어 데이터 과학자 위주로 데이터 과학자들을 영입하게 된다.

이렇게 되면서, 이들이 적절한 데이터 분석 과제를 찾고 문제 해결을 해나갈 수 있도록 지도하고 이끌어갈 수 있는 시니어 데이터 과학자, 리더급 데이터 과학자가 영입되지 않아 데이터 과학팀이 자기조직적으로, 자기 스스로 목표 설정을 하고 움직이는 자율적인 팀이 되기보다는 빅데이터 프로젝트를 리드하고 있는 내부 구성원 리더의 통제를 받는 조직으로 바뀌게 된다. 

이런 경우 내부 구성원이 데이터 과학을 혼자서 익혀서라도 제대로 수행한다면 문제가 없지만 대개의 경우 데이터 과학을 이용해 문제를 직접 해결해본 경험이나 역량이 부족한 경우가 많기 때문에 데이터 과학팀이 자율적인 문제 해결 역량을 발휘하지 못하고 사업 경험을 통해 쌓은 경험적인 사실들만 데이터를 통해 다시 확인하는 과정만 반복하게 된다.

이렇게 데이터 과학팀이 본연의 역할을 하지 못하게 되면 빅데이터 시스템과 데이터 과학자 영입에 투자하면서 회사 사업의 성장을 기대했던 대표 이사를 포함한 경영진들은 데이터 과학팀과 빅데이터 프로젝트팀에 성과 독촉을 하기 시작한다. 

이 때문에 초조해진 데이터 과학팀과 빅데이터 프로젝트 리더들이 데이터 과학자와 데이터 엔지니어들에게 성과 독촉을 하는 악순환에 빠지게 되면서 어렵게 영입한 데이터 과학자들이 조직을 떠나게 되고, 이 때문에 데이터 과학팀의 역량과 데이터 과학 추진 의지가 약해지게 된다.

이렇게 나타나는 데이터 과학자의 영입과 데이터 과학팀의 운영 과정에서 생기는 문제와 함께, 일반 기업에서 데이터 과학을 잘 활용하지 못하는 또 하나의 중요한 이유는 보유한 데이터가 가지는 정보의 한계를 적절하게 평가하지 않고 무작정 데이터 분석부터 시작하는 것이다.

이미 보유한 데이터들, 특히 데이터베이스 테이블로 정의, 축적된 정형 데이터들은, 이들 정형 데이터들을 수집하기 위한 데이터베이스 스키마가 모델링, 정의되는 시점의 필요에 맞게 정의되어 수집되었기 때문에 이 필요에 맞는 정보만을 담고 있다. 

물론 이 정보가 다른 데이터가 가진 정보와 같이 분석되어 지금까지 미처 파악하지 못하고 있던 사실과 통찰을 발견할 수 있는 가능성이 없지는 않다. 그렇지만, 이렇게 긍정적인 상황인지 여부도 데이터 과학자들이 기존에 수집된 데이터 사이의 관계와 관련성에 대해서 많은 노력을 들여 분석, 검토, 해석을 해봐야 알 수 있는 것이다.

그런데, 데이터 과학 프로젝트 사례들을 보면 이렇게 분석의 대상으로 삼는 정형 데이터들이 지금 풀려는 문제와 관련된 정보를 어느 정도로 담고 있고, 이 정보가 얼마나 쓸모가 있는지 적절하게 평가하는 과정이 없이 무작정 탐색적 데이터 분석부터 시작하는 경우가 많다. 기존에 가진 데이터 자산이 가진 정보와 효용에 대한 사전 평가 없이 하는 탐색적 데이터 분석은 노력에 비해 얻는 것이 많지 않고 낭비도 심한 경우가 많다.

비정형 데이터의 경우, 정형 데이터와 같이 데이터가 가진 정보의 수준과 효용에 대한 평가를 체계적으로 하기 어렵기 때문에 쉽지 않을 수는 있다. 그렇다고 하더라도 지금 해결하려고 하는 문제와 관련이 있는지, 원하는 정보를 충분히 얻을 수 있을지 사전에 검토, 확인하고 시작하는 것이 데이터 분석 과정의 시행착오를 줄이는 데 도움이 된다.

이렇게 이미 보유한 데이터 자산을 기초로 하여 시작하는 데이터 과학 프로젝트에서 이미 수집된 데이터가 가진 정보와 효용을 평가하는 과정은, 데이터 과학 프로젝트 착수 전의 기획 과정에서 이 프로젝트에서 어떤 문제를 해결하고, 어떤 사업상의 효과를 기대하는지 명확하게 분석, 정의되었을 때 그 효과가 더 커진다. 

막연하게 하둡(Hadoop) 클러스터와 같은 빅데이터 시스템을 구축하는 프로젝트로 시작하는 것보다 지금 데이터 과학을 이용해 해결하고자 하는 비즈니스 문제가 무엇인지, 왜 데이터 분석이 필요한지, 데이터 분석 과정을 통해 어떤 정보를 얻어야 하고 어떤 사업상의 효용을 기대해야 하는지, 사전에 가능하면 구체적으로 기획, 디자인하고 시작해야 데이터 과학의 효용을 비로소 경험할 수 있다.

데이터 과학 활동이 진정한 비즈니스 금맥이 되기 위해서는 빅데이터 시스템을 구축하는 것만으로 충분하지 않다. 빅데이터 시스템은 데이터 과학 활동을 효과적으로 수행할 수 있도록 돕는 도구일 뿐, 이 빅데이터 시스템을 이용해서 데이터 과학을 효과적으로 수행할 수 있는 데이터 과학자, 데이터 엔지니어가 적절하게 임무를 수행해야 금맥으로 발전시킬 수 있음을 빅데이터 프로젝트 기안자는 꼭 기억해야 한다.

사례 1의 교훈 마지막으로 데이터 레이크의 비용 대비 효과(Return on Input; ROI)에 대해서 같이 생각해보고자 한다. 

빅데이터 시대를 연 기술인 하둡(Hadoop)과 스파크(Spark)로 이미 구축되어 있는 빅데이터 데이터웨어하우스(big-data datawarehouse)를 활용하는 새로운 트렌드 용어로 데이터 레이크(Data Lake)가 한동안 많은 관심을 모았다. 데이터 레이크(Data Lake)가 화두가 된 지 꽤 되었지만 데이터 레이크(Data Lake)로 모은 데이터를 통해 눈에 띄는 효과를 보았다는 사례를 아직까지 필자는 들어보지 못했다.

데이터 레이크(Data Lake)가 필요할 만큼의 빅데이터가 정말로 사업에 필요한 중요한 자산이어서 데이터 레이크(Data Lake)를 구축하는 경우가 분명히 있을 것이다. 그렇지만, 필자가 본 사례의 상당수는 기업이 보유한 데이터 자산을 하둡(Hadoop)이나 스파크(Spark)와 같은 빅데이터 기술로 분석하기 쉽도록 한 곳으로 모으기 위해 데이터 레이크(Data Lake)를 구축하는 경우였다.

이런 이유로 데이터 레이크(Data Lake)를 구축하는 경우는 그나마 나은 경우이다. 이런 경우와 함께 빅데이터 조직의 사내 영향력과 정치적인 입지를 다지기 위해 데이터 레이크(Data Lake)를 구축하기도 한다. 빅데이터 분석과 시스템 구축, 운영을 주도하는 조직에서 전사 조직 내에서의 정치적인 입지를 다지고, 전사 데이터를 해당 조직의 영향력 아래 모두 집중시키기 위해 데이터 레이크(Data Lake)를 구축해서 우선 전사의 데이터를 무작정 데이터 레이크로 들이붓는 것이다.

이런 경우에는 CEO나 기업의 주요 경영진들이 주의할 필요가 있다. 해당 조직이 정치적인 문제를 일으킬 수 있어서라기 보다는 이렇게 구축된 데이터 레이크(Data Lake)가 중장기적으로 사업에 전혀 도움이 되지 않기 때문이다. 의사결정자들이 항상 명심해야 할 것은, 데이터 과학을 통해 해결하려고 하는 문제에 필요한 적절한 데이터와 정보를 선별하는 데 들이는 노력이 지나치게 많으면 데이터 과학의 효과를 보기 어려울 수 있다는 것이다.

빅데이터가 금맥이 될 수 있다고 해서 언제나 긍정적인 측면만 있는 것은 아니다. 데이터가 필요 이상으로 많으면 데이터 정제와 가공에 불필요한 많은 노력을 들이게 되어 정작 의미 있는 현상과 사실을 발견하는데 더 방해가 될 수도 있다. 데이터가 많을수록 데이터의 숨은 본질과 정보를 가리는 잡음도 많아진다. 

이런 잡음이 많아질수록 문제의 본질을 보는 데 더 방해가 되기 때문에 지나치게 많은 데이터, 특히 사전에 관련성이 명확하게 검토되지 않은 다양한 데이터 소스들을 무작정 한 곳으로 모으고 엮는 것은 데이터 과학자들이 문제의 본질에 집중하지 못하도록 방해가 될 수 있으므로 주의해야 한다.

필자는 데이터 레이크(Data Lake)를 구축하는 것보다는 마이크로서비스 아키텍처를 이용한 데이터소스 API와 데이터 카탈로그 서비스를 잘 갖추어 놓는 것을 고객들에게 권하는 편이다. 데이터 레이크(Data Lake)는 하둡(Hadoop) 기반으로 구축된 빅데이터 시스템에서 하둡(Hadoop)을 활용한 데이터 소스 통합과 분석을 용이하게 하기 위해 발전된 개념이다. 하둡(Hadoop)이 빅데이터 분석의 모든 경우에 반드시 유용하리라는 법도 없고, 데이터 레이크(Data Lake)로 모은 데이터가 하둡(Hadoop)이나 스파크(Spark)로 분석하기에 꼭 적합한 것도 아니다.

데이터 레이크(Data Lake)를 무겁게 구축하는 것보다는 각 부서와 사업부별로 사업을 추진하면서 얻은 데이터들이 어떤 데이터와 정보를 담고 있는지를 RESTful API 형태로 조회, 열람하여 데이터 과학자와 데이터 엔지니어들이 당면한 데이터 과학 프로젝트 수행에 필요한 적절한 데이터 소스인지 사전에 평가하기 용이하도록 데이터 카탈로그 서비스를 구축해두자. 

이렇게 하면 굳이 데이터를 데이터 레이크(Data Lake)로 억지로 모으지 않아도 데이터 과학 프로젝트에 맞는 데이터가 어디에 있는지, 어떻게 활용할 수 있는지 사전에 평가할 수 있어 시행착오를 많이 줄일 수 있다.

위와 같은 데이터 카탈로그 서비스와 함께 해당 데이터 소스의 주요 데이터를 마이크로서비스 형태로 제공할 수 있도록 API화해놓으면 굳이 데이터 레이크(Data Lake)로 통합하는 어려운 작업을 거치지 않더라도 탐색적 데이터 분석이나 다른 데이터 소스와 같이 융합(fusion)하여 수행하는 복합 데이터 분석을 수행할 때 필요한 데이터만 적절하게 추출하여 활용하기에 용이하다.

무엇보다도 이런 방법을 이용하면 데이터 소스의 소유권을 가진 사업부나 부서의 반발도 줄일 수 있어 정치적으로도 매우 용이하고 협조를 얻기도 쉽다. 데이터 레이크(Data Lake)를 구축하는 것보다 비용도 많이 줄일 수 있고 데이터 통합에 들이는 노력과 시간도 많이 절감할 수 있다.

다만 이렇게 마이크로서비스 아키텍처를 이용한 데이터 소스 API와 데이터 카탈로그 서비스를 이용해 전사 데이터 소스를 통합할 경우, 마이크로서비스 아키텍처를 지원하는 서비스 메시(service mesh)와 도커(Docker), 쿠버네티스(Kubernetes)와 같은 마이크로서비스 배치(deployment), 관리 인프라를 적절하게 운영하고 이를 이용한 사내 정보 시스템 개발을 전문적으로 수행할 수 있는 전문 인력과 소프트웨어 엔지니어들이 잘 갖춰져 있어야 한다. 

서비스 메시(service mesh)와 도커(Docker), 쿠버네티스(Kubernetes)와 같은 기술들이 하둡(Hadoop)기반 데이터 레이크(Data Lake)를 구축하는 것에 비해 기술적인 난이도가 높기 때문에 이런 점은 단점이기는 하지만, 마이크로서비스 아키텍처가 주는 장점이 대부분의 경우 이런 단점을 상쇄하는 경우가 많기 때문에 고려해 볼 만하다.

이 글의 지면이 제한되어 있어 위와 같은 마이크로서비스 아키텍처와 데이터 카탈로그를 이용한 다양한 빅데이터 소스 통합의 구체적인 방법과 전략은 여기서는 더 논의하지 않겠다. 하지만, 데이터 레이크(Data Lake)보다는 마이크로서비스 아키텍처와 데이터 카탈로그를 이용한 데이터 소스 통합이 대부분의 많은 기업들에는 더 효과적인 방법이라는 것만 한 번 더 강조하고 싶다.

사례 1의 교훈은 다음과 같이 정리하도록 하자.

교훈 1. 빅데이터 프로젝트의 목적과 기대 효과, 해결하려는 문제를 명확하게 정의하는 기획 프로젝트를 통해 빅데이터 프로젝트의 위험과 타당성을 먼저 검증하도록 하자. 이런 기획 프로젝트를 통해 파일럿 분석을 해보는 과정을 거쳐보면 대부분의 경우 빅데이터를 쌓아 활용하는 단계까지 가지 않더라도 기존의 데이터 소스를 이용해 데이터 과학만으로도 어느 정도 해결할 수 있는 문제가 많다는 사실에 깜짝 놀랄지 모른다. 

(다만, 빅데이터를 앞세워 승진과 성과를 노렸던 구성원은 빅데이터라는 말을 앞세울 수 없어 다소 실망할 수 있을지도 모르겠다. 빅데이터를 억지로 꾸역꾸역 모아 놓는 것이 중요한지, 자신이 일하는 기업과 조직의 비즈니스 성공이 중요한지는 굳이 필자가 말하지 않아도 잘 알 것이다.)

교훈 2. 데이터 과학팀이 자기 조직적인(self-organized) 문제 해결 역량을 발휘할 수 있도록 자신의 역량보다 나은 전문가들을 영입하는 것을 주저하지 않도록 하자. 정말 자신의 위치가 위협받을 것 같아 불안하다면 선발 과정에서 데이터 과학자로서 경력을 중요시하는 사람인지, 데이터 과학자는 그저 타이틀로 걸어 놓고 회사에 입사하여 조직의 위계 구조 사다리를 타고 올라 가려는 게 목적인지 잘 가려낼 수 있는 안목과 실력을 본인이 갖출 수 있도록 노력하자. 데이터 과학팀이 자기 조직적인(self-organized) 문제 해결 역량을 갖추지 못하면 그 부작용은 결국 빅데이터 프로젝트를 이끄는 리더의 부담으로 언젠가 돌아오게 된다.

교훈 3. 빅데이터 시스템을 효과적으로 구축하는 것은 경우에 따라 정말 중요하지만, 데이터 과학 프로젝트가 빅데이터 시스템 구축 프로젝트로 변질되지 않도록 주의하자. 당장의 성과를 보여주는 것도 중요하지만, 데이터 과학 자산을 꾸준히 쌓아가지 않는다면 언젠가는 좌초되게 된다. 데이터 과학은 결국 데이터 과학자, 데이터 엔지니어들, 즉 사람들이 하는 것이기 때문이다.

교훈 4. 기존 데이터를 한 곳으로 모아 분석하면 뭔가 의미 있는 게 나오겠지 식의 막연한 데이터 수집, 중앙 집중화는 데이터 과학 프로젝트의 실패 확률을 높인다. 특히, 모으려는 데이터 자산이 가지고 있는 정보의 한계와 효용에 대한 적절한 평가 없이 무작정 데이터 레이크로 데이터를 들이붓는 식의 데이터 수집은 분석해야 할 문제에 집중하기 어렵게 하고 불필요한 쓰레기 정보만 늘어나도록 하여 데이터 과학자들이 의미 있는 성과를 내기 어렵게 한다. 데이터를 무작정 모으기보다는 데이터 과학 프로젝트의 필요에 따라 데이터를 발견하고 사용하기 편하도록 빅데이터 인프라를 갖추는데 집중하는 것이 더 좋다.

사례 2: 겉도는 데이터 과학팀, 지쳐가는 데이터 과학 리더 H
한국의 대기업인 K사에 영입된 데이터 과학팀의 리더 H는 요즘 매우 스트레스를 받고 있다. 왠지 데이터 과학에 대한 회사 경영진의 관심이 진심이 아닌 듯한 생각이 자꾸 들기 때문이다. 

H는 미국에서 컴퓨터 과학과 통계학을 복수로 전공하여 기계 학습에 관한 논문으로 박사학위를 취득한 후, 요즘은 널리 알려진 실리콘밸리의 인터넷 서비스 회사 G에서 데이터 과학자로서 성공적인 경력을 쌓았다. 

H가 G사에서 경력을 시작했을 때에는 데이터 과학이라는 말이 매우 생소했을 때였으나, G사가 서비스를 통해 모아들이는 전 세계 고객 데이터는 그 어떤 회사에서도 경험해보기 힘든 귀중한 데이터들이었다. 과연 이 데이터 속에 어떤 비밀이 숨겨져 있을까 하는 호기심에 자신이 일하던 팀의 리더에게 허락을 받아 데이터 분석 시스템을 직접 만들어 3명의 동료와 데이터 분석을 시작한 것이 5년이 넘게 계속하게 되었다. H의 데이터 분석을 통해 G사는 데이터를 이용해 할 수 있는 신규서비스의 아이디어를 많이 얻어 성공적인 서비스 사업으로 발전시킬 수 있었다.
 




2021.03.29

김진철의 How-to-Big Data | 빅데이터 괴담

김진철 | CIO KR
이번 글은 필자가 지금까지 데이터 과학자로 경력을 쌓아오면서 경험했거나 듣고 읽었던 빅데이터 활용 사례들을 중심으로 빅데이터를 활용하는 과정에서 많은 조직이 흔히 저지르는 실수와 오해, 시행착오에 대해서 살펴보고, 이를 어떻게 개선할 수 있을지 같이 생각해보기로 한다.

소개하는 사례들은 실제 사례들이 아니라 필자가 경험했거나 들은 사례들을 각색하여 만든 가상의 사례들이며, 필자가 전달하고자 하는 메시지를 부각하기 위해 조금 과장했음을 미리 알려 둔다. 지금까지 같이 생각해봤던 빅데이터 활용의 교훈을 되새기고 독자들의 시행착오를 줄이는 것을 돕기 위해 만들 사례들이니 사실이 아닌 것을 염두에 주고 가볍고 즐겁게 읽었으면 좋겠다.
 
ⓒGetty Images


사례 1: 데이터 호수가 너무 넓어서 ROI가 나지 않아 곤란한 A 기업의 CIO 이야기
많은 사람에게 널리 알려진 A 회사에서 빅데이터를 앞세워 승승장구한 C는 요즘 고민이 많다. 문제는 바로 그에게 회사에서 승승장구한 경력을 만들어준 데이터 레이크 시스템 때문이다.

C는 2011년도 빅데이터 붐이 일기 시작할 즈음 승진을 위한 기획 아이템으로 뭘 앞세울까 고민하다가 그 당시 막 떠오르고 있던 빅데이터를 앞세워서 A 회사에 하둡 기반의 빅데이터 시스템을 구축하는 기획안을 만들어 임원의 승인을 받는 데 성공했다. 

당시 NexR과 같이 오픈소스 하둡을 기반으로 빅데이터 솔루션을 상용화하는 스타트업이 막 등장하고 있었다. 이런 스타트업 중에서 괜찮은 회사 하나를 잘 골라서 같이 일하면서 키우면 자신의 승진에 많이 도움이 될 것 같았다. 운이 좋다면 자신의 직속 임원이 이 스타트업을 인수, 합병하여 사업 성과를 낼 수 있도록 하면서 그 회사의 고급 소프트웨어 엔지니어들을 자연스럽게 회사로 영입하여 자신의 세력으로 키울 수 있을 것 같았다.

C는 당시 하둡 기반 빅데이터 스타트업으로서 같이 하둡 시스템 구축 사업을 수행한 D사를 잘 활용하여 예상보다 빠르게 하둡 시스템을 안정적으로 구축할 수 있었다. 이후 프로젝트를 승인해준 임원의 지원으로 빅데이터 시스템을 성공적으로 구축하여 회사가 빅데이터 활용에서 앞서 나갈 수 있게 했다는 공로를 인정받아 승진하여 A사의 빅데이터 그룹을 총괄하는 그룹장이 되었다. A사에서 빅데이터 분야의 전문가로 인정받아 계속해서 승승장구할 수 있을 것 같았다.

그룹장 승진 후 요즘은 데이터가 금맥이라는 세간의 말을 A사의 대표 이사가 회의 석상에서 C에게 자주 읊기 시작했다. 이제 데이터를 많이 모았을 테니 빨리 회사의 수익에 도움이 될 만한 데이터 분석 결과를 보고 싶다는 대표 이사의 은근한 압박은 처음에는 빅데이터 전문가라는 자신감과 승진의 기쁨으로 크게 걱정이 되는 일이 아니었으나, 시간이 지날수록 데이터 분석에서 원래 생각했던 “제대로 된 한 건”이 나오지 않으면서 점차 부담이 커지기 시작했다.

자신보다 학력도 높고 소위 업계 전문가라는 데이터 과학자들을 꽤 많이 채용해서 데이터 과학팀을 운영하고 있었지만, 어찌 된 이유인지 데이터 분석 결과가 영 신통치 않았다. 성과가 전혀 없는 것은 아니었다. 확인되지는 않았지만 회사를 경영하는 과정에서 어렴풋하게 얻었던 직관적인 지식이 데이터로 사실임이 확인된 것들도 꽤 많았다. 그렇지만, 회사의 수익을 크게 개선시켜 줄 만큼 눈에 띄는 성과로 이어질 것 같은 분석 결과는 나오지 않았다.

그룹장 승진 후 3년이 지날 때까지 데이터 분석으로 눈에 띄는 성과가 나지 않자, C는 임원 승진을 위한 또 하나의 승부수를 띄우기로 했다. 당시 막 유행하기 시작했던 “데이터 레이크(Data Lake)”를 하둡을 기반으로 구축하고, 현재 자신을 지원하고 있는 임원의 정치적 영향력을 이용해 전사의 데이터가 모두 이 데이터 레이크에 모이게끔 해서 모든 데이터에 대한 관리 권한을 자신에게 집중시키려는 것이었다.

전사 사업부들의 반발이 왠지 심할 수도 있을 것 같다는 생각이 들었지만, 대표 이사를 설득해서 일단 데이터 레이크로 모든 데이터를 모을 수만 있으면 그토록 바라던 데이터 분석 한방도 노릴 수 있을 것 같았다. C는 대표 이사에게 지금까지 데이터 분석 결과가 회사 수익에 눈에 띄지 않게 도움이 되지 않았던 것은 전사의 데이터를 현재 사업 운영 데이터와 같이 분석하지 않기 때문이라고 설득해서 데이터 레이크 구축을 위한 예산과 인력을 추가로 받는 데 성공했다.

A사의 빅데이터 프로젝트는 이제 데이터 레이크 구축 프로젝트로 바뀌었고, 각 사업부의 모든 데이터를 새로 구축한 데이터 레이크로 모으라는 C의 요청과 협조하라는 대표 이사의 지시에 전사 사업부들의 반발이 예상대로 이어졌다. 그렇지만, 대표이사의 지원으로 각 부서의 협조를 얻어서 일단 데이터 레이크로 데이터를 모으는 시스템을 구축하는 데 성공했다. 전사의 데이터를 속속들이 모으기 시작했으니 똑똑한 데이터 과학자들만 채근하면 이제 기대하던 데이터 분석 한방을 얻는 것은 시간문제일 것 같았다.

데이터 레이크 구축 후 속속 각 사업부의 사업 운영 데이터를 저장하는 데이터베이스와 비정형 데이터들이 데이터 레이크로 수집되기 시작했고, 데이터 과학팀의 데이터 과학자들이 다양한 분석을 시작했지만 여전히 신통한 결과를 보이지 않았다. 데이터 레이크가 구축되어 전사 데이터를 수집하고 분석한 지 3년이 지나기 시작했지만 데이터 레이크를 구축하기 전과 크게 상황이 달라지지 않았다.

뚜렷한 데이터 분석 성과가 6년이 되도록 보이지 않자 대표 이사는 이제는 임원이 된 C에게 노골적으로 불만을 내비치기 시작했다. C는 임원으로 승진한 지 2년이 넘어 계약 만료가 얼마 남지 않았는데, 대표이사가 이번에도 본인을 신뢰해줄지 왠지 자신이 없었다. 더군다나, A사의 지주사인 그룹의 E 회사에서 곧 A사의 대표이사를 새로 선임할 것이라고 하는데, 왠지 새 대표이사가 현재의 빅데이터 그룹장 자리에 본인을 계속 둘 것인지도 알 수 없었다.

이에 더해서 데이터가 점점 수집되다 보니 데이터 레이크 시스템의 꾸준한 증설이 필요했고, 전사의 데이터가 늘어나고 축적되다 보니 해가 갈수록 시스템 증설과 운영에 필요한 비용이 점차 늘어나기 시작했다. 데이터 분석의 성과가 생각보다 신통치 않자 대표이사가 C가 신청하는 데이터 레이크 시스템 증설, 운영 비용에 대해서 재검토하라는 지시를 하였고, 늘어나는 데이터에 비해 예산이 모자라 데이터 레이크 시스템 유지가 어려워지기 시작했다.

데이터 과학팀의 데이터 과학자들의 회의에서 좀 의미 있는 데이터 분석 결과를 만들어 달라고 계속 채근하지만, 데이터 과학자들은 불만 섞인 목소리로 노력하고 있다고만 답할 뿐이다. C의 인내심이 한계에 이른 어느 날 데이터 과학팀 회의 시간에 데이터 과학자들에게 내가 데이터 레이크도 잘 만들어주고 데이터도 다 모아 줬는데 왜 분석을 제대로 못 하는 거냐고 호통을 쳤다.

데이터 과학자들이 분석, 검토해야 할 데이터의 양이 너무 많이 늘어나서, 이 중에서 관련이 있는 정보들을 찾아내기 위한 데이터 정제, 전처리 작업에 드는 시간이 너무 많아 정작 부서 데이터 간 교차 분석을 할 수 있는 시간이 많이 부족하다고 설명했으나 C의 눈에는 이 모든 것들이 변명처럼 보여 화만 계속 났다.

이 일이 있고 난 이후로 데이터 과학팀을 떠나 부서를 이동하거나 이직을 하는 데이터 과학자들이 점점 늘어나기 시작했다. 안 그래도 임원들 사이에서 데이터 레이크가 돈 잡아먹는 하마로 말이 돌기 시작하는 때에 데이터 분석 성과를 내어주어야 할 데이터 과학자들까지 떠나고 있으니 대표이사에게 안 좋은 인상을 줄 것이 분명했다.

결국 C는 그해 정기 임원 인사에서 밀려나 회사를 나와야 했다. 다행히 회사에서 밀려나기 전에 헤드헌터의 연락을 받아 G사에 신설되는 빅데이터 본부의 본부장 자리를 제안받았고, A사에서 빅데이터 그룹장으로 일했던 경력을 인정받아 빅데이터를 활용하고 싶어 하던 G사의 빅데이터 본부 본부장으로 이직하는 데 성공했다.

이직에 성공하기는 했지만, A사에서 있던 동안 빅데이터 프로젝트를 진행하면서 왜 기대했던 성과가 나오지 않았는지 아직도 이해할 수 없었다. 일단은 지난 7년간 A사에서 빅데이터라는 말로 승승장구했던 방식을 다시 써먹으면서 이직한 G사에서도 당분간 버텨볼 생각이다. 

하지만, 뭔가 문제가 있다는 생각이 계속해서 들었고 그게 뭔지 알 수 없어 답답했다. G사에서도 비슷한 방식으로 7년 정도 버티다가 또 적당한 때에 이직을 해볼까하는 생각도 든다. 그것도 나쁘지 않겠지만, 최근 빅데이터 분야에서 더 이상 하둡이 떠오르는 말이 아닌 것이 마음에 걸린다. 스파크(Spark)니, 플링크(Flink)니 새로운 빅데이터 기술이 나온 것도 모자라 이제는 데이터 가공 파이프라인도 자산화해야 하고 에어플로우(Airflow) 같은 새로운 데이터 가공 파이프라인 기술도 써야 한다고 한다.

G사에서 빅데이터 프로젝트를 축포를 터뜨리면서 시작하는 날, C는 자신의 앞날이 어떻게 될지 막연한 불안감이 앞섰다. 뭐가 문제였고 어떻게 해야 할까? 데이터만 모아서 분석만 하면 회사 수익이 쑥쑥 크는 중요한 정보가 쏟아져 나올 것 같았는데, 이번에도 비슷한 상황이면 어떻게 하지라는 걱정이 앞서기 시작했다. C는 이런 고민으로 불면증과 스트레스에 시달리면서 오늘도 불안한 회사 생활을 계속하고 있다.

사례 1의 교훈
지금 소개한 사례 1과 같은 경우가 빅데이터 붐이 인 지난 2011년부터 지금까지 필자가 가장 많이 보아온 경우다. 대개의 경우 기업의 내부 구성원이 승진과 성과를 위한 프로젝트로써 트렌드 분석을 하다가 빅데이터에 관한 자료를 읽게 되고, 빅데이터라는 말을 앞세워서 빅데이터 기술의 대표 격인 하둡(Hadoop)을 이용한 데이터 분석 시스템 구축을 기획, 실행하면서 빅데이터 프로젝트가 시작된다.

이렇게 시작된 빅데이터 프로젝트는 데이터 분석이 왜 필요하고, 현재 기업의 사업과 현안에 어떤 효용이 있으며, 데이터 분석을 통해서 뭘 얻고자 하고, 데이터 분석이 기업의 비즈니스 모델과 어떤 관계가 있는지 구체적이고 실질적인 분석과 고민이 없이 시작하게 된다. 

이렇게 시작되다 보니 겉으로는 빅데이터 프로젝트라는 거창한 이름으로 시작하지만 기업의 비즈니스 모델과 정렬되어 효용이 정의되지 않고, 기업의 어떤 필요에 부응하게 될 것인지 분명하지 않은 상태에서 하둡(Hadoop)과 같은 데이터 처리, 분석용 분산 컴퓨팅 시스템을 구축하는 시스템 통합 프로젝트로 진행되게 된다.

위와 같은 과정을 통해 시스템 통합 프로젝트로 하둡(Hadoop) 시스템을 구축하기는 하지만, 기업의 비즈니스 모델과 연계되지도 않았고 분석할 데이터가 당장 모이지도 않기 때문에, 프로젝트가 끝나게 되면 하둡(Hadoop) 클러스터 하나만 덩그러니 남게 되고 경영진을 통한 많은 구성원이 이제 뭘 해야 할지 고민하기 시작한다.

우선 분석할 데이터를 모아야 하기 때문에 사내에 있는 데이터를 이리저리 끌어다가 하둡(Hadoop) 시스템에 적재하는 일부터 진행하게 된다. 여기까지는 그럴 수 있다고 하지만, 문제는 들이는 노력에 비해서 효과가 크지 않다는 것이다. 사내에 있는 데이터 대부분이 관계형 데이터베이스에 저장된 테이블 형태의 데이터이거나 그렇지 않으면 마이크로소프트 엑셀(Excel)과 같은 형태의 정형 데이터가 우선 눈에 띄게 된다.

이런 데이터베이스 및 정형 데이터를 먼저 끌어다가 ETL 도구와 데이터 정제, 마이그레이션을 위한 솔루션 업체나 용역 업체를 통해서 하둡(Hadoop) 시스템으로 데이터를 옮기기 시작한다. 그다음, 하둡(Hadoop) 생태계에서 쓰이는 데이터 분석 소프트웨어인 HBase나 Hive, Impala와 같은 소프트웨어들을 이용해 데이터를 분석하기 시작한다.

여기까지도 기업에서는 빅데이터 활용을 시작했다는 자부심과 기대감으로 빅데이터 프로젝트에 투자와 지원을 하며, 해당 프로젝트를 기획하고 추진한 구성원은 승진과 같은 보상을 받고, 이와 함께 그 구성원의 프로젝트를 후원하는 임원과 리더들이 같이 승진하면서 사내에서 점점 주목받는 프로젝트로 성장하게 된다.

문제는 이 다음부터 일어난다. 데이터 과학자와 데이터 엔지니어도 열심히 채용해서 데이터 분석을 시키고, 사내에 있는 데이터 소스들을 모두 모아 하둡(Hadoop) 기반의 빅데이터 분석 시스템과 데이터 레이크에 연동하여 데이터를 열심히 모아 쌓지만, 정작 이들 데이터를 열심히 분석해보면 실제 사업화하거나 사업에 크게 도움이 될 수 있는 지식과 통찰을 얻기가 의외로 쉽지 않다는 것을 알게 된다.

이렇게 데이터 분석을 통해서 성과를 내기가 쉽지 않다 보니 다시 기존의 데이터 분석 시스템을 새로운 빅데이터 기술을 들여와 업그레이드하거나, 기존의 빅데이터 시스템을 데이터 레이크로 전환하는 것과 같은 새로운 트렌드 용어를 이용한 정보 시스템 구축 프로젝트로 바꾸어 예산을 받고 성과를 내는 일이 반복된다. 

이렇게 정말 중요한 데이터 과학 업무를 수행하지 않고 예산과 시간의 대부분을 눈에 보이는 성과를 낼 수 있는 빅데이터 정보 시스템 구축 프로젝트 위주로 빅데이터 프로젝트가 돌아가기 시작하면서 데이터 과학을 활용할 수 있는 환경과 무형적 자산을 쌓는 데 소홀하게 돼 데이터 과학의 활용이 더디어지게 된다.

빅데이터 시스템은 구축을 해 놓는다고 해서 자동으로 기업의 비즈니스를 위한 통찰과 지식이 쏟아져 나오는 것이 아니다. 데이터 과학자들이 이 빅데이터 시스템을 잘 이용해서 다루기 어려운 빅데이터들을 효과적으로 다루고 이들을 사업 기획과 운영에 활용할 수 있는 지식과 통찰로 바꾸고 정제해주어야 쓸모가 있는 것이다. 

이런 데이터 과학 활동을 통해 쌓인 소프트웨어들이 쌓이고 모여 자동화된 분석 시스템과 데이터 가시화, 큐레이션 시스템으로 발전해갈 때 비로소 빅데이터 시스템이 자동으로 기업의 비즈니스에 부가가치를 만들어 내기 시작하는 것이다.

데이터 과학자들을 뽑는 과정에서도 필자는 많은 문제점을 확인할 수 있었다. 대개 이런 식으로 기업의 내부 구성원이 자신의 승진과 성과를 위해 빅데이터 프로젝트를 시작하게 된 경우는 해당 구성원이 계속해서 주도권을 쥐고 리더의 역할을 하기를 원하는 경우가 많다. 이런 상황에서는 앞의 사례에서 소개한 것과 같은 시행착오를 겪으면서 본인의 역량을 외부에서 데이터 과학자들을 영입해서 해결하려고 하게 된다.

문제는 데이터 과학자들이 자기조직적으로 능동적으로 팀워크를 발휘할 수 있도록 주니어 데이터 과학자, 시니어 데이터 과학자, 리더급 데이터 과학자를 적절하게 선발해서 지원해주어야 하는데 주니어 데이터 과학자 위주로 편향되어 선발한다는 것이다. 

대개의 경우 기존 빅데이터 프로젝트를 시작한 구성원보다 높은 학력과 경력을 가지고 있는 전문가들이 데이터 과학자로서 검토 대상이 되는 경우가 많기 때문에, 빅데이터 프로젝트를 시작한 내부 구성원은 자신의 승진과 이해관계 때문에 주니어 데이터 과학자 위주로 데이터 과학자들을 영입하게 된다.

이렇게 되면서, 이들이 적절한 데이터 분석 과제를 찾고 문제 해결을 해나갈 수 있도록 지도하고 이끌어갈 수 있는 시니어 데이터 과학자, 리더급 데이터 과학자가 영입되지 않아 데이터 과학팀이 자기조직적으로, 자기 스스로 목표 설정을 하고 움직이는 자율적인 팀이 되기보다는 빅데이터 프로젝트를 리드하고 있는 내부 구성원 리더의 통제를 받는 조직으로 바뀌게 된다. 

이런 경우 내부 구성원이 데이터 과학을 혼자서 익혀서라도 제대로 수행한다면 문제가 없지만 대개의 경우 데이터 과학을 이용해 문제를 직접 해결해본 경험이나 역량이 부족한 경우가 많기 때문에 데이터 과학팀이 자율적인 문제 해결 역량을 발휘하지 못하고 사업 경험을 통해 쌓은 경험적인 사실들만 데이터를 통해 다시 확인하는 과정만 반복하게 된다.

이렇게 데이터 과학팀이 본연의 역할을 하지 못하게 되면 빅데이터 시스템과 데이터 과학자 영입에 투자하면서 회사 사업의 성장을 기대했던 대표 이사를 포함한 경영진들은 데이터 과학팀과 빅데이터 프로젝트팀에 성과 독촉을 하기 시작한다. 

이 때문에 초조해진 데이터 과학팀과 빅데이터 프로젝트 리더들이 데이터 과학자와 데이터 엔지니어들에게 성과 독촉을 하는 악순환에 빠지게 되면서 어렵게 영입한 데이터 과학자들이 조직을 떠나게 되고, 이 때문에 데이터 과학팀의 역량과 데이터 과학 추진 의지가 약해지게 된다.

이렇게 나타나는 데이터 과학자의 영입과 데이터 과학팀의 운영 과정에서 생기는 문제와 함께, 일반 기업에서 데이터 과학을 잘 활용하지 못하는 또 하나의 중요한 이유는 보유한 데이터가 가지는 정보의 한계를 적절하게 평가하지 않고 무작정 데이터 분석부터 시작하는 것이다.

이미 보유한 데이터들, 특히 데이터베이스 테이블로 정의, 축적된 정형 데이터들은, 이들 정형 데이터들을 수집하기 위한 데이터베이스 스키마가 모델링, 정의되는 시점의 필요에 맞게 정의되어 수집되었기 때문에 이 필요에 맞는 정보만을 담고 있다. 

물론 이 정보가 다른 데이터가 가진 정보와 같이 분석되어 지금까지 미처 파악하지 못하고 있던 사실과 통찰을 발견할 수 있는 가능성이 없지는 않다. 그렇지만, 이렇게 긍정적인 상황인지 여부도 데이터 과학자들이 기존에 수집된 데이터 사이의 관계와 관련성에 대해서 많은 노력을 들여 분석, 검토, 해석을 해봐야 알 수 있는 것이다.

그런데, 데이터 과학 프로젝트 사례들을 보면 이렇게 분석의 대상으로 삼는 정형 데이터들이 지금 풀려는 문제와 관련된 정보를 어느 정도로 담고 있고, 이 정보가 얼마나 쓸모가 있는지 적절하게 평가하는 과정이 없이 무작정 탐색적 데이터 분석부터 시작하는 경우가 많다. 기존에 가진 데이터 자산이 가진 정보와 효용에 대한 사전 평가 없이 하는 탐색적 데이터 분석은 노력에 비해 얻는 것이 많지 않고 낭비도 심한 경우가 많다.

비정형 데이터의 경우, 정형 데이터와 같이 데이터가 가진 정보의 수준과 효용에 대한 평가를 체계적으로 하기 어렵기 때문에 쉽지 않을 수는 있다. 그렇다고 하더라도 지금 해결하려고 하는 문제와 관련이 있는지, 원하는 정보를 충분히 얻을 수 있을지 사전에 검토, 확인하고 시작하는 것이 데이터 분석 과정의 시행착오를 줄이는 데 도움이 된다.

이렇게 이미 보유한 데이터 자산을 기초로 하여 시작하는 데이터 과학 프로젝트에서 이미 수집된 데이터가 가진 정보와 효용을 평가하는 과정은, 데이터 과학 프로젝트 착수 전의 기획 과정에서 이 프로젝트에서 어떤 문제를 해결하고, 어떤 사업상의 효과를 기대하는지 명확하게 분석, 정의되었을 때 그 효과가 더 커진다. 

막연하게 하둡(Hadoop) 클러스터와 같은 빅데이터 시스템을 구축하는 프로젝트로 시작하는 것보다 지금 데이터 과학을 이용해 해결하고자 하는 비즈니스 문제가 무엇인지, 왜 데이터 분석이 필요한지, 데이터 분석 과정을 통해 어떤 정보를 얻어야 하고 어떤 사업상의 효용을 기대해야 하는지, 사전에 가능하면 구체적으로 기획, 디자인하고 시작해야 데이터 과학의 효용을 비로소 경험할 수 있다.

데이터 과학 활동이 진정한 비즈니스 금맥이 되기 위해서는 빅데이터 시스템을 구축하는 것만으로 충분하지 않다. 빅데이터 시스템은 데이터 과학 활동을 효과적으로 수행할 수 있도록 돕는 도구일 뿐, 이 빅데이터 시스템을 이용해서 데이터 과학을 효과적으로 수행할 수 있는 데이터 과학자, 데이터 엔지니어가 적절하게 임무를 수행해야 금맥으로 발전시킬 수 있음을 빅데이터 프로젝트 기안자는 꼭 기억해야 한다.

사례 1의 교훈 마지막으로 데이터 레이크의 비용 대비 효과(Return on Input; ROI)에 대해서 같이 생각해보고자 한다. 

빅데이터 시대를 연 기술인 하둡(Hadoop)과 스파크(Spark)로 이미 구축되어 있는 빅데이터 데이터웨어하우스(big-data datawarehouse)를 활용하는 새로운 트렌드 용어로 데이터 레이크(Data Lake)가 한동안 많은 관심을 모았다. 데이터 레이크(Data Lake)가 화두가 된 지 꽤 되었지만 데이터 레이크(Data Lake)로 모은 데이터를 통해 눈에 띄는 효과를 보았다는 사례를 아직까지 필자는 들어보지 못했다.

데이터 레이크(Data Lake)가 필요할 만큼의 빅데이터가 정말로 사업에 필요한 중요한 자산이어서 데이터 레이크(Data Lake)를 구축하는 경우가 분명히 있을 것이다. 그렇지만, 필자가 본 사례의 상당수는 기업이 보유한 데이터 자산을 하둡(Hadoop)이나 스파크(Spark)와 같은 빅데이터 기술로 분석하기 쉽도록 한 곳으로 모으기 위해 데이터 레이크(Data Lake)를 구축하는 경우였다.

이런 이유로 데이터 레이크(Data Lake)를 구축하는 경우는 그나마 나은 경우이다. 이런 경우와 함께 빅데이터 조직의 사내 영향력과 정치적인 입지를 다지기 위해 데이터 레이크(Data Lake)를 구축하기도 한다. 빅데이터 분석과 시스템 구축, 운영을 주도하는 조직에서 전사 조직 내에서의 정치적인 입지를 다지고, 전사 데이터를 해당 조직의 영향력 아래 모두 집중시키기 위해 데이터 레이크(Data Lake)를 구축해서 우선 전사의 데이터를 무작정 데이터 레이크로 들이붓는 것이다.

이런 경우에는 CEO나 기업의 주요 경영진들이 주의할 필요가 있다. 해당 조직이 정치적인 문제를 일으킬 수 있어서라기 보다는 이렇게 구축된 데이터 레이크(Data Lake)가 중장기적으로 사업에 전혀 도움이 되지 않기 때문이다. 의사결정자들이 항상 명심해야 할 것은, 데이터 과학을 통해 해결하려고 하는 문제에 필요한 적절한 데이터와 정보를 선별하는 데 들이는 노력이 지나치게 많으면 데이터 과학의 효과를 보기 어려울 수 있다는 것이다.

빅데이터가 금맥이 될 수 있다고 해서 언제나 긍정적인 측면만 있는 것은 아니다. 데이터가 필요 이상으로 많으면 데이터 정제와 가공에 불필요한 많은 노력을 들이게 되어 정작 의미 있는 현상과 사실을 발견하는데 더 방해가 될 수도 있다. 데이터가 많을수록 데이터의 숨은 본질과 정보를 가리는 잡음도 많아진다. 

이런 잡음이 많아질수록 문제의 본질을 보는 데 더 방해가 되기 때문에 지나치게 많은 데이터, 특히 사전에 관련성이 명확하게 검토되지 않은 다양한 데이터 소스들을 무작정 한 곳으로 모으고 엮는 것은 데이터 과학자들이 문제의 본질에 집중하지 못하도록 방해가 될 수 있으므로 주의해야 한다.

필자는 데이터 레이크(Data Lake)를 구축하는 것보다는 마이크로서비스 아키텍처를 이용한 데이터소스 API와 데이터 카탈로그 서비스를 잘 갖추어 놓는 것을 고객들에게 권하는 편이다. 데이터 레이크(Data Lake)는 하둡(Hadoop) 기반으로 구축된 빅데이터 시스템에서 하둡(Hadoop)을 활용한 데이터 소스 통합과 분석을 용이하게 하기 위해 발전된 개념이다. 하둡(Hadoop)이 빅데이터 분석의 모든 경우에 반드시 유용하리라는 법도 없고, 데이터 레이크(Data Lake)로 모은 데이터가 하둡(Hadoop)이나 스파크(Spark)로 분석하기에 꼭 적합한 것도 아니다.

데이터 레이크(Data Lake)를 무겁게 구축하는 것보다는 각 부서와 사업부별로 사업을 추진하면서 얻은 데이터들이 어떤 데이터와 정보를 담고 있는지를 RESTful API 형태로 조회, 열람하여 데이터 과학자와 데이터 엔지니어들이 당면한 데이터 과학 프로젝트 수행에 필요한 적절한 데이터 소스인지 사전에 평가하기 용이하도록 데이터 카탈로그 서비스를 구축해두자. 

이렇게 하면 굳이 데이터를 데이터 레이크(Data Lake)로 억지로 모으지 않아도 데이터 과학 프로젝트에 맞는 데이터가 어디에 있는지, 어떻게 활용할 수 있는지 사전에 평가할 수 있어 시행착오를 많이 줄일 수 있다.

위와 같은 데이터 카탈로그 서비스와 함께 해당 데이터 소스의 주요 데이터를 마이크로서비스 형태로 제공할 수 있도록 API화해놓으면 굳이 데이터 레이크(Data Lake)로 통합하는 어려운 작업을 거치지 않더라도 탐색적 데이터 분석이나 다른 데이터 소스와 같이 융합(fusion)하여 수행하는 복합 데이터 분석을 수행할 때 필요한 데이터만 적절하게 추출하여 활용하기에 용이하다.

무엇보다도 이런 방법을 이용하면 데이터 소스의 소유권을 가진 사업부나 부서의 반발도 줄일 수 있어 정치적으로도 매우 용이하고 협조를 얻기도 쉽다. 데이터 레이크(Data Lake)를 구축하는 것보다 비용도 많이 줄일 수 있고 데이터 통합에 들이는 노력과 시간도 많이 절감할 수 있다.

다만 이렇게 마이크로서비스 아키텍처를 이용한 데이터 소스 API와 데이터 카탈로그 서비스를 이용해 전사 데이터 소스를 통합할 경우, 마이크로서비스 아키텍처를 지원하는 서비스 메시(service mesh)와 도커(Docker), 쿠버네티스(Kubernetes)와 같은 마이크로서비스 배치(deployment), 관리 인프라를 적절하게 운영하고 이를 이용한 사내 정보 시스템 개발을 전문적으로 수행할 수 있는 전문 인력과 소프트웨어 엔지니어들이 잘 갖춰져 있어야 한다. 

서비스 메시(service mesh)와 도커(Docker), 쿠버네티스(Kubernetes)와 같은 기술들이 하둡(Hadoop)기반 데이터 레이크(Data Lake)를 구축하는 것에 비해 기술적인 난이도가 높기 때문에 이런 점은 단점이기는 하지만, 마이크로서비스 아키텍처가 주는 장점이 대부분의 경우 이런 단점을 상쇄하는 경우가 많기 때문에 고려해 볼 만하다.

이 글의 지면이 제한되어 있어 위와 같은 마이크로서비스 아키텍처와 데이터 카탈로그를 이용한 다양한 빅데이터 소스 통합의 구체적인 방법과 전략은 여기서는 더 논의하지 않겠다. 하지만, 데이터 레이크(Data Lake)보다는 마이크로서비스 아키텍처와 데이터 카탈로그를 이용한 데이터 소스 통합이 대부분의 많은 기업들에는 더 효과적인 방법이라는 것만 한 번 더 강조하고 싶다.

사례 1의 교훈은 다음과 같이 정리하도록 하자.

교훈 1. 빅데이터 프로젝트의 목적과 기대 효과, 해결하려는 문제를 명확하게 정의하는 기획 프로젝트를 통해 빅데이터 프로젝트의 위험과 타당성을 먼저 검증하도록 하자. 이런 기획 프로젝트를 통해 파일럿 분석을 해보는 과정을 거쳐보면 대부분의 경우 빅데이터를 쌓아 활용하는 단계까지 가지 않더라도 기존의 데이터 소스를 이용해 데이터 과학만으로도 어느 정도 해결할 수 있는 문제가 많다는 사실에 깜짝 놀랄지 모른다. 

(다만, 빅데이터를 앞세워 승진과 성과를 노렸던 구성원은 빅데이터라는 말을 앞세울 수 없어 다소 실망할 수 있을지도 모르겠다. 빅데이터를 억지로 꾸역꾸역 모아 놓는 것이 중요한지, 자신이 일하는 기업과 조직의 비즈니스 성공이 중요한지는 굳이 필자가 말하지 않아도 잘 알 것이다.)

교훈 2. 데이터 과학팀이 자기 조직적인(self-organized) 문제 해결 역량을 발휘할 수 있도록 자신의 역량보다 나은 전문가들을 영입하는 것을 주저하지 않도록 하자. 정말 자신의 위치가 위협받을 것 같아 불안하다면 선발 과정에서 데이터 과학자로서 경력을 중요시하는 사람인지, 데이터 과학자는 그저 타이틀로 걸어 놓고 회사에 입사하여 조직의 위계 구조 사다리를 타고 올라 가려는 게 목적인지 잘 가려낼 수 있는 안목과 실력을 본인이 갖출 수 있도록 노력하자. 데이터 과학팀이 자기 조직적인(self-organized) 문제 해결 역량을 갖추지 못하면 그 부작용은 결국 빅데이터 프로젝트를 이끄는 리더의 부담으로 언젠가 돌아오게 된다.

교훈 3. 빅데이터 시스템을 효과적으로 구축하는 것은 경우에 따라 정말 중요하지만, 데이터 과학 프로젝트가 빅데이터 시스템 구축 프로젝트로 변질되지 않도록 주의하자. 당장의 성과를 보여주는 것도 중요하지만, 데이터 과학 자산을 꾸준히 쌓아가지 않는다면 언젠가는 좌초되게 된다. 데이터 과학은 결국 데이터 과학자, 데이터 엔지니어들, 즉 사람들이 하는 것이기 때문이다.

교훈 4. 기존 데이터를 한 곳으로 모아 분석하면 뭔가 의미 있는 게 나오겠지 식의 막연한 데이터 수집, 중앙 집중화는 데이터 과학 프로젝트의 실패 확률을 높인다. 특히, 모으려는 데이터 자산이 가지고 있는 정보의 한계와 효용에 대한 적절한 평가 없이 무작정 데이터 레이크로 데이터를 들이붓는 식의 데이터 수집은 분석해야 할 문제에 집중하기 어렵게 하고 불필요한 쓰레기 정보만 늘어나도록 하여 데이터 과학자들이 의미 있는 성과를 내기 어렵게 한다. 데이터를 무작정 모으기보다는 데이터 과학 프로젝트의 필요에 따라 데이터를 발견하고 사용하기 편하도록 빅데이터 인프라를 갖추는데 집중하는 것이 더 좋다.

사례 2: 겉도는 데이터 과학팀, 지쳐가는 데이터 과학 리더 H
한국의 대기업인 K사에 영입된 데이터 과학팀의 리더 H는 요즘 매우 스트레스를 받고 있다. 왠지 데이터 과학에 대한 회사 경영진의 관심이 진심이 아닌 듯한 생각이 자꾸 들기 때문이다. 

H는 미국에서 컴퓨터 과학과 통계학을 복수로 전공하여 기계 학습에 관한 논문으로 박사학위를 취득한 후, 요즘은 널리 알려진 실리콘밸리의 인터넷 서비스 회사 G에서 데이터 과학자로서 성공적인 경력을 쌓았다. 

H가 G사에서 경력을 시작했을 때에는 데이터 과학이라는 말이 매우 생소했을 때였으나, G사가 서비스를 통해 모아들이는 전 세계 고객 데이터는 그 어떤 회사에서도 경험해보기 힘든 귀중한 데이터들이었다. 과연 이 데이터 속에 어떤 비밀이 숨겨져 있을까 하는 호기심에 자신이 일하던 팀의 리더에게 허락을 받아 데이터 분석 시스템을 직접 만들어 3명의 동료와 데이터 분석을 시작한 것이 5년이 넘게 계속하게 되었다. H의 데이터 분석을 통해 G사는 데이터를 이용해 할 수 있는 신규서비스의 아이디어를 많이 얻어 성공적인 서비스 사업으로 발전시킬 수 있었다.
 


X