데이터 사이언티스트로 했던 실수들

이 글은 원문 Mistakes I’ve Made As A Data Scientist by Chris I.를 저자의 동의하에 번역한 글입니다. 흔쾌히 번역에 동의해 주신 저자 Chris I. 님께 감사의 말씀을 드립니다.

필자가 데이터 사이언티스트로 일하면서, 개인 경력이나 회사의 발전을 더디게 한 실수를 모아봤다.

  • 다양한 데이터 사이언스 직업이 있다는 것을 알지 못한 점
  • 멘토가 없던 점
  • 프로젝트가 실패했을 때 인정하지 못한 점
  • 프로젝트가 끝난 후 보고서 작성을 하지 않은 점
  • 도움 요청을 지연한 점
  • 아무것도 모른다는 것을 인정하지 않은 점
  • 프로젝트 없이 학습한 점
  • Exploitation vs Exploration의 잘못된 균형
  • 재사용할 수 있는 함수를 쓰지 않은 점
  • 도메인 지식의 중요성을 과소평가한 점

다양한 데이터 사이언스 직업이 있다는 것을 알지 못한 점

예측 모델링(Predictive Modelling) 업무를 예상하고 “데이터 사이언티스트”로 입사한 경험이 있다. 하지만 필자의 예상과는 달리 백엔드 어플리케이션 코드 작성 일을 했다. 필자가 전에 일했던 데이터 사이언스 직업에서는 모델 구축 일만 했었기 때문에, 당연히 다른 데이터 사이언스 직업도 같은 일을 할 것이라고 착각했다.

실제로는 “데이터 사이언스”라는 큰 틀 안에서는 다양한 종류의 직업이 존재한다. 이에 더불어 JD(Job Description)가 엉망으로 되어있다면 굉장히 혼란스러워진다.

데이터 사이언스 채용 공고를 훑어본다면, 직업 공고가 전부 아래의 분야 중 하나에 해당된다.

  • 비즈니스 인텔리전스
  • 데이터 분석
  • 머신러닝 엔지니어링
  • 데이터 엔지니어링
  • 소프트웨어 엔지니어링

취직하기 전에 먼저 직업의 세부 사항을 자세하게 알아야 한다. 면접을 보는 팀의 팀원과 얘기하며 알아내는 것을 추천한다. 그렇지 않으면 이직하자마자 새로운 직업을 찾게 될 수 있다.

멘토가 없던 점

필자는 한 머신러닝 문제로 한 달 동안 머리를 싸맨 경험이 있다. 하지만 새롭게 만난 멘토가 추천한 특정 기술로 일주일 만에 손쉽게 해결했다.

무엇을 모르는지를 몰랐다.

필자는 당시 존재하는 NLU 기술을 전부 알 수 없었다. 하지만 PhD를 취득하고 NLU 분야에 경험이 있는 필자의 멘토는 전부 알았기 때문에 도움을 받을 수 있었다.

You don’t know what you don’t know.
무엇을 모르는지를 모른다.

스타트업에서는 종종 익숙하지 않은 분야까지 일해야 하는 상황도 생긴다. 만약 그 분야에 익숙하지 않다면, 해결책을 검색하는 것조차 힘들 수 있다. AI 같은 고도의 기술 분야에서, 같이 아이디어를 공유할만한 시니어 엔지니어나 멘토가 없다면 일하기 까다로울 것이다.

프로젝트가 실패했을 때 인정하지 못한 점

대체용 모델을 만드는 데에 2주를 투자했지만, 기존 모델의 퍼포먼스가 여전히 더 좋았던 적이 있다. 손실을 줄이는 대신, 퍼포먼스를 개선하고자 파이프라인을 고치는 데에 2주를 더 보냈다. 하지만 여전히 효과는 없었고, 결국 새로운 모델과 시간을 전부 버렸다.

Timeboxing은 그만두라고 했지만, 괜한 자존심 때문에 멈출 수가 없었다.

데이터 사이언스 팀에 고립된 사람들은 회사의 우선순위에 대해 완전하게 모를 수 있다. 우리가 가치를 더할 수 있는 프로젝트는 무궁무진하다. 그중 일부는 실패할 수 있지만, 계속해서 나아가야 한다.

중요하지 않은 프로젝트에 시간을 지나치게 사용했고, 시간을 더 투자하더라도 성공을 보장할 수 없다면, 포기하는 게 종종 현명한 해결책이다.

프로젝트가 끝난 후 보고서 작성을 하지 않은 점

필자가 일하는 스타트업의 우선순위가 바뀌면서 일 년 반 전에 그만뒀던 NLP 프로젝트를 다시 진행하게 되었다. 하지만 시도해본 접근이나 연구에 대한 보고서가 없었기 때문에, 처음부터 다시 시작해야만 했다.

스타트업의 우선순위는 바뀔 수 있기 때문에, 그만둔 프로젝트를 다시 시작하는 경우가 종종 있다.

프로젝트가 실패하면 원인을 기억하지 못하기 마련이고, 경영진은 같은 프로젝트를 다시 시도하길 원할 수 있다. 커밋한 코드, 연구에 대한 링크, 그리고 시도된 내용에 대한 보고서가 있다면, 참고해서 빠르게 프로젝트를 다시 시작하기 쉽다.

