데이터 사이언티스트의 역습

데이터 사이언티스트의 전성기는 끝난 걸까? 하버드 비즈니스 리뷰는 한때 데이터 사이언티스트를 "21세기 가장 섹시한 직업"이라 불렀다.¹ 테크 업계에서 데이터 사이언티스트는 최고 수준의 연봉을 받는 직군 중 하나였다.² 이 직업이 요구하는 역량 조합도 독특했다:

Data Scientist (n.): Person who is better at statistics than any software engineer and better at software engineering than any statistician.

— JosH100 (@josh_wills) May 3, 2012

이런 높은 진입 장벽 덕분에 데이터 사이언티스트는 예측 모델을 만들고, 인과관계를 측정하고, 데이터에서 패턴을 찾아낼 수 있었다. 이 중 가장 몸값이 높았던 영역은 예측 모델링이었다. 기업들은 이후 이 업무를 별도 직함으로 떼어냈는데, 그것이 바로 머신러닝 엔지니어(Machine Learning Engineer, "MLE")다.³

수년간 AI를 출시하려면 데이터 사이언티스트와 MLE가 핵심 경로(critical path)에 있어야 했다. LLM 시대가 열리면서 이 공식이 깨졌다. 파운데이션 모델 API 덕분에 다른 팀도 독립적으로 AI를 통합할 수 있게 된 것이다.

핵심 루프에서 빠지게 되자, 내가 아는 데이터 사이언티스트와 MLE들은 동요하기 시작했다. 회사가 더 이상 AI를 출시하는 데 나를 필요로 하지 않는다면, 이 직업의 미래가 예전 같을 수 있을까 의문을 품는 건 당연하다. 더 냉정한 자기 서사는 이렇다: 파운데이션 모델 랩에서 사전학습을 하는 게 아니라면, 진짜 중요한 일은 내 몫이 아니다.

나는 정반대로 본다. 모델 학습은 원래 이 직업의 핵심이 아니었다. 업무의 대부분은 AI가 본 적 없는 데이터에도 잘 일반화하는지 실험을 설계하고, 확률적 시스템을 디버깅하고, 좋은 메트릭을 설계하는 일이다. API로 LLM을 호출한다고 해서 이 일이 사라지지는 않는다.

최근 PyAI Conf에서 "데이터 사이언티스트의 역습"이라는 제목으로 발표했다. 주장만이 아니라 구체적인 사례를 통해 이 논점을 풀어보고 싶었다. 아래는 그 발표를 주석과 함께 정리한 글이다.

하네스(Harness)는 데이터 사이언스다

OpenAI가 하네스 엔지니어링에 관한 블로그 글을 올렸는데, 일독을 권한다. 이 글에서는 Codex가 수개월간 자율적으로 소프트웨어 프로젝트를 수행하되, 테스트와 명세로 구성된 하네스가 에이전트의 행동 범위를 제한하는 방식을 설명한다.

이 글에서 놓치기 쉬운 디테일이 하나 있다. 하네스에 옵저버빌리티(Observability) 스택이 포함되어 있다는 점이다. 로그, 메트릭, 트레이스를 에이전트에 노출해서 에이전트 스스로 경로 이탈을 감지할 수 있게 한다. 테스트와 명세 외에 메트릭이 있다는 것, 이것이 시스템의 핵심 구성 요소다.

Andrej Karpathy의 auto-research 프로젝트에서도 같은 패턴이 나타난다. 모델이 검증 손실(validation loss) 메트릭을 기준으로 반복 최적화한다. 개념은 같고, 하네스만 다르다.

내가 강조하고 싶은 핵심은 이것이다: 하네스의 상당 부분은 곧 데이터 사이언스라는 점.

한 발 물러서서 지금 우리가 어디쯤 와 있는지 짚어보자.

몇 년 전만 해도 실무자들은 데이터를 꼼꼼히 살피고, 레이블 정합성을 확인하고, 메트릭을 직접 설계하는 데 많은 시간을 쏟았다. 지금은 어떤가? "느낌(vibes)"에 기대어 개발하고, 모델에게 "잘했니?"라고 물어보고, 기성 메트릭 라이브러리를 데이터도 안 보고 가져다 쓴다.

이런 현상은 검색(retrieval)과 평가(eval) 영역에서 가장 두드러진다. 데이터 배경이 없는 엔지니어들은 자기가 이해하지 못하는 것을 두려워한다. "RAG는 끝났다", "평가는 끝났다"고 선언하면서도, 정작 그 개념에 의존하는 시스템을 만들고 있다.

이 글의 나머지 부분에서는 내가 반복적으로 목격하는 다섯 가지 평가 함정과, 데이터 사이언티스트라면 각 경우에 어떻게 다르게 접근하는지를 살펴본다.

