평가 체계

=> AI관련들 이동

AI 엔지니어링에서 평가 체계를 구축하는 방법

AI 시스템을 개발하다 보면 다음과 같은 판단을 해야 하는 순간이 반복적으로 발생한다.

모델을 바꿨는데 정말 좋아진 것인가?

Prompt를 수정했는데 성능이 향상된 것인가?

Context를 줄였는데 정확도가 떨어지지는 않았는가?

새로운 Tool을 추가했는데 Agent가 실제로 더 일을 잘하는가?

비용은 줄었지만 실패율이 높아진 것은 아닌가?

이러한 질문에 객관적으로 답하기 위해 필요한 것이 평가 체계(Evaluation / Evals)다.

일반적인 소프트웨어에서는 테스트가 성공하면 기능이 정상적으로 동작한다고 판단하기 비교적 쉽다.

하지만 AI 시스템은 상황이 조금 다르다.

동일한 입력에서도 서로 다른 결과가 나올 수 있고, 하나의 작업을 완료하는 방법도 여러 가지일 수 있다.

특히 Agent는 여러 단계에 걸쳐

사용자 요청
    ↓
계획 수립
    ↓
정보 검색
    ↓
Tool 선택
    ↓
Tool 실행
    ↓
중간 결과 판단
    ↓
추가 행동
    ↓
최종 결과

를 수행하기 때문에 단순히 마지막 답변 하나만 보고 시스템 전체의 성능을 판단하기 어렵다.

따라서 AI 엔지니어링에서 평가 체계는

"AI가 정답을 맞혔는가?"

만을 확인하는 것이 아니라

"우리가 기대한 작업을 얼마나 안정적이고 효율적으로 수행했는가?"

를 측정하는 구조라고 볼 수 있다.

---

왜 AI 엔지니어링에서 평가 체계가 중요할까?

초기 AI 기능을 개발할 때는 직접 사용해보는 것만으로도 어느 정도 품질을 판단할 수 있다.

Prompt 수정
   ↓
직접 실행
   ↓
"전보다 괜찮아 보이는데?"

작은 프로젝트에서는 이 방식도 가능하다.

하지만 기능이 많아지고 Agent가 복잡해지면 문제가 생긴다.

예를 들어 Prompt 하나를 수정했더니

문서 작성 성능
90 → 95

로 좋아졌지만

Tool 선택 정확도
92 → 81

로 떨어질 수도 있다.

또는 새로운 모델이 기존보다 더 똑똑해 보이지만

정확도 +3%

Token 사용량 +80%
Latency +50%

가 될 수도 있다.

평가 체계가 없다면 이런 변화를 객관적으로 확인하기 어렵다.

변경
 ↓
느낌으로 판단
 ↓
Production 적용
 ↓
사용자 문제 발생
 ↓
그제야 문제 발견

반대로 평가 체계가 있다면

변경
 ↓
Eval 실행
 ↓
기존 Baseline과 비교
 ↓
Regression 확인
 ↓
배포 여부 판단

이 가능하다.

즉 Eval은 AI 시스템에서 변경에 대한 안전망 역할을 한다.

---

1. 먼저 성공의 기준을 정의한다

평가를 만들기 전에 가장 먼저 해야 할 일은

"무엇을 잘한다고 할 것인가?"

를 정의하는 것이다.

예를 들어 고객지원 Agent가 있다고 하자.

단순히

고객 문의에 잘 답한다.

라고 정의하면 평가하기 어렵다.

대신 성공 조건을 분리할 수 있다.

고객 질문을 올바르게 이해했는가?

정확한 정책을 사용했는가?

필요한 Tool을 올바르게 선택했는가?

고객 문제를 실제로 해결했는가?

잘못된 정보를 생성하지 않았는가?

불필요한 Tool을 호출하지 않았는가?

정해진 권한을 위반하지 않았는가?

이렇게 평가 기준이 구체적으로 정의되어야 측정도 가능하다.

결국 좋은 Eval은 좋은 요구사항에서 시작한다.

모호한 Requirement
        ↓
모호한 Eval

명확한 Requirement
        ↓
검증 가능한 Eval

따라서 평가 체계를 만드는 과정 자체가 요구사항을 명확하게 만드는 역할을 하기도 한다.

