데이터 세계의 황금 트라이앵글

[임백준 칼럼] 기업의 데이터팀 구축 가이드

지난 2월 7일부터 9일까지 보스턴에서 열린 스파크서밋에 다녀왔다. 스파크가 요즘 뜨거운 기술이라는 건 알고 있었지만 행사의 규모가 생각보다 크고 열기가 뜨거워서 놀랐다. 스파크라는 특정한 프레임워크에 대한 행사가 아니라 빅데이터 처리, 데이터 분석, 데이터 과학, 머신러닝 등을 망라하는 생태계 전체의 거대한 축제였다.

강연은 유명한 회사의 개발자나 데이터 과학자가 실전 프로젝트 경험을 공유하는 식으로 진행됐다. 변화 속도가 워낙 빠르고 광범한 공간이기 때문에 강연자가 '정답'을 제시하기보다는 청중과 함께 호흡하며 고민하는 모습이 많았다. 작년에 다녀온 리액티브서밋의 확장판이라는 생각도 들었다. 3일 동안 여러 강연을 듣고 참석자들과 네트워킹을 하면서 최근 데이터 엔지니어링의 무게가 배치처리에서 실시간(에 근접한) 스트리밍 처리로 옮겨가고 있음도 확인할 수 있었다.

개인적으로는 회사에서 데이터 업무를 수행하는 팀을 효율적으로 구축하는 방법을 고민하고 있던 참이었다. 회사 내부에 분절적으로 흩어져 있는 데이터 관련 직원들을 어떻게 통합해서 시너지를 이끌어낼지 고민이 많았다. 스파크서밋에서 이 질문에 대해 영감을 얻었고 기차를 타고 돌아오는 길에 창 밖의 설경을 보면서 답을 찾았다. 그것은 데이터분석가(Data Analyst), 데이터 엔지니어(Data Engineer), 데이터 과학자(Data Scientist) 이렇게 세 개의 축으로 구성되는 황금의 트라이앵글이다.

데이터와 관련된 세 분야는 서로 겹치는 부분이 많지만 자기만의 고유한 영역이 있다. 이것은 전통적인 DBA의 영역과도 구분된다. 많은 회사가 이러한 다름을 인식하지 못하고 하나의 팀 혹은 심지어 한 사람에게 모든 것을 요구하는 경우가 있는데, 그건 잘못된 접근이다. 적어도 비효율적이다. 그렇게 하는 것은 개발자 한 명에게 자바 백엔드 개발, 리눅스 운영체제 업그레이드, 보안 시스템 구축, 프린터 카트리지 교환을 주문하는 것과 비슷하다. DA, DE, DS는 저마다의 역할이 있는 전문직이며 현대의 모든 회사는 (테크놀로지 회사든 아니든) 반드시 조직 내에 이 황금 트라이앵글을 구축할 필요가 있다.

데이터분석가라는 직군을 생각해 보자. 대부분의 회사에서 이들은 '개발자'로 분류되지 않는다. 그들은 비즈니스를 수행하는 사람들 사이에 섞여서 하루종일 SQL 구문을 작성하거나 엑셀을 만지작거린다. 크리스탈 리포트나 마이크로스트래티지 같은 BI 도구를 이용하는 경우도 있지만 기본적으로 그들은 변덕스러운 데이터 요청에 반응하는 ‘인간 SQL’이다. 기술적인 성장에 대한 욕구가 있는 사람이라면 선택할 수 있는 길이 아니다.

사용자나 상사가 부리는 변덕에 직접적으로 노출되어 있기 때문에 일에 대한 만족도나 성취감이 낮다. 내가 이러려고 비즈니스 분석가가 되었나 하는 자괴감에 빠지거나, 엑셀과 SQL의 늪에서 벗어나 코딩이나 머신러닝 같은 최신기술을 배우고 싶어하는 사람이 많다. 그렇지만 회사의 비즈니스 도메인, 즉 데이터 자체에 대해 가장 많은 지식과 경험을 쌓는 건 결국 이들이다. 기술이나 개발에 직접 연결하기는 어렵지만 이들이 가진 지식과 경험은 황금 트라이앵글의 한 축을 형성한다. 특히 스파크를 중심으로 하는 최근 데이터 공간의 변화는 질척한 SQL의 늪에 빠진 이들을 최신 기술의 세계로 인도하고 있다.

