한 팀이 LLM 기반의 고객 지원 상담 에이전트를 배포했습니다. 이들의 평가 대시보드는 유용성(helpfulness), 정확성(accuracy), 어조(tone), 완전성(completeness), 관련성(relevance), 안전성(safety), 간결성(conciseness), 유창성(fluency)의 8가지 차원에서 5점 만점에 4.2점이라는 준수한 점수를 보여주고 있었습니다. 리더십 팀은 만족했습니다. 그러나 2주 후, 고객 이탈률(churn)이 급증했습니다. 에이전트가 존재하지도 않는 환불 규정을 확신에 찬 어조로 지어내고 있었던 것입니다. 8가지 평가 차원 중 그 어느 것도 이 문제를 잡아내지 못했습니다.

이것이 바로 거의 모든 AI 팀이 빠지는 ’평가의 함정(evaluation trap)’입니다. 평가 체계가 없어서가 아니라, 잘못된 평가 체계가 존재하기 때문에 발생하는 문제입니다.

해결책은 메트릭을 무작정 늘리는 것이 아닙니다. 근본적으로 다른 방법론을 취하는 것입니다.

검증자의 법칙(The Verifier’s Rule)

실전으로 들어가기 전에 이론부터 살펴보겠습니다. 제이슨 웨이(Jason Wei)의 ’검증자의 법칙(verifier’s rule)’에 따르면, AI가 특정 작업을 해결하도록 훈련시키는 난이도는 해당 작업이 ’얼마나 쉽게 검증 가능한가’에 비례합니다. 해결할 수 있고 검증하기 쉬운 모든 작업은 결국 AI에 의해 해결될 것입니다.

어떤 작업을 최적화 가능(optimizable)하게 만드는 5가지 속성은 다음과 같습니다:

  1. 객관적 진실(Objective truth) — 무엇이 좋은 해결책인지 모두가 동의함
  2. 빠른 검증 속도(Fast to verify) — 주어진 해결책을 수 초 내에 검증할 수 있음
  3. 확장 가능한 검증(Scalable to verify) — 수많은 해결책을 동시에 검증할 수 있음
  4. 낮은 노이즈(Low noise) — 검증 결과가 해결책의 실제 품질과 밀접하게 상관됨
  5. 연속적인 보상(Continuous reward) — 품질에 따라 해결책들의 순위를 쉽게 매길 수 있음

평가기를 구축하는 엔지니어에게 이 법칙이 시사하는 바는 분명합니다. 사전에 충분한 작업(front-loading work)을 수행함으로써 검증 가능성을 획기적으로 높일 수 있다는 점입니다. 경시대회 수학 문제는 정답표(answer key)가 있으면 검증이 매우 단순해집니다. 코딩 문제는 테스트 케이스가 있으면 검증 가능해집니다. LLM 출력은 신입 직원이 보더라도 일관되게 적용할 수 있을 만큼 구체적인 합격/불합격(pass/fail) 기준을 정의할 때 검증 가능해집니다.

이것이 바로 훌륭한 평가(eval)가 수행하는 역할입니다. 무엇이 ’좋은 것’인지 정의하는 노력을 초기에 집중 투자함으로써, 이후의 지속적인 검증 과정을 저렴하고 확장 가능하게 만드는 것입니다.

핵심 문제: 기준 표류(Criteria Drift)

평가 연구에서 매우 중요한 발견 중 하나는 UC 버클리의 샨카르(Shankar) 연구팀 등의 연구(UIST 2024)에서 나왔습니다:

“출력물을 채점하기 위해 사람들은 자신의 평가 기준을 외재화하고 정의해야 합니다. 그러나 출력물을 직접 채점하는 과정 자체가 바로 그 기준을 정의하는 데 도움을 줍니다. 우리는 이러한 현상을 ’기준 표류(criteria drift)’라고 부릅니다.”