---

2. 실제 업무를 기반으로 평가 데이터를 만든다

Eval을 만들 때 임의로 만든 간단한 질문만 사용하면 실제 성능을 제대로 측정하지 못할 수 있다.

예를 들어 Coding Agent를 평가하면서

두 숫자를 더하는 함수를 만들어라.

같은 문제만 사용한다면 실제 Repository에서 복잡한 기능을 수정하는 능력을 알 수 없다.

평가 데이터는 가능한 한 실제 업무에서 가져오는 것이 좋다.

실제 사용자 요청

실제 Bug

실제 장애 사례

실제 고객 문의

실제 개발 Task

과거에 Agent가 실패했던 사례

특히 실패했던 사례는 좋은 Eval 데이터가 된다.

Production 문제
      ↓
원인 분석
      ↓
Eval Case 추가
      ↓
다시는 같은 문제를 놓치지 않도록 함

기존 소프트웨어에서 Bug가 발생했을 때 Regression Test를 추가하는 것과 비슷하다.

Eval 역시 시간이 지날수록 실제 실패 사례가 축적되면서 점점 강해져야 한다.

---

3. 처음부터 거대한 Eval Dataset을 만들 필요는 없다

평가 체계를 구축한다고 하면 수백 개 또는 수천 개의 테스트가 필요하다고 생각하기 쉽다.

하지만 초기에는 작은 평가 세트로도 충분히 시작할 수 있다.

대표 Task 20~50개

정도만 있어도 시스템의 큰 변화를 비교하는 데 도움이 될 수 있다.

초기에는 다음과 같은 Task를 우선 포함하는 것이 좋다.

가장 자주 사용하는 작업

가장 중요한 작업

실패 비용이 높은 작업

과거에 실제로 실패했던 작업

경계 조건이 복잡한 작업

그리고 시스템이 성장하면서 새로운 실패 사례와 기능을 계속 추가한다.

20 Tasks
   ↓
50 Tasks
   ↓
100 Tasks
   ↓
Production Failure 반영
   ↓
지속적으로 증가

즉 Eval Dataset도 코드와 마찬가지로 계속 관리해야 하는 자산이다.

---

4. 가능한 영역은 코드로 평가한다

AI 결과라고 해서 모든 것을 다른 AI에게 평가시킬 필요는 없다.

가능하다면 가장 먼저 결정론적인 평가 방식을 사용하는 것이 좋다.

예를 들어 Coding Agent라면 다음을 사용할 수 있다.

Unit Test

Integration Test

Regression Test

Type Check

Lint

Static Analysis

Security Scan

Build 성공 여부

Tool을 사용하는 Agent라면 실제 시스템 상태를 확인할 수도 있다.

예를 들어

"예약을 취소해줘."

라는 Task를 수행했다면 최종 답변이

"예약을 취소했습니다."

인지 확인하는 것보다

Database

reservation.status == CANCELLED

인지 확인하는 것이 더 신뢰할 수 있다.

즉 가능한 경우

AI가 뭐라고 말했는가?

보다

실제로 어떤 상태가 되었는가?

를 평가하는 것이 좋다.

---

5. 결과가 정형화될 수 있다면 Schema를 검증한다

AI가 구조화된 데이터를 생성하는 경우에는 결과 자체를 Schema로 검증할 수 있다.

예를 들어 Agent의 결과가 다음 형태여야 한다고 하자.

{
  "task": "reservation_cancel",
  "status": "success",
  "reservationId": "R1024"
}

이때 다음을 검증할 수 있다.

JSON 형식인가?

필수 필드가 존재하는가?

status 값이 허용된 값인가?

reservationId 형식이 올바른가?

즉 자연어 결과를 그대로 평가하기보다 가능한 부분은 구조화해서 평가하는 것이 좋다.

Free Text
   ↓
Structured Output
   ↓
Schema Validation

AI 시스템에서 자유도를 줄일 수 있는 영역은 줄일수록 평가도 쉬워진다.

---

6. 코드로 평가하기 어려운 영역은 모델 기반 평가를 사용한다

모든 작업을 정해진 값으로 평가할 수 있는 것은 아니다.

예를 들어 다음과 같은 작업이 있다.

문서 요약

보고서 작성

코드 리뷰

