AI 에이전트 평가 지표 7가지: 정확도만 보면 운영에 실패하는 이유

AI 에이전트 평가 지표 7가지: 정확도만 보면 운영에 실패하는 이유

도입부

LLM 답변 정확도가 95%라면 좋은 AI 에이전트일까? 답변은 맞았지만 잘못된 도구를 호출하거나, 같은 환불을 두 번 처리하거나, 한 작업에 과도한 토큰과 시간을 사용했다면 운영 품질은 낮다.

일반 챗봇은 주로 최종 텍스트를 평가하지만 AI 에이전트는 모델 호출, 도구 선택, 인자 생성, 권한 확인, 재시도, 외부 시스템 변경까지 하나의 실행 경로를 만든다. 따라서 최종 답변과 실행 과정, 비용, 지연, 보안을 함께 측정해야 한다.

이번 글에서는 특정 모델 벤치마크가 아니라 실제 서비스에서 사용할 수 있는 일곱 가지 평가 지표를 정리한다.

AI 에이전트 평가는 무엇이 다른가?

“주문을 취소해 주세요”라는 요청을 처리하는 에이전트는 의도 분류, 주문 조회, 취소 가능 여부 확인, 권한 검사, 취소 실행, 결과 설명을 순서대로 수행한다.

마지막 문장이 자연스럽다고 성공한 것은 아니다. 잘못된 주문 ID를 사용했거나 취소 API를 두 번 호출했다면 심각한 실패다. OpenAI의 공식 가이드도 모델 호출, 도구 호출, 가드레일, 핸드오프를 포함한 전체 추적 기록을 평가 대상으로 본다.

평가 지표 7가지

평가 영역	핵심 지표	확인할 질문
1. 결과	작업 성공률	실제 업무가 올바르게 끝났는가?
2. 답변	사실성·완전성	도구 결과를 정확히 설명했는가?
3. 도구	선택·인자 정확도	올바른 도구와 입력을 사용했는가?
4. 경로	단계 수·복구율	루프 없이 오류에서 회복했는가?
5. 지연	p50·p95·p99	일부 요청이 지나치게 느리지 않은가?
6. 비용	성공 작업당 비용	성공 한 건에 실제 얼마가 들었는가?
7. 안전	정책 위반율	권한·개인정보 규칙을 지켰는가?

1. 작업 성공률

작업 성공률 = 성공한 작업 수 / 전체 작업 수

성공은 “좋아 보이는 답변”이 아니라 비즈니스 규칙으로 정의한다. 주문 취소라면 올바른 주문 ID, 취소 가능 상태, API 성공, 중복 실행 없음, 정확한 결과 안내를 모두 만족해야 한다.

2. 최종 답변 품질

최종 답변의 사실성, 완전성, 관련성, 출력 형식을 평가한다. 정답이 명확한 값은 코드로 채점하고 설명 품질은 구체적인 루브릭으로 평가한다.

LLM 평가자를 사용할 수 있지만 장문 선호와 위치 편향이 있을 수 있다. 사람의 정답 라벨과 정기적으로 일치도를 확인해야 한다.

3. 도구 호출 정확도

도구 오류율 = 실패한 도구 호출 수 / 전체 도구 호출 수

getOrder 대신 바로 cancelOrder를 골랐다면 도구 선택 실패다. 도구는 맞지만 다른 사용자의 주문 ID를 넣었다면 인자 정확도 실패다. 도구 이름, 마스킹된 인자, 응답 상태, 호출 순서, 재시도 횟수를 추적해야 한다.

4. 경로 효율과 복구율

같은 작업에 성공해도 도구를 두 번 호출한 에이전트와 열다섯 번 호출한 에이전트의 품질은 다르다. 성공 작업당 모델·도구 호출 수, 동일 도구 반복, 최대 단계 초과율, 오류 후 복구 성공률, 사람 개입률을 본다.

읽기와 쓰기 도구의 재시도 정책을 분리하고 결제·환불·삭제에는 멱등성 키를 사용한다.

5. 지연 시간

평균만 보면 긴 대기를 숨길 수 있다. p50은 일반적인 체감 속도, p95는 SLO와 경보, p99는 외부 API나 반복 재시도의 병목 분석에 활용한다.

전체 시간뿐 아니라 모델 응답, 도구 실행, 큐 대기, 가드레일 검사 시간을 나눠 기록해야 원인을 찾을 수 있다.

6. 성공 작업당 비용

성공 작업당 비용 =
(모델 + 도구 + 인프라 비용) / 성공 작업 수

토큰 단가보다 “주문 문의 한 건 해결 비용”처럼 업무 단위로 본다. 모델 재호출, 실패 작업, 유료 검색, 사람 검토 비용까지 포함해야 한다.

7. 보안·정책 위반율

보안은 평균 점수에 섞지 않고 별도 통과 조건으로 관리한다. 작업 성공률이 높아도 무단 환불이나 개인정보 노출이 한 건 발생하면 배포 중단 기준이 될 수 있다.

