에이전트 평가 — 정답이 하나가 아닐 때 품질을 측정하는 법

"이 에이전트, 잘 돌아가?"라는 질문에 답하기는 의외로 어렵습니다. 분류 모델이라면 정확도 한 숫자로 끝나지만, 데이터 엔지니어링 에이전트는 같은 질문에 정답을 내는 SQL이 여러 개거든요. 어떤 건 조인으로, 어떤 건 서브쿼리로 같은 답에 도달합니다. 출력 문자열을 정답과 그대로 비교하는 방식으론 멀쩡한 답을 자꾸 틀렸다고 합니다.

이것이 에이전트 평가가 일반 LLM 평가보다 한 겹 더 까다로운 이유입니다. 이 글은 데이터 엔지니어링 에이전트를 프로덕션에 올리기 위한 운영 3부작의 2편이고, 1편 AgentOps 관측성에서 쌓은 궤적 데이터를 품질 측정의 연료로 쓰는 단계입니다.

이 글에서 배우는 것

• 에이전트 평가가 LLM 평가와 무엇이 다른지(결과 vs 궤적)
• 정답이 하나가 아닐 때 "성공"을 정의하는 법
• 궤적(trajectory) 평가 — 답은 맞아도 과정이 틀린 경우
• 회귀 테스트로 프롬프트 수정의 부작용을 잡는 법
• LLM-as-judge의 함정과 그것을 길들이는 법

운영 3부작 — 1편 AgentOps 관측성 · 2편 에이전트 평가(이 글) · 3편 에이전트 보안

LLM 평가의 기본기(평가 지표, 데이터셋 구성, 자동/사람 평가)는 LLM 평가 가이드에 정리돼 있습니다. 이 글은 그 위에 에이전트 특유의 축을 얹습니다.

1. 결과만으로는 부족하다 — 두 개의 평가 축

LLM 평가는 보통 출력을 봅니다. 정답과 얼마나 가까운가. 에이전트는 여기에 축이 하나 더 붙습니다. 거기까지 어떻게 갔는가 — 즉 궤적입니다.

왜 두 축이 다 필요할까요? 답은 맞는데 과정이 끔찍한 경우가 흔하기 때문입니다. 정답을 냈지만 테이블 풀스캔을 세 번 돌고, 자기수정을 다섯 번 했다면 — 결과 평가는 통과지만 프로덕션에선 비용 폭탄입니다. 반대로 운 좋게 답만 맞은 경우도 위험합니다(잘못된 조인이 우연히 같은 수를 냄). 과정을 봐야 진짜 실력이 보입니다.

2. "성공"을 정의하기 — 정답이 하나가 아닐 때

문자열 비교가 안 되면 무엇으로 성공을 판정할까요? 데이터 엔지니어링 맥락에선 다행히 더 견고한 기준들이 있습니다.

쓸 수 있는 성공 기준은 단계별로 이렇습니다.

• 실행 정확도(execution accuracy) — SQL 문자열이 아니라 실행 결과셋을 비교. 정렬·컬럼순서를 무시한 집합 비교가 핵심. Text-to-SQL 평가의 사실상 표준입니다.
• 태스크 완수(task success) — "테이블이 생성됐고 품질 규칙을 통과했나" 같은 최종 상태로 판정. 변환·파이프라인 작업에 적합.
• 제약 충족 — 결과가 맞아도 행 한도·스캔량·런타임 같은 운영 제약을 넘으면 실패로 처리.
• 사람 선호(human preference) — 자동 판정이 애매한 케이스는 사람이 라벨링해 황금 데이터셋으로.

핵심 원칙 하나: 출력이 아니라 효과(effect)를 평가하라. 에이전트가 무엇을 썼는지가 아니라 무엇을 이뤘는지로 채점할 때 평가가 견고해집니다.

3. 궤적 평가 — 과정을 채점하기

궤적 평가는 1편에서 쌓은 트레이스·스팬 데이터가 그대로 입력이 됩니다. 관측이 평가의 연료가 되는 지점이죠.

특히 챙겨야 할 궤적 지표:

• 스텝 효율 — 이상적 경로 대비 실제 스텝 수. 늘어나면 프롬프트나 도구 설명이 모호하다는 신호.
• 도구 선택 정확도 — 옳은 도구를, 옳은 인자로 불렀나. 잘못된 도구 호출은 비용·위험의 주요 원인.
• 복구력 — 에러 뒤에 회복했는지, 같은 실수를 반복하며 루프를 돌았는지(1편에서 본 "루프 지옥").
• 근거성(groundedness) — 최종 답이 실제 도구 반환값에 기반하는지, 아니면 그럴듯하게 지어냈는지. 환각 탐지의 핵심.