이는 채점을 시작하기 전에 완벽한 루브릭(rubric, 평가 기준표)을 작성하는 것이 불가능함을 의미합니다. 실제 데이터를 보면서 기준 자체가 진화하기 때문입니다. LLM 출력물을 단 하나도 살펴보지 않은 채 평가 프레임워크를 정의하느라 몇 주씩 쏟아붓는 팀은 모래 위에 성을 쌓고 있는 것과 같습니다.

실무적 결론은 명확합니다. 사전에 완벽한 루브릭을 만들려는 시도를 멈추십시오. 먼저 채점을 시작하고, 데이터로부터 기준이 자연스럽게 도출되도록 하십시오.

비평 섀도잉 방법론(The Critique Shadowing Methodology)

사용자의 요구와 완벽히 일치하는 LLM 평가기(LLM Judge)를 구축하기 위해 실전에서 가장 철저히 검증된 방법론은 하멜 후세인(Hamel Husain)이 30개 이상의 AI 프로젝트를 진행하며 정립한 ’비평 섀도잉(Critique Shadowing)’입니다. 이 방법론은 6단계로 이루어집니다.

1단계: 핵심 도메인 전문가(Principal Domain Expert)를 찾아라

모든 조직에는 여러분의 AI 제품에서 가장 중요한 판단력을 가진 한두 명의 전문가가 존재합니다. 엔지니어링 리드도 아니고, 부사장(VP)도 아닙니다. 무엇이 진정으로 좋은 결과물인지를 실제로 알고 있는 사람입니다.

  • 정신 건강 상담 AI 어시스턴트라면 심리학자
  • 법률 문서 분석기라면 변호사
  • 고객 지원 챗봇이라면 고객 서비스 디렉터
  • GxP 규정 준수 툴이라면 품질 보증(QA) 매니저

이것이 중요한 이유는 도메인 전문가가 기준을 세우고, 암묵적인 기대치를 포착하며, 일관성을 보장하고, 평가에 대한 오너십을 갖기 때문입니다. 규모가 작은 조직이라면 창업자일 수도 있습니다. 만약 1인 개발자라면 본인이 도메인 전문가가 되어야 하겠지만, 자신의 전문성에 대해 솔직해야 합니다.

많은 엔지니어가 스스로 도메인 전문가 역할을 대신하려 합니다. 이는 재앙으로 가는 지름길입니다.

2단계: 유의미한 차원에 걸친 데이터셋 구축

사용 사례에서 중요한 의미를 갖는 다양한 차원(dimension)에 걸쳐 테스트 데이터를 구조화하십시오:

  • 기능(Features) — 구체적인 기능 영역 (주문 조회, 문서 검색, 환불 처리)
  • 시나리오(Scenarios) — AI가 처리해야 하는 상황 (검색 결과 없음, 모호한 요청, 시스템 오류, 유효하지 않은 데이터)
  • 페르소나(Personas) — 사용자 프로필 (신규 사용자, 전문가, 비원어민, 바쁜 직장인)

모든 차원의 조합을 포괄할 수 있을 만큼 충분한 데이터를 생성하십시오. 가능한 경우 실제 사용자 인터랙션 데이터를 활용하고, 부족한 부분은 합성 데이터(synthetic data)로 보완하십시오. 합성 데이터를 만들 때는 LLM으로 사용자 입력만을 생성하고, 이를 실제 AI 시스템에 통과시켜 실제 응답을 수집해야 합니다.

데이터는 얼마나 필요할까요? 200개 이상의 샘플로 시작하고, 50~100개의 실패 사례(fail cases)를 확보하는 것을 목표로 삼으십시오. 수백 개의 라벨이 달려 있어도 실패 사례가 고작 5개뿐인 데이터셋은 쓸모가 없습니다. 작고 성능이 낮은 모델을 사용하면 강력한 모델로 생성한 인위적인 결함보다 훨씬 더 가치 있는 ‘자연스러운(organic)’ 실패를 쉽게 얻을 수 있습니다.

