▲

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

 (hamel.dev)
4P by GN⁺ 5시간전 | ★ favorite | 댓글 1개
  • 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)을 통해 eval 파이프라인을 분석하고 잘못된 부분을 진단하는 도구 공개
▲
GN⁺ 5시간전  [-]
Hacker News 의견들

  • GenAI 솔루션을 구축할 때 좋은 실천법들이지만, 이 변화가 데이터 사이언티스트 직군의 지속 가능성을 보장하진 않는다고 생각함
    과거에는 모델을 직접 만들어 비즈니스 가치를 창출하는 능력 때문에 데이터 사이언티스트가 주목받았음
    하지만 지금은 LLM 제공자와 API를 호출하는 엔지니어가 그 역할을 대신함. LLM의 동작을 조정하는 건 일종의 블랙매직이지만, 수학적 지식이 꼭 필요한 건 아님
    이제 남는 일은 평가와 모니터링인데, 이는 비즈니스 관점에서 ‘핵심 가치’로 보이지 않음. 빠르게 프로토타입을 배포하려는 조직에서는 오히려 방해 요소로 여겨짐
    결국 “데이터 사이언티스트가 LLM 구축의 게이트키퍼가 되어야 한다”고 설득해야 하는 상황인데, 그 논리가 얼마나 설득력 있을지는 의문임

    • 나도 비슷하게 느꼈음. 기성 LLM을 사용하는 데 데이터 사이언티스트가 꼭 필요하지 않음. 나 같은 AI 친화적 엔지니어도 금방 익힐 수 있었음
      다만 LLM 외에도 여전히 맞춤형 ML 모델이 필요한 영역이 많다고 생각함. 예를 들어 AirBnB의 검색 랭킹이나 Uber의 매칭 알고리즘은 LLM으로 대체 불가함
      결국 시장이 줄어든 건 맞지만, 완전히 사라진 건 아님
    • 리더십을 설득하기 어렵고, 실제로 많은 DS들도 이런 평가 작업을 하고 싶어하지 않음
      하지만 이 과정은 “무엇을 해결하려는가”를 명확히 정의하게 만들어줌. 때로는 그 답이 “이 제품은 만들 가치가 없다”일 수도 있음
      다만 이런 이야기를 듣고 싶어하는 사람은 거의 없음
    • 평가 작업이 꼭 데이터 사이언티스트의 영역이어야 하는 이유를 모르겠음
      SWE 출신 AI 엔지니어들이 오히려 더 잘 맞는 경우가 많음. “평가 = 자동화된 테스트”라는 사고방식이 자연스럽기 때문임
      실제로 많은 에이전트 프로젝트에서 DS의 역할이 거의 사라지고 있음
    • 데이터 사이언티스트가 제공하던 통계적 엄밀성이 LLM 기반 솔루션에서는 거의 사라진 것 같음

  • 데이터 사이언티스트들에게 자주 하는 조언임

    1. 컨텍스트 데이터를 훈련 데이터로 생각할 것 — LLM은 주어진 문맥으로부터 학습함
    2. 평가 데이터는 테스트 데이터로 생각할 것 — 에이전트의 실행 로그에서 수집하고 수동으로 라벨링해야 함
      LLM을 판정자로 쓰려면, 그 모델도 결국 좋은 예시 데이터를 통해 인컨텍스트 학습을 해야 함
      관련 내용은 내 책에 정리되어 있음
    • 완전 동의함. “Evaluations = Tests”
      다만 모델이 다른 모델의 출력을 평가해야 하는 경우엔 메타적 구조가 되어버려, 결국 어딘가에서는 ‘진짜 정답’을 고정해야 함

  • 나는 데이터 사이언스/엔지니어링 배경을 가졌음
    AI를 사용하는 건 마치 해결 공간을 탐색하는 일과 같음. 수십억 개의 파라미터 조합 중 최적점을 찾는 과정임
    프롬프트로 탐색 공간을 좁히고, 의미 기반 휴리스틱으로 더 나은 해를 찾으려 함
    종종 지역 최적점에 갇히기도 하고, 완전히 잘못된 방향으로 가기도 함. 그래서 매주 코드베이스를 새로 시작하며 단순화하거나 기능을 추가함. 그렇게 해야 더 나은 해를 찾을 수 있음

  • 최근 언급된 pg_textsearch 같은 사례는 이런 개발 방식이 잘 맞는 예시라고 생각함
    명확한 테스트 케이스와 벤치마크가 있을 때는 성공 가능성이 높음
    하지만 그린필드 개발에서는 테스트 케이스를 정의하는 게 코드 작성만큼 어렵거나 더 어려움
    또한 LLM은 종종 로컬 미니마에 갇히는 경향이 있음. 코드 구조가 굳어지면 큰 리팩터링을 거의 시도하지 않음. 일종의 오버피팅과 비슷한 현상임

  • AI 실험의 핵심은 모델이 새로운 데이터에 얼마나 일반화하는지를 검증하는 것이라 했지만, 실제로는 “데이터가 무엇인지”를 명확히 확인하는 과정이 빠져 있음
    종종 사람들이 생각하는 데이터와 실제 데이터가 다르기 때문임

  • 나는 복잡한 LLM-판정자 워크플로우를 만드는 것보다, 에이전트의 동작을 직접 관찰하는 게 훨씬 더 많은 인사이트를 줌

  • 어제 Karpathy의 autoresearch 접근법을 ML 문제에 적용해봤음
    여러 번의 실험 끝에 모델이 보여준 결과에 놀랐음. Kaggle이 여전히 활발했다면, AI가 대부분의 문제를 이겼을 것 같음
    하지만 현실의 데이터 사이언스 작업은 대부분 기초 도구조차 제대로 모르는 사람들이 많음. AI를 준다고 해서 그들이 갑자기 뛰어나질 것 같진 않음
    결국 전문가들은 여전히 주니어를 부려서 일하고, 비전문가들은 엉성한 결과물 속에서 헤매게 됨

    • Kaggle 문제라면 AI가 꽤 잘할 수 있을 것 같음
      하지만 실제 DS 업무는 불완전한 데이터와 모호한 목표를 다루는 일이 대부분임
      좋은 DS는 “이건 안 됩니다”라고 말할 줄 알아야 함. 반면 LLM은 언제나 “좋아요, 멋진 아이디어네요!”라고만 함

  • 결국 AI 개발도 비슷한 루프임 — “좋은 결과가 무엇인지 정의하고, 그와의 차이를 측정하고, 반복 개선하는” 과정임
    다만 이런 사고방식을 오래 해온 사람들은 프롬프트 엔지니어보다 훨씬 앞서 있음

답변달기