#Agent는 왜 안 써도 될 도구를 자꾸 쓰는가

← 전체 목차 · 이전: 파라미터가 자꾸 빠지는 건 모델 탓이 아니다 · 다음: LLM 도구 호출 Schema 설계

단일 턴 질의응답에서는 거의 흔들리지 않던 모델이, Agent로 만들어 도구를 열어주는 순간 잡담에도 도구를 호출하고, 같은 도구를 반복 호출하고, 전혀 무관한 인터페이스를 건드리고, 파라미터를 없는 데서 지어낸다. 로컬 데모에서는 도구 수가 적고 시나리오가 단순해 잘 드러나지 않다가, 프로덕션에 올라가서야 오작동·데이터 오염·무의미한 요청 폭주로 터진다. 이 문서가 다루는 것은 "어떤 도구를 고를지"가 아니라 그보다 앞선 질문, **"애초에 도구를 써야 하는가, 그리고 언제 그만 써야 하는가"**다.

#왜 도구만 열어줘도 남용이 시작되는가

대형모델은 이어쓰기 관성을 갖는다. 도구 목록이 컨텍스트에 보이는 순간, 모델은 그 목록을 다음에 "채워야 할 것"으로 여기는 쪽으로 기울며, 외부 능력이 전혀 필요 없는 요청에도 습관적으로 파라미터를 생성해 호출을 트리거한다. 이것은 모델이 멍청해서가 아니라 도구 목록 자체가 이미 하나의 강한 프롬프트로 작동하기 때문이다.

#네 가지 근원

#대책 1: 전치 의도 게이트

도구 결정 흐름에 들어가기 전에 분류 단계를 하나 둔다.

사용자 요청
  ├─ 상식 / 잡담 / 문안 작성 / 이미 아는 정적 지식
  │    → 모델이 바로 답변, 도구 흐름에 아예 진입하지 않음
  └─ 실시간 데이터 / 외부 인터페이스 / 업무 조작이 필요
       → 그제서야 도구 결정 흐름으로 진입

이 한 층만으로도 불필요한 호출의 상당 부분이 원천 차단된다 — 도구 자체를 고치기 전에, 애초에 도구까지 갈 필요가 없는 요청을 걸러내는 것이 투자 대비 효과가 가장 크다.

#대책 2: 동적 도구 탑재

전체 도구를 상시 전역 공개하지 않는다.

• 사용자 신원별로 탑재
• 대화 시나리오별로 탑재
• 작업 유형별로 탑재
• 무관한 도구는 자동으로 숨김

목적은 매 순간 모델이 실제로 고려해야 할 도구 집합 자체를 줄여, 선택 압박과 혼동 확률을 근본에서 낮추는 것이다.

#대책 3: 종료 조건을 명시적으로 설계

"도구를 호출했다"와 "작업이 끝났다"는 별개의 사실이다. 종료 판단이 없으면 모델은 결과를 못 미덥게 여기고 같은 도구를 반복 호출한다.

의미적 판단이 실패할 때를 대비해 기계적 상한을 반드시 같이 둔다. 하나만 있으면 둘 중 하나의 실패 모드(무한 재시도, 혹은 아직 안 끝났는데 강제 종료)에 그대로 노출된다.

#"어떤 도구를 고를지"와 무엇이 다른가

Agent가 호출할 도구를 아는 법은 "여러 도구 중 올바른 하나를 어떻게 고르는가"를 다룬다. 이 문서는 그보다 한 단계 앞과 뒤에 있다 — 앞에서는 "도구 목록에 들어갈 필요가 있는가"를 걸러내고, 뒤에서는 "언제 그만 불러야 하는가"를 판단한다. 도구 선택이 정확해도 이 두 판단이 없으면 잡담에 인터페이스를 두드리고, 이미 끝난 일을 계속 반복 실행하게 된다.

#핵심 통찰

