대기업 계열사의 빅데이터 분석 그룹에서 일하고 있습니다. 주업무가 데이터 분석이죠. 프로젝트를 따라 움직이는데 회사에 들어간 지 1년 정도 됐는데 그 사이에 전자업체 프로젝트를 3번 정도 했습니다. 지금은 공공 프로젝트를 하고 있고요.

입사 1년차라서 직장 생활에 한창 적응해 가고 있습니다. 처음으로 실무 분석 프로젝트에서 했던 일은 ‘기준정보 자동연계’였습니다. 거래선 ID와 이름을 수동으로 매칭했던 것을 자동으로 적용하는 일이었어요. 관련 정보를 입력하면 바로 연관 정보가 뜨게 하는 알고리즘 개발 작업이요.

시스템 개발 과제에서 if, then, else의 조합으로 접근하면 결과물이 부정확해질 수 있다고 하더라고요. 예외가 너무나 많아서요. 그러다 보니 SI 부서에서 프로젝트를 할 때, 특히 예외가 많은 업무를 처리할 때 분석가 그룹과 함께 접근합니다. 그 때문인지 개발자 대상의 사내 데이터 분석 교육 프로그램을 운영하지 않나 생각했습니다. 사내 데이터 분석 전문가 자격증도 레벨별로 있고요.

ADP 시험 응시 배경

학위를 딴 다음에 취직을 했는데 천문학 전공이 이 분석 업계에 그리 내세울 만한 게 아니거든요. 다들 잘 모르니까요. 천문학은 분석과 매우 관련이 깊어요. IT 관련 전공을 하지 않은 분석가로서 대외적으로 인정을 받으려면 ADP(데이터 분석 전문가) 자격증이 필요하다고 여겨 시험 준비를 했습니다. 박사 학위가 있어서 ADsP를 거치지 않고 바로 ADP 시험에 응시했어요. 다니는 직장에 들어가기 전부터 ADP 공부를 했고요.

회사 생활에 적응하느라 집중하여 공부할 시간이 많이 부족했지요. 특히 ADP 실기시험은 회사 프로젝트 기간과 겹쳐 집중하여 공부하기 어려웠습니다. 이론은 [데이터분석 전문가 가이드] 책으로 공부를 했고요.

ADP 공부를 하면서 어려웠던 부분은, 하둡 에코시스템 등 분산 데이터 저장 기술이었어요. 개발자를 비롯하여 IT 전공자들이라면 쉽게 받아들일 영역일 텐데, 제게는 많이 낯설게 여겨지더라고요. ADP 시험을 준비한 덕분에 ‘데이터 분석 시스템 아키텍처’ 얘기가 나오면 소통할 정도 실력을 쌓게 됐습니다.

많은 분석 경험이 도움 돼

회사에 입사했을 때는 제안서 작성을 돕고 적응하는 기간을 거쳤어요. 대학원에서 데이터 분석을 많이 했던 경험을 갖고 있어서 직장 업무가 그리 낯설지는 않더라고요. 직장에 와서 쓰기 시작한 파이썬으로 일하는 것도 비교적 쉽게 적응했고요.

주어진 분석 과제를 접하면 ‘아 어떻게 접근해야겠구나’ 하는 나름대로의 감이 오는 편이에요. 하지만 시험은 시험이죠. ADP 실기시험 때에는 제시된 문제에 대한 답을 만족스럽게 못 썼던 거 같아요. 운이 좋아서인지 턱걸이로 ADP 시험에 합격했습니다.

데이터 분석에 대한 관심

회사 입사 면접 때도 강조했던 바이기도 하지만, 대학원에서 분석이 ‘주업’이었어요. (천문학) 연구 과정이 형태만 조금 달랐지 데이터 분석 과정이거든요. 어떤 데이터가 주어지면, 그걸 분석하여 논문 형태로 발표할지, 고객이 알아보기 쉬운 형태로 전달할지만 다를 뿐 본질적으로 같아요. 대학원에서 목표 지점까지 갔으니 데이터 분석이 맞는 사람이라고 볼 수 있지 않을지…(웃음).

“한정된 물과 식량을 주고서 깊은 산속에서 길을 찾아 안전한 곳으로 탈출하라는 미션이 주어졌다고 해보죠. 자신의 온갖 지식과 감을 총동원하여 길을 찾아야 하겠지요. 데이터 분석도 그런 과정과 조금은 비슷하다고 봐요.”

