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

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

사례 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사는 데이터를 이용해 할 수 있는 신규서비스의 아이디어를 많이 얻어 성공적인 서비스 사업으로 발전시킬 수 있었다.

이렇게 G사에서 데이터 분석을 통해 얻은 아이디어로 G사의 매출 성장에 크게 기여한 H는 팀의 리더, 동료와 함께 그 공로를 인정받아 승진의 승진을 거듭하고 결국 G사에 데이터 과학 본부를 만들어 초대 본부장까지 역임하게 된다.

G사에서 이렇게 성공적인 경력을 쌓던 H는 어느 날, 한국의 유명 기업인 K사에서 데이터 과학 부서를 신설하니 K사에서 데이터 과학 부서를 성장시킬 수 있는 리더로서 역할을 해달라는 제안을 K사 빅데이터 본부 P본부장에게 받는다. 

K사는 인터넷 서비스사가 아닌 제조업을 하는 회사라 과연 소프트웨어 마인드로 유연하게 일을 할 수 있을까라는 의구심이 들었지만, K사 빅데이터 본부장과 인사관리 임원의 적극적인 설득, 그리고 제안된 파격적인 처우에 결국 한국에서 한번 경력을 쌓아 보기로 하고 K사 빅데이터 본부 데이터 과학팀 리더로서 K사의 임원으로 합류하게 된다.

K사에서 데이터 과학에 보이는 놀라운 관심에 H는 크게 놀랄 수밖에 없었다. 사실 G사에서 데이터 과학을 시작한 것은 본인의 호기심과 잘 따라준 행운, 자신이 잠재력을 잘 발휘할 수 있도록 배려해준 팀 리더와 뛰어난 동료들의 역할이 컸다고 생각하고 있었다. 

G사에서 데이터 분석을 시작할 때에는 데이터 과학이라는 말이 실리콘밸리에서조차 매우 생소했을 때였기 때문에 회사에서 이렇게까지 관심을 보이지는 않았다. 업무 외 여분 시간에 스컹크워크 프로젝트로 시작한 것이 의외로 큰 성과를 내어 회사의 정식 업무가 되었던 것이라 K사에서 빅데이터 본부에 보내는 전폭적인 지지가 매우 놀랍기도 했고, 왠지 H 본인이 일하는 데에도 크게 도움이 될 것 같았다.

K사에 합류했을 때 데이터 과학팀이 이미 조직되어 있었고, 소속된 팀원들 대부분이 이미 회사에서 소프트웨어 개발 업무를 하던 구성원 중에서 데이터 분석에 관심이 있는 구성원을 특별히 선발해서 재배치한 사람들이었다. K사가 유명한 대기업이었기에 이들의 역량도 뛰어났지만, 이들의 데이터 과학 역량을 가이드 해주고 지도해줄 시니어 데이터 과학자와, H 자신의 아이디어를 실현해줄 능숙한 데이터 과학자들이 필요했기에 미국 G사 시절 쌓았던 인맥을 총동원해 데이터 과학자들을 영입했다. K사의 명성을 알고 있던 H의 전 동료, 지인들도 H의 설득에 팀에 합류해 H의 데이터 과학팀은 급격하게 구성원이 늘어가기 시작했다.

회사의 전폭적인 지지와 환대에 데이터 과학팀이 급격하게 성장했고, H는 자부심을 가지고 열심히 일했다. H의 열정과, 새로 영입된 팀원들의 뛰어난 역량, 이들이 H를 믿고 보내는 헌신적인 업무 수행 덕에 데이터 과학팀이 결성된 지 1년 만에 회사의 사업에 크게 도움이 될 만한 중요한 사실들이 기존 데이터에서 발견되기 시작하였다.

H와 팀원들 또한 자신들이 일하던 인터넷 서비스 회사가 아닌 제조사에서 이렇게 흥미로운 데이터 분석 결과를 얻은 것에 고무되어, 이를 이용해서 할 수 있는 다양한 사업 아이디어들을 생각해내기 시작했다. H가 영입한 시니어 데이터 과학자들은 H가 영입되기 전에 팀에 합류했던 K사 직원들이 데이터 과학자로서 성장할 수 있도록 도왔고, 이들 기존 K사 직원들은 이제 팀의 일원으로서 맡은 역할을 훌륭하게 수행해내고 있었다. 

