데이터, 어디까지 알아야 할까?
단단한 성장을 위한 공부
비단 데이터 지식뿐만 아니라, 테크 업계에서는 새로운 지식들이 매일같이 쏟아진다. 새로운 것을 배워나가는 일은 언제나 즐거운 일이지만, 업계에 있는 사람들 입장에서는 이것도 알아야 할 것 같고 저것도 알아야 할 것 같은 압박감에 시달리기도 한다. 무엇보다, 시간은 한정되어있기 때문에 어떤 것을 먼저 공부할지 결정하는 일은 무엇보다 중요하다.
SQL은 모두에게 중요하다.
최근에는 SQL 강의를 활발하게 진행하고 있다. 처음에는 사내 동료들을 위해 간단하게 준비해서 진행했던 것이, 외부분들에게 오픈하여 소규모 그룹 강의로 진행을 하며 점점 스케일이 커졌고 최근에는 운이 좋게 다른 기업에서도 퇴근시간을 활용하여 강의를 진행하고 있다.
다양한 직군 분들이 학습자로 참여해주셨는데, 퍼포먼스 마케터, B2B Pre-Sales, Business Develoment 그리고 프런트엔드 개발자 분들까지 매우 다양한 분들이 참여해주셨다. 직군은 다양했지만 왜 SQL을 배우고자 하시냐는 질문에는 다른 사람의 도움 없이 직접 데이터를 추출하고 원하는 질문에 대한 대답을 찾기 위해 SQL이 실무에서 중요하다고 말씀해주셔서 동일한 생각을 가지고 계시는구나 하는 것을 알 수 있었다.
아까운 퇴근 후 저녁 시간을 투자하는 분들인 만큼 어느 한 분 따질 것 없이 배움에 대한 열정에 가득하시다. 내가 진행하는 SQL의 경우, 처음 접하는 입장에서는 문법이 그렇게 어렵지 않다. 그러다 보니 어떤 개발자/직장인 분들은 SQL은 프로그래밍 언어가 아니라고 말하는 경우도 종종 보게 된다.
하지만 SQL은 Structured Query Language의 약자로서, 엄연한 Language이다. 처음 시작하는 입장에서 데이터를 가져오기 위해 작성해야 하는 코드가 매우 간단한 것도 사실이지만, 조금만 더 들어보면 DB 전반의 지식과 실행되는 원리까지 이해해야만 효율적이고 간단하게 코드를 작성할 수 있게 된다. 시작까지는 쉽지만, 잘 쓰기에는 노력이 필요하다는 뜻이다.
SQL은 배우기에는 쉽지만, 사용하기에 따라서는 매우 강력하게 쓸 수 있는 매력적인 언어이기도 하다. 개발을 하지 않더라도, 서비스에 대한 간단한 질문들에 대해 답해줄 수 있고 사업 전체의 KPI를 관리하는 데에도 빼놓을 수 없기 때문이다. 나의 경우에도 문제를 정해두고 답을 찾아나가는 분석 업무와 KPI 관리를 진행하는 데에 7~80%는 쿼리 작성에 시간을 쓰고 있다.
데이터 공부를 같이하던 친구들을 만나서 이야기를 나누어도 SQL에 대한 이야기는 빠지지 않고 나온다. 비디오 생방송 서비스를 하는 회사에 머신러닝 엔지니어로 취업한 친구도 SQL이 약하니 모델링에 쓰일 데이터를 추출할 때 백엔드 개발자에게 아쉬운 소리를 해야 해서 최근에는 다시 공부를 시작했다는 이야기를 꺼냈다. 비단 분석 포지션뿐 아니라 머신러닝 엔지니어 포지션에서도 SQL의 중요성은 빠지지 않고 등장한다는 뜻이다.
어디에 집중해야 할까?
이런 상황에도 불구하고, 데이터 공부를 시작한다는 분을 주변에서 보면 십중팔구는 SQL보다는 Python이나 R과 같은 언어를 통해 머신러닝 공부를 먼저 하는 것을 자주 목격하게 된다. 지금 와서는 매우 안타까우면서도 또 매우 공감되는 부분인데, 왜냐하면 나도 데이터 공부가 하고 싶었을 때 닥치는 대로 보이는 것을 하면서 시작했던 것이 케글(Kaggle)과 같은 사이트에 들어가 csv로 된 데이터를 다운로드하여 파이썬이나 R로 스크립트를 짜고 머신러닝 라이브러리를 적용하는 등의 공부였기 때문이다. (그렇게 적용하면서도 해당 알고리즘에 대한 이해도는 높지 않았다. 단지 데이터를 형태에 맞게 넣고 정확도만 체크해봤을 뿐)
강의를 제공하는 학원들을 돌아다녀보아도 상황은 비슷한데, 파이썬으로 업무를 자동화한다거나 매우 핫한 머신러닝 알고리즘(Ex; 랜덤 포레스트)을 엑셀로도 돌릴 수 있게 해 준다거나, 그것도 아니면 케글 상위권을 달성하는 방법을 알려준다는 식의 ML/DL 기반의 강의들이 대다수다.
상황을 유추해보았을 때, 이러한 강의는 SQL과 달리 케글에서 다운로드한 csv 등으로도 로컬에서 진행이 가능하며 좀 더 널리 알려져 있는 반면 SQL은 DB에 접근해야 하는 환경이 주어져야만 그 필요성을 깨달을 수 있다는 점과 강의 진행이 가능하다는 점 때문에 '강의의 용이성'이라는 측면에서 좀 더 머신러닝/딥러닝 기반 강의들이 우세하지 않나 하는 생각이 든다. (그리고 무엇보다.. 더 멋있어 보인다. 왠지 데이터 하는 사람이 되었다는 느낌을 팍팍 준다.)
이러한 ML/DL 강의와 공부의 필요성을 폄하하려는 것은 절대로 아니다. 딥러닝은 충분히 핫하고, 지금까지 분기문으로만 프로그래밍해와서 풀 수 없었던 문제들을 해결할 수 있기에 앞으로 주류로 떠오를 것이라는 주장에 매우 동의한다.
다만, 데이터라는 분야를 커리어로 삼기 위해 오랜 수련을 통한 전문가의 길을 걸으려는 사람이 아닌 이제 막 데이터의 중요성을 깨닫고 조금씩 활용하고자 하시는 내가 만난 학습자 분들과 같은 일반 직장인들에게 과연 ML/DL 지식들이 실무에 있어서는 얼마나 의미가 있을지에 대해서는 여전히 의구심이 든다. 실제 업무에서의 활용도 측면이 아닌, 강의를 제공하는 강의자의 편의에 맞춘 흐름이 아닌가? 데이터를 처음 접하는 사람에게 권할만한 내용들인가? 하는 의문이 여전히 해결되지 않고 있다.
앞으로의 노력 방향성
지금 진행하는 강의뿐만 아니라, 향후 커리어를 설정하는 데에 있어서도 최근에는 같은 고민이 있었다. 지난 몇 년간 기회가 닿을 때마다 ML/DL등에 대한 지식을 쌓으려고 노력했었고 추천 시스템에 대한 논문 리딩 모임에도 참석했었는데, 막상 실제 서비스에 이를 적용하기 위해서는 오히려 Data Pipeline은 어떻게 구성해야 할지, 태스크 관리는 어떤 방식으로 해야 하는지, 학습용 데이터를 통해 모델을 갱신하기 위한 주기는 어떻게 설정해야 할지, 어떤 데이터를 학습 Feature로 사용해야 할지와 같은 데이터 엔지니어링 분야의 내용이 실무적으로는 더 중요하다는 것을 깨달았기 때문이다.
실제로 모델링을 하여 정확도를 높이는 과정에서는, 작고 귀엽게나마(?) 쌓아왔던 수학/알고리즘 지식은 사실 별로 중요하지 않고, 이미 너무 잘 나와있는 최신 머신러닝 라이브러리를 찾아 조건들을 이리저리 변경해보며 복권 긁듯이 정확도를 올리는 다소 노가다(?)성 작업을 진행하는 상황이 연출되곤 했다. (실제로 수학적 지식은 매우 중요하다. 다만 내 상황에서는 겉핣기로 배운 지식이 크게 도움이 되진 않았다는 말을 하고 싶었다.)
가장 압권이었던 것은 이번 추천 시스템을 적용하기 위해서 구입했던 '실전 머신러닝'이라는 책의 첫 구절이었는데 서비스에 머신러닝을 적용하기 위해서 가장 먼저 고민해야 하는 질문은 '정말 머신러닝을 적용해야만 풀 수 있는 기술적 문제인가?'를 충분히 고민하고 아니라면 과감히 머신러닝은 포기하라는 말이었다. 우리가 아는 것보다 머신러닝 기술은 기술 부채도 클뿐더러 차후 관리 리소스도 많이 들어가는 기술이기 때문이다.
그래서 수학/통계적인 지식으로 무장한 사람보다는 조금 덜 화려해 보일지라도 단단한 지식을 가진 엔지니어링 지식 기반의 분석가로 성장하고 싶다. 서비스에 Log를 심어서 사용자들의 행동을 추적하는 업무를 시도했었는데, 300개가 넘는 이벤트/액션들을 정리하고 설계하는 일은 결코 화려하거나 멋진 일은 아니었다. 하지만, 그 단순한 작업들이 모여 보여주는 숫자들은 서비스를 개선하는 데에 충분히 임팩트 있고 중요한 단단한 역할을 해주기 때문이다.
데이터 엔지니어들을 채용하는 공고나 데이터 엔지니어를 지망하는 사람들이 공부하는 로드맵을 참고해보면 어떤 지식을 채워야 하는지에 대한 실마리를 얻을 수 있었는데 자료구조와 같은 펀더멘털한 지식이 기반이 되어야 하고 대규모 데이터를 다루기 위해 탄생한 오픈소스(Ex; Airflow, Kafka, Hadoop)등에 대한 경험이 중요한 요소인 것 같다.
당분간은 위와 같은 지식/경험들을 할 수 있는 환경에 노출되도록 신경을 써야겠다.
+ 21.03.21 업데이트
- "방향성이 트렌디하고 잘 될 것 같은 것들을 단순히 추종하는 선택을 하는거 아니냐" 라는 피드백을 받았다. 개발이 진짜 즐거운 개발자들은 그냥 그 자체를 즐기는 느낌이라면 나는 좋아보이는 것들을 선택을 하고 있는 것 아니냐는 의견.
- 그 자리에서는 그렇게 보일 수도 있을 것 같다고 대답하고 뒤에 더 생각해보니 그 피드백은 반은 맞고 반은 틀리다는 생각이 들었다. 기존에 재미를 느끼고 파고들었던 부분은 분석쪽이었다. 그 분석을 하기 위해 기술이 필요했고 배워나갔던 것들이 CS지식, SQL, Python같은 도구들 이었기 때문이다. 분석이 회사에서 활용되는 것에 의문이 들었고 방향성을 변경해야겠다고 생각했다. 그렇기 때문에 분석을 벗어나 엔지니어로 가려는 방향성에 대한 위의 피드백은 어느정도 맞는 말이다.
하지만, 잘 생각해보니 데이터를 저장하고 가공하는 언어를 다루는 것에서 오는 만족/흥미가 있다는 것 역시 뒤에 깨달을 수 있었다. 대부분의 작업은 고되지만 SQL, Python으로 데이터를 문제 없이 서빙하고 가공하는 인프라 구축에서 오는 재미를 느끼기 때문이다.
그렇기 때문에 분석가가 아니더라도 데이터를 다룰 수 있는 엔지니어 직군이라면 만족하고 일할 수 있다고 판단했고, 최근 받았던 피드백에 반은 아니라고 말할 수 있을 것 같다. 디테일한 직군의 변화는 있었을지 몰라도 데이터의 활용성을 목표로 한 지향점은 아직 변하지 않았다.
- Gradient Descent하듯이 내 커리어도 가고 있다. Global Optima인지는 모르겠는데 일단 지금은 내게는 Local optima는 되는 것 같다.
참고한 글
1. 쏘카 변성윤 님 Github Repository
2. 컴퓨터 공학 독학을 위한 자료 - 인터뷰를 위한 자료구조(Data Structure)
https://github.com/JaeYeopHan/Interview_Question_for_Beginner/tree/master/DataStructure
3. 마르코 님 브런치 - 데이터 엔지니어가 하는 일
https://brunch.co.kr/@imagineer/301