스파크 노트북, 제플린, 주피터 등으로 대표되는 현대적 도구는 누구보다도 DA를 위한 것이다. 현대 DA가 하는 일은 더 이상 SQL 클라이언트나 BI 도구를 이용해서 정적인 리포트를 생산하는데 그치지 않는다. 그들은 노트북에 두 손을 깊이 담근다. 그래서 데이터의 흐름을 이해하고, 시각화하고, 분석한다. 이런 과정에서 파이썬, 스칼라, R 같은 언어로 코딩을 하고, 다양한 시각화 도구를 이용해서 데이터의 흐름도 보여준다. 반복되는 상사의 변덕을 코드로 자동화해서 처리하고, 남는 시간을 이용해서 머신러닝을 이용한 이상감지(anomaly detection) 시스템 등을 구축한다. DA가 이런 일을 수행하려면 원하는 데이터가 원하는 장소에 있어야 하는데, 그 일을 해주는 것이 데이터 엔지니어다.

데이터 엔지니어는 A라는 장소에 있는 데이터를 B라는 장소에 옮기는데 따르는 모든 엔지니어링적 요소를 책임진다. 패킷에 담긴 내용을 들여다보지 않고 정확한 목적지로 전달하는데 주력하는 네트워크 라우터처럼, 데이터 엔지니어는 데이터에 담긴 내용과 상관없이 그것을 필요한 장소에 배달하는데 주력한다. 과거에는 이런 일을 주로 extract, transform, load를 의미하는 ETL 스크립트로 처리했다. 지금도 대부분의 회사가 콘트롤엠(Ctrl-M)이나 스카이봇(Skybot) 같은 스케줄링 도구를 이용해서 수많은 배치작업을 돌리고 있을 것이다. 이런 스크립트 중심의 아키텍처가 낳는 문제점은 설명할 필요가 없다.

앞에서 보았던 노트북 기술이 주로 DA를 위한 도구라면, 카프카와 스파크로 대표되는 최근 기술은 누구보다도 DE를 위한 도구다. 컨퍼런스에서 데이터도그(DataDog)에서 근무하는 데이터 엔지니어들과 점심을 먹으며 많은 이야기를 나누었는데, 그들은 회사 내의 데이터 과학자들이 스파크 자원을 요청하면 AWS를 이용해서 스파크 클러스터를 즉석에서 만들어 제공하는 일을 수행하고 있었다. 스파크를 활용한 데이터 운반을 책임지는 것은 물론이다.

아직 데이터 엔지니어와 데이터 과학자를 엄밀하게 구분하지 않는 경우가 많은데 구분이 필요하다. 요즘에는 풀스택 개발자나 데브옵스라는 표현을 써서 한 사람이 해야할 일의 범위를 넓히는 경향이 있지만 개발자(dev)와 시스템운영자(ops)의 전문분야가 다르듯 DE가 하는 일과 DS가 하는 일은 엄연히 다르다. DE가 데이터를 옮기는 일에 주력한다면, DS는 데이터의 내용 자체에 집중한다.

데이터 과학자의 역할은 피처 엔지니어링(feature engineering)에 있다. 데이터에 구조를 부여하고, 비정상적인 데이터를 배제하고, 빠진 데이터를 채워 넣고, 오류를 바로잡고, 비즈니스의 목적에 따라 데이터를 선택하고, 통계적 모델을 고민하고, 머신러닝 학습을 수행해서 모델을 산출하고, 결과를 검증하고, 모델을 개선하고, 개발팀에서 모델을 사용할 수 있도록 API를 만들어 제공한다. 예컨대 데이터를 실시간 스트리밍으로 옮길지 아니면 마이크로배치로 옮길지 하는 것은 그들의 주요한 관심사가 아니다. 그건 DE의 몫이다.

지면 관계상 자세한 이야기를 하기 어렵지만, 나는 회사에 흩어져 있는 DA, DE, DS를 하나로 묶어서 트라이앵글을 구축하고 그들이 서로 긴밀하게 협업하도록 만들어야 한다는 결론에 도달했다. 자기정체성을 고민하는 데이터 분석가에게 DA도 테크놀로지 그룹에 속하는 개발자라는 점을 일깨워주고, 데이터를 수집하고 옮기는 코드를 작성하느라 시간을 빼앗기는 데이터 과학자에게 피처 엔지니어링에 집중할 수 있는 환경을 마련해 주어야 한다는 생각도 하게 되었다.

회사에 따라 같은 사람이 셋 중에서 두 개 혹은 세 개의 역할을 모두 수행하는 경우도 있을 것이다. 현실이 그렇다면 어쩔 수 없다. 그렇다고 해도 세 분야의 업무가 저마다의 커리어 경로를 가진 전문분야라는 사실은 인식할 필요가 있다. DA가 DA의 일을, DE가 DE의 일을, DS가 DS의 일을 잘 할 때 회사의 경쟁력이 개선되기 때문이다. 세 개의 분야를 아울러서 데이터 세계의 황금 트라이앵글이라는 멋진 이름을 붙인 이유다.

*본 칼럼 내용은 본지 편집방향과 다를 수 있습니다.