---

범용 메트릭의 함정

첫 번째 함정은 범용 메트릭이다.

평가 프레임워크를 가져와서 기본 메트릭을 그대로 쓰고 싶은 유혹에 빠지기 쉽다. 문제는, 실제로 뭐가 고장 났는지 전혀 알 수 없다는 것이다. 대부분의 팀이 유용성 점수, 일관성 점수, 환각 점수 같은 대시보드를 만든다. 그럴듯해 보이지만, 너무 범용적이라 애플리케이션의 실제 실패 원인을 진단하는 데는 무용지물이다.

데이터 사이언티스트라면 기성 메트릭을 그냥 가져다 쓰지 않는다. 데이터를 직접 탐색하고, 트레이스를 살펴보고, "여기서 실제로 뭐가 깨지고 있지?"를 묻고, 가장 가치 있는 측정 대상부터 파악한다. 측정할 수 있는 것은 무한하다. 가설을 세우고 반복해야 한다.

이 함정에 대한 최고의 처방은 데이터를 직접 보는 것이다.

"데이터를 본다"는 게 실무에서는 무슨 뜻일까? 트레이스를 읽는 것이다. 마찰을 줄이고 자기 도메인의 특수성에 맞게 화면을 커스터마이징할 수 있도록, 직접 트레이스 뷰어를 만들어라. 발견한 문제를 기록하라. 오류 분석을 하라: 실패를 분류하고, 우선순위를 정하고, 무엇부터 손볼지 결정하라.

데이터를 직접 보면, 자연스럽게 애플리케이션에 특화된 메트릭으로 수렴하게 된다. ROUGE나 BLEU 같은 기성 유사도 메트릭은 LLM 출력에 거의 맞지 않는다. 진짜 중요한 메트릭은 "일정 예약 실패율"이나 "휴먼 에스컬레이션 실패율" 같은 것이다.

이 글에서 단 하나만 기억한다면 이것이다: 데이터를 직접 보라. 어떻게 볼 것인가는 별개의 문제이고 연습이 필요하다. 가장 ROI가 높은 활동임에도, 가장 자주 건너뛰는 활동이다.

---

검증되지 않은 LLM 심사자

두 번째 함정은 검증되지 않은 심사자(judge)다. 많은 팀이 LLM을 심사자로 사용해 자기 AI가 제대로 작동하는지 판단한다. 대부분의 경우, "그 심사자를 어떻게 신뢰하느냐"는 질문에 제대로 답하지 못한다.

일반적인 접근법: LLM에게 출력을 점수로 평가하게 한 뒤 그 숫자를 그대로 쓴다. 데이터 사이언티스트라면 심사자를 분류기(classifier)로 취급한다. 예측값을 내뱉는 블랙박스가 있는 셈이니, 이걸 어떻게 신뢰할 것인가? 휴먼 레이블을 확보하고, 데이터를 학습/개발/테스트 세트로 나누고, 분류기가 신뢰할 만한지 측정한다.

few-shot 예시는 학습 세트에서 가져오고, 개발 세트를 기준으로 심사자의 프롬프트를 반복 개선(hill-climb)한다. 테스트 세트는 별도로 남겨두어 오버피팅 여부를 확인한다. 머신러닝을 해본 사람이라면 지극히 당연한 이야기다. 그런데 실제로 이걸 하는 팀이 없다. 분류기 검증은 현대 AI에서 잊힌 기술이 되어 버렸다.

결과를 보고하는 방식도 심사자를 분류기로 다뤄야 한다. 어디를 가나 정확도(accuracy)만 보고한다. 특정 실패 모드가 5%의 빈도로 발생한다면, 정확도는 시스템의 실제 성능을 감춰버린다. 정밀도(precision)와 재현율(recall)을 사용하라.

---

잘못된 실험 설계

세 번째 함정은 실험 설계다. 이 주제에는 여러 차원이 있는데, 가장 자주 등장하는 두 가지를 다룬다.

첫 번째는 테스트 세트 구성이다. 대부분의 팀은 LLM에 "테스트 쿼리 50개를 만들어줘"라고 프롬프트를 던져 합성 데이터를 생성한다. 결과는 범용적이고 대표성 없는 데이터다. 데이터 사이언티스트라면 먼저 실제 프로덕션 데이터를 살펴보고, 어떤 차원이 중요한지 가설을 세운 뒤, 그 차원을 따라 합성 예시를 생성한다.

합성 데이터는 실제 로그나 트레이스에 기반해야 한다. 어떤 차원을 변화시킬지 파악하고, 엣지 케이스를 주입하라. 합성 데이터의 토대는 반드시 실제 데이터여야 한다.

