LLM 평가 프레임워크: 골든셋, 회귀 테스트, LLM-as-a-judge, 사람 피드백 루프

왜 이 주제가 중요한가

LLM 기반 기능은 한 가지 곤란한 성질을 가진다. 같은 입력에도 출력이 매번 달라지고, "좋아졌다"가 숫자로 잘 잡히지 않는다. 프롬프트 한 줄을 고치거나 모델 버전을 올렸을 때, 그게 정말 개선인지 아니면 어떤 케이스를 조용히 망가뜨린 퇴행인지 눈으로는 알 수 없다.

그래서 LLM 제품의 신뢰성은 모델 자체보다 평가 체계(evaluation) 에서 갈린다. 평가가 없으면 모든 변경이 "느낌상 더 나아진 것 같다"로 머물고, 평가가 있으면 변경을 측정 가능한 의사결정으로 바꿀 수 있다.

이 문서는 운영 무용담이 아니라 평가를 어떻게 설계하는가의 관점에서 네 가지 축을 한 흐름으로 엮는다.

• 골든셋(golden set) — 무엇을 정답으로 둘 것인가
• 회귀 테스트(regression test) — 변경이 기존 품질을 깨지 않았는지 어떻게 자동으로 잡는가
• LLM-as-a-judge — 정답이 고정되지 않는 출력을 모델로 어떻게 채점하는가
• 사람 피드백 루프(human feedback loop) — 사람을 어디에, 얼마의 비용으로 끼워 넣는가

여기서는 단일 호출·단일 응답 수준의 평가 기반을 다룬다.

전체 그림과 네 축의 관계

평가 프레임워크는 따로 노는 도구 묶음이 아니라 하나의 순환이다.

핵심은 데이터(golden set)와 채점(scorer)을 분리하고, 회귀 통과 조건을 자동화하며, 사람(human)을 전수가 아니라 선택 지점에만 넣는다는 점이다. 이 분리가 안 되면 평가가 매번 즉흥적인 수동 검수로 회귀한다.

1. 골든셋의 정답 정의

골든셋은 "이 입력에는 이런 출력이 나와야 한다"를 고정해 둔 평가용 데이터셋이다. 학습 데이터와 다르다. 학습은 모델을 바꾸지만, 골든셋은 모델을 바꾸지 않고 판정만 한다.

좋은 골든셋의 조건은 크기보다 분포다.

• 대표성 — 실제 트래픽의 주요 의도/카테고리 분포를 반영한다. 쉬운 케이스만 모으면 항상 100점이 나와 변별력이 없다.
• 난이도 혼합 — 평이한 케이스, 경계 케이스, 알려진 실패 케이스를 의도적으로 섞는다.
• 부정 케이스 포함 — "거절해야 하는 입력", "모른다고 답해야 하는 입력"을 반드시 넣는다. 정상 응답만 평가하면 환각·과잉응답을 못 잡는다.
• 라벨의 종류 명시 — 정답이 한 개로 고정되는지(분류·추출), 여러 정답이 허용되는지(요약·생성)에 따라 채점 방식이 달라진다.

각 케이스는 단순 입력/정답 쌍을 넘어, 무엇을 기준으로 통과로 볼지를 함께 적는다.

{
  "id": "refund-policy-001",
  "category": "policy_qa",
  "input": "결제 후 3일 지났는데 환불 되나요?",
  "reference": "기간 조건에 따라 다르며, 구체 조건은 정책 문서를 인용해 안내해야 함",
  "rubric": [
    "환불 가능 여부를 단정하지 않고 조건을 설명한다",
    "근거가 되는 정책 출처를 인용한다",
    "모르는 부분은 추측하지 않는다"
  ],
  "must_not": ["무조건 환불 가능하다고 단정", "정책에 없는 기간 임의 생성"],
  "difficulty": "boundary"
}

흔한 실수:

• 데이터 오염(leakage) — 골든셋 입력이 프롬프트 예시(few-shot)에 그대로 들어가면 점수가 부풀려진다. 평가셋과 프롬프트 예시는 분리한다.
• 버전 관리 부재 — 골든셋도 코드처럼 버전을 찍는다. 데이터가 조용히 바뀌면 어제와 오늘의 점수를 비교할 수 없다.
• 정답을 한 표현으로 못박기 — 생성 과제에서 정답 문자열 하나만 두면, 의미가 같아도 표현이 다르면 다 틀리게 나온다. 이 경우 rubric(채점 기준표) 기반 채점으로 넘어가야 한다.

2. 변경으로 발생한 품질 저하 자동 감지

회귀 테스트의 목적은 "프롬프트/모델/검색 파이프라인을 바꿨을 때, 기존에 잘 되던 케이스가 깨지지 않았는가"를 자동으로 확인하는 것이다. 일반 단위 테스트와 다른 점은 출력이 비결정적이라 정확 일치(exact match)만으로는 부족하다는 데 있다.

설계 포인트는 세 가지다.

