데이터 과학자의 복귀

• LLM과 Foundation Model API 확산으로 AI 배포 과정에서 데이터 과학자의 역할이 축소되었지만, 실험 설계·디버깅·지표 설계 등 핵심 업무는 여전히 필수적임
• Harness Engineering과 같은 자율 코드 개발 환경에서도 로그·메트릭·트레이스 관리가 필요하며, 이는 본질적으로 데이터 과학의 영역에 속함
• 범용 메트릭, 검증되지 않은 평가자, 잘못된 실험 설계, 나쁜 데이터, 과도한 자동화 등 다섯 가지 평가 함정이 반복적으로 발생함
• 이러한 문제의 근본 원인은 데이터 과학의 기본 원리 부재로, 탐색적 데이터 분석과 모델 평가, 실험 설계, 데이터 수집의 중요성이 다시 부각됨
• 결국 데이터를 직접 살펴보는 능력이 가장 높은 가치의 활동이며, 데이터 과학자의 핵심 역량으로 재조명되고 있음

데이터 과학자의 부활

• 데이터 과학자는 한때 “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) 메트릭을 기준으로 반복 최적화하는 동일한 패턴을 보임
• 이러한 하니스의 상당 부분이 데이터 과학의 영역에 해당
  • 과거에는 데이터 점검, 라벨 정합성 확인, 메트릭 설계에 많은 시간을 썼으나
  • 현재는 모델의 “감(感)”에 의존하거나, 오픈소스 메트릭 라이브러리를 그대로 사용하는 경향이 있음
• 특히 RAG(Retrieval-Augmented Generation) 이나 Evals(평가) 영역에서 데이터 이해 부족으로 오해가 많음
  • 데이터 과학자는 이를 체계적으로 다루며, 다섯 가지 주요 평가 함정을 구체적으로 제시

일반화된 메트릭(Generic Metrics)

• 첫 번째 함정은 범용 메트릭 사용
  • 많은 팀이 ‘도움됨’, ‘일관성’, ‘환각률’ 같은 일반 점수를 대시보드에 표시하지만, 실제 문제 원인을 파악하기에는 무용
• 데이터 과학자는 데이터 탐색과 트레이스 분석을 통해 무엇이 깨지고 있는지 규명
  • 가설을 세우고 반복 측정하며, 가장 가치 있는 지표를 직접 정의
• 데이터를 직접 살펴보는 것이 가장 높은 ROI를 가진 활동
  • 커스텀 트레이스 뷰어를 만들어 도메인 특성에 맞게 시각화
  • 오류를 분류하고 우선순위를 정해 개선 방향을 결정
• 결과적으로 애플리케이션 특화 메트릭으로 발전
  • 예: “일정 예약 실패”, “사람에게 에스컬레이션 실패”
  • ROUGE, BLEU 같은 범용 유사도 지표는 LLM 출력에 적합하지 않음

검증되지 않은 평가자(Unverified Judges)

• 두 번째 함정은 검증되지 않은 LLM 평가자 사용
  • 많은 팀이 LLM을 판정자로 사용하지만, 신뢰성 검증 절차가 없음
• 데이터 과학자는 평가자를 분류기(classifier) 로 간주
  • 인간 라벨을 확보하고, train/dev/test 세트를 나누어 신뢰도를 측정
  • few-shot 예시를 학습 세트에서 가져오고, dev 세트로 프롬프트를 조정하며, test 세트로 과적합 여부 확인
• 결과 보고 시에도 분류기처럼 정밀도(precision)와 재현율(recall) 을 사용
  • 정확도만으로는 5%의 실패율 같은 문제를 감춤

잘못된 실험 설계(Bad Experimental Design)

• 세 번째 함정은 실험 설계 부재
  • 많은 팀이 LLM에 “테스트 쿼리 50개 생성”을 요청해 비현실적 테스트 세트를 만듦
  • 데이터 과학자는 실제 운영 로그나 트레이스 기반으로 테스트 세트를 구성
  • 가설에 따라 중요 차원을 정의하고, 엣지 케이스를 주입
• 메트릭 설계에서도 문제 발생
  • 팀은 1~5점 리커트 척도로 평가하지만, 데이터 과학자는 이를 이진(pass/fail) 기준으로 단순화
  • 각 메트릭을 행동 가능하고 비즈니스 결과와 연결된 형태로 설계
  • 리커트 척도는 모호성을 숨기고 성능 판단을 지연시킴

나쁜 데이터와 라벨(Bad Data and Labels)

• 네 번째 함정은 데이터와 라벨에 대한 불신 부족
  • 데이터 과학자는 본능적으로 데이터를 의심하지만, 많은 AI 엔지니어는 그렇지 않음
• 라벨링은 종종 개발팀이나 외주에 위임되며, 도메인 전문가는 배제됨
  • 데이터 과학자는 도메인 전문가가 직접 라벨링하고, 결과를 지속적으로 검증해야 한다고 봄
• 라벨링은 단순 품질 문제가 아니라 요구사항 정의 과정이기도 함
  • Shreya Shankar 등의 연구에 따르면, 사용자는 LLM 출력을 보고 나서야 자신이 원하는 기준을 명확히 인식
  • 이를 criteria drift라 부르며, 라벨링 과정이 곧 기준을 형성하는 과정임
• 따라서 제품 관리자와 도메인 전문가가 원시 데이터에 직접 접근해야 함

과도한 자동화(Automating Too Much)

• 다섯 번째 함정은 자동화의 과잉
  • LLM이 평가 파이프라인의 코드나 보일러플레이트를 작성하는 데 도움은 줄 수 있으나

  • 데이터를 직접 살펴보는 인간의 역할은 대체 불가

    • 사용자가 실제 출력을 보기 전까지는 무엇을 원하는지 알 수 없기 때문

기타 함정(Other Pitfalls)

• 추가로 언급된 문제들
  • 유사도 점수 오용, “도움이 되었는가?” 같은 모호한 질문, JSON 원문을 읽게 하는 주석자, 신뢰 구간 없는 비보정 점수 보고, 데이터 드리프트, 과적합, 잘못된 샘플링, 의미 없는 대시보드 등

데이터 과학으로의 회귀(The Mapping)

• 모든 함정의 근본 원인은 데이터 과학의 기본 원리 결여
  • 트레이스 읽기와 오류 분류 → 탐색적 데이터 분석(EDA)
  • LLM 평가자 검증 → 모델 평가(Model Evaluation)
  • 운영 데이터 기반 테스트 세트 구성 → 실험 설계(Experimental Design)
  • 도메인 전문가의 라벨링 → 데이터 수집(Data Collection)
  • 운영 중 제품 성능 모니터링 → 프로덕션 ML
• 이름만 바뀌었을 뿐, 작업의 본질은 동일
• Python은 여전히 데이터를 다루고 분석하는 데 가장 강력한 도구
  • 오픈소스 플러그인 evals-skills를 통해 평가 파이프라인의 문제점을 자동 점검 가능
• 결론적으로, 항상 데이터를 직접 살펴보는 것이 데이터 과학자의 핵심 역량임