고객 상담

기획안 작성

검색 결과 정리

이런 결과는 하나의 정답만 존재하지 않는다.

이때 다른 LLM을 평가자로 사용하는 Model-based Evaluation을 사용할 수 있다.

예를 들어 보고서를 다음 기준으로 평가할 수 있다.

요구사항을 충족했는가?

중요 내용을 빠뜨리지 않았는가?

근거 없는 내용을 생성하지 않았는가?

논리적 구조가 적절한가?

평가 모델은 각 항목에 점수를 줄 수 있다.

Requirement      5 / 5
Correctness      4 / 5
Completeness     5 / 5
Clarity          4 / 5

하지만 여기서 주의할 점이 있다.

평가자 역시 AI다.

따라서

AI가 AI를 평가했으니까 맞다.

라고 볼 수는 없다.

평가 기준을 명확하게 정의하고 사람 평가와 비교해 평가 모델 자체의 신뢰성을 확인해야 한다.

---

7. Rubric을 명확하게 만든다

모델 기반 평가에서 특히 중요한 것이 평가 기준표(Rubric)다.

예를 들어

"답변 품질을 1~5점으로 평가해."

라고 하면 평가 모델도 기준을 자의적으로 해석할 수 있다.

대신 구체적인 기준을 정의한다.

5점
- 요구사항을 모두 충족
- 사실 오류 없음
- 중요한 내용 누락 없음

4점
- 핵심 요구사항 충족
- 사소한 누락 존재

3점
- 주요 기능은 수행
- 일부 잘못된 내용 존재

2점
- 중요한 요구사항 누락

1점
- 요구사항을 대부분 수행하지 못함

이렇게 하면 같은 결과에 대한 평가 편차를 줄일 수 있다.

좋은 Rubric은 결국

사람이 평가하더라도
비슷한 판단을 내릴 수 있는 기준

이어야 한다.

---

8. 사람 평가를 완전히 없애려고 하지 않는다

자동 평가가 중요하지만 모든 영역을 완전히 자동화할 필요는 없다.

특히 초기 Eval을 만들 때는 사람이 직접 평가하면서 기준을 잡는 과정이 필요하다.

AI 결과
   ↓
Human Evaluation
   ↓
평가 기준 정리
   ↓
Rubric 생성
   ↓
LLM Evaluator 구축

그리고 이후에도 일정 비율의 결과를 사람이 확인할 수 있다.

자동 평가

90%

+

사람 평가

10%

이 과정을 통해 자동 평가가 실제 사람의 판단과 계속 일치하는지 확인한다.

즉 Human Evaluation은 자동화와 경쟁하는 것이 아니라 자동 평가 체계를 보정하는 기준 역할을 한다.

---

9. 한 번의 실행만 보고 평가하지 않는다

LLM은 동일한 입력에서도 결과가 달라질 수 있다.

따라서 한 번 성공했다고 해서 해당 작업을 안정적으로 수행한다고 판단하기 어렵다.

예를 들어 같은 Task를 10번 실행했을 때

성공 10회
실패 0회

와

성공 6회
실패 4회

는 완전히 다른 시스템이다.

둘 다 한 번만 실행했다면 성공할 수도 있다.

따라서 중요한 Task는 여러 번 실행해 성공률을 측정할 수 있다.

Task A

Trial 1 ✅
Trial 2 ✅
Trial 3 ❌
Trial 4 ✅
Trial 5 ✅

Pass Rate = 80%

AI 평가에서는 한 번의 결과보다 성공 확률이 중요하다.

특히 운영 자동화처럼 높은 신뢰성이 필요한 영역에서는 평균 성능뿐 아니라 실패 가능성을 확인해야 한다.

---

10. Capability Eval과 Regression Eval을 구분한다

AI 평가에서 중요한 구분 중 하나가

Capability Eval

과

Regression Eval

이다.

Capability Eval은

"현재 Agent가 어디까지 할 수 있는가?"

를 평가한다.

일부러 어려운 문제를 포함할 수 있다.

Pass Rate = 40%

여도 문제가 아니다.

이 Eval의 목적은 앞으로 개선해야 할 영역을 찾는 것이다.

반면 Regression Eval은

"기존에 잘하던 것을 여전히 잘하는가?"

