AI 에이전트가 환각을 일으키는 대신 올바른 도구를 호출하는지 테스트하는 방법

당신의 에이전트에는 12개의 도구(tools)가 등록되어 있습니다. 당신이 고객의 주문 상태를 조회하라고 요청합니다. 에이전트는 get_order_status 대신 search_knowledge_base를 호출합니다. 에러는 발생하지 않으며, 에이전트는 그럴듯하게 들리는 텍스트 응답을 반환합니다. 당신은 실수를 인지하지 못한 채 이를 배포할 수도 있습니다.

이것은 도구를 사용하는 에이전트에서 발생하는 가장 흔한 '조용한 실패(silent failure)' 모드이며, 많은 팀이 이를 잡아낼 체계적인 방법을 갖추고 있지 않습니다.

도구 선택이 실패하는 이유

LLM(대규모 언어 모델)은 어떤 도구를 호출해야 하는지 "아는" 것이 아니라, 프롬프트(prompt)가 주어졌을 때 가장 가능성 높은 다음 토큰(token)을 예측합니다. 이는 다음을 의미합니다:

모호한 도구 설명 (Ambiguous tool descriptions) → 잘못된 도구 선택
너무 많은 도구 (Too many tools) → 모델이 가장 유사한 의미적 일치 항목을 선택
프롬프트 드리프트 (Prompt drift) (시스템 프롬프트 변경) → 이전에 올바랐던 선택이 깨짐
모델 버전 업데이트 (Model version updates) → 동작이 조용히 변화함

도구 구현에 대한 단위 테스트(unit tests)로는 이를 잡아낼 수 없습니다. 최종 답변이 괜찮아 보이는지뿐만 아니라, 어떤 도구가 호출되었는지를 단언(assert)하는 평가(eval) 케이스가 필요합니다.

필요한 테스트 구조

각 테스트 케이스에는 세 가지가 필요합니다:

입력 (Input) — 사용자 메시지 (및 선택적으로 대화 기록)
예상되는 도구 호출 (Expected tool call) — 이름 + 주요 인자(arguments)
통과 조건 (Pass condition) — 정확한 일치(exact match), 부분 일치(partial match), 또는 "X를 호출해서는 안 됨"

이를 위해 잘 작동하는 구체적인 YAML 형식을 소개합니다:

# tool_selection_tests.yaml

- id: order_status_lookup
...

match_mode에 관한 참고 사항: 아래의 하네스(harness)는 exact_name_only와 exact_name_partial_args 두 가지 모드를 지원합니다. 인식되지 않는 값은 기본적으로 exact_name_only로 설정되며, 조용히 통과하는 대신 경고를 로그에 남깁니다.

실제 에이전트에 적용하기

다음은 OpenAI 함수 호출(function calling)을 사용하는 최소한의 Python 하네스입니다. 사용하기 전에 두 가지 중요한 사항을 확인하십시오:

실제 시스템 프롬프트를 포함하세요. run_agent_get_tool_call 함수는 플레이스홀더(placeholder)를 사용합니다. 평가(evals) 시에는 실제 운영 중인 에이전트와 동일한 시스템 프롬프트를 사용해야 합니다. 그렇지 않으면 실제 동작을 테스트하는 것이 아닙니다.
CI에서 실행하기 전에 재시도(retries) 및 에러 처리(error handling)를 추가하세요.

import yaml
import json
from openai import OpenAI
...

위의 세 가지 YAML 케이스에 대해 실행하면 다음과 같은 출력이 생성됩니다:

PASS [order_status_lookup]
PASS [refund_eligibility_check]
PASS [ambiguous_product_question]
...

실패가 발생하면 잘못된 도구 이름(wrong tool name), 금지된 도구 호출(forbidden tool called), 또는 인자 값 오류(argument value off)와 같이 정확한 불일치 사항이 출력되므로, 무엇을 수정해야 하는지 즉시 알 수 있습니다.

케이스가 실패했을 때 해야 할 일

