이 논문은 대규모 언어 모델(LLM) 및 파운데이션 모델(Foundation Model) API의 부상으로 인해 데이터 과학자와 머신러닝 엔지니어(MLE)의 역할이 약화되고 있다는 인식에 반박하며, 데이터 과학의 핵심적인 가치가 여전히 유효하고 오히려 더욱 중요해지고 있음을 주장합니다. 저자는 과거 '21세기 가장 섹시한 직업'으로 불렸던 데이터 과학이 모델 훈련(training)을 넘어선 영역, 즉 AI 시스템의 평가, 디버깅, 최적화에 필수적인 역할을 한다고 강조합니다.

저자는 "하네스(Harness)가 곧 데이터 과학이다"라는 핵심 주장을 펼칩니다. 이는 OpenAI의 '하네스 엔지니어링' 개념에서 영감을 얻은 것으로, 자율적인 AI 에이전트가 성공적으로 작동하기 위해서는 테스트, 사양(specifications)뿐만 아니라 로그(logs), 메트릭스(metrics), 트레이스(traces)와 같은 관측 가능성(observability) 스택을 포함하는 '하네스'가 필수적이라고 설명합니다. 저자는 이 하네스의 상당 부분이 데이터 과학이라고 주장하며, 현재 많은 팀이 '감'에 의존하거나, 모델에게 자체 평가를 맡기거나, 데이터에 대한 이해 없이 상용 메트릭스 라이브러리를 사용하는 문제점을 지적합니다. 특히 Retrieval-Augmented Generation (RAG) 및 평가(evals) 영역에서 이러한 문제점이 두드러진다고 덧붙입니다.

논문은 AI 시스템 평가 시 자주 발생하는 다섯 가지 일반적인 함정(pitfalls)을 제시하고, 각 함정에서 데이터 과학자가 어떻게 다르게 접근할지 상세히 설명합니다. 이것이 곧 논문의 핵심 방법론이자 데이터 과학적 접근 방식에 대한 구체적인 설명입니다.

1. Generic Metrics (일반적인 메트릭스):
   • 문제점: 상용 평가 프레임워크의 일반적인 메트릭스(예: 유용성, 일관성, 환각 점수)를 사용하여 무엇이 문제인지 진단하기 어렵습니다.
   • 데이터 과학자의 접근: 데이터 과학자는 데이터를 탐색하고, 트레이스(traces)를 면밀히 분석하며, "무엇이 실제로 문제를 일으키는가?"라는 질문을 던집니다. 이를 통해 가장 가치 있는 측정 대상을 식별하고 가설을 세워 반복합니다. 사용자 정의 트레이스 뷰어(custom trace viewer)를 개발하여 도메인의 특이성에 맞게 표시하고, 오류 분석(error analysis)을 수행하여 실패 유형을 분류하고 우선순위를 정합니다. 궁극적으로 ROUGE나 BLEU와 같은 일반적인 유사도 메트릭스 대신 "Calendar Scheduling Failure" 또는 "Failure to Escalate To Human"과 같이 애플리케이션에 특화된(application-specific) 메트릭스를 설계합니다. 가장 중요한 교훈은 "데이터를 보라(look at the data)"는 것입니다.

