데이터 직군: 분석가·엔지니어·머신러닝 엔지니어·사이언티스트

데이터 직군을 나누는 축

데이터 직군은 이름보다 성향으로 나누면 이해가 쉽다. 같은 이름이라도 회사와 조직 형태에 따라 하는 일이 크게 다르고, 직군의 경계는 시간이 지나며 빠르게 바뀐다.

• 데이터 사이언티스트와 머신러닝 엔지니어의 경계는 모호하다. 이 노트에서는 프로덕션을 신경 쓰면 머신러닝 엔지니어, 연구 개발에 집중하면 데이터 사이언티스트로 구분한다. 연구 조직에는 둘 사이에 리서치 엔지니어가 있다.
• 데이터 사이언티스트라는 이름이 분석 쪽을 가리키는 조직도 많다. 그때는 데이터 분석가 업무에 통계 모델링을 더한 일을 한다. R&D 집중이냐 분석 집중이냐에 따라 필요한 역량이 다르다.
• 작은 회사에서는 백엔드 개발자가 데이터 엔지니어 역할을 겸한다. 데이터 엔지니어도 백엔드 성향, 머신 러닝 성향, 데이터 엔지니어링 전담으로 갈린다.

데이터 분석가

데이터 분석가는 전사적 의사결정을 위해 가설과 KPI를 세우고 데이터로 검증하는 사람이다. DB에 쌓인 데이터, 대시보드, 애널리틱스 도구(GA4, Amplitude, Mixpanel 같은)를 쓴다. 주로 비즈니스·운영·데이터 팀에 속한다. 과거에는 Facebook Analytics(2021년 종료) 같은 도구도 많이 썼다.

일하는 흐름: 신규 기능이 잘 되고 있나

1. 문제 정의     「신규 기능이 활성화됐나」를 측정할 수 있는 질문으로 바꾼다
                 예) 사진 촬영 기능이면 촬영 수를 활성화 지표로 쓴다.
                     날마다 사용자 수가 다르니 절대 수치가 아니라 사용자 수로 나눈 비율로 본다
2. 추출·가공     SQL로 원천 데이터를 뽑고 집계 함수로 결론에 필요한 테이블을 만든다
3. 탐색·분석     테이블을 조인하고, 요일을 평일·주말로 나눠 보는 식으로 시도와 실패를 반복한다
4. 결과 공유     분석 기간, 가설, 결론, 다음 행동 제안을 적절한 시각화와 함께 공유한다

자주 받는 질문은 이런 모양이다. 지난주 WAU(주간 활성 사용자)는 얼마나 변했나, 우리 앱의 리텐션은 얼마이고 어떻게 늘리나, AARRR 단계별 핵심 지표는 무엇으로 할까, 고객은 어느 지점에서 이탈하나, 연령대별 사용 패턴은 어떤가, 아시아 국가의 DAU는 어떤가. 지표의 정의와 조작적 정의, 로그 설계, 코호트·퍼널, A/B 테스트는 프로덕트 데이터 분석에 정리돼 있다.

데이터 엔지니어

데이터 엔지니어는 앱·웹에서 나오는 데이터를 분석가와 모델이 쓰기 쉬운 형태로 수집·가공·저장하고 그 흐름을 관리한다. 데이터 엔지니어링의 목표는 데이터의 순환 속도를 높이고, 재처리의 심리적 부담을 줄이는 것이다. 도구는 블록처럼 몇 개를 조합할 뿐이라 모두 알 필요는 없다. 비슷한 도구 대비 왜 이것을 골랐는가를 늘 설명할 수 있어야 한다. 파이프라인 단계와 저장소 용어는 데이터 파이프라인과 저장소 용어에 있다.

신입에게 1TB 이상을 처리해 본 경험을 기대하기 어려우므로 채용에서는 Linux, 자료구조, 알고리즘, 운영체제, 네트워크 같은 CS 기초를 중점적으로 본다.

머신러닝 엔지니어와 데이터 사이언티스트

두 직군은 추천 시스템(개인화 추천), 금융(자산 가격 예측), 자연어 처리, 컴퓨터 비전(분류·검출·분할), 음성 인식, 강화 학습(게임 AI) 같은 도메인에서 목적에 맞는 모델을 만들고 성능을 고도화한다. 차이는 결과물이 서비스에 붙느냐(머신러닝 엔지니어), 연구 성과와 논문이냐(데이터 사이언티스트)다.

일하는 흐름: 스팸 사진을 분류하고 싶다