프롬프트 인젝션, 권한 없는 도구 호출, 민감정보 노출, 확인 없는 파괴적 작업, 단계·비용 상한 초과를 공격 시나리오로 테스트한다. OWASP도 프롬프트 인젝션, 민감정보 노출, 과도한 자율성, 무제한 자원 소비를 주요 위험으로 제시한다.

Spring Boot에서 최소 지표 수집하기

Micrometer를 사용한다면 실행 결과를 하나의 객체로 모아 기록할 수 있다.

public record AgentRun(
        boolean success,
        long latencyMs,
        double cost,
        int toolCalls,
        int toolFailures,
        boolean policyViolation
) {
}

아래 코드는 미리 등록한 Counter, Timer, DistributionSummary 필드에 실행 결과를 기록하는 핵심 부분이다.

public void record(AgentRun run) {
    total.increment();

    if (run.success()) {
        success.increment();
    }
    if (run.policyViolation()) {
        policyViolations.increment();
    }

    toolCalls.increment(run.toolCalls());
    toolFailures.increment(run.toolFailures());
    latency.record(run.latencyMs(), TimeUnit.MILLISECONDS);
    cost.record(run.cost());
}

userId, 전체 프롬프트, traceId처럼 종류가 계속 늘어나는 값을 메트릭 태그로 넣으면 시계열 수가 폭증한다. 메트릭에는 agentType, modelFamily, environment, result처럼 제한된 값만 사용하고 상세 경로는 개인정보를 제거한 추적 로그에 저장한다.

실무 평가 흐름

배포 전 평가셋에는 세 종류의 사례를 섞는다.

• 일반 사례: 실제 트래픽에서 자주 발생하는 요청
• 경계 사례: 값 누락, 긴 대화, 애매한 도구 응답
• 공격 사례: 프롬프트 인젝션, 권한 상승, 민감정보 요청

배포 후에는 지연, 비용, 도구 오류, 사용자 피드백, 사람 개입률을 관측한다. 새 장애와 근접 사고는 개인정보를 제거한 뒤 회귀 평가셋에 추가한다.

운영 실패 수집 → 익명화 → 평가 사례화
→ 프롬프트·도구 수정 → 회귀 평가 → 점진적 배포

NIST 생성형 AI 위험관리 프로필도 배포 전 평가에서 끝내지 않고 운영 중 성능, 오류, 사고, 사용자 피드백을 지속적으로 추적하도록 권고한다.

품질 게이트를 분리한다

모든 지표를 하나의 평균 점수로 합치면 안전 실패가 높은 정확도에 가려질 수 있다.

agent:
  quality-gate:
    task-success-rate: 0.95
    tool-argument-accuracy: 0.98
    p95-latency-ms: 8000

  safety-gate:
    unauthorized-action-rate: 0
    sensitive-data-leak-rate: 0

수치는 구조를 설명하기 위한 예시다. 실제 기준은 서비스 위험도와 비용에 맞춰 정해야 한다.

자주 하는 실수

• 모델 벤치마크를 서비스 품질로 본다. 실제 도구와 트래픽 분포로 평가해야 한다.
• 성공 사례만 테스트한다. 값 누락, 타임아웃, 공격 입력을 포함해야 한다.
• 최종 답변만 저장한다. 도구 선택과 인자, 재시도, 가드레일 결과가 필요하다.
• LLM 평가자를 그대로 믿는다. 사람 라벨과 정기적으로 교정한다.
• 평균값만 본다. p95·p99와 실패 작업 비용을 함께 본다.
• 프롬프트, 모델, 도구를 동시에 바꾼다. 한 번에 하나씩 변경해 비교한다.

핵심 요약

• 에이전트는 최종 답변과 전체 실행 경로를 함께 평가한다.
• 작업 성공률, 답변, 도구, 경로, 지연, 비용, 안전을 측정한다.
• 비용은 토큰 단가보다 성공 작업당 비용으로 계산한다.
• 안전 지표는 평균과 분리된 하드 게이트로 관리한다.
• 운영 장애를 익명화해 회귀 평가셋에 계속 추가한다.

마무리

에이전트는 답을 생성하는 모델이면서 실제 시스템을 움직이는 실행기다. 먼저 핵심 업무 하나의 성공 조건을 코드로 정의하고 실패 실행의 전체 경로를 남겨 보자.

LLM 환각 대응은 답변 사실성 평가와 연결되고, Spring Boot MCP 서버 만들기는 도구 호출 추적의 기반이 된다. 모델을 고르기 전에는 GPT-5.6 vs Claude Fable 5 비교보다 자체 평가 결과를 우선해야 한다.

공식 자료:

• OpenAI 에이전트 워크플로 평가
• OpenAI 평가 설계 모범 사례
• NIST 생성형 AI 위험관리 프로필
• OWASP LLM 애플리케이션 Top 10