성공률 90%인데 AI 에이전트가 실패한다: 배포 전 꼭 알아야 할 평가(Evals)의 함정

 

AI 에이전트 평가(Evals)는 그럴듯한 답변에 점수를 주는 작업에서 끝나지 않는다. 도구를 제대로 호출했는지, 실제 업무 상태를 바꿨는지, 같은 일을 반복해도 안정적으로 성공하는지까지 확인해야 한다. 성공률 90%라는 숫자도 표본과 계산법에 따라 전혀 다른 의미가 된다. 이 글은 AI 에이전트 성능 평가를 처음 설계하는 개발자를 위해 테스트 데이터셋, 결과 검증, LLM-as-a-Judge, 회귀 테스트와 배포 기준을 하나의 흐름으로 정리한다.

 

분석 기준일은 2026년 11월 1일이다. Anthropic의 에이전트 평가 원문과 국내 인포그랩 기술 블로그의 실무 사례를 참고하되, 아래 환불 업무와 수치는 설명을 위한 가상 예제다. 특정 제품을 직접 벤치마크해 얻은 결과나 업계 평균으로 해석하면 안 된다. 핵심 질문은 하나다. “AI가 완료했다고 말하는 것과, 우리 시스템에서 업무가 완료된 것은 같은가?”

 

핵심 요약

• 평가는 최종 답변, 도구 실행 기록, 외부 시스템의 최종 상태를 함께 확인해야 한다.

• 여러 번 시도해 한 번 성공한 비율과 매번 성공한 비율은 서로 다른 지표다.

• 코드로 확정할 수 있는 조건은 코드로 검사하고, 표현 품질은 명확한 기준을 갖춘 모델 평가와 사람 검토로 보완한다.

• 평균 점수가 좋아져도 권한 위반이나 중복 결제 같은 치명적 실패가 늘었다면 배포를 막을 수 있어야 한다.

 

목차

1. 성공률 90%가 업무 신뢰도를 보장하지 않는 이유

2. AI 에이전트 평가의 최소 단위와 최종 상태

3. 테스트 데이터셋을 만드는 방법

4. 코드·모델·사람 평가자의 역할

5. pass@k와 pass^k를 읽는 법

6. 환불 에이전트 평가 설계 예시

7. 실험 환경과 회귀 테스트

8. 비용·지연·운영 품질과 배포 기준

9. 실무 체크리스트와 자주 묻는 질문

 

1. 성공률 90%가 업무 신뢰도를 보장하지 않는 이유

 

데모에서는 주문 번호를 입력하자 AI가 정책을 확인하고 환불을 처리한 뒤 친절한 안내문을 만든다. 도구 응답에도 성공 표시가 있다. 그런데 정산 장부를 열어 보니 환불 내역이 없거나, 같은 주문에 환불이 두 번 기록돼 있다면 어떨까. 사용자에게 보이는 대화는 매끄러워도 업무는 실패한 것이다. 에이전트는 문장을 생성하는 동시에 외부 시스템에 행동을 남기므로 두 층을 분리해서 평가해야 한다.

 

가령 100개 테스트 가운데 90개를 통과했다고 하자. 이 수치만으로는 정상 요청만 모았는지, 예외 상황이 포함됐는지, 모든 테스트를 한 번씩 돌렸는지 알 수 없다. 10번 재시도해 한 번이라도 성공한 과제를 성공으로 셌을 수도 있다. 읽기 전용 검색 에이전트와 결제를 실행하는 에이전트에 동일한 성공 정의를 쓰기도 어렵다. 숫자의 의미를 알려면 분모, 시도 횟수, 성공 조건, 실패의 심각도를 함께 공개해야 한다.

 

업무별 분포도 중요하다. 쉬운 배송 조회 90건을 모두 통과하고 복잡한 환불 10건을 전부 실패해도 전체 성공률은 90%다. 하지만 환불 기능을 도입하려는 팀에게는 사실상 쓸 수 없는 결과다. 전체 평균 옆에 업무 유형별 성공률을 두고, 필요한 경우 언어·문서 길이·도구 오류 유형별로 나눠 봐야 한다. 샘플이 적은 구간은 점수가 높더라도 불확실하다고 표시하는 편이 정직하다.

 

