왜 LLM Evals와 A/B 테스트는 함께 가야 하는가

많은 팀이 LLM 기반 기능을 개발하면서 '어떻게 평가할 것인가'라는 질문에 직면합니다. 단순히 'LLM Judge(판별기)'를 만들어 점수를 매기고 끝내는 경우가 많은데, 스포티파이의 최근 연구는 이것만으로는 부족하다고 말합니다.

스포티파이에 따르면, 모든 A/B 테스트 중 약 12%만이 출시 가능한 긍정적 결과로 이어집니다. 나머지 64%는 '회귀 발견', '아이디어 배제', '가설 정교화' 같은 유효한 학습을 제공합니다. 즉, 승률만으로 실험의 가치를 판단하면 안 된다는 뜻이죠.

여기에 LLM Evals라는 새로운 도구가 등장했습니다. 관련성, 일관성, 톤, 의도 정렬 등 기존에는 사람이 직접 평가해야 했던 차원을 자동으로, 더 빠르고 저렴하게 측정할 수 있게 해줍니다. 문제는 이 두 도구를 '둘 중 하나'로 보는 시각입니다. 스포티파이는 이것이 포크(fork)가 아니라 퍼널(funnel) 관계여야 한다고 강조합니다.

"LLM Evals는 실험 전에 사용해야지, 실험을 대체해서는 안 된다."

이 개념을 이해하는 것이 LLM 기반 시스템을 제대로 평가하는 첫걸음입니다.

검증(Verification)과 타당화(Validation)의 차이

스포티파이 연구자 Schultzberg와 Ottens는 두 개념을 명확히 구분합니다:

  • Evals = 검증(Verification): 출력물이 품질 기준에 부합하는가?
  • 실험 = 타당화(Validation): 실제 사용자가 예측대로 반응하는가?

Evals는 실험 대역폭을 소모하기 전에 가능성 없는 후보를 걸러내어, 이후 실험의 **Hit Rate(성공률)**을 높여줍니다. 예를 들어, 신뢰를 해치는 콘텐츠를 탐지하는 LLM Judge를 만들었다고 해봅시다. 이 Judge는 팀이 미처 몰랐던 패턴을 발견하고, 그 패턴을 제품 수정으로 연결합니다. 수정이 배포된 후, 같은 Judge가 '위반 건수 감소'를 확인해주죠. 이게 Evals의 두 가지 역할입니다: 무엇을 개선할지 발견하고, 개선이 실제로 이루어졌는지 확인하는 것.

그러나 Evals는 다음 질문에 답할 수 없습니다:

"개선된 버전을 받은 사용자가 실제로 더 나은 경험을 했는가?" "신뢰 상실이 이탈로 이어지는 것을 막았는가?"

이 질문에는 반드시 실제 사용자를 대상으로 한 실험이 필요합니다. 바로 여기서 퍼널 구조가 의미를 갖습니다.

LLM evaluation funnel diagram showing offline evals filtering into online A/B experiments Programming Illustration

퍼널 구조: Evals -> 실험 -> 교정 피드백

스포티파이는 Evals와 실험을 연결하는 **두 개의 보정 레이어(Calibration Layer)**와 하나의 피드백 루프로 시스템을 설계합니다.

1. 첫 번째 보정: 전통적 정량 지표

정밀도, 재현율, 순위 점수 등 기존 메트릭을 LLM Judge가 대체하는 것이 아니라, 함께 사용합니다.

2. 두 번째 보정: LLM Judge 점수와 실제 사용자 결과 간의 매핑

Evals는 **프록시(Proxy)**입니다. 점수가 실제로 중요한 결과를 추적하는 한에서만 유효합니다. LLM Judge가 'A 변형이 더 좋다'고 말할 때, 실제로 사용자 경험이 더 좋은지 확인해야 합니다.

예를 들어, Anthropic이 Opus 4.5 모델을 출시했을 때 Qodo의 코딩 Evals는 개선을 보여주지 못했지만, 실제로는 긴 작업(long tasks)에서 큰 향상이 있었습니다. 반대 사례도 많습니다. Judge가 피상적인 패턴에 점수를 몰아주는 경우죠.

실전 코드 예제: 간단한 LLM Judge + A/B 데이터 교정 파이프라인

# LLM Judge 점수와 실제 실험 결과를 비교하여 교정 계수를 계산하는 예시
import numpy as np
from sklearn.metrics import mean_squared_error

# 예시 데이터: LLM Judge 점수 (0~1)와 실제 사용자 전환율 (0~1)
eval_scores = np.array([0.85, 0.72, 0.91, 0.63, 0.78])
actual_conversion = np.array([0.12, 0.09, 0.15, 0.07, 0.11])

# MSE로 교정 오차 계산
mse = mean_squared_error(actual_conversion, eval_scores)
print(f"교정 오차 (MSE): {mse:.4f}")