3단계: 정성적 비평(Critique)을 곁들인 이진(Pass/Fail) 평가

이 단계에서 대부분의 팀이 실패합니다. 8개 차원에 걸쳐 1점부터 5점까지의 정교한 점수 체계를 만들고, 결국 아무도 실행에 옮기지 않는 숫자로 가득 찬 대시보드를 마주하게 됩니다.

도메인 전문가가 답해야 할 질문은 단 하나뿐입니다: “AI가 의도한 결과를 달성했는가?”

합격(Pass) 아니면 불합격(Fail)입니다. 다른 것은 필요 없습니다.

전문가는 이진 결정과 함께 자신의 판단 근거를 설명하는 상세한 비평(critique)을 작성합니다. 이러한 비평은 다음과 같은 역할을 합니다:

  • 이진 라벨만으로는 담을 수 없는 뉘앙스를 포착합니다.
  • 구체적이고 실행 가능한 개선 가이드를 제공합니다.
  • LLM 평가기를 위한 퓨샷 예제(few-shot examples)로 활용됩니다.
  • 신입 직원이 읽어도 이해할 수 있을 만큼 구체적이어야 합니다.

흔히 나오는 반론이 있습니다: “비즈니스 팀에서 이 8가지 차원이 중요하다고 했는데요.” 만약 누군가가 1~5점 척도로 8가지를 측정해야 한다고 말한다면, 그들은 자신이 무엇을 찾고 있는지 모르는 상태이며 단순한 추측을 하고 있는 것입니다. 도메인 전문가가 Pass/Fail과 비평을 통해 주도하도록 맡겨두면, 실제로 무엇이 중요한지 저절로 드러나게 됩니다.

수십 개의 제품 팀을 경험한 유진 얀(Eugene Yan)의 통찰에 따르면, 이해관계자들은 흔히 “나중에 임계값(threshold)을 조정하기 위해” 세분화된 점수를 요구하곤 합니다. 하지만 실제로 그렇게 임계값을 조정한 팀은 단 하나도 없었습니다. 결국 그들이 최종적으로 요구하는 것은 ’Pass/Fail 비율’입니다. 어차피 도달하게 될 종착점에서부터 시작하십시오.

4단계: 전문가 예제를 기반으로 LLM 평가기(LLM Judge) 구축

데이터를 직접 확인하기 전까지는 좋은 평가기 프롬프트를 작성할 수 없습니다. 이것이 바로 기준 표류(criteria drift)가 가져오는 운영상의 결과입니다.

전문가가 작성한 비평을 평가기 프롬프트의 퓨샷 예제로 활용하는 것부터 시작하십시오. 실무에서 사용하는 프롬프트 구조는 다음과 같습니다:

You are evaluating [application] responses.

Context: [what the application does, domain knowledge needed]

Criterion: [one precise criterion, including what to ignore]

Example (fail): [input] → [output] → Reasoning: [why it fails] → Verdict: fail
Example (pass): [input] → [output] → Reasoning: [why it passes] → Verdict: pass

Evaluate the reply below. Write your reasoning first, then output
exactly one of: pass, fail, unknown.

여기에는 5가지 핵심 요소가 포함되어 있습니다:

  1. 컨텍스트(Context) — 애플리케이션의 역할과 필요한 도메인 지식
  2. 단 하나의 명확한 기준(One precise criterion) — 무엇을 무시해야 하는지까지 명시
  3. 라벨링된 예제(Labeled examples) — 전문가의 추론 과정이 담긴 2~4개의 사례
  4. 추론 먼저, 판정은 마지막에(Reasoning first, verdict last) — 평가기의 정확도를 유의미하게 향상시킴
  5. 명시적인 예외 탈출구(An explicit way out) — 정보가 불충분할 때 선택할 수 있는 “unknown”

5단계: 수렴할 때까지 반복(Iterate Until Convergence)