• 메트릭 기준 점검 — 케이스별 pass/fail이 아니라 골든셋 전체의 집계 지표(정확도, rubric 통과율 등)에 임계값을 둔다. 단건 흔들림에 CI가 과민 반응하지 않게 한다.
• 카테고리별 분해 — 전체 점수만 보면 "환불 카테고리가 무너졌는데 다른 카테고리가 올라가서 총점은 유지"되는 퇴행을 놓친다. 카테고리별로 따로 본다.
• 비결정성 흡수 — temperature가 0이 아니면 같은 입력도 점수가 흔들린다. 케이스를 여러 번 돌려 평균을 쓰거나, 평가 시점에는 temperature를 낮춰 분산을 줄인다.

CI에 붙일 때는 "이전 버전 대비 임계 이상 하락하면 차단"이 기본형이다.

# 예: PR마다 평가 실행 후 임계값 통과 조건 확인
eval-check:
  run: python run_eval.py --golden golden_v3.json --out report.json
  rules:
    - metric: overall_pass_rate
      min: 0.85                 # 절대 하한
    - metric: overall_pass_rate
      max_drop_vs_main: 0.03    # main 대비 3%p 이상 하락 시 실패
    - metric: policy_qa_pass_rate
      max_drop_vs_main: 0.0     # 핵심 카테고리는 하락 불허

스냅샷 비교(이전 출력과 텍스트 diff)도 보조로 쓸 수 있지만, 생성 과제에서는 표현만 바뀌어도 diff가 터지므로 메트릭 기준 점검을 주로 두고 스냅샷은 참고용으로 둔다.

3. 정답이 고정되지 않는 출력을 채점하는 LLM-as-a-judge

요약·설명·대화처럼 정답이 한 개로 안 떨어지는 과제는, 사람이 매번 채점하면 느리고 비싸다. 그래서 모델이 모델의 출력을 채점하는 LLM-as-a-judge를 쓴다. 다만 judge도 LLM이라 같은 약점을 공유한다는 점을 전제로 설계해야 한다.

채점 방식은 크게 둘이다.

• Pointwise — 출력 하나에 rubric 기준으로 점수/통과 여부를 매긴다. 기준이 명확할 때 안정적이다.
• Pairwise — 두 출력 중 어느 쪽이 더 나은지 고른다. 절대 점수보다 상대 비교가 사람과 더 잘 맞는 경우가 많다. A/B 비교나 모델 교체 판단에 적합하다.

judge가 가진 알려진 편향:

• Position bias — pairwise에서 먼저 제시된 답을 선호한다. 순서를 바꿔 두 번 물어 일관성을 확인한다.
• Verbosity bias — 길고 장황한 답을 더 좋게 본다. rubric에 "간결성"을 명시하거나 길이를 통제한다.
• Self-preference — 같은 계열 모델이 만든 답을 선호하는 경향이 있다. 가능하면 채점 모델과 생성 모델 계열을 분리한다.

가장 중요한 원칙은 judge 자체를 검증해야 한다는 것이다. judge를 믿기 전에, 사람이 라벨링한 소규모 셋에서 judge 판정과 사람 판정의 일치도(agreement)를 측정한다. 일치도가 낮으면 점수가 아니라 rubric을 고친다.

judge 신뢰성 점검 절차
1. 사람이 라벨링한 케이스 50~100건 준비
2. 동일 케이스를 judge로 채점
3. 사람 vs judge 일치율 / 상관 측정
4. 불일치 케이스 원인 분석 → rubric 문장 구체화
5. 목표 일치율 도달 후에야 judge를 대규모로 사용

rubric은 추상어("좋은 답인가")를 피하고, 통과 조건을 검증 가능한 문장으로 쪼갠다. 앞의 골든셋 예시에 넣은 rubric 배열이 그대로 judge 입력이 된다. 골든셋과 judge가 같은 기준을 공유하게 설계하는 것이 핵심이다.

4. 사람 피드백을 넣는 위치

사람 검수는 가장 정확하지만 가장 비싸다. 그래서 설계의 핵심은 "사람을 전수 검수에 쓰지 않고, 자동 평가가 불확실한 지점에만 배치"하는 것이다.

사람을 끼우면 좋은 지점:

• judge가 낮은 신뢰도로 판정한 구간 — 통과/실패 경계 점수, judge가 순서에 따라 답이 바뀐 케이스.
• 새 실패 유형 발굴 — 자동 평가가 통과시켰지만 실제로는 이상한 출력. 여기서 나온 케이스를 골든셋에 환류한다.
• rubric 보정 — 사람과 judge가 자주 엇갈리는 카테고리의 기준을 다시 쓴다.

피드백을 받는 방식도 비용 차이가 크다.

• 명시적 피드백 — 사람이 직접 점수/라벨을 단다. 정확하지만 느리다.
• 암묵적 피드백 — 사용자의 재질문, 복사, 이탈 같은 행동 신호. 싸지만 노이즈가 많고 해석이 필요하다.

