Skip to content
Published on

AI 시대 생존 가이드 5편: 데이터 사이언티스트의 미래 - 위기인가, 기회인가?

🇰🇷KO🇺🇸EN🇯🇵JA
Split View
Authors

AI 시대 생존 가이드 5편: 데이터 사이언티스트의 미래 - 위기인가, 기회인가?

2019년, "데이터 사이언티스트는 21세기 가장 섹시한 직업"이라는 하버드 비즈니스 리뷰의 기사가 전 세계 IT 종사자들의 마음을 흔들었습니다. 많은 분들이 통계학을 다시 공부하고, Python을 배우고, Kaggle에서 밤을 지새웠습니다. 그리고 이제 2026년, ChatGPT와 Claude 같은 LLM이 데이터 분석 리포트를 순식간에 작성하고, AutoML 도구들이 모델 선택과 하이퍼파라미터 튜닝을 자동화하고 있습니다.

솔직하게 물어보겠습니다. "그래서 데이터 사이언티스트는 이제 어떻게 해야 하는 건가요?"

이 질문이 머릿속을 떠나지 않는 분들을 위해 이 글을 씁니다. 결론부터 말씀드리면, 위기이면서 동시에 엄청난 기회입니다. 하지만 어느 쪽이 될지는 전적으로 여러분의 선택에 달려 있습니다.

1. AutoML과 LLM이 대체하는 DS 업무 현실

먼저 불편한 진실을 직시해야 합니다. AI가 이미 대체하고 있는 데이터 사이언티스트 업무들을 솔직하게 살펴보겠습니다.

탐색적 데이터 분석 (EDA)의 자동화

2023년까지만 해도 EDA는 데이터 사이언티스트의 핵심 업무였습니다. 데이터를 불러오고, 결측값을 확인하고, 분포를 시각화하고, 상관관계를 분석하는 과정 말이죠. 이제는 어떨까요?

# 과거: 수십 줄의 코드로 직접 작성하던 EDA
import pandas as pd
import matplotlib.pyplot as plt
import seaborn as sns

df = pd.read_csv('data.csv')
print(df.describe())
print(df.isnull().sum())
df.hist(figsize=(20, 15))
plt.show()
# ... 수십 줄 더

지금은 Claude나 GPT-4에게 "이 데이터셋을 분석해줘"라고 하면 완성된 EDA 코드와 인사이트를 함께 받을 수 있습니다. ydata-profiling(구 pandas-profiling) 같은 도구는 한 줄의 코드로 수백 페이지의 EDA 리포트를 생성합니다.

기본 모델 구축의 민주화

AutoML의 발전은 더욱 충격적입니다. Google의 Vertex AI AutoML, Amazon SageMaker Autopilot, 그리고 오픈소스 도구인 Auto-sklearn, FLAML은 이제 비전문가도 꽤 좋은 예측 모델을 만들 수 있게 해줍니다.

# AutoML로 모델 학습 - 데이터만 넣으면 됩니다
from flaml import AutoML

automl = AutoML()
automl.fit(
    X_train,
    y_train,
    task="classification",
    time_budget=3600  # 1시간 안에 최적 모델 탐색
)
print(automl.best_estimator)
print(automl.best_config)

과거라면 주니어 DS가 몇 주를 투자해야 했던 작업입니다. 이제 버튼 하나로 됩니다.

정형 리포트 작성의 자동화

매달 같은 형식으로 작성하던 성과 리포트, 이제는 LLM이 데이터를 받아 자동으로 작성합니다. 많은 기업들이 이미 자동화 리포팅 파이프라인을 구축했고, 이 과정에서 기계적으로 리포트를 작성하던 DS 포지션들이 줄어들고 있습니다.

피처 엔지니어링의 변화

딥러닝의 발전으로 테이블형 데이터에서도 자동 피처 학습이 가능해졌습니다. TabNet, FT-Transformer 같은 모델들은 수동 피처 엔지니어링 없이도 훌륭한 성능을 냅니다. LLM 기반 피처 엔지니어링 도구들은 자연어로 설명된 피처를 자동으로 코드로 변환합니다.

결론: 루틴하고 반복적인 DS 작업의 상당 부분이 자동화되고 있습니다. 이것은 현실입니다.

2. 여전히 필요한 DS 핵심 역량

하지만 여기서 중요한 전환점이 있습니다. 자동화가 대체할 수 없는 영역들이 있고, 그 영역의 가치는 오히려 높아지고 있습니다.

도메인 이해와 비즈니스 문제 정의

