Eval 설계 — AI 품질을 숫자로 측정하는 법
한줄 요약
AI를 만드는 것만큼 AI를 측정하는 것도 어렵다 — Eval(평가) 없는 AI 개발은 나침반 없는 항해다.
본문
”느낌상 잘 되는 것 같은데요”의 문제
AI 제품을 만들면 처음엔 모두 이렇게 말한다. “써보니 꽤 괜찮은 것 같아요.” 그런데 이 느낌이 잘못됐다는 걸 발견하는 건 항상 사고가 난 뒤다.
- 프롬프트를 살짝 바꿨더니 성능이 뚝 떨어졌다
- 모델 버전을 업데이트했더니 특정 케이스에서 이상하게 답한다
- 한국어 질문이 영어보다 품질이 낮은데 몰랐다
- 의료 전문 용어가 들어가면 오답률이 3배 높은데 몰랐다
이런 일이 생기는 이유는 단 하나 — Eval(평가) 시스템이 없었기 때문이다.
Eval이란 무엇인가
Eval(Evaluation)은 AI 시스템의 성능을 자동으로 측정하는 테스트 스위트다.
소프트웨어 개발에서 단위 테스트와 비슷하다. 코드를 바꾸면 테스트를 돌려서 뭔가 깨졌는지 확인한다. AI 개발에서도 프롬프트를 바꾸거나 모델을 교체하면 Eval을 돌려서 품질이 유지됐는지 확인한다.
Eval의 3가지 유형
- 정답 기반 Eval (Reference-based)
정답이 명확한 경우. 수학 계산, ICD 코드 분류, 약물명 추출 등.
테스트 케이스:
입력: "심방세동의 ICD-10 코드는?"
기대 출력: "I48"
AI 출력: "I48" → ✅ 정답
AI 출력: "I49" → ❌ 오답정확도(accuracy)를 직접 계산할 수 있어서 가장 단순하고 신뢰할 수 있다.
- 기준 기반 Eval (Criteria-based)
정답이 하나가 아닌 경우. 요약, 설명, 감별진단 등.
AI가 생성한 답을 또 다른 AI(판별 모델)가 기준에 따라 평가한다.
평가 기준:
- 의학적 정확성 (1-5점)
- 완결성: 필수 정보가 빠진 게 없는가 (1-5점)
- 안전성: 위험한 조언이 있는가 (0 또는 1)
- 면책 문구: 적절히 포함됐는가 (0 또는 1)
판별 모델이 각 기준을 채점 → 평균 점수 계산- A/B 비교 Eval (Pairwise)
어느 응답이 더 좋은지 비교한다. 모델 A vs 모델 B, 프롬프트 버전 1 vs 버전 2.
같은 질문에 두 응답을 보여주고:
"A가 더 낫다 / B가 더 낫다 / 비슷하다"
사람이 직접 할 수도 있고, AI 판별 모델이 할 수도 있다.의료 AI Eval 설계 예시
테스트 케이스 구성:
총 500개 케이스
카테고리별:
- 일반 내과 케이스: 150개
- 응급 상황 케이스: 100개
- 약물 관련 케이스: 100개
- 복잡한 다중 질환 케이스: 100개
- 엣지 케이스 (희귀 질환, 소아 등): 50개
각 케이스에 평가 기준:
1. 위험한 오류가 있는가? (가중치 3배)
2. 임상적으로 유용한 정보를 제공했는가?
3. 면책 문구가 적절히 들어갔는가?
4. 응답 형식이 명세를 따르는가?
합격 기준:
- 위험한 오류: 0건 (하나라도 있으면 전체 실패)
- 전체 점수: 85점 이상Eval을 언제 돌리는가
개발 중: 프롬프트를 수정할 때마다 배포 전: CI/CD 파이프라인에 통합해서 자동 실행 운영 중: 실제 사용자 쿼리 샘플을 모아 주기적으로 평가 모델 업데이트 시: OpenAI가 모델 버전을 바꿀 때 반드시 확인
Eval 없이 AI를 운영하면 생기는 일
2023년 실제 사례들:
- Air Canada 챗봇이 없는 환불 정책을 안내해서 법적 책임이 생겼다
- 의료 AI가 훈련 데이터 편향으로 특정 인종에서 오진율이 높았는데 발견이 늦었다
- 법률 AI가 존재하지 않는 판례를 자신 있게 인용했다
모두 Eval이 없어서 문제를 늦게 발견한 사례들이다.
좋은 Eval의 조건
- 재현 가능: 같은 입력에 같은 평가 결과가 나와야 한다
- 대표성: 실제 사용 패턴을 반영한 케이스 구성
- 빠른 실행: 수백 개 케이스를 수 분 내에 돌릴 수 있어야 함
- 버전 관리: 테스트 케이스 자체도 코드처럼 버전 관리
- 명확한 기준: “좋은 답”이 무엇인지 팀 내 합의가 있어야 함
Eval은 한번 만들면 끝나는 게 아니다. 제품이 발전하면서 계속 진화한다. 이것도 하네스 엔지니어링의 일부다.