LLM 평가와 LLMOps (LLM Evaluation & LLMOps)

난이도: 중급
선수 지식: 대규모 언어 모델, 실험 추적
관련 문서: RAG 심화 | MLOps 기초 | 통계적 검정

핵심 요약: LLM은 정답이 하나가 아니라 정확도로 잴 수 없다. 그래서 ① 평가셋을 직접 만들고, ② 다른 LLM에게 채점시키고(LLM-as-judge), ③ 바뀔 때마다 회귀 평가를 돌린다. 그리고 코드가 아니라 프롬프트가 바뀌어도 결과가 달라지므로, 프롬프트·평가셋·모델 버전을 모두 버전 관리해야 한다.

초보자를 위한 핵심 용어

평가셋(Eval set): “이 질문에는 이런 답이 나와야 한다”를 모아둔 우리 서비스 전용 시험지. 공개 벤치마크로는 대체할 수 없다.
LLM-as-judge: 사람 대신 다른 LLM에게 채점시키는 방법. 싸고 빠르지만 그 자체를 검증해야 한다.
회귀 평가(Regression test): 프롬프트나 모델을 바꾼 뒤 이전보다 나빠진 항목이 없는지 확인하는 것.
프롬프트 버저닝: 프롬프트를 코드처럼 버전 관리하는 것. 한 줄만 바뀌어도 결과가 달라진다.
트레이싱(Tracing): 한 요청이 검색·도구 호출·생성을 거치는 전 과정을 기록하는 것.

개요

기존 ML은 평가가 명확했다. 정답이 정해져 있으니 정확도나 RMSE를 재면 끝이었다.

LLM은 그렇지 않다.

	기존 ML	LLM
정답	하나	여럿 (같은 뜻, 다른 표현)
채점	자동, 명확	애매함
무엇이 바뀌면 결과가 바뀌나	코드·데이터	코드·데이터 + 프롬프트·모델 버전·온도
실패 양상	틀린 예측	환각·거부·형식 위반·장황함 등 다양

그래서 LLM 시스템에는 다른 평가 체계와 다른 운영 체계가 필요하다.

비유: 객관식 채점과 논술 채점의 차이다. 객관식은 답안지만 있으면 누구나 같은 점수를 매긴다. 논술은 채점 기준표(rubric)를 만들어야 하고, 채점자에 따라 점수가 갈리며, 채점자가 일관되게 채점하는지도 검증해야 한다. LLM 평가가 어려운 이유가 정확히 이것이다.

탄생 배경

2023년 기업들이 LLM을 실제 서비스에 붙이기 시작하면서 곧바로 곤란한 상황이 반복되었다.

프롬프트를 한 줄 고쳤더니 다른 질문의 답이 망가졌는데, 배포 후에야 알았다
모델 버전이 공급자 쪽에서 조용히 올라가 어제까지 되던 것이 안 됐다
“좋아진 것 같다”는 느낌만 있고 근거가 없었다
토큰 비용이 예상의 5배로 나왔는데 어디서 쓰였는지 몰랐다

이것들은 전부 기존 MLOps가 다루지 않던 문제였다. 모델 가중치는 그대로인데 프롬프트가 바뀌고, 학습을 안 하는데 성능이 변하기 때문이다.

그래서 프롬프트를 코드처럼 관리하고, 평가셋을 테스트 스위트처럼 돌리고, 요청을 로그처럼 추적하는 관행이 자리 잡았다. 이것을 통칭해 LLMOps라 부른다.

핵심 개념

1. 평가셋을 직접 만들어야 하는 이유

공개 벤치마크 점수는 내 서비스의 성능을 말해주지 않는다. 우리 사용자의 질문 분포가 벤치마크와 다르기 때문이다.

최소한의 평가셋 구성

종류	비율	목적
대표 질문	60%	실제 사용자 질문 로그에서 추출
엣지 케이스	20%	애매하거나 답이 없는 질문
안전 케이스	10%	거부해야 하는 질문
회귀 케이스	10%	과거에 틀렸다가 고친 것

마지막 항목이 특히 중요하다. 한 번 고친 버그가 다시 재발하는 것이 LLM 시스템에서 매우 흔하기 때문이다.

50~100개면 시작할 수 있다. 완벽한 1,000개를 기다리다 아무것도 못 재는 것보다, 불완전한 50개로 오늘부터 재는 편이 낫다.

2. LLM-as-judge — 쓰되 검증하고 쓴다

사람이 채점하면 정확하지만 느리고 비싸다. 그래서 다른 LLM에게 채점을 시킨다.

반드시 지킬 것

기준표(rubric)를 명시한다. “좋은가?”가 아니라 “근거에 없는 내용이 있는가? 질문에 답했는가? 형식을 지켰는가?”
절대 점수보다 비교(A/B)가 안정적이다. “몇 점?”보다 “둘 중 어느 쪽이 나은가?”가 일관성이 높다
심판 자체를 검증한다. 사람이 채점한 표본 50개와 대조해 일치도를 재라
위치 편향에 주의한다. A/B 비교 시 순서를 바꿔가며 물어야 한다