AutoML은 데이터를 학습할 수 있습니다. 하지만 "어떤 문제를 풀어야 하는가?"를 정의하는 것은 여전히 인간의 영역입니다.

헬스케어 분야의 예를 들어보겠습니다. "환자 재입원율을 줄이고 싶다"는 비즈니스 목표가 있을 때, 이를 예측 모델의 문제로 변환하는 과정에서 수많은 의사결정이 필요합니다.

  • 재입원의 기준을 30일로 할지, 90일로 할지
  • 예방 가능한 재입원만 타겟으로 할지
  • 어떤 개입이 가능한지에 따라 예측 시점을 언제로 설정할지
  • 모델의 오탐(False Positive)과 미탐(False Negative) 중 어느 쪽이 더 비용이 큰지

이런 결정들은 의료 도메인에 대한 깊은 이해 없이는 내릴 수 없습니다. 그리고 이 결정들이 모델의 실제 비즈니스 가치를 좌우합니다.

실험 설계와 인과 추론

"매출이 올랐다. A/B 테스트 때문인가, 아니면 계절적 요인인가?" 이 질문에 답하는 것이 인과 추론입니다.

상관관계와 인과관계를 구분하는 능력은 AI가 아직 대체하기 어려운 영역입니다. 잘못 설계된 실험에서 나온 데이터로 아무리 좋은 모델을 만들어봐야 의미 없는 결론이 나옵니다.

# 인과 추론: 처치 효과 추정 (도구변수법 예시 개념)
# X -> Y 인과관계를 교란변수 없이 추정하기 위한 접근법

# 단순 OLS는 교란변수로 인해 편향될 수 있음
# 자연 실험이나 도구변수를 활용한 인과 추정이 중요

from sklearn.linear_model import LinearRegression
import numpy as np

# 처치군과 대조군의 단순 비교가 아니라
# 선택 편향을 보정한 추정이 필요합니다
# 이 판단을 내리는 것은 도메인 전문가 + DS의 협업입니다

이중차분법(Difference-in-Differences), 합성 대조군(Synthetic Control), 회귀 불연속 설계(Regression Discontinuity Design) 같은 인과 추론 방법론은 비즈니스 현장에서 그 가치가 점점 높아지고 있습니다.

데이터 품질 감별 능력

"이 데이터를 믿을 수 있는가?" 이 질문은 AI가 스스로 답하기 매우 어렵습니다. 데이터가 수집된 맥락, 측정 오류의 패턴, 선택 편향의 가능성을 파악하는 것은 경험 많은 DS의 역할입니다.

실제로 많은 ML 프로젝트가 실패하는 이유는 알고리즘 문제가 아니라 데이터 품질 문제입니다. AutoML이 아무리 좋아도 "쓰레기 입력에서 쓰레기 출력(Garbage In, Garbage Out)"이라는 원칙은 변하지 않습니다.

불확실성의 정량화와 소통

비즈니스 의사결정자들은 "이 모델이 얼마나 확실한가?"를 알고 싶어합니다. 신뢰 구간, 예측 구간, 모델 불확실성을 이해하고 비기술적 이해관계자들에게 명확히 전달하는 능력은 여전히 귀중합니다.

3. DS에서 ML 엔지니어/AI 제품 빌더로의 진화

많은 DS들이 두 방향 중 하나를 선택하고 있습니다.

방향 1: ML 엔지니어/MLOps로의 전환

모델을 만드는 것에서 모델을 프로덕션에서 운영하는 것으로 초점이 이동합니다.

# MLflow를 활용한 모델 추적 및 배포 예시
# mlproject 파일 구조

name: churn_prediction

conda_env: conda.yaml

entry_points:
  train:
    parameters:
      learning_rate: { type: float, default: 0.01 }
      n_estimators: { type: int, default: 100 }
    command: 'python train.py --lr {learning_rate} --n_est {n_estimators}'
  evaluate:
    command: 'python evaluate.py'

MLOps 엔지니어는 다음을 책임집니다.

  • 모델 학습 파이프라인 자동화
  • 피처 스토어 구축 및 관리
  • 모델 서빙 인프라 (latency, throughput)
  • 모델 드리프트 모니터링과 재학습 트리거
  • A/B 테스트 인프라

한국에서 MLOps 엔지니어의 수요는 2024년 이후 급격히 증가했습니다. 네이버, 카카오, 쿠팡 등 대형 테크 기업뿐 아니라 금융, 헬스케어 스타트업에서도 이 포지션을 적극 채용하고 있습니다.

방향 2: AI 제품 빌더로의 진화

