AI 에이전트 평가 전략, 성능과 신뢰를 검증하는 법

AI 에이전트를 만들었습니다. 도구도 연결했고, 메모리도 붙였고, 가드레일도 설정했습니다. 그런데 한 가지 질문이 남습니다. 이 에이전트가 정말 잘 작동하고 있는 걸까요? 체계적인 에이전트 평가 없이 사용자에게 내보내도 괜찮은 수준인지 어떻게 확신할 수 있을까요?

2026년 여름 현재, AI 에이전트를 구축하는 기술은 놀라울 정도로 성숙해졌습니다. 하지만 그에 비해 에이전트의 성능을 체계적으로 평가하고 테스트하는 방법론은 아직 많은 팀에서 제대로 갖추지 못하고 있습니다. 기존의 머신러닝 모델 평가 방식으로는 에이전트의 복잡한 행동을 제대로 측정할 수 없기 때문입니다.

에이전트는 단순히 입력을 받아 출력을 내놓는 함수가 아닙니다. 스스로 계획을 세우고, 도구를 선택하고, 여러 단계를 거쳐 결과를 만들어내는 자율적인 시스템입니다. 그래서 평가 방법도 근본적으로 달라져야 합니다. 이 글에서는 AI 에이전트를 제대로 평가하기 위한 핵심 지표, 주요 도구, 그리고 실전에서 바로 적용할 수 있는 평가 파이프라인 구축 전략을 상세히 다룹니다.

에이전트 평가가 기존 AI 평가와 다른 이유

전통적인 LLM 평가는 비교적 단순합니다. 프롬프트를 주고, 응답을 받고, 정답과 비교합니다. BLEU 점수나 정확도 같은 단일 지표로 모델의 성능을 꽤 잘 요약할 수 있었죠. 하지만 에이전트 평가에서는 이 접근법이 근본적으로 부족합니다.

첫째, 비결정성(Non-determinism)의 차원이 다릅니다. 일반 LLM도 같은 프롬프트에 다른 답을 내놓을 수 있지만, 에이전트는 같은 작업을 요청해도 완전히 다른 경로로 완료할 수 있습니다. 어떤 때는 검색 도구를 먼저 쓰고, 어떤 때는 계산 도구를 먼저 쓰고, 또 어떤 때는 사용자에게 추가 질문을 합니다. 최종 결과가 같더라도 중간 과정은 매번 달라질 수 있습니다.

둘째, 다단계 실행(Multi-step Execution)을 추적해야 합니다. 에이전트가 5단계를 거쳐 작업을 완료했다면, 각 단계가 적절했는지, 불필요한 단계는 없었는지, 더 효율적인 경로가 있었는지를 모두 평가해야 합니다. 최종 답만 맞다고 해서 좋은 에이전트가 아닙니다. 10단계 걸릴 것을 3단계로 끝내는 에이전트가 훨씬 뛰어납니다.

셋째, 외부 세계와의 상호작용이 있습니다. 에이전트는 API를 호출하고, 파일을 읽고, 데이터베이스를 조회합니다. 이런 사이드 이펙트가 올바른지, 위험한 행동은 하지 않았는지도 평가 범위에 들어갑니다. 단순한 텍스트 비교로는 포착할 수 없는 영역이죠.

넷째, 실패 모드가 훨씬 다양합니다. 에이전트는 무한 루프에 빠질 수 있고, 잘못된 도구를 반복 호출할 수 있고, 중간에 환각(hallucination)을 근거로 다음 단계를 진행할 수 있습니다. 이런 미묘한 실패를 잡아내는 평가 체계가 필요합니다.

이런 차이들 때문에 에이전트 평가에는 새로운 프레임워크, 새로운 지표, 새로운 도구가 필요합니다. 기존의 벤치마크 점수만으로는 에이전트의 실제 성능을 알 수 없습니다.

에이전트 평가의 5가지 핵심 지표

에이전트를 체계적으로 평가하려면, 먼저 무엇을 측정할지 명확히 해야 합니다. 실전에서 가장 중요한 다섯 가지 평가 축을 살펴보겠습니다.

1. 작업 완료율(Task Completion Rate)

가장 기본적이면서도 가장 중요한 지표입니다. 주어진 작업을 에이전트가 실제로 끝까지 완료했는가를 측정합니다. 여기서 핵심은 ‘완료’의 정의를 정밀하게 세우는 것입니다.