4. 회귀 테스트 — 프롬프트 하나 고쳤다가 다 망가지는 일을 막기

에이전트 개발의 무서운 점: 프롬프트 한 줄을 고치면 어디가 깨질지 모른다는 것. A 케이스를 고치는 수정이 조용히 B·C 케이스를 망가뜨립니다. 그래서 에이전트에도 일반 소프트웨어처럼 회귀 테스트 스위트가 필요합니다.

여기서 1편과 2편이 맞물립니다. 관측에서 건진 실패 궤적이 회귀 테스트의 케이스가 됩니다. 프로덕션에서 한 번 틀린 질문을 고정 케이스로 묶어 두면, 같은 버그가 되살아나는 순간 CI가 잡아줍니다. 변환 로직을 검증 가능한 단위로 테스트하는 규율은 PySpark 테스트 가이드와 같은 정신이고, 프롬프트를 "검증 가능하게" 다루는 사고법은 Spec-Driven Development 시리즈와도 닿아 있습니다.

실전 팁: 평가는 CI에 묶어 자동으로 돌리고, 점수가 임계 아래로 떨어지면 머지를 막으세요. 사람의 의지에 기대면 반드시 건너뛰게 됩니다.

5. LLM-as-judge — 강력하지만 길들여야 하는 도구

자동 채점이 애매한 영역(설명의 적절성, 답변 품질)은 다른 LLM에게 채점을 맡기는 LLM-as-judge가 흔히 쓰입니다. 빠르고 싸고 확장되지만, 함정이 많아 그대로 믿으면 안 됩니다.

알려진 함정과 대응:

• 위치 편향 — 두 답을 비교시킬 때 먼저 제시된 쪽을 선호. → 순서를 바꿔 두 번 물어 일관성 확인.
• 장황함 편향 — 길고 화려한 답을 더 좋게 평가. → 루브릭에 "간결성"을 명시하고 길이를 통제.
• 자기 선호(self-preference) — 심판이 자기와 같은 모델 계열의 출력을 편애. → 생성과 채점에 다른 모델을 쓰기.
• 루브릭 표류 — 명확한 기준 없이 "느낌"으로 채점. → 점수마다 정의를 박은 구체적 루브릭과 few-shot 예시를 줄 것. 좋은 루브릭 설계는 프롬프트 엔지니어링 실전의 기법과 통합니다.

가장 중요한 원칙: 심판도 평가하라(meta-evaluation). LLM 심판의 점수를 사람 라벨 일부와 주기적으로 대조해 심판이 사람과 얼마나 일치하는지를 측정하세요. 심판이 미덥지 않으면 그 위에 쌓은 모든 평가가 모래성입니다. 그리고 가능한 곳에선 LLM 판단보다 결정적 검증(실행 정확도 같은)을 우선하세요 — 결과셋 비교가 가능한데 굳이 LLM에게 물어볼 이유는 없습니다.

6. 평가 파이프라인 — 전부 엮기

지금까지의 조각을 하나의 흐름으로 묶으면 이렇게 됩니다.

이 파이프라인이 자리잡으면, 프롬프트·모델·도구를 바꿀 때마다 숫자로 좋아졌는지 나빠졌는지를 알 수 있습니다. "느낌상 나아진 것 같다"에서 "회귀 없이 실행 정확도 +4%p"로 대화가 바뀌는 거죠.

마치며 — 측정할 수 없으면 개선할 수 없다

1편이 "보이지 않으면 고칠 수 없다"였다면, 2편의 교훈은 **"측정할 수 없으면 개선할 수 없다"**입니다. 에이전트 평가의 핵심은 출력을 글자 그대로 비교하려는 욕심을 버리고, 효과를 평가하고(결과셋 동등성) 과정을 채점하는(궤적) 것, 그리고 그것을 회귀 테스트로 박아 CI에 묶는 것입니다. LLM-as-judge는 강력하지만 길들이기 전엔 믿지 마세요.

이제 관측(1편)과 평가(2편)로 에이전트를 보이게 하고 측정 가능하게 만들었습니다. 마지막 남은 다리는 안전입니다. 도구를 들고 실제 시스템에 손대는 에이전트는, 잘못 설계하면 그대로 공격 표면이 됩니다. 다음 3편 에이전트 보안에서 프롬프트 인젝션 그 너머의 위협과 방어를 다룹니다.

한 문장으로: 에이전트는 출력이 아니라 효과로 평가하고, 결과와 궤적 두 축을 함께 보며, 회귀 테스트로 박아 CI 게이트에 묶을 때 비로소 품질이 공학이 된다.