신입 데이터 분석가의 좌충우돌 성장기
상태바
신입 데이터 분석가의 좌충우돌 성장기
  • 데이터넷
  • 승인 2019.02.11 14:31
  • 댓글 0
이 기사를 공유합니다

원만한 의사소통 능력·도메인 지식 갖출수록 유리…상시 코드 확인은 필수

데이터 분석 역량이 중요해지면서 데이터 분석가를 필요로 하는 곳들도 늘어나고 있다. 그러나 아직까지 데이터 분석 분야의 진입 장벽은 높은 편에 속하는 것으로 알려져 있으며, 이에 데이터 분석에 흥미가 있어도 쉽게 도전하지 못 하는 이들도 많은 편이다. 데이터 분석가를 꿈꾸는 이들을 위해 신입 데이터 분석가로서 그동안 수행했던 프로젝트 경험을 공유하며, 데이터 분석가가 되기 위해 필요한 점, 그리고 어려운 점은 어떤 것들이 있는지 알아본다. 

▲ 배병선 애자일소다 AI 알고리즘 연구팀 선임연구원(byung2070@agilesoda.com)

필자는 2017년 1월 2일 인공지능(AI) 서비스 및 소프트웨어 기업 애자일소다에 입사하며 데이터 분석가로서의 첫 발을 뗐다. 그 이전에는 1년여 동안 통계학과 학부연구원 생활을 하며 다양한 분석 언어와 도구에 대한 탐사 및 분석에 대한 기초 훈련을 받았다.

신입 분석가였지만 스타트업에서 일하기에 다양한 기회가 주어졌으며, 생각했던 것 이상의 경험을 할 수 있었다. 이를 토대로 데이터 분석가를 꿈꾸는 이들에게 그동안의 경험을 공유하면서 데이터 분석가의 길에 대해 소개하는 한편, 스스로도 더 열심히 달려나가기 위해 마음을 다잡아보려 한다.


결과는 반드시 공유하라

이 회사에 들어와 가장 기억에 남는 프로젝트가 두 가지 있다. 그중 하나는 2018년 초에 한 달간 어느 제조사의 파일럿 프로젝트 수행에 참여했던 것이다. 목표는 한 부품을 생성하는 공정에서 찍은 엑스레이 이미지를 통해 부품의 불량 여부를 결정하는 모델을 만드는 것이었다.

출발은 순조로웠다. 데이터 라벨링에 일관성이 없는 것이 보였지만 수작업을 통해 분류하고, 모델 구조도 디자인해서 학습을 시키니 검증 셋(Validation Set, Out-of-Sample)에 대해 98%의 정확도를 보였다. 정확성(Precision), 재현율(Recall), 그리고 AUC(Area Under Curve) 등의 지표도 수치상 상당히 높은 수준이었다. 물론 거의 100% 정확도를 목표로 해야 했지만, 주어진 기간 동안 가능성만 확인하는 것이었기 때문에 가능한 한 최선을 다했다.

그러나 미처 알아채지 못한 실수가 있었다. 바로 고객이 요구한 테스트 셋(Out-of-Time) 데이터에 대한 검증 결과를 공유하지 못한 것이다. 기존 검증 셋에 대한 검증 결과는 좋았지만, 검증 셋에 대한 정확도는 기대보다 안 좋은 결과를 보였다.

고객에 실망감을 주고 싶지 않다는 생각에 공유하지 않고, 개선을 위해 이런저런 시도만 하다가 놓쳐버린 것이다. 어디에 메모도 해두지 않았기에 까맣게 잊고 있었다.


혼자만의 판단은 금물

그렇게 프로젝트는 끝났고 3주 뒤 고객에게서 연락이 왔다. 왜 결과가 잘 나오지 않느냐는 문의와 함께 결과를 공유하지 않은 것에 대한 질책을 받았다. 이때 회사 생활을 하면서 처음으로 엄청난 자책감을 느꼈다. 내가 얼마나 부족하고 무책임한 사람이었는지 깨닫게 됐다.

결국 고객사에 가서 잘못을 인정하고, 고객과 함께 이야기해 돌파구를 찾으려 노력하면서 마무리 될 수 있었다. 그 이후로는 이슈가 있을 때마다 휴대폰, 태블릿, 노트, 메모장에 전부 기록하는 습관을 만들었고, 새로운 정보는 고객과 반드시 공유했다.