를 평가한다.

따라서 Pass Rate가 거의 100%에 가까워야 한다.

예를 들어

Capability

복잡한 대규모 Refactoring
새로운 Framework Migration
복잡한 장애 분석

과

Regression

기존 예약 수정
기존 결제 조회
기존 회원 검색

을 별도로 관리할 수 있다.

그리고 Capability Eval에서 안정적으로 성공하기 시작한 Task는 Regression Suite로 이동시킬 수 있다.

어려운 Task

Capability Eval
      ↓
성능 향상
      ↓
안정적으로 성공
      ↓
Regression Eval

이 구조를 통해 새로운 능력을 확장하면서 기존 능력을 잃지 않도록 관리할 수 있다.

---

11. 최종 결과뿐 아니라 실행 과정도 평가한다

Agent는 정답을 만들더라도 좋지 않은 방식으로 작업할 수 있다.

예를 들어 사용자가

특정 파일 하나의 오류를 수정해줘.

라고 요청했다.

Agent가 결국 문제를 해결했지만

30개 파일 수정

20번 Tool 호출

관련 없는 설정 변경

새로운 Library 추가

를 했다면 좋은 결과라고 보기 어렵다.

따라서 Agent에서는 최종 결과뿐 아니라 실행 과정(Trace / Trajectory)도 평가할 수 있다.

필요한 Tool을 사용했는가?

불필요한 Tool 호출이 많지 않았는가?

관련 없는 파일을 수정하지 않았는가?

정해진 권한을 위반하지 않았는가?

과도한 반복을 하지 않았는가?

즉

Outcome Evaluation

과

Process Evaluation

을 함께 볼 수 있다.

다만 실행 경로 자체를 지나치게 고정해서는 안 된다.

AI가 우리가 예상하지 못한 더 좋은 해결 방법을 찾을 수도 있기 때문이다.

따라서

정해진 순서를 그대로 따라라.

보다는

결과는 맞아야 하고
위험한 행동은 하지 않아야 하며
불필요한 행동은 최소화해야 한다.

와 같은 형태가 더 적절하다.

---

12. Agent가 변경한 실제 환경을 평가한다

Agent 평가에서는 최종 텍스트보다 환경 상태가 더 중요할 수 있다.

예를 들어 Coding Agent가

Bug를 수정했습니다.

라고 말하는 것은 중요하지 않다.

실제로

Code 변경
+
Test 성공
+
기존 Test 유지

가 이루어졌는지를 확인해야 한다.

업무 Agent도 마찬가지다.

"환불을 처리했습니다."

가 아니라

Payment Status

REFUNDED

인지 확인한다.

Agent Output

보다

Environment State

를 평가하는 것이다.

Agent가 실제 행동을 수행하는 시스템일수록 상태 기반 평가의 중요성이 높아진다.

---

13. 비용과 속도도 평가에 포함한다

성능이 높다고 해서 항상 좋은 시스템은 아니다.

예를 들어

Model A

Success Rate 95%
Cost $0.10
Latency 8s

와

Model B

Success Rate 96%
Cost $1.20
Latency 45s

가 있다고 하자.

정확도만 보면 Model B가 좋다.

하지만 실제 서비스에서는 Model A가 더 적합할 수도 있다.

따라서 Eval에는 다음과 같은 지표도 함께 포함할 수 있다.

Token Usage

Latency

Model Call 수

Tool Call 수

Retry 횟수

Task당 비용

결국 중요한 것은

가장 높은 정확도

가 아니라

필요한 품질을
적절한 비용과 시간 안에서 달성하는 것

이다.

---

14. Baseline을 만들어 변경 전후를 비교한다

Eval의 가장 큰 장점 중 하나는 변경 전후를 객관적으로 비교할 수 있다는 것이다.

예를 들어 현재 Agent의 기준 성능을 저장한다.

Baseline

Task Success Rate  82%
Regression         98%
Avg Cost           $0.42
Latency            12s
Human Intervention 18%

그리고 새로운 모델을 적용한다.

New Model

Task Success Rate  89%
Regression         97%
Avg Cost           $0.38
Latency            9s
Human Intervention 12%

이렇게 하면

"새 모델이 느낌상 좋아졌다."

