AI 기능을 붙인 서비스를 만들다 보면 금방 부딪히는 질문이 있습니다. “이 모델이 진짜 괜찮은 걸까?” 데모에서는 그럴듯해 보이는데 실제 사용자 질문이 들어오면 품질이 흔들리는 경우가 많습니다.
그래서 LLM evaluation은 옵션이 아니라 거의 필수에 가깝습니다. 프롬프트를 바꾸거나, 모델을 교체하거나, RAG를 붙였을 때 결과가 실제로 좋아졌는지 확인할 기준이 필요하기 때문입니다.
이 글에서는 아래 내용을 정리합니다.
- LLM 평가가 왜 중요한지
- 무엇을 평가해야 하는지
- 정성 평가와 정량 평가를 어떻게 함께 보는지
핵심은 LLM 평가는 “모델 점수” 하나를 보는 일이 아니라, 실제 사용 맥락에서 원하는 품질을 반복 가능하게 확인하는 과정이라는 점입니다.
왜 LLM 평가가 중요한가
LLM 출력은 같은 질문에도 조금씩 달라질 수 있고, 실제 서비스에서는 질문 종류도 매우 다양합니다. 그래서 몇 번 써보고 느낌이 좋다고 해서 품질이 안정적이라고 말하기 어렵습니다.
평가가 중요한 이유는 보통 아래와 같습니다.
- 모델 교체 전후 품질 비교
- 프롬프트 변경 효과 확인
- RAG나 tool use 도입 효과 검증
- 오류 유형 파악
- 출시 전 위험 점검
즉, 평가는 “좋아 보인다”를 “어떤 조건에서 얼마나 좋아졌는가”로 바꾸는 작업입니다.
무엇을 평가해야 할까
정답은 제품마다 다르지만, 보통 아래 축을 함께 봅니다.
1. 정확성
사실 기반 질문에서 틀린 정보를 말하지 않는가를 봅니다. 특히 검색, 요약, Q&A 기능에서는 가장 중요합니다.
2. 관련성
질문 의도에 맞는 답을 주는지 확인합니다. 문장이 자연스러워도 엉뚱한 답이면 좋은 응답이 아닙니다.
3. 완전성
중요한 정보를 빠뜨리지 않았는지 봅니다. 요약, 분석, 코드 리뷰 같은 작업에서 자주 중요해집니다.
4. 형식 준수
JSON, 표, 불릿, 특정 스키마처럼 원하는 출력 형식을 지키는지 확인합니다.
5. 안정성
비슷한 입력에서 결과가 지나치게 흔들리지 않는지 봅니다.
정성 평가와 정량 평가는 둘 다 필요하다
초기에는 사람 눈으로 읽어보는 정성 평가가 매우 중요합니다. 어떤 실수가 실제로 거슬리는지, 어디서 신뢰가 무너지는지 사람이 제일 빨리 발견할 수 있기 때문입니다.
하지만 규모가 커지면 정성 평가만으로는 비교가 어렵습니다. 그래서 정량 평가가 필요해집니다.
예를 들어:
- 100개 질문 세트에 대한 정답률
- 형식 준수율
- 근거 문서 인용 비율
- 특정 오류 발생 빈도
이런 식으로 측정하면 변경 전후를 비교하기 쉬워집니다.
가장 좋은 흐름은 보통 이렇습니다.
- 사람 평가로 중요한 품질 기준을 찾는다
- 그 기준을 데이터셋과 지표로 옮긴다
- 반복 평가에 넣는다
평가 데이터셋은 어떻게 만들까
가장 좋은 출발점은 실제 사용자 질문입니다. 데모용 예시만 모아두면 실제 운영 문제를 놓치기 쉽습니다.
평가셋을 만들 때는 아래를 섞는 것이 좋습니다.
- 자주 들어오는 질문
- 자주 실패하는 질문
- 애매한 질문
- 길거나 복잡한 질문
- 형식 준수가 중요한 질문
즉, “잘 되는 예시”만 모으지 말고 “헷갈리는 예시”를 일부러 포함해야 합니다.
LLM-as-a-judge는 만능일까
모델이 다른 모델의 출력을 평가하는 방식은 빠르고 확장성이 좋아서 많이 쓰입니다. 하지만 이것만 믿으면 위험할 수 있습니다.
왜냐하면:
- 평가 기준이 모호할 수 있고
- 평가 모델도 편향될 수 있으며
- 사실 정확성은 따로 검증이 필요하기 때문입니다
그래서 보통은 사람 평가, 규칙 기반 검사, LLM judge를 함께 씁니다.
자주 하는 실수
1. 한두 개 데모만 보고 모델을 고른다
데모에서 잘 보이는 것과 실제 운영 품질은 다를 수 있습니다.
2. 평균 점수만 본다
평균은 괜찮아 보여도 특정 유형 질문에서 계속 망가질 수 있습니다.
3. 품질 지표 없이 프롬프트를 계속 바꾼다
이 경우 좋아진 건지, 그냥 느낌만 달라진 건지 구분하기 어렵습니다.
FAQ
Q. 작은 프로젝트도 평가가 필요할까
규모는 작아도 좋습니다. 다만 최소한 대표 질문 몇 개와 확인 기준은 있어야 변경할 때 덜 흔들립니다.
Q. 정확성만 보면 충분한가
아닙니다. 정확해도 형식을 안 지키거나 질문 의도에서 벗어나면 실제 사용성이 떨어질 수 있습니다.
Q. 평가를 언제 시작해야 할까
가능하면 초반부터 시작하는 것이 좋습니다. 뒤로 갈수록 감으로 쌓인 변경이 많아져 비교가 더 어려워집니다.
Read Next
- 모델 선택 기준을 넓게 보고 싶다면 LLM 벤치마크 가이드를 같이 읽어보세요.
- 문서 기반 정확성을 높이는 구조는 RAG 가이드와 자연스럽게 이어집니다.
심사 대기 중에는 광고 대신 관련 가이드를 먼저 보여줍니다.
먼저 읽어볼 가이드
검색 유입이 많은 핵심 글부터 이어서 보세요.
- 미들웨어 트러블슈팅 가이드: Redis vs RabbitMQ vs Kafka 개발자를 위한 미들웨어 트러블슈팅 허브 글입니다. Redis, RabbitMQ, Kafka 중 어떤 증상부터 먼저 봐야 하는지와 어떤 문제 패턴이 각 시스템에 가까운지 정리합니다.
- Kubernetes CrashLoopBackOff: 먼저 볼 것들 startup failure, probe, config, resource limit 관점에서 CrashLoopBackOff를 어떻게 나눠서 봐야 하는지 정리한 가이드입니다.
- Kafka consumer lag가 계속 늘 때: 트러블슈팅 가이드 Kafka consumer lag가 계속 늘어날 때 무엇부터 봐야 하는지 정리합니다. poll 주기, 처리 속도, rebalance, consumer 설정까지 실전 기준으로 다룹니다.
- Kafka Rebalancing Too Often 가이드 Kafka consumer group에서 rebalance가 너무 자주 일어날 때 membership flapping, poll timing, protocol, assignment churn을 어떤 순서로 봐야 하는지 설명하는 실전 가이드입니다.
- Docker container가 계속 재시작될 때: 먼저 확인할 것들 exit code, command failure, environment mistake, health check 관점에서 Docker restart loop를 푸는 실전 가이드입니다.
심사 대기 중에는 광고 대신 관련 가이드를 먼저 보여줍니다.