도메인 전문가에게 LLM의 비평과 전문가 자신의 비평을 나란히 정리한 스프레드시트를 전달하십시오. 이를 바탕으로 프롬프트를 반복적으로 개선해 나갑니다. 시간이 지남에 따라 일치율(agreement rate)을 추적하십시오.

허니컴(Honeycomb)의 사례 연구에서는 LLM 평가기와 도메인 전문가 사이의 90% 이상 일치율을 달성하기까지 세 번의 반복 작업이 필요했습니다. 당시 도메인 전문가였던 필립 카터(Phillip Carter)는 다음과 같이 회고했습니다:

“LLM이 추론 과정을 단계별로 분해하는 것을 보면서, 제가 특정 엣지 케이스를 판단할 때 일관성을 유지하지 못하고 있었다는 사실을 깨달았습니다.”

평가기를 구축하는 과정 자체가 평가 기준을 표준화한 것입니다. 이것이 바로 숨겨진 가치입니다. 평가기 구축은 팀으로 하여금 데이터를 꼼꼼히 들여다보도록 강제하는 일종의 ’해킹(hack)’인 셈입니다.

6단계: 오류 분석(Error Analysis)

전문가와 일치된 평가기를 확보했다면, 이를 프로덕션 데이터에 적용하십시오. 정의한 차원(기능 × 시나리오 × 페르소나) 전반에 걸쳐 오류율을 계산합니다. 트레이스(trace)를 근본 원인(root cause)별로 분류하고 오류 분포를 구성합니다.

전형적인 근본 원인 분포는 다음과 같이 드러날 수 있습니다: 사용자 안내 부족 40%, 인증 문제 30%, 부실한 컨텍스트 처리 20%, 부적절한 오류 메시지 10%. 이제 어디에 집중해야 할지 명확해집니다.

오류 분석은 30개의 샘플로 시작하십시오. 새로운 실패 모드(failure mode)가 더 이상 나타나지 않을 때까지 계속 진행합니다. 첫 번째 검토를 마친 후에는 무작위 샘플링 대신 오류 자체에 집중하여, 동일한 패턴을 유발하는 사례를 추가로 찾아내십시오.

만능 평가기 안티패턴(The God Evaluator Anti-Pattern)

평가 설계에서 가장 흔하게 저지르는 실수는 이른바 ’만능 평가기(God Evaluator)’입니다. 하나의 프롬프트 안에서 정확성, 어조, 완전성, 관련성, 안전성, 간결성을 1~10점 척도로 한꺼번에 채점하는 단일 LLM 평가기를 뜻합니다.

이 방식은 결코 제대로 작동하지 않습니다. 산출된 종합 점수는 무엇을 고쳐야 하는지 알려주지 못합니다. 어떤 차원이 어긋났는지 격리할 수 없기 때문에 평가기를 캘리브레이션(calibration, 보정)하는 것도 불가능합니다. 게다가 이러한 점수는 실행 가능한 의사결정으로 이어지지 않습니다.

기준(criterion)마다 개별 평가기를 만들고, 단순한 휴리스틱(모든 차원을 통과해야만 최종 통과)을 통해 이를 결합하십시오. 이렇게 하면 세부적인 지표를 확보할 수 있어, 어떤 차원이 성능을 떨어뜨리고 있는지 정확히 파악할 수 있습니다. 어떤 차원은 가드레일(guardrail, 배포를 위해 반드시 통과해야 하는 필수 조건)이고, 어떤 차원은 북극성(north-star, 점진적 개선을 목표로 하는 지표)입니다. 이 둘을 동일하게 취급하면 양쪽 모두 흐려지게 됩니다.

가능한 결정론적(Deterministic) 평가를 우선하라

코드 평가기 (Code Evaluator) LLM 평가기 (LLM-as-Judge)
비용(Cost) 저렴함 (cheap) 비쌈 (expensive)
속도(Speed) 밀리초(ms) 단위 수 초에서 수 분
일관성(Consistency) 항상 동일한 판정 실행 간 변동 발생
범위(Scope) 구조, 상태, 값 비교 의미, 관련성, 어조