가 아니라 실제 데이터를 기준으로 판단할 수 있다.

Prompt 변경, Context 전략 변경, Tool 추가 등도 동일하게 비교할 수 있다.

Before
   ↓
Change
   ↓
Eval
   ↓
Baseline Comparison

AI 시스템 변경은 가능하면 이러한 과정을 거치는 것이 좋다.

---

15. 모델 교체 역시 Eval을 기준으로 결정한다

새로운 모델이 출시되었다고 무조건 교체하는 것은 좋은 방법이 아니다.

새 모델이 일반 Benchmark에서는 더 뛰어나더라도 현재 서비스의 특정 업무에서는 오히려 성능이 떨어질 수 있다.

따라서

새로운 모델 출시
       ↓
우리 Eval Suite 실행
       ↓
기존 Model 비교
       ↓
품질 / 비용 / 속도 분석
       ↓
교체 여부 결정

이라는 구조가 좋다.

Eval Suite가 잘 구축되어 있다면 새로운 모델이 나왔을 때 빠르게 테스트할 수 있다.

반대로 Eval이 없다면

사람이 직접 여러 Task 테스트
      ↓
며칠 또는 몇 주 소요

될 수 있다.

따라서 평가 체계는 모델 선택과 교체 속도에도 직접적인 영향을 준다.

---

16. Context 전략 역시 Eval로 비교한다

Context Engineering에도 정답은 하나가 아니다.

예를 들어 다음 전략을 비교할 수 있다.

A

관련 문서 10개

B

관련 문서 5개
+ Metadata Filtering

C

Vector RAG
+ Ontology

각 전략을 동일한 Eval Dataset에 실행한다.

              Accuracy   Token   Cost

Strategy A      90%       50K    $0.8

Strategy B      92%       30K    $0.5

Strategy C      96%       25K    $0.45

이런 방식으로 Context 전략도 실험할 수 있다.

즉 Eval은 단순히 모델 성능을 측정하는 도구가 아니라 AI 시스템의 모든 구성 요소를 비교하기 위한 공통 기준이 된다.

---

17. Tool 선택 능력도 별도로 평가한다

Agent에서는 어떤 Tool을 선택하는지도 중요한 능력이다.

예를 들어

"이번 주 매출을 알려줘."

라는 요청에서 Agent가

Web Search

를 사용하면 잘못된 선택일 수 있다.

올바른 Tool은

Sales Database

일 수 있다.

따라서 다음도 평가할 수 있다.

올바른 Tool을 선택했는가?

불필요한 Tool을 호출하지 않았는가?

Tool Parameter가 올바른가?

Tool 실행 결과를 올바르게 해석했는가?

특히 MCP나 다양한 외부 Tool을 연결한 Agent에서는 Tool 선택 평가가 중요하다.

Tool이 많아질수록 Agent가 선택해야 할 경우의 수도 증가하기 때문이다.

---

18. Multi-Agent 시스템에서는 Agent별 성능도 평가한다

여러 Agent가 협업하는 시스템에서는 전체 결과만 평가하면 어디서 문제가 발생했는지 알기 어렵다.

예를 들어

Planner
   ↓
Researcher
   ↓
Worker
   ↓
Reviewer

구조가 있다고 하자.

최종 Task 성공률이 떨어졌다.

원인은 여러 가지일 수 있다.

Planner가 계획을 잘못 세움

Researcher가 잘못된 정보를 가져옴

Worker가 구현을 잘못함

Reviewer가 오류를 놓침

따라서 Agent별 Eval을 만들 수 있다.

Planner

계획 정확도
Task 분해 품질

Researcher

검색 정확도
출처 품질

Worker

Task 성공률
Test 통과율

Reviewer

오류 탐지율
False Positive

그리고 마지막으로 전체 시스템의 End-to-End Eval을 실행한다.

Component Eval
       +
End-to-End Eval

두 가지를 함께 사용하면 문제 발생 위치를 찾기 쉬워진다.

---

19. 실패 유형을 분류해서 관리한다

단순히

Success 80%
Failure 20%

만 보는 것으로는 시스템을 개선하기 어렵다.

실패 원인을 분류하는 것이 좋다.

예를 들어

Requirement 이해 실패      5%

Context 검색 실패          4%

Tool 선택 실패             3%