H가 K사에 합류한 지 2년 2개월이 된 시점, H는 본인을 영입한 직속 상사인 빅데이터 본부 P본부장을 포함하여 K사의 대표 이사와 경영진에게 그간의 데이터 분석 성과와 이 결과로 얻은 통찰들이 K사 경영에 의미하는 중요한 의미들과 이 때문에 가능한 새로운 신사업 아이디어들에 대한 보고를 진행했다. 

P본부장에게 프로젝트의 진행 상황과 주요 사실들에 대해서는 꾸준하게 보고하고 공유해와 주요한 사실들에 대해서는 대표 이사와 경영진에게 전달이 되었을 것이지만, 그래도 통상적인 데이터 과학팀 리더들이 그러하듯이 데이터 분석 결과가 사업에 주는 의미에 대해서는 대표 이사와 경영진에게 직접 전달하는 자리를 가지는 것이 바람직할 것이어서 회의 자리를 어렵게 만들었다.

보고회 전 P본부장에게 팀원 모두와 사전 보고를 드린 후 좋은 피드백을 받은 H는 대표 이사와 경영진 대상의 보고회도 좋은 반응이 있을 것으로 기대하였다. 실제로 보고회에서 대표 이사와 주요 경영진의 반응은 매우 호의적이었고, 사업에 대해 몰랐던 사실들을 새로이 알게 된 것에 매우 좋은 인상을 받은 듯했다. 무엇보다도, 그동안 축적한 데이터를 이용해 새롭게 추진 가능한 신사업의 방향과 가능성에 대해 다양한 아이디어를 내어놓은 것에 대해 보고회에 참석한 대표 이사와 주요 경영진은 매우 고무된 듯했다.

H는 보고회 때 반응이 좋았던 것으로 보아 H와 팀원들의 아이디어가 조만간 새로운 사업으로 실현되어 회사 성장에 도움이 되는 모습을 볼 수 있을 것이라 생각하였다. 이로 인해 승진을 포함한 더 큰 보상이 주어질 수 있지 않을까 기대가 되었고, 팀원들도 이런 과실을 같이 나누어 그간의 수고를 보답받을 수 있을 것이라 생각하였다.

그렇지만 보고회 이후 별다른 피드백이 대표 이사나 경영진, 심지어는 P본부장에게서도 전달되지 않았다. P본부장과의 주간 회의 때 조심스럽게 분위기를 살피며 보고회 이후의 별도 프로젝트에 대한 피드백이나 후속 조치 사항에 대한 내용을 살피려고 노력하였으나 역시 별다른 피드백이 대표 이사나 경영진에게서 없었던 듯하였다.

H는 아마도 제조사다 보니 다른 더 급한 사안이 있어 우선 보고회 때 제안된 신사업 아이디어들을 실제로 실현하기 위한 후속 프로젝트의 우선순위가 조금 밀린 것 같아, H는 직접 신사업 아이디어들을 일부라도 프로토타이핑해서 타당성이라도 검증해볼 요량으로 후속 프로젝트를 기획해 P본부장에게 보고하였다. P본부장은 후속 프로젝트 기획안에 대해 검토한 후, 실행을 위한 예산을 마련하기 위해 대표 이사와 경영진에 보고한 후에 경과를 알려주겠다며 우선 현재 업무를 지속하면서 기다리라는 지시를 내렸다.

P본부장에 후속 프로젝트를 보고한 지 6개월이 지나도 프로젝트 진행 여부나 예산 확보에 대한 아무런 경과 공유가 없자, H는 P본부장에게 다시 조심스럽게 후속 프로젝트에 대한 의견을 여쭈었다. P본부장은 대표 이사께 한 달 전에 보고를 드렸으나 아직 다른 급한 사안들 때문에 후속 프로젝트에 대한 실행 여부는 여전히 검토 중이라는 의견만 전했다.

후속 프로젝트 실행이 언제 될지 알 수 없어 H는 우선 팀원들과 그간의 데이터 분석 성과를 사업 운영 정보 시스템으로 만들어 회사 구성원들이 데이터 분석의 내용을 모니터링 형식으로 쉽게 공유받을 수 있도록 사업 운영 대시보드를 만드는 프로젝트를 시작하였다. 데이터 분석 업무와 사업 운영 대시보드 프로젝트를 동시에 진행하면서 신사업 프로젝트의 진행 상황을 간간히 P본부장에게 여쭈어보았으나 P본부장 또한 속 시원하게 답을 주지 않았다.