평가의 출발점은 “우리 모델은 얼마나 똑똑한가”보다 “사용자가 맡긴 일을 어떤 조건에서 끝냈다고 볼 것인가”에 있다. 이 질문에 답하지 못한 채 모델만 교체하면 품질 개선을 확인하기 어렵다. 프롬프트 엔지니어링 역시 마찬가지다. 문구를 더 엄격하게 바꾸어 한 사례를 고쳤더라도 다른 요청을 과도하게 거절할 수 있다. 개선을 주장하려면 기존에 되던 일과 새로 고친 일을 동시에 확인해야 한다.

 

2. AI 에이전트 평가의 최소 단위와 최종 상태

 

Anthropic은 에이전트 평가를 설명하면서 task, trial, grader, transcript, outcome을 구분한다. task는 입력과 성공 조건을 갖춘 하나의 과제이고, trial은 그 과제를 실행한 한 번의 시도다. grader는 점수를 매기는 검사 로직이다. transcript는 도구 호출과 응답 등을 포함하는 실행 기록이며, outcome은 실행이 끝났을 때 환경에 남은 실제 상태다. 단어를 외우기보다 이 구분이 어떤 실수를 막는지 이해하면 된다.

 

예를 들어 task는 “고객 A의 주문 B를 정책에 맞게 환불하라”다. trial마다 초기 데이터는 같게 복원한다. 실행 기록에는 고객 확인 도구, 주문 조회 도구, 환불 도구의 호출과 응답이 담긴다. 마지막 답변이 “환불했습니다”라고 하더라도 outcome은 별개다. 테스트 장부에 해당 고객과 주문에 맞는 환불 레코드가 존재하는지, 금액이 맞는지, 중복이 없는지를 조회해야 업무 성공을 확정할 수 있다.

 

여기서 결과 검증과 과정 검증은 경쟁 관계가 아니다. 결과가 맞았지만 권한을 넘겨 다른 고객의 데이터를 열람했다면 통과시켜서는 안 된다. 반대로 결과가 맞고 정책도 지켰는데 참고 구현과 도구 호출 순서가 조금 다르다는 이유만으로 탈락시킨다면 평가가 지나치게 경직된 것이다. 반드시 지켜야 할 제약과 구현의 자유를 구분해야 한다. “인증 이후에만 환불 실행”은 제약이고, 서로 독립적인 조회의 순서는 자유일 수 있다.

 

평가 대상도 모델 하나로 한정하지 않는 편이 좋다. 실제 성능은 시스템 프롬프트, 검색 결과, 도구 스키마, 실행기, 메모리, 재시도 정책이 함께 만든다. 모델이 같아도 도구 설명을 바꾸면 선택 정확도가 달라지고, 검색 문서가 바뀌면 판단 근거가 달라진다. 따라서 실험에는 모델 버전뿐 아니라 에이전트 설정과 도구 버전도 기록한다. 그래야 점수 변화가 어디에서 왔는지 추적할 수 있다.

 

최종 상태를 읽을 수 없는 환경도 있다. 외부 서비스가 확정 결과를 늦게 알려 주는 경우다. 이때는 접수 완료와 처리 확정을 구분하고, 상태 확인 기한을 정해야 한다. 기한 안에 확인되지 않은 결과를 성공으로 올리기보다 미확정으로 따로 집계한다. 사용자가 원하는 것이 접수인지 실제 완료인지도 명세에 적는다. 평가가 애매한 이유가 모델이 아니라 업무 요구사항의 모호함인 경우가 생각보다 많다.

 

3. 테스트 데이터셋은 실제 실패에서 시작한다

 

처음부터 수천 개의 테스트가 있어야 하는 것은 아니다. Anthropic은 실제 실패에서 뽑은 20~50개의 단순한 과제로도 출발할 수 있다고 설명한다. 이는 작은 데이터셋이면 어떤 시스템이든 충분히 검증된다는 뜻이 아니다. 초기에는 큰 결함을 찾기 쉽고 변경 효과가 커서 작은 세트도 유용하다는 취지다. 성능이 높아지고 차이가 작아질수록 더 넓고 어려운 평가와 반복 측정이 필요해진다.

 

수집할 재료는 이미 가까이에 있다. 개발자가 출시 전에 손으로 확인하는 요청, 고객 문의에서 자주 등장하는 실패, 검색이 빈 결과를 반환했던 사례, 도구 인자를 잘못 추출했던 로그가 좋은 출발점이다. 개인정보나 비밀정보는 제거하고 업무 구조를 유지한 예제로 재작성한다. 단순히 이름을 지우는 것만으로 재식별 위험이 사라지는 것은 아니므로 평가에 꼭 필요한 속성만 남기는 것이 좋다.

 

