행동 평가로 AI 에이전트 평가하기: 결과뿐 아니라 과정도 본다

최근 AI Agent를 다루는 팀이라면 이런 상황을 겪어봤을 것이다. 모델도 그대로, 비즈니스도 그대로다.

그저 System Prompt를 바꾸고, Tool Schema를 조정했거나, Coding Agent에 도구를 하나 새로 추가했을 뿐이다.

그런데 Benchmark를 다시 돌려보니 성공률이 오히려 떨어졌다.

이때 가장 골치 아픈 문제가 생긴다. 대체 어디가 문제인 걸까?

모델의 추론 능력이 나빠진 걸까? 아니면 도구를 잘못 선택한 걸까? 파라미터를 잘못 넘긴 걸까? 혹은 코드는 다 작성했지만 Agent가 테스트를 아예 돌리지 않은 걸까?

과거에 이런 문제를 만나면, 많은 팀이 수동 점검에 의존할 수밖에 없었다. Prompt, 로그, Trace, Tool Calling 기록을 다시 뒤지며 하나하나 보고, 단계별로 문제를 찾는 것은 시간도 많이 들고 원인을 빠르게 특정하기도 어려웠다.

그런데 Google이 최근 공개한 Harness Engineering에 관한 기술 아티클이 바로 이 문제를 다루고 있다.

Google이 제시한 것은 테스트 엔지니어가 주목할 만한 관점이다. AI Agent를 테스트할 때는 마지막에 "정답을 맞혔는지"만 볼 것이 아니라, 그 중간에 "어떻게 했는지"까지 봐야 한다는 것이다.

예를 들어, 올바른 도구를 호출했는가? 파라미터를 제대로 넘겼는가? 테스트를 실행해야 할 때 실행했는가? 전체 작업 흐름이 예상대로 진행되었는가?

이처럼 Agent 실행 과정에서 일어나는 행동은 관찰되고, 판단되고, 반복 검증될 수 있다면 테스트의 일부가 되어야 한다.

이것이 Behavioral Evaluation, 즉 '행동 평가'이다.

그 배후에 반영된 변화가 사실 더 중요하다. AI Agent는 점점 더 진짜 소프트웨어 시스템처럼 되어가고 있다.

과거에 대규모 모델을 테스트할 때는 문제 세트를 주고 최종 점수를 보는 경우가 많았다. 하지만 AI Agent를 테스트할 때는 결과만 보는 것으로는 부족하다. 우리는 소프트웨어를 테스트하듯 그 실행 과정, 도구 호출, 핵심 행동을 점검하고, 지속적인 회귀 테스트를 통해 Prompt나 도구를 한 번 조정한 것이 도대체 "무엇을 망가뜨렸는지" 즉시 발견해야 한다.

一、예전에는 Agent를 어떻게 테스트했을까?

지금도 많은 AI 팀이 Agent Evaluation(지능형 에이전트 평가)을 할 때 가장 먼저 떠올리는 것은 역시 Benchmark 점수 매기기다.

예를 들어 AI Coding 분야에서는 흔히 SWE-bench, Terminal-Bench, 그리고 회사 내부에서 자체 정리한 Evaluation Dataset 등이 있다.

테스트 방법도 아주 직접적이다.

Agent에게 과제 하나를 준다 ↓ Agent가 스스로 실행한다 ↓ 최종 결과를 받는다 ↓ 테스트를 실행한다 ↓ PASS / FAIL을 판정한다 ↓ 성공률을 집계한다

테스트 과제가 100개라고 가정하면, 결과는 이렇다.

Agent V1: 82% 통과율 Agent V2: 86% 통과율

언뜻 보면 간단하다. V2가 V1보다 강하다. 성공률이 4% 올랐으니까.

하지만 Google은 아주 핵심적인 문제를 제기한다. 86%는 왜 82%보다 높은가? 대체 어디가 좋아진 것인가?

반대의 경우도 마찬가지다. 업그레이드 후에 이렇게 됐다고 가정하자.

Agent V3: 79% 통과율

우리는 그것이 나빠졌다는 것만 알 뿐, 왜 나빠졌는지는 모른다.

모델 능력이 퇴화한 걸까? 아니면 Prompt를 잘못 고친 걸까? 혹은 Harness(Agent에게 도구와 환경, 실행 흐름을 제공하는 인프라)의 어딘가를 잘못 고쳐서 문제가 생긴 걸까?