가장 중요한 건 루프가 닫혀야 한다는 것이다. 사람이 찾은 실패가 골든셋의 새 케이스로 들어가고, 그 케이스가 다음 회귀 테스트에서 다시 검사되어야 같은 실패가 재발하지 않는다. 피드백을 모으기만 하고 골든셋에 환류하지 않으면, 평가는 점점 현실과 멀어진다.

나쁜 설계와 개선된 설계

나쁜 설계:

• 출시 직전 팀원이 손으로 20개쯤 돌려 보고 "괜찮네" 하고 배포한다.
• 정답을 문자열 하나로 고정해 의미가 같아도 틀렸다고 나온다.
• judge 점수를 검증 없이 그대로 믿는다.
• 프롬프트 예시에 평가 케이스가 섞여 점수가 부풀려진다.

개선된 설계:

• 카테고리·난이도가 분포된 버전 관리되는 골든셋을 둔다.
• 생성 과제는 rubric 기반 judge로 채점하고, judge는 사람 라벨과의 일치도로 먼저 검증한다.
• 변경마다 CI에서 카테고리별 회귀 점검을 통과해야 머지된다.
• 사람 검수에서 나온 실패를 골든셋에 환류해 루프를 닫는다.

작은 실습 환경

거창한 플랫폼 없이도 로컬에서 평가 골격을 만들 수 있다. JSON 골든셋, 러너와 간단한 채점으로 시작한 뒤 judge를 붙이는 순서가 좋다.

# 1. 골든셋과 러너만으로 시작
mkdir llm-eval && cd llm-eval
python -m venv .venv && source .venv/bin/activate
pip install pytest
# golden.json 작성 후
pytest -q test_eval.py

가장 단순한 형태의 평가 러너는 다음과 같다. 실제 모델 호출부는 call_model로 추상화해 두고, 채점은 rubric 통과 비율을 집계한다.

import json
 
def call_model(prompt: str) -> str:
    # 실제로는 LLM API 호출. 테스트에서는 stub로 대체.
    ...
 
def judge(output: str, rubric: list[str]) -> float:
    # 실제로는 judge 모델 호출. 여기서는 rubric 통과 개수 비율을 반환한다고 가정.
    ...
 
def run_eval(golden_path: str) -> dict:
    cases = json.load(open(golden_path, encoding="utf-8"))
    by_category: dict[str, list[float]] = {}
    for c in cases:
        out = call_model(c["input"])
        score = judge(out, c["rubric"])
        by_category.setdefault(c["category"], []).append(score)
    return {
        cat: sum(scores) / len(scores)
        for cat, scores in by_category.items()
    }
 
if __name__ == "__main__":
    report = run_eval("golden.json")
    for cat, avg in report.items():
        print(f"{cat}: {avg:.2f}")

출력은 카테고리별 평균으로 떨어진다.

policy_qa: 0.88
refund: 0.79
small_talk: 0.95

이 숫자를 이전 버전과 비교하는 한 줄을 CI에 추가하면, 그 순간부터 "느낌"이 아니라 "지표"로 변경을 판단하게 된다.

면접 답변 프레임

평가 설계 질문은 화려한 운영 규모가 아니라 사고의 분리를 본다. 다음 골격으로 답하면 운영 경험을 과장하지 않고도 설계 감각을 보여줄 수 있다.

• "LLM 기능은 비결정적이라 회귀를 눈으로 못 잡습니다. 그래서 먼저 분포가 잡힌 골든셋을 만들고, 변경마다 그 셋으로 회귀를 봅니다."
• "정답이 고정되는 과제는 정확 매칭, 생성 과제는 rubric 기반 judge로 나눠 채점합니다. judge는 그대로 믿지 않고 사람 라벨과의 일치도로 먼저 검증합니다."
• "사람은 전수가 아니라 judge가 불확실한 구간에만 넣고, 거기서 나온 실패를 골든셋에 환류해 루프를 닫습니다."
• "에이전트처럼 단계가 여러 개면 결과만이 아니라 궤적과 위험 행동도 따로 평가해야 합니다." (여기서 위험 점검 주제로 자연스럽게 확장)

면접에서 함정은 "정확도 몇 %를 봤냐"가 아니라 "그 정확도를 어떻게 신뢰하느냐"를 되물을 때다. 이때 judge 검증과 데이터 오염 방지를 언급하면 한 단계 위의 답이 된다.

체크리스트

• 골든셋이 실제 트래픽 분포를 반영하고, 부정 케이스(거절·모름)를 포함하는가
• 골든셋이 버전 관리되고, 프롬프트 예시와 분리되어 데이터 오염이 없는가
• 정답 고정 과제와 생성 과제의 채점 방식을 구분했는가
• 회귀 점검이 전체 점수만이 아니라 카테고리별로 하락을 감지하는가
• 비결정성(temperature)으로 인한 점수 분산을 통제했는가
• LLM-as-a-judge를 사람 라벨과의 일치도로 먼저 검증했는가
• judge의 position/verbosity/self-preference 편향을 완화하는 장치가 있는가
• 사람 검수가 전수가 아니라 불확실 구간에 집중되는가
• 사람이 찾은 실패가 골든셋으로 환류되어 루프가 닫히는가