1. "도구가 보이는 것" 자체가 이미 하나의 프롬프트다 — 어떤 도구가 이번 턴에 보이느냐는 도구 설명을 얼마나 잘 썼느냐보다 강한 통제 변수다. 도구 가시성을 관리하는 것이 도구 문구를 다듬는 것보다 먼저다.
2. 단일 턴이 안정적이고 다중 턴(Agent)이 무너지는 근본 원인은 컨텍스트 길이가 아니라 동작 공간이다 — 단일 턴의 출력 공간은 텍스트뿐이지만, Agent의 출력 공간에는 "어떤 도구를 호출하고 무엇을 넘길지"가 추가된다. 환각의 결과물이 잘못된 문장에서 실제 부작용을 낳는 호출로 바뀌므로, 같은 오류율이라도 대가가 한 자릿수 이상 커진다.
3. 로컬 데모는 남용의 사각지대다 — 데모는 도구가 적고 시나리오가 단순하며 동시성·재시도가 없어, 혼동 매칭과 중복 호출이라는 두 문제를 정확히 가려 준다. Agent 평가는 반드시 "도구 수가 많고 시나리오가 섞인" 조건에서 해야 실제 실패율이 드러난다.
4. "전부 허용"과 "전부 금지"는 같은 오류의 두 얼굴이다 — 둘 다 판단 비용을 생략한다. 진짜 공학적 답은 분급이다: 의도로 나누고, 신원으로 권한을 나누고, Schema로 합법성을 나누고, ID로 멱등을 나눈다. 각 층은 자신이 맡은 한 종류의 실패만 해결한다.
5. 무효 호출의 상당 부분은 도구 결정에 진입하기도 전에 없앨 수 있다 — 가장 투자 대비 효과가 큰 위치는 맨 앞단이다. 도구 자체를 손보기 전에 먼저 분류부터 해야 한다.
6. 가시성 통제와 종료 조건은 대칭적인 두 경계다 — 앞단(전치 게이트, 동적 탑재)은 "불필요한 진입"을 막고, 뒷단(종료 조건)은 "불필요한 반복"을 막는다. 둘 중 하나만 갖추면 절반짜리 방어선이다.

#엔지니어링 실전 Tips

• 전치 의도 게이트를 옵션이 아니라 첫 관문으로 만들 것: "도구 흐름에 들어가기 전"이라는 위치가 핵심이다. 도구 사이에서 그나마 덜 틀린 것을 고르게 하는 것보다, 애초에 진입을 막는 편이 훨씬 싸다.
• 도구 노출을 권한 시스템의 일부로 다룰 것: 신원·시나리오·작업 유형별 탑재를 기존 RBAC/테넌시 체계와 묶으면 도구 가시성이 권한 모델의 자연스러운 연장이 된다.
• 종료 조건은 의미 축과 기계 축을 함께 둘 것: 의미적 판단(결과가 요구를 충족했는가)이 실패하는 경우를 대비해 최대 호출 횟수 상한을 반드시 병행한다.
• 비슷한 기능의 도구는 위험 지표로 관리할 것: 파라미터가 비슷하거나 기능이 겹치는 도구 쌍은 우선 합치거나 격리 대상으로 표시해 둔다.
• 도구 수를 KPI로 삼지 말 것: "도구가 많을수록 강력하다"는 직관은 도구가 많을수록 남용과 혼동도 함께 늘어난다는 사실 앞에서 뒤집힌다. 도구를 늘리기 전에 가시성 통제와 종료 조건이 먼저 갖춰져 있는지 확인할 것.
• 후치 복기를 파이프라인에 넣을 것: 각 호출의 의도 판정, 탑재 목록, 검증 결과, 종료 판단 근거를 기록해 두면 규칙을 지속적으로 개선하는 되먹임 고리가 된다.
• 무호출 판단과 종료 판단을 분리해서 측정할 것: "불필요하게 호출된 비율"과 "필요 이상으로 반복 호출된 비율"은 서로 다른 지표다. 하나로 뭉뚱그리면 어느 층이 고장 났는지 알 수 없다.