2. Unverified Judges (검증되지 않은 평가자):
   • 문제점: LLM을 평가자로 사용하여 AI 시스템의 작동 여부를 판단할 때, 평가자의 신뢰성을 검증하지 않습니다. 단순히 LLM에게 1-5점 척도로 평가를 요청하는 경우가 많습니다.
   • 데이터 과학자의 접근: 데이터 과학자는 LLM 평가자를 분류기(classifier)처럼 취급합니다. 인간 라벨(human labels)을 확보하고, 데이터를 훈련(train), 개발(dev), 테스트(test) 세트로 분할하여 분류기의 신뢰성을 측정합니다. 훈련 세트에서 Few-shot 예제를 선별하고, 개발 세트를 사용하여 평가자 프롬프트(judge's prompt)를 최적화합니다(hill-climb). 과적합(overfit) 방지를 위해 별도의 테스트 세트를 유지합니다. 결과를 보고할 때 단순히 정확도(accuracy) 대신 정밀도(precision)와 재현율(recall)을 사용하여 시스템의 실제 성능, 특히 드문 실패 모드(failure mode)를 정확히 반영합니다.

3. Bad Experimental Design (부실한 실험 설계):
   • 문제점 1 (테스트 세트 구성): 단순히 LLM에 "테스트 쿼리 50개를 만들어라"고 요청하여 대표성이 없는 합성 데이터(synthetic data)를 생성합니다.
   • 데이터 과학자의 접근 1: 실제 프로덕션 데이터(production data)를 먼저 분석하고, 가설을 통해 어떤 차원(dimensions)이 중요한지 파악한 다음, 해당 차원을 따라 합성 예제를 생성합니다. 실제 로그나 트레이스에 기반을 두고, 극단적인 경우(edge cases)를 주입하여 테스트 세트를 실제 데이터에 뿌리내리게 합니다.
   • 문제점 2 (메트릭스 설계): 전체 평가 기준(rubrics)을 단일 LLM 호출에 묶고, 1-5점 척도(Likert scales)를 사용합니다.
   • 데이터 과학자의 접근 2: 복잡성을 줄이고, 각 메트릭스를 실행 가능하게(actionable) 만들며, 비즈니스 결과(business outcome)와 연결합니다. 주관적인 척도 대신 명확한 범위의 이진 통과/실패(binary pass/fail) 기준을 사용합니다.

4. Bad Data and Labels (나쁜 데이터 및 라벨):
   • 문제점: AI 엔지니어들이 데이터, 라벨, 또는 그 어떤 것도 쉽게 신뢰하지 않는 데이터 과학자의 회의적인(skeptical) 태도를 갖추지 못합니다. 라벨링 작업의 중요성을 간과하고 외부 위임하거나 개발 팀에 떠넘깁니다.
   • 데이터 과학자의 접근: 데이터 과학자는 도메인 전문가(domain experts)가 직접 데이터를 라벨링하도록 주장하고, 라벨에 대해 회의적인 태도를 유지하며, 데이터를 직접 들여다봅니다. 라벨링은 단순히 품질을 넘어, 사용자가 LLM의 출력을 보면서 자신이 무엇을 원하는지(criteria drift) 명확히 하는 과정이기 때문에 중요합니다. 데이터 과학자는 도메인 전문가와 제품 관리자가 요약 점수 대신 원시 데이터(raw data)를 직접 검토하도록 주도합니다.

5. Automating Too Much (과도한 자동화):
   • 문제점: 위에서 언급된 모든 작업(데이터 보기, 오류 분석, 라벨링 등)은 본질적으로 인간의 작업임에도 불구하고, LLM을 이용해 과도하게 자동화하려는 유혹에 빠집니다.
   • 데이터 과학자의 접근: LLM은 파이프라인 구성이나 상용구 코드(boilerplate code) 생성에는 도움이 될 수 있지만, 인간 대신 데이터를 '보고' 무엇을 원하는지 파악할 수는 없습니다. 이는 사용자가 출력을 직접 보기 전까지는 원하는 것이 무엇인지 정확히 알 수 없기 때문입니다.

결론적으로, 저자는 위에서 언급된 모든 함정이 "데이터 과학 기본 원칙의 부재"에서 비롯된다고 강조합니다. 트레이스 읽기(Reading traces)는 탐색적 데이터 분석(Exploratory Data Analysis), LLM 평가자 검증은 모델 평가(Model Evaluation), 대표성 있는 테스트 세트 구축은 실험 설계(Experimental Design), 도메인 전문가 라벨링은 데이터 수집(Data Collection), 제품 모니터링은 프로덕션 ML(Production ML)에 해당합니다. 즉, 이름은 바뀌었지만 핵심 작업은 변하지 않았으며, Python과 같은 데이터 분석 도구는 여전히 이러한 작업을 수행하는 데 최적의 도구라고 주장합니다. 논문은 AI 시대에 데이터 과학의 역할이 축소되는 것이 아니라, AI 시스템의 신뢰성과 효율성을 확보하는 데 필수적인 '하네스 엔지니어링'의 핵심 요소로서 그 중요성이 더욱 부각될 것이라는 메시지를 전달합니다.