LLM 평가 시대의 새로운 질문

LLM 기반 기능이 빠르게 늘면서, '이 모델이 정말 잘 동작하는가'를 판단하는 방법도 함께 진화하고 있습니다. 과거에는 사람이 직접 평가하거나 간단한 정확도(Accuracy) 지표로 판단했다면, 이제는 LLM 자체를 평가자(Judge)로 활용하는 LLM Eval이 주목받고 있습니다.

하지만 여기서 중요한 질문이 하나 생깁니다. LLM Eval이 좋은 성적을 냈다면, 그대로 배포해도 될까?

스포티파이(Spotify)의 실험 데이터를 보면, A/B 테스트를 통해 실제 출시까지 이어진 긍정적 결과는 약 12%에 불과합니다. 나머지 64%는 유효한 학습(회귀 발견, 아이디어 배제, 가설 정교화)을 제공했지만, '출시'까지는 연결되지 않았습니다. 즉, 오프라인 평가와 온라인 결과 사이에는 항상 간극이 존재합니다.

이 글에서는 LLM Eval을 단순한 '대체 도구'가 아니라, A/B 테스트와 연결되는 평가 퍼널(Evaluation Funnel) 로 구성하는 방법을 소개합니다. 이 내용은 스포티파이 엔지니어링 블로그의 원문을 기반으로, 국내 개발자 실무 맥락에 맞게 재구성했습니다.

LLM eval funnel diagram showing offline verification leading to online validation Coding Session Visual

Eval이 하는 일 vs 실험이 하는 일

Schultzberg와 Ottens(2024)는 검증(Verification) 과 타당성 확인(Validation) 을 명확히 구분합니다.

  • Eval = 검증: 출력물이 품질 기준에 부합하는가?
  • 실험 = 타당성 확인: 실제 사용자가 예측한 대로 반응하는가?

예를 들어, 추천 시스템이 부적절한 콘텐츠를 사용자에게 전달하는 '신뢰 파괴' 패턴을 탐지하는 LLM Judge를 만들었다고 가정합시다. 이 Judge는 다음과 같은 두 가지 역할을 합니다.

  1. 탐색(Discovery): 팀이 미처 몰랐던 패턴을 표면화하여 제품 개선 포인트를 제공합니다.
  2. 검증(Verification): 개선 후 동일 Judge로 다시 평가하여 위반 건수가 줄었는지 확인합니다.

하지만 Judge는 다음 질문에는 답하지 못합니다.

"개선된 버전을 받은 사용자가 실제로 더 나은 경험을 했는가? 그로 인해 이탈률이 줄었는가?"

이 질문은 반드시 온라인 실험(A/B 테스트) 을 통해 확인해야 합니다. 스포티파이의 경우, 출시된 실험의 약 42%가 2차 지표(세션 길이 감소, 크래시율 증가, 리텐션 하락)의 회귀를 막기 위해 롤백됩니다. 이는 어떤 오프라인 Eval도 잡아내지 못한 문제입니다.

Developer analyzing A/B test results with LLM judge calibration feedback loop System Abstract Visual

두 개의 보정 레이어, 하나의 피드백 루프

LLM Eval은 본질적으로 대리 변수(Proxy) 입니다. 실제로 원하는 결과(사용자 만족도, 매출, 리텐션)를 점수로 대체한 것입니다. 이 대체가 유효하려면, 점수와 실제 결과 간의 관계가 지속적으로 보정(Calibration)되어야 합니다.

여기서 LLM Judge는 전통적인 정량적 지표(랭킹 점수, 정밀도, 재현율) 위에 두 번째 보정 레이어를 추가합니다. 두 레이어 모두 온라인 결과와의 정합성 검증이 필요합니다.

# 예시: LLM Judge 점수와 실제 사용자 행동 간의 상관관계 추적 (의사 코드)
import numpy as np

def calibrate_eval_judge(judge_scores, actual_outcomes):
    """
    judge_scores: LLM Judge가 평가한 점수 배열 (0~1)
    actual_outcomes: 실제 사용자 행동 지표 (예: 클릭률, 체류 시간)
    """
    correlation = np.corrcoef(judge_scores, actual_outcomes)[0, 1]
    print(f"Judge-실험 상관계수: {correlation:.3f}")
    
    if correlation < 0.3:
        print("⚠️ 경고: Judge 점수가 실제 사용자 행동을 제대로 반영하지 못합니다.")
        print("   Judge의 평가 기준을 재조정하거나, 다른 Judge 모델을 고려하세요.")
    else:
        print("✅ Judge 점수와 실제 행동 간 유의미한 상관관계가 확인되었습니다.")
    return correlation

예를 들어, Anthropic이 Opus 4.5 모델을 출시했을 때 Qodo의 코딩 Eval은 개선을 감지하지 못했지만, 더 긴 태스크에서는 모델이 실질적으로 향상되었습니다. 반대 방향의 오정보(Miscalibration)도 발생할 수 있습니다. 즉, Eval이 표면적 패턴에 과적합되어 실제로는 가치 없는 점수를 높게 주는 경우입니다.

이 문제를 해결하려면 오프라인-온라인 신호 보정 루프(Offline-Online Calibration Loop) 를 구축해야 합니다. Eval을 한 번 설정하고 끝내는 것이 아니라, 실험 결과를 피드백으로 받아 지속적으로 Judge를 재조정하는 것입니다.

Data scientist configuring automated LLM evaluation pipeline on terminal Algorithm Concept Visual

결론: 루프를 닫아라

LLM Eval과 A/B 테스트는 '둘 중 하나'를 선택하는 관계가 아닙니다. 다음과 같은 퍼널(Funnel) 구조로 연결해야 합니다.

  1. Eval로 좋은 후보를 먼저 선별하라. 실험 대역폭을 낭비하지 마라.
  2. 실험으로 실제 사용자 반응을 검증하라. Eval이 놓친 2차 지표 회귀를 잡아내라.
  3. 실험 데이터로 Eval을 재보정하라. Judge가 선호한 버전이 실제로 더 나은 성과를 냈는지 확인하고, 차이가 크다면 그 자체가 진단의 금광이다.

이 접근법은 특히 국내 SI/스타트업 환경에서 유용합니다. "일단 배포하고 보자"는 문화에서 벗어나, 체계적인 평가 퍼널을 구축하면 장기적으로 기술 부채와 예상치 못한 장애를 크게 줄일 수 있습니다.

다음 단계 학습 방향:

함께 보면 좋은 글:

본 콘텐츠는 신뢰할 수 있는 출처를 바탕으로 AI 도구를 활용하여 초안이 작성되었으며, 편집자의 검토를 거쳐 발행되었습니다. 전문가의 조언을 대체하지 않습니다.