Google이 9월 9일 발표한 Harness Engineering 관련 아티클에서 언급했듯이, 엔드투엔드 Benchmark는 Agent가 "전체적으로 어떻게 수행하는지"를 판단하기에는 아주 적합하지만, 점수가 변했을 때 "문제가 대체 어디에 있는지"를 알려주기는 어렵다.

예를 들어, 79%라는 성공률 하나만으로는 다음을 판단하기 어렵다.

- Agent가 모호한 Prompt를 만났을 때 지나치게 확신한 것은 아닌가?

- Agent가 코드를 다 쓴 뒤 테스트 실행을 잊은 것은 아닌가?

- Agent가 존재하지도 않는 CLI 파라미터를 "환각"으로 만들어낸 것은 아닌가?

- 아니면 특정 도구 호출이나 실행 흐름에 문제가 생긴 것은 아닌가?

이것은 사실 전통적인 소프트웨어 테스트와 매우 닮았다.

예전에 소프트웨어를 테스트할 때 우리는 이것만 하지 않았다.

System Test(시스템 테스트)

다음처럼 나누기도 했다.

Unit Test(단위 테스트) Integration Test(통합 테스트) Regression Test(회귀 테스트)

"전체 시스템이 최종적으로 돌아가느냐"만 보면 결과가 맞는지 틀린지만 알려줄 뿐, 문제가 어디에 있는지는 알려주기 어렵기 때문이다.

Agent도 마찬가지다.

Benchmark 최종 PASS / FAIL만 들여다보는 것은 시스템 테스트만 하는 것과 같다.

그것은 Agent가 강해졌는지 약해졌는지는 알려주지만, 진짜로 Agent를 잘 만들려면 한 걸음 더 나아가 풀어서 봐야 한다. 도대체 어느 단계에서 맞게 했고, 어느 단계에서 문제가 생겼는지를.

二、구글이 AI Agent의 "감독관"이 되다: 말이 예쁜지는 보지 않고, 일 처리가 규범에 맞는지만 본다!

Google은 Behavioral Evaluation(행동 평가)이라는 개념을 제시했다.

이름은 다소 복잡해 보이지만 이해는 간단하다. 이것은 Agent에게 '통합 테스트'를 해주는 것과 비슷하다.

중점은 Agent가 마지막에 얼마나 멋지게 답하는지가 아니라, 과제를 완수하는 과정에서 해야 할 일을 했는지에 있다.

예를 들어, 사용자가 제공한 정보가 불완전할 때 Agent는 어떻게 처리해야 하는가?

먼저 되물어서 빠진 정보를 채워야 하는가? 아니면 이것저것 따지지 않고 스스로 답을 하나 추측해버리는가?

또 다른 예로:

- Agent가 Build 파일을 수정한 뒤 Validator를 실행해 점검했는가?

- Agent가 코드 수정을 마친 뒤 테스트 도구를 호출했는가?

- Agent가 문서를 생성할 때 올바른 Repository를 인용했는가?

이런 점검들이 주목하는 것은 "최종 답이 어떻게 생겼는가"가 아니라, Agent의 "일하는 과정"이 올바른지 여부다.

이것은 과거에 AI를 테스트하던 방식과 큰 차이가 있다.

예전에 우리는 아마 이것에 더 주목했을 것이다.

assert response == expected_answer

즉, Agent가 내놓은 답이 기대 답과 일치하는가.

하지만 이제는 이것까지 점검해야 한다.

assert agent.called_tool( "test_runner" )

즉, Agent가 과제를 수행하는 과정에서 호출해야 할 도구를 호출했고, 완수해야 할 단계를 완수했는가.

왜 이 점이 중요할까?

"결과가 올바른 것"과 "과정이 올바른 것"은 사실 별개의 문제이기 때문이다.

어떤 Agent가 이번에는 우연히 답을 맞혔을 수 있지만, 올바른 흐름에 따라 실행하지 않았을 수 있다. 이런 Agent는 실제 비즈니스에서 신뢰할 수 없다.

그래서 Behavioral Evaluation이 진짜로 해결하려는 문제는 이것이다. Agent가 "정답을 맞혔는지"만 볼 것이 아니라, "올바른 방식으로 일을 제대로 해냈는지"까지 봐야 한다.

다시 말해, 결과가 맞았다고 해서 행동이 올바른 것은 아니다. 진짜 신뢰할 수 있는 Agent는 결과도 제대로 맞히고 과정도 제대로 밟아야 한다.

三、실제 비즈니스에 놓고 보면 더 쉽게 이해된다