이렇게 답답한 마음으로 신사업 프로젝트 추진에 관한 의사 결정을 기다리고 있던 H는 어느 날 우연히 만난 대학 동기인 L에게서 놀라운 이야기를 전해 듣게 된다. L은 H가 데이터 과학팀 리더로 K사에 합류하기 전부터 K사에서 IT 전문가로 일하고 있었는데, 최근 자신의 부서에서 맡게 된 신사업 프로젝트에 대해 도움이 필요하다며 H에게 오랜만에 같이 식사도 할 겸 만나자고 한 것이다. 

H는 L과의 식사 자리에서 L의 부서에서 추진하려는 신사업 프로젝트가 바로 자신과 자신의 팀원들이 데이터 과학을 통해 찾아낸 니치 시장의 빅데이터를 이용하는 같은 아이디어를 활용하는 것이라는 것을 알고 겉으로는 태연하게 얘기를 들었으나 속으로는 왠지 모를 불안감과 불쾌함이 느껴지기 시작했다.

H 본인에게 적절한 피드백이 없이 회사 내부에서 그 아이디어의 사업화가 벌써 진행되고 있는 것 같다는 생각을 하게 된 H는 자신과 팀원들의 지인들을 통해서 그 뒤 사정을 수소문해서 알아보게 되었다. 수소문을 통해 자신이 제안한 신사업 프로젝트 진행의 실상을 알게 된 H는 자신이 데이터 과학팀에서 하고 있는 일이 정말 자신과 팀원들, 그리고 회사에 도움이 되고 있는 일인지 의구심이 들면서 K사에서의 경력에 대해서 강한 회의감이 들기 시작했다.

먼저 팀원들 중 수석 데이터 과학자인 G가 H에게 전한 사실은 다음과 같다. K사내 대표 이사의 총애를 받고 있는 경영진인 M이 자신의 차기 승진을 위한 프로젝트로 데이터 과학팀을 꾸리고 빅데이터 사업을 만들려고 하였다. 이를 위해 자신이 가장 신뢰하는 부하 직원인 P 본부장에게 지시하여 데이터 과학팀을 만들도록 했다. M의 승진에 유리하도록 데이터 과학팀의 멤버는 외부 홍보용으로 쓰일 수 있게끔 H와 같이 유명한 실리콘밸리 인터넷 서비스 플랫폼 회사에서 일하던 인력들로만 영입하도록 극비리에 P 본부장이 헤드헌터들에게 의뢰하였다.

다행히도 이런 조건에 잘 맞는 H가 영입되었고, H와 그 팀원들이 조직한 데이터 과학팀은 M의 실적으로 인정되어 M은 K사의 부사장으로 승진하게 되었다. P 본부장은 H와 그 팀원들이 데이터 과학을 통해 내는 아이디어와 성과들을 M 임원의 성과로 만드는 일을 하고 있다고 수석 데이터 과학자인 G의 지인이 H와 그의 팀에 대해서 사내에서 돌고 있는 소문에 대해 G에게 알려주었다는 것이다.

소문이라고는 하지만 현재 H가 처한 상황을 너무나도 이해하기 쉽게 해주는 내용에 H는 정확하지는 않더라도 어느 정도 사실을 담고 있을 것이라 생각하게 되었다. 그런데, 팀원 중 한 사람이고 H와 G사에서 같이 일하다가 H가 영입한 X는 더 놀라운 소식을 전해주었다.

X는 우연하게 P 본부장과 자주 협력하는 사업부인 S사업부의 실무진들과 함께 하는 회의에 S사업부 W팀장의 요청으로 참석하게 되었다. 그런데, W팀장이 회의에서 기술 검토를 요청한 신사업 기획안에 H와 그의 팀이 몇 개월 전 대표이사와 P 본부장에게 보고한 빅데이터 기반의 신사업 아이디어의 많은 부분이 담겨 있는 것을 보고 놀랐다고 한다.

X와 H의 팀은 데이터 과학팀이니 이런 아이디어를 관련이 있는 다른 사업부에서 사업화하는 것까지야 회사 사정에 따라 그럴 수 있다고 하더라도, 최소한 사전에 데이터 과학팀과의 협업이나 사업화 진행 상황 정도는 서로 공유하면서 성과를 나눌 수 있지 않을까하고 생각했다. 그렇지만 현재 상황을 보면, 아무래도 데이터 과학팀의 성과가 제대로 평가되지 못하고 다른 부서의 성과를 위해 이용만 되고 있는 것 같다고 X는 답답한 마음을 H에서 토로하였다.