1. 문제 구체화   분류 문제다. 스팸 여부만인가, 라벨이 여러 개인가?
2. 데이터        DB에 있나, 클라우드 저장소에 있나? 모델에 넣을 수 있게 전처리한다
3. 베이스라인    단순한 모델로 먼저 끝까지 돌리고 성능을 최대한 올린다
4. 고도화        앙상블·스태킹, 하이퍼파라미터 튜닝
5. 프로덕션      정확도보다 가중치 파일 용량, 추론 속도가 더 중요할 수 있다(딥러닝이 늘 최선은 아니다)

연구와 프로덕션의 차이

머신러닝 코드는 머신러닝 시스템의 아주 작은 일부다(구글의 「Hidden Technical Debt in Machine Learning Systems」). 팀이 커지면 전처리 흐름이 복잡해지고, 사람마다 쓰는 프레임워크가 다르고, 환경마다 서빙이 달라지고, 문제가 생기면 데이터 탓인지 모델 탓인지 가리기 어려워진다. 이 간극을 줄이려고 생긴 분야가 MLOps이고, 핵심 원칙은 재현성(연구에서 만든 모델이 프로덕션에서도 재현된다)과 오케스트레이션(설정·배포·확장의 자동화)이다. 배치 서빙과 온라인 서빙의 설계는 머신러닝 모델 서빙에 있다.

인접 직군과 새 직군

기대와 현실

데이터 직군을 떠나는 사람이 가장 많이 꼽는 이유는 예상과 실제가 다르다는 것이다.

모델의 목표를 정확도가 아니라 활용 의도에 맞는 기대 이익으로 두는 방식도 있다. 이탈 예측이라면 기대 이익 = 전환율 × (추가 생존 기간 × 일별 평균 결제액) − 인센티브 처럼 정의한다. 모든 고객을 이탈로 예측하는 것이 모델보다 이익이 크다면 그것은 마케팅이 아니라 모델의 문제다. 서비스는 업데이트·이벤트로 사용자 행동이 자주 바뀌므로, 학습 기간과 평가 기간을 달리해 시간 변화에 강건한지도 함께 본다. 분류 지표 자체는 분류 모델 성능 평가 지표에 있다.

잘하는 사람의 기준

AI가 왜 잘 되는지 다 설명되지 않아도 잘하는 사람은 판단할 수 있다. 기준은 고객을 만족시키는가이고, 역량은 두 가지다.

1. 어떤 문제를 풀어야 만족할지 안다. 이게 부족하면 딥러닝으로 풀 수 없는 문제를 고르거나, 만족과 초점이 어긋난 문제를 고르거나, 다른 방법보다 비싼 문제를 고른다.
2. 그 문제를 빠르고 정확하게 푼다. 요리처럼, 비슷한 문제를 많이 풀어 본 사람이 잘 푼다.

분석가로 인정받는 데 필요한 습관은 다음과 같다.

• 손가락(R, Python, SAS)이 아니라 달(분석, 통계)을 본다. 도구 공부에 머물지 않는다.
• 그래도 도구는 고른다. 코드와 데이터가 섞이는 스프레드시트는 실수를 부르고, 전문 분석 도구와 tidy data 계열 문법은 전처리·시각화의 실수를 줄인다.
• 분석은 과학 연구다. 대조군 대비 효과 크기를 말할 수 있어야 한다.
• 큰 데이터가 늘 좋지는 않다. 이상 탐지처럼 희소한 사건이 아니면 표본으로 충분하고, 노이즈 정제 비용만 커진다.
• 작은 보폭으로 자주 공유한다(애자일한 분석). 좋은 결과가 인정받는 데는 시간이 걸릴 수 있다.

직군별 학습 로드맵

• 프레임워크는 PyTorch가 기본이다. 연구 대부분과 프로덕션 다수가 PyTorch로 돌아간다. JAX는 일부 대형 연구 조직에서 쓰고, Keras 3는 여러 백엔드 위에서 돈다. 과거에는 「엔지니어는 TensorFlow, 연구자는 PyTorch」라는 조언이 흔했고 TensorFlow Serving이 서빙의 기본이었다.
• 이론만 배우고 끝내지 않는다. 선형대수도 코드로는 한 줄이지만 직접 쳐 본다. 수학을 다 끝내고 딥러닝을 시작하려 하면 지치니, 논문을 보다 막히는 수학을 그때그때 공부한다.
• 넓은 AI 지식 위에 한 분야를 깊게 판 T자형 역량을 목표로 한다.
• 영어가 중요하다. 연구와 실사례를 주도하는 나라들이 모두 영어로 발표하고, 이 분야는 2년 전 최고 결과가 금세 낡는다.
• 논문을 고르고 읽고 구현하는 방법은 논문 읽기와 구현에 있다.

진입 준비

자주 묻는 질문

