MCP 도구 검색과 동적 로딩

도구가 많아질수록 에이전트에는 전체 목록보다, 필요한 도구를 다시 찾을 수 있는 작은 검색 인터페이스가 필요합니다.

스키마가 컨텍스트를 차지하는 문제

Model Context Protocol(MCP)은 서버가 제공하는 도구를 공통 형식으로 노출하는 프로토콜입니다. 도구 하나에는 이름과 설명뿐 아니라 입력을 정의하는 구조화된 스키마가 붙습니다. 출력 스키마와 실행 관련 속성이 추가될 수도 있습니다.

클라이언트가 모든 정의를 모델에 넣으면 도구 수와 스키마 크기만큼 입력이 늘어납니다. 문제는 토큰 비용에 그치지 않습니다. 비슷한 이름과 설명이 한꺼번에 보이면 모델이 엉뚱한 도구를 고르거나 필요한 도구를 지나칠 수 있습니다.

MCP 도구 명세에서 tools/list는 서버의 도구 정의를 페이지 단위로 반환합니다. 이 목록을 수집하는 일과 모든 스키마를 매 추론에 노출하는 일은 별개입니다. 전체 목록은 시스템이 관리하되, 모델에는 현재 작업과 관련된 일부만 줄 수 있습니다.

검색과 로드의 분리

검색 후 로드하는 구조는 고정된 메타 도구와 작업별 실행 도구를 나눕니다. 메타 도구는 도구 검색과 로드를 담당하며 항상 모델에 보입니다. 실행 도구는 검색 결과에서 선택된 뒤에만 모델의 호출 목록에 들어갑니다.

Dynamic ReAct는 이 흐름을 search_tools와 load_tools로 나눴습니다. 검색은 원자적인 질의로 후보의 설명과 식별자를 반환합니다. 모델은 필요한 식별자만 골라 해당 도구의 실제 스키마를 로드합니다.

중요한 성질은 검색 결과를 전부 실행 가능 상태로 만들지 않는 데 있습니다. 검색은 후보 회수를 넓게 맡고, 로드는 모델이 비교할 최종 스키마 수를 줄입니다.

색인 문서와 실행 스키마

검색 색인은 사용자의 표현과 도구 기능을 연결하기 위한 문서입니다. 이름, 설명, 매개변수 설명, 서버나 애플리케이션 같은 메타데이터를 한 텍스트로 묶어 임베딩할 수 있습니다. 임베딩은 텍스트의 의미를 비교 가능한 수치 벡터로 바꾸는 표현입니다.

실행 스키마는 호출 인자와 결과의 계약입니다. 검색 품질을 높이려고 설명을 보강할 수는 있지만, 보강된 문장을 실행 계약으로 사용하면 안 됩니다. 검색 결과의 식별자로 레지스트리나 MCP 서버에서 현재 스키마를 다시 읽어 바인딩해야 합니다.

MCP 서버는 도구 목록 변경 알림을 지원할 수 있습니다. 클라이언트는 알림을 받으면 색인을 무효화하거나 다시 만들 수 있습니다. 알림을 지원하지 않는 서버에는 버전이나 주기적 동기화 같은 별도 갱신 기준이 필요합니다.

후보에서 빠진 도구

검색 결과에 관련 도구 하나가 들어왔다는 사실과 필요한 도구가 모두 들어왔다는 사실은 다릅니다. 적중률(Hit Rate)은 상위 K개에 관련 도구가 하나라도 있는 질의의 비율입니다. 재현율(Recall)은 질의에 필요한 전체 관련 도구 가운데 검색된 비율입니다.

Semantic Tool Discovery는 2026년 3월 공개된 동료 심사 전 원고입니다. 저자들의 5개 서버, 121개 도구, 140개 질의 벤치마크에서 K=3 적중률은 97.1%였지만 재현율은 59.6%였습니다. 여러 도구가 필요한 작업에서는 높은 적중률만 보고 검색이 충분하다고 판단할 수 없습니다.