H는 팀 리더로서 X의 얘기를 듣고 착잡함을 감출 수가 없었다. 하지만, 전사 조직 차원에서의 역할 분담이라고 좀 더 긍정적으로 생각하고 다음 기회를 노려보기로 했다. X에게 기술 실무 검토 협조 요청이 넘어올 정도이니 아마도 곧 신사업에서 H의 데이터 과학팀의 협업이나 역할 분담에 대한 얘기가 P 본부장에게서 나오지 않을까 하고 생각하였다.

하지만, H의 생각과는 다르게 X의 기술 검토 결과는 W팀장의 신사업에 반영이 되기는 했지만 데이터 과학팀과의 협업으로 이어지지 않았다. S사업부는 W팀장의 신사업 기획, 실행에 따른 회사 매출 창출의 기여를 공로로 S사업부장이 전무로 승진하게 되었고, W팀장 또한 S사업부장의 자리를 이어받아 상무로 승진하게 되었다. H를 더 힘들게 한 것은 그의 팀원이었던 X와 X가 같이 일하고 있던 동료 N이 S사업부의 데이터 엔지니어링팀으로 발령이 나 이동하게 된 것이다.

이런 상황에서도 전사적인 관점에서의 역할 분담과 업무 실행의 결과라고 애써 자신을 다독이려고 했지만, 애써 끓어오르는 P 본부장과 회사에 대한 실망감은 사라지지 않았다. 데이터 과학팀의 수석 데이터 과학자 G는 이번 상황에 대해서 적지 않게 실망한 듯, 최근 이직 준비를 하고 있는 듯한 느낌이다. 다른 팀원들도 X와 N의 발령에 대해서 왠지 불편하게 받아들이는 눈치였다.

H는 자신을 믿고 자신의 데이터 과학팀에 합류해준 팀원들에게 좋은 성과에 따른 보상을 적절하게 해주지 못하고 있는 것 같아 힘들었다. 이와 함께, 내가 지금 하고 있는 일이 정말 회사의 성장에 기여하고 있는 일인지, 특정 이익 집단의 관계와 관련성에 대해에 맞게 이용만 되고 데이터 과학 팀원들의 경력에 도움이 되지 않는 것은 아닌지 생각이 많아지게 되었다. 

의기소침해진 H는 요즘 업무 의욕이 예전보다 많이 떨어진 것을 느끼며 팀원들에게 내색하지 않으려고 노력하지만, 팀 전체적으로도 많이 분위기가 가라앉은 것 같아 걱정이다. H는 오늘도 자신과 데이터 과학팀의 미래를 어떻게 그려야 할지 고민하면서 밤잠을 설치고 있다.

사례 2의 교훈
데이터 과학, 빅데이터 붐 때문에 데이터 과학팀을 조직하고 내부 직원을 데이터 과학팀 리더로 승진시키거나 외부에서 데이터 과학팀 리더를 영입하는 우리나라 기업들이 많아지고 있다.  기업의 형편과 상황에 따라 데이터 과학팀이 맡게 되는 업무 영역과 내용은 차이가 꽤 나는 듯하다. 그래도 요즘 많이 주목을 받는 트렌드를 쫓는 부서이다 보니 새로이 데이터 과학 관련 부서가 신설되고 외부에서 데이터 과학자들이 영입되면 전사적으로 많은 주목을 받는 듯하다.

필자가 경험하거나 간접적으로 전해 들은 것을 돌이켜 보면 데이터 과학팀의 성과가 미미한 것처럼 보이는 경우는 사실 데이터 과학 그 자체의 효용이 없기 때문이기보다는 그 기업의 조직간 관계나 정치적 이해관계 때문에 협업이 제대로 이루어지지 않거나, 데이터 과학팀의 역할에 맞지 않는 부수적인 업무에 매몰되어 데이터 과학 본연의 성과를 창출할 기회를 만들기가 쉽지 않기 때문인 경우가 더 많은 것으로 보인다.

데이터 과학팀이 전사적인 데이터 자원을 조망하면서 정밀한 데이터 분석을 통해 사업에 도움이 되는 사실들을 밝혀 나가고 사업 실행 조직에 실질적인 도움을 줄 수 있을 정도로 체계가 정비되기까지 시간이 걸린다. 

이 때문에, 이렇게 복잡한 상황에서 데이터 과학팀을 일단 유지하려고 애쓰는 데이터 과학 부서 리더들이 흔히 하기 쉬운 실수 중의 하나로 데이터 과학 본연의 활동에 소홀하면서 데이터 분석을 위한 기반을 쌓지 못하고 데이터 과학에 필요한 특정 기술이나 시스템을 구축하는 것으로 계속 성과를 내려고 하는 것을 앞서 지적한 바 있다.