3. 회귀 평가 — 평균만 보면 놓친다

프롬프트를 바꾼 뒤 평균 점수가 올랐다고 안심하면 안 된다. 평균은 올랐는데 특정 유형이 크게 나빠졌을 수 있다.

배포 판단 기준의 예:

평균 점수가 떨어지지 않았는가
크게 나빠진 항목이 없는가 (예: 2점 이상 하락 0건)
안전 케이스가 전부 통과하는가

4. 무엇을 버전 관리할 것인가

LLM 시스템에서 결과를 바꾸는 요소는 코드만이 아니다.

항목	왜
프롬프트	한 단어만 바뀌어도 결과가 달라진다
모델 이름·버전	공급자가 조용히 갱신할 수 있다
온도·top_p 등 파라미터	같은 프롬프트도 결과가 달라진다
평가셋	시험지가 바뀌면 점수 비교가 무의미하다
검색 인덱스 버전	RAG라면 문서가 바뀌면 답이 바뀐다

숫자로 이해하기

프롬프트를 개선하고 평가셋 50개로 A/B 비교했다고 하자.

기존 프롬프트 새 프롬프트
평균 점수 3.06 2.94
개선된 항목 — 3개
악화된 항목 — 9개

평균이 0.12 떨어졌으니 배포하면 안 된다 — 여기까지는 쉽다.

반대 경우가 함정이다. 평균이 3.06 → 3.20으로 올랐는데 악화된 항목이 9개라면?

개선 항목이 20개, 악화가 9개라면 평균은 확실히 오른다

하지만 그 9개에 해당하는 사용자에게는 서비스가 나빠진 것이다

그중 하나가 “환불 규정”처럼 자주 묻는 질문이라면 체감 품질은 떨어진다

그래서 실무 배포 기준은 평균 하나가 아니라 세 가지를 모두 본다.

평균이 떨어지지 않았는가

크게 악화된 항목이 없는가 (예: 2점 이상 하락 0건)

안전 케이스가 전부 통과하는가

	기존 프롬프트	새 프롬프트
평균 점수	3.06	2.94
개선된 항목	—	3개
악화된 항목	—	9개

상세 내용

토큰 비용 모니터링

LLM 서비스에서 비용은 사용자 수에 비례해 선형으로 늘어난다. 기존 ML처럼 “서버 한 대 더” 식으로 예측되지 않는다.

관측해야 할 것:

요청당 입력·출력 토큰 (평균이 아니라 분포를 봐야 한다. 상위 1%가 비용을 지배하는 경우가 흔하다)
캐시 히트율 (프롬프트 캐싱이 실제로 걸리고 있는가)
기능별·사용자별 비용 배분
재시도·실패 요청의 비용 (실패해도 토큰은 나간다)

트레이싱

RAG나 에이전트는 한 요청이 여러 단계를 거친다. 어느 단계에서 문제가 생겼는지 알려면 전 과정을 기록해야 한다.

최소한 남길 것: 최종 프롬프트 전문, 검색된 문서와 점수, 도구 호출 인자와 결과, 각 단계 지연 시간, 토큰 수.

“프롬프트에 최종적으로 무엇이 들어갔는가”를 볼 수 없으면 디버깅이 불가능하다.

언제 사용하는가

상황	최소한 갖출 것
프로토타입	평가셋 20~50개, 수동 확인
내부 사용자 대상	+ LLM-as-judge, 프롬프트 버저닝
외부 서비스	+ 회귀 평가 자동화, 트레이싱, 비용 모니터링
고위험 도메인(의료·금융·법률)	+ 사람 검토 루프, 안전 평가셋, 감사 로그

실전 사례

프롬프트 한 줄로 다른 기능이 망가진 팀

한 팀이 고객 응대 챗봇의 프롬프트에 “답변은 3문장 이내로 간결하게”를 추가했다. 목적은 장황한 답변을 줄이는 것이었고, 그 목적은 달성되었다 — 평균 응답 길이가 절반이 되었고 사용자 만족도 평균도 올랐다.

2주 뒤 CS팀에서 항의가 들어왔다. 환불 절차 안내가 불완전해 재문의가 급증했다는 것이었다. 환불 안내는 원래 필요 서류·기한·처리 기간을 모두 담아야 하는데, “3문장 이내” 지시가 이를 잘라냈다.

문제는 이것이 평균 지표에서 전혀 보이지 않았다는 점이다. 환불 문의는 전체의 4%였고, 나머지 96%에서 개선이 컸기 때문에 평균은 오히려 좋아졌다.

수습 후 팀이 도입한 것은 세 가지였다.

평가셋을 질문 유형별로 분리해 유형별 점수를 따로 봄
“어떤 항목도 2점 이상 하락하면 배포 중단”이라는 규칙
프롬프트 변경을 PR로 관리하고 평가 결과를 자동 첨부

교훈: LLM 시스템에서 프롬프트 한 줄은 전역 변경이다. 한 기능을 고치면 다른 기능이 조용히 망가질 수 있고, 평균 지표는 그것을 숨긴다.

