본문으로 건너뛰기

데이터 과학자의 복수

게시일: 2026년 4월 4일 | 원문 작성일: 2026년 3월 26일 | 저자: Hamel Husain | 원문 보기

데이터 과학자의 복수 — 16비트 픽셀 아트 일러스트레이션

핵심 요약

Hamel Husain이 PyAI Conf에서 한 발표의 주석 달린 버전이에요. 데이터 과학자가 밀려났다는 통념을 뒤집고, LLM 시스템의 핵심 작업이 줄곧 데이터 사이언스였음을 다섯 가지 eval 함정을 통해 보여줘요.

  • 하네스는 데이터 사이언스다 — 오늘날의 LLM 시스템에서 핵심은 하네스(harness)이며, 그 하네스를 제대로 구축하는 데 필요한 역량이 바로 데이터 사이언스다.
  • 다섯 가지 eval 함정 — 범용 지표 남용, 검증되지 않은 판정 모델, 잘못된 실험 설계, 나쁜 데이터와 레이블, 과도한 자동화. 모두 데이터 사이언스 기본기 부재에서 비롯된다.
  • 이름만 바뀌었을 뿐 — EDA, 모델 평가, 실험 설계, 데이터 수집, Production ML. 새로운 것은 없다. 데이터 과학자가 늘 해온 일이다.
  • 항상 데이터를 보세요 — 가장 ROI가 높은 활동인데도 가장 자주 생략된다. 트레이스를 직접 읽고, 레이블을 직접 달고, 데이터를 직접 들여다봐야 한다.

• • •

데이터 사이언티스트의 전성기는 끝난 걸까요? Harvard Business Review는 한때 이 직업을 “21세기 가장 섹시한 직업”이라고 불렀어요.1 테크 업계에서 데이터 사이언티스트는 가장 높은 연봉을 받는 직군 중 하나였죠.2 이 직업은 보기 드문 복합적 역량을 요구하기도 했어요.

(원문에는 트위터 임베드가 포함되어 있습니다: 데이터 과학자에게 요구되는 다양한 기술을 다룬 트윗)

높은 진입 장벽을 만들어내는 것 외에도, 이 역량들 덕분에 데이터 사이언티스트는 예측 모델을 구축하고, 인과관계를 측정하고, 데이터에서 패턴을 찾을 수 있었어요. 그 중에서도 예측 모델링이 보수가 가장 높았죠. 이후 기업들은 그 업무를 별도 직함으로 떼어냈어요. 바로 Machine Learning Engineer(“MLE”)예요.3

오랫동안, AI를 출시한다는 것은 데이터 사이언티스트와 MLE를 핵심 경로에 두는 것을 의미했어요. LLM이 등장하면서, 이것이 기본값이 아니게 됐죠. 파운데이션 모델 API는 이제 각 팀이 독자적으로 AI를 도입할 수 있게 해줘요.

루프에서 제외됐다는 사실이 제가 아는 데이터 사이언티스트와 MLE들을 흔들어놨어요. 회사가 더 이상 AI를 출시하는 데 여러분이 필요하지 않다면, 그 직업이 여전히 같은 가치를 지니는지 의문을 품는 건 당연해요. 사람들이 스스로에게 하는 더 냉혹한 이야기는 이래요: 파운데이션 모델 랩에서 사전 학습(pretraining)을 하지 않는 이상, 여러분은 판 밖으로 밀려난 거라고요.

저는 반대로 읽어요. 모델을 훈련하는 것은 애초에 이 직업의 대부분이 아니었어요. 업무의 대부분은 AI가 학습에 쓰이지 않은 데이터에 얼마나 잘 일반화하는지 테스트하는 실험을 설계하고, 확률적 시스템을 디버깅하고, 좋은 지표를 설계하는 일이에요. API로 LLM을 호출한다고 해서 이 작업이 없어지지는 않아요.

저는 최근 PyAI ConfT1에서 “데이터 과학자의 복수”라는 제목의 발표를 했어요. 주장만이 아니라 구체적인 예시로 그 논지를 펼치기 위해서였죠. 아래는 그 발표의 주석 달린 버전이에요.

하네스는 데이터 사이언스다

OpenAI가 하네스 엔지니어링에 관한 블로그 포스트를 공개했는데, 꼭 읽어보길 권해요. 그들은 Codex가 테스트와 명세(specification)로 이루어진 하네스 안에서, 에이전트들이 코드를 개발하며 몇 달간 자율적으로 소프트웨어 프로젝트를 수행한 방식을 설명해요.