기업에 따라 다소 차이는 있지만, 한 사업부의 데이터 분석 필요에 맞게 작게 시작하는 데이터 과학팀의 경우에는 상대적으로 이런 정치적인 외풍에 덜 시달리고 자리도 잘 잡는 것으로 보인다. 반대로 특정 임원의 주도로 전사 데이터를 모아 분석을 하겠다거나, 전사 경영에 도움이 되는 데이터 분석 결과를 위해 모든 부서의 데이터를 한곳에 모아 빅데이터 분석을 해보겠다거나 하는 식으로 규모 있는 일로 시작되어 조직된 데이터 과학 부서의 경우가 상대적으로 이런 정치적인 외풍에 잘 시달리는 것으로 보인다.

일단 이렇게 시작부터 전사적인 규모의 데이터 분석을 하겠다고 시작한 데이터 과학 부서는 데이터 분석의 목적과 효용이 초기에 분명하게 정의되지 않는 경우가 많다. 일단 데이터부터 모아보고, 이렇게 모은 데이터에서 탐색적 데이터 분석을 통해 효용이 있을 만한 문제를 찾아보겠다는 식이다. 

그렇지만 이런 경우 전사적인 경영에 도움이 될 만한 문제를 찾는 것은 더 어렵다. 일단 데이터 소스가 많아지고 검토할 데이터가 많아지기 때문에 탐색적 데이터 분석 과정에 필요한 시간과 노력이 더 많이 들어갈 뿐만 아니라, 목적이 분명하지 않으니 데이터의 의미를 이해하고 문제를 정의하는 데에도 더 많은 시간과 노력이 들어가게 된다.

무엇보다도, 전사적인 규모의 문제를 풀겠다고 시작한 데이터 과학팀은 조직 내 다른 부서의 부러움도 사지만, 경계와 시기심을 받는 경우가 많다. 전사적인 사업 문제를 해결하기 위해서는 관련된 부서의 자료와 데이터의 협조를 받아야 하는 경우가 많은데, 이런 협조 요청을 모든 부서에서 좋게만 여기지는 않기 때문이다. 

이런 미묘한 부서 간 입장 차이와 감정의 골이 데이터 과학 부서의 부담으로 다가오는 경우가 많다는 것을 데이터 과학 부서의 리더, 특히 외부에서 팀장이나 임원으로 영입되어 온 데이터 과학 부서 리더의 경우는 염두에 두고 조심스럽게 데이터 과학 부서의 연착륙을 설계하는 것을 권장한다.

필자가 현재 데이터 과학자를 꿈꾸는 데이터 과학자 지망생들과 현직에서 데이터 과학자 경력을 키워가고 있는 많은 동료에게 이번 사례를 통해 전달하고 싶은 또 하나의 메시지는 이것이다. 본인이 이직하여 합류를 고려하고 있는 데이터 과학 부서의 정치적 상황과 리더의 상황에 대해 이직, 합류 전에 최대한 정보를 얻을 수 있을 만큼 얻어 분석해볼 필요가 있다. 이는 본인의 경력을 위해 매우 중요하다.

아마도 경력과 연륜이 꽤 쌓인 시니어 데이터 과학자, 시니어 소프트웨어 엔지니어 이상의 노련한 전문가들은 자신의 인맥을 동원해서 이런 상황에 대해 할 수 있는 만큼의 최대한의 정보를 수집하고 데이터 과학팀 합류 후의 경력 성장의 방향을 이직 전에 설계해보는 경우가 많을 것이다. 

하지만 이제 막 경력을 시작한 데이터 과학자나 소프트웨어 엔지니어들은 전문 역량 향상과 당장 떨어진 업무 수행에 바쁘기도 하고, 좋은 경력 상승의 기회만이 먼저 눈에 띄어 이직 후에 겪을 수 있는 이런 업무 외적인 문제들을 미처 고려하지 못하는 경우가 많을 것이다.

데이터 과학자의 경우 대표 이사를 포함한 임원을 직접 대하고 보고해야 하는 경우가 많다는 점, 그리고 다루어야 하는 문제가 전사적인 규모의 협조를 얻어야 하는 경우가 많다는 점을 생각해보면 조직 내에서 데이터 과학팀의 정치적, 이해관계 측면에서의 위치를 올바르게 파악하고 적절하게 처신하는 정치적, 사회적 대인 관계 기술 역량은 데이터 과학자에게 필수적이다. 

