LLM에게 “1~5점으로 평가해줘”를 그만해야 하는 이유: 신뢰할 수 있는 채점 설계법
전략은 단순했습니다. 모델에게 모든 프로젝트 제안서를 1~5점으로 평가하게 하고, 4점 이상이면 예산을 배정한다. 하룻밤 사이에 산더미 같던 제안서가 명쾌한 후보 목록으로 바뀌었습니다. 위쪽에 확실한 승자들, 그 아래로 나머지. 성공처럼 보였죠.
그리고 한 해가 흘렀습니다. 우리가 지원한 4.2점짜리는 조용히 폐기됐고, 넘겼던 3.4점짜리는 “그때 지원했어야 했다”고 후회하는 대상이 됐습니다. 점수는 실제 예산을 완전한 확신을 갖고 정렬해 주었고, 바로 그 확신이 문제였습니다. (설명을 위해 단순화한 복합 시나리오입니다.)
LLM이나 Copilot Studio 에이전트에게 “이걸 1~5점으로 평가해줘”라고 시켜 본 적이 있다면 — 제안서든, 답변이든, 문서든, 고객 응대든, 요약이든 — 아마 이 간극을 보셨을 겁니다. 다행인 점은, “LLM에게 채점을 맡기기”와 “믿을 수 있는 숫자 얻기” 사이에서 선택할 필요가 없다는 것입니다. 그저 숫자를 직접 물어보는 것을 멈추면 됩니다.
왜 1~5점 채점이 실패하는가
두 가지가 동시에 잘못됩니다.
첫째, 척도가 모호합니다. 3점과 4점을 가르는 기준이 무엇인지 아무도 일관되게 말하지 못합니다. 그리고 척도의 중간이 모든 것을 흡수합니다 — 부분적으로 맞음, 괜찮지만 불완전함, 사소한 결함, 좋지만 훌륭하진 않음이 전부 같은 숫자에 안착합니다.
둘째, 심판이 불안정합니다. LLM의 점수는 프롬프트 표현, 항목을 본 순서, 답변 길이, 실행 중인 모델 버전에 따라 흔들립니다. 심지어 자기 모델 계열에서 나온 답변을 은근히 선호하기까지 합니다.
두 실패 양상 모두 LLM-as-judge 연구 문헌에 잘 기록되어 있습니다. 해법은 더 영리한 프롬프트가 아닙니다. LLM에게는 작고 구체적인 것만 판단하게 하고, 최종 숫자는 내가 통제하는 규칙으로 직접 만드는 것입니다.
가장 큰 신뢰성 향상은 더 나은 1~5 프롬프트가 아니다. 하나의 모호한 점수를 여러 개의 이진(binary), 근거 기반 검사로 대체하는 것이다.
1. 점수가 아니라 ‘결정’에서 출발하라
무엇을 측정하기 전에 한 가지에 답하세요. 이 점수로 무엇을 할 것인가? 출시할까 보류할까? 두 모델 중 무엇을 고를까? 이 변경이 실제 진전인가? 어느 부분이 약한가?
당연해 보이지만 대부분이 건너뛰는 단계입니다. 결정이 무엇을 측정할지, 어떻게 채점할지, 어떻게 합산할지를 사실상 결정하기 때문에 중요합니다. 한 문장으로 적으세요.
앞선 프로젝트 심사 사례에서 그 문장은 이렇습니다. “각 제안서를 지원 후보로 올릴지, 재작업으로 되돌릴지, 거절할지 결정한다.” 숫자가 아니라 세 가지 결과입니다.
2. ‘품질’을 몇 개의 구체적 검사로 분해하라
실제로 중요한 몇 개 차원을 먼저 이름 붙이고, 각각을 막연한 품질 평가가 아니라 확인 가능한 구체적 조건으로 바꿉니다. “좋은가?”는 “모든 주장이 실제로 뒷받침하는 출처를 인용하는가?”가 됩니다. 실제 겪은 실패에서 검사를 뽑고, 개수를 적게, 서로 겹치지 않게 유지하며, 결격 사유(dealbreaker) 를 표시합니다.
제안서 사례에서 “품질”은 이렇게 나뉩니다.
- 문제 명확성: 구체적인 사용자·상황·현재 비용과 함께 문제가 서술되어 있는가?
- 근거: 주장이 실제로 존재하는 데이터·참고문헌·선행연구로 뒷받침되는가?
- 실현 가능성: 계획, 팀, 현실적인 일정이 있는가?
- 예산 타당성: 항목 합계가 맞고 계획과 일치하는가?
- 전략 적합성: 이번 펀딩 사이클의 명시된 우선순위에 부합하는가?
- 결격 사유: 필수 섹션 누락, 검증 불가능한 주장, 이해충돌이 있는가?
여섯 개의 겹치지 않는 검사이고, 각각 제안서를 앞에 두고 사람이 답할 수 있는 구체적 질문이며, 그중 하나는 하드 스톱으로 표시되어 있습니다.
3. 각 검사를 ‘가능한 가장 단순한 방법’으로 채점하라
정답인 단일 방법은 없습니다. 아래 사다리를 내려가며 맞는 첫 번째에서 멈추세요.
- 스크립트로 검사 가능한가? 그렇다면 LLM을 아예 쓰지 마세요. 형식 유효성, 필수 필드, 인용 존재 여부, 올바른 도구 호출 — 가장 저렴하고 신뢰할 수 있는 신호이므로 먼저 실행합니다.
- 아니라면, 근거와 함께 예/아니오 질문을 하라. 이것이 기본값입니다. 모호한 판단을 몇 개의 이진 질문으로 쪼개는 것이 가장 큰 신뢰성 향상입니다.
- pass / minor / major / fail 라벨은 아껴 쓰라. 등급 판단이 최종 결정에 정말 중요하고 중간 상태가 명확히 정의된 경우에만. 뉘앙스를 얻는 대신 3-vs-4의 모호함이 일부 되돌아옵니다.
- 두 시스템·버전을 비교한다면? 각각을 따로 채점하지 말고 “A와 B 중 어느 쪽이 더 나은가” 를 물으세요. 1:1 비교가 절대 점수보다 눈에 띄게 안정적입니다.
- 모델이 선택지 전반의 확신도를 보고할 수 있다면, 그 확신도를 점수의 가중치로 쓸 수 있습니다. 모든 값이 상단에 몰릴 때 도움이 됩니다.
같은 여섯 검사를 이 사다리에 올리면 이렇게 됩니다.
- 문제 명확성 → 인용문을 근거로 하는 예/아니오 하나. “실제 사용자를 실제 상황에서, 현재 비용과 함께 서술하는가?”
- 근거 → 인용된 출처(데이터셋·참고문헌·선행연구)를 하나씩 각각 예/아니오로. 한 번에 하나씩 다루면 “근거가 탄탄한가?”라는 감(感)에 의존한 판단을 막습니다.
- 실현 가능성 → 등급 판단이 값어치를 하는 유일한 검사. pass/minor/major/fail로 반환합니다. “계획 완비, 팀 지정, 일정 현실적”과 “팀 없음, 일정 없음”은 진짜로 다르고, 중간 지대에 이름을 붙일 가치가 있습니다.
- 예산 타당성 → LLM이 전혀 필요 없습니다. 스프레드시트가 산수를 합니다.
- 전략 적합성 → 척도가 아니라 비교로 채점. “이번 사이클의 우선순위 중 어디에 가장 잘 부합하는가?”
- 결격 사유 → 혼합. 필수 섹션 누락 같은 하드 실패는 스크립트가, 검증 불가 주장·이해충돌 같은 소프트 실패는 예/아니오 LLM 호출이 잡습니다.
모델 선택은 채점 행동에 영향을 주지만 보편적 최고 심판은 없습니다. 추론(reasoning) 모델은 다단계 근거 대조가 필요할 때 도움이 되지만 여전히 보정이 필요합니다. 후보 심판들을 같은 사람 검토 벤치마크로 테스트해 일치·불일치 패턴을 측정하고, 내 루브릭에 가장 신뢰할 만한 심판을 고르세요.
4. 결과는 ‘적어 둔 규칙’으로 합산하라
중요한 설계 결정 대부분이 여기서 이뤄집니다. 첫 번째 원칙은 라벨을 평균 내지 말 것입니다. pass/fail을 합격률로 평균 내는 것은 괜찮고, 진짜 연속값을 평균 내는 것도 괜찮습니다. 하지만 minor/major/fail 같은 라벨을 3.7로 평균 내는 것이 바로 이 글 첫머리의 함정입니다.
결정에 맞는 합산 규칙을 고르세요.
| 무엇을 결정하는가 | 어떻게 채점 | 어떻게 합산 |
|---|---|---|
| 출시 여부 (릴리스 게이트) | pass/fail 검사, 결격 사유 표시 | 게이팅: 치명적 실패 하나면 나머지가 아무리 좋아도 차단 |
| 변경이 상황을 악화시켰나? | pass/fail, 또는 마지막 정상 버전과 A/B | 임계값(통과 수 미달) 또는 기준선 대비 1:1 비교 |
| 어느 시스템이 더 나은가? | 둘 중 어느 쪽이 나은지 여러 번 질의 | 승률 / 랭킹 |
| 어디가 약한가? | 검사별 결과 | 분리 유지 — 단일 숫자 만들지 않기 |
| 실서비스 품질이 유지되나? | pass/fail 검사 | 합격률 추적, 드리프트 감시 |
어떤 규칙을 고르든 적어 두고, 버전을 매기고, 모델 밖에 두세요. 같은 입력이 항상 같고 검사 가능한 결과를 내도록.
심사 사례의 규칙은 이렇게 정리됩니다. 결격 사유가 하나라도 있으면 그 자체로 거절. 결격 외 5개 검사 중 4개 미만 통과이거나 실현 가능성이 fail이면 재작업. 나머지는 후보 목록.
규칙이 자리 잡으면, 프로젝트마다 다시 쓰지 말고 재사용 가능한 채점 계약(scoring contract) 으로 포장하세요. Copilot Studio에서는 (정적 스크립트 유무와 관계없이) 재사용 가능한 skill, connected agent, 또는 워크플로로 둘 수 있습니다.
5. 모델이 ‘근거를 보여주게’ 하라
모든 판단은 그 뒤의 근거와 함께 도착해야 합니다. 판단을 정당화한 인용문, 필드, 라인. 이것이 점수를 감사 가능(auditable) 하게 만듭니다. 숫자가 이상해 보일 때 미스터리 숫자를 두고 논쟁하는 대신, 왜 그 값이 나왔는지 정확히 볼 수 있습니다.
폐기된 4.2점 제안서의 근거 검사를 예로 들면, pass 하나만으로는 나중에 방어할 수 있는 것이 없습니다. 중요한 것은 기록이 검증한 주장(“평균 처리 시간 32% 단축”), 인용 출처의 인용문, 한 줄 근거를 담고 있다는 점입니다. 에이전트가 이를 검사별 작은 JSON으로 반환하게 하면 감사 추적 전체가 기계 판독 가능해지고, 저장하기 쉽고, 실행 간 diff도 쉬워집니다.
여섯 달 뒤 누군가 거절 결정에 이의를 제기해도, 아무도 모델을 다시 돌리지 않습니다. 리포트를 열면 됩니다.
6. 두 개의 기준으로 검증하라
독립적인 두 가지에 대해 보정하세요. 사람이 검토한 예시 세트, 그리고 다른 모델 계열의 두 번째 LLM 심판. 계열이 다른 것이 중요합니다 — 모델은 자기 부류를 선호하는 경향이 있으니 친척에게 채점을 맡기지 마세요. 사람 라벨 자체가 흔들리는 곳에서는 검토자를 여러 명 두고 일치율을 추적합니다.
두 번째 심판의 목적은 부드러운 평균이 아니라 ‘불일치를 신호로 삼는 것’ 입니다. 갈린 케이스는 사람에게 보내고, 그 분열을 유발한 루브릭 항목이 다음에 날카롭게 다듬을 대상이 됩니다.
솔직한 단서 하나: 이 모든 것은 점수를 재현 가능하고 감사 가능하게 만들 뿐, 자동으로 옳게 만들지는 않습니다. 재현 가능한 숫자도 여전히 엉뚱한 것을 측정하고 있을 수 있습니다. 보정이 그것을 현실에 겨누게 유지하며, 그래서 결코 완전히 끝나지 않습니다.
7. 시간에 따라 지켜보고, 모든 변경을 증명하라
모델과 사용 방식이 바뀌면 점수는 드리프트합니다. 합격률과 분포 형태, 그리고 두 번째 심판이 주기적 사람 스팟체크와 얼마나 일치하는지를 추적하세요. 일치가 떨어지면 재보정합니다.
채점 시스템을 손볼 때마다 고정된 벤치마크로 변경을 검증하세요. 신뢰하는 기준과의 일치가 올라갔는지, 이미 맞히던 항목을 깨뜨리지 않았는지 확인하고, 새 불일치를 벤치마크에 추가해 사각지대를 계속 덮습니다.
아키텍처를 처음 전환할 때(예: 이 파이프라인의 1~5 프롬프트 은퇴)는 둘 다 같은 벤치마크로 돌리고 서로가 아니라 사람 라벨과 비교하세요. 오류를 거짓 통과(false pass) 와 거짓 차단(false block) 으로 나누면 — 이 둘은 대개 비용이 아주 다릅니다.
이것이 채점을 자동화된 에이전트 개선 루프 안에서 쓸 수 있게 만드는 지점이기도 합니다. 심판이 안정적이고 벤치마크가 고정되어 있으면, 에이전트를 손볼 때마다 매번 새로운 1~5 추측이 아니라 진짜 전후 비교를 얻습니다.
마무리
문제는 LLM이 채점을 할 수 있느냐가 아니었습니다. 그 점수가 의미가 있느냐입니다. 단일 1~5 등급은 모호한 척도와 불안정한 심판을 한 덩어리로 묶어 버립니다.
해법은 순서대로 몇 단계입니다. 결정 먼저, 구체적 검사 둘째, 내가 적어 둔 합산 규칙 셋째, 그리고 보정은 처음부터 끝까지. 어느 단계도 그 자체로 영리하지 않지만, 함께 놓이면 하나의 미스터리 숫자를 누군가 짚어 가며 방어할 수 있는 결정으로 바꿉니다.
LLM을 측정 방식의 한 부분으로 다루되, 자(measuring tape) 자체로 다루지 마세요.
이렇게 제안서 점수를 만들면 4.2와 3.4는 더 이상 미스터리 숫자가 아닙니다. 각각이 어떤 검사를 통과하고 실패했는지 보이고, “4점 넘으면 지원”이 드디어 누군가 방어할 수 있는 결정이 됩니다.
출처: Stop Asking an LLM to “Rate This 1-5”: A Better Way to Score with LLMs (MCSCAT Blog — The Custom Engine, Microsoft Copilot Studio Customer Advisory Team, 2026-06-26)
- 원문: https://microsoft.github.io/mcscatblog/posts/better-llm-scoring/
- 원문에서 측정 이론·방법론 전체·각 주장의 근거 연구를 다룬 LLM 1-5 Scoring 백서(PDF) 를 함께 제공합니다.
자세한 내용은 원문을 참조하세요.