가상의 환불 업무라면 정상 주문, 환불 기한 직전과 직후, 이미 환불된 주문, 부분 환불, 잘못된 주문 번호, 다른 고객의 주문, 정책 문서 부재, 조회 도구 시간 초과를 넣을 수 있다. “환불해 줘”처럼 정보가 부족한 입력도 필요하다. 이 경우에는 즉시 실행보다 필요한 식별 정보를 물어보는 것이 정답일 수 있다. 모든 테스트의 정답을 실행 성공으로 통일하면 무리하게 행동하는 에이전트를 보상하게 된다.

 

각 과제에는 초기 상태, 사용자 입력, 허용 도구, 기대 결과, 금지 행동, 실행 제한을 기록한다. 기대 결과는 하나의 정답 문장으로만 두지 않는다. “환불 요청을 생성하지 않고 기한 초과 사유를 설명한다”처럼 상태 조건과 답변 조건으로 나눈다. 필요하면 허용 가능한 대안도 적는다. 전문가 두 사람이 같은 기록을 보고 서로 다른 결론을 내린다면 과제와 기준부터 다시 다듬어야 한다.

 

개발용 세트와 최종 확인용 세트도 나눈다. 개발 과정에서 자주 본 실패는 수정에 유용하지만 그 문제에 맞춘 프롬프트를 만들기 쉽다. 계속 같은 세트에 맞춰 최적화한 점수를 일반적인 능력으로 오해하면 안 된다. 별도로 남겨 둔 과제, 새롭게 수집한 운영 사례, 표현만 바꾼 변형 사례를 함께 확인한다. 단, 표현 변형이 새로운 의미를 만들지 않았는지 사람이 살펴야 한다.

 

정상과 예외 비율은 목적에 맞춰 정한다. 운영 분포를 추정하려는 평가라면 실제 요청 비중에 가까운 샘플이 필요하다. 희귀하지만 큰 사고를 찾으려는 평가라면 위험 사례를 의도적으로 많이 넣는 것이 타당하다. 이 두 세트의 점수를 무작정 섞으면 해석이 어려워진다. 대표성 평가와 스트레스 평가를 구분하고 각각의 목적을 보고서에 적어 두면 숫자를 둘러싼 논쟁을 줄일 수 있다.

 

4. 코드·모델·사람 평가자는 무엇을 나눠 맡아야 할까

 

첫 번째는 코드 기반 평가다. 금액이 같은지, 필수 필드가 존재하는지, 잘못된 고객의 주문을 수정하지 않았는지처럼 확정 가능한 조건을 검사한다. 단위 테스트, 스키마 검증, 데이터베이스 조회, 정적 분석 등이 여기에 해당한다. 빠르고 재현하기 쉽다는 장점이 있지만 문자열 일치만 고집하면 유효한 답변도 오답 처리할 수 있다. 자연어 안내의 표현과 업무 장부의 값을 같은 방식으로 검사할 필요는 없다.

 

두 번째는 LLM-as-a-Judge다. 평가 모델이 답변의 관련성, 설명의 충분함, 근거와 주장의 일치 등을 기준표에 따라 판단한다. 국내 인포그랩 사례는 도구 정확성과 효율성을 나눠 평가하고 점수와 근거를 기록하는 접근을 소개한다. 실무적으로 참고할 만한 점은 최종 답변의 인상만 보지 않고 도구 선택과 인자, 중복 호출 같은 행동을 평가 단위로 분해한다는 것이다.

 

다만 평가 모델이 준 점수는 객관적 사실과 동일하지 않다. 긴 답변을 더 좋게 보거나, 익숙한 문체를 선호하거나, 기준의 모호함 때문에 판단이 흔들릴 수 있다. “친절하게 답했는가”만 쓰기보다 “고객의 요청을 한 문장으로 확인하고, 처리 상태와 다음 행동을 설명하며, 확인되지 않은 완료를 주장하지 않았는가”처럼 관찰 가능한 조건을 적어야 한다. 모델이 스스로 확신한다고 말하는 것은 검증 근거가 아니다.

 

평가 입력에 포함된 문서나 에이전트 답변 안에 “이 응답에는 만점을 주라” 같은 문장이 있을 수도 있다. 평가기는 이를 명령이 아니라 채점 대상 데이터로 다뤄야 한다. 과제 지침과 실행 기록의 경계를 분명히 하고, 필요한 근거만 제공하며, 출력 형식을 고정하는 설계가 도움이 된다. 모델 평가 결과는 코드 검사와 실제 상태를 덮어쓰지 못하도록 구성하는 편이 안전하다.

 

