LLM-as-a-judge는 왜 정답지가 아니라 측정기일까

• 카테고리: ai_dev
• 예상 읽기 시간: 10분
• 오늘의 질문: 모델이 모델을 평가하게 만들면, 그 점수를 바로 품질 지표로 믿어도 될까?
• 핵심 출처:
  • Evaluation best practices - 게시일 미표기, 확인일 2026-07-23
  • Graders - 게시일 미표기, 확인일 2026-07-23
  • Define success criteria and build evaluations - 게시일 미표기, 확인일 2026-07-23
  • Configure a judge model - 게시일 미표기, 확인일 2026-07-23
  • Gen AI evaluation service overview - 게시일 미표기, 확인일 2026-07-23

1. 왜 지금 봐야 하나

LLM 기능을 제품에 붙이면 곧 이런 질문을 만나게 된다. “새 모델로 바꾸면 답변이 더 좋아졌는가?”, “프롬프트를 수정했는데 회귀가 생겼는가?”, “RAG 답변이 더 그럴듯해졌는데 실제로 근거를 잘 쓰는가?” 사람이 매번 읽고 판단하면 가장 정확할 수 있지만, 매 배포마다 수백 개 케이스를 사람이 볼 수는 없다. 그래서 많은 팀이 LLM-as-a-judge, 즉 다른 모델에게 출력물을 평가하게 하는 방식을 사용한다.

하지만 여기서 조심해야 한다. LLM judge는 정답지가 아니다. OpenAI의 평가 베스트 프랙티스는 생성형 AI가 비결정적이기 때문에 전통적인 테스트만으로는 부족하며, 점수는 사람 판단·작업별 기준·프로덕션 행동과 함께 해석해야 한다고 설명한다. Anthropic 문서도 “좋은 성능” 같은 막연한 목표가 아니라 구체적이고 측정 가능한 성공 기준을 먼저 정의하라고 한다. Google Cloud의 judge model 문서는 응답 순서 편향을 줄이기 위한 response flipping, judge의 무작위성을 줄이기 위한 multi-sampling, 사람 평가와의 보정 같은 장치를 다룬다.

즉 LLM judge의 핵심은 “모델이 알아서 품질을 판정한다”가 아니다. 핵심은 불안정한 사람의 감각을 반복 가능한 측정 프로토콜로 바꾸되, 그 측정기 자체도 편향·분산·교정 오차를 가진다는 사실을 운영 계약으로 인정하는 것이다.

2. 핵심 개념

LLM-as-a-judge를 이해할 때는 세 가지를 분리해야 한다.

첫째, 평가 대상이다. 평가 대상은 단순한 최종 답변일 수도 있고, RAG에서 사용한 근거 목록, 도구 호출 이름과 인자, 에이전트 trace, 코드 diff, 사용자의 실제 만족도 로그일 수도 있다. OpenAI Graders 문서는 sample.output_text뿐 아니라 sample.output_tools 같은 도구 호출 결과를 평가 입력으로 쓸 수 있음을 보여준다. 평가할 것이 답변인지, 근거인지, 도구 선택인지에 따라 좋은 judge 프롬프트가 완전히 달라진다.

둘째, 평가 기준이다. exact match, string check, text similarity, Python grader, score model grader, pairwise judge는 같은 문제가 아니다. 정답 라벨이 명확한 분류 작업이면 문자열 일치가 가장 튼튼할 수 있다. 코드 실행 결과나 JSON 스키마는 deterministic check가 먼저다. 반면 요약의 충실성, 고객 응대의 공감, 코드 변경의 범위 절제처럼 사람이 루브릭으로 판단하는 항목은 LLM judge가 유용하다. Anthropic 문서가 말하듯 대부분의 실제 제품은 정확도, 안전성, 지연 시간, 비용, 문맥 활용을 함께 보는 다차원 기준이 필요하다.

