Apr 5, 2026

마지막 업데이트 Apr 14, 2026

LLM 평가 가이드: AI 모델 품질을 어떻게 측정하고 개선할까

AI 기능을 붙여서 데모를 만들면 처음에는 꽤 그럴듯해 보입니다. 그런데 실제 사용자 질문이 들어오기 시작하면 금방 다른 문제가 보입니다. 어떤 질문에는 잘 답하는데, 비슷한 질문에는 틀리고, 프롬프트를 조금만 바꿔도 형식이 무너지거나, RAG를 붙였더니 오히려 답변이 장황해지는 식입니다.

그래서 LLM evaluation은 선택이 아니라 운영의 기본에 가깝습니다. 프롬프트를 수정할 때마다 “이번엔 더 좋아 보인다”고 느꼈는데, 고정 질문 30개로 평가를 돌려보니 정확도는 올랐지만 JSON 형식 준수율이 95%에서 70%로 떨어져 있었습니다. 평가 세트가 없었으면 그대로 배포했을 겁니다. 모델을 바꾸든, 프롬프트를 손보든, 검색 문서를 넣든, 지금 시스템이 정말 좋아졌는지 확인할 기준이 없으면 계속 감으로만 수정하게 됩니다.

이 글에서는 아래 내용을 정리합니다.

LLM 평가가 왜 중요한지
어떤 항목을 평가해야 하는지
정성 평가와 정량 평가를 어떻게 같이 써야 하는지

핵심만 먼저 말하면 LLM 평가는 “모델 점수 하나”를 보는 일이 아니라, 실제 사용 시나리오에서 원하는 품질을 안정적으로 내는지 반복해서 검증하는 과정입니다.

LLM 평가란 무엇인가

LLM 평가는 모델이 똑똑해 보이는지 확인하는 작업이 아닙니다. 우리 제품의 질문, 제약, 출력 형식, 실패 허용 범위에 맞게 결과를 내는지를 확인하는 일입니다.

예를 들어 같은 모델이라도 용도에 따라 평가 기준이 달라집니다.

고객지원 챗봇: 사실 정확성, 정책 준수, 톤 안정성
문서 요약 도구: 핵심 정보 보존, 누락 여부, 길이 제어
코드 보조 기능: 지시 이행, 형식 준수, 위험한 제안 회피
RAG 검색 답변: 근거 문서 반영, 인용 일관성, 환각 감소

즉 평가의 출발점은 “이 모델이 좋으냐”가 아니라 “이 작업에서 충분히 믿고 쓸 수 있느냐”입니다.

왜 LLM 평가가 중요한가

LLM 시스템은 겉으로 보기보다 변화에 민감합니다. 다음과 같은 수정이 모두 품질 변화로 이어질 수 있습니다.

모델 교체
프롬프트 구조 변경
system prompt 추가
temperature 변경
RAG 검색 로직 변경
툴 호출 순서 변경

문제는 이런 변화가 모든 항목에 같은 방향으로 작용하지 않는다는 점입니다. 정확도는 올라갔는데 응답 속도가 나빠질 수 있고, 형식 준수는 좋아졌는데 답변이 너무 딱딱해질 수도 있습니다. 그래서 평가 없이 “이번 변경이 더 좋아 보인다”라고 판단하면 위험합니다.

평가는 특히 이런 순간에 필요합니다.

새 모델 도입 전후를 비교할 때
프롬프트 수정이 실제 개선인지 확인할 때
RAG나 툴 사용이 환각을 줄였는지 검증할 때
출시 전 리스크를 점검할 때
운영 중 회귀(regression)를 빨리 찾고 싶을 때

결국 평가는 감으로 하던 개선을 재현 가능한 개선으로 바꿔 줍니다.

무엇을 평가해야 할까

정답은 제품마다 다르지만, 대부분의 LLM 기능은 아래 축을 기본으로 봅니다.

1. 정확성