LLM 시대에 새롭게 부상한 역할입니다. DS의 분석 능력과 엔지니어링 능력을 결합해 실제로 동작하는 AI 제품을 만드는 역할입니다.

# RAG 기반 AI 제품의 핵심 파이프라인 예시
from langchain.embeddings import OpenAIEmbeddings
from langchain.vectorstores import Chroma
from langchain.chat_models import ChatOpenAI
from langchain.chains import RetrievalQA

# 문서 임베딩 및 벡터 스토어 구축
embeddings = OpenAIEmbeddings()
vectorstore = Chroma.from_documents(documents, embeddings)

# 검색 기반 QA 체인 구성
retriever = vectorstore.as_retriever(search_kwargs={"k": 5})
qa_chain = RetrievalQA.from_chain_type(
    llm=ChatOpenAI(model="gpt-4o"),
    chain_type="stuff",
    retriever=retriever,
    return_source_documents=True
)

# 쿼리 실행
result = qa_chain({"query": "우리 제품의 환불 정책은?"})

이 역할은 단순한 ML 모델 개발을 넘어, AI 시스템 전체를 설계하고 구현합니다.

4. 데이터 사이언티스트가 배워야 할 AI 스킬

LLM 파인튜닝 이해와 실습

LLM을 파인튜닝하는 것은 이제 DS의 중요한 역량이 되었습니다. 전체 파인튜닝(Full Fine-tuning)은 비용이 많이 들지만, LoRA(Low-Rank Adaptation)를 활용하면 소비자용 GPU로도 가능합니다.

# LoRA를 활용한 LLM 파인튜닝 예시 (Hugging Face PEFT)
from peft import get_peft_model, LoraConfig, TaskType
from transformers import AutoModelForCausalLM, AutoTokenizer

model_name = "meta-llama/Llama-3.2-3B"
tokenizer = AutoTokenizer.from_pretrained(model_name)
model = AutoModelForCausalLM.from_pretrained(model_name)

# LoRA 설정
lora_config = LoraConfig(
    task_type=TaskType.CAUSAL_LM,
    r=16,           # LoRA rank
    lora_alpha=32,  # 스케일링 파라미터
    target_modules=["q_proj", "v_proj"],
    lora_dropout=0.05,
    bias="none",
)

# LoRA 어댑터 적용
peft_model = get_peft_model(model, lora_config)
peft_model.print_trainable_parameters()
# trainable params: 2,097,152 || all params: 3,213,olean000 || trainable%: 0.065

파인튜닝을 언제 해야 하고 언제 프롬프트 엔지니어링이나 RAG로 충분한지 판단하는 능력도 중요합니다.

RAG 시스템 설계와 구현

Retrieval-Augmented Generation은 현재 가장 많이 활용되는 AI 제품 패턴입니다. DS는 RAG 시스템에서 다음을 담당할 수 있습니다.

  • 청킹 전략 실험 (고정 크기 vs 문장 단위 vs 의미 단위)
  • 임베딩 모델 선택과 평가
  • 하이브리드 검색 구현 (벡터 검색 + BM25)
  • 재순위화(Reranking) 모델 활용
# 하이브리드 검색 구현 개념
from langchain.retrievers import EnsembleRetriever
from langchain.retrievers import BM25Retriever
from langchain.vectorstores import FAISS

# 벡터 검색기
vector_retriever = faiss_store.as_retriever(search_kwargs={"k": 10})

# BM25 키워드 검색기
bm25_retriever = BM25Retriever.from_documents(documents)
bm25_retriever.k = 10

# 앙상블 검색 (0.6: 벡터, 0.4: BM25)
ensemble_retriever = EnsembleRetriever(
    retrievers=[vector_retriever, bm25_retriever],
    weights=[0.6, 0.4]
)

AI 시스템 평가

이것이 아마 DS에게 가장 중요한 새 역량입니다. LLM 기반 시스템은 기존 ML 모델과 다르게 평가해야 합니다. 고정된 테스트 세트 정확도로 충분하지 않습니다.

# LLM 시스템 평가 프레임워크 예시 (RAGAS)
from ragas import evaluate
from ragas.metrics import (
    faithfulness,       # 생성된 답변이 검색된 컨텍스트에 충실한가
    answer_relevancy,  # 답변이 질문에 관련이 있는가
    context_precision, # 검색된 컨텍스트가 정확한가
    context_recall,    # 관련 컨텍스트를 모두 찾았는가
)

result = evaluate(
    dataset=test_dataset,
    metrics=[faithfulness, answer_relevancy, context_precision, context_recall],
)
print(result.to_pandas())