그 블로그 포스트에서 놓치기 쉬운 세부 사항이 하나 있어요. 하네스에는 옵저버빌리티 스택이 포함돼 있다는 거예요: 에이전트가 경로를 이탈하고 있을 때 파악할 수 있도록 노출된 로그, 지표, 트레이스가 그것이에요. 테스트와 명세 외에도 지표가 있어요. 바로 이것이 시스템의 핵심 구성 요소랍니다.

Andrej Karpathy의 auto-research 프로젝트도 동일한 패턴을 보여줘요: 모델이 검증 손실(validation loss) 지표를 기준으로 반복적으로 최적화하는 것이죠. 같은 아이디어, 다른 하네스예요.

제가 여러분에게 납득시키고 싶은 것은, 하네스의 상당 부분이 데이터 사이언스라는 점이에요.

한 발짝 물러서서 우리가 지금 어디에 있는지 파악해봐요.

예전에는 실무자들이 수 시간을 데이터를 살피고, 레이블 정합성을 확인하고, 지표를 설계하는 데 보냈어요. 오늘날 우리는 “감으로” 구축하고, 모델한테 잘 했는지 물어보고, 데이터는 보지도 않은 채 기성 지표 라이브러리를 가져다 쓰죠.

이것은 검색(retrieval)과 평가(eval) 주변에서 가장 두드러져요. 데이터 배경이 없는 엔지니어들은 자신이 이해하지 못하는 것을 두려워해요. “RAG는 죽었다”, “eval은 죽었다”고 말하면서도, 정작 그 개념에 의존하는 시스템을 만들고 있어요.

이 포스트의 나머지 부분에서는 제가 반복적으로 목격하는 다섯 가지 eval 함정을 살펴볼게요. 각각의 경우에 데이터 사이언티스트라면 어떻게 다르게 접근할지도 함께요.

• • •

함정 1: 범용 지표

첫 번째 함정은 범용 지표예요.

eval 프레임워크를 가져다 기본 제공 지표를 그대로 쓰고 싶은 마음은 충분히 이해해요. 문제는, 실제로 무엇이 망가져 있는지 전혀 알 수 없다는 거예요. 대부분의 팀은 유용성 점수, 일관성 점수, 환각(hallucination) 점수를 대시보드에 올려 놓아요. 그럴듯하게 들리죠. 하지만 이 지표들은 너무 범용적이어서 애플리케이션의 실패를 진단하는 데는 아무 쓸모가 없어요.

데이터 과학자라면 지표를 그대로 가져다 쓰지 않아요. 데이터를 탐색하고, 트레이스를 살피고, “여기서 실제로 무엇이 망가지고 있지?”라고 물으면서, 가장 가치 있는 측정 대상을 찾아내죠. 측정할 수 있는 건 무한히 많아요. 가설을 세우고 반복해야 해요.

이 함정에 대한 가장 좋은 처방은 데이터를 직접 들여다보는 거예요.

실제로 “데이터를 들여다본다”는 게 무슨 뜻일까요? 트레이스를 읽는다는 뜻이에요. 직접 커스텀 트레이스 뷰어를 만들어서 마찰을 줄이고, 해당 도메인의 특성에 맞게 표시 방식을 조정하세요. 발견한 문제들을 메모해 두세요. 오류 분석을 해야 해요—실패 사례를 분류하고, 우선순위를 파악하고, 무엇에 집중할지 결정하세요.

데이터를 직접 들여다보면, 결국 애플리케이션 특화 지표로 나아가게 돼요. ROUGET2나 BLEU 같은 기성 유사도 지표는 LLM 출력에 잘 맞지 않아요. 실제로 중요한 지표는 “일정 예약 실패”나 “인간 에스컬레이션 누락”처럼 생겼어요.

이 글에서 단 하나만 가져가세요: 데이터를 들여다보세요. 어떻게 들여다볼지는 별개의 문제이고 연습이 필요해요. 가장 ROI가 높은 활동이면서, 동시에 가장 자주 생략되는 활동이에요.

• • •

함정 2: 검증되지 않은 판정 모델

두 번째 함정은 검증되지 않은 판정 모델이에요. 많은 팀이 자신들의 AI가 잘 작동하는지 판단하기 위해 LLM을 판정 모델(LLM judge)로 사용해요. 그런데 대부분의 경우, “그 판정 모델을 얼마나 신뢰할 수 있나요?”라는 질문에 제대로 답하는 사람이 없어요.

흔히 쓰는 방식: LLM에게 출력을 점수로 평가하게 하고 그 숫자를 그대로 사용해요. 데이터 과학자라면 판정 모델을 분류기처럼 다뤄요. 예측을 뱉는 블랙박스가 있는 거예요. 어떻게 신뢰하겠어요? 사람이 직접 레이블을 붙이고, 데이터를 train/dev/test로 분할하고, 그 분류기가 신뢰할 수 있는지 측정해요.