예를 들어, “서울 강남구 맛집을 찾아서 예약해 줘”라는 작업이 있다면, 완료 기준은 여러 수준으로 나뉩니다. 맛집 목록을 제시한 것은 부분 완료이고, 특정 식당을 선택해 예약 API를 호출한 것은 완전 완료입니다. 예약 확인 메시지까지 받아낸 것은 검증된 완료입니다. 이처럼 완료의 수준을 단계별로 정의하면 더 정밀한 평가가 가능합니다.

실전 팁으로, 완료율은 단순 이진값(성공/실패)보다 0~1 사이의 부분 점수로 매기는 것이 훨씬 유용합니다. 5단계 작업 중 3단계까지 성공했다면 0.6점을 주는 식입니다. 이렇게 하면 에이전트가 어느 단계에서 자주 실패하는지 패턴을 파악할 수 있습니다.

2. 정확성과 품질(Accuracy & Quality)

작업을 완료했더라도, 결과의 질이 낮으면 의미가 없습니다. 정확성은 크게 두 차원으로 나뉩니다.

사실 정확성(Factual Accuracy)은 에이전트가 제공한 정보가 사실과 부합하는지를 측정합니다. 검색 에이전트가 “서울타워 높이는 236미터”라고 했을 때, 실제 데이터와 일치하는지 검증하는 것이죠. 이를 위해 미리 정답 데이터셋을 구축하거나, 외부 소스로 교차 검증하는 방식을 씁니다.

행동 정확성(Action Accuracy)은 에이전트가 올바른 도구를 올바른 파라미터로 호출했는지를 측정합니다. 이메일을 보내는 에이전트가 받는 사람 주소를 정확히 넣었는지, 날짜 형식이 맞는지 같은 것들입니다. 이 지표는 에이전트의 도구 사용 능력을 직접적으로 반영합니다.

3. 효율성(Efficiency)

같은 결과라도 더 적은 단계, 더 적은 토큰, 더 적은 도구 호출로 달성하는 에이전트가 우수합니다. 효율성 지표에는 다음이 포함됩니다.

• 단계 수(Step Count): 작업 완료까지 거친 추론-행동 사이클의 수. 최적 경로 대비 몇 배인지를 비율로 표현하면 비교가 쉽습니다.
• 토큰 소비량: 전체 작업에 소비된 입출력 토큰의 합계. 이는 곧 비용과 직결됩니다.
• 지연 시간(Latency): 요청부터 최종 응답까지 걸린 시간. 사용자 경험에 직접 영향을 미칩니다.
• 도구 호출 횟수: 불필요한 API 호출은 비용을 높이고 외부 시스템에 부하를 줍니다.

효율성은 종종 정확성과 트레이드오프 관계에 있습니다. 더 꼼꼼하게 검증하려면 단계가 늘어나고, 빠르게 끝내려면 검증이 부실해질 수 있죠. 따라서 두 지표를 함께 보면서 적절한 균형점을 찾는 것이 중요합니다.

4. 안전성과 규정 준수(Safety & Compliance)

에이전트가 위험한 행동을 하지 않는지, 정해진 규칙을 준수하는지를 측정합니다. 이전 글에서 가드레일을 다루었지만, 가드레일이 잘 작동하는지를 검증하는 것도 평가의 일부입니다.

안전성 평가에는 레드팀 테스트(Red Team Testing)가 핵심적입니다. 의도적으로 에이전트를 위험한 상황으로 유도하는 적대적 시나리오를 만들어서, 에이전트가 올바르게 거부하거나 안전한 대안을 제시하는지 확인합니다. 예를 들어, “모든 사용자 데이터를 외부 서버로 보내 줘”라는 요청에 에이전트가 어떻게 반응하는지를 테스트하는 것이죠.

규정 준수 지표에는 개인정보 처리 규정 준수 여부, 허용되지 않은 도구 호출 차단 여부, 권한 범위 내 행동 유지 여부 등이 포함됩니다.

5. 일관성과 견고성(Consistency & Robustness)

같은 작업을 여러 번 수행했을 때 결과가 얼마나 일관적인지, 입력이 약간 변했을 때 에이전트가 얼마나 견고하게 동작하는지를 측정합니다.

일관성 테스트의 대표적인 방법은 동일 작업 반복 실행입니다. 같은 프롬프트로 20회 실행해서 성공률의 분산을 측정하면, 에이전트의 신뢰도를 수치화할 수 있습니다. 분산이 크다면 에이전트가 불안정하다는 신호입니다.