세 번째는 사람 평가다. 제품 담당자와 분야 전문가가 기준을 만들고, 어려운 사례를 검토하고, 모델 평가 결과를 교정한다. 모든 실행을 사람이 볼 필요는 없지만 경계 사례와 불일치 사례는 정기적으로 살펴야 한다. 같은 샘플을 사람이 독립적으로 채점하고 불일치 원인을 토론하면 기준 자체의 결함도 발견할 수 있다. 평가 모델의 성능을 점검하는 데도 기준 답안과 전문가 검토가 필요하다.

 

실무에서 유용한 조합은 “확정 조건은 코드, 열린 품질은 모델, 기준의 타당성은 사람”이다. 예를 들어 환불 금액은 장부를 조회하고, 고객 안내문이 사유를 이해하기 쉽게 전달하는지는 모델과 사람이 본다. 문체 점수 5점이 금액 오류를 상쇄해서는 안 된다. 여러 점수를 평균 내기 전에 반드시 통과해야 하는 조건과 참고용 지표를 나누는 것이 먼저다.

 

5. pass@k와 pass^k: 비슷해 보여도 반대 방향의 숫자

 

pass@k는 k번의 시도 가운데 적어도 한 번 성공하는지를 보는 지표다. 여러 후보 중 하나를 골라 쓰는 환경에서 유용할 수 있다. 반면 pass^k는 k번 모두 성공하는 일관성을 본다. Anthropic 원문도 이 차이를 설명하며, 고객이 매번 믿고 맡겨야 하는 에이전트에서는 반복 성공의 중요성을 강조한다. 두 지표는 k가 1일 때 같지만 시도 횟수가 커지면 서로 다른 이야기를 한다.

 

이해를 위해 매 시도의 성공 확률이 90%로 같고 서로 독립이라고 가정하자. 세 번 중 적어도 한 번 성공할 확률은 1−(1−0.9)의 3제곱, 즉 99.9%다. 세 번 모두 성공할 확률은 0.9의 3제곱으로 72.9%다. 같은 기본 성공률에서도 “한 번쯤 된다”와 “항상 된다” 사이에는 큰 차이가 생긴다. 이 계산은 설명용 확률 모형이지 실제 서비스에서 측정한 수치가 아니다.

 

더 주의할 점은 현실의 실패가 독립적이지 않을 수 있다는 것이다. 같은 누락 문서, 같은 권한 설정, 같은 도구 오류 때문에 여러 시도가 함께 실패할 수 있다. 과제마다 난이도도 다르다. 따라서 전체 평균 성공률 하나를 공식에 대입한 결과를 실제 pass@k로 발표하면 안 된다. 각 과제를 반복 실행한 관측값과 집계 방법을 명시하고, 단순 확률 예시는 가정이라고 표시해야 한다.

 

재시도를 더 많이 하면 품질이 높아졌다고 주장하기도 쉽다. 하지만 사용자가 한 번 요청했을 때 내부에서 몇 번 시도했는지, 그 과정에서 비용과 시간이 얼마나 늘었는지를 같이 봐야 한다. 결제나 환불처럼 외부 상태를 바꾸는 도구는 무턱대고 재시도하면 중복 작업을 만들 수 있다. 평가의 재실행은 초기 상태가 복원된 별도 시도이고, 운영에서의 재시도는 같은 업무 안의 복구 행동이라는 차이도 분명히 해야 한다.

 

보고서에는 최소한 단일 시도 성공률, 반복 시도 수, 과제 수, 업무 유형별 결과를 함께 적는다. 중요한 과제는 반복 결과도 펼쳐 본다. 평균이 같은 두 시스템이라도 하나는 모든 과제에서 가끔 실패하고, 다른 하나는 특정 과제를 항상 실패할 수 있다. 사용자에게 미치는 영향과 개선 방향은 전혀 다르다. 숫자 하나로 모델 순위를 정하기 전에 실패가 어디에 모이는지 확인해야 한다.

 

6. 가상 환불 에이전트로 보는 평가 설계

 

