에이전트가 잘못된 도구를 호출할 때: Function-Calling을 프로덕션에 배포할 수 있을 만큼 신뢰할 수 있게 만드는 방법

우리가 에이전트(Agent)를 실제 도구 앞에 처음 배치했을 때, 매우 교훈적인 일이 발생했습니다. "고객의 마지막 주문을 환불해줘"라는 요청을 받았을 때, 에이전트는 issue_refund 대신 cancel_subscription을 호출했습니다. 두 도구 모두 존재했습니다. 두 도구 모두 불만족한 고객과 타당하게 연관되어 있었습니다. 모델은 잘못된 것을 선택했고, 완전한 확신을 가지고 실행했습니다.

이것이 바로 데모 영상에서는 생략되는 에이전트 엔지니어링(Agent Engineering)의 부분입니다. 모델이 텍스트를 생성하게 하는 것은 쉽습니다. 하지만 모델이 시스템 내에서 행동을 취하게 하는 것 — 함수 호출(Function Calling), API 호출, 상태 변경 — 은 신뢰성이 존재하느냐 아니냐의 문제입니다. 여기에서 우리는 Function-Calling을 프로덕션(Production) 환경에 배치할 수 있을 만큼 신뢰할 수 있게 만드는 방법을 소개합니다.

더 적은 도구, 더 명확한 이름

에이전트에게 더 많은 도구를 줄수록, 잘못 선택할 확률도 높아집니다. 우리는 단일 에이전트가 목적이 중복되는 도구를 20개 이상 갖게 되면 정확도가 급격히 떨어지는 것을 목격했습니다. 두 가지 해결책이 있습니다. 도구 세트를 작고 뚜렷하게 유지하고, 혼란이 생기기 어려울 정도로 각 도구의 이름과 설명을 정밀하게 지정하는 것입니다. "완료된 주문에 대해 금전적 환불을 실행합니다; 구독을 취소하지는 않습니다"라는 설명이 붙은 refund_order는 모호한 handle_order보다 언제나 낫습니다. 설명은 단순한 문서가 아닙니다. 그것은 모델이 결정을 내릴 때 실제로 읽는 지침(Instruction)입니다.

인자를 신뢰하기 전에 검증하라

에이전트가 올바른 도구를 선택하더라도, 말도 안 되는 값을 전달할 수 있습니다: 주문 금액보다 큰 환불 금액, 잘못된 형식의 날짜, 존재하지 않는 고객 ID, 음수 수량 등입니다. 모델은 검증된 인자가 아니라 그럴싸해 보이는 인자를 생성하고 있는 것입니다. 따라서 우리가 노출하는 모든 도구는 무언가를 수행하기 전에 서버 측에서 타입 체크(Type checks), 범위 체크(Range checks), 존재 여부 체크(Existence checks), 비즈니스 규칙 체크(Business-rule checks)를 통해 입력값을 엄격하게 검증합니다. 잘못된 호출은 데이터를 손상시키는 대신, 에이전트가 읽고 수정할 수 있는 명확한 에러를 반환합니다. 에이전트가 제공하는 인자는 인터넷상의 익명 사용자가 입력한 값과 똑같이 취급하십시오. 즉, 절대 신뢰해서는 안 됩니다.

"읽기(Read)" 도구와 "쓰기(Write)" 도구를 분리하고, 쓰기 작업에 게이트를 설치하라

데이터를 읽는 것은 위험도가 낮지만, 데이터를 변경하는 것은 그렇지 않습니다. 저희는 도구를 이 두 가지 클래스로 분리하고 매우 다르게 취급합니다. 에이전트가 자유롭게 호출할 수 있는 '읽기(Read)' 도구와, 돈을 이동시키거나, 메시지를 보내거나, 기록을 삭제하거나, 주문을 변경하는 등 모든 '쓰기(Write)' 도구는 추가적인 게이트를 거칩니다. 여기에는 더 엄격한 유효성 검사, 속도 제한(rate limits), 그리고 가장 높은 위험도의 작업을 위해서는 인간의 승인 단계가 포함됩니다. 에이전트가 행동을 준비하면, 사람이 이를 확인하는 방식입니다. 특정 워크플로우에 대한 신뢰가 쌓임에 따라 게이트를 느슨하게 할 수 있습니다. 하지만 그곳에서 시작해서는 안 됩니다.