두 번째는 메트릭 설계다. 많은 팀이 평가 루브릭 전체를 하나의 LLM 호출에 뭉뚱그려 넣고, 기본값으로 1~5점 리커트 척도를 사용한다. 데이터 사이언티스트라면 복잡도를 줄이고, 각 메트릭을 실행 가능한(actionable) 형태로 만들어 비즈니스 성과에 연결한다. 주관적인 점수 척도 대신, 범위가 명확한 기준에 대한 이진(pass/fail) 판정으로 바꿔라. 리커트 척도는 모호함을 감추고, 시스템 성능에 대한 어려운 판단을 뒤로 미룰 뿐이다.

---

불량 데이터와 레이블

네 번째 함정은 불량 데이터와 레이블이다. 데이터 사이언티스트는 데이터를 믿지 않는다. 레이블도 믿지 않는다. 아무것도 믿지 않는다. 훈련 과정 자체가 회의주의를 체화시킨다. AI 엔지니어 대다수는 아직 이 근육을 키우지 못했다.

레이블링은 대부분의 팀에서 "남의 일"로 치부된다. 화려하지 않은 작업이라 개발팀에 떠넘기거나 외주를 주기 일쑤다. 데이터 사이언티스트라면 도메인 전문가가 직접 레이블링해야 한다고 주장하고, 레이블 자체에도 회의적 태도를 유지하며, 데이터를 직접 본다.

레이블링이 중요한 이유는 레이블 품질 때문만이 아니다. 더 근본적인 이유가 있다. 데이터를 보지 않으면 자기가 무엇을 원하는지 알 수 없다. "기준 드리프트(criteria drift)"라는 개념이 있는데, Shreya Shankar 외 연구자들의 논문에서 검증되었다: 사용자는 출력을 채점하기 위해 기준이 필요하지만, 출력을 채점하는 과정이 기준을 다듬어준다. 사람들은 LLM의 출력을 직접 보기 전까지는 자기가 뭘 원하는지 모른다. 레이블링 과정 자체가 무엇이 중요한지를 드러내준다.

데이터 사이언티스트가 늘 강조하는 것이 바로 이것이다: 도메인 전문가와 프로덕트 매니저를 요약 점수가 아니라 원시 데이터 앞에 앉혀라.

---

과도한 자동화

다섯 번째 함정은 과도한 자동화다. 이 모든 작업은 사람의 몫이다. 그런데 자동화하고 싶은 유혹이 크다.

LLM은 배관 작업(plumbing)을 처리하고, 평가용 보일러플레이트를 생성하는 데 도움이 된다. 하지만 데이터를 대신 봐주지는 못한다. 방금 논의한 이유 그대로다: 출력을 직접 보기 전까지는 자기가 뭘 원하는지 모른다. 적어도 아직은.

---

그 밖의 함정들

발표 시간이 부족해 모든 함정을 다루지는 못했다. 나머지를 빠르게 훑어본다.

유사도 점수의 오용. 심사자에게 "도움이 되나요?" 같은 모호한 질문 던지기. 어노테이터에게 원시 JSON을 그대로 읽히기. 신뢰 구간 없이 보정되지 않은 점수 보고하기. 데이터 드리프트, 오버피팅, 잘못된 샘플링, 의미 없는 대시보드.

---

매핑: 결국 데이터 사이언스 기초의 문제

한 발 물러서서 보면, 위의 모든 함정은 같은 근본 원인을 공유한다: 데이터 사이언스 기초의 부재.

트레이스를 읽고 실패를 분류하는 것은 탐색적 데이터 분석(EDA)이다. LLM 심사자를 휴먼 레이블로 검증하는 것은 모델 평가다. 프로덕션 데이터에 기반해 대표성 있는 테스트 세트를 구축하는 것은 실험 설계다. 도메인 전문가에게 출력을 레이블링하게 하는 것은 데이터 수집이다. 프로덕션에서 제품이 제대로 작동하는지 모니터링하는 것은 프로덕션 ML이다. 이 중 새로운 것은 하나도 없다. 이름만 바뀌었을 뿐, 일은 그대로다.

이 발표는 Python 컨퍼런스에서 했으니 덧붙이자면: 데이터를 보고 다루는 데 Python은 여전히 최고의 도구다.

이 주제를 더 깊이 다루는 오픈소스 플러그인을 만들었다. 평가 파이프라인에 연결하면 무엇이 잘못되었는지 알려준다—최소한 최선을 다해.

항상 데이터를 직접 보라.

이 발표에 나온 밈(meme)들이 재밌었다면, 제 웹사이트에 더 많이 있다.

읽어주셔서 감사합니다. 각 주제를 더 깊이 들여다보고 싶다면, 아래에 슬라이드와 영상을 첨부해 두었다.

---

영상

슬라이드

PDF 파일 다운로드