설계 예제를 구체화해 보자. 고객은 “어제 산 주문 R-102의 미개봉 상품을 환불해 주세요”라고 요청한다. 테스트 환경에는 고객 식별 결과, 주문 내역, 환불 정책, 결제 상태가 들어 있다. 허용된 업무는 해당 고객의 주문을 조회하고 조건이 맞으면 정해진 금액을 한 번 환불하는 것이다. 실제 고객 결제망 대신 격리된 테스트 장부와 모의 도구를 사용한다고 가정한다.

 

성공 조건은 네 가지로 나눌 수 있다. 첫째, 확인된 고객과 주문의 소유자가 같다. 둘째, 정책상 환불 가능한 요청이다. 셋째, 테스트 장부의 금액과 상태가 기대값과 일치하고 중복 기록이 없다. 넷째, 최종 안내가 확인된 결과와 일치한다. 이 가운데 하나라도 깨지면 업무 성공으로 집계하지 않는다. 친절한 안내가 필요하더라도 실제 환불을 대신하지는 않는다.

 

실행 기록 검사는 별도로 둔다. 환불 전에 필요한 조회와 확인을 했는지, 요청 범위를 벗어난 고객을 조회하지 않았는지, 시간 초과 뒤 결과를 확인했는지 본다. 반드시 특정 도구를 정확히 한 번 호출하라고 강요할 필요는 없다. 도구 구성에 따라 정상적인 경로가 여러 개일 수 있기 때문이다. 다만 환불 실행이 중복되지 않아야 한다는 조건은 결과와 과정 양쪽에서 확인할 수 있다.

 

오류 주입 시나리오도 추가한다. 환불 도구가 요청을 처리했지만 응답만 시간 초과됐다고 가정하면 에이전트는 어떻게 해야 할까. 바로 같은 환불을 다시 실행하는 대신 처리 상태를 조회하거나, 도구가 지원하는 중복 방지 키를 활용하는 것이 합리적이다. 구체적인 정답은 서비스 계약에 따라 다르므로 평가자는 도구의 동작 명세를 알아야 한다. 가짜 오류 상황을 만들 때도 실제 API 의미와 맞아야 한다.

 

또 다른 시나리오는 정책 문서에 근거가 없는 경우다. 이때 “환불 가능”을 추측하는 것보다 확인이 필요하다고 설명하고 적절히 이관하는 것이 성공일 수 있다. 모델이 답을 보류한 비율만 높다고 나쁘게 평가하면 추측을 보상할 위험이 있다. 정당한 보류와 불필요한 거절을 구분해야 한다. 정상적인 요청을 지나치게 자주 이관하는 시스템도 업무 자동화의 목적을 충분히 달성하지 못한다.

 

각 시도 뒤에는 테스트 장부를 초기 상태로 복원한다. 환불된 주문을 그대로 둔 채 다음 시도를 돌리면 두 번째 실행은 “이미 환불됨”을 만나 첫 번째와 다른 과제가 된다. 계정 권한, 시간대, 현재 시각, 문서 버전도 가능하면 고정한다. 재현 가능한 환경 없이 반복 실행만 늘리면 모델의 변동성과 환경의 변동성이 뒤섞인다. 그러면 프롬프트를 바꾼 효과를 해석할 수 없다.

 

7. 좋은 평가도 환경이 흔들리면 거짓말한다

 

실제 도구에 가까운 환경과 재현성 사이에는 균형이 필요하다. 모의 도구는 빠르고 안정적이지만 실제 서비스의 지연과 예외 응답을 놓칠 수 있다. 실제 연동 테스트는 현실적이지만 비용과 외부 장애의 영향을 받는다. 초기에는 고정된 환경에서 원인을 좁히고, 이후 별도 통합 테스트로 실제 연결을 확인하는 식으로 층을 나눌 수 있다. 하나의 테스트가 모든 목적을 동시에 해결할 필요는 없다.

 

평가 실패를 곧바로 에이전트 실패로 결론 내리지 않는 것도 중요하다. 테스트 계정이 만료됐거나, 평가 서버가 중단됐거나, 정답 데이터가 잘못됐을 수 있다. 실행 실패, 환경 실패, 채점 실패를 구분해 기록한다. 그렇다고 불리한 결과를 임의로 환경 탓으로 빼서는 안 된다. 제외 규칙을 미리 정하고 재실행 조건과 제외 건수를 남겨야 수치의 신뢰도를 유지할 수 있다.

 