작업을 Idempotent하고 되돌릴 수 있게 설계하라

에이전트는 재시도합니다. 도구 호출이 시간 초과되면, 에이전트는 실패했다고 가정하고 다시 호출하지만, 실제로는 첫 번째 호출이 성공적으로 진행된 경우입니다. 이제 두 번 환불을 하게 됩니다. 방어책은 모든 상태 변경 도구에 Idempotency Key를 적용하는 것입니다. 이는 서버가 확인하여 반복적인 호출이 다시 행동을 취하기보다 원래의 결과를 반환하도록 하는 결정론적 식별자입니다. 그리고 비즈니스상 허용되는 곳이라면 어디든, 에이전트가 즉시 커밋하는 되돌릴 수 없는(irreversible) 작업보다는, 사람이 해제할 수 있는 '초안(draft)' 또는 '보류(pending)' 상태와 같은 되돌릴 수 있는 작업을 선호해야 합니다.

에이전트에게 침묵 대신 정직한 오류를 제공하라

도구가 실패했을 때 무엇을 반환하는지가 엄청나게 중요합니다. 일반적인

프로덕션 환경에서 에이전트가 예상치 못한 행동을 할 때, 이를 이해할 수 있는 유일한 방법은 에이전트가 어떤 도구를, 어떤 인자(arguments)와 함께, 어떤 순서로 호출했는지, 그리고 무엇이 반환되었는지를 정확히 확인하는 것입니다. 우리는 모든 도구 호출(tool invocation)을 구조화된 기록으로 로그(log)에 남깁니다. 이는 선택 사항이 아닙니다. 이는 "한 시간 만에 문제를 해결했다"와 "무슨 일이 일어났는지 전혀 모르겠다"의 차이를 만듭니다. 또한, 이는 다음 회귀(regression)가 배포되기 전에 이를 잡아낼 수 있는 평가 세트(evaluation set)를 구축할 수 있게 해줍니다.

채팅이 아닌 행동을 테스트하라

대부분의 팀은 에이전트가 옳은 말을 "하는지"를 테스트합니다. 에이전트가 옳은 행동을 "하는지"를 테스트하는 팀은 훨씬 적습니다. 우리는 "이미 환불된 주문에 대해 고객이 환불을 요청하는 경우", "사용자가 취소를 요청했지만 실제로는 일시 정지를 원하는 경우"와 같은 시나리오 세트를 구축하며, 에이전트가 생성하는 단어가 아니라 에이전트가 실제로 수행하는 도구 호출(tool calls)을 검증(assert)합니다. 진짜 버그는 바로 그곳에 숨어 있으며, 이것이 바로 행동을 취하는 에이전트(action-taking agents)를 당당하게 배포할 수 있는 유일한 방법입니다.

챗봇에서 에이전트로의 전환은 단어를 생성하는 것에서 행동을 취하는 것으로의 전환이며, 행동에는 결과가 따릅니다. 신뢰할 수 있는 함수 호출(function-calling)은 단 하나의 기술이 아닙니다. 그것은 엄격한 도구 세트, 강력한 검증(validation), 게이트가 있는 쓰기(gated writes), 멱등성(idempotency), 정직한 오류, 그리고 행동을 확인하는 테스트와 같은 작은 규율들의 집합입니다. 이러한 요소들을 갖추면 에이전트는 진정으로 유용해집니다. 이를 건너뛴다면, 당신은 프로덕션 시스템에 예측 불가능한 손을 배포한 셈이 됩니다.

Shanti Infosoft 소개: Shanti Infosoft는 16개 이상의 산업 분야에서 700개 이상의 프로젝트를 수행한 CMMI Level 5 AI 개발 기업입니다. 우리는 팀이 AI 아이디어에서 신뢰할 수 있는 프로덕션급 소프트웨어로 나아갈 수 있도록 돕습니다 - shantiinfosoft.com | AI 개발 서비스.

만약 당신의 에이전트가 불안할 정도로 자주 잘못된 도구를 호출한다면, 우리가 배포할 수 있을 만큼 신뢰할 수 있을 때까지 함수 호출(function-calling) 레이어를 강화해 드릴 수 있습니다. 저희 팀과 상담하세요.

Rishabh Jain은 Shanti Infosoft의 디렉터로, 이곳의 팀은 실제 비즈니스 운영을 위한 AI 에이전트(AI agents) 및 자동화(automation)를 구축합니다.