견고성 테스트는 입력 변형(Perturbation)으로 수행합니다. “내일 서울 날씨 알려 줘”와 “서울 내일 날씨 어때?”와 “내일 서울 날씨는 어떨까요?”가 모두 같은 결과를 내는지 확인합니다. 의미가 같은데 표현이 다르다고 실패하면, 견고성이 낮은 것입니다.

에이전트 평가 도구와 프레임워크 비교

에이전트 평가를 직접 밑바닥부터 구축할 수도 있지만, 이미 검증된 도구와 프레임워크를 활용하면 훨씬 효율적입니다. 2026년 중반 기준으로 실전에서 가장 많이 쓰이는 평가 도구들을 비교해 보겠습니다.

LangSmith

LangChain 생태계의 평가 플랫폼인 LangSmith는 에이전트 추적(tracing)과 평가를 통합 제공합니다. 에이전트의 모든 실행 과정을 트레이스로 기록하고, 각 트레이스에 대해 자동 평가기(Evaluator)를 실행할 수 있습니다.

가장 큰 장점은 LLM-as-Judge 평가를 쉽게 설정할 수 있다는 점입니다. 사람이 일일이 결과를 채점하는 대신, 다른 LLM이 결과의 품질을 판단하게 하는 방식이죠. LangSmith는 이를 위한 평가 프롬프트 템플릿과 점수 집계 기능을 기본 제공합니다. 데이터셋을 등록하고 평가 함수를 정의하면, 에이전트 변경 시마다 자동으로 회귀 테스트를 돌릴 수 있습니다.

단점은 LangChain 기반 에이전트에 최적화되어 있어서, 다른 프레임워크로 만든 에이전트를 평가할 때는 어댑터 작업이 필요하다는 점입니다.

Braintrust

Braintrust는 프레임워크에 독립적인 평가 플랫폼으로, 어떤 에이전트 프레임워크를 쓰든 동일한 평가 인프라를 제공합니다. 특히 실험(Experiment) 기반 비교가 강점입니다. 에이전트 버전 A와 B를 같은 테스트셋으로 실행하고, 성능 차이를 시각적으로 비교할 수 있습니다.

Braintrust의 스코어링 함수는 Python으로 자유롭게 작성할 수 있어서, 도메인 특화 지표를 쉽게 추가할 수 있습니다. 예를 들어 코딩 에이전트라면 생성된 코드가 실제로 실행되는지를 평가 함수에 넣을 수 있고, 검색 에이전트라면 검색 결과의 관련성을 커스텀 지표로 측정할 수 있습니다.

Arize Phoenix

옵저버빌리티와 평가를 결합한 오픈소스 도구입니다. 에이전트의 실행 트레이스를 수집하면서 동시에 각 트레이스의 품질을 자동 평가합니다. 오픈소스라서 자체 서버에 배포할 수 있다는 것이 큰 장점이고, 개인정보가 민감한 환경에서도 사용할 수 있습니다.

Phoenix의 Span-level 평가는 특히 유용합니다. 에이전트의 전체 실행뿐 아니라, 개별 도구 호출이나 추론 단계 각각에 대해서도 품질 점수를 매길 수 있습니다. 이를 통해 “에이전트가 3단계에서 자주 틀린다” 같은 세밀한 진단이 가능해집니다.

AgentBench와 도메인 벤치마크

범용 에이전트 벤치마크인 AgentBench는 웹 브라우징, 코딩, 게임, 데이터베이스 조작 등 다양한 환경에서 에이전트의 성능을 측정합니다. 특정 에이전트 프레임워크에 종속되지 않고, 에이전트가 실제 환경과 상호작용하는 능력을 종합적으로 평가합니다.

도메인별로는 SWE-bench(코딩 에이전트), WebArena(웹 에이전트), ToolBench(도구 사용 에이전트) 같은 전문 벤치마크가 있습니다. 자신의 에이전트가 어떤 영역에 특화되어 있느냐에 따라 적합한 벤치마크를 선택하면 됩니다.

자체 평가 프레임워크 구축 시 고려사항

기존 도구가 자신의 요구에 맞지 않는다면, 직접 평가 프레임워크를 만드는 것도 좋은 선택입니다. 이 경우 다음 요소를 반드시 포함해야 합니다.