평가하려는 대상이 시스템 상태에 드러나거나(데이터베이스 행이 작성되었는지, 티켓이 종결되었는지, 환불이 처리되었는지) 기대 출력값과 직접 비교할 수 있다면, 코드를 사용하십시오. 빠르고, 저렴하며, 결정론적이고, 디버깅하기 쉽습니다.

LLM 평가기는 오직 자연어만이 평가할 수 있는 영역에 아껴두십시오. 응답에 공감 능력이 있는지, 요약이 미묘한 뉘앙스를 제대로 포착했는지, 비전문가에게 설명이 명확한지 등이 여기에 해당합니다.

앤트로픽(Anthropic)의 에이전트 평가 가이드에 나오는 핵심 원칙이 있습니다: 대화 기록(transcript)에 적힌 주장이 아니라, 환경(environment) 내의 실제 결과를 채점하십시오. 고객 지원 에이전트가 대화창에서 “고객님의 200달러 환불이 처리되었습니다. 모두 완료되었습니다!“라고 응답했더라도 데이터베이스에는 환불 내역이 전혀 없을 수 있습니다. 대화 기록 대신 환불 테이블을 확인하십시오.

에이전트 평가는 훨씬 더 어렵다

에이전트는 여러 턴에 걸쳐 작동하고, 시스템 상태를 변경하며, 중간 결과에 따라 동적으로 적응합니다. 실수는 연쇄적으로 전파됩니다. 창의적인 해결책이 정적 평가에서는 ’실패’로 판정되더라도 실제로는 훨씬 우수한 방식일 수도 있습니다.

앤트로픽의 Opus 4.5는 CORE-Bench에서 초기에 42%라는 점수를 기록했습니다. 그러나 채점 버그, 모호한 태스크 명세, 확률적 태스크를 수정한 후 점수는 95%로 껑충 뛰었습니다. 모델이 문제가 아니라 평가 체계 자체가 고장 나 있었던 것입니다. METR은 지시사항을 그대로 따른 모델에 오히려 페널티를 주는 태스크를 발견하기도 했습니다. 채점 기준이 명시된 기준을 충족하는 것이 아니라 초과 달성할 것을 요구했던 것입니다.

에이전트 평가를 위해서는 세 가지 유형의 채점기(grader)가 협력해야 합니다:

코드 기반 채점기(Code-based graders): 결정론적 검증을 담당합니다. 단위 테스트, 상태 검증, 도구 호출 검증 등이 포함됩니다. 빠르고 저렴하며 재현 가능합니다.

모델 기반 채점기(Model-based graders): 미묘한 뉘앙스 평가를 담당합니다. 루브릭 점수화, 자연어 어설션(natural language assertions), 쌍대 비교(pairwise comparison) 등이 있습니다. 유연하지만 보정(calibration)이 필요합니다.

인간 채점기(Human graders): 골드 스탠다드(gold-standard) 캘리브레이션을 담당합니다. 도메인 전문가(SME) 리뷰, 평가자 간 일치도(inter-annotator agreement) 측정이 포함됩니다. 비용이 많이 들지만 기준을 세우는 데 있어 대체 불가능합니다.

또한 비결정론(non-determinism)을 다룰 줄 알아야 합니다. 두 가지 메트릭이 도움이 됩니다:

  • pass@k — k번의 시도 중 최소 한 번 성공할 확률 (한 번의 성공이 중요한 도구 환경에 적합)
  • pass^k — k번의 시도가 모두 성공할 확률 (일관성이 필수적인 에이전트에 적합)

k=1일 때 두 지표는 동일합니다. 하지만 k=10에 도달하면 완전히 상반된 이야기를 들려줍니다. 제품 요구사항에 맞춰 적절한 메트릭을 선택하십시오.