특히, 데이터 과학팀의 리더로서 합류하게 되는 시니어, 수석 데이터 과학자들의 경우 자신이 이끌 데이터 과학 부서의 조직 내 정치적인 위치와 다른 부서와의 이해관계를 파악하고 데이터 과학 부서가 조직 내에 안전하게 연착륙할 수 있도록 초반에 세심하게 신경 쓰는 것이 앞으로의 성과 창출과 부서의 성장을 위해 장기적으로 더 도움이 된다는 것을 꼭 염두에 두길 권한다.

앞서 CPS와 디지털 전환과의 관계를 살펴본 마흔여덟 번째 글에서 살펴본 것과 같이, 데이터 과학과 소프트웨어가 주도하는 디지털 전환이 기업 조직 내에 성공적으로 안착하기 위해서는 CEO를 포함한 경영진의 의지와 주도가 절대적이다. 

버버리와 GE의 사례에서 본 것과 같이, CEO가 데이터 과학과 소프트웨어 플랫폼의 중요성을 먼저 인지하고 이들을 조직의 DNA로 이식하기 위한 노력을 일관성 있게 추진해 나갈 때 디지털 전환 노력이 결실을 맺었음을 다시 한번 떠올려 보자. 이와 함께, 버버리와 GE의 경우 모두 이런 노력이 실질적인 비즈니스 모델의 전환과 재무적인 성과로 이어지기까지 꽤 오랜 시간이 걸렸음도 다시 한번 떠올려보자.

이런 버버리와 GE의 디지털 전환 사례를 비추어 보고, 데이터 과학과 빅데이터도 이런 전사적인 역량에 속한다는 점을 고려하면, 데이터 과학자들이 이직할 때 자신이 일하게 될 부서가 이런 전사적인 노력의 일환으로 만들어진 팀인지, 아니면, 조직 내 특정한 부서나 개인의 의지로 만들어진 팀인지 사전에 알아보고 판단해 보는 것도 성공적인 경력을 만드는 데 많은 도움이 될 것이다.

위 두 번째 사례는 가상의 사례로 만들어진 내용이지만, 실제로도 이와 꽤 비슷한 일들이 많이 일어나는 것으로 들었다. 최근 주요 기업의 빅데이터, 데이터 과학 관련 활동을 보면 기업 조직 내 임원이나 구성원이 승진과 성과를 위한 일로써 빅데이터 사업과 데이터 과학팀을 조직하는 경우가 꽤 많은 것으로 보인다. 

이 경우 전사적 자원을 움직인다고 하는 빅데이터 사업과 데이터 과학팀을 조직하는 부서나 개인이 CEO의 전사적인 전략 하에 움직이는 부서나 개인인지, CEO와 주요 경영진과의 관계가 견실하고 신임을 얻고 있는 부서나 개인인지, CEO와 기업이 빅데이터, 데이터 과학을 장기적인 전략의 주요 요소로서 적극적으로 고려하고 있는지, CEO와 주요 경영진이 데이터 과학, 소프트웨어 마인드를 가진 사람들인지 다양한 자료를 통해 사전 검증하면 데이터 과학자들이 위의 사례 2와 같은 어려운 상황에 처할 수 있는 위험을 사전에 조금이라도 예방할 수 있을 것이다.

데이터 과학, 빅데이터의 성공 사례가 기존에 견실하게 자리를 잡고 있던 대기업과 중견 기업보다는, 인터넷 서비스 플랫폼을 만드는 스타트업과 IT기업을 중심으로 많이 나타나는 이유가 위와 같은 조직 내 역학 관계의 문제와 관련이 많을 수 있다는 점을 생각해보자. 

정치가 없는 곳은 없고, 스타트업은 스타트업 나름의 복잡한 정치가 있는 것도 사실이지만, 이미 잘 자리 잡은 비즈니스 모델과 조직을 가진 중견 기업과 대기업에 비해서 스타트업은 조직 내부가 상대적으로 훨씬 유연하고 변화에 적응하기 쉽다.

인터넷 서비스의 경우 스마트폰, 웹 브라우저 등 사용자와 원격으로 직접 연결되어 데이터를 수집할 수 있게 하는 데이터 수집 채널을 가질 수 있고, 서비스 플랫폼에서 수집된 데이터를 이용해 사용자들의 행동과 선호를 분석하고 이를 서비스 플랫폼의 비즈니스 로직과 플랫폼 자체의 개선에 반영하면 즉각적이고 확장성 있게 비즈니스에 적용할 수 있어 빅데이터와 데이터 과학의 효용을 매우 빨리 볼 수 있다.