직접 해보기

import numpy as np
rng = np.random.default_rng(0)
n = 200
human = rng.integers(1, 6, n)                      # 사람 점수 1~5
judge = np.clip(human + rng.normal(0, 0.8, n).round(), 1, 5).astype(int)

print("[1] LLM-as-judge 신뢰도 - 심판 모델을 그대로 믿어도 되는가")
print(f"  정확 일치율      {(human==judge).mean():.3f}")
print(f"  ±1점 이내 일치율 {(np.abs(human-judge)<=1).mean():.3f}")
print(f"  상관계수         {np.corrcoef(human,judge)[0,1]:.3f}")

print("\n[2] 회귀 평가 - 평균만 보면 놓치는 것")
base = rng.integers(1, 6, 50)
new  = np.clip(base + rng.choice([-1,0,0,0,1], 50), 1, 5)
worse = (new < base).sum(); better = (new > base).sum()
print(f"  평균: {base.mean():.2f} -> {new.mean():.2f}")
print(f"  개별 항목: 개선 {better}개 / 악화 {worse}개")

# 실행 결과:
# [1] LLM-as-judge 신뢰도 - 심판 모델을 그대로 믿어도 되는가
#   정확 일치율      0.565
#   ±1점 이내 일치율 0.960
#   상관계수         0.871
#
# [2] 회귀 평가 - 평균만 보면 놓치는 것
#   평균: 3.06 -> 2.94
#   개별 항목: 개선 3개 / 악화 9개

[1]이 알려주는 것: 심판 모델과 사람의 정확 일치는 56.5%지만 ±1점 이내는 96%다. 이 조합이 실무적 결론을 준다 — “모델 A가 3.8점”이라고 절대 점수를 보고하기엔 부족하지만, “A가 B보다 낫다”는 순위 비교에는 쓸 만하다. 그래서 LLM-as-judge는 절대 점수보다 A/B 비교에 쓰는 것이 안전하다.

[2]가 알려주는 것: 평균은 3.06 → 2.94로 0.12만 움직였지만, 개별로 보면 9개 항목이 악화되었다. 만약 개선 항목이 더 많아 평균이 올랐다면 이 9개는 지표에 묻혔을 것이다. 평균 하나로 배포를 결정하면 안 되는 이유다.

흔한 오해와 함정

“공개 벤치마크 점수가 높으니 우리 서비스에서도 잘할 것” — 벤치마크와 우리 사용자의 질문 분포는 다르다. 자체 평가셋이 없으면 아무것도 모르는 것이다.
“LLM-as-judge 점수를 그대로 믿는다” — 심판 모델도 편향이 있다(위치 편향, 장황한 답 선호, 자기 모델 선호). 사람 표본과 대조해 검증해야 한다.
“평균 점수가 올랐으니 배포한다” — 악화된 항목을 반드시 따로 봐야 한다. 평균은 소수의 심각한 회귀를 숨긴다.
“모델 이름만 고정하면 재현된다” — 공급자가 같은 이름으로 모델을 갱신할 수 있다. 온도·top_p까지 고정해도 완전한 결정성은 보장되지 않는다.
“토큰 비용은 평균으로 추정하면 된다” — 분포를 봐야 한다. 긴 문서를 붙이는 소수 요청이 전체 비용의 대부분을 차지하는 경우가 흔하다.

스스로 점검하기

1. 프롬프트를 바꿨더니 평가셋 평균이 3.1에서 3.3으로 올랐다. 배포해도 되는가?

정답 보기

평균만으로는 판단할 수 없다. 개별 항목 중 크게 악화된 것이 있는지 확인해야 한다. 개선 20개·악화 9개여도 평균은 오르지만, 그 9개가 자주 묻는 질문이라면 체감 품질은 떨어진다. 안전 케이스 통과 여부도 함께 봐야 한다.

2. LLM-as-judge를 쓸 때 절대 점수보다 A/B 비교가 권장되는 이유는?

정답 보기

심판 모델의 절대 점수는 일관성이 낮다(정확 일치율 50%대). 반면 “둘 중 어느 쪽이 나은가”라는 상대 비교는 훨씬 안정적이다. 단, 위치 편향이 있으므로 순서를 바꿔가며 물어야 한다.

3. 기존 MLOps에 없던, LLMOps에서 새로 버전 관리해야 하는 것은?

정답 보기

프롬프트, 모델 이름·버전, 생성 파라미터(온도 등), 평가셋, 검색 인덱스 버전이다. 기존 ML은 코드와 데이터가 같으면 결과가 같지만, LLM은 가중치를 건드리지 않아도 프롬프트 한 줄이나 공급자의 조용한 모델 갱신으로 결과가 달라진다.

다른 주제와의 연결

RAG 심화: RAG 파이프라인의 검색·생성 단계별 평가
MLOps 기초: 모니터링·드리프트·재학습의 일반 원칙
실험 추적: 재현성을 위해 무엇을 남길 것인가
통계적 검정: 점수 차이가 유의한지 판단하기
대규모 언어 모델: 토큰 비용 구조와 추론 최적화