사실 질문에서 틀린 내용을 말하지 않는지 봅니다. Q&A, 고객지원, 문서 요약, 분석형 기능에서는 거의 항상 중요합니다.

2. 관련성

질문 의도에 맞는 답을 했는지 확인합니다. 문장이 자연스러워 보여도 질문을 살짝 비껴가면 실사용 품질은 낮습니다.

3. 완전성

핵심 포인트를 빼먹지 않았는지 봅니다. 요약, 리뷰, 비교, 보고서 생성 같은 작업에서는 특히 중요합니다.

4. 형식 준수

JSON 스키마, 표 형식, 불릿 구조, 금지 문구, 출력 길이 제한 같은 요구사항을 지키는지 확인합니다.

5. 안정성

비슷한 입력에서 품질이 지나치게 흔들리지 않는지 봅니다. 데모에서는 잘 되는데 운영에서는 출렁이는 경우가 많기 때문입니다.

6. 안전성

민감한 주제에서 위험한 조언을 하거나, 권한 없는 행동을 유도하거나, 정책 위반 가능성이 있는 답을 하는지 확인합니다.

이 여섯 가지를 모두 같은 비중으로 볼 필요는 없습니다. 대신 우리 기능에 치명적인 실패가 무엇인지 먼저 정해야 합니다.

정성 평가와 정량 평가는 왜 둘 다 필요할까

초기에는 사람 눈으로 보는 정성 평가가 매우 중요합니다. 왜 품질이 나쁜지, 어떤 말투가 거슬리는지, 어디서 흐름이 깨지는지는 사람이 가장 빨리 발견합니다.

하지만 사람 평가만으로는 시간이 지날수록 비교가 어려워집니다. 지난달보다 좋아졌는지, 프롬프트 A와 B 중 무엇이 나은지, 새 모델이 정말 개선인지 일관되게 말하기 어려워집니다.

그래서 정량 평가가 필요합니다. 예를 들면:

100개 질문 세트 기준 정답률
JSON 형식 준수율
인용 포함 비율
금지된 오류 유형 발생 횟수
특정 업무 성공률

실무에서는 보통 아래 순서가 가장 자연스럽습니다.

사람 리뷰로 중요한 기준을 찾는다.
그 기준을 데이터셋과 체크 항목으로 만든다.
변경이 있을 때마다 반복 측정한다.

정성 평가는 “무엇이 문제인가”를 찾는 데 강하고, 정량 평가는 “개선이 실제로 일어났는가”를 확인하는 데 강합니다.

평가 세트는 어떻게 만들어야 할까

가장 좋은 출발점은 실제 사용자 질문입니다. 데모용 예시만 모으면 운영에서 자주 터지는 문제를 놓치기 쉽습니다.

평가 세트에는 보통 이런 유형을 섞는 것이 좋습니다.

자주 들어오는 기본 질문
시스템이 자주 실패한 질문
애매하거나 의도가 모호한 질문
여러 단계를 거쳐야 하는 질문
형식 준수가 중요한 질문
긴 문맥을 요구하는 질문

그리고 꼭 넣어야 하는 것이 “불편한 질문”입니다. 모델이 잘하는 예시만 모으면 점수는 높아져도 운영 체감은 나빠질 수 있습니다.

간단한 시작 형태는 아래처럼 잡을 수 있습니다.

질문: 환불 정책을 한 문장으로 요약해줘
기대 조건:
- 정책 문서 범위 안에서만 답할 것
- 1문장으로 끝낼 것
- 환불 가능 기간을 포함할 것

처음부터 완벽한 정답 문장을 만들 필요는 없습니다. “무엇이 통과 조건인가”를 명확하게 적는 것만으로도 평가 품질이 훨씬 좋아집니다.

오프라인 평가와 온라인 평가는 다르다

많은 팀이 평가라고 하면 고정된 질문 세트로 점수 내는 장면만 떠올립니다. 그것은 중요하지만 전체의 절반입니다.

오프라인 평가는 출시 전 비교에 강합니다.