고객의 요구사항은 꼭 기억해야 할 뿐만 아니라 그 요구사항에 대한 정확한 확인이 필요하다. 가능한 것과 불가능한 것은 합리적으로 구분해 설득할 수 있어야 하고, 안 좋은 결과도 공유해 다각도로 해결책을 모색해야 한다. 그래야 투입 인력 혹은 프로젝트 기간 조정을 검토하거나 다른 방법으로 접근하는 등 대처할 수 있는 방안을 찾을 수 있다.

프로젝트 매니저(PM: Project Manager)가 있다면 PM에게 진행 상황을 공유해야 하며, 끊임없이 논의해야 한다. 절대 지양해야 할 것은 스스로 판단해 결정하는 것이다. 개인의 판단이 언제나 정답은 아니며, 프로젝트는 참여자들이 함께 협력할 때 가장 최상의 결과를 낼 수 있기 때문이다.


도메인 지식 확보 노력 필요

기억에 남는 또 다른 프로젝트는 마무리 된 지 얼마 되지 않았기에 더욱 생생하다. 2018년 가을 무렵부터 약 4개월간 머신러닝 관련 프로젝트를 진행했다. 해당 프로젝트는 A사 및 B사와 협력해 기업신용평가 솔루션을 만드는 프로젝트였고, 그중 애자일소다는 머신러닝 알고리즘을 이용한 모형을 만드는 작업을 수행했다.

A사는 과제를 만들고, B사는 데이터를 제공해주는 역할을 맡았다. A사에서는 실력 있는 분석가가 참여했는데, 함께 일하며 많은 것을 배웠다.

전하고 싶은 내용은 크게 세 가지다. 첫 번째는 데이터를 파악하는 단계에서 도메인 지식에 관한 이야기이다. 기업신용평가모형이다 보니 재무데이터를 사용해야 했다. 관련된 항목들은 매우 많았다. 그러나 그 데이터들을 어떻게 다뤄야할지 당최 감을 잡을 수가 없었다.

처음에는 질문 리스트조차 작성하지 못했는데, 이대로 진행하다가는 아무 것도 하지 못할 것이라는 생각이 들었다. 그래서 우선 각 항목별로 데이터가 어떻게 묶여있는지 살펴봤다.

예를 들어 당좌자산, 유형/무형자산 등의 항목은 대차대조표, 매출총이익과 영업이익 등은 손익계산서로 묶여있었다. 항목을 하나씩 다 살펴보기에는 양이 많았고, 실제로 사용되지 않는 항목도 있기 때문이다.

다행히 데이터를 제공해주는 B사도 기업신용평가모형을 보유하고 있었기 때문에 실사용 항목들에 대해 문의할 수 있었다. 이처럼 도메인 지식에 대해 잘 모를 때 내가 알아가는 것도 중요하지만, 주변에 해당 문제를 알고 있는 사람이 있다면 의사소통을 하는 것이 제한된 시간을 효율적으로 사용하는 방법이다.

물론 100% 다 이해할 수는 없다. 하지만 최소한 데이터를 다루는데 있어 필요한 지식을 얻을 수 있다. 

▲ 2018년 10월 열린 R사용자 컨퍼런스에서 신입 분석가로서 경험을 공유하는 발표를 진행하는 모습.

잦은 코드 확인으로 실수 없애야

두 번째는 데이터를 다루는 부분이다. 모형을 만들기에 앞서 타깃 정의는 문제 해결의 방향에 따라 바뀔 수 있다. 바꿔 말하자면, 데이터를 잘못 다뤄서 타깃이 이상하게 정의되면 문제 방향과 어긋나기 때문에 매우 중요한 작업이다. 사실 이 부분에 있어서 필자도 여러 번 실수한 경험이 있다.

대개 실수는 작은 것에서부터 시작된다. 타깃 정의 로직 및 코드를 정리하다 보면 하나씩 발견되는데 ‘~보다 크다’와 ‘~보다 크거나 같다’는 확실히 다른 로직이다. ‘~보다 크거나 같다’는 로직이 들어가야 하는데, 코드에 ‘=’ 하나를 빼먹어서 ‘~보다 크다’는 로직이 들어가 버린 것이다.