이커머스 애프터서비스(CS) 사례 하나로 살펴보자.

사용자가 Agent에게 이렇게 말했다고 가정하자.

"방금 산 이어폰이 아직 발송 안 됐는데, 안 필요해졌어요. 환불해 주세요."

Agent가 곧바로 답한다.

"네, 환불 신청이 접수되었습니다."

최종 결과만 보면 별문제 없어 보인다. 이 테스트는 곧바로 이렇게 판정해도 될 것 같다.

PASS

하지만 Agent의 실제 실행 과정, 즉 Trace를 열어보면 그것이 이렇게 했다는 걸 알 수 있다.

사용자 요청 ↓ 주문 조회 query_order ↓ 바로 환불 refund_payment ↓ 사용자에게 답변

문제가 생겼다. 아주 중요한 단계 하나가 빠졌다.

check_refund_policy

즉, 환불 규칙을 먼저 점검하지 않은 것이다.

심지어 다음을 완전히 확인하지도 않았을 수 있다.

- 주문이 지금 대체 어떤 상태인가?

- 사용자가 이미 결제했는가?

- 이 주문이 환불 조건에 부합하는가?

이번에는 환불이 성공했고 최종 결과도 맞았지만, 이것은 십중팔구 "우연히 맞힌" 것일 뿐이다.

주문을 바꾸거나, 상품을 바꾸거나, 환불 규칙을 바꾸면 곧바로 문제가 생길 수 있다.

그래서 Agent를 테스트할 때는 "환불 성공" 한마디만 보고 PASS로 판정해서는 안 된다.

계속 점검해야 한다.

주문을 조회했는가? 환불 규칙을 점검했는가? 환불 자격을 확인했는가? 도구 호출 순서가 맞는가?

이것이 Behavioral Evaluation의 가치다.

그것이 주목하는 것은 이것만이 아니다.

"마지막에 일이 성사됐는가?"

한 걸음 더 나아가 점검한다.

"Agent가 올바른 흐름에 따라 일을 성사시켰는가?"

실제로 출시할 Agent에게 "우연히 맞는 것"은 터무니없이 부족하다. 우리에게 필요한 것은 결과가 올바를 뿐만 아니라 실행 과정도 올바른 것이다.

四、AI 어시스턴트에 '규정 준수 모니터링'을 달다: 행동 평가 (Behavioral Evaluation)

Agent를 평가할 때는 마지막에 답을 맞혔는지만 볼 것이 아니라, "중간에 어떻게 했는지"도 봐야 한다.

예를 들어 사용자가 이렇게 말한다.

"주문이 아직 발송되지 않았는데, 환불해 주세요."

우리는 먼저 테스트 Case 하나를 정의할 수 있다.

case = { "input" : "주문이 아직 발송되지 않았는데, 환불해 주세요" , "must_call" : [ "query_order" , "check_refund_policy" ], "forbidden_before_validation" : [ "refund_payment" ], "max_steps" : 8 }

여기서 사실 평가 시스템에 몇 가지를 알려주고 있는 셈이다.

- Agent는 반드시 먼저 주문을 조회하고, 환불 규칙을 점검해야 한다;

- 필요한 검증을 완료하기 전에는 곧바로 환불 도구를 호출해서는 안 된다;

- 전체 과제는 되도록 8단계를 넘지 않는 것이 좋다.

다음으로 Agent를 실행한다.

trace = agent.run(case[ "input" ])

그런데 여기에는 핵심 포인트가 하나 있다. Agent의 마지막 답만 볼 것이 아니라, 그것의 완전한 실행 궤적(Trace)까지 점검해야 한다.

예를 들어 그것이 호출한 도구를 모두 꺼내보자.

def get_tool_calls ( trace ): return [ event .tool for event in trace if event .type == "tool_call" ]

그다음 이 실행 과정들에 대해 "행동 단언"(Behavior Assertion)을 수행한다.

def evaluate_behavior ( trace, case ): tools = get_tool_calls(trace) missing_tools = [ tool for tool in case [ "must_call" ] if tool not in tools ] return { "missing_tools" : missing_tools, "steps" : len (trace), "passed" : ( len (missing_tools) == 0 and len (trace) <= case [ "max_steps" ] ) }

이렇게 하면 우리가 평가하는 것은 "과제가 마지막에 완료됐는지"만이 아니라, 호출해야 할 도구를 호출했는지, 호출 순서가 맞는지, 필요한 검증을 했는지, 실행 단계가 너무 많은지, 그리고 조건이 충족되지 않았을 때 위험한 작업을 미리 실행하지는 않았는지까지 한 걸음 더 판단할 수 있다.