포트폴리오

Kaggle은 2010년에 생겨 2017년 Google이 인수한 데이터 경진대회 플랫폼이다. 메달이 없어도 꾸준히 참여한 기록이 포트폴리오가 된다.

• 대회 유형: Featured(상금이 걸린 주요 대회), Research, Getting Started(입문용), Playground, 채용 연계 대회가 있다. 대회 페이지에서 평가 지표(Evaluation)를 가장 먼저 확인한다.
• 리더보드는 공개(public)와 비공개(private)로 나뉜다. 최종 순위는 private 데이터로 매겨서, public 점수에 과적합하면 순위가 크게 떨어진다. 교차 검증(CV) 점수를 믿는다.
• 진행 흐름: 평가 지표 조사 → 탐색적 분석(분포, 결측치) → 전처리(결측치, 범주형 변수, 이상값, 이미지라면 리사이즈·증강) → 단일 모델(랜덤 포레스트, XGBoost, LightGBM, CatBoost) → 특징 공학 반복(가장 중요하다) → 여러 모델을 섞는 스태킹. 트리 앙상블의 원리는 결정 트리와 앙상블에 있다.
• 다른 참가자의 공개 노트북(과거 이름은 Kernels)을 하나씩 따라 쓰며 배우되, EDA는 먼저 스스로 해 본 뒤 비교한다. 대회가 끝나면 Discussion에 올라오는 상위권 솔루션 정리를 읽는다. 과거 대회 솔루션을 모아 검색할 수 있는 사이트도 있다.
• 데이터셋마다 폴더 하나에 노트북을 쌓듯 꾸준히 기록하면 그 자체가 성장 기록이 된다.
• GitHub에 정리할 때 README는 개요(주최, 문제 유형, 평가 지표, 기간) → 결과 표(CV 점수, public·private 점수와 순위) → 재현 방법(데이터 위치, 실행 명령, 라이브러리 버전) → 상위 솔루션 링크 순서가 읽기 좋다.

공모전·해커톤은 국내 기업·공공기관 데이터를 다룰 기회다(DACON 같은 국내 플랫폼도 있다). 코드를 GitHub에 올릴 때는 데이터 저작권과 공개 범위를 반드시 확인한다. 대회에서 얻는 교훈은 비슷하다. 모델보다 데이터 증강·전처리가 점수를 바꾸는 경우가 많고(한국어 텍스트는 형태소보다 음절·자소 단위가 나을 때도 있다), 논문의 모델이 늘 최선은 아니며, 멘토·옆 팀과 이야기하다 더 나은 아이디어가 나온다.

개인 프로젝트가 그래도 가장 좋다.

• 공개 데이터셋 대신 데이터를 직접 수집하는 프로젝트를 권한다. 실무에서는 수집·가공이 절반 이상이고 모델링·시각화의 비중은 의외로 작다. 교재 샘플 데이터만 쓴 포트폴리오는 매력이 떨어지고, 질이 조금 떨어져도 직접 모은 데이터가 더 좋게 평가된다. 수집 방법은 웹 크롤링 전략에 있다.
• 관심 있는 도메인을 고르고, 완성도보다 문제 정의 → 수집 → 모델 → 결론의 전체 사이클을 한 번 끝내는 데 초점을 둔다.
• 핵심은 「~을 해 봤다」가 아니라 그 경험에서 얻은 생각이다. 배치 정규화를 넣으면 좋아진다고 배웠는데 내 데이터에서는 아니었다면, 불균형 때문인지 도메인 특성 때문인지 따져 본다.
• 사례: 브런치 사용자 3만여 명의 관심 작가 목록을 문서로, 작가 ID를 단어로 보고 Word2Vec을 학습해 비슷한 작가를 추천하는 API를 만든 프로젝트(아이템을 단어처럼 임베딩하는 방식), 일 평균 10만 쿼리를 받던 한국어 자동 띄어쓰기 모델을 패키지로 공개한 프로젝트, 등록하지 않은 얼굴을 모자이크해 초상권을 지키는 프로젝트.

블로그·GitHub는 생각을 정리하고 쌓인 기록으로 실력을 보여 준다. 다만 급조했거나 몇 달 뒤 방치된 흔적은 오히려 꾸준함이 부족해 보인다. 쓰고 운영하는 법은 개발자 기술 블로그에 있다.

채용 과제와 면접

무엇을 보나