평가 데이터셋 구축, 사람 평가(Human Evaluation)와 자동 평가의 조합, 회귀 방지(Regression Prevention)를 위한 평가 파이프라인 구축이 모두 DS의 역할입니다.

프롬프트 엔지니어링과 LLM 오케스트레이션

단순한 프롬프트 작성을 넘어, 복잡한 AI 워크플로우를 설계하는 능력이 필요합니다.

# LangGraph를 활용한 에이전트 워크플로우
from langgraph.graph import StateGraph, END
from typing import TypedDict, Annotated
import operator

class AgentState(TypedDict):
    messages: Annotated[list, operator.add]
    next: str

# 분석 에이전트 워크플로우 예시
workflow = StateGraph(AgentState)
workflow.add_node("data_loader", load_data_node)
workflow.add_node("analyzer", analyze_node)
workflow.add_node("visualizer", visualize_node)
workflow.add_node("reporter", report_node)

workflow.set_entry_point("data_loader")
workflow.add_edge("data_loader", "analyzer")
workflow.add_conditional_edges(
    "analyzer",
    route_next_step,
    {"needs_viz": "visualizer", "done": "reporter"}
)
workflow.add_edge("visualizer", "reporter")
workflow.add_edge("reporter", END)

5. 12개월 전환 로드맵

이제 구체적인 행동 계획을 세워보겠습니다.

1-3개월: 기반 점검과 LLM 입문