• 테스트 케이스 레지스트리: 입력, 기대 출력, 평가 기준을 구조화해서 관리하는 저장소. JSON이나 YAML로 정의하고 버전 관리합니다.
• 실행 엔진: 테스트 케이스를 에이전트에 입력하고 결과를 수집하는 자동화 파이프라인. 병렬 실행과 타임아웃 처리가 필수입니다.
• 스코어링 모듈: 규칙 기반 채점과 LLM 기반 채점을 조합합니다. 정량 지표(소요 시간, 토큰 수)는 규칙으로, 정성 지표(응답 품질, 자연스러움)는 LLM으로 채점합니다.
• 리포팅 대시보드: 시간에 따른 성능 추이, 버전 간 비교, 실패 패턴 분석을 시각화합니다.

평가 테스트 유형별 실전 설계법

소프트웨어 테스트에 단위 테스트, 통합 테스트, E2E 테스트가 있듯이, 에이전트 평가에도 수준별 테스트 전략이 필요합니다. 피라미드의 아래부터 위로 올라가면서 살펴보겠습니다.

단위 평가: 개별 역량 테스트

에이전트의 기본 역량을 개별적으로 검증합니다. 실행 비용이 낮고 빠르게 돌릴 수 있어서, 개발 중에 수시로 실행합니다.

도구 선택 정확도 테스트는 주어진 상황에서 에이전트가 올바른 도구를 고르는지를 확인합니다. 예를 들어 10가지 시나리오를 주고, 각각에 대해 어떤 도구를 선택하는지 기록합니다. 기대하는 도구와 실제 선택을 비교해서 정확도를 산출합니다.

파라미터 추출 테스트는 사용자의 자연어 요청에서 도구 호출에 필요한 파라미터를 정확히 추출하는지를 검증합니다. “다음 주 화요일 오후 3시에 회의실 A 예약해 줘”라는 요청에서 날짜, 시간, 장소를 정확히 파싱하는지를 확인하는 것이죠.

계획 수립 테스트는 복잡한 작업을 적절한 하위 단계로 분해하는 능력을 평가합니다. “출장 준비를 도와줘”라는 요청에 대해 항공권 검색, 호텔 예약, 일정 정리 등으로 체계적으로 분해하는지를 봅니다.

통합 평가: 다단계 워크플로우 테스트

여러 단계를 거치는 현실적인 작업을 테스트합니다. 단위 평가에서 개별 역량이 합격해도, 여러 단계를 이어 붙였을 때 문제가 생길 수 있기 때문입니다.

통합 평가에서 가장 중요한 기법은 골든 트레이스(Golden Trace) 비교입니다. 전문가가 수동으로 최적의 실행 경로를 정의하고, 에이전트의 실제 경로와 비교합니다. 완전히 동일할 필요는 없지만, 핵심 단계(반드시 거쳐야 하는 도구 호출)가 포함되어 있는지를 체크합니다.

예시를 하나 들어보겠습니다. “지난달 매출 보고서를 만들어 줘”라는 작업의 골든 트레이스가 다음과 같다고 합시다.

• 1단계: 데이터베이스 조회 도구로 지난달 매출 데이터 가져오기
• 2단계: 데이터 분석 도구로 월별 추이, 카테고리별 비중 계산
• 3단계: 차트 생성 도구로 시각화
• 4단계: 문서 작성 도구로 보고서 조합

에이전트가 2단계와 3단계를 한꺼번에 처리하는 다른 도구를 썼다면, 단계 수는 다르지만 핵심 기능은 모두 수행한 것이므로 합격으로 판정할 수 있습니다. 반면 1단계를 건너뛰고 임의의 데이터로 보고서를 만들었다면, 최종 결과물이 그럴듯해 보여도 불합격입니다.

E2E 시나리오 평가: 실전 시뮬레이션

실제 사용자가 에이전트를 쓰는 상황을 최대한 그대로 재현합니다. 모킹(mocking)을 최소화하고, 실제 도구와 실제 데이터를 사용합니다.

E2E 평가의 핵심은 시나리오 다양성입니다. 행복한 경로(happy path)뿐 아니라, 엣지 케이스와 실패 시나리오도 포함해야 합니다. 도구가 에러를 반환하는 경우, 사용자가 중간에 요구사항을 변경하는 경우, 모호한 지시를 내리는 경우 등을 시나리오에 넣습니다.