데이터 분석가 채용은 흔히 과제 + 실무 면접으로 이뤄진다. 한 사례는 Kaggle 주택 가격 회귀 문제를 과제로 내고(결과 점수, 분석 과정 문서, 소스 코드 제출), 최종 점수를 과제 30% + 면접 70%로 매겼다. 과제는 공개 자료를 참고할 수 있어 신뢰도가 낮고, 면접에서 과제를 물으면 과제 역량도 확인되기 때문이다. Kaggle 점수와 평가 순위의 상관은 낮았다. 점수보다 문서·코드 정리 수준과 탐색 분석의 체계성을 봤다.

기술 질문이 묻는 개념은 각 개념 노트에 있다. 평가 지표는 분류 모델 성능 평가 지표, 과적합·MLE·정규화는 머신 러닝 기초, 앙상블은 결정 트리와 앙상블, 실험과 통계 검정은 프로덕트 데이터 분석이다.

흔한 실수

• 이력서에 기법을 많이 나열하지만 이해가 부족하다. 잘 모르는 채 「LSTM으로 게임 밸런스를 조절하겠다」고 쓰면 감점이다. 이력서에는 막연한 표현 대신 쓴 라이브러리·기법·수치·문제 해결 과정을 구체적으로 쓴다.
• 기본 개념을 잘못 안다. 토픽 모델링의 LDA(Latent Dirichlet Allocation)와 분류의 LDA(Linear Discriminant Analysis)를 혼동하는 식이다. 다중 회귀에서 상관만 보고 변수를 하나씩 고르는 것도 잘못된 접근이다.
• 설계형 질문에 모델링·시각화만 말한다. 흐름의 핵심은 수집, 정제, 가설 설정이다. 설문으로 자기 자신을 군집화하는 것처럼 데이터와 기법이 맞지 않는 답도 낮게 평가된다.
• 모범 답안에 맞추려 하거나, 긴장해 답을 자꾸 번복한다. 모르는 것은 모른다고 명확히 답한다.
• 약점이 있는 프로젝트는 숨기지 말고, 당시 방법의 한계와 지금이라면 어떻게 고칠지를 말하면 장점이 된다.

일반 면접 태도와 답변 요령은 면접 잘 보는 법에 있다.

머신 러닝 연구 조직의 채용 과정

해외 연구 조직은 대개 서류 → 전화 면접 1~2회 → 온사이트 → 레퍼런스 체크 → 오퍼 순서다.

• 서류에는 논문·논문 구현·연구 경험·대회 수상이 핵심이다. 같은 분야 연구자들의 공개 CV를 참고해 수십 번 고친다.
• 전화 면접은 30분~1시간이고 기초를 정확히 묻는다. 수식을 쓰게 하고, 문제점과 해결책을 묻는다. 야코비안, 유사 역행렬, 깁스 샘플링, NP-완전 같은 CS·수학·통계 기초가 나온다.
• 온사이트는 56시간 동안 머신 러닝 이론 면접(개념 → 예시 → 칠판 증명 반복)과 코딩 면접(일반 알고리즘, 확장성, ML 관련 코딩)을 여러 번 본다. 일반 코딩은 LeetCode 같은 사이트로 12주 동안 100문제 이상 풀어 대비한다.
• 맡을 역할, 팀의 연구 주제를 묻는 역질문을 준비한다. 레퍼런스는 지도 교수와 이전 직장 동료에게 받는다.
• 오퍼는 기본급 + 지분 + 보너스로 구성되고, 다른 오퍼가 있어야 협상이 쉽다. 협상 원칙은 연봉 협상, 미국 채용 단계는 미국 채용 과정에 있다.

정리

• 데이터 직군은 성향으로 나눈다. 분석가는 기획자, 데이터 엔지니어와 머신러닝 엔지니어는 개발자, 데이터 사이언티스트는 연구자에 가깝다. 이름보다 실제 업무를 공고에서 확인한다.
• 분석가는 문제 정의 → SQL 추출·가공 → 탐색 → 공유로, 머신 러닝 직군은 문제 구체화 → 데이터 → 베이스라인 → 고도화 → 프로덕션 제약 확인으로 일한다.
• 새 직군(애널리틱스 엔지니어, MLOps 엔지니어, AI 엔지니어)은 기존 직군 사이의 간극을 메우며 생겼다.
• 현실의 일은 리포팅·ETL·데이터 만들기가 많고, 정확도보다 회사의 이익과 재현성으로 평가받는다.
• 진입 준비는 자격증보다 프로젝트, 학위는 연구냐 적용이냐로, 포트폴리오는 직접 모은 데이터와 그 경험에서 얻은 생각으로 한다.

관련 노트: 프로덕트 데이터 분석, 논문 읽기와 구현, 데이터 파이프라인과 저장소 용어, 머신러닝 모델 서빙, 머신 러닝 기초, 사이드 프로젝트 팁, 개발자 기술 블로그