[현장] 데이터과학자들이 자주 겪는 고민 3가지는?

▲10월14일 저녁 열린 ‘데이터야 놀자’ 패널토론

이광춘 데이터과학자 : 내가 학교에서 공부하던 시절에는 ‘데이터사이언티스트’라는 직업이 없었다. 대학교 때는 통계학 학사, 석사를 했다. 당시 지도 교수님이 컴퓨터를 활용한 통계를 많이 다루셨고, 그러다보니 나도 소프트웨어를 조금씩 공부했다. 내가 알고 있는 데이터사이언티스트는 과학, 엔지니어링, 비즈니스의 개념이 혼재돼 있다. 특히 과학이기 때문에 가설을 세우고 이를 검증할 수 있는 능력이 필요하다. 이 부분이 데이터사이언티스트의 가장 중요한 요소라고 생각한다.

엄태욱 데이터프로그래머 : 보통 데이터프로그래머라고 나를 소개하는 편이다. 데이터 일은 검색 업무를 맡으면서 시작했다. 그러다가 하둡을 다뤘고 현재 SK플래닛에서 데이터 인프라팀에 속해 있다. 데이터 일을 하다보니 여러 분야 쪽 사람들과 일하게 됐다. 데이터엔지니어라고 불리는 분 중에 코딩을 할 수 있는 사람과 아닌 사람이 있다는 걸 알았다. 그 뒤 나는 개발자이고 앞으로 프로그래밍을 계속 할 것 같다는 생각에 데이터프로그래머라는 이름을 이용하게 됐다.

김호연 데이터엔지니어 : 데이터사이언티스트에 대해서 명확한 답변을 가지고 가지고 있진 않다. 마치 ‘웹2.0’이란 용어랑 비슷한 느낌이다. 여러가지 개념이 혼재됐고, 이 질문에 대한 답변도 다양하다. 회사에선 데이터사이언티스트라는 사람에게 개발과 분석 능력 둘 다 바라는 것 같다. 풀스택 엔지니어가 모든 걸 할 수 있는 것처럼 말이다. 우리 회사로 보면 2가지로 나뉘어 있다. 엔지니어와 분석가다. 최근에는 이러한 명확한 구분이 조금씩 깨지는 것 같다.

고영혁 데이터과학자 : 사실 데이터사이언스라는 용어는 4-5년 전 링크드인의 DJ 파틸이라는 사람이 처음 제시했다. 용어 자체가 생긴 지 얼마 안 된 거다. 그만큼 데이터과학은 아직 정의가 확실치 않은 용어다.

김호연 데이터엔지니어 : 우리 회사에서 데이터 분석팀은 원래 하나였다. 그러다가 최근 분석팀과 엔지니어팀으로 나누어서 일하고 있다. 현재는 다른 팀이지만 몇 분은 과거 같은 팀이었기 때문에 서로 조금씩 이해하고, KPI(핵심 성과 지표)를 설정할 때도 공통의 목표를 잡기도 한다. 물론 서로 조금씩 감정이 상하는 부분이 있다. 하지만 나중에 워크샵이나 회식 등을 하거나 친밀감을 높이면서 해결하고 있다. 역시 사람이 제일 중요한 것 같다. 약간의 문제점은 어느 회사나 조직에나 있지 않은가.

엄태욱 데이터프로그래머 : 이런 이야기를 할 때면 조심스럽다. 그동안 분석가들과 의견 충돌을 겪었다. 물론 일부 분석가들 이야기다. 내가 처음 뵌 분석가, DB 엔지니어들은 대부분 RDB 엔진이나 비싼 엔터프라이즈 솔루션을 많이 이용했다. 그들은 그 제품으로 주어진 일만 기계적으로 했다. 내가 “왜 이렇게 하시나요?”라고 물어볼 때면 “그동안 이렇게 해왔다. 넌 데이터를 얼마나 다뤄봤느냐”라고 되물었다. 그분들은 주어진 일, 눈앞에 있는 일만 하시는 것 같더라. 사실 데이터를 처리하고 분석하는 전체 과정은 굉장히 길고, 여러 단계로 나뉜다. 과거 일부 분석가들은 눈앞의 단계만 봤다. DB 안에 데이터만 바라보거나, 누군가 분석한 결과를 시각화하는 것만 생각하는 것이다. 그 앞 단계로 나가는 분들은 잘 못 봤다. 물론 그분들도 “할 수 있는 거 다 해봤지만 앞 단계에서 바뀌는건 없었다”라고 이야기한다.

