LLM judge 점수가 호출마다 흔들려서 median으로 안정화한 경험: 5회 평가가 한 번 평가보다 나았던 이유

2026년 08월 11일

0 Views

LLM judge 점수가 호출마다 흔들려서 median으로 안정화한 경험: 5회 평가가 한 번 평가보다 나았던 이유

결론부터 말하면, LLM judge 평가가 매번 달라질 때는 같은 샘플을 3~5회 평가하고 median 값을 쓰는 방식이 가장 빨리 효과를 봤습니다. temperature를 0으로 낮춰도 모델 출력과 채점 이유가 완전히 고정되지는 않았고, 평균보다 median이 튀는 점수에 덜 흔들렸습니다.

지금 쓰는 평가 스크립트에 5회 반복 호출과 median_score 컬럼을 먼저 추가해보세요.

제가 만든 셋업은 Claude Code로 평가 스크립트를 고치고, OpenAI API와 Anthropic Claude 응답을 비교한 뒤, 결과를 CSV로 저장해 Notion에 붙여 보는 단순한 구조였습니다. 복잡한 플랫폼을 붙이기 전에도 이 정도만으로 “이번 프롬프트가 정말 나아졌나?”를 훨씬 덜 감으로 판단할 수 있었습니다.

바로 해볼 다음 단계
현재 쓰는 judge 프롬프트 10개 샘플에 대해 5회 반복 채점 후 median 컬럼을 하나 추가해보세요.

왜 LLM judge 점수는 같은 입력에서도 흔들릴까

LLM judge는 사람이 만든 정답표가 아니라, 또 다른 LLM이 품질을 해석해서 점수를 매깁니다. 그래서 기준 문장이 조금 모호하거나, 7점과 8점의 차이가 애매하면 호출마다 다른 판단을 할 수 있습니다.

특히 요약 품질, 답변 친절도, 코드 리뷰 유용성처럼 정성 평가가 섞인 항목은 더 흔들립니다. JSON으로 점수만 뽑게 해도 내부 판단 과정이 매번 동일하다고 보장되지는 않습니다.

제가 처음 막힌 지점

AI 코딩 에이전트용 프롬프트를 비교하면서, A 프롬프트가 8.2점이었다가 다음 실행에서는 7.4점으로 내려가는 일이 있었습니다. 문제는 실제 답변 품질이 크게 달라진 게 아니라 judge 쪽 판정이 흔들린다는 점이었습니다.

처음에는 temperature 0, 더 엄격한 rubric, JSON schema 강제 순서로 고쳤습니다. 어느 정도 나아졌지만, 작은 차이를 비교할 때는 여전히 불안했습니다. 그래서 각 결과를 5번 평가하고 가운데값을 채택했습니다.

median 방식으로 바꾼 실제 워크플로

구조는 단순합니다. 테스트할 답변을 만들고, 같은 답변을 judge 모델에 여러 번 넣습니다. 각 호출에서 1~10점 점수와 짧은 근거를 받고, 점수 배열의 median을 최종 점수로 저장합니다.

예를 들어 한 답변의 judge 점수가 8, 7, 8, 6, 8로 나왔다면 평균은 7.4지만 median은 8입니다. 6점 하나가 전체 판단을 끌어내리지 않기 때문에, 실제로는 더 납득 가능한 결과가 됐습니다.

간단한 구현 예시

Python 기준으로는 어렵지 않습니다. Claude Code나 Cursor에서 기존 평가 루프에 반복 호출만 추가하면 됩니다. 핵심은 모델 응답 원문, 점수, rubric 버전, 실행 시간을 같이 저장하는 것입니다.

scores = []
for i in range(5):
    result = call_judge_model(answer, rubric)
    scores.append(result['score'])
final_score = statistics.median(scores)