월 1: 현재 상태 진단

  • 내가 지금 하는 DS 업무 중 자동화 위험에 처한 것과 아닌 것 분류
  • LLM API 기초 실습 (OpenAI API, Anthropic API)
  • Prompt Engineering Guide (https://www.promptingguide.ai) 완독

월 2: LLM 애플리케이션 이해

  • LangChain 또는 LlamaIndex 튜토리얼 완료
  • 간단한 RAG 시스템 직접 구축 (자신의 도메인 지식을 AI에게 먹이는 실습)
  • Hugging Face 강좌 무료 수강: "LLM Course"

월 3: 전문화 방향 결정

  • MLOps 방향 vs AI 제품 빌더 방향 선택
  • 선택한 방향의 핵심 도구 집중 학습 시작
  • 커뮤니티 합류: 한국 MLOps 커뮤니티, LangChain 한국 사용자 모임

4-6개월: 핵심 기술 습득

MLOps 방향 선택 시:

# 학습 순서
# 1. Docker & Kubernetes 기초
docker build -t my-model:v1 .
kubectl apply -f deployment.yaml

# 2. MLflow 마스터
mlflow server --backend-store-uri sqlite:///mlflow.db

# 3. Kubeflow 또는 Vertex AI Pipelines
# 4. 모니터링: Prometheus + Grafana + Evidently AI

AI 제품 빌더 방향 선택 시:

  • LangChain/LlamaIndex 심화 학습
  • 벡터 데이터베이스 이해 (Pinecone, Weaviate, Chroma)
  • LLM 평가 프레임워크 (RAGAS, DeepEval)
  • 프로덕션 배포 경험 (Streamlit, FastAPI + Vercel)

7-9개월: 실전 프로젝트

이 시기에는 반드시 실제로 동작하는 무언가를 만들어야 합니다.

추천 프로젝트 아이디어:

  • 자신의 도메인(헬스케어, 금융, 이커머스 등)에 특화된 RAG 챗봇
  • 데이터 분석 자동화 에이전트 (CSV 업로드하면 인사이트 자동 생성)
  • MLOps 파이프라인 구축 프로젝트 (GitHub Actions + MLflow + FastAPI)

10-12개월: 포지셔닝과 취업 활동

  • 프로젝트를 GitHub에 정리하고 README를 충실히 작성
  • 기술 블로그에 학습 과정과 프로젝트 후기 포스팅
  • LinkedIn 프로필 업데이트
  • 타겟 회사 리스트 작성 및 지원 시작

6. 취업 시장 현실: 한국과 해외

한국 시장

2026년 현재 한국의 DS/AI 채용 트렌드를 솔직하게 살펴보겠습니다.

수요가 높은 역할:

  • MLOps/ML 엔지니어: 네이버, 카카오, 쿠팡, 토스, 당근마켓 등 모두 채용 중
  • LLM 애플리케이션 엔지니어: 스타트업 중심으로 수요 폭발
  • AI 리서처 (논문 쓰는 역할): 최상위권 대학원 졸업자, 상위 컨퍼런스 논문 필수

현실적인 진입 장벽:

  • 대기업은 여전히 SKY/KAIST/POSTECH 학벌 선호 경향
  • 하지만 스타트업은 실력 중심 채용이 많아지는 추세
  • 포트폴리오와 GitHub 기여도가 점점 중요해지고 있음

연봉 현실 (2026년 기준 추정):

  • 주니어 DS/ML 엔지니어 (1-3년): 4,500만-6,500만원
  • 미드 레벨 (3-7년): 7,000만-1억원
  • 시니어 (7년+): 1억원+
  • 해외 경험 있거나 상위 컨퍼런스 논문 보유 시 대폭 상향 가능

해외 시장 (원격 근무 포함)

영어 실력이 된다면 해외 시장은 훨씬 넓습니다.

  • Upwork, Toptal 같은 플랫폼에서 LLM 컨설턴트로 시간당 80-200달러 가능
  • 원격 근무 스타트업에서 ML 엔지니어로 연봉 10만-20만 달러
  • Kaggle 마스터/그랜드마스터 타이틀은 여전히 해외에서 강력한 신호

7. 포트폴리오 전략: 캐글에서 실제 제품으로

많은 DS들이 캐글 메달을 포트폴리오의 전부로 생각합니다. 하지만 2026년의 채용 시장은 달라졌습니다.

캐글의 가치와 한계

캐글은 여전히 가치 있습니다. 상위 입상 경험은 ML 기술력을 증명합니다. 하지만 캐글 문제는 현실과 다릅니다.

  • 데이터가 깨끗하게 주어집니다 (현실은 지저분)
  • 문제가 명확히 정의됩니다 (현실은 정의부터 해야 함)
  • 배포와 운영을 고려할 필요 없습니다 (현실은 이게 절반 이상의 일)

실제 제품 포트폴리오 만들기

레벨 1: 도구 숙달 증명

자신의 분야 데이터로 RAG 시스템을 만들고 배포합니다. 예를 들어:

  • "한국 약 정보 검색 AI" - 식품의약품안전처 공공데이터 활용
  • "법률 문서 요약 AI" - 판례 공공데이터 활용
  • "금융 리포트 분석 AI" - 공시 데이터 활용
# 배포까지 완료된 RAG 시스템 아키텍처
# 1. 데이터 수집 및 전처리 파이프라인
# 2. 문서 청킹 및 임베딩
# 3. 벡터 스토어 구축
# 4. 검색 + 생성 체인
# 5. FastAPI 백엔드
# 6. Streamlit 또는 React 프론트엔드
# 7. Docker 컨테이너화 및 클라우드 배포 (AWS/GCP/Azure)

레벨 2: 실제 사용자 있는 제품

사용자 100명이라도 실제로 쓰는 제품을 만들면 훨씬 강력합니다.

  • 실제 사용 데이터와 피드백이 생깁니다
  • 운영 중 발생하는 문제들을 해결한 경험이 생깁니다
  • "이 사람이 진짜 제품을 만들 수 있구나"를 증명합니다

레벨 3: 측정 가능한 비즈니스 임팩트

가장 강력한 포트폴리오는 "내가 만든 AI가 X%의 비용을 절감했다" 혹은 "Y개의 업무를 자동화했다"는 구체적인 임팩트입니다. 현재 직장에서 작은 AI 자동화 프로젝트를 해보세요. 허락을 구하기 어렵다면 주변의 작은 사업자나 비영리 단체에 자원봉사로 AI 도입을 도와주는 것도 훌륭한 포트폴리오가 됩니다.

마치며

데이터 사이언티스트의 직함은 사라질 수 있습니다. 하지만 "데이터를 이해하고, 문제를 정의하고, AI로 해결하는 사람"의 수요는 오히려 폭발적으로 늘어날 것입니다.

AutoML이 모델을 만든다면, 우리는 어떤 모델을 만들어야 하는지를 정의합니다. LLM이 분석 리포트를 쓴다면, 우리는 어떤 질문을 해야 하는지를 결정합니다. AI가 패턴을 찾는다면, 우리는 그 패턴이 의미 있는지를 판단합니다.

지금 당장 완벽한 계획이 없어도 괜찮습니다. 오늘 OpenAI API 문서를 열어보는 것부터 시작하세요. 작은 RAG 프로젝트를 하나 만들어보세요. 그 첫 발걸음이 1년 후 여러분의 커리어를 완전히 바꿔놓을 것입니다.

이 시리즈의 다음 편에서는 AI 시대 기획자/PM의 생존 전략을 다룹니다.

Discuss on Twitter • View on GitHub