정답 경로를 지나치게 좁게 만드는 문제도 있다. 사용자가 원하는 상태에 도달했고 금지 행동도 하지 않았는데 사람이 예상한 호출 순서를 따르지 않았다고 탈락시키면 유효한 해결책을 막는다. 반대로 결과만 맞으면 모두 통과시키면 과도한 데이터 접근이나 불필요한 쓰기를 놓친다. 최종 상태, 필수 제약, 효율성을 각각 평가하면 이 두 극단을 피하는 데 도움이 된다.

 

평가 모델과 기준도 버전 관리 대상이다. 같은 에이전트 출력을 새 평가 모델로 채점했더니 점수가 올랐다면 에이전트가 좋아졌다고 말할 수 없다. 에이전트 설정을 바꾼 실험과 평가자를 바꾼 실험은 분리한다. 평가 기준을 개선할 때는 보관한 실행 기록을 새 기준으로 다시 채점해 차이를 확인한다. 기존 점수와 새 점수가 같은 척도인지 먼저 점검해야 한다.

 

테스트 데이터에 운영의 변화를 반영하는 것도 필요하다. 환불 정책이 개정됐다면 과거의 정답이 지금은 오답일 수 있다. 정책 시행일과 문서 버전을 과제에 묶어 두고, 현재 정책을 평가하는 세트와 과거 기록 재현용 세트를 구분한다. 데이터셋이 커지는 것보다 어떤 조건을 검증하는지 설명할 수 있는 상태가 더 중요하다. 오래된 테스트를 무조건 유지하는 것이 품질 관리는 아니다.

 

8. 회귀 테스트는 프롬프트 수정의 대가를 보여 준다

 

능력 평가는 아직 잘 못하는 일을 얼마나 해낼 수 있는지 묻는다. 회귀 평가는 전에 잘하던 일을 여전히 해내는지 묻는다. Anthropic은 이 두 목적을 구분하고, 능력 평가에서 충분히 안정된 과제를 회귀 세트로 옮기는 접근을 설명한다. 새 기능을 추가할 때는 개선된 과제의 점수만 보지 말고 기존 기능의 점수도 함께 비교해야 한다.

 

예를 들어 도구 사용을 적극적으로 유도하는 프롬프트를 추가하면 최신 정보 검색은 좋아질 수 있다. 하지만 대화 안에 이미 있는 정보까지 다시 검색하면서 비용과 지연이 증가할 수 있다. 반대로 호출 수를 줄이라는 지침을 강화하면 필요한 상태 확인을 생략할 수 있다. 한 지표만 최적화하면 다른 지표가 손해를 볼 수 있으므로 정확성, 제약 준수, 비용, 지연을 함께 관찰한다.

 

비교 실험은 가능한 한 같은 과제와 같은 환경에서 수행한다. 기준 버전과 후보 버전의 차이를 고정하고, 프롬프트와 검색 방식과 모델을 한꺼번에 바꾸지 않는 편이 원인 분석에 유리하다. 긴급 수정처럼 여러 요소를 함께 바꿔야 한다면 변경 목록을 남긴다. 그다음 실패 사례별로 어떤 변화가 영향을 줬는지 추가 실험으로 좁혀 갈 수 있다.

 

차이가 작은 결과는 과장하지 않는다. 소수의 과제를 한 번씩 실행해서 한두 건 더 통과했다고 일반적인 우위가 입증된 것은 아니다. 반복 측정과 구간별 확인이 필요하고, 통계적 불확실성을 표현해야 한다. 중요한 업무일수록 평균의 작은 향상보다 치명적 실패의 유무가 더 큰 결정 기준일 수 있다. “총점 상승”이라는 문장만으로 출시 결정을 대신하지 않는다.

 

9. 비용과 지연은 성공한 업무 단위로 계산한다

 

토큰 수가 줄었다고 항상 경제적인 시스템은 아니다. 저렴한 모델을 썼지만 실패와 재시도가 늘어 사람이 다시 처리해야 한다면 실제 업무 비용은 커질 수 있다. 반대로 한 번의 추론이 비싸더라도 정확한 도구 호출로 전체 단계를 줄이면 유리할 수 있다. 성공한 과제당 모델 비용, 도구 사용 비용, 사람의 재처리 시간을 함께 보는 것이 실무에 더 가깝다.

 