실패하는 케이스는 다음 세 가지 중 하나를 알려줍니다:

도구 설명(Tool description)이 모호함 — 모델이 의미론적으로 유사한 다른 도구와 이를 구별하지 못했습니다. 해당 도구를 사용하지 않아야 하는 상황에 대해 더 구체적으로 설명을 다시 작성하세요.
시스템 프롬프트(System prompt)가 도구 선택을 방해함 — "응답하기 전에 항상 검색하세요"와 같은 지침은 올바른 라우팅(routing)을 방해할 수 있습니다. 프롬프트에 암시적인 편향(implicit biases)이 있는지 감사(audit)하세요.
모델이 실제로 인자(argument)를 추출하지 못함 — 자연어에서 days_since_purchase를 추출하는 것과 같은 케이스의 경우, 도구 시그니처(tool signature)가 현실적인지, 아니면 도구 호출 전에 전처리(pre-processing) 단계에서 추출을 처리해야 하는지 검토하세요.

테스트 출력은 정확한 실패 신호를 제공합니다. 해결책은 도구 구현(tool implementations)이 아니라, 거의 항상 도구 설명이나 시스템 프롬프트에 있습니다.

규모 확장하기 (Scaling Up)

세 가지 케이스만으로는 실제 에이전트를 커버할 수 없습니다. 고객 지원 에이전트를 위한 프로덕션급 평가 스위트(eval suite)에는 일반적으로 다음이 필요합니다:

해피 패스(Happy path) 케이스: 모든 도구에 대해 (깨끗한 입력값과 함께 올바른 라우팅이 이루어지는 경우)
적대적(Adversarial) 케이스: 잘못된 도구를 트리거하도록 설계된 입력값
경계(Boundary) 케이스: 올바른 도구가 명확하지 않은 모호한 문구
호출 금지(Must-not-call) 케이스: 모호한 입력 시 절대 실행되어서는 안 되는 민감한 도구 (예: cancel_order)

의미 있는 커버리지를 확보하려면 보통 최소 20~30개의 케이스가 필요합니다. 구조는 동일하게 유지됩니다. 더 많은 YAML 항목과 동일한 테스트 하네스(harness)를 사용하면 됩니다.

요약

조용한 도구 오라우팅 (Silent tool misrouting)은 예외를 발생시키지 않고 종종 그럴싸해 보이는 출력을 생성하기 때문에 에이전트 버그 중 가장 포착하기 어려운 문제 중 하나입니다. 해결 방법은 간단합니다. 예상되는 도구 호출 (tool calls)을 구조화된 테스트 케이스로 정의하고, 모든 프롬프트 또는 모델 변경 시 실제 에이전트를 대상으로 이를 실행하며, 실패를 회귀 (regressions)로 취급하는 것입니다. 위의 하네스 (harness)는 최소 기능 버전 (minimum viable version)입니다. 실제 사용 중인 도구, 실제 시스템 프롬프트 (system prompt), 그리고 귀하의 사용 사례에서 중요한 실패 모드 (failure modes)를 커버할 수 있는 충분한 케이스를 추가하여 확장하십시오.

무료 5개 케이스 스타터 팩: github.com/weiseer/ai-agent-qa-eval-pack-starter · 전체 23개 케이스 팩: gumroad.com/l/dcipxt · 이메일로 새로운 케이스 받기: dl.weiseer.com/cases

도구 선택 실패는 근본적으로 사양 (specification)의 문제입니다. 모델은 각 도구가 언제 사용되어야 하고 언제 사용되지 않아야 하는지를 도구 설명 (tool descriptions)에 명확하게 인코딩했을 때만 올바르게 라우팅할 수 있습니다. 구조화된 평가 스위트 (eval suite)를 구축하면 이러한 경계(boundaries)를 명시적으로 만들 수밖에 없으며, 모델이나 프롬프트가 변경될 때마다 이를 실행하면 보이지 않던 회귀 위험을 측정 가능하고 수정 가능한 신호로 바꿀 수 있습니다.