위치 편향과 섭동 테스트(Position Bias and Perturbation)

LLM 평가기에는 반드시 테스트하고 보정해야 하는 체계적인 편향(systematic biases)이 존재합니다:

  • 위치 편향(Position bias) — 특정 위치에 제시된 출력을 선호하는 경향
  • 장황함 편향(Verbosity bias) — 길이가 긴 응답을 더 우수하다고 판단하는 경향
  • 자기 강화(Self-enhancement) — 자신이 생성한 출력을 더 높게 평가하는 경향
  • 숫자 편향(Number bias) — GPT-3.5는 숫자 7을 선호하고, GPT 계열 모델은 42를 선호하는 경향

완화 방안:

  • 순서를 맞바꿔가며 쌍대 평가(pairwise evaluation)를 2회 실행합니다.
  • 점수 척도 대신 이진(binary) 또는 범주형(categorical) 점수를 사용합니다.
  • 섭동 연구(perturbation studies)를 수행합니다. 위치를 바꾸거나, 점수 체계를 역전시켜 봅니다.
  • 섭동 테스트 후에도 평가기가 동일한 출력을 일관되게 선호한다면, 그 평가기는 유효할 가능성이 높습니다.

프롬프트 민감도는 극단적입니다. 사소한 포맷 변화만으로도 정확도가 최대 76%p까지 차이 날 수 있습니다. 삼중 따옴표(triple-quote)를 사용한 멀티라인 문자열 대신 명시적인 문자열 연결(string concatenation)을 사용하는 것이 안전합니다. 대소문자, 공백, 문자열 파싱 규칙을 세심하게 관리하십시오.

평가 스택(The Evaluation Stack)

어떤 단일 방법도 모든 문제를 잡아낼 수는 없습니다. 가장 효과적인 접근법은 한 계층을 빠져나간 결함을 다른 계층에서 잡아내는 ’스위스 치즈 모델(Swiss Cheese Model)’입니다:

자동화된 평가(Automated evals): 모든 커밋마다 실행됩니다. 빠른 반복과 회귀 테스트가 가능하며 사용자에게 영향을 주지 않습니다. 하지만 실제 사용자 이용 패턴을 놓칠 수 있습니다.

프로덕션 모니터링(Production monitoring): 실시간 지표를 추적합니다. 실제 동작에 대한 그라운드 트루스(ground truth)를 제공합니다. 그러나 사후 대응적(reactive)이어서 문제를 인지하기 전에 사용자에게 먼저 노출됩니다.

A/B 테스트(A/B testing): 대규모 환경에서 실제 사용자 성과를 측정합니다. 하지만 통계적 유의성을 확보하기까지 며칠에서 몇 주가 걸릴 정도로 느립니다.

사용자 피드백(User feedback): 예상치 못한 문제를 수면 위로 끌어올립니다. 그러나 데이터가 희소하고(sparse), 자발적 참여자에게 편향되며(self-selected), 원인을 설명해 주는 경우가 드뭅니다.

수동 대화 기록 검토(Manual transcript review): 실패 모드에 대한 엔지니어의 직관을 길러줍니다. 그러나 확장성(scalability)이 없습니다.

가장 뛰어난 팀들은 이 모든 것을 유기적으로 결합합니다. CI/CD를 위한 자동화 평가, 그라운드 트루스를 위한 프로덕션 모니터링, 그리고 보정(calibration)을 위한 정기적인 인간 검토를 함께 운용합니다.

역량 평가와 회귀 평가(Capability and Regression Evals)

두 가지 유형의 평가는 서로 다른 목적을 가집니다:

역량 평가(Capability evals): “이 에이전트가 무엇을 잘할 수 있는가?“를 묻습니다. 처음에는 낮은 통과율(pass rate)에서 시작하며, 이것이 바로 팀이 정복해야 할 산입니다. 에이전트가 개선될수록 통과율이 올라갑니다.