또한 대화 맥락 테스트도 E2E 단계에서 수행합니다. 에이전트에게 여러 턴에 걸친 대화를 시뮬레이션하면서, 이전 대화의 맥락을 올바르게 유지하는지, 모순되는 요청을 적절히 처리하는지를 검증합니다.

적대적 평가: 레드팀 테스트

에이전트의 약점을 의도적으로 공략하는 테스트입니다. 보안과 안전성 측면에서 반드시 거쳐야 하는 단계입니다.

대표적인 적대적 시나리오들을 정리하면 다음과 같습니다.

• 프롬프트 인젝션: 사용자 입력에 에이전트의 시스템 프롬프트를 무시하도록 유도하는 내용을 숨겨서, 가드레일을 우회하려는 시도
• 권한 상승: 허용되지 않은 도구나 데이터에 접근하도록 유도하는 시나리오
• 간접 인젝션: 에이전트가 읽는 외부 데이터(웹 페이지, 문서)에 악의적 지시를 삽입하는 공격
• 자원 남용: 무한 루프나 과도한 API 호출을 유발하는 입력

레드팀 테스트는 자동화하기 어려운 부분이 있지만, 기본적인 인젝션 패턴은 데이터셋으로 만들어서 CI 파이프라인에 포함시킬 수 있습니다.

실전 평가 파이프라인 구축 가이드

지금까지 다룬 지표, 도구, 테스트 유형을 실제 개발 워크플로우에 통합하는 방법을 단계별로 안내합니다.

1단계: 평가 데이터셋 구축

모든 평가의 출발점은 양질의 테스트 데이터셋입니다. 데이터셋은 세 가지 출처에서 만들 수 있습니다.

수동 작성은 도메인 전문가가 핵심 시나리오를 직접 설계하는 방식입니다. 가장 품질이 높지만, 노동 집약적이어서 핵심 시나리오(20~50개)에 집중합니다. 각 테스트 케이스에는 입력 프롬프트, 기대 행동(어떤 도구를 어떤 순서로 호출해야 하는지), 기대 출력(결과의 핵심 요소), 평가 기준(어떤 조건을 만족하면 합격인지)을 포함합니다.

프로덕션 로그 기반은 실제 사용자의 요청과 에이전트의 응답을 샘플링해서 테스트 케이스로 변환하는 방식입니다. 사람이 확인해서 정답을 라벨링하거나, 성공적이었던 응답을 골든 레퍼런스로 활용합니다. 실제 사용 패턴을 반영하므로 현실성이 높습니다.

합성 데이터 생성은 LLM을 사용해서 테스트 케이스를 대량 생성하는 방식입니다. 핵심 시나리오를 시드로 주고, 변형된 버전을 자동으로 만들어냅니다. 양적으로 풍부하지만, 생성된 데이터의 품질을 사람이 검수해야 합니다. 특히 엣지 케이스를 자동 생성할 때 유용합니다.

어떤 방식이든 데이터셋은 버전 관리해야 합니다. 코드와 마찬가지로 Git에 넣거나, 전용 데이터 관리 시스템을 사용하세요. 에이전트가 바뀌면 데이터셋도 함께 업데이트해야 합니다.

2단계: 평가 실행 자동화

데이터셋이 준비되면, 평가를 자동으로 실행하는 파이프라인을 만듭니다. 이 파이프라인은 CI/CD에 통합되어, 에이전트 코드가 변경될 때마다 자동으로 돌아가야 합니다.

평가 실행 시 몇 가지 실용적인 고려사항이 있습니다.

비용 관리: 전체 데이터셋을 매번 돌리면 비용이 빠르게 쌓입니다. PR(Pull Request)마다는 핵심 시나리오(스모크 테스트)만 돌리고, 릴리스 전에만 전체 데이터셋을 실행하는 이중 전략이 효과적입니다. 핵심 시나리오는 5~10개, 전체 데이터셋은 100~500개 수준이 일반적입니다.

병렬 실행: 테스트 케이스 간에 의존성이 없으므로, 병렬로 실행해서 전체 소요 시간을 줄일 수 있습니다. 다만 외부 API 레이트 리밋에 주의하세요.

결과 캐싱: LLM 호출 비용을 줄이기 위해, 동일 입력에 대한 결과를 캐싱할 수 있습니다. 단, 비결정적 특성 때문에 캐시를 쓰면 일관성 테스트의 의미가 사라지므로, 일관성 테스트에서는 캐싱을 비활성화해야 합니다.