도움 요청을 지연한 점

필자는 사람들의 시간을 낭비하는 것을 싫어한다. 주로 조언을 더 구하기 전에 시니어나 멘토가 추천한 것들을 전부 시도해 본다. 이를 위해 미팅도 미룬 적이 있다. 즉 교과서적인 완벽주의자 같은 사람이다.

너무 일찍 도움을 청하는 것과 너무 늦게 도움을 청하는 것은 종이 한 장 차이다.

누군가가 당신의 멘토가 되기로 동의했다면, 당신을 돕고 싶어 할 것이다. 그리고 당신이 잘못된 길로 가고 있을 때, 당신의 멘토는 도움을 줄 경험을 가지고 있다.

조언을 구하고, 시도해보고, 후속 조치(follow up)를 취하라.

스스로 문제를 해결할 수 있다면, 당신은 멘토가 필요하지 않을 것이다.

아무것도 모른다는 것을 인정하지 않은 점

머신 러닝 경력을 쌓기 훨씬 전, 필자는 커피를 마시며 첫 AI 멘토를 만났다.

멘토: 이전에 머신러닝을 사용해 본 적이 있나요?
필자: 신경망(Neural Networks)이요.
멘토: 어떤 프레임워크를 썼죠?
필자: 음… 파이썬이요.

사실 필자가 실제로 머신러닝에 대해 알고 있던 거는 Andrew Ng의 Deep Learning 수업에서 들은 몇 가지 레슨이 전부였다. 하지만 똑똑해 보이고 싶었다.

결국 그 멘토와 같이 일하게 되었지만, 필자처럼 모르는 것을 아는 척하지 말아라. 한 분야에 경력을 가진 사람들은 멀리서도 거짓말을 쉽게 알아차릴 수 있기 때문이다. 또한, 멘토의 입장에서도 모르는 것을 인정한 사람을 돕기 더 쉽다.

프로젝트 없이 학습한 점

필자는 더 이상 기억하지도 못하는 기술과 이론에 대해 읽으면서 몇 달의 시간을 보냈다. 노트와 이름 없는 쥬티퍼 노트북(Jupyter notebooks)은 어쩔 수 없이 분실된다.

반대로 실행되는 앱에 접목하거나, 쥬피터 코드로 쓰거나, 블로그 글을 쓴 내용은 전부 기억한다. 뿐만 아니라 나중에 코드를 참고하는 데 쉽다.

시간을 할애해서 배운 것들을 사용해서 어떤 종류의 결과물이든 만드는 것을 추천한다.

Exploitation vs Exploration의 잘못된 균형

MABP(Multi-Armed Bandit Problem. 다중 무장 도적단 문제)에 참고하자면, Exploitation은 이미 알고 있는 기술을 사용하는 반면, Exploration은 새로운 기술을 탐구하며 시도하는 것이다. Exploitation과 Exploration, 둘 다 필요하다.

몇몇 머신 러닝 라이브러리에만 너무 익숙해지는 것에도 문제가 있다. 모든 머신 러닝 문제들을 이미 알고 있는 기술의 범위에서만 보게 된다.

필자의 경우, 필자가 Sklearn으로 구현한 기능을 한 번도 들어본 적이 없는 라이브러리가 훨씬 능가한 적이 있다.

새로운 문제를 해결하기 시작할 때, 제일 원리 접근 방식을 통해 항상 탐구하길 바란다.

재사용할 수 있는 함수를 쓰지 않은 점

Cleaning, lemmatization, 벡터화, 모델 선택 등을 포함한 표준 NLP 파이프라인 구축을 하는 면접 과제를 받은 적이 있다. 시간이 제한되어있었기 때문에, 재사용할 수 있는 파이프라인 모듈이 있었으면 좋았을 것 같다고 생각했다.

천재처럼 30분 만에 프로젝트를 끝내는 대신, 몇 시간에 걸쳐 완성해야 했다. 면접 단계는 통과했지만, 미리 준비한 모듈이 있었다면 더 쉬울 수 있었다.

I choose a lazy person to do a hard job. Because a lazy person will find an easy way to do it.

나는 게으른 사람에게 어려운 일을 맡길 거다. 게으른 사람은 일하는 데 쉬운 방법을 찾을 것이기 때문이다.

빌 게이츠 (Bill Gates)

만약 쥬피터 노트북에 같은 코드를 한 번 이상 쓴다면, 재사용 가능한 모듈을 쓰는 것을 추천한다.

도메인 지식의 중요성을 과소평가한 점

잘못된 기능을 사용하는 머신 러닝 파이프라인을 구축한 적이 있다. 업계에서 필요로 하지 않는 제품을 만드는 회사에서 일 한 경험도 있다.

업계에 대해 잘 이해하고 도메인 지식을 갖는 것은 소프트웨어 개발에서 가장 과소평가 되는 부분이다.

도메인 지식은 코딩 스킬보다 습득하기 더 어렵다. 몇 년 동안 해당 도메인에서 일하며 얻을 수 있다.

  1. 도메인 지식에는 전혀 관심이 없는 엔지니어들은 주의해야 한다. 어느 순간 한계에 도달할 것이다.
  2. 창업자 중 적어도 한 명이 프로덕트의 업계에 많은 경험을 가지고 있을 때만 스타트업을 조인해라.

--

--