# 교정 계수: 간단한 선형 회귀로 Judge 점수 -> 실제 전환율 예측
from sklearn.linear_model import LinearRegression
model = LinearRegression()
model.fit(eval_scores.reshape(-1, 1), actual_conversion)
print(f"교정 계수 (기울기): {model.coef_[0]:.3f}")
print(f"교정 계수 (절편): {model.intercept_:.3f}")

# 교정된 Judge 점수
calibrated_scores = model.predict(eval_scores.reshape(-1, 1))
print(f"교정된 점수: {calibrated_scores}")

이런 교정 루프가 없다면, Evals는 '의견'일 뿐 '증거'가 아닙니다. 스포티파이는 이 루프를 지속적으로 돌려 Evals가 점점 더 정확한 검증 도구가 되도록 합니다.

가드레일 메트릭(Guardrail Metrics)의 중요성

스포티파이 팀은 출시된 실험의 약 42%를 롤백합니다. 세션 길이 감소, 충돌률 상승, 리텐션 하락 같은 2차 메트릭에서 회귀를 발견했기 때문입니다. Evals나 오프라인 평가로는 이런 문제를 전혀 잡아내지 못합니다.

"가드레일의 핵심은 최적화 대상은 아니지만 신경 쓰는 차원을 관찰하는 것"

Evals는 한 차원의 구현 품질을 측정합니다. 실험은 프로덕션 시스템과 최종 사용자에 미치는 영향을 정량화합니다. 이 둘은 함께 가야 합니다.

Developer calibrating LLM judge scores against real user outcome metrics on a dashboard System Abstract Visual

한국 개발 생태계에서의 적용 맥락

국내에서는 특히 빠른 출시 압박 속에서 A/B 테스트를 '비용'으로 보는 경향이 있습니다. 하지만 스포티파이의 데이터가 보여주듯, 실험 없이 출시했다가 주요 비즈니스 메트릭에서 큰 회귀를 발견하지 못하면 그 비용은 훨씬 큽니다.

  • SI/플랫폼 기업: LLM 기반 추천, 검색, 챗봇 기능을 도입할 때, 오프라인 Evals만 믿고 출시했다가 사용자 이탈을 경험할 수 있습니다. 반드시 소규모 A/B 테스트로 검증하세요.
  • 스타트업: 리소스가 부족하더라도 '빠른 방향성 테스트'용 실험과 '출시 결정'용 실험을 분리하는 습관이 필요합니다. Evals로 방향성을 잡고, 실험으로 확신을 얻는 구조를 만드세요.

이 접근법의 한계 또는 주의사항

  1. Evals는 장기적인 사용자 행동을 포착하기 어렵습니다. 구조적으로 긴 작업, 장기적 행동 변화는 Evals로 측정하기 까다롭습니다.
  2. LLM Judge 자체도 편향될 수 있습니다. Judge가 특정 패턴(예: 긴 답변, 특정 키워드)에 점수를 몰아주는 현상을 지속적으로 모니터링해야 합니다.
  3. 교정 루프를 운영하는 데도 비용이 듭니다. 온라인-오프라인 신호 교정을 자동화하지 않으면 오히려 관리 부담이 늘 수 있습니다.

함께 보면 좋은 글

Spotify engineering team analyzing experiment results with guardrail metrics and eval feedback loop Algorithm Concept Visual

결론: 루프를 닫아라

스포티파이가 제안하는 최종 워크플로는 다음과 같습니다:

  1. Evals를 초기에, 자주 실행하여 최상의 처리를 찾는다.
  2. 실험으로 실제 사용자와 시스템이 예측대로 반응하는지 검증하고, 최적화하지 않은 메트릭도 모니터링한다.
  3. A/B 테스트 데이터 자체에 LLM Evals를 다시 실행한다. Judge가 선호한 버전이 실제로 사용자에게 더 나은 성과를 냈는지 확인한다.
  4. Eval 점수와 실험 결과 간의 차이가 크다면, 그 자체가 진단의 금광이다. 각 사이클이 다음 교정을 더 똑똑하게 만든다.

"성공은 기본을 잘하고, 그것을 규모에 맞게 실행하는 데서 온다. 시스템이 사용하기 충분히 단순하고, 신뢰할 수 있을 만큼 엄격할 때 가치는 배가된다."

LLM Evals는 실험 문화를 상류로 확장합니다. 실험 전에 최상의 처리를 찾고, 실험 후에 Judge를 교정하세요. 이 퍼널이 제대로 작동하면, 12%의 성공률도 충분히 의미 있는 숫자가 됩니다.

다음 단계 학습 방향

  • 근거자료: Spotify Engineering Blog 원문
  • 직접 LLM Judge를 만들어보고, 간단한 A/B 테스트 데이터와 교정 파이프라인을 구축해보세요.
  • 가드레일 메트릭 설계에 대해 더 공부하고, 자신의 서비스에 맞는 2차 메트릭을 정의해보는 것을 추천합니다.
본 콘텐츠는 신뢰할 수 있는 출처를 바탕으로 AI 도구를 활용하여 초안이 작성되었으며, 편집자의 검토를 거쳐 발행되었습니다. 전문가의 조언을 대체하지 않습니다.