이와 함께, 인터넷 서비스 사업의 특성상 IT 기술이 중요하게 쓰일 수밖에 없어 CEO가 컴퓨터 과학, 수학, 물리학과 같이 데이터를 깊게 다루는 분야의 석, 박사 학위를 가지고 있거나 이에 대한 깊은 소양을 갖추는 경우가 많기 때문에 상대적으로 빅데이터와 데이터 과학의 성공 사례를 만들 가능성이 높다.

이에 반해서 일반 소매업, 제조업과 전통적인 서비스업을 주 업으로 하는 대기업과 중견 기업들은 그 조직이 이미 현재 시장에서 잘 자리 잡은 사업에 맞게 짜여 바쁘게 움직이고 있기 때문에 스타트업이나 인터넷 서비스를 업으로 하는 IT 기업에 비해 조직의 경직성이 높다. 

또한 이들 분야는 데이터 과학과 소프트웨어 기술이 없이도 이미 큰 성장을 이룬 경험이 있어 CEO나 창업주가 의지를 가지고 노력하지 않으면 다양한 현안을 해결하는데 바빠 데이터 과학과 소프트웨어 기술에 대한 깊은 소양을 가지기가 쉽지 않다.

이와 함께 이미 매출을 잘 내고 있는 비즈니스 모델과 사업 시스템이 잘 작동하고 있고 이를 통해서 기업이 잘 운영되고 있기 때문에, 당장 생존의 위기를 걱정하고 이를 위해 전력투구해야 하는 스타트업에 비해 데이터 과학과 소프트웨어 기술에 대한 절실함이 덜한 것도 사실이다. 

디지털 전환이 부각되면서 앞으로 이런 분위기는 조금씩 바뀌어 가겠지만, 그렇다고 해도 지금까지 해오던 관성이 하루아침에 바뀌기는 쉽지 않다. 이런 이유로 버버리와 GE와 같은 기업이 디지털 전환에 성공하는데 10년에서 20년에 걸친 꽤 오랜 시간이 걸릴 수밖에 없었음은 어느 정도 이해가 된다.

경직된 조직 내에 데이터 과학팀과 같이 전사 부서와 관계를 맺고, 석, 박사 수준의 전문 역량과 기술을 갖추고 일하는 전문가 조직이 새로이 만들어졌을 때, 기존 조직과 데이터 과학팀 사이에서 일어날 수 있는 마찰과 갈등이 없을 수 없다. 이미 조직된 기존 부서들과 구성원들 사이의 이해관계가 데이터 과학팀이 그 역량을 온전하게 발휘할 수 없도록 옥죄는 쇠사슬과 같을 수 있다.

CEO와 경영진이 새롭게 합류한 데이터 과학팀을 위한 지원과 조치를 눈에 띄게 하여 기존 조직의 사기를 떨어뜨리거나 반발을 사는 것도 좋지 않기 때문에 이런 문제를 나서서 해결해주기도 쉽지 않은 경우가 많아 데이터 과학팀이 기존 조직에 자리 잡는 것은 생각보다 쉽지 않은 문제이다.

데이터 과학자로서 경력을 추구하는 독자들은 위와 같은 이유로 전통적인 사업 영역에서 이미 잘 알려진 기업이 데이터 과학팀을 조직하기 위해 데이터 과학자를 채용하고 이런 자리에 대한 입사 권유를 받았을 때 앞서 소개한 사례와 같은 상황이 나타날 수 있음을 미리 염두에 두고 경력 설계를 할 것을 권한다. 

대기업과 중견 기업에서 전사적인 규모의 데이터 과학 프로젝트를 하게 되는 경우 내부 조직에서 많은 저항을 받을 수 있고, 기업 내부 구성원들 사이의 이해관계에 따라 데이터 과학팀의 성과가 빛을 보기 힘들 수도 있다는 것을 사전에 잘 인지하고 경력설계를 하길 바란다.

위와 같은 이유로, 데이터 과학팀과 데이터 과학자가 하게 될 직무 내용을 잘 분석해 보길 권한다. 데이터 과학팀이 조직도에 없거나 데이터 과학을 적용한 성과가 눈에 띄지 않는 기업이 데이터 과학자를 찾는 경우, 데이터 과학자가 수행할 데이터 과학 프로젝트의 목적과 해결하려는 문제가 전사적인 스케일로 이루어지는 큰 프로젝트인 경우보다는 특정한 사업부의 사업 현안과 관련된 문제를 위한 프로젝트인 경우가 성공 가능성이 높고 좋은 경력으로 만들기도 유리하다는 점을 고려하도록 하자.