회귀 평가(Regression evals): “에이전트가 이전에 잘 처리하던 모든 태스크를 여전히 처리할 수 있는가?“를 묻습니다. 이 지표는 100%에 가까워야 합니다. 수치가 하락한다는 것은 어딘가 고장 났음을 의미합니다.

역량 평가가 높은 통과율에 도달하면, 회귀 평가 스위트로 ’졸업(graduate)’합니다. 한때 “이 작업을 조금이라도 할 수 있는가?“를 측정하던 태스크가 이제는 “여전히 안정적으로 수행할 수 있는가?“를 검증하는 잣대가 됩니다.

이때 평가 포화(eval saturation) 현상을 주의해야 합니다. 100%에 도달한 평가는 회귀를 추적할 수는 있지만 추가 개선을 위한 신호는 전혀 제공하지 못합니다. 올해 SWE-bench Verified는 30% 수준에서 시작했지만, 현재 프론티어 모델들은 80%를 넘어섰습니다. 평가가 포화될수록 가장 까다로운 극소수의 태스크만 남게 되며, 실제로는 큰 폭의 역량 개선이 이루어져도 점수 상으로는 미미한 증가로만 보이게 됩니다.

통계적 현실(The Statistical Reality)

샘플은 얼마나 필요할까요? 이는 팀이 요구하는 신뢰도 수준에 따라 달라집니다.

만약 제품의 결함률(defect rate)을 5% 미만으로 유지해야 하는 상황에서 200개의 샘플을 평가하여 3%의 결함률을 확인했다고 가정해 보겠습니다. 이 경우 95% 신뢰구간은 대략 3% ± 2.4%가 됩니다. 신뢰구간의 상한선인 5.4%가 요구 조건(5%)을 초과하므로, 규정을 확실하게 충족했다고 확신을 갖고 주장할 수 없습니다.

샘플 수를 두 배인 400개로 늘리면 신뢰구간은 3% ± 1.7%로 좁혀집니다. 이제 상한선은 4.7%로 떨어져 5% 미만 기준을 만족합니다. 표준오차(standard error)는 표본 크기의 제곱근에 반비례하여 감소합니다. 오차 범위를 절반으로 줄이려면 표본 크기를 4배로 늘려야 합니다.

진정한 가치(The Real Value)

어느 한 팀이 평가 하네스(evaluation harness)를 구축하는 데 4주를 투자했습니다. 기준을 정의하고, 어노테이션(annotation)을 수집하고, 평가기를 도메인 전문가와 일치시키고, 실험 파이프라인을 구축했습니다. 이해관계자들은 이것이 본업에 방해가 되는 일이 아닐까 우려했습니다.

그러나 그 후 2주 동안, 그 팀은 다양한 모델, 검색(retrieval) 설정, 프롬프트 템플릿에 걸쳐 수십 번의 실험을 수행했습니다. 그리고 몇 달 동안 수백 번의 실험을 추가로 진행했습니다. 매번 변경 사항이 생길 때마다 사람의 수작업 어노테이션에 의존하는 병목이 있었다면 이는 불가능했을 일입니다.

평가의 이점은 단순히 품질을 측정하는 것에 그치지 않습니다. 피드백 루프를 극적으로 단축하여 훨씬 더 빠르게 반복 개선할 수 있게 해줍니다.

하지만 현장에서 이를 가장 많이 경험한 실무자가 전하는 더 깊은 진실이 있습니다. 진정한 비즈니스 가치는 ’데이터를 직접 들여다보는 것’에서 나옵니다. LLM 평가기를 구축하는 과정은 엔지니어와 팀이 데이터를 꼼꼼히 들여다보도록 유도하는 일종의 ’해킹’입니다. 평가기는 그 과정에서 얻어지는 부산물일 뿐이며, 데이터를 깊이 이해하는 문해력(Data Literacy)이야말로 진정한 보상입니다.

연구 노트: [[Writing Good Evals - Comprehensive Report]]

관련 글