Tool Parameter 오류        2%

추론 오류                  3%

권한 문제                  1%

Timeout                    2%

처럼 분류할 수 있다.

이렇게 하면 가장 큰 문제부터 개선할 수 있다.

Failure
  ↓
Taxonomy
  ↓
원인별 분류
  ↓
가장 큰 실패 원인 개선

AI 시스템에서는 단순한 평균 점수보다 어디서 실패하는지를 아는 것이 더 중요할 때가 많다.

---

20. Production 데이터도 Eval에 다시 반영한다

개발 단계에서 아무리 많은 Eval을 만들어도 실제 사용자가 예상하지 못한 요청을 할 수 있다.

따라서 Production에서 발생한 문제를 다시 Eval Dataset에 추가해야 한다.

Production
    ↓
사용자 실패 사례
    ↓
원인 분석
    ↓
Eval Case 추가
    ↓
수정
    ↓
Regression Suite 포함

이러한 루프를 반복하면 Eval Dataset이 실제 서비스 사용 패턴을 반영하게 된다.

즉 Eval은 출시 전에 한 번 실행하고 끝나는 것이 아니라 지속적으로 성장해야 한다.

---

21. 운영 지표와 Offline Eval을 함께 본다

개발 환경에서 실행하는 Eval만으로 모든 문제를 발견할 수는 없다.

실제 Production에서는

사용자 만족도

Task 완료율

재질문 비율

사람에게 넘겨진 비율

오류율

Latency

Cost

등을 측정할 수 있다.

따라서

Offline Eval

과

Production Monitoring

을 함께 사용하는 것이 좋다.

Offline Eval

배포 전 문제 발견

Production Metric

실제 사용자 환경에서 문제 발견

두 데이터를 연결하면

Eval에서는 좋아졌는데
실사용 만족도는 떨어졌다.

같은 문제도 찾을 수 있다.

---

22. 변경 사항은 A/B Test로 검증할 수 있다

일부 AI 기능은 Offline Eval만으로 어느 쪽이 더 좋은지 판단하기 어려울 수 있다.

이때 실제 사용자 환경에서 두 버전을 비교할 수 있다.

Version A

기존 Prompt

Version B

새로운 Prompt

사용자를 나누어 적용하고

Task 성공률

사용자 만족도

재질문률

Latency

Cost

를 비교한다.

이를 통해 Eval에서 보이지 않았던 실제 사용자 경험 차이를 확인할 수 있다.

다만 위험도가 높은 기능은 Production A/B Test 전에 충분한 Offline Eval과 안전 검증이 선행되어야 한다.

---

23. Eval 자체도 지속적으로 검증해야 한다

Eval 점수가 높다고 무조건 좋은 시스템이라는 의미는 아니다.

평가 기준 자체가 잘못될 수도 있기 때문이다.

예를 들어 Agent가 실제로 좋은 해결책을 만들었는데 Eval이 하나의 특정 방식만 정답으로 인정한다면 실패로 처리될 수 있다.

반대로 Eval의 허점을 이용해 점수만 높이는 결과가 나올 수도 있다.

Eval Score ↑

하지만

실제 사용자 경험 ↓

따라서 Eval 자체도 검토해야 한다.

Task가 너무 쉬워지지 않았는가?

평가 데이터가 실제 사용 패턴을 반영하는가?

정답 기준이 지나치게 좁지 않은가?

평가 모델의 편향은 없는가?

평가 기준을 Agent가 우회하고 있지는 않은가?

사람이 주기적으로 실제 실행 결과와 Trace를 직접 확인하는 과정도 필요하다.

Eval은 절대적인 진실이 아니라 시스템의 품질을 측정하기 위해 우리가 만든 측정 장치이기 때문이다.

---

24. 평가 체계를 CI/CD와 연결한다

Eval이 실제 개발 프로세스와 연결되어야 의미가 있다.

예를 들어

Prompt 변경

Model 변경

Tool 변경

Context Pipeline 변경

Agent Logic 변경

이 발생하면 자동으로 Eval Suite를 실행한다.

Pull Request
      ↓
Unit Test
      ↓
Agent Eval
      ↓
Regression Eval
      ↓
Security Eval
      ↓
기준 만족
      ↓
Merge