프롬프트 A/B 비교
모델 교체 전후 비교
검색 품질 조정 전후 비교
회귀 테스트

온라인 평가는 실제 사용 중 품질 확인에 강합니다.

사용자 재질문 비율
답변 후 이탈률
사람이 수정한 비율
잘못된 답변 신고율
CS 전환율

오프라인 점수가 좋아도 실제 사용자 만족도가 떨어질 수 있고, 반대로 온라인 지표만 보면 왜 성능이 흔들리는지 원인을 찾기 어렵습니다. 둘은 경쟁 관계가 아니라 서로 보완하는 관계입니다.

LLM-as-a-judge는 어디까지 믿어야 할까

모델이 다른 모델의 답을 채점하게 하는 방식은 빠르고 확장성이 좋아서 많이 쓰입니다. 특히 초안 비교, 스타일 체크, 기준 기반 평가에서는 유용합니다.

하지만 이것만 믿으면 위험합니다.

평가 기준이 모호하면 판정도 흔들립니다.
judge 모델 자체에 편향이 있을 수 있습니다.
사실 정확성은 별도 근거 확인이 필요합니다.
미묘한 업무 규칙은 사람보다 잘 못 잡을 수 있습니다.

그래서 안정적인 평가는 보통 세 층을 같이 씁니다.

사람 리뷰
규칙 기반 체크
LLM judge

예를 들어 JSON 형식은 규칙으로 검사하고, 근거 문서 포함 여부는 규칙과 문자열 검사를 섞고, 답변의 자연스러움이나 비교 우열은 사람이나 LLM judge가 보는 식입니다.

작은 팀은 어떻게 시작하면 될까

처음부터 거대한 평가 플랫폼을 만들 필요는 없습니다. 작은 팀이라면 아래 정도로도 충분히 좋은 출발입니다.

실제 질문 20개를 모읍니다.
각 질문마다 통과 조건 2~3개를 적습니다.
프롬프트나 모델을 바꿀 때 같은 세트로 다시 봅니다.
자주 틀리는 유형을 별도 카테고리로 묶습니다.

예를 들면 이런 항목만 있어도 꽤 쓸모 있습니다.

정답 여부
형식 준수 여부
근거 포함 여부
치명적 오류 여부

이 정도만 운영해도 “무조건 좋아진 것 같다”는 느낌 대신 “이 변경은 정확도는 유지하면서 형식 준수율을 올렸다” 같은 판단이 가능해집니다.

자주 하는 실수

1. 데모가 잘 되니 충분하다고 생각한다

데모는 보통 쉬운 질문 위주라서 실제 운영 난도를 반영하지 못합니다.

2. 평균 점수 하나만 본다

평균은 보기 좋지만, 특정 질문군에서 치명적으로 망가지는 문제를 가릴 수 있습니다.

3. 기준 없이 프롬프트만 계속 바꾼다

기준점이 없으면 개선인지 단순한 스타일 변화인지 구분하기 어렵습니다.

4. 평가 세트가 너무 깨끗하다

실사용 입력은 오탈자, 모호한 표현, 긴 문장, 부족한 맥락이 섞여 있습니다. 평가 세트도 그 현실을 어느 정도 닮아야 합니다.

FAQ

Q. 작은 프로젝트도 LLM 평가가 필요할까

그렇습니다. 다만 거창할 필요는 없습니다. 고정 질문 10~20개와 간단한 통과 기준만 있어도 큰 차이가 납니다.

Q. 정확도만 보면 충분할까

아닙니다. 형식 준수, 관련성, 누락 여부, 안전성까지 함께 봐야 실제 사용자 경험을 설명할 수 있습니다.

Q. 평가는 언제 시작하는 게 좋을까

가능하면 초반부터 시작하는 것이 좋습니다. 늦을수록 비교 기준이 흐려지고, 왜 좋아졌는지 설명하기 어려워집니다.

먼저 읽어볼 가이드

검색 유입이 많은 핵심 글부터 이어서 보세요.