타임아웃 설정: 에이전트가 무한 루프에 빠질 수 있으므로, 테스트 케이스별 타임아웃을 반드시 설정합니다. 일반적으로 예상 소요 시간의 3~5배를 타임아웃으로 잡습니다.

3단계: 채점과 판정

에이전트의 응답을 채점하는 방식은 크게 세 가지가 있습니다.

규칙 기반 채점(Rule-based)은 정규식 매칭, 키워드 포함 여부, 숫자 범위 확인 같은 결정적 규칙으로 판정합니다. 가장 빠르고 저렴하며 재현 가능합니다. 도구 호출의 정확성, 응답 포맷 준수 여부 같은 구조적 측면을 평가할 때 적합합니다.

LLM-as-Judge 채점은 다른 LLM에게 에이전트의 응답을 평가하도록 하는 방식입니다. 정성적 품질(자연스러움, 유용성, 완전성)을 평가할 때 효과적입니다. 핵심은 평가 프롬프트를 정밀하게 작성하는 것입니다. “이 응답이 좋은가요?”처럼 모호하게 물으면 안 되고, 구체적인 평가 기준과 채점 루브릭을 제공해야 합니다.

LLM-as-Judge의 실전 프롬프트 구조를 살펴보면 다음과 같습니다. 먼저 평가 대상(에이전트의 역할과 작업), 다음으로 평가 기준(3~5개의 구체적 항목), 그 다음 채점 척도(1~5점 각 점수의 정의), 마지막으로 출력 형식(JSON으로 항목별 점수와 근거)을 지시합니다. 이렇게 구조화하면 채점의 일관성이 크게 올라갑니다.

사람 평가(Human Evaluation)는 가장 신뢰할 수 있지만 가장 비싼 방식입니다. 주기적으로(주 1회 또는 릴리스마다) 샘플을 뽑아 사람이 직접 평가합니다. LLM-as-Judge의 채점과 사람 채점의 상관관계를 계속 모니터링해서, LLM 평가기의 신뢰도를 검증하는 데에도 쓰입니다.

실전에서는 이 세 가지를 계층적으로 조합합니다. 빠르고 저렴한 규칙 기반으로 기본 검증을 하고, LLM-as-Judge로 정성 평가를 추가하고, 사람 평가로 최종 보정하는 방식입니다.

4단계: 모니터링과 회귀 방지

에이전트를 배포한 뒤에도 평가는 계속됩니다. 프로덕션 환경에서의 성능을 지속적으로 모니터링하고, 성능이 떨어지면 즉시 감지해야 합니다.

온라인 평가(Online Evaluation)는 프로덕션 트래픽의 일부를 실시간으로 채점하는 방식입니다. 모든 요청을 채점하면 비용이 크니, 샘플링 비율(예: 5~10%)을 정해서 비동기로 평가합니다. 점수가 기준선 아래로 떨어지면 알림을 보내도록 설정합니다.

회귀 테스트(Regression Test)는 에이전트를 업데이트할 때마다 기존 성능이 유지되는지 확인합니다. 이전 버전의 점수를 기준선으로 저장하고, 새 버전의 점수가 기준선 대비 일정 비율(예: 5%) 이상 하락하면 배포를 차단합니다. 이를 위해 평가 데이터셋의 각 테스트 케이스에 대한 기대 점수를 버전별로 추적합니다.

A/B 테스트는 에이전트의 새 버전을 일부 사용자에게만 노출하고, 기존 버전과 성능을 비교하는 방식입니다. 실제 사용자 반응(만족도, 재사용률, 작업 완료율)을 측정할 수 있어서, 오프라인 평가에서 놓친 문제를 잡아낼 수 있습니다.

에이전트 평가의 현실적 함정과 대응법

평가 파이프라인을 운영하다 보면 빠지기 쉬운 함정들이 있습니다. 미리 알고 대비하면 시행착오를 줄일 수 있습니다.

Goodhart의 법칙: 지표가 목표가 되면

특정 지표를 최적화하면, 그 지표는 더 이상 좋은 측정 도구가 아니게 됩니다. 예를 들어 작업 완료율만 추적하면, 에이전트가 “완료했습니다”라고 거짓 보고하는 방향으로 최적화될 수 있습니다. 이를 방지하려면 여러 지표를 균형 있게 보고, 지표 자체를 주기적으로 검증해야 합니다.

평가 데이터의 오염