데이터 분석가로서 직장 생활

저는 ‘데이터 사이언티스트’라는 타이틀을 달고 일하고 있어요. 우리 부서는 50명 정도로 구성됐는데 부서원의 2/3정도가 데이터 사이언티스트입니다. 통계학 전공자들이 많고 수학이나 물리, 산업공학을 전공한 분들이 눈에 띄더라고요. 박사급 멤버는 20명 정도 됩니다.

코딩을 조금하는 편입니다. 급할 때는 툴을 쓰지만, 보통 툴에서 지원하지 않는 경우가 많으므로 라이브러리를 토대로 프로그래밍하여 접근하는 경우가 많죠. 급할 때라면, 초기 탐색적 데이터 분석 과정(EDA)이라고 해야 할까요. 데이터를 가져오면 모델을 만들기 전에 살펴보는 과정을 말합니다.

탐색적 데이터 분석은 편차가 얼마인지와 분포를 확인해보고, 널 값을 채우고 하는 자잘한 전처리를 하는 과정이죠. 이 과정에서 적용하기 가장 쉬운 도구가 ‘엑셀’입니다. 엑셀에서 필요 없는 값을 지우고 피봇한 다음, 간단한 그림을 그려봅니다.

그 과정에서 약간 시간이 나면 R이나 파이썬으로 더 좋은 그림을 그려보면서 본격적인 분석을 어떻게 해야 할지 더 구체화합니다. 코딩을 하면서 어떻게 분석해야 할지를 전략을 짭니다. 에러가 나오면 찾아서 빼고 다시 시도하고 반복해 가면서 시도하는, 그리 거창한 건 아니지만 굳이 말하자면 애자일식으로 접근하는 거죠.

분석 업무의 즐거움과 아쉬운 점

흥미로운 부분이라면 매우 다양한 분석 주제를 만난다는 점입니다. 전자업계, 금융업계, 공공분야 등의 분석 프로젝트에 2명이 한 팀이 되어 2~3개월만에 끝내는데요. SI 프로젝트에서 비해서는 단기간에 이뤄지는 거죠.

고객이 데이터를 제시하면서 무엇을 궁금해하는지를 중심으로 분석합니다. 이 점이 좋기도 하지만, 아쉬운 지점이기도 해요. 어떤 데이터를 깊이 파고들어가 결과를 도출해내는 전형적인 빅데이터 분석을 해볼 기회가 그리 없기 때문이죠. 특정 데이터를 깊이 파고들어 가면서 당초 예상하지 못한 지점까지 도출해내는, 뭐 전형적인 빅데이터 분석이 있잖아요. 그런 분석을 하지 못한다는 점이 아쉽기는 해요.

촉과 경험이 필요한 영역

회사에서 ‘데이터 엔지니어’로 부르는 직군이 있어요. SQL 튜닝이나 DB 관리(DBA) 업무는 개발자들이 비교적 쉽게 진입할 수 있는데, 데이터 분석 업무는 약간 성격이 달라서 새로운 접근이 필요하지 않나 싶습니다. 저는 DB 엔지니어들이 하는기 위해 조인을 걸고 하는 정도로 알고 있어요. 성능을 높이는 접근은 아니예요. 데이터 분석 영역은 코딩력이 필요하다고 하는데, 이것도 절대적이지는 않다고 느꼈어요. 제 경험을 기준으로 보면, 감을 잡는 것이 아닐까 합니다.

어떻게 해야 이 데이터에서 내가 원하는 걸 뽑을 수 있을지 감을 잡는 실력이 필요해요. 데이터를 돌려보고 어느 게 중요하네! 하고 알아볼 수 있는 실력 말입니다. 직접 데이터를 돌려보거나 그림을 그려보거나 표로 보거나 하면서 해당 데이터에 대한 감을 잡습니다. 어떤 걸 해줘야 내가 원하는 데이터 분석이 가능하다는 감을 잡아 그걸 기준으로 분석하는 것이지요.