훈련 데이터에서 퓨샷 예제를 추출하세요. 판정 모델의 프롬프트를 dev 세트를 대상으로 힐 클라이밍(반복 개선)하세요. 오버피팅 여부를 확인하기 위해 테스트 세트는 따로 보관하세요. 머신러닝 해봤다면 지루한 작업이에요. 그런데 사람들은 이걸 하지 않아요. 분류기를 검증하는 일은 이제 현대 AI에서 사라진 기예가 됐어요.

결과를 보고할 때도 판정 모델을 분류기처럼 다루세요. 어딜 가든 정확도(accuracy)만 보고하더라고요. 어떤 실패 유형이 5%의 빈도로 발생한다면, 정확도는 시스템의 실제 성능을 숨겨버려요. precision과 recall을 사용하세요.

• • •

함정 3: 잘못된 실험 설계

세 번째 함정은 실험 설계예요. 이 주제에는 여러 차원이 있지만, 가장 자주 등장하는 두 가지를 살펴볼게요.

첫 번째는 테스트 세트 구성이에요. 대부분의 팀은 LLM에게 “테스트 쿼리 50개 만들어줘”라고 요청해서 합성 데이터를 생성해요. 그 결과물은 일반적이고 실제를 반영하지 못한 데이터예요. 데이터 과학자라면 먼저 실제 프로덕션 데이터를 살펴보고, 어떤 차원이 중요한지 가설을 세운 뒤, 그 차원을 따라 합성 예제를 생성할 거예요.

합성 데이터는 실제 로그나 트레이스에 기반을 두어야 해요. 어떤 차원을 변화시킬지 파악하고, 엣지 케이스를 주입하고, 실제 데이터를 바탕으로 합성 데이터를 만드세요.

두 번째는 메트릭 설계예요. 팀들은 전체 루브릭을 단일 LLM 호출에 몰아넣고, 기본적으로 1–5점 Likert 척도T3를 사용해요. 데이터 과학자라면 복잡도를 줄이고, 각 메트릭이 실행 가능하도록 만들고, 비즈니스 결과와 연결할 거예요. 주관적인 척도 대신 범위가 명확한 기준을 두고 이진 판정(통과/실패)을 내리세요. Likert 척도는 모호함을 감추고, 시스템 성능에 대한 어려운 결정을 뒤로 미루게 만들어요.

• • •

함정 4: 나쁜 데이터와 레이블

네 번째 함정은 나쁜 데이터와 레이블이에요. 데이터 과학자는 데이터를 믿지 않아요. 레이블을 믿지 않아요. 아무것도 믿지 않아요. 훈련을 통해 몸에 밴 회의주의예요. 대부분의 AI 엔지니어들은 아직 이 근육을 키우지 못했어요.

레이블링 작업에서 대부분의 팀은 이걸 다른 사람의 일로 넘겨요. 레이블링이 화려하지 않다 보니 개발팀에 위임하거나 외주를 줘버리죠. 데이터 과학자라면 도메인 전문가가 직접 데이터에 레이블을 달아야 한다고 주장하고, 레이블에 의문을 품고, 데이터를 직접 볼 거예요.

그런데 레이블링이 중요한 이유는 레이블 품질 때문만이 아니에요. 데이터를 직접 보지 않고서는 자신이 무엇을 원하는지 알 수가 없어요. “기준 표류(criteria drift — 평가 기준이 서서히 흐릿해지는 현상)“라는 개념이 있어요. Shreya ShankarT4와 동료들의 논문에서 검증된 개념인데, 출력물을 평가하려면 기준이 필요하지만, 출력물을 평가하는 과정 자체가 기준을 정의하는 데 도움을 준다는 거예요. 사람들은 LLM의 출력물을 직접 보기 전까지 자신이 뭘 원하는지 몰라요. 레이블링 과정 그 자체가 무엇이 중요한지를 드러내요.

데이터 과학자들은 이걸 강력히 주장해요: 도메인 전문가와 프로덕트 매니저를 요약 점수 앞이 아니라, 날것의 데이터 앞에 세우세요.

• • •

함정 5: 너무 많은 자동화

다섯 번째 함정은 너무 많은 자동화예요. 이 모든 건 사람의 몫이에요. 자동화로 없애버리고 싶은 유혹이 생기죠.

LLM은 배선 연결, 플러밍 코드 작성, 평가용 보일러플레이트 생성 등을 도울 수 있어요. 하지만 LLM이 데이터를 대신 봐줄 수는 없어요. 바로 방금 이야기한 바로 그 이유 때문이에요: 출력물을 직접 보기 전까지는 자신이 무엇을 원하는지 모르니까요.