나는 앞 단계에서 직접 무엇인가 만들어 해결할 수 있을 거라고 봤다. 그러다보니 데이터를 처음 만드는 개발 쪽에도 간섭을 하게 됐다. 데이터 분석 전 단계에서 필요없는 데이터를 미리 없앨 수는 없는지, 더 좋은 데이터를 미리 만들수 없었는지 살펴봤다. 이러한 상황에서 개발자라는 직군이 좋았다. 개발자는 원하는 도구를 만들고 문제를 직접 해결할 수 있기 때문이다. 그렇다고 분석가나 DB 담당자에게 프로그래밍을 단기간에 알려주는 건 힘들다. 그래서 대부분 쉬운 도구를 만들어주거나 불필요한 부분을 해소해주는 인프라를 구축해주는 식으로 문제를 해결했다.

이광춘 데이터사이언티스트 : 나도 직접 코딩을 하면서 문제를 해결하려 했다. 과거에는 그게 불가능했다. 지금은 오픈소스 기술이나 도구가 굉장히 잘 나와 있어 누구나 코딩을 할 수 있다. 또한 문제가 있으면 직접 해결할 수 있지만 내가 가지고 있는 문제를 오픈소스화해서 다른 사람들과 함께 해결하기도 했다.

고영혁 데이터사이언티스트 : 10년 전에 비슷한 경험이 있었다. 그때 로그를 남기고 이를 분석하고 싶었다. 하지만 직접 인프라를 만들 수 있는 실력은 아니었다. 그래서 담당자분에게 기술을 만들어달라고 요청하니 돌아온 답변은 “이거 추가해서 서비스가 느려지거나 문제가 생기면 책임지겠어요?”라는 말이었다. 사실 엔지니어는 언제나 최악의 상황을 대비해야 한다. 게다가 다른 큰 회사가 비슷한 시도를 한적이 없다면 이런 말을 할 수 있다.

나는 그때 2가지 방식으로 대처했다. 먼저 회식도 하고 함께 지내면서 인간적으로 친해지려고 노력했다. 두 번째는 제일 작은 규모로 테스트를 시도해봤다. 그 작은 단위 테스트에서 별 문제 없으면 조금 확대해 실험해보자고 제안했다. 작은 테스트가 잘 성공될 때면 담당자분한테 고맙다는 말을 꼭 전했다. 이게 반복되면 상대방이 먼저 뭔가를 만들어주려고 한다. 결과로 이야기하고, 일을 작은 단위에서 시도한 셈이다.

엄태욱 데이터과학자 : 나도 예전에 서버 개발자에게 어떤 기술을 지원해달라고 요청했다. 그때 그분은 어려운 기술적인 용어를 이용해 설명하면서 안된다고 했다. 보통 데이터 분석팀은 그럴 때마다 어쩔 수 없이 돌아오곤 했는데, 나는 개발자였기 때문에 상대방의 기술 내용을 이해하고 그럼 “이런 식으로 프로그래밍해서 해결하면 되지 않을까”라고 제안하니 받아줬다. 그래서 데이터 조직 안에 개발자가 있으면 외부 조직과 커뮤니케이션하는 데 도움을 많이 줄 수 있다고 본다.

김호연 데이터엔지니어 : 우리 회사에도 아예 조직 안에 게임 개발자가 있다. 게임 개발자들이 아예 로그 수집 모듈이나 필요한 기술은 내부에서 따로 만들어 외부에 전달해준다.

고영혁 데이터사이언티스트: 엔지니어와 협업을 하기 위해 코딩을 배우는 분석가들에 대해서는 어떻게 생각하나?

엄태욱 데이터과학자 : 환영할 일이라고 본다. 잘 하려고 노력하는 분들의 기를 꺾으려고 하진 않는다. 그분들의 접근 방법이 “내가 개발을 좀 아니까 이야기해요”가 아닌 “내가 이 정도로 협업할 만큼의 노력을 하고 왔어요”라고 표현한다면 좋을 것 같다.

김호연 데이터엔지니어 : 요즘 신규 입사하는 분석가분들은 R를 할 수 있어야 갈 수 있다. 시대가 조금 변한 거다. 우리를 이해하기 위해 직접 공부하고 왔다고 하면, 그게 헬로월드 코드 한 줄 짜왔다 하더라도 고맙기도 하고 도와주고 싶을 거다.