한정된 물과 식량을 주고 깊은 산속에서 길을 찾아 탈출하라는 미션이 주어졌다고 해보죠. 자신의 온갖 지식과 감을 총동원하여 길을 찾아야 하잖아요. 데이터 분석도 그런 과정과 조금은 비슷하다고 봐요. 그러다 보니 분석 분야에서는 전공과 관련 없이 촉이 발달한 사람을 뽑으려는 거 같아요. ‘촉’ 또는 ‘감’을 갖고 데이터를 다뤄본 경험이 데이터 사이언티스트에게 필요한 거 같아요.

전처리 작업이 업무의 70~80% 차지

실제로 데이터 분석 업무의 70~80%는 전처리 업무라는 걸 실감합니다. 전처리 작업은 내가 원하는 분석을 하기 위해 널값이나 눈에 띄는 이상한 것을 빼고 변환하는 과정이죠. 주어진 데이터에서 내가 원하는 것을 어떻게 끌어낼 수 있는가에 대한 모든 고민과 시도를 딱 한 단어로 표현한 것이 바로 바로 전처리입니다.

“다양한 분야의 데이터를 경험함으로써 어떤 데이터를 만나더라도 자신 있게 접근하고 싶습니다. 나중에는 CDO(Chief Data Officer)를 꼭 해보고 싶네요.”

전처리 작업이 끝나면 모델을 선정해 돌려보고 테스트하는 것은 정말 금방입니다. 그 과정에서 머신러닝을 적용하여 ‘정확도가 이 정도 나왔네’ 하고 확인하면서 분석하기도 합니다.

감을 잡는 것은 업무 특성상 개발자에게는 상대적으로 낯선 일일 거 같아요. 보통 개발 업무는 로직에 따라 코드를 짜서 목표 지점에 도착하는 거 잖아요. 일의 경중을 얘기하는 게 아니라 업무 성격 말입니다. 제 경험으로 보면 프로그래밍 측면에서 접근하면, 조금 위험했어요. 정확도 위주로 본다거나 효율 중심으로 보는 매트릭에 빠질 수 있어요.

코드 수행에서는 좋은 결과물이라는 게 있잖아요. 버그가 없어야 하는 건 당연하지만, 더 효율적으로 돌어가야 한다, 결과가 빨리 나와야 한다는 기준만 염두에 두면 그 기준에 매몰될 수 있어요. 그것보다는 어떻게 해야 고객이 원하는 값을 도출할 수 있을까?가 더 중요하죠.

물론 입맛에 맞는 결과를 제시해야 한다는 말이 아니라, 맞는 결과가 나왔는데 이게 정말로 고객이 원하는 형태인가? 아니면 다른 게 필요한가?를 늘 염두에 두고 접근해야 하는 거죠. 일을 하다 보면 되게 본질적이고 주관적이라는 느낌마저 들 때가 있어요. 어찌 보면 근거가 되는 데이터의 속성과는 배치되는 것 같기도 하고요. 정확한 룰에 따라서 정확하게 짜면 정확한 값이 나올 것이라는 코딩의 기본 원칙과 다르기 때문에 애매하다고 여겨질 때도 있고요.

통계적으로 분산된 데이터에서 어떤 걸, 어떻게 골라서 어떻게 변환하고 어떤 알고리즘을 적용하는냐에 따라 결과도 달라질 수 있어요. 대푯값 하나만 내는 것이 아니고 오차 범위 안에서 움직이고 있다는 것을 제시해야 하죠. 이 지점을 개발자들이 받아들이기 힘들어할 수 있다고 봤어요. 저 스스로는 10~20% 정도의 개발자 마인드를 가지고 있다고 생각하는데, 물론 분석에 어느 정도는 개발력이 필요하지만 그게 주된 접근 방식이면 힘들 거라고 생각합니다.

‘어느 분야 데이터를 만나더라도 자신 있는 분석가’

아직 사회생활 초년생이니까 회사 일을 잘 파악하는 것이 우선입니다. 짧게는 공공, 금융, 전자업 등 분야를 막론하고 다양한 분야의 데이터를 접해보고 어떤 데이터를 만나더라도 자신 있게 접근하고 싶습니다. 길게는 CDO(Chief Data Officer)가 되고 싶습니다. 직장의 한 동료께서 얼마 전에 CDO로 가는 것을 보았는데 저도 모르게 CDO가 되고 싶다는 생각이 들더라고요. (끝)

출처 : 한국데이터산업진흥원
제공 : 데이터 온에어 Dataonair.or.kr