LLM 평가로 더 나은 실험하기 — 포크가 아닌 퍼널 | Spotify Engineering (새 탭에서 열림)

LLM 평가(evals)는 실험을 대체하는 도구가 아니라, 실험 전에 유망한 후보를 걸러내고 실험 후 판단 기준을 보정하는 퍼널의 일부다. Evals는 출력의 품질과 의도 부합 여부를 검증하지만, 실제 사용자의 행동과 사업 성과까지 검증하지는 못한다. 따라서 오프라인 평가와 온라인 A/B 테스트를 반복적으로 연결해야 실험 성공률과 평가 모델의 신뢰도를 함께 높일 수 있다.

Evals와 실험의 역할 차이

• **Evals는 검증(verification)**을 담당한다.
  • 출력이 관련성, 일관성, 어조, 의도 부합성 등 정해진 품질 기준을 만족하는지 평가한다.
  • 대규모 데이터에서 사람의 수작업 평가보다 빠르고 저렴하게 후보를 비교할 수 있다.
• **실험은 검증(validation)**을 담당한다.
  • 실제 사용자가 변경된 결과에 어떻게 반응하는지 확인한다.
  • 개선된 출력이 참여도, 유지율, 매출 등 실제 사업 성과로 이어지는지 측정한다.
• 따라서 관계는 “eval 또는 실험”이라는 분기가 아니라, eval로 후보를 좁힌 뒤 실험으로 사업 효과를 확인하는 퍼널이어야 한다.
• Spotify의 사례에서도 A/B 테스트 중 긍정적인 결과로 출시되는 비율은 약 12%지만, 약 64%는 회귀를 발견하거나 가설을 수정하는 등 유효한 학습을 제공한다.

Evals가 제공하지만 제공하지 못하는 것

• LLM judge는 다음과 같은 품질 문제를 대규모로 탐지할 수 있다.
  • 사용자 의도와 맞지 않는 추천
  • 신뢰를 훼손하는 콘텐츠
  • 응답의 관련성, coherence, 어조 문제
• 평가 과정에서 팀이 예상하지 못한 문제 패턴을 발견할 수 있다.
  • 예를 들어 부적절한 추천이 특정 사용자군이나 상황에서 반복된다는 사실을 찾아낼 수 있다.
  • 발견된 패턴은 제품 개선 가설이 된다.
• 같은 judge를 수정 후에도 사용하면 문제가 실제로 줄었는지 확인할 수 있다.
  • 문제가 되는 평가 항목의 발생 빈도가 감소하면 구현 품질이 개선된 것으로 볼 수 있다.
• 그러나 eval만으로는 다음을 알 수 없다.
  • 사용자의 장기 참여도가 높아졌는지
  • 이탈이나 churn이 줄었는지
  • 시스템 전체에서 예상치 못한 부작용이 발생했는지
• Spotify에서는 출시된 실험의 약 42%가 세션 길이, 충돌률, 유지율 등 최적화 대상이 아니었던 보조 지표의 회귀 때문에 되돌려졌다. 이런 문제는 오프라인 eval에서 포착되지 않을 수 있으므로 온라인 실험과 가드레일 지표가 필요하다.

두 단계의 보정과 평가 드리프트

• Evals는 실제 성과를 직접 측정하는 것이 아니라, 성과를 대신하는 프록시 점수다.
• 기존의 정량 지표(랭킹 점수, precision, recall) 위에 LLM judge라는 또 하나의 보정 계층이 추가된다.
• 두 계층 모두 실제 온라인 결과와 비교해 보정해야 한다.
  • judge가 더 높은 점수를 준 변형이 실제로 더 나은 사용자 경험을 제공하는가?
  • judge가 실질적 가치가 아닌 표면적 문체나 특정 패턴을 보상하고 있지는 않은가?
• 평가 기준은 시간이 지나면서 드리프트할 수 있다.
  • 모델, 사용자 행동, 콘텐츠 유형, 제품 목표가 바뀌면 기존 judge의 점수와 실제 성과의 관계가 약해질 수 있다.
• Qodo의 코딩 eval에서는 Anthropic의 Opus 4.5가 개선되지 않은 것처럼 보였지만, 실제로는 긴 작업에서 성능이 크게 향상된 사례가 있었다.
  • 반대로 eval 점수는 좋아졌지만 실제 사용자 성과가 개선되지 않는 경우도 가능하다.
• 따라서 오프라인 점수와 온라인 결과를 지속적으로 비교해야 eval이 단순한 의견이 아니라 신뢰할 수 있는 증거가 된다.

실험 전후를 연결하는 피드백 루프

• 실험 전
  • 여러 후보를 LLM eval로 평가한다.
  • 품질 기준을 충족하지 못하는 후보를 제거한다.
  • 남은 후보에 실험 리소스를 집중해 실험의 적중률을 높인다.
• 실험 중
  • 주요 사업 지표뿐 아니라 최적화하지 않은 가드레일 지표도 관찰한다.
  • 세션 길이, 오류율, 충돌률, 유지율처럼 회귀 가능성이 있는 지표를 함께 확인한다.
• 실험 후
  • A/B 테스트에 사용된 실제 데이터에 eval을 다시 적용한다.
  • judge가 선호한 변형이 실제 사용자 성과도 개선했는지 비교한다.
  • eval 점수와 실험 결과 사이의 차이를 다음 평가 기준을 개선하는 신호로 활용한다.
• 결과가 어느 쪽이든 학습이 발생한다.
  • eval과 사용자 성과가 함께 개선되면 judge가 가치 있는 품질 요소를 측정하고 있다는 뜻이다.
  • eval만 개선되고 사용자 성과가 그대로라면 judge가 사업 성과와 무관한 요소를 측정하고 있다는 뜻이다.

상황에 따른 실험 강도

• 모든 변경에 동일한 수준의 증거를 요구할 필요는 없다.
• 빠른 반복 단계에서는 방향성을 파악하기 위한 간단한 테스트를 사용할 수 있다.
• 출시 결정이나 영향 범위가 큰 변경에는 충분한 표본, 장기 지표, 가드레일을 포함한 엄격한 실험이 필요하다.
• 시스템이 복잡할수록 실험을 생략해 발생하는 대규모 회귀 위험이 커진다.

실무적으로는 LLM eval을 후보 선별과 품질 진단에 사용하고, 최종 출시는 반드시 사용자 대상 실험과 가드레일 지표로 판단하는 방식이 권장된다. 실험 결과를 다시 eval 보정에 반영하면 시간이 지날수록 더 정확한 평가 체계를 구축할 수 있다.