# 평가(Evals)
> **이 장에서 배우는 것**
> 개인은 눈으로 보고 판정하지만 조직은 못 합니다. 무엇을 어떻게 재는지, 그리고
> 이게 없으면 무슨 일이 생기는지.
## 개인과 조직의 차이
개인이 쓸 때는 평가가 필요 없습니다. 답을 보고 마음에 안 들면 다시 말하면
됩니다. **판정이 즉시, 무료로 일어납니다.**
조직은 다릅니다.
| | 개인 | 조직 |
|---|---|---|
| 누가 판정 | 본인 | 매번 다른 사람 |
| 언제 | 즉시 | 나중에, 또는 안 함 |
| 기준 | 자기 감 | **사람마다 다름** |
| 하루 건수 | 몇 건 | 수백~수천 건 |
수백 건을 사람이 다 보면 자동화의 이득이 사라집니다. **그래서 판정을 자동화해야
하고, 그게 평가입니다.**
## 평가가 없으면 벌어지는 일
```mermaid
graph TD
A["프롬프트를 고침"] --> B["좋아진 것 같다"]
B --> C["배포"]
C --> D["다른 케이스가 나빠짐"]
D --> E["아무도 모름"]
E --> A
```
**가장 흔한 증상**: "프롬프트를 고쳤더니 이 케이스는 좋아졌는데 저 케이스가
나빠졌다." 그런데 저 케이스를 아무도 안 봐서 모릅니다. 몇 번 반복하면 **어느
버전이 제일 나은지 아무도 말할 수 없는 상태**가 됩니다.
이건 소프트웨어에서 이미 겪은 문제이고, 답도 같습니다 — **회귀 테스트**입니다.
## 무엇을 만드나 — 골든 데이터셋
핵심은 **정답이 붙은 예시 묶음**입니다.
```
케이스 1
입력: "어제 주문한 거 언제 와요? 주문번호 A-12345"
기대: 분류=배송조회, 주문번호=A-12345
케이스 2
입력: "이거 환불되나요"
기대: 분류=환불문의, 주문번호=없음 → 되물어야 함
케이스 3
입력: "지난번에도 늦더니 또 늦네요 진짜"
기대: 분류=불만, 감정=부정, 사람에게 전달
...
```
### 몇 개나 필요한가
**처음에는 20~30개면 시작할 수 있습니다.** 수천 개가 필요한 게 아닙니다.
중요한 건 개수가 아니라 **무엇이 들어 있느냐**입니다.
| 반드시 넣을 것 | 왜 |
|---|---|
| 가장 흔한 케이스 | 전체 품질을 좌우 |
| **실제로 틀렸던 케이스** | 같은 실수 재발 방지 |
| 애매한 경계 케이스 | 판단이 갈리는 지점 |
| 하면 안 되는 케이스 | 예: 개인정보를 요구하면 거절해야 함 |
**두 번째가 핵심입니다.** 운영 중에 틀린 건이 나오면 그걸 데이터셋에 추가합니다.
그러면 데이터셋이 시간이 갈수록 좋아집니다.
## 어떻게 채점하나
세 가지 방식이 있고, 섞어 씁니다.
### 1. 정확히 일치 (가장 확실)
분류나 추출처럼 **정답이 하나**인 경우입니다.
```
기대: 분류=배송조회 실제: 분류=배송조회 → 통과
기대: 주문번호=A-12345 실제: 주문번호=A-1234 → 실패
```
가능하면 이 형태로 만드세요. **채점에 논쟁이 없습니다.**
### 2. 규칙 검사
정답이 하나는 아니지만 **지켜야 할 조건**이 있는 경우입니다.
```
□ 답변이 3문장 이내인가
□ 금액이 언급됐다면 조회 결과와 일치하는가
□ 개인정보를 되묻지 않았는가
□ 정해진 형식(JSON)을 지켰는가
```
### 3. 모델이 채점 (LLM-as-judge)
말투나 적절성처럼 **규칙으로 못 적는 것**은 다른 모델에게 채점을 시킵니다.
```
아래 고객 응대 답변을 평가해주세요.
기준: 정중한가 / 질문에 실제로 답했는가 / 없는 정보를 지어내지 않았는가
각 항목 통과/실패로만 답하세요.
```
> **주의**: 채점하는 모델도 틀립니다. 그래서 **채점 결과를 가끔 사람이
> 표본 검사**해야 합니다. 이걸 안 하면 채점기가 틀린 걸 아무도 모릅니다.
## 언제 돌리나
```
□ 프롬프트를 고칠 때마다 ← 가장 중요
□ 모델을 바꿀 때
□ 도구를 추가/변경할 때
□ 주기적으로 (주 1회)
```
**첫 줄이 핵심입니다.** 프롬프트를 고치고 평가를 안 돌리면 앞의 그림으로
돌아갑니다.
## 실무에서 시작하는 법
거창하게 시작할 필요 없습니다.
```
1주차: 실제 케이스 20개를 모아 스프레드시트에 정리
(입력 / 기대 결과 두 열이면 시작 가능)
2주차: 20개를 돌려서 몇 개 맞는지 센다 → 이게 기준선
3주차: 프롬프트를 고칠 때마다 20개를 다시 돌린다
이후: 틀린 케이스가 나오면 데이터셋에 추가
```
**2주차의 "기준선"이 중요합니다.** 지금 몇 점인지 모르면 좋아졌는지도 모릅니다.
[Phase 1에서 현재 값을 기록하라](/guide/ax-phase1-problem)고 한 것과 같은
원리입니다.
## 하이퍼 애자일과의 연결
[하이퍼 애자일](/guide/ha-micro-sprint)은 "테스트가 완료의 유일한 판정
기준"이라고 말합니다. 그 테스트가 코드에 대해서는 단위 테스트이고, **AI 출력에
대해서는 이 평가**입니다.
둘은 다른 것입니다.
| | 대상 | 판정 |
|---|---|---|
| 단위 테스트 | 코드 동작 | 통과/실패가 명확 |
| **평가(Evals)** | **AI 출력** | **통계적. 90% 통과 같은 형태** |
AI 출력은 매번 조금씩 다르므로 "100% 통과"가 목표가 아닙니다. **"기준선보다
나아졌는가"**가 판정입니다.
## 자주 하는 오해
### "우리는 규모가 작아서 필요 없다"
규모와 무관합니다. 케이스 20개짜리 스프레드시트도 평가입니다. 없으면 프롬프트를
고칠 때마다 **감으로 판단**하게 되고, 그 판단은 자주 틀립니다.
### "평가 만드는 게 일이 더 크지 않나?"
20개 케이스를 모으는 데 반나절이면 됩니다. 그 반나절이 없으면 **"이 버전이 더
낫나?"에 영원히 답할 수 없습니다.** 그리고 그 질문은 앞으로 수십 번 나옵니다.
---
## 확인
**1. 개인은 평가가 없어도 되는데 조직은 필요한 이유는?**
답
개인은 답을 보고 **즉시 무료로 판정**하지만, 조직은 판정하는 사람이 매번 다르고
기준도 다르며 건수가 수백~수천입니다. 사람이 다 보면 자동화의 이득이 사라지므로
판정 자체를 자동화해야 합니다.
**2. 골든 데이터셋에 반드시 넣어야 하는 것 중 가장 중요한 것은?**
답
**실제로 틀렸던 케이스**입니다. 운영 중 나온 오류를 데이터셋에 추가하면 같은
실수가 재발하지 않고, 데이터셋이 시간이 갈수록 좋아집니다.
**3. AI 평가와 단위 테스트의 차이는?**
답
단위 테스트는 통과/실패가 명확하지만, **AI 출력은 매번 조금씩 달라 통계적으로
봅니다.** "100% 통과"가 아니라 "기준선보다 나아졌는가"가 판정 기준입니다.
---
다음은 무엇을 고르고 얼마를 쓰느냐입니다 →
[모델 고르기와 비용](/guide/ai-choosing-models)