AI 에이전트 도구를 전부 넣지 말고 필요한 것만 고르는 방법

플랫폼에서 GitHub, , Notion, Stripe, , 같은 외부 서비스 커넥터를 붙이면, 각 서비스마다 여러 도구 설명을 모델에 알려줘야 한다. 처음 방식은 모든 커넥터의 모든 를 매 대화마다 모델 문맥에 넣는 것이었다. 8개 커넥터에 각각 약 15개 도구만 있어도 시작 전부터 수천 토큰의 설명이 들어가고, 도구가 100개를 넘으면 모델이 엉뚱한 도구를 고르거나 잘못된 값을 만들거나 멈추는 일이 늘었다. Qwen3처럼 자체 인프라에서 돌리는 은 200개 도구 중 하나를 안정적으로 고르는 데 한계가 있었다.

더 나은 방식은 사용자의 말에서 필요한 커넥터를 먼저 찾고, 그 커넥터의 관련 도구 몇 개만 모델에 넘기는 것이다. 이를 위해 각 도구의 이름, 설명, 소속 커넥터를 색인해 두고, 대화 문맥에 맞는 도구를 검색한 뒤 그 결과만 도구 호출 과정에 연결했다. 임베딩은 “화난 고객에게 답해 달라” 같은 의도를 잡는 데 강하고, BM25는 Stripe나 refund처럼 정확한 제품명과 행동 단어를 잡는 데 강했다. 두 검색 점수를 함께 써서 상위 도구만 고르자 도구 설명 문맥은 수천 토큰에서 수백 토큰으로 줄었고, 잘못된 도구 호출도 줄었으며, 커넥터가 늘어나도 전체 성능이 덜 흔들렸다.

다만 검색이 맞는 도구를 놓치면 모델은 그 도구를 아예 쓸 수 없기 때문에 항상 켜 두는 기본 도구 묶음과 재검색 예비 절차가 필요했다. 기준값을 너무 엄격하게 잡으면 필요한 도구가 빠지고, 너무 느슨하게 잡으면 다시 과부하가 생긴다. 여러 서비스로 이어지는 작업은 처음 한 번만 고르면 부족하고, 매 대화 턴마다 다시 골라야 한다.

핵심 포인트

  • 모든 를 매번 문맥에 넣으면 토큰 비용과 지연 시간이 커진다.
  • 도구가 100개를 넘으면 모델이 잘못된 도구나 잘못된 입력값을 고를 위험이 커졌다.
  • 도구 이름, 설명, 소속 커넥터를 색인하고 필요한 도구만 검색해 모델에 넘겼다.
  • 임베딩은 의도 파악에, BM25는 제품명과 정확한 행동 단어 찾기에 도움이 됐다.
  • 검색 실패에 대비해 기본 도구 묶음, 재검색, 기준값 조정이 필요하다.
원문 보기