기준 이하로 떨어지면 Merge를 막을 수도 있다.

Regression < 99%

→ FAIL

또는

Cost > 기존 대비 30% 증가

→ Review 필요

같은 조건도 사용할 수 있다.

이렇게 되면 Eval이 단순한 분석 도구에서 AI 시스템의 품질 Gate로 발전한다.

---

25. 평가 결과를 하나의 Score로만 보지 않는다

AI 시스템의 성능은 하나의 숫자로 표현하기 어렵다.

예를 들어

Overall Score = 92

만 있으면 무엇이 좋은지 알기 어렵다.

대신 여러 축으로 보는 것이 좋다.

Task Success        94%

Correctness         96%

Tool Selection      91%

Regression          99%

Security            100%

Human Intervention  8%

Average Cost        $0.31

P95 Latency         12s

이렇게 보면 시스템의 강점과 약점을 알 수 있다.

결국 평가 체계는

순위를 만들기 위한 점수

보다는

어디를 개선해야 하는지 알려주는 계기판

에 가깝다.

---

평가 체계의 전체 구조

AI 엔지니어링에서 평가 체계를 정리하면 다음과 같다.

                 실제 요구사항

                      ↓

                 Eval Dataset

          실제 Task / 실패 사례 / Edge Case

                      ↓

                 Agent 실행

                      ↓

        ┌─────────────┼─────────────┐
        │             │             │

     코드 기반      모델 기반       사람 평가
      평가            평가

        │             │             │
        └─────────────┼─────────────┘

                      ↓

                 결과 평가

                      +

                 실행 과정 평가

                      +

                 환경 상태 평가

                      ↓

                  Metrics

        Success Rate
        Regression
        Cost
        Latency
        Tool Usage
        Human Intervention

                      ↓

              Baseline과 비교

                      ↓

            개선 / Regression 확인

                      ↓

                Production 배포

                      ↓

             실제 사용자 데이터

                      ↓

              새로운 Eval 추가

실제로 활용할 수 있는 평가 방법을 정리하면 다음과 같다.

• Unit / Integration / Regression Test
• Schema Validation
• Static Analysis
• State Verification
• Code-based Grader
• Model-based Grader
• Human Evaluation
• Rubric
• Multi-Trial Evaluation
• Capability Eval
• Regression Eval
• Trace / Trajectory Evaluation
• Tool Selection Eval
• Component Eval
• End-to-End Eval
• Failure Taxonomy
• Baseline
• Benchmark
• Production Monitoring
• A/B Test
• Cost / Latency Evaluation
• CI/CD Quality Gate

결국 AI 엔지니어링에서 평가 체계의 목적은

AI에게 점수를 매기는 것

자체가 아니다.

평가 체계가 있어야

모델을 바꿔도 되는지

Prompt 수정이 실제 개선인지

Context 전략이 효과적인지

Tool 추가가 도움이 되는지

Agent 구조가 더 좋아졌는지

를 객관적으로 판단할 수 있다.

그리고 AI 시스템은 비결정적이기 때문에

"한 번 잘 됐다."

보다

"다양한 상황에서 반복적으로 잘 된다."

는 것을 확인하는 것이 중요하다.

AI의 결과를 사람이 매번 직접 확인하는 방식은 시스템의 규모가 커질수록 한계가 있다.

따라서 앞으로의 AI 엔지니어링에서는 사람이 모든 결과를 평가하는 것이 아니라

무엇을 성공으로 볼 것인지 정의하고, 그 기준을 자동으로 측정할 수 있는 평가 체계를 설계하는 것

이 더 중요해진다.

결국 좋은 Eval은 AI를 평가하기 위한 단순한 테스트가 아니라

AI 시스템을 안전하게 변경하고 지속적으로 개선하기 위한 피드백 시스템

이라고 볼 수 있다.

특히 현재 실무에서는 **코드 기반 평가 → 모델 기반 평가 → 사람 평가**를 적절히 섞고, `Capability Eval`과 `Regression Eval`을 분리하며, Agent 특성상 한 Task를 여러 번 실행해 성공률을 보는 방식이 강조되고 있습니다. Anthropic도 Eval Suite를 단위 테스트처럼 지속적으로 관리해야 하는 자산으로 보고 있습니다.