지난 포스트에 대해 한 독자가 당시에는 제가 답변할 수 없었던 지적을 해주셨고, 그래서 직접 측정해 보았습니다.

지적 내용: "도구 추가(tool added)"가 자동으로 안전한 변경을 의미하는 것은 아니다. 저는 모든 기존 호출이 여전히 자신의 스키마(schema)에 따라 검증되기 때문에, 추가 사항을 무해한 것으로 분류해 왔습니다. 하지만 검증(validation)이 선택(selection)은 아닙니다. 새로운 중복 도구가 기존에 다른 곳으로 라우팅되던 호출을 가로챌 수 있으며, 이때 아무런 오류도 발생하지 않습니다. 에이전트는 그저 조용히 다른 일을 하기 시작할 뿐입니다.

저는 이름 중복(name-overlap)이 명백한 첫 번째 근사치이며 분명히 불완전하다고 말했습니다. 그것은 두 가지 모두에 해당합니다. 측정 결과는 다음과 같습니다.

측정 (The measurement)

익명 핸드셰이크(anonymous handshake)를 완료하는 레지스트리 등록 MCP 서버 377개, 7,164개의 도구, 각 서버 내의 모든 쌍을 비교 — 총 170,345개의 쌍. 이름이 대부분의 토큰(token)을 공유하거나, 설명(description)이 심하게 중복되거나, 혹은 두 가지 모두 적당히 겹치는 경우 해당 쌍을 플래그(flag)로 표시했습니다.

377개 서버 중 173개(45.8%)가 최소 하나 이상의 혼동 가능한 도구 쌍을 보유하고 있습니다.

전체 '쌍(pairs)' 중 플래그가 지정된 비율은 1.15%에 불과하며, 이는 반대 측면에서의 동일한 사실을 보여줍니다: 혼동은 도구 표면(tool surfaces)이 큰 서버에 집중되어 있으며, 고르게 퍼져 있지 않습니다.

대표적인 사례:

list_skills            <->  get_skills                     (동일한 토큰)
legislation            <->  list_legislation
tf_briefing            <->  tf_premium_briefing
...

list_skills 대 get_skills는 정직한 사례입니다. 인간에게는 명확한 차이가 있습니다. 하지만 토큰 압박(token pressure) 하에서 평면적인 리스트 중 하나를 선택해야 하고, 설명을 주의 깊게 읽을 수도 있고 안 읽을 수도 있는 모델에게 이는 아무도 기록하지 않는 동전 던지기와 같습니다.

비중이 클 것이라 예상했지만 그렇지 않았던 하위 분류

저의 첫 번째 분석에서는 이름이 상업적 등급 단어 — free 대 premium, pro, plus — 에 의해서만 달라지는 도구들을 찾았습니다. 만약 에이전트가 여기서 잘못 선택한다면, 그것은 정확성 버그(correctness bug)가 아니라 결제(billing) 버그입니다. 이것이 어디에나 있을 것이라고 느꼈습니다.

1차 통과 결과, 101개 서버에 걸쳐 147개의 쌍이 발견되었습니다 — 26.7%.

그 수치는 약 33배 정도 잘못되었습니다. 그 이유는 누구나 저지르기 쉬운 두 가지 문제 때문이며, 이를 명시하고자 합니다.

1. 저는 deep, full, advanced, extended 등을 등급(tier) 단어로 포함했습니다. 하지만 이 단어들은 등급을 나타내는 것이 아니라, 도구가 수행하는 작업의 양을 설명합니다. 예를 들어 deep_research와 bet_research가 과금 쌍(billing pair)으로 분류되었는데, 이는 말도 안 되는 결과입니다.
2. 하나의 게이트웨이(gateway.pipeworx.io)가 13개의 별도 엔드포인트에 걸쳐 동일한 도구 설계를 게시하고 있습니다. 저는 이를 13번으로 집계했습니다. 이는 하나의 설계 결정일 뿐, 13개의 발견이 아닙니다.

모호하지 않은 과금 관련 단어로 기준을 좁히고 도구 쌍의 시그니처(signature)를 기준으로 중복을 제거한 결과: 3개의 서버에서 47개의 고유한 쌍이 발견되었습니다. 1% 미만입니다.

따라서 (과금 관련) 뚜렷한 사례는 드뭅니다. 하지만 존재하며, 다음과 같은 형태를 띱니다:

tf_briefing              <->  tf_premium_briefing
get_game_recommendation  <->  get_premium_game_recommendation
gpt55_summarize          <->  gpt55_summarize_plus / gpt55_summarize_pro
...

한 서버가 네 가지 별도 작업에 대해 무료 버전과 _plus, _pro 변형 버전을 노출하고 있습니다. 이름의 유사성만으로 이들 사이에서 선택하는 에이전트는, 자신이 구매 결정을 내리고 있다는 신호도 없이 구매 결정을 내리고 있는 셈입니다.

이 분석을 통해 얻은 결론

일반적인 문제는 실재합니다: 서버의 약 46%가 에이전트에게 최소 하나 이상의 진정으로 모호한 선택지를 제공합니다. 이미 40개의 도구가 있는 서버에 도구를 추가하는 것은 아무런 영향이 없는 작업(no-op)이 아니며, 저에게 이의를 제기했던 독자의 지적이 맞았습니다.

과금 관련 사례는 드물지만 가드레일(guard rail)을 세울 가치가 있는 사례입니다. 왜냐하면 실패가 직접적인 비용으로 이어지면서도 오류 표면(error surface)이 없는 유일한 부류이기 때문입니다. 유료 및 무료 변형 버전을 노출한다면, 단순히 도구 이름에만 적지 말고 설명(description)에 가격을, 어노테이션(annotations)에 등급을 기재하십시오.

그리고 이 측정 방식은 어휘적(lexical)이며, 이는 실제적인 한계입니다. 이름이 동일한 두 도구가 서로 다른 기능을 수행한다는 점을 파악할 수 없으며, 유능한 모델이라면 아주 쉽게 구분할 수 있는 쌍들을 오류로 분류할 것입니다. 45.8%라는 수치를 모호성의 상한선(upper bound)이자, 이 문제가 기울여야 할 주의력의 하한선(lower bound)으로 간주하십시오.

방법론 (Method)

이전 포스트와 동일한 시드(seed)를 사용한 무작위 샘플(random.seed(20260730))을 익명 핸드셰이크(anonymous handshake)에 응답하는 5,346개의 레지스트리 엔드포인트(registry endpoints)에서 추출하였으므로, 시리즈 전체에서 결과를 비교할 수 있습니다. initialize → notifications/initialized → tools/list 과정을 거치며, SSE 프레임(SSE frames)과 Mcp-Session-Id 스레딩(threading)을 처리합니다. 쌍별 비교(Pairwise comparison)에는 이름 토큰(name tokens)과 불용어(stopwords)를 제거한 설명 용어(description terms)에 대한 자카드 유사도(Jaccard similarity)를 사용합니다.

가공되지 않은 도구 인벤토리(Raw tool inventories)는 캐시(cached)되어 있으므로, 정의를 더 엄격하게 수정한 후 동일한 데이터에 대해 계층 분석(tier analysis)을 다시 실행했습니다. 덕분에 출판 후에가 아니라 출판 전에 33배의 오류를 잡아낼 수 있었습니다.

이전 글: 스키마 드리프트(schema drift)는 비율이 아니라, 끊임없이 움직이는 소수의 서버 집합입니다.