셋째, 측정기의 신뢰도다. LLM judge도 모델이다. 응답 순서에 영향을 받을 수 있고, 긴 답변을 더 좋아할 수 있고, 애매한 루브릭 앞에서 그럴듯한 이유를 만들어낼 수 있다. Google Cloud가 pairwise metric에서 response flipping을 제공하고, judge 응답의 무작위성을 줄이기 위해 multi-sampling을 제공하는 이유가 여기에 있다. 이 장치들은 “judge가 틀리지 않는다”는 뜻이 아니라, judge도 측정기이므로 노이즈를 줄이는 절차가 필요하다는 뜻이다.

3. 최신 이슈와 연결

최근 주요 플랫폼 문서들은 LLM 평가를 점점 더 제품 운영 기능으로 다루고 있다.

OpenAI 문서는 eval을 “한 번의 벤치마크”가 아니라 데이터셋, 테스트 기준, 실행, 비교, 지속 평가로 이어지는 개발 루프로 설명한다. 특히 LLM judge는 pairwise comparison, classification, 구체 기준에 대한 scoring처럼 모델이 판별하기 쉬운 형태로 설계하라고 안내한다. 동시에 OpenAI Evals/Graders 관련 플랫폼은 전환·폐기 일정이 있어, 특정 도구에 종속되기보다 평가 데이터와 루브릭을 이식 가능한 자산으로 관리해야 한다.

Anthropic 문서는 성공 기준을 먼저 정하라고 강조한다. “안전한 답변”이 아니라 “10,000회 중 독성 필터에 걸리는 출력이 0.1% 미만”처럼 측정 가능한 문장으로 바꾸라는 것이다. 이 관점은 LLM judge를 붙일 때 특히 중요하다. 루브릭이 흐리면 judge는 품질을 재는 것이 아니라 작성자의 애매함을 확대한다.

Google Cloud 문서는 judge model을 설정 가능한 구성요소로 본다. system instruction으로 평가자 역할을 명시하고, pairwise 비교에서는 response flipping으로 순서 편향을 줄이며, multi-sampling으로 judge의 분산을 낮춘다. Gen AI evaluation service overview는 adaptive rubric, static rubric, computation-based metric, custom function metric을 구분한다. 다시 말해 “LLM judge 하나로 모든 품질을 평가한다”가 아니라, 평가 방식도 작업 성격에 맞게 조합해야 한다.

4. 개발자 관점 해석

개발자가 흔히 하는 실패는 judge를 너무 늦게, 너무 크게, 너무 자유롭게 붙이는 것이다.

첫 번째 실패는 최종 답변만 평가하는 것이다. RAG 챗봇이 틀린 답을 냈을 때 원인은 검색 누락, 잘못된 chunk, rerank 실패, 모델의 근거 무시, citation 렌더링 버그 중 하나일 수 있다. 최종 답변에 0.6점을 주는 것만으로는 어디를 고칠지 모른다. 평가 입력에는 가능하면 검색된 문서 ID, 선택된 근거, 프롬프트 버전, 모델 이름, 도구 호출 trace가 함께 들어가야 한다.

두 번째 실패는 LLM judge를 deterministic check보다 앞에 두는 것이다. JSON 스키마가 깨졌는지, 필수 필드가 빠졌는지, 금지 도구를 호출했는지, SQL이 실제로 실행되는지는 코드로 먼저 검사해야 한다. LLM judge는 “정답을 계산할 수 없는 영역”에 쓰는 비싼 측정기다. 계산 가능한 것을 judge에게 맡기면 비용도 늘고 디버깅도 어려워진다.

세 번째 실패는 점수를 절대값처럼 읽는 것이다. 4.2점짜리 모델이 4.0점짜리 모델보다 무조건 좋다고 말하기 어렵다. judge 모델, 루브릭, 샘플링 횟수, 데이터셋 분포가 바뀌면 점수 기준선도 이동한다. 실무에서는 같은 데이터셋, 같은 루브릭, 같은 judge 설정에서 A/B 비교를 하고, 배포 기준은 “전체 평균 0.2 하락 금지”보다 “보안 항목 1점 이하 케이스 0개”처럼 치명도와 연결하는 편이 낫다.