최종 Evaluation 보고서는 이렇게 될 수 있다.

Final Answer: PASS Business Result: PASS Tool Selection: PASS Tool Sequence: FAIL Required Validation: FAIL Steps: 5 Overall: FAIL

이 결과는 상당히 흥미롭다. Agent가 마지막에 실제로 환불 처리를 잘 해냈고 답도 문제없어 보이지만, 올바른 흐름에 따라 실행하지는 않았다. 예를 들어, 환불 규칙을 점검하기도 전에 곧바로 환불 인터페이스를 호출했을 수 있다.

그래서 이것만 알려주는 것보다

성공률: 86%

이런 행동 평가가 더 가치 있다.

"성공률 86%"는 Agent가 대략 어떻게 수행하는지만 알려줄 수 있지만, Behavioral Evaluation은 한 걸음 더 나아가 Agent가 도대체 어디서 틀렸는지, 도구를 잘못 선택했는지, 순서가 틀렸는지, 필요한 검증을 빠뜨렸는지, 아니면 실행 과정이 너무 길었는지를 알려줄 수 있다.

실제로 출시할 Agent에게 "결과가 올바른 것"은 중요하고, "과정이 올바르고 통제 가능한 것" 역시 마찬가지로 중요하다.

五、왜 이 일이 Harness와 이렇게 관계가 깊을까?

최근 AI Agent 분야에는 아주 뜨거운 단어가 하나 있다. Agent Harness.

이 단어는 다소 추상적으로 보이지만, 간단히 이해하면 이렇다. 모델은 "두뇌"이고, Harness는 이 두뇌를 둘러싸고 세워진 일整套의 "작업 시스템"으로, 모델이 실제로 일을 해내도록 책임진다.

예를 들어, Agent가 과제를 완수하려면 모델만으로는 부족하다. 그것은 자신이 어떤 역할을 맡아야 하는지, 어떤 정보를 기억해야 하는지, 언제 도구를 호출해야 하는지, 과제가 실패하면 재시도해야 하는지, 복잡한 과제를 어떻게 나눠야 하는지, 그리고 코드가 어디에서 안전하게 실행되어야 하는지를 알아야 한다.

이런 능력들 뒤에는 보통 다음과 같은 것들이 관련된다:

System Prompt Context Memory Tools MCP Skills Subagent Retry Planning Session Sandbox Execution Loop ...

이것들을 조합한 것을 통틀어 Agent의 Harness라고 부를 수 있다.

그래서 이제 하나의 Agent의 능력을 평가할 때, 단순히 이렇게 생각할 수는 없다:

Agent 능력 = Model 능력

실제에 더 가까운 것은:

Agent 능력 = Model × Harness × Context × Tool × Runtime Configuration

즉, 같은 모델이라도 서로 다른 Harness에 넣으면 최종 성능이 크게 달라질 수 있다.

예를 들어, 마찬가지로 Agent에게 Bug 하나를 고치게 할 때: 하나는 코드를 읽고 조언만 할 수 있고, 다른 하나는 스스로 프로젝트를 검색하고, 코드를 수정하고, 테스트를 실행하고, 실패를 발견하고, 로그를 분석하고, 다시 수정한 뒤 테스트를 한 번 더 돌릴 수 있다.

둘은 같은 모델을 사용할 수 있지만, 최종 효과는 전혀 다르다.

이것이 최근 반년 동안 Harness Engineering이 테스트 개발 엔지니어에게 점점 더 주목할 만한 가치가 있는 이유이기도 하다.

Harness가 복잡할수록 검증해야 할 것도 많아지기 때문이다: 컨텍스트가 제대로 전달되었는가? 도구를 제대로 호출했는가? 실패 후 재시도가 합리적인가? 다중 Agent 협업은 오류가 나지 않는가? Sandbox는 안전한가? 실행 루프가 멈춰버리지는 않는가?

다시 말해, 과거에는 주로 "소프트웨어 기능이 올바른가"를 테스트했다면, 이제는 "Agent가 과연 안정적이고 올바르게 일을 끝낼 수 있는가"도 테스트하기 시작해야 한다.

그리고 바로 이 지점이 테스트 개발 엔지니어가 매우 익숙해하면서도, 가치를 발휘할 기회가 매우 큰 곳이다.