이때 judge 모델은 GPT-4o mini, GPT-4.1, Claude Sonnet 계열처럼 실제 비용과 정확도의 균형을 보고 고르면 됩니다. 저는 빠른 실험에는 저렴한 모델을 쓰고, 최종 회귀 테스트에는 더 강한 모델로 한 번 더 확인하는 식이 편했습니다.

평균, 단일 호출, median 비교

아래 표는 제가 평가 파이프라인을 고칠 때 판단 기준으로 삼은 비교입니다. 모든 팀에 정답은 아니지만, 프롬프트 변경 효과를 보는 용도라면 median이 꽤 실용적입니다.

방식	장점	한계	추천 상황
단일 호출	빠르고 비용이 낮음	운이 나쁜 한 번의 판정에 취약	초기 디버깅, 샘플 확인
평균값	전체 경향을 보기 쉬움	극단값이 결과를 흔듦	점수 분포까지 분석할 때
median	튀는 점수에 강하고 해석이 쉬움	호출 비용이 3~5배 증가	프롬프트 A/B 비교, 회귀 테스트
사람 검수	맥락 판단이 가장 좋음	느리고 반복 자동화가 어려움	최종 기준표 확정

이 방식을 추천하는 경우와 아닌 경우

굳이 필요 없는 경우

정답이 명확한 테스트에는 median judge보다 일반 유닛 테스트가 낫습니다. 예를 들어 API 응답 형식, 계산 결과, 권한 체크는 LLM에게 묻지 말고 코드로 검증하는 편이 더 안전합니다.

또 샘플이 3개뿐이면 반복 호출보다 데이터셋을 먼저 늘리는 게 좋습니다. judge 안정화는 샘플 수 부족을 해결해주지는 않습니다.

가장 흔한 실수: 점수만 저장하는 것

처음에는 최종 점수만 저장했는데, 나중에 왜 점수가 흔들렸는지 추적하기 어려웠습니다. 최소한 judge 모델명, 프롬프트 버전, rubric 문장, 원본 답변, 각 호출의 근거 문장은 남겨야 합니다.

LangSmith, Braintrust, promptfoo 같은 평가 도구를 쓰면 이런 기록을 더 체계적으로 관리할 수 있습니다. 다만 작은 프로젝트라면 Google Sheets나 Airtable에 저장하는 것부터 시작해도 충분합니다.

FAQ

몇 번 호출해야 하나요?

처음에는 3회로 시작하고, 점수가 자주 갈리면 5회까지 늘리는 게 현실적입니다. 7회 이상은 비용 대비 개선 폭이 작을 수 있어 중요한 평가에만 쓰는 편이 좋습니다.

median을 쓰면 평가가 객관적이 되나요?

완전히 객관적이 되지는 않습니다. 다만 한 번의 이상한 판정에 의사결정이 흔들리는 문제를 줄여줍니다. 최종 rubric은 여전히 사람이 검토해야 합니다.

temperature 0이면 반복 평가가 필요 없지 않나요?

항상 그렇지는 않습니다. API와 모델 버전, 내부 샘플링, 긴 문맥 처리 방식 때문에 같은 입력에서도 미세한 차이가 생길 수 있습니다. 중요한 비교라면 반복 측정이 안전합니다.

오늘 바로 적용할 액션

새 도구를 도입하기 전에, 지금 쓰는 평가 스크립트에 repeat_n=5와 median_score 컬럼만 추가해보세요. 그리고 기존 단일 점수와 median 점수가 크게 갈리는 샘플을 따로 모으면, judge 프롬프트의 애매한 문장을 빠르게 찾을 수 있습니다.

monstereae에서 AI 에이전트 평가 워크플로를 계속 다룰 예정이라면, 다음 글에서는 promptfoo나 Braintrust로 이 과정을 대시보드화하는 방법을 이어서 보면 좋겠습니다.

LLM judge 점수가 호출마다 흔들려서 median으로 안정화한 경험: 5회 평가가 한 번 평가보다 나았던 이유