분류 모델 만들 때는 잘 됐냐는 질문이 별로 안 어려웠다. 정답이 정해져 있으니까 맞았는지 틀렸는지 세면 되고, 정확도나 F1 하나 던지면 대화가 끝났으니까. 그런데 LLM 붙인 기능을 만들기 시작하면서 이게 갑자기 곤란해졌다. 요약이 잘 된 건가? 답변 톤은 괜찮나? 에이전트가 일을 제대로 한 건가? 물어보면 할 말이 “그런 것 같은데요”밖에 없었다. 결과물 스무 개쯤 눈으로 훑어보고 괜찮아 보이면 넘어갔는데, 이걸 평가라고 부르기는 좀 그렇다는 건 나도 알고 있었다.
그래서 마음먹고 LLM 평가 방법을 훑어봤다. 근데 이게 이름만 봐서는 뭐가 뭔지 도무지 구분이 안 된다. BLEU, ROUGE, G-Eval, DAG… 다 따로 노는 것처럼 보인다. 한참 들여다보다가 내 나름대로 네 덩어리로 묶으니까 그제서야 지도가 그려졌다. 이 글은 그 정리 노트다. 각각 뭘 정답으로 치는지, 언제 쓰는지, 그리고 어디서 넘어지는지까지 적어뒀다.
1. 정답을 맞혔는데 0점이 나온다고?
왜 이렇게 방법이 많아졌는지는 예시 하나만 보면 감이 온다.
채점기를 뭘로 쓰느냐에 따라 같은 답이 0점도 되고 100점도 된다.
“프랑스의 수도는 어디야?”라고 물었더니 모델이 “프랑스 수도라면 단연 파리죠”라고 답했다. 사람이 보면 뭐 하나 나무랄 데 없는 정답이다. 그런데 정답지에 “파리는 프랑스의 수도이다”라고 적혀 있고 채점 방식이 단어 겹침이면, 이 답은 거의 0점을 받는다. 어순도 다르고 어미도 다르니까.
전통적인 머신러닝에서는 이런 일이 잘 안 생긴다. 스팸이냐 아니냐, 이탈하냐 마느냐처럼 정답이 딱 떨어지기 때문이다. 근데 자연어는 같은 뜻을 담는 표현이 수십 가지고, 심지어 뭐가 좋은 답인지도 상황마다 다르다. 요약할 때는 빠뜨리지 않는 게 중요하고, 번역할 때는 표현이 정확한 게 중요하고, 상담 답변이면 말투가 중요하다. 하나의 잣대로 다 잴 수가 없다.
그러니까 방법이 여러 개인 건 어느 하나가 최고고 나머지가 열등해서가 아니다. 각자 “정답이 뭐냐”에 대해 다른 가정을 깔고 있어서, 애초에 다른 질문에 답하고 있는 거다. 이걸 알고 보면 외울 게 확 줄어든다.
2. 네 덩어리로 묶어보자
무엇을 정답의 근거로 삼느냐를 기준으로 11가지를 묶으면 이렇게 된다.
계열을 가르는 기준은 “무엇을 정답의 근거로 삼느냐”다.
정답지를 놓고 비교하는 쪽, 다른 모델한테 채점을 맡기는 쪽, 사람이나 규칙으로 기준을 못 박는 쪽, 그리고 답이 아니라 시스템이 어떻게 굴러갔는지를 보는 쪽. 위에서 아래로 내려갈수록 질문이 “정답 맞혔나”에서 “이거 제품으로 굴러가나”로 옮겨간다. 하나씩 보자.
3. 정답지랑 비교하기
제일 오래됐고 제일 이해하기 쉬운 쪽이다. 모범 답안을 미리 만들어두고 모델 답이 거기서 얼마나 벗어났는지 센다. 여기 속한 셋은 화살표 방향으로 기억하면 안 헷갈린다.
BLEU는 답에서 정답지 쪽으로, ROUGE는 정답지에서 답 쪽으로 묻는다.
BLEU는 모델이 낸 말을 기준으로 묻는다. “네가 쓴 이 표현, 정답지에 있는 거 맞아?” 정밀도 쪽이다. 번역처럼 답이 거의 정해진 일에 쓴다. 짧게 써서 틀릴 위험만 피하는 얌체 짓을 막으려고 길이 벌점이 붙어 있고, 문장별로 점수 내서 평균 내지 말고 전체 코퍼스 단위로 계산하는 게 정석이다. 정답이 여러 개일 수 있으면 참조 답안도 여러 개 넣어주는 게 좋다.
ROUGE는 방향이 반대다. 정답지 기준으로 “여기 있는 이 내용, 네 답에 들어 있어?”를 묻는다. 재현율이다. 요약이나 정보 추출처럼 빠뜨리는 게 군더더기보다 아픈 일에 쓴다. 대신 재현율만 보면 길게 쓸수록 유리해지니까 정밀도 지표랑 같이 봐야 한다. 순서가 좀 바뀌어도 봐주는 ROUGE-L 같은 변형도 있다.
BERTScore는 앞의 둘이 못 잡는 걸 잡으려고 나왔다. 글자가 아니라 임베딩, 그러니까 의미 공간에서 비교한다. 그래서 아까 그 “단연 파리죠”를 정답으로 쳐준다. 대신 점수가 높은 쪽 좁은 구간에 몰려 있어서 0.85 같은 숫자를 정확도처럼 읽으면 안 된다. A 모델이 B 모델보다 높네, 정도로만 쓰는 게 맞다. 임베딩 모델이 우리 도메인이랑 언어에 맞는지도 봐야 하고.
여기까지 오면 한계가 보인다. 셋 다 정답지가 있어야 쓴다. 근데 실무에서 만나는 일들은 정답지를 못 만드는 게 태반이다. 상담 답변이 충분히 공손한지에 대한 정답지를 어떻게 만드나.
4. 모델한테 채점을 맡기기
정답지를 못 만들면 사람이 채점하는 수밖에 없는데, 사람은 느리고 비싸다. 그래서 나온 게 채점을 아예 다른 LLM한테 맡기는 방식이다.
기준을 단계로 풀어 점수를 내거나, 둘을 붙여 승자를 고르거나, 여러 판정자 의견을 모은다.
G-Eval은 평가 기준을 주면 판정 모델이 그걸 채점 단계로 풀어낸 다음, 단계를 하나씩 보면서 점수를 매긴다. 톤이나 지시 준수 여부처럼 정답지가 없는 주관적인 기준에 쓴다. 여기서 실무 팁이 하나 있는데, 기준을 “친절해야 한다” 같은 형용사로 쓰면 점수가 들쭉날쭉하고, “고객 질문을 다시 확인하는 문장이 있는가”처럼 체크리스트로 쓰면 훨씬 일관되게 나온다. 이거 알기 전엔 기준을 추상적으로 써놓고 왜 점수가 흔들리나 했었다. 판정 모델은 온도 낮춰서 돌리고.
LLM-as-Judge는 보통 둘을 붙여놓고 고르게 하는 형태로 쓴다. 절대 점수는 돌릴 때마다 흔들리는데 “둘 중에 뭐가 나아?”는 상대적으로 안정적이라, 모델 두 개나 프롬프트 두 버전 비교할 때 실용적이다.
LLM 배심원단은 판정자 여러 명을 따로 돌려서 점수를 평균 낸다. 판정자 하나한테는 일정한 버릇이 있기 때문인데, 여기서 중요한 게 있다. 같은 모델을 세 번 돌리는 건 배심원단이 아니다. 서로 다른 계열 모델을 섞어야 한다. 그리고 작은 모델 여럿이 큰 모델 하나보다 나은 경우가 꽤 흔하다.
근데 채점하는 모델도 결국 모델이다
이 계열 쓸 때 제일 조심할 게 판정자의 버릇이다. 알려진 것만 세 개다.
순서, 길이, 자기 계열 선호. 셋 다 여러 번 돌려 평균 낸다고 사라지지 않는다.
판정 모델은 먼저 보여준 답을 더 자주 고르고, 내용이 딱히 낫지 않아도 긴 답에 점수를 더 주고, 자기랑 같은 계열 모델이 쓴 답을 편든다. 그래서 A/B 순서를 무작위로 섞고, 길이를 통제하고, 배심원단은 다른 계열로 구성하라는 얘기가 나온다.
여기서 하나 짚고 싶은 게 있다. 이 셋은 잡음이 아니라 한쪽으로 쏠린 버릇이다. 잡음이면 여러 번 돌려서 평균 내면 상쇄되는데, 쏠린 버릇은 평균 내도 그대로 남는다. 오히려 여러 번 돌린 만큼 더 자신 있게 틀린 점수가 나온다. 통계 배울 때 분산이랑 편향은 다른 문제라고 배웠던 게 여기서 똑같이 적용되는 셈이다. 그래서 판정 모델 도입할 때는 사람이 채점한 작은 세트를 먼저 만들고 판정자 점수가 거기랑 얼마나 맞는지 확인하는 절차가 필요하다. 평가자를 평가하는 단계가 하나 더 생기는 거다.
5. 사람이 기준을 못 박기
자동 채점이 흔들릴 때 붙잡아주는 두 가지가 있다.
사람 평가는 결국 모든 자동 지표가 맞춰야 할 기준점이다. 평가자들이 정해진 항목별로 점수를 매기고, 그게 판정 모델을 검증하는 캘리브레이션 세트가 된다. 쓰이는 자리는 두 군데다. 판정자를 믿어도 되는지 확인할 때, 그리고 출시 직전 마지막 관문에서. 중요한 원칙은 채점 기준을 먼저 확정하고 시작하는 것, 그리고 평가자끼리 얼마나 일치하는지를 재는 것이다. 일치도가 낮으면 평가자가 이상한 게 아니라 기준이 모호한 거다. 데이터 라벨링 해본 사람이면 익숙한 이야기일 텐데, 여기서도 똑같이 반복된다.
DAG는 결정 트리로 채점한다. 노드마다 좁은 질문 하나 던지고, 답에 따라 다음 노드로 갈라지고, 마지막 잎이 점수를 갖는다. 형식을 지켰는지, 필수 항목이 들어갔는지, 고지 문구가 있는지처럼 반드시 지켜야 하는 것들에 쓴다. 분기가 결정론적이라 같은 입력은 언제나 같은 점수가 나오는 게 장점이고, 값싼 규칙 검사를 트리 위쪽에 두면 탈락할 답이 모델 호출 전에 걸러져서 비용도 아낀다.
6. 답 말고 동작 보기
여기부터는 성격이 좀 다르다. 답 한 줄이 아니라 시스템이 어떻게 굴러갔는지를 본다. 에이전트를 만들기 시작하면 이쪽이 필수가 된다.
경로 정확도는 에이전트가 밟은 생각·도구 호출·관찰의 순서를 통째로 붙잡아서 기대한 경로랑 비교한다. 왜 필요한지는 예시를 보면 바로 이해된다.
최종 답이 같아도 과정은 전혀 다를 수 있다.
둘 다 같은 정답을 냈는데, 하나는 3단계로 깔끔하게 갔고 다른 하나는 12단계를 헤매면서 토큰을 네 배 쓰고 건드리면 안 되는 도구까지 한 번 만졌다. 결과만 채점하면 둘 다 100점이다. 운 좋게 맞은 답이 망가진 실행 경로를 가려주는 셈인데, 이런 건 배포하고 나서야 터진다. 그래서 경로랑 결과를 따로 채점해야 한다. 참고로 이걸 하려면 실행 추적, 그러니까 트레이싱이 먼저 깔려 있어야 한다. 기록이 없으면 채점할 경로도 없으니까.
멀티턴 평가는 대화 전체를 한 덩어리로 보고 역할 유지, 앞 내용 기억, 일관성을 채점한다. 턴 하나씩 따로 보면 시간이 지나야 드러나는 실패를 놓치기 때문이다. 다섯 턴 전에 사용자가 정해준 제약을 슬그머니 어긴다든가, 앞에서 한 말이랑 모순되는 답을 한다든가 하는 것들. 이건 인위적으로 만든 2턴짜리 예제 말고 실제 대화 로그로 돌려야 의미가 있다. 규칙 까먹는 문제는 대화가 깊어져야 나온다.
안전성 평가는 편향·유해성·개인정보 노출을 각각의 분류기로 병렬 검사해서 위반을 표시한다. 여기서 제일 중요한 건 이걸 점수로 만들지 말라는 거다. 평균 품질 점수 안에 안전성을 한 항목으로 넣으면 다른 점수가 높을 때 위반이 묻힌다. 개인정보 한 번 새는 건 평균이 아무리 좋아도 상쇄가 안 되는 종류의 사고다. 평균에 넣을 항목이 아니라 통과냐 차단이냐를 정하는 관문으로 둬야 한다.
7. 그래서 나는 뭘 써야 하나
다 알아도 막상 고르려면 막막해서, 내가 판단하는 순서를 흐름으로 정리해봤다.
정답지 유무로 크게 갈리고, 아래 두 층은 어느 길로 왔든 붙는다.
시작은 정답지가 있느냐다. 있고 표현까지 거의 정해져 있으면 BLEU나 ROUGE, 같은 뜻을 다르게 쓸 수 있는 일이면 BERTScore. 정답지가 없으면 뭘 알고 싶은지로 갈린다. 톤이나 지시 준수 같은 주관적 기준이면 G-Eval, 두 버전 중에 뭐가 나은지가 궁금하면 LLM-as-Judge.
그리고 어느 길로 왔든 아래 두 층은 붙는다. 사람 평가는 자동 지표를 믿을 수 있게 만드는 기준점으로, DAG는 꼭 지켜야 할 형식 검사로, 안전성은 게이트로. 에이전트를 만든다면 경로 정확도랑 멀티턴이 더 얹힌다.
8. 개인적인 견해
정리하고 나서 제일 크게 남은 생각은, LLM 시대에는 평가 자체가 모델링 작업이 됐다는 거다.
예전에 평가는 모델 다 만들고 나서 하는 확인 절차에 가까웠다. 정답이 주어져 있으니까 지표 고르는 데 큰 고민이 없었고, 논쟁은 주로 모델 쪽에서 벌어졌다. 근데 LLM에서는 순서가 뒤집힌다. 뭘 좋은 답으로 볼지 정의하는 것부터가 일이고, 그 정의를 체크리스트로 옮기고, 채점자를 고르고, 채점자 버릇을 보정하고, 사람 채점 세트로 검증한다. 이쯤 되면 확인 절차가 아니라 설계 작업이다. 판정 모델을 쓰기 시작하면 평가자 자체가 학습된 모델이라 평가자를 평가하는 층이 하나 더 생기고.
그래서 좋은 평가 세트 만드는 일이 좋은 프롬프트 쓰는 일보다 오래 남는 자산이라고 느낀다. 프롬프트는 모델 바뀌면 다시 써야 하는데, “우리 도메인에서 좋은 답은 이런 것”이라는 기준이랑 그걸 담은 데이터는 모델이 바뀌어도 계속 쓰인다. 오히려 모델 갈아탈 때 갈아타도 되는지 판단하는 근거가 된다. 예전에 AI Agent는 더 좋은 프롬프트가 아니라 더 좋은 Harness에서 나온다에서 모델 바깥의 구조가 성능을 만든다는 얘기를 했는데, 평가 세트도 그 구조의 일부인 것 같다.
또 하나, 에이전트로 넘어오면서 평가 대상이 답에서 행동으로 옮겨간 게 인상적이었다. 결과만 맞으면 됐던 시절이 끝나고 어떤 도구를 건드렸는지, 몇 번 헤맸는지, 하면 안 되는 일을 했는지를 봐야 한다. 사람으로 치면 결과 보고서만 보다가 업무 로그를 보기 시작한 셈이다. 금융 AI에서의 에이전틱 엔지니어링에서 다뤘던 것처럼 실수 비용이 큰 도메인일수록 이 차이가 더 벌어질 것 같다.
9. 직접 해보려면
여기까지 읽고 “그래서 뭘로 돌리지”가 궁금해질 텐데, 다행히 대부분은 직접 구현할 필요가 없다. 오픈소스 평가·관측 도구인 Opik에 이 글에서 다룬 지표들이 상당수 내장돼 있다. BLEU, ROUGE, BERTScore 같은 참조 기반 지표부터 G-Eval, LLM 배심원단, 경로 정확도, 대화 단위 평가, 모더레이션까지 들어 있다. 무엇보다 실행 추적 위에서 돌아가서, 아까 말한 “경로를 채점하려면 트레이싱이 먼저 필요하다”는 조건도 같이 해결된다.
함께 보면 좋은 글:
- AI Agent는 더 좋은 프롬프트가 아니라 더 좋은 Harness에서 나온다
- 금융 AI에서의 에이전틱 엔지니어링
- 컨텍스트 압축(Context Compaction): 에이전트에게 전부 넣지 말고 필요한 것만 남기기
참고 자료
- BLEU: a Method for Automatic Evaluation of Machine Translation (Papineni et al., 2002)
- ROUGE: A Package for Automatic Evaluation of Summaries (Lin, 2004)
- BERTScore: Evaluating Text Generation with BERT (Zhang et al., 2020)
- G-Eval: NLG Evaluation using GPT-4 with Better Human Alignment (Liu et al., 2023)
- Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena (Zheng et al., 2023)
- Opik (오픈소스 LLM 평가·관측 도구)
본 글은 2026년 7월 25일 기준 공개 자료를 바탕으로 정리했다. 판정 모델의 편향처럼 연구가 진행 중인 부분은 모델 세대에 따라 양상이 달라질 수 있다.