CCAF 101

Tool Selection & Disambiguation

8 min read

Tool Selection & Disambiguation

이 문서는 CCAF Domain 2를 이해하기 위한 개념 설명용 노트다.
여기서는 개별 도구 하나의 설명 품질보다, 도구 집합 전체에서 경계를 어떻게 나눌 것인가를 다룬다. 즉 tool selection을 단순한 모델 추론 문제가 아니라, toolset-level boundary design 문제로 이해하는 데 초점을 둔다.

tool selection 문제는 왜 생기는가

Agent Loop에서 모델은 종종 여러 도구 중 하나를 골라야 한다.
이때 실패는 단순히 모델이 “멍청해서” 생기는 것이 아니다.

실제로는:

  • 도구 이름이 비슷하거나
  • 설명이 겹치거나
  • 책임 경계가 모호하거나
  • 입력 구조가 지나치게 유사하면

모델은 충분히 헷갈릴 수 있다.

즉 tool selection 실패는 종종

선택 문제라기보다 경계 설계 문제

다.

disambiguation이란 무엇인가

Disambiguation은 여러 도구가 비슷해 보일 때, 각 도구가 언제 선택되어야 하는지를 더 분명하게 만드는 작업이다.

즉 목적은:

  • “이 도구도 되고 저 도구도 될 듯”한 상태를 줄이고
  • 각 도구의 책임을 더 분리하고
  • 모델이 선택 시 더 적은 모호성을 느끼게 만드는 것

이다.

한 문장으로 줄이면:

Disambiguation은 도구를 더 많이 설명하는 작업이 아니라, 도구들 사이를 덜 겹치게 만드는 작업이다.

겹치는 도구는 왜 위험한가

비슷한 도구가 많으면 선택지가 늘어나므로 좋아 보일 수 있다.
하지만 실제로는 다음 문제가 생긴다.

  • 잘못된 도구를 선택할 확률이 올라간다
  • 같은 기능을 여러 방식으로 호출하게 된다
  • 결과 일관성이 떨어진다
  • 에러 복구 경로도 복잡해진다

예를 들어:

  • search_docs
  • lookup_docs
  • retrieve_knowledge
  • find_internal_doc

이 네 개가 실제론 거의 비슷한 역할을 한다면, 모델은 선택 경계를 안정적으로 잡기 어렵다.

즉 도구 수가 많다고 capability가 좋아지는 것은 아니다.

많은 도구보다, 경계가 분명한 도구 집합이 더 낫다.

선택 경계를 어떻게 나눠야 하는가

도구 경계를 나눌 때는 보통 아래 축이 유용하다.

1. 데이터 소스 기준

  • 내부 DB 조회
  • 외부 웹 검색
  • 파일 시스템 읽기

2. 작업 목적 기준

  • 조회
  • 수정
  • 실행
  • 검증

3. 결과 책임 기준

  • 사실 조회
  • 변환/가공
  • 상태 변경
  • 검증/승인

이런 기준으로 나누면 각 도구의 역할이 더 선명해진다.

예를 들어:

  • search_web는 외부 공개 웹 검색
  • lookup_customer는 내부 고객 DB 조회
  • process_refund는 실제 상태 변경

이렇게 구분되면 선택 품질도 올라간다.

이름과 설명으로 어떻게 구분을 강화할 수 있는가

도구를 구분하려면 이름만 다르게 짓는 것으로는 부족하다.
설명에서도 차이를 드러내야 한다.

예:

  • search_web: 외부 공개 웹 자료 검색용
  • search_internal_docs: 내부 문서 저장소 검색용
  • lookup_customer: 검증된 customer ID 기반 고객 조회용

이렇게 하면:

  • 데이터 소스
  • 입력 조건
  • 사용 시점

이 분명해진다.

즉 disambiguation의 핵심은:

각 도구가 무엇을 하는지보다, 다른 도구와 무엇이 다른지를 드러내는 것

이다.

좋은 toolset은 어떤 모습인가

좋은 toolset은 단순히 기능이 많은 집합이 아니다.
보통 아래 특징을 가진다.

  • 각 도구의 책임이 겹치지 않는다
  • 비슷한 기능이 있더라도 차이가 명확하다
  • 입력 조건이 선명하다
  • 결과 책임이 분리되어 있다
  • 모델이 “언제 이 도구를 써야 하는지” 쉽게 추론할 수 있다

즉 좋은 toolset은 풍부한 카탈로그라기보다,

선택 가능한 경계가 잘 정리된 카탈로그

다.

좋은 toolset과 나쁜 toolset의 차이

나쁜 toolset

  • 기능이 겹치는 도구가 많다
  • 같은 데이터를 여러 도구가 비슷하게 다룬다
  • 이름은 다르지만 설명상 차이가 거의 없다
  • 모델이 도구 간 우선순위를 추론해야 한다

좋은 toolset

  • 각 도구의 책임이 분리돼 있다
  • 겹치더라도 차이가 설명에 명시돼 있다
  • 도구 간 선택 기준이 명확하다
  • 모델이 억지 추론보다 명시적 경계에 기대어 선택할 수 있다

즉 tool selection 품질은 개별 도구 설명만이 아니라, 도구 집합 전체의 경계 구조에서 나온다.

흔한 오해

“도구가 많을수록 더 똑똑한 시스템이다”

그렇지 않다. 너무 많으면 오히려 selection noise가 커진다.

“설명에 기능만 적으면 된다”

아니다. 선택 기준과 구분 기준까지 드러나야 한다.

“겹치는 도구는 모델이 알아서 잘 고른다”

그 기대는 위험하다. 경계가 모호하면 모델도 흔들린다.

한 문장 요약

Tool selection 품질은 개별 도구 설명의 품질만이 아니라, 도구 집합 전체의 책임 경계를 얼마나 명확하게 분리했는지에 크게 좌우된다.

관련 개념

그래프 뷰

백링크