또 다른 실수는 타깃과 x인자들 간의 매핑(Mapping)이었다. 모형을 만들 때 사용하는 데이터는 재무데이터 이외에도 비재무데이터가 존재하는데, 비재무데이터는 월별 정보이고 재무데이터는 연도별 정보다.

타깃 정의 시 비재무데이터는 조회시점을 기준으로 1개월 이전 시점의 것을 사용하고, 재무정보는 조회시점을 기준으로 1년 이전 시점의 것을 사용해야하는데, 시점 기준을 조회시점이 아닌 다른 시점을 기준으로 설정해버린 것이다.

이를 발견할 수 있었던 것은 코드 리뷰였다. 데이터 분석가로서 R이나 파이선 등 코드를 작성해 분석을 하는 분들은 코드 리뷰를 상시 잘해야 한다. 특히 본인이 생각한 로직과 작성된 코드가 일치하는지를 틈틈이 살펴봐야 한다. 대충 코드만 보는 것이 아니라 실제로 실행해보면서 확인을 제대로 해야 한다.


원활한 의사소통 위해 노력해야

세 번째는 의사소통이다. 해당 프로젝트에서 개인적으로도 몹시 아쉽게 여겼던 부분이다. 프로젝트를 진행하던 중 이슈가 발생해 회의를 진행하면서 처음에 정의했던 문제의 방향이 A사가 원하는 방향이 아니라는 것을 알게 됐다.

회의가 끝난 후 A사의 현업 팀에서 원하는 방향을 전달해왔다. 문제는 거기서 끝나는 것이 아니었다. 문제 정의 자체가 계속 바뀌고 수정된 탓에 필자가 그 속도를 따라가지 못하는 사태가 발생한 것이다. 그 상태에서 내부적으로 의사소통을 하려니, 서로 사용하는 단어가 달라졌고, 의사소통에 문제가 생기기 시작했다.

필자의 부족한 점 중 하나는 원활한 의사소통이 되지 않을 경우 긴장하면서 상기된 상태로 이야기를 하게 된다는 점이다. 긴장한 상태로 의사소통을 하려면 할수록 에너지만 소모될 뿐, 제대로 된 해결책이 나오지 않는다. 스스로도 너무 안타까웠고, 다음 프로젝트를 수행할 때 이 같은 습관을 정말 고쳐야 하겠다는 생각이 들었다.

협업을 위해서는 다소 시간이 들더라도 침착하게 이해하고 정리하려 노력해야 한다. 비교적 기간이 길었던 프로젝트이자 동시에 많은 것을 깨닫고 배울 수 있었던 프로젝트로 기억된다. 


업무 능률 높이기 위해 꾸준한 공부 병행

필자의 글을 관심 있게 본 독자들은 분석가를 꿈꾸고 있거나 분석가의 일에 대해 알고 싶은 이들이라 생각한다. 데이터 분석가나 데이터 사이언티스트는 흔히 떠올릴 수 있는 이미지와는 달리 직접적인 노동을 한다. 그 노동은 컴퓨터를 통해 이뤄지므로, 일을 얼마나 잘 할지의 여부는 어떤 상황에서 어떤 도구를 사용해야 하는지 알고 아는 것에서부터 판가름 난다.

그렇기에 지속적인 공부는 필수다. 취업을 준비하면서 여러 가지 강의나 과정을 통해 공부를 하겠지만, 절대 그것으로 끝나는 것이 아니다. 당장 쓸 일이 없더라도 꾸준히 학습하다 보면 언젠가는 그 지식을 활용할 날이 반드시 올 것이라 생각한다.

그렇다고 공부만 하라는 것은 절대 아니다. 시간을 효율적으로 활용하면서 일과 삶을 즐길 수 있는 분석가가 되기를 바라기에, 그 방법을 미리 찾아보라는 것이다. 미래 데이터 분석가를 꿈꾸는 이들이 필자가 저질렀던 실수와 같은 경험들을 하지 않길 바란다. 


댓글삭제
삭제한 댓글은 다시 복구할 수 없습니다.
그래도 삭제하시겠습니까?
댓글 0
댓글쓰기
계정을 선택하시면 로그인·계정인증을 통해
댓글을 남기실 수 있습니다.