데이터 과학 프로젝트의 자세한 정보는 기업의 기밀에 해당하는 내용이기 때문에 사전에 잘 노출하지 않으려고 할 수도 있을 것이다. 그렇다고 하더라도, 면접 때에 데이터 과학자와 데이터 과학팀이 수행할 프로젝트의 목적과 문제에 대해서 물어보고 조금의 정보라도 얻을 수 있다면 이런 판단을 내리기 쉬울 수 있고, 면접관들에게도 좀 더 좋은 인상을 줄 수 있을 것이다.

반대로, 디지털 전환과 빅데이터 사업을 새롭게 일으켜 보기 위해 데이터 과학팀을 조직하여 꾸려보고자 하는 CEO, CIO와 경영 임원의 경우도 애써 조직한 데이터 과학팀이 위와 같은 조직 내부의 역학 관계의 희생양이 되어 그 역할을 못 하게 되는 경우가 없는지 잘 살펴볼 필요가 있다. 

데이터 과학자 수준의 전문적인 지식과 경험은 없더라도, 데이터 과학팀이 맞닥뜨릴 수 있는 현실적인 어려움을 해결해주고 그 역량을 잘 발휘할 수 있도록 지원해줄 수만 있어도 데이터 과학의 효용을 경험하고 데이터 과학 프로젝트를 성공시킬 수 있는 가능성이 훨씬 더 높아질 것이다.

사례 2의 교훈은 다음과 같이 정리하려고 한다.

교훈 1. 전사적인 규모의 데이터 과학 프로젝트는 조직 사이의 이해관계와 다뤄야 하는 방대한 데이터 때문에 실패 가능성이 높다. 데이터 과학으로 해결하려는 문제가 잘 정의되어 있고 사업의 필요와 잘 맞는지, 데이터 과학팀의 조직 목적이 CEO 및 주요 경영 임원의 전사 전략과 잘 맞닿아 있는지 데이터 과학자들이 새로운 데이터 과학팀에 합류하기 전에 잘 살필 필요가 있다.

교훈 2. 데이터 과학팀의 리더로 이직을 하게 될 시니어 데이터 과학자들은 팀 조직 초반에 자신이 이끌 데이터 과학팀이 조직에 잘 연착륙할 수 있도록 협력이 예상되는 주요 조직, 부서와의 협력 관계를 잘 구축하는 것에 중점을 두는 것이 좋다. 이와 함께, 이직 전에, 또는 이직 후라도, 팀 조직 초반에는 데이터 과학팀 조직 배경에 대해서 잘 조사하고 데이터 과학 프로젝트 수행 과정에서 겪을 수 있는 조직 관리 측면의 위험을 잘 분석하기를 권한다.

교훈 3. 빅데이터와 데이터 과학을 통해 기업의 체질과 비즈니스 모델을 개선하고자 데이터 과학팀을 조직하고자 하는 CEO, CIO, 경영 임원들께서는 데이터 과학팀만이 가질 수 있는 독특한 조직 내 역학 관계 때문에 데이터 과학팀의 역량이 온전하게 발휘될 수 없음을 인지하고 있을 필요가 있다. 

어쩌면 이런 조직 내 역학 관계에서 잘 살아남으면서 일할 수 있는 것도 데이터 과학팀의 역량이라고 여기시는 분들도 있을 것이다. 그렇지만, 데이터 과학팀의 역량만으로 해결되기 어려운 문제들이 있을 수 있고, CEO, CIO 및 경영 임원의 전사 전략의 일환으로 추진되는 데이터 과학 프로젝트라면 그에 맞는 업무 조율과 지원이 이루어지는 것이 합당하다.

* 김진철 박사는 1997년 한국과학기술원에서 물리학 학사, 1999년 포항공과대학교에서 인공신경망에 대한 연구로 석사 학위를, 2005년 레이저-플라즈마 가속기에 대한 연구로 박사 학위를 받았다. 2005년부터 유럽입자물리학연구소(CERN)의 LHC 데이터 그리드 구축, 개발에 참여, LHC 빅데이터 인프라를 위한 미들웨어 및 데이터 분석 기술을 연구하였다. 이후 한국과학기술정보연구원(KISTI), 포항공과대학교, 삼성SDS를 거쳐 2013년부터 SK텔레콤에서 클라우드 컴퓨팅과 인공지능 기술을 연구하고 있다. 빅데이터와 인공지능 기술의 기업 활용 방안에 대해 최근 다수의 초청 강연 및 컨설팅을 수행하였다. dl-ciokorea@foundryco.com