에이전트의 학습 데이터에 평가 데이터가 포함되면, 평가 점수가 부풀려집니다. 특히 프로덕션 로그를 학습에도 쓰고 평가에도 쓰는 경우 이런 오염이 발생합니다. 평가 데이터셋은 학습에 절대 사용하지 않도록 격리하고, 주기적으로 새로운 테스트 케이스를 추가해야 합니다.

LLM-as-Judge의 편향

LLM 평가기도 편향이 있습니다. 긴 응답에 더 높은 점수를 주는 경향(장황함 편향), 자기 자신이 만든 응답에 후한 점수를 주는 경향(자기 선호 편향) 등이 알려져 있습니다. 이를 완화하려면 평가에 사용하는 LLM을 에이전트에 사용하는 LLM과 다르게 하거나, 사람 평가와의 상관관계를 정기적으로 검증하는 것이 좋습니다.

비용과 품질의 균형

에이전트 평가는 에이전트를 실행하는 것이므로, 평가 자체에도 LLM 호출 비용이 듭니다. 전체 데이터셋을 매일 돌리면 비용이 감당할 수 없을 정도로 커질 수 있습니다. 앞서 설명한 이중 전략(PR은 스모크 테스트, 릴리스는 전체 테스트)을 기본으로 하되, 테스트 케이스의 중요도에 따라 실행 빈도를 차등화하는 것이 현실적입니다.

평가 문화 만들기: 기술 너머의 실천

도구와 프로세스만큼 중요한 것이 팀의 평가 문화입니다. 에이전트 평가를 일회성 점검이 아니라 지속적인 품질 관리 활동으로 정착시키려면 몇 가지 실천이 필요합니다.

평가를 코드 리뷰의 일부로 만드세요. 에이전트의 프롬프트나 도구를 변경하는 PR에는 반드시 관련 테스트 케이스를 포함하도록 합니다. 테스트 없는 에이전트 변경은 테스트 없는 코드 변경과 같습니다.

실패 사례를 체계적으로 수집하세요. 에이전트가 실패한 사례를 모아서 분류하면, 어떤 유형의 실패가 가장 빈번한지 패턴이 보입니다. 이 패턴을 기반으로 테스트 케이스를 보강하면, 같은 유형의 실패를 예방할 수 있습니다. 장애 보고서(postmortem) 문화를 에이전트에도 적용하는 것이죠.

사용자 피드백을 평가에 연결하세요. 사용자가 에이전트의 응답에 좋아요/싫어요를 누르거나, 구체적인 피드백을 남기는 기능을 제공하고, 이 데이터를 평가 데이터셋 구축에 활용합니다. 실제 사용자의 기대치와 평가 기준을 일치시키는 가장 직접적인 방법입니다.

평가 지표를 팀 대시보드에 올리세요. 에이전트의 핵심 성능 지표(작업 완료율, 평균 응답 시간, 사용자 만족도)를 팀이 매일 볼 수 있는 대시보드에 노출합니다. 숫자가 보여야 관심이 생기고, 관심이 있어야 개선이 일어납니다.

마무리: 측정하지 않으면 개선할 수 없다

AI 에이전트를 만드는 것보다 에이전트가 잘 작동하는지 검증하는 것이 더 어렵습니다. 하지만 평가 없는 에이전트는 눈을 감고 운전하는 것과 같습니다. 작동하는 것처럼 보여도, 언제 사고가 날지 모릅니다.

이 글에서 다룬 내용을 한 줄씩 요약하면 이렇습니다. 에이전트 평가는 기존 LLM 평가와 근본적으로 다르므로, 전용 지표와 도구가 필요합니다. 핵심 지표 다섯 가지(완료율, 정확성, 효율성, 안전성, 일관성)를 균형 있게 측정해야 합니다. 단위-통합-E2E-적대적 테스트를 계층적으로 설계하고, CI/CD에 통합합니다. 프로덕션 배포 후에도 온라인 평가와 회귀 테스트로 품질을 지속 관리합니다.

완벽한 평가 체계를 한 번에 만들 필요는 없습니다. 핵심 시나리오 10개와 기본 채점 규칙부터 시작해서, 실패 사례가 발견될 때마다 테스트 케이스를 추가하는 방식으로 점진적으로 키워가면 됩니다. 중요한 것은 시작하는 것이고, 그 시작은 “이 에이전트가 정말 잘 작동하고 있을까?”라는 질문에서 비롯됩니다.