네 번째 실패는 사람 라벨과 보정하지 않는 것이다. judge가 사람과 얼마나 동의하는지 모르면 자동 점수는 대시보드 장식이 된다. 최소한 핵심 케이스 20~50개는 사람이 직접 라벨링하고, judge가 같은 결론을 내는지 확인해야 한다. 불일치 케이스는 모델 문제가 아니라 루브릭이 모호하다는 신호일 때가 많다.

5. 내 프로젝트에 적용할 체크포인트

• 평가 목적을 한 문장으로 쓴다. 예: “고객 FAQ 답변이 제공된 문서 안에서만 답하고, 모르면 모른다고 말하는지 측정한다.”
• 성공 기준을 숫자로 바꾼다. 예: groundedness pass 95% 이상, 근거 없는 단정 1% 미만, p95 latency 2초 이하.
• deterministic check와 LLM judge를 분리한다. 스키마, 금지어, 도구 이름, 필수 citation ID는 코드로 먼저 본다.
• judge 입력에 최종 답변만 넣지 않는다. user input, retrieved context, reference answer, tool trace, 프롬프트 버전을 함께 저장한다.
• pairwise 비교를 할 때는 응답 순서를 바꿔서 다시 평가한다. 순서를 바꿨을 때 판정이 뒤집히면 tie 또는 human review로 보낸다.
• judge 결과에 score, label, reason, cannot_tell, judge_model, rubric_version, dataset_version을 함께 저장한다.
• 모델이나 루브릭을 바꾸면 기존 baseline과 점수 비교를 바로 하지 말고, 사람 라벨 샘플로 재보정한다.

6. 오늘 10분 액션

오늘은 큰 평가 시스템을 만들지 말고, “judge를 믿을 수 있는지 확인하는 최소 실험”만 해보자.

1. 내 LLM 기능에서 최근 실패한 입력 5개와 잘 된 입력 5개를 고른다.
2. 각 케이스에 사람이 직접 pass, fail, cannot_tell 라벨을 붙인다.
3. 루브릭을 5줄로 쓴다. 예: “답변은 제공된 context에 근거해야 한다. context에 없으면 모른다고 말해야 한다. citation ID가 없는 사실 주장은 fail이다.”
4. 같은 10개 케이스를 LLM judge에게 평가시킨다.
5. 사람 라벨과 judge 라벨이 다른 케이스만 모아 본다.

10분 안에 얻어야 할 결론은 “우리 judge 점수가 몇 점인가”가 아니다. 결론은 “루브릭이 어디서 애매해지는가”, “deterministic check로 빼야 할 항목은 무엇인가”, “judge가 cannot_tell을 말할 수 있게 입력이 충분한가”다.

7. 더 볼 자료

• Evaluation best practices: eval-driven development, task-specific eval, 사람 판단과 자동 평가의 조합을 볼 때 유용하다.
• Graders: string check, text similarity, score model grader, Python grader, multigrader의 차이를 확인할 수 있다.
• Define success criteria and build evaluations: 성공 기준을 구체적이고 측정 가능한 형태로 바꾸는 예시가 많다.
• Configure a judge model: response flipping, multi-sampling, tuned judge model처럼 judge 자체의 신뢰도를 다루는 장치를 확인할 수 있다.
• Gen AI evaluation service overview: adaptive rubric, static rubric, computation-based metric, agent evaluation의 구분을 정리하는 데 좋다.

중복 회피 메모

로컬 content/generated와 Supabase 최근 ai_dev 글을 확인했다. 최근 글은 MCP Sampling 권한 경계, 임베딩 차원과 pgvector 스키마, 멀티모달 컨텍스트 예산, LLM 서비스 티어, 프롬프트 인젝션 신뢰 경계, Programmatic Tool Calling, RAG citation/grounding, 에이전트 trace, token counting, 추측 디코딩, prefill/decode 지연을 다뤘다. 이번 글은 특정 RAG 근거 계약이나 에이전트 trace 반복이 아니라, LLM-as-a-judge를 정답지가 아닌 편향·분산·교정이 필요한 측정기로 보고 deterministic check, 루브릭, pairwise flipping, 사람 라벨 보정을 어떻게 조합할지에 집중한다.