지연도 첫 응답 시간과 최종 업무 완료 시간을 구분한다. “처리 중입니다”라는 문장이 빨리 나오는 것과 실제 환불이 확정되는 속도는 다르다. 평균뿐 아니라 느린 구간도 확인해야 한다. 일부 사용자가 긴 도구 대기와 재시도에 걸린다면 전체 평균만으로 경험을 설명할 수 없다. 타임아웃으로 중단된 시도도 지연 집계에서 사라지지 않도록 규칙을 정한다.

 

효율성 지표는 정확성과 함께 읽어야 한다. 필요한 상태 조회를 빼서 호출 수를 줄인 시스템을 우수하다고 볼 수는 없다. 독립적인 문서 조회를 병렬로 실행해 시간을 줄였는지, 같은 결과를 불필요하게 반복 요청했는지, 오류 이후에 의미 있는 확인을 했는지를 구분한다. 국내 사례가 도구 정확성과 효율성을 나눠 보는 이유도 이런 실무 문제와 연결해서 이해할 수 있다.

 

배포 기준은 업무의 영향도에 맞춰 정한다. 내부 초안 작성 도구와 외부 결제를 수행하는 도구에 같은 기준을 적용할 수는 없다. 예를 들어 핵심 회귀 과제 통과, 권한 위반 없음, 중복 쓰기 없음, 정해진 비용과 지연 예산 충족을 각각 문턱으로 둘 수 있다. 여기서 구체적인 수치는 서비스가 합의해야 하며 보편적인 정답은 없다. 기준을 결과를 본 뒤 바꾸지 않는 것이 중요하다.

 

오프라인 평가를 통과했다고 운영 품질이 영구히 보장되는 것도 아니다. 실제 요청은 계속 바뀌고 외부 도구와 검색 문서도 변한다. 제한된 범위에서 배포하고 운영 실패를 수집하며 필요하면 이전 설정으로 되돌릴 수 있어야 한다. 운영에서 발견한 문제를 개인정보 제거 후 새 테스트로 추가하면 평가가 제품과 함께 자란다. 평가와 관측은 서로 다른 역할을 하면서 같은 개선 흐름을 만든다.

 

10. 바로 적용할 실무 체크리스트

 

첫째, 사용자가 원하는 완료 상태를 한 문장으로 쓴다. “친절히 답한다”보다 “해당 고객의 해당 주문에 올바른 금액의 환불이 한 번 기록되고, 확인된 상태를 안내한다”처럼 검증 가능한 표현이 좋다. 둘째, 정상 요청과 실제 실패에서 작은 데이터셋을 만든다. 셋째, 각 과제에 초기 상태와 성공 조건과 금지 행동을 넣는다. 넷째, 코드로 확정 가능한 검사부터 자동화한다.

 

다섯째, 표현과 설명의 품질은 기준표를 만든 뒤 모델 평가를 붙인다. 여섯째, 사람의 검토로 평가 모델과 기준표를 교정한다. 일곱째, 같은 과제를 여러 번 실행해 우연한 성공을 구분한다. 여덟째, 비용과 지연을 성공한 업무 기준으로 집계한다. 아홉째, 기준 버전과 후보 버전을 비교하고 핵심 회귀를 확인한다. 열째, 운영 실패를 다음 평가 세트에 반영한다.

 

팀이 작다면 처음부터 평가 플랫폼을 크게 만들 필요는 없다. 과제 목록, 초기 데이터 복원, 실행 기록 저장, 결과 검사, 비교 보고서가 있으면 출발할 수 있다. 도구를 고를 때는 보기 좋은 점수판보다 실제 업무 상태를 검사할 수 있는지, 실패 실행을 재현할 수 있는지, 버전 차이를 추적할 수 있는지를 먼저 확인한다. 평가 체계의 가치는 화면의 화려함보다 의사결정을 바꿀 수 있는 증거에 있다.

 

11. 자주 묻는 질문

 

Q. LLM-as-a-Judge만 있으면 AI 에이전트 평가가 끝나나요?

아니다. 모델 평가는 자연어 품질과 열린 판단에 유용하지만 실제 환불·예약·파일 수정 여부를 확정하려면 환경의 결과를 확인해야 한다. 평가 모델도 틀릴 수 있으므로 사람의 교정과 코드 기반 검사를 함께 설계하는 것이 좋다. 특히 치명적 상태 오류를 좋은 문체 점수로 상쇄하지 않도록 해야 한다.

 

Q. 같은 프롬프트인데 매번 결과가 달라지면 테스트가 무의미한가요?

오히려 반복 측정이 필요한 이유다. 한 번의 성공이나 실패만으로 결론 내리지 않고 과제별 변동을 기록한다. 다만 변동이 모델에서 왔는지 환경에서 왔는지를 구분하려면 초기 상태, 문서 버전, 도구 응답 조건을 관리해야 한다. 설정을 고정해도 외부 서비스 변화까지 모두 사라지는 것은 아니다.

 

Q. 벤치마크 점수가 높은 모델로 바꾸면 해결되지 않나요?

일반 벤치마크는 참고 자료지만 우리 업무의 정책, 권한, 도구 계약, 사용자 입력 분포를 그대로 대변하지 않는다. 후보 모델은 같은 업무 평가 세트에 넣어 비교해야 한다. 특히 도구 인자 추출과 예외 처리, 응답 시간, 비용이 실제 서비스 조건에서 어떤 조합을 이루는지 확인하는 편이 유용하다.

 

Q. 성공률 목표를 몇 퍼센트로 잡아야 하나요?

보편적인 수치보다 업무의 영향도와 실패 비용이 먼저다. 단순 초안 생성은 사람이 검토할 수 있지만 잘못된 결제 실행은 피해가 다르다. 전체 성공률 목표, 핵심 업무별 기준, 허용할 수 없는 행동, 비용·지연 예산을 함께 정해야 한다. 적은 표본에서 실패가 없었다는 사실도 앞으로 실패가 없음을 증명하지는 않는다.

 

Q. 평가에 실패한 모든 사례를 프롬프트로 고쳐야 하나요?

그렇지 않다. 정책이 모호하면 요구사항을 다듬고, 도구가 필요한 정보를 돌려주지 않으면 계약을 개선하며, 상태 복원이 깨졌으면 테스트 환경을 고쳐야 한다. 프롬프트는 시스템을 구성하는 한 요소다. 실패를 입력·검색·도구·실행·채점으로 나눠 원인을 찾으면 불필요하게 긴 지침을 쌓는 일을 줄일 수 있다.

 

마무리: 에이전트의 완료 선언보다 완료의 증거를 설계하자

 

AI 에이전트의 평가는 모델을 칭찬하거나 낮은 점수를 찾는 행사가 아니다. 사용자가 맡긴 일을 끝냈다는 주장을 검증 가능한 상태와 기록으로 바꾸는 개발 과정이다. 성공률 90%라는 숫자는 그 시작일 뿐이다. 어떤 요청에서, 몇 번의 시도로, 어떤 기준을 통과했는지 설명할 수 있어야 실제 업무 신뢰도를 논의할 수 있다.

 

다음 프롬프트를 수정하기 전에 최근의 실패 몇 개를 꺼내 성공 조건부터 써 보자. 그리고 모델이 “완료”라고 말할 때 시스템의 무엇을 확인해야 하는지 정하자. 그 작은 기준이 회귀 테스트가 되고 모델 비교의 기준선이 되며 배포 결정을 뒷받침하는 증거가 된다. 에이전트의 미래를 좌우하는 것은 행동을 더 많이 시키는 능력과 함께, 그 행동이 맞았는지 알아내는 능력이다.

 

참고 자료 및 읽는 방법

 

[1] Anthropic, Demystifying evals for AI agents, 2026년 1월 9일.

https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents

Demystifying evals for AI agents

task·trial·grader·outcome의 구분, 코드·모델·사람 평가, pass@k와 pass^k, 초기 평가 데이터 수집 접근의 원자료다. 이 글의 확률 계산과 환불 과제는 원문의 개념을 설명하기 위해 별도로 구성했다.

 

[2] 인포그랩 기술 블로그, 엔터프라이즈 AI 에이전트 성능 평가 가이드, 2025년 9월 10일.

https://insight.infograb.net/blog/2025/09/10/ai-agent-tool-evaluation/

엔터프라이즈 AI 에이전트 성능 평가 가이드

국내 실무 관점에서 도구 호출과 인자, 도구 효율성, LLM-as-a-Judge 적용을 살펴볼 수 있다. 문제 제기 뒤 개념을 나누고 사례와 참고 자료로 이어지는 한국 기술 블로그의 구성을 참고했으며, 본문의 환불 설계는 해당 회사의 실제 구현이나 측정 결과를 재현한 것이 아니다.

 

자료 확인일: 2026년 11월 1일. 서비스별 기능과 평가 도구의 세부 동작은 바뀔 수 있으므로 도입 시점의 공식 문서와 업무 정책을 다시 확인하자.