개념
"정답이 하나"라는 전제가 무너진다
모듈 3에서 배운 테스트 케이스는 "이 입력을 넣으면 정확히 이 값이 나와야 한다"는 전제 위에 있었다. LLM(대형 언어 모델)에게 "이 상품을 한 문장으로 소개해줘"라고 물으면, 매번 표현이 다른 답이 나온다 — 정확히 같은 문장이 아니어도 여러 개가 다 "맞는 답"일 수 있다.
전통적 테스트: calculateDiscount(10000, 0.1) === 9000 (정답이 정확히 하나)
LLM 평가: "이 답변이 정확하고, 도움이 되고, 안전한가?" (여러 답이 동시에 맞을 수 있음)평가(Evaluation)라는 새로운 어휘
이런 이유로 LLM 분야에서는 "테스트(Test)"보다 **"평가(Evaluation, 줄여서 Eval)"**라는 용어를 즐겨 쓴다. 결과가 맞다/틀리다로 딱 떨어지지 않고, 품질을 점수나 등급으로 매기는 접근이 필요하기 때문이다.
평가축 — 무엇을 기준으로 채점하는가
정확성(Accuracy) — 사실관계가 맞는가 (레슨 2의 환각과 직결)
관련성(Relevance) — 질문에 실제로 답하고 있는가
일관성(Consistency) — 비슷한 질문에 비슷한 수준의 답을 주는가
안전성(Safety) — 유해하거나 부적절한 내용을 생성하지 않는가
톤·형식(Tone/Format) — 요구한 형식(예: 200자 이내)을 지키는가모듈 6(레슨 1)에서 배운 것처럼 "심각도"와 "우선순위"를 나눠 판단했듯, LLM 평가에서도 이 축들을 하나로 뭉뚱그리지 않고 각각 따로 점수를 매기는 것이 핵심이다.
평가 방법 세 가지
1. 사람이 직접 평가한다 — 가장 정확하지만 느리고 비용이 크다. 모듈 5의 탐색적 테스팅처럼, 사람의 판단력이 필요한 미묘한 케이스에 적합하다.
2. 규칙 기반으로 자동 평가한다 — "답변에 반드시 특정 단어가 포함되어야 한다", "200자를 넘으면 안 된다" 같은 명확한 규칙은 코드로 자동 검사할 수 있다. 모듈 3에서 배운 테스트 자동화와 가장 가까운 형태다.
3. 또 다른 AI로 평가한다(LLM-as-Judge) — 사람이 매번 채점하기 어려운 규모에서는, 다른 AI 모델에게 "이 답변이 좋은 답변인지 평가해줘"라고 시키는 방법도 쓰인다. 다만 이 방법도 "평가자 역할의 AI가 틀릴 수 있다"는 한계를 가지므로, 사람의 표본 검증(모듈 14 레슨 5의 정기 검토 원칙)과 함께 써야 신뢰할 수 있다.
왜 비결정성이 테스트를 어렵게 만드는가
모듈 10(레슨 4)에서 배운 비결정적 요소를 떠올려보자 — 시간·랜덤 값 같은 비결정성은 코드에서 통제할 수 있었다. 하지만 LLM의 출력 자체가 본질적으로 비결정적이다(레슨 5에서 이걸 어떻게 다루는지 자세히 배운다). 이건 "버그를 없애면 해결되는" 문제가 아니라, LLM이라는 기술 자체의 특성이라는 점이 근본적으로 다르다.
이 모듈의 지도
레슨 1(이 레슨) — 평가란 무엇인가, 전체 지도
레슨 2 — 정확성 축: 환각 탐지
레슨 3 — RAG 시스템의 검색·생성 단계별 검증
레슨 4 — 안전성 축: 편향·공정성
레슨 5 — 비결정성을 통계적으로 다루는 법
레슨 6 — 이 모든 것이 규제·표준과 어떻게 연결되는가실무에서 왜 필요한가
"AI 기능을 테스트해달라"는 요청을 받았을 때, 기존 방식대로 "정답이 뭔지 정하고 그것과 비교"하려 하면 막힌다. 평가라는 새로운 어휘와 접근을 아는 QA는, "이 답변이 정확한가, 관련 있는가, 안전한가"를 각각 나눠 판단하는 프레임을 가지고 시작할 수 있다.