• • •

그 밖의 함정들

모든 함정을 다 다룰 시간은 없었어요. 나머지를 빠르게 훑어볼게요.

유사도 점수를 오용하는 것. 판정 모델에게 “도움이 됐나요?” 같은 모호한 질문을 던지는 것. 주석 작업자들에게 날것의 JSON을 읽게 하는 것. 신뢰 구간 없이 보정되지 않은 점수를 보고하는 것. 데이터 드리프트, 과적합, 잘못된 샘플링, 의미 없는 대시보드.

• • •

매핑

한 발짝 물러보면, 위의 모든 함정에는 같은 근본 원인이 있어요: 데이터 사이언스 기본기의 부재.

트레이스를 읽고 실패를 분류하는 건 탐색적 데이터 분석 (EDA)이에요. LLM 판정 모델을 사람의 레이블과 대조해 검증하는 건 모델 평가예요. 실제 프로덕션 데이터로 대표성 있는 테스트셋을 구성하는 건 실험 설계예요. 도메인 전문가가 출력물에 레이블을 달게 하는 건 데이터 수집이에요. 제품이 프로덕션에서 제대로 작동하는지 모니터링하는 건 Production ML이에요. 이 중 새로운 것은 하나도 없어요. 이름만 바뀌었을 뿐, 일은 그대로예요.

여기는 Python 컨퍼런스니까요. 데이터를 들여다보고 다루는 데 Python은 여전히 최고의 도구예요.

더 깊이 파고든 오픈소스 플러그인을 만들었어요. eval 파이프라인에 연결해 보세요. 뭘 잘못하고 있는지 알려줄 거예요 — 최대한은요.

항상 데이터를 보세요.

이 발표의 밈들이 재밌으셨다면, 제 웹사이트에 훨씬 더 많이 있어요.

이 주제들을 더 깊이 공부하고 싶다면, 슬라이드와 영상이 아래에 있어요.

이 발표를 빚어낸 수많은 대화를 나눠준 Shreya Shankar와 Bryan BischofT5에게 감사해요.

영상 및 슬라이드

슬라이드 링크

각주

역자 주

  1. PyAI Conf: 파이썬 AI 개발자를 위한 미국 컨퍼런스로, LLM 응용 및 AI 엔지니어링 실무를 주제로 다뤄요. 2025년부터 시작된 비교적 새로운 행사예요. ↩
  2. ROUGE / BLEU: 텍스트 생성 품질을 자동으로 측정하는 NLP 지표예요. BLEU(Bilingual Evaluation Understudy)는 기계 번역 평가용으로 2002년 IBM이 개발했고, ROUGE(Recall-Oriented Understudy for Gisting Evaluation)는 문서 요약 평가용으로 주로 쓰여요. 두 지표 모두 참조 텍스트와의 단어 겹침을 기반으로 하기 때문에, 문맥·의미·유용성을 따지는 LLM 출력 평가에는 잘 맞지 않아요. ↩
  3. Likert 척도(Likert scale): 1932년 심리학자 Rensis Likert가 설문 응답 측정을 위해 개발한 방법으로, 보통 “1(매우 동의하지 않음) ~ 5(매우 동의함)” 형식의 등간 척도예요. AI 평가에서는 “1점 ~ 5점으로 답변 품질을 평가하세요” 형태로 많이 쓰이지만, 기준이 주관적이어서 평가자 간 일관성이 떨어지는 문제가 있어요. ↩
  4. Shreya Shankar: UC 버클리 박사과정 연구자로, LLM 평가 및 데이터 품질 분야를 연구해요. “기준 표류(criteria drift)” 개념을 다룬 논문의 주저자이며, AI 시스템의 실용적 평가 방법론으로 ML 커뮤니티에서 주목받고 있어요. ↩
  5. Bryan Bischof: 데이터 사이언스 및 LLM 엔지니어링 분야의 실무 리더예요. Building LLM Apps(O’Reilly, 2024)의 공동 저자이기도 해요. ↩

원문: The Revenge of the Data Scientist — Hamel Husain (2026년 3월 26일)

생성: Claude (Anthropic)

총괄: 존 (디노이저denoiser)

Footnotes

  1. https://hbr.org/2012/10/data-scientist-the-sexiest-job-of-the-21st-century ↩

  2. https://www.forbes.com/sites/louiscolumbus/2018/01/29/data-scientist-is-the-best-job-in-america-according-glassdoors-2018-rankings/ ↩

  3. https://www.mckinsey.com/about-us/new-at-mckinsey-blog/ai-reinvents-tech-talent-opportunities ↩