▲데이터야 놀자 패널토론에 참여한 이광춘 데이터과학자, 엄태욱 데이터프로그래머, 김호연 데이터 엔지니어(왼쪽부터)

엄태욱 데이터 프로그래머 : 2가지가 있다. 먼저 데이터 조직은 개발자, 분석가 등 다양한 사람으로 구성된다. 데이터과학은 팀 스포츠라고도 불린다. 이 말은 각기 잘하는 게 다른 사람들이 팀으로 있어야 한다는 뜻이다. 가장 중요한 것은 거기서 협업이 잘 돼야 한다. 예전에 나는 개발밖에 할 줄 몰라서 SQL을 굉장히 무시했다. SQL을 모르기 때문에 더 그랬는지도 모른다. 근데 어느 새 내가 SQL을 짜고 있더라. 굳이 SQL로 할 수 있는 일을 어렵게 길게 코딩할 필요 없기 때문이다. 공부할 부분도 많았다. 즉, 각자의 도구가 서로 다르고, 도구가 많을수록 더 편리하고 빠르게 문제를 해결할 수 있다는 것에 동의를 하면 됐다. 잘하는 게 각자 다른 사람일 수록 각자 자기 것에 집착을 하고 거기에만 매몰되는 경우가 많더라. 나도 그런 셈이다. 데이터 분석 조직에서는 누군가가 함께 해서 시너지를 낼 수 있는 마음가짐이 중요한 것 같다.

두 번째로 목표가 명확해야 한다. 많은 조직에서 잘못하고 있는 것 중 하나가 데이터 조직을 사내조직으로 만든다. ‘사내 고객’을 위해서 분석을 한다. ‘연봉 높은 사람들의 의견(HiPPO, High-Paid Person’s Opinion)’을 뒷받침하려고 데이터를 활용하는 것이다. 다시 말해 회사에서 이미 결정을 내린 사람이 이에 대한 근거를 대기 위해 데이터를 만들어 달라고 요청하는 식이다. 데이터 조직이 그렇게 흘러가면 팀원들은 의욕도 상실하고 거짓 데이터를 위해 일한다는 생각이 든다. 아무리 좋은 팀을 만들어도 그런 식으로 쓰면 데이터 조직은 망가진다. 지금은 데이터가 직접 서비스가 되고 제품이 되는 세상이다. 사내 고객을 위한 데이터 조직이 아니라 사외의 실제 고객에게 무엇인가 가치를 준다는 것을 목표로 삼으면 좋을 것 같다.

김호연 데이터엔지니어: 조직원들이 체감할 수 있을 정도로 목표가 명확해야 한다. 예를 들어 인공지능 기술을 개발한다고 했을 때 ‘게임을 자동으로 분석해주는 인공지능을 만들자’라고 말하면 모호하다. 대신 ‘우리가 가진 지표는 600개인데, 이 지표들간의 상관관계를 분석하고 어떤 부분이 특이한지 그 이유를 찾아보자’는 식의 목표여야 한다. 사람들이 머리속으로 떠올릴 수 있는 목표는 실제로 팀원이 할 수 있을 거라는 생각을 들게 한다.

두 번째는 문서가 아니라 제품으로 만들어야 한다. 예를 들어 게임 분석 결과를 문서로 나눠주고 관련 팀에 전달하면 아무도 안 본다. 그들은 이미 비슷한 정보를 많이 읽었기 때문이다. 차라리 게임에 바로 설치할 수 있는 프로그램을 만들어 제공하는 게 낫다. 우리는 이 두 가지를 목표로 삼고 있다.

이광춘 데이터과학자 : 데이터 조직이 내놓을 수 있는 결과물은 2개다. 하나는 보고서고, 또 하나는 데이터 제품이다. 보고서의 경우 사람과 관련돼 있다. 따라서 여기선 커뮤니케이션이 중요하다. 회식을 하든 선물을 주든 그 사람을 내편으로 만들어서 회사 생활을 할 수 있을 것이다. 또 다른 방법은 실행가능하도록 도와주는 데이터 서비스나 제품을 만드는 것이다. 이건 기계와 알고리즘의 문제다. 둘 중 하나는 선택해야 하는데, 대부분의 사람은 둘 중의 하나를 왔다갔다하며 시간을 보낸다. 본인이 어떻게 선택하느냐에 따른 문제다.