LLM API 하나면 AI 제품을 만들 수 있는 시대가 됐습니다. 파운데이션 모델을 직접 학습할 필요도 없고, 데이터 파이프라인을 처음부터 구축할 필요도 없습니다. 그런데 이상한 일이 벌어지고 있습니다. LLM 기반 시스템이 복잡해질수록, 정작 제대로 된 평가 체계를 갖춘 팀을 찾기가 점점 어려워지고 있다는 겁니다.
ML 엔지니어 Hamel Husain이 PyAI Conf에서 발표한 강연 “The Revenge of the Data Scientist”를 블로그에 정리한 글입니다. LLM 시대에 데이터 사이언티스트가 설 자리를 잃었다는 통념에 반기를 들며, 오히려 이들의 핵심 역량—데이터 보기, 메트릭 설계, 실험 설계—이 지금 가장 부재한 능력이라고 주장합니다.
출처: The Revenge of the Data Scientist – Hamel Husain
LLM 하네스의 본질은 데이터 사이언스
OpenAI가 공개한 Codex 하네스 엔지니어링 사례를 보면, 에이전트가 자율적으로 수개월간 소프트웨어 프로젝트를 진행하면서 테스트와 명세뿐 아니라 관측 스택(로그, 메트릭, 트레이스)을 기반으로 스스로 이탈 여부를 판단했습니다. Andrej Karpathy의 auto-research 프로젝트도 같은 패턴입니다. 모델이 검증 손실 메트릭에 맞춰 반복 최적화하는 구조죠.
Hamel은 이 하네스의 상당 부분이 데이터 사이언스라고 말합니다. LLM을 API로 호출한다고 해서 이 일이 사라지지는 않는다는 겁니다. 오히려 지금 현장에서는 “바이브”로 시스템을 구축하고, 모델 스스로에게 “잘 했니?”라고 묻고, 데이터는 들여다보지도 않고 기성 메트릭 라이브러리를 그대로 가져다 쓰는 일이 너무 흔합니다.
반복되는 5가지 함정
1. 범용 메트릭
팀들은 eval 프레임워크를 가져다 쓰면서 helpfulness, coherence, hallucination 점수를 대시보드에 올립니다. 들으면 합리적으로 들리지만, 실제로 무엇이 고장났는지는 알 수 없습니다. 데이터 사이언티스트라면 트레이스를 직접 읽고, 에러를 분류하고, 자기 애플리케이션에 맞는 메트릭을 설계했을 겁니다. “Calendar Scheduling Failure”나 “Failure to Escalate To Human” 같은 구체적인 지표가 ROUGE나 BLEU보다 훨씬 더 실질적입니다.
2. 검증되지 않은 LLM 판정자
많은 팀이 LLM을 판정자(judge)로 씁니다. 문제는 “그 판정자를 어떻게 신뢰하냐”는 질문에 답하지 못한다는 겁니다. 데이터 사이언티스트는 이 판정자를 분류기처럼 취급합니다. 사람이 직접 레이블링한 데이터로 train/dev/test를 나누고, 판정자가 얼마나 신뢰할 수 있는지를 측정하죠. 그리고 정확도(accuracy) 대신 정밀도(precision)와 재현율(recall)로 보고합니다. 실패 모드가 5%에 불과해도 정확도 지표는 그걸 숨기니까요.
3. 허술한 실험 설계
대부분의 팀은 LLM에게 “테스트 쿼리 50개 만들어줘”라고 합니다. 그 결과물은 실제 사용 패턴과 동떨어진 범용적인 데이터입니다. 데이터 사이언티스트는 실제 프로덕션 로그나 트레이스를 먼저 보고, 어떤 차원이 중요한지 가설을 세운 다음에 합성 데이터를 생성합니다. 메트릭 설계도 마찬가지입니다. 전체 평가 기준을 단일 LLM 호출에 묶고 1~5점 척도를 기본값으로 쓰는 팀이 많은데, 데이터 사이언티스트라면 각 메트릭을 독립적으로 만들고 주관적인 척도 대신 통과/실패 이진 기준으로 단순화할 겁니다.
4. 나쁜 데이터와 레이블
레이블링은 번거롭다는 이유로 개발팀에 떠넘기거나 외주로 돌리는 경우가 많습니다. 데이터 사이언티스트는 도메인 전문가가 직접 레이블링에 참여해야 한다고 주장합니다. Shreya Shankar 연구팀의 논문에서 확인된 개념인 “기준 표류(criteria drift)”처럼, 사람들은 LLM의 출력을 직접 보기 전까지 자신이 무엇을 원하는지 모릅니다. 레이블링 과정 자체가 중요한 것이 무엇인지를 드러내 주기 때문에, 요약 점수가 아닌 날것의 데이터를 도메인 전문가와 PM 앞에 직접 놓는 것이 중요합니다.
5. 과도한 자동화
LLM은 평가의 배관을 짜고 보일러플레이트를 만드는 데는 도움이 됩니다. 하지만 데이터를 대신 들여다봐 줄 수는 없습니다. 자신이 원하는 것을 정의하는 일은 결국 사람이 직접 해야 합니다.
이름만 바뀌었을 뿐
Hamel은 이 5가지 함정 모두 같은 뿌리에서 온다고 말합니다. 트레이스를 읽고 실패를 분류하는 건 탐색적 데이터 분석(EDA)이고, LLM 판정자를 사람 레이블로 검증하는 건 모델 평가이며, 프로덕션 데이터로 테스트셋을 만드는 건 실험 설계입니다. 이름이 달라졌을 뿐 일 자체는 사라지지 않았습니다.
LLM API가 모델 구축의 장벽을 낮췄지만, 그 시스템이 실제로 잘 작동하는지 판단하는 체계를 만드는 일은 여전히 데이터 사이언스의 영역입니다. 저자가 공개한 eval 진단 오픈소스 플러그인과 강연 슬라이드, 영상은 원문에서 확인할 수 있습니다.
참고자료:
답글 남기기