후보 회수에 실패하면 모델은 보지 못한 도구를 선택할 수 없습니다. 특히 여러 시스템을 잇는 요청을 한 문장으로 검색하면 한쪽 도메인의 후보만 상위에 모일 수 있습니다. 작업을 원자적인 하위 작업으로 나누어 각각 검색하는 이유가 여기에 있습니다.

운영에서는 제한된 재검색 경로를 두는 편이 좋습니다. 필요한 기능이 후보에 없거나 로드한 스키마로 계획한 인자를 표현할 수 없을 때 질의를 바꿔 다시 찾습니다. 검색 범위 확대와 재시도 횟수에는 상한을 두고, 그래도 모호하면 사용자에게 필요한 대상을 묻습니다.

이 재검색 규칙은 두 논문이 측정한 결론이 아니라 운영 설계 제안입니다. 목적은 최초 검색의 누락을 복구하면서 검색만 반복하는 루프를 막는 것입니다. 재검색 질의에는 원래 문장보다 현재 계획에서 빠진 기능과 대상 시스템을 명시하는 편이 낫습니다.

검색과 권한의 경계

도구 검색은 관련성을 판단하고, 권한 검사는 호출 가능성을 판단합니다. 검색 결과에 나타났거나 모델에 로드됐다는 사실은 실행 권한을 뜻하지 않습니다. 두 판단을 하나로 합치면 오래된 색인이나 잘못된 메타데이터가 권한 우회로 이어질 수 있습니다.

후보를 찾기 전에는 사용자, 조직, 연결된 계정에 따라 검색 가능한 목록을 거릅니다. 호출 직전에는 현재 자격 증명과 작업 범위로 권한을 다시 확인합니다. 쓰기나 외부 전송처럼 부작용이 있는 작업은 제품 정책에 맞는 사용자 확인을 별도로 거칩니다.

MCP 명세도 사람이 도구 호출을 거부할 수 있는 상호작용을 권고합니다. 검색 단계에서도 비공개 도구 이름과 설명이 새지 않게 해야 합니다. 따라서 검색 필터, 실행 권한, 사용자 확인은 서로 다른 통제 지점으로 기록하고 시험해야 합니다.

실무 평가 기준

오프라인 검색 평가는 후보 회수 능력을 봅니다. Hit@K와 Recall@K를 함께 측정하고, 첫 관련 도구의 순위를 보는 평균 역순위(Mean Reciprocal Rank, MRR)도 기록합니다. 도구 하나가 필요한 질의와 여러 서버를 잇는 질의를 나누면 전체 평균에 가려진 실패를 찾기 쉽습니다.

온라인 평가는 검색 이후의 결과를 봅니다. 전체 작업 성공률, 잘못된 도구 호출, 인자 검증 오류, 재검색 발생률, 권한 거부를 따로 남깁니다. 검색 지연과 모델에 전달한 스키마 토큰도 측정해야 비용과 정확도의 교환 관계를 판단할 수 있습니다.

비교 기준에는 전체 도구 로드, 검색 상위 K개 즉시 로드, 검색 후 선택적 로드를 함께 둡니다. 도구 설명을 바꾸거나 레지스트리가 갱신된 조건도 시험해야 합니다. 권한이 없는 도구가 의미상 가장 가깝지만 권한 때문에 제외돼야 하는 사례도 넣어야 합니다.

두 연구의 수치는 출발점으로만 보는 편이 안전합니다. Semantic Tool Discovery의 결과는 하나의 임베딩 모델과 연구진이 만든 벤치마크에서 나왔습니다. Dynamic ReAct도 자체 레지스트리와 구현을 사용했으므로, 실제 도구 설명과 작업 분포로 다시 측정해야 합니다.

정리

MCP 도구가 많아지면 전체 스키마를 매번 넣기보다 검색과 로드를 분리할 수 있습니다. 검색 색인은 후보를 찾기 위한 표현이고, 실행에는 현재의 정식 스키마와 별도 권한 검사가 필요합니다. 최초 후보가 필요한 도구를 모두 담지 못할 수 있으므로 제한된 재검색 경로와 Recall 중심 평가를 둬야 합니다. 2026년 9월 확인 기준 두 연구는 가능성을 보여 주지만, 운영값은 실제 레지스트리와 작업 분포에서 다시 정해야 합니다.