#Agent 성능을 어떻게 정량화하는가

평가를 **결과층(작업 성공률), 과정층(궤적 평가), 시스템층(지연/비용/안정성)**이라는 3층 입체 지표 체계로 쪼개고, 여기에 코드 어서션, 환경 상태 비교, LLM as Judge 세 가지 자동화 평가 수단을 붙인다. 진짜 공학적 난점은 지표를 정의하는 것이 아니라 오류 전파, 결과의 비결정성, 심판의 환각이라는 세 함정을 처리하고, 최종적으로 재현 가능하고 귀인 가능하며 지속 반복 가능한 평가 폐루프를 형성하는 것이다.

#왜 Agent는 일반 대모델의 평가 방식을 그대로 쓸 수 없나

• 일반 대모델 — 생성 품질: 답이 정확한가, 표현이 매끄러운가
• Agent — 정말로 일을 해냈는가, 과정이 믿을 만한가, 비용이 감당 가능한가

#1층: 결과층 — 작업 성공률(task level success)

Agent를 「디지털 직원」으로 볼 때 가장 기본적인 질문은 작업을 완수했는가다. 판단 기준 세 예시:

1. 주보를 생성시켰다 → 올바른 파일이 생성되었는가
2. DB 주문 상태를 바꾸게 했다 → 「처리 대기」에서 「완료」로 바뀌었는가
3. 코드 한 단락을 실행시켰다 → 테스트 케이스를 통과했는가

용어: task level success(작업급 성공률). 이것은 하한선이지만 턱없이 부족하다 — 두 Agent가 똑같이 작업을 완수했더라도, 하나는 3스텝이고 다른 하나는 30스텝을 돌면서 여러 인터페이스를 잘못 호출했다면 분명히 동등하지 않다.

#2층: 과정층 — 궤적 평가(Trajectory Evaluation)

「Agent의 모든 단계를 완전히 기록」하며, 기록 대상은 계획, 도구 호출, 재시도 세 가지다. 중점적으로 볼 세 지표:

지표	구체적으로 무엇을 보나
도구 호출이 정확한가	DB를 조회해야 할 때 검색 도구를 잘못 호출하지 않았는가, user_id를 넘겨야 하는데 order_id를 넘기지 않았는가. 도구 오선택 + 파라미터 오전달이 가장 흔한 문제다
실행 경로가 효율적인가	같은 정보를 반복 조회하지 않는가, 한 스텝이면 될 것을 십수 스텝으로 쪼개지 않는가(지연과 비용에 직접 영향)
자기 교정 능력	오류 후 문제를 식별하고 → 재계획하고 → 다시 시도할 수 있는가. 인터페이스가 파라미터 오류를 반환했을 때 에러 메시지를 근거로 스스로 고칠 수 있는가, 아니면 그냥 포기하는가

#3층: 시스템층 — 지연, 비용, 안정성

Agent는 알고리즘 문제일 뿐 아니라 공학 문제이기도 하다.

• 종단간 지연: 사용자가 작업을 발기해서 결과를 받기까지의 대기 시간
• Token 소모 + 도구 호출 비용
• 안정성: 연속 100회를 돌렸을 때 몇 번이나 안정적으로 완수하는가

반례: 작업은 해내지만 매번 1분이 걸리고 수만 Token을 소모하며 외부 API를 잔뜩 호출한다면, 실제 업무에서는 상용에 올리기 어렵다.

3층 구결: 결과는 해냈는지를 보고, 과정은 어떻게 해냈는지를 보며, 시스템은 그 일을 해내기 위해 얼마의 대가를 치렀는지를 본다.

#자동화 평가의 3대 핵심 방법

방법	방식	적합한 작업
방법 1: 코드 어서션	유닛 테스트를 직접 실행, 통과=성공 실패=실패. 가장 객관적	명확한 표준 답이 있는 것: 코드 생성, SQL 생성, 수학 계산, 설정 변경
방법 2: 환경 상태 변화	Agent가 뭐라고 말하는지 보지 않고, DB 레코드가 바뀌었는지, 파일이 생성되었는지, 페이지 상태가 갱신되었는지만 본다	RPA, 데이터 분석 Agent, 운영 Agent
방법 3: LLM as Judge	더 강한 모델이 규칙에 따라 채점	유일한 표준 답이 없는 것: 고객 위로 메일 작성 등

보충: 방법 1의 예시 코드는 def test_agent(): res = agent.run(); assert res == expected # PASS 형태이며, 「코드 생성 / SQL 생성 / 수학 계산」 + 「객관적이고 명확함」으로 라벨링된다.

LLM as Judge의 채점 차원 4가지: 어조가 적절한가, 정보가 완전한가, 안전 리스크가 있는가, 업무 목표에 부합하는가. 레드라인: 모델 심판은 보조만 할 수 있고 맹신하면 안 된다.

