Skip to content

Data Scientist

빅데이터 분석가(Big Data Analyst)는 빅데이터 전문가로 ‘디지털 사이언티스트(Digital Scientist)’ 혹은 ‘데이터 과학자’(Data Scientist)로 불리는 전문가이다.

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

  • 데이터 사이언티스트의 역습 | GeekNews
  • LLM API 등장으로 데이터 사이언티스트·MLE가 AI 출시 핵심 경로에서 배제되었지만, 실제 업무의 본질—실험 설계, 지표 측정, 확률적 시스템 디버깅—은 사라지지 않았음
  • OpenAI의 Codex 사례와 Karpathy의 auto-research 프로젝트 모두 테스트·지표·관측 스택으로 구성된 하네스(harness) 가 핵심임을 보여주며, 이 하네스의 상당 부분이 데이터 사이언스임
  • 현장에서 반복적으로 나타나는 5가지 평가(eval) 함정—범용 지표, 미검증 심판 모델, 잘못된 실험 설계, 불량 데이터·레이블, 과도한 자동화—이 AI 시스템 품질을 저해하고 있음
  • 각 함정의 공통 원인은 데이터 사이언스 기본기 부재이며, 탐색적 데이터 분석·모델 평가·실험 설계·데이터 수집·프로덕션 ML 등 기존 방법론이 그대로 해법임
  • "데이터를 직접 보는 것" 이 가장 ROI가 높은 활동임에도 가장 자주 생략되며, 데이터 사이언티스트의 역할은 LLM 시대에도 여전히 핵심임

하네스(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 파이프라인을 분석하고 잘못된 부분을 진단하는 도구 공개

See also

Favorite site