# 데이터 사이언티스트의 역습 > Clean Markdown view of GeekNews topic #28105. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=28105](https://news.hada.io/topic?id=28105) - GeekNews Markdown: [https://news.hada.io/topic/28105.md](https://news.hada.io/topic/28105.md) - Type: GN+ - Author: [xguru](https://news.hada.io/@xguru) - Published: 2026-04-02T10:34:04+09:00 - Updated: 2026-04-02T10:34:04+09:00 - Original source: [hamel.dev](https://hamel.dev/blog/posts/revenge/) - Points: 22 - Comments: 2 ## Summary LLM API 시대에 데이터 사이언티스트가 불필요해졌다는 시각에 반론을 제기하는 글입니다. 모델 학습은 API로 대체됐지만, **실험 설계, 지표 측정, 확률적 시스템 디버깅** 같은 본질적 역량은 오히려 더 중요해졌다는 주장인데요. 현장에서 반복되는 **5가지 eval 함정**을 짚으면서, 결국 원인이 모두 **데이터 사이언스 기본기 부재**로 귀결된다고 분석합니다. 특히 "데이터를 직접 보는 것이 가장 ROI가 높은 활동인데 가장 자주 생략된다"는 지적이 뼈아프고요. AI 제품을 만들고 있는 팀이라면 eval을 어떻게 설계하고 있는지 되돌아보게 되는 글입니다. ## Topic Body - LLM API 등장으로 데이터 사이언티스트·MLE가 AI 출시 핵심 경로에서 배제되었지만, 실제 업무의 본질—**실험 설계, 지표 측정, 확률적 시스템 디버깅**—은 사라지지 않았음 - OpenAI의 Codex 사례와 Karpathy의 auto-research 프로젝트 모두 **테스트·지표·관측 스택으로 구성된 하네스(harness)** 가 핵심임을 보여주며, 이 하네스의 상당 부분이 데이터 사이언스임 - 현장에서 반복적으로 나타나는 **5가지 평가(eval) 함정**—범용 지표, 미검증 심판 모델, 잘못된 실험 설계, 불량 데이터·레이블, 과도한 자동화—이 AI 시스템 품질을 저해하고 있음 - 각 함정의 공통 원인은 **데이터 사이언스 기본기 부재**이며, 탐색적 데이터 분석·모델 평가·실험 설계·데이터 수집·프로덕션 ML 등 기존 방법론이 그대로 해법임 - **"데이터를 직접 보는 것"** 이 가장 ROI가 높은 활동임에도 가장 자주 생략되며, 데이터 사이언티스트의 역할은 LLM 시대에도 여전히 핵심임 --- ### 데이터 과학자의 부활 - 데이터 과학자는 한때 **“21세기에서 가장 섹시한 직업”** 으로 불리며 높은 보수를 받았음 - 예측 모델링, 인과관계 측정, 데이터 패턴 탐색 등 복합 기술을 요구 - 이후 예측 모델링 업무가 **Machine Learning Engineer(MLE)** 로 분리됨 - **LLM(대형 언어 모델)** 의 등장으로 기업이 AI를 배포할 때 데이터 과학자나 MLE가 필수 경로에서 제외되는 변화 발생 - Foundation Model API를 통해 팀이 독립적으로 AI를 통합 가능 - 그러나 모델 학습이 데이터 과학자의 전부는 아니며, **실험 설계·디버깅·지표 설계**가 여전히 핵심 업무로 남음 - LLM API 호출만으로는 이러한 작업이 사라지지 않음 - PyAI Conf의 “The Revenge of the Data Scientist” 발표는 이 점을 사례 중심으로 다루며, **데이터 과학의 역할이 여전히 중요함**을 강조 ### 하네스(Harness)의 본질은 데이터 사이언스 - OpenAI의 **Harness Engineering** 개념은 에이전트가 테스트와 명세로 둘러싸인 환경에서 자율적으로 코드를 개발하는 구조를 설명 - 하니스에는 **로그, 메트릭, 트레이스** 등 관측 가능성 스택이 포함되어, 에이전트가 스스로 이상 동작을 감지 가능 - Andrej Karpathy의 **auto-research 프로젝트**도 검증 손실(validation loss) 메트릭을 기준으로 반복 최적화하는 동일한 패턴을 보임 - "LLM을 API로 호출하는 것"이 실험 설계·디버깅·지표 설계 작업을 없애지는 않으며, **하네스의 상당 부분이 데이터 사이언스**임 - 과거에는 데이터 점검, 라벨 정합성 확인, 메트릭 설계에 많은 시간을 썼으나 - 현재는 모델의 “감(感, Vibes)”에 의존하거나, 오픈소스 메트릭 라이브러리를 그대로 사용하는 경향이 있음 - 특히 **RAG(Retrieval-Augmented Generation)** 이나 **Evals(평가)** 영역에서 데이터 이해 부족으로 오해가 많음 - **RAG is dead, evals are dead** 같은 주장이 나오지만, 정작 그런 주장을 하는 팀들도 해당 개념에 의존하는 시스템을 구축하고 있음 - 데이터 배경 없는 엔지니어들이 이해하지 못하는 것을 두려워하며 회피하는 현상이 retrieval과 evals 영역에서 두드러짐 - "LLM을 API로 호출하는 것"이 실험 설계·디버깅·지표 설계 작업을 없애지는 않으며, **하네스의 상당 부분이 데이터 사이언스**임 ### 5가지 Eval 함정 - ## 함정 1: 범용 지표(Generic Metrics) - Helpfulness score, coherence score, hallucination score 같은 **범용 지표**는 애플리케이션의 실제 장애를 진단하기에 너무 포괄적임 - 데이터 사이언티스트라면 지표를 바로 채택하지 않고 데이터와 트레이스를 직접 탐색하며 "실제로 무엇이 깨지고 있는가"를 먼저 파악함 - **"데이터를 본다"** 는 것은 트레이스를 직접 읽고, 커스텀 트레이스 뷰어를 만들고, 실패를 분류하는 오류 분석(error analysis)을 의미함 - ROUGE, BLEU 같은 범용 유사도 지표는 LLM 출력에 거의 맞지 않으며, **"Calendar Scheduling Failure"** 나 **"Failure to Escalate To Human"** 같은 애플리케이션 특화 지표가 필요함 - 데이터를 보는 것이 가장 ROI가 높은 활동이며 가장 자주 생략됨 - ## 함정 2: 미검증 심판 모델(Unverified Judges) - LLM을 심판으로 사용하는 팀 대부분이 **"심판을 어떻게 신뢰하는가"** 에 대한 답을 갖고 있지 않음 - 데이터 사이언티스트는 심판을 **분류기(classifier)** 처럼 다루며, 인간 레이블을 확보하고 train/dev/test로 분할해 신뢰도를 측정함 - Few-shot 예시는 학습 세트에서 가져오고, dev set으로 심판 프롬프트를 개선하며, test set은 오버피팅 확인용으로 보존함 - 결과 보고 시 단순 **accuracy** 대신 **precision과 recall**을 사용해야 함 — 실패 모드가 5%에 불과해도 accuracy는 실제 성능을 숨김 - 분류기 검증이 현대 AI에서 **사라진 기술**이 되었음 - ## 함정 3: 잘못된 실험 설계(Bad Experimental Design) - **테스트 세트 구성**: 대부분의 팀이 LLM에게 "테스트 쿼리 50개 생성해 달라"고 요청하는데, 이 방식은 **비대표적인 범용 데이터**를 생성함 - 데이터 사이언티스트라면 실제 프로덕션 데이터를 먼저 살펴보고, 중요한 차원(dimensions)을 파악한 뒤 그 차원에 맞는 합성 예시를 생성함 - 실제 로그나 트레이스에 기반해 합성 데이터를 생성하고, 엣지 케이스를 주입해야 함 - **지표 설계**: 전체 루브릭을 단일 LLM 호출에 담고 1~5점 **Likert 척도**를 기본값으로 사용하는 방식은 모호성을 숨기고 시스템 성능에 대한 어려운 결정을 미루는 것임 - 범위가 좁은 기준에 대한 **이진(pass/fail) 판단**으로 대체해야 함 - ## 함정 4: 불량 데이터·레이블(Bad Data and Labels) - 레이블링이 비화려하다는 이유로 개발팀에 위임되거나 외주화되는 경향이 있으나, 데이터 사이언티스트는 **도메인 전문가**가 직접 레이블링하도록 요구함 - 레이블 품질 외에 더 깊은 이유가 있음: Shreya Shankar 등의 논문에서 검증된 **"criteria drift"** 개념—사용자는 출력물을 평가하기 위해 기준이 필요하지만, 출력물을 평가하는 과정에서 기준을 정의하게 됨. 즉, **LLM 출력을 보기 전까지 자신이 무엇을 원하는지 모름** - 도메인 전문가와 PM을 요약 점수가 아닌 **원시 데이터** 앞에 배치해야 함 - ## 함정 5: 과도한 자동화(Automating Too Much) - LLM은 배관 코드(plumbing) 작성, 보일러플레이트 생성, 평가 연결 작업을 도울 수 있음 - 그러나 **데이터를 직접 보는 작업은 자동화 불가** — "출력을 보기 전까지 무엇을 원하는지 모른다"는 이유 때문임 - 나머지 언급된 추가 함정: 유사도 점수 오용, "도움이 되는가?" 같은 모호한 질문을 심판에게 던지기, 주석자에게 raw JSON 읽히기, 신뢰구간 없는 미보정 점수 보고, 데이터 드리프트, 오버피팅, 잘못된 샘플링, 이해하기 어려운 대시보드 ### 데이터 사이언스 기본기와의 매핑 - 5가지 함정 모두 **데이터 사이언스 기본기 부재**라는 동일한 근본 원인을 가짐 - 각 함정과 기존 방법론의 대응 관계: - 트레이스 읽기·실패 분류 → **탐색적 데이터 분석(EDA)** - 인간 레이블로 LLM 심판 검증 → **모델 평가(Model Evaluation)** - 프로덕션 데이터 기반 대표 테스트 세트 구축 → **실험 설계(Experimental Design)** - 도메인 전문가 레이블링 → **데이터 수집(Data Collection)** - 프로덕션에서 제품 작동 모니터링 → **프로덕션 ML(Production ML)** - 이름은 바뀌었지만 업무 자체는 동일함 - Python은 데이터를 탐색하고 다루는 데 여전히 **최적의 툴셋**임 - **오픈소스 플러그인**([evals-skills](https://github.com/hamelsmu/evals-skills))을 통해 eval 파이프라인을 분석하고 잘못된 부분을 진단하는 도구 공개 ## Comments ### Comment 54414 - Author: neo - Created: 2026-04-02T10:34:04+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=47557385) - GenAI 솔루션을 구축할 때 좋은 실천법들이지만, 이 변화가 **데이터 사이언티스트** 직군의 지속 가능성을 보장하진 않는다고 생각함 과거에는 모델을 직접 만들어 **비즈니스 가치를 창출**하는 능력 때문에 데이터 사이언티스트가 주목받았음 하지만 지금은 LLM 제공자와 API를 호출하는 엔지니어가 그 역할을 대신함. LLM의 동작을 조정하는 건 일종의 블랙매직이지만, 수학적 지식이 꼭 필요한 건 아님 이제 남는 일은 평가와 모니터링인데, 이는 비즈니스 관점에서 ‘핵심 가치’로 보이지 않음. 빠르게 프로토타입을 배포하려는 조직에서는 오히려 방해 요소로 여겨짐 결국 “데이터 사이언티스트가 LLM 구축의 게이트키퍼가 되어야 한다”고 설득해야 하는 상황인데, 그 논리가 얼마나 설득력 있을지는 의문임 - 나도 비슷하게 느꼈음. **기성 LLM**을 사용하는 데 데이터 사이언티스트가 꼭 필요하지 않음. 나 같은 AI 친화적 엔지니어도 금방 익힐 수 있었음 다만 LLM 외에도 여전히 **맞춤형 ML 모델**이 필요한 영역이 많다고 생각함. 예를 들어 AirBnB의 검색 랭킹이나 Uber의 매칭 알고리즘은 LLM으로 대체 불가함 결국 시장이 줄어든 건 맞지만, 완전히 사라진 건 아님 - 리더십을 설득하기 어렵고, 실제로 많은 DS들도 이런 **평가 작업**을 하고 싶어하지 않음 하지만 이 과정은 “무엇을 해결하려는가”를 명확히 정의하게 만들어줌. 때로는 그 답이 “이 제품은 만들 가치가 없다”일 수도 있음 다만 이런 이야기를 듣고 싶어하는 사람은 거의 없음 - 평가 작업이 꼭 데이터 사이언티스트의 영역이어야 하는 이유를 모르겠음 **SWE 출신 AI 엔지니어**들이 오히려 더 잘 맞는 경우가 많음. “평가 = 자동화된 테스트”라는 사고방식이 자연스럽기 때문임 실제로 많은 에이전트 프로젝트에서 DS의 역할이 거의 사라지고 있음 - 데이터 사이언티스트가 제공하던 **통계적 엄밀성**이 LLM 기반 솔루션에서는 거의 사라진 것 같음 - 데이터 사이언티스트들에게 자주 하는 조언임 1) 컨텍스트 데이터를 **훈련 데이터**로 생각할 것 — LLM은 주어진 문맥으로부터 학습함 2) 평가 데이터는 **테스트 데이터**로 생각할 것 — 에이전트의 실행 로그에서 수집하고 수동으로 라벨링해야 함 LLM을 판정자로 쓰려면, 그 모델도 결국 좋은 예시 데이터를 통해 인컨텍스트 학습을 해야 함 관련 내용은 내 [책](https://www.amazon.com/Building-Machine-Learning-Systems-Fea...)에 정리되어 있음 - 완전 동의함. “Evaluations = Tests” 다만 모델이 다른 모델의 출력을 평가해야 하는 경우엔 **메타적 구조**가 되어버려, 결국 어딘가에서는 ‘진짜 정답’을 고정해야 함 - 나는 데이터 사이언스/엔지니어링 배경을 가졌음 AI를 사용하는 건 마치 **해결 공간을 탐색**하는 일과 같음. 수십억 개의 파라미터 조합 중 최적점을 찾는 과정임 프롬프트로 탐색 공간을 좁히고, 의미 기반 휴리스틱으로 더 나은 해를 찾으려 함 종종 지역 최적점에 갇히기도 하고, 완전히 잘못된 방향으로 가기도 함. 그래서 매주 코드베이스를 새로 시작하며 단순화하거나 기능을 추가함. 그렇게 해야 더 나은 해를 찾을 수 있음 - 최근 언급된 [pg_textsearch](https://news.ycombinator.com/item?id=47589856) 같은 사례는 이런 개발 방식이 잘 맞는 예시라고 생각함 명확한 테스트 케이스와 벤치마크가 있을 때는 성공 가능성이 높음 하지만 **그린필드 개발**에서는 테스트 케이스를 정의하는 게 코드 작성만큼 어렵거나 더 어려움 또한 LLM은 종종 **로컬 미니마**에 갇히는 경향이 있음. 코드 구조가 굳어지면 큰 리팩터링을 거의 시도하지 않음. 일종의 오버피팅과 비슷한 현상임 - AI 실험의 핵심은 모델이 새로운 데이터에 얼마나 **일반화**하는지를 검증하는 것이라 했지만, 실제로는 “데이터가 무엇인지”를 명확히 확인하는 과정이 빠져 있음 종종 사람들이 생각하는 데이터와 실제 데이터가 다르기 때문임 - 나는 복잡한 LLM-판정자 워크플로우를 만드는 것보다, **에이전트의 동작을 직접 관찰**하는 게 훨씬 더 많은 인사이트를 줌 - 어제 **Karpathy의 autoresearch** 접근법을 ML 문제에 적용해봤음 여러 번의 실험 끝에 모델이 보여준 결과에 놀랐음. Kaggle이 여전히 활발했다면, AI가 대부분의 문제를 이겼을 것 같음 하지만 현실의 데이터 사이언스 작업은 대부분 **기초 도구조차 제대로 모르는 사람들**이 많음. AI를 준다고 해서 그들이 갑자기 뛰어나질 것 같진 않음 결국 전문가들은 여전히 주니어를 부려서 일하고, 비전문가들은 엉성한 결과물 속에서 헤매게 됨 - Kaggle 문제라면 AI가 꽤 잘할 수 있을 것 같음 하지만 실제 DS 업무는 **불완전한 데이터와 모호한 목표**를 다루는 일이 대부분임 좋은 DS는 “이건 안 됩니다”라고 말할 줄 알아야 함. 반면 LLM은 언제나 “좋아요, 멋진 아이디어네요!”라고만 함 - 결국 AI 개발도 비슷한 루프임 — “좋은 결과가 무엇인지 정의하고, 그와의 차이를 측정하고, 반복 개선하는” 과정임 다만 이런 사고방식을 오래 해온 사람들은 **프롬프트 엔지니어**보다 훨씬 앞서 있음 ### Comment 54516 - Author: raykim - Created: 2026-04-03T09:07:32+09:00 - Points: 1 - Parent comment: 54414 - Depth: 1 여기 DS분들이 댓글 달아주셨는지 모르겠습니다. 모두 개발자 시선인듯해서..