#정리

1. Agent 평가는 작업 성공률만 봐서는 안 되고 입체적 지표 체계를 구축해야 한다
2. 첫째로 결과를 본다: 작업을 완수했는가
3. 둘째로 과정을 본다: 계획이 합리적인가, 도구 호출이 정확한가, 자기 교정이 되는가
4. 셋째로 시스템을 본다: 지연, 비용, 안정성이 실제 상용을 뒷받침할 수 있는가
5. 구현상으로는 결정론적 작업에 코드 어서션 + 상태 비교를 우선하고, 개방형 작업에 그다음으로 모델 심판을 도입한다
6. 진짜 난점을 짚는다: 오류 전파, 비결정성, 심판의 환각
7. 마무리는 공학 폐루프로: Mock 도구 + 샌드박스 스냅샷 + 다중 심판 + 사람의 샘플 검사 → 재현 가능, 귀인 가능, 지속 반복 가능한 평가 폐루프

#핵심 통찰

1. 평가 대상이 「출력」에서 「행위」로 바뀌었다 — 대모델은 텍스트 한 단락을 평가하지만 Agent는 동작 시퀀스 하나를 평가한다. 외부 상태를 바꿀 수 있는 모든 시스템은 평가의 닻을 「무엇을 말했는가」에서 「무엇을 해냈는가」로 옮겨야 한다.
2. 같은 결과가 같은 품질을 뜻하지 않는다 — 3스텝으로 완수한 것과 30스텝으로 완수한 것은 성공률 지표는 같지만 비용, 지연, 신뢰성이 하늘과 땅 차이다. 오직 과정층 지표만이 이 차이를 드러낼 수 있다.
3. 자기 교정 능력이 성숙도의 분수령이다 — Agent가 「상용에 올릴 수 있는지」 판단할 때, 「틀리지 않는 것」보다 중요한 것은 「틀린 뒤 스스로 일어날 수 있는가」다. 이것이 실제 공학 경험을 가장 잘 보여주는 지점이기도 하다.
4. 능력 평가는 먼저 격리해야 귀인이 가능하다 — 캐스케이드 파이프라인에서 종단간 지표는 「망가졌다」만 알려줄 뿐 「어디가 망가졌는지」는 알려주지 못한다. Mock + 변수 고정이 블랙박스를 측정 가능한 단위로 쪼개는 범용 기법이다.
5. 재현 불가능한 평가는 평가가 없는 것과 같다 — 환경 스냅샷과 샌드박스가 평가 결론에 의미를 부여하는 전제다. 그렇지 않으면 당신이 측정한 것은 모델의 능력이 아니라 운의 분산이다.
6. 심판 자체도 평가가 필요한 컴포넌트다 — LLM as Judge는 새로운 오차원을 도입한다. 평가 체계 설계는 「결정론적 수단 우선, 모델 수단은 폴백」이라는 강등 순서를 따라야 한다: 규칙 어서션 > 환경 상태 비교 > 모델 심판 > 사람의 샘플 검사.
7. 평가는 일회성 검수가 아니라 폐루프다 — 재현 가능(다시 돌릴 수 있음), 귀인 가능(위치를 특정할 수 있음), 지속 반복 가능(버전 비교 가능). 셋 중 하나가 빠지면 일회성 데모 시연으로 퇴화한다.

#엔지니어링 실전 Tips

• 궤적(trajectory)은 반드시 전량 적재할 것: 모든 계획, 모든 도구 호출, 모든 재시도를 기록하지 않으면 과정층 지표를 논할 수 없다.
• 도구 호출의 두 가지 고빈도 오류를 별도로 집계할 것: 도구 오선택과 파라미터 오전달(전형: user_id를 넘겨야 하는데 order_id를 넘김).
• 「스텝 수」를 일급 지표로 모니터링할 것 — 스텝 수 팽창은 곧 지연 팽창 + Token 청구서 팽창이다.
• 안정성은 「연속 N회 성공률」로 측정할 것(N=100). 한 번 돌아간 것으로는 아무것도 설명할 수 없다.
• 비용 레드라인을 명시적으로 정의할 것: 반례의 규모는 「1회 1분 + 수만 Token + 외부 API 여러 개」이며, 이런 것은 기능이 정확해도 상용에 올릴 수 없다.
• LLM as Judge의 채점 규칙은 구조화된 차원(어조 / 완전성 / 안전 / 업무 목표)으로 쓸 것. 모델이 자유롭게 총점 하나를 매기게 하지 말 것.
• 모델 심판은 다중 모델 교차 + 사람의 샘플 검사로 보정해 「Agent가 심판을 속이는」 이중 실패를 방지할 것.
• assert로 해결할 수 있는 것에는 절대 모델 심판을 쓰지 말 것: 결정론적 수단은 저렴하면서 환각도 없다.