도구 선택은 이름이 아니라 스키마가 바꾼다

arXiv에 공개된 Which Metadata Matters for LLM Tool Selection in MCP? Evidence from Controlled Factor-Level Interventions는 MCP 환경에서 LLM의 도구 선택을 다룬 연구입니다. 원문 링크는 제목 아래에 걸어두었습니다. 이 연구가 내세우는 주장은 한 문장으로 정리됩니다. MCP에서 모델이 어떤 도구를 고를지는 구현 코드가 아니라 메타데이터가 정하고, 그중에서도 파라미터 스키마가 가장 크게 흔든다는 것입니다.

저는 이 한 문장을 처음 봤을 때보다, 그 뒤에 붙은 실험 방식을 보고 더 오래 머물렀습니다. 이름과 설명과 스키마를 한 번에 뭉뚱그려 비교하지 않고, 매번 딱 하나의 요인만 바꿔서 선택이 어떻게 달라지는지 물었기 때문입니다. 이번 글에서는 그 설계가 왜 필요했는지부터, 367,174개 도구를 훑은 관찰이 무엇을 보여주는지, 그리고 실제 시스템을 만들 때 어디를 먼저 고쳐야 하는지까지 순서대로 따라가 보겠습니다.

저는 이 논문을 왜 그냥 넘기지 못했을까요

에이전트를 만들어본 분이라면 비슷한 답답함을 느껴본 적이 있을 겁니다. 분명히 기능이 맞는 도구를 등록해 두었는데, 모델은 엉뚱한 도구를 집어 듭니다. 코드를 다시 봐도 문제는 없고, 프롬프트를 고쳐도 그때뿐입니다. 그러다 문득 도구 설명 한 줄을 바꾸면 거짓말처럼 잘 되기도 하죠. 저는 이런 경험을 몇 번 하고 나면 다음 질문이 바로 생긴다고 봅니다. 도대체 모델은 도구의 무엇을 보고 고르는 걸까요.

이 논문이 제 눈에 들어온 이유는 바로 그 질문을 정면으로 붙잡았기 때문입니다. MCP에서는 모델이 도구의 구현을 직접 보지 못합니다. 볼 수 있는 것은 서버 이름과 도구 이름, 설명문, 파라미터 스키마 같은 메타데이터뿐인데, 이 겉모습이 선택을 좌우한다면 우리가 도구를 설계하는 방식도 달라져야 합니다. 지금까지는 파라미터 스키마를 호출이 잘 되느냐의 문제로만 봤는데, 선택 자체가 바뀐다면 이야기가 다르니까요.

그렇다면 이름이 멋지면 더 잘 뽑힐까요. 설명을 길게 쓰면 유리할까요. 아니면 스키마 모양이 결정적일까요. 저는 이 숫자보다 그 뒤의 구조가 더 중요하다고 봅니다. 어떤 요인이 진짜로 선택을 움직이는지 알아야, 다음에 도구를 만들 때 힘을 어디에 쓸지 정할 수 있기 때문입니다.

모델은 도구의 속을 보지 않습니다

MCP 구조를 떠올려보면 이 연구의 출발점이 바로 이해됩니다. 모델 앞에 놓이는 것은 함수 본문이 아니라, 이 도구가 무엇이고 어떤 인자를 받는지를 적은 명세입니다. 사람이 식당에서 메뉴판만 보고 음식을 고르는 것과 비슷합니다. 주방에서 어떻게 만드는지 볼 수 없으니, 메뉴에 적힌 이름과 설명과 가격 표시를 보고 판단할 수밖에 없죠. 모델도 마찬가지라서, 메타데이터가 곧 도구의 얼굴이 됩니다.

문제는 그 얼굴들이 생각보다 많이 닮았다는 데 있습니다. 연구진이 367,174개 MCP 도구의 메타데이터를 훑었을 때 드러난 것도 이 지점입니다. 기능적으로 비슷한 도구들인데도 파라미터를 드러내는 방식이 제각각이었고, 이름이나 설명은 거의 같은데 정작 인자를 받는 모양은 달랐습니다. 저는 여기서 조금 멈칫했습니다. 우리가 서로 다른 도구라고 믿었던 것들이, 모델 눈에는 이름만 비슷한 채 스키마만 다른 선택지로 보였을 수도 있기 때문입니다.

실제 시스템 관점에서 보면 다음 질문이 바로 생깁니다. 이렇게 겉은 비슷하고 속은 다른 도구들이 즐비하다면, 모델은 무엇을 단서로 삼을까요. 사람이 메뉴판에서 애매한 표현보다 재료와 조리법이 또렷한 메뉴를 고르듯, 모델도 어딘가에서 확실한 단서를 찾을 가능성이 큽니다. 이 논문은 그 단서가 이름인지 설명인지 스키마인지를 가려내는 데서 시작합니다.

이름이 같아도 스키마는 따로 놉니다

367,174개라는 숫자는 그 자체로도 할 말이 많습니다. 일일이 눈으로 볼 수 없는 규모라서, 비슷해 보이는 도구들이 얼마나 많은지가 숫자로 드러나야 비로소 실감이 나기 때문입니다. 연구진의 관찰을 풀어보면 이렇습니다. 기능적으로 같은 일을 하는 도구들인데, 이름은 같거나 거의 같고 설명도 비슷한 결을 갖고 있는데, 파라미터 스키마는 따로 노는 경우가 적지 않았습니다.

어떤 도구는 받는 값을 낱개로 펼쳐놓고, 어떤 도구는 하나의 객체 안에 묶어서 받습니다. 어떤 도구는 선택지가 또렷하고, 어떤 도구는 뭉뚱그려져 있습니다. 호출하는 입장에서는 둘 다 같은 결과를 낼 수 있지만, 고르는 입장에서는 전혀 다른 인상을 남기죠. 사람이 이력서를 볼 때 경력란 제목은 같은데 상세 경력의 적힌 방식이 전혀 다른 경우를 떠올리면 비슷합니다. 제목만 보면 같은 사람 같지만, 항목을 펼치는 순간 누구에게 일을 맡길지가 달라집니다.

여기서 재미있는 질문이 생깁니다. 이런 차이가 우연히 생긴 것이라면 그냥 두어도 될까요. 저는 그렇지 않다고 봅니다. 저희가 새로운 AI 아키텍처를 볼 때도 benchmark 숫자만 보지는 않습니다. 실제로 무엇이 바뀌었고, 그 변화가 시스템에서 어떤 비용 구조를 만드는지를 함께 봅니다. 같은 맥락에서 스키마의 들쭉날쭉함은 단순한 스타일 차이가 아니라, 선택 편향을 만들어내는 구조일 수 있습니다. 그렇다면 다음 단계는 관찰을 넘어 실험이어야 합니다. 실제로 하나씩 바꿔보면 선택이 어떻게 달라지는지 말이죠.

하나씩만 바꿔서 물어보면 답이 나옵니다

제가 이 논문에서 가장 흥미롭게 본 부분은 실험 설계입니다. 다섯 가지 모델과 다섯 가지 작업을 놓고, 매번 정확히 하나의 메타데이터 요인만 바꿔서 비교했기 때문입니다. 서버 이름이면 서버 이름만, 도구 이름이면 도구 이름만, 설명이면 설명만, 스키마면 스키마만 바꿉니다. 나머지는 전부 고정합니다. 이렇게 해야 무엇이 선택을 움직였는지 말할 수 있으니까요.

이 방식이 왜 중요할까요. 평소에 우리가 도구를 고칠 때는 여러 가지를 한꺼번에 손대기 때문입니다. 이름을 바꾸면서 설명도 다듬고, 스키마도 손보고, 그러고 나서 잘 되면 설명 덕분이라고 짐작합니다. 하지만 그 짐작은 틀리기 쉽습니다. 진짜로 먹힌 것은 스키마였는데 이름 덕분이라고 믿고 다음에도 이름만 다듬는 식이죠. 요인별 통제라는 말은 거창하지만, 하는 일은 단순합니다. 범인을 하나씩 따로 불러서 묻는 것입니다.

작업도 다섯 가지로 나눈 점이 눈에 띕니다. 하나의 작업에서만 통하는 효과가 아니라, 여러 상황에서 반복되는지를 보고 싶었던 것입니다. 모델도 다섯 가지라서, 특정 모델의 버릇인지 아니면 여러 모델에 걸친 경향인지 가릴 수 있습니다. 물론 다섯이라는 숫자가 세상의 모든 경우를 담지는 못합니다. 여기서는 조금 조심해서 읽을 필요가 있습니다. 다만 같은 질문을 여러 모델과 여러 작업에 반복했다는 점에서, 한 번의 인상에 기대지 않으려는 태도는 분명합니다.

위치가 바뀌면 선택도 바뀌니까요

도구 선택 실험에서 가장 골치 아픈 것은 위치입니다. 앞에 놓인 도구가 더 잘 뽑히는 경향이 있어서, 내용을 바꿨는데 사실은 위치 때문에 바뀐 것처럼 보일 수 있기 때문입니다. 메뉴판 맨 위가 잘 팔리는 것과 같은 이치죠. 맛 때문인지 자리 때문인지 가리려면 자리를 바꿔가며 팔아봐야 합니다.

연구진은 그래서 도구의 위치를 균등하게 배치했습니다. 같은 비교를 위치만 뒤바꿔서 반복하면서, 위치가 준 이득을 걷어내고 내용의 효과를 따로 추정한 것입니다. 이때 쓴 도구가 조건부 로지스틱 회귀인데, 이름이 어렵게 들리지만 하는 일은 직관적입니다. 위치라는 배경 소음을 줄이고, 각 요인이 선택 확률을 얼마나 밀어 올렸는지를 위치 조정 값으로 읽어내는 것이죠.

이 차이는 생각보다 중요합니다. 위치 효과를 그대로 두면 작은 이름 효과가 크게 보이고, 반대로 스키마의 효과가 위치에 묻힐 수도 있기 때문입니다. 저는 이런 대목을 볼 때마다 실험의 정직함이 떠오릅니다. 정직하다는 것은 좋은 숫자를 뽑는 것이 아니라, 숫자가 부풀려질 통로를 미리 막는 것이니까요. 위치를 균등하게 깔고 나서도 남는 효과가 진짜 효과에 가깝습니다. 그렇다면 이제 그 진짜 효과를 볼 차례입니다.

스키마를 건드리면 선택이 가장 크게 흔들립니다

결과부터 말하면 스키마가 가장 크고 가장 일관되게 선택을 움직였습니다. 다른 요인을 고정하고 스키마만 바꾸면, 여러 모델과 여러 작업에 걸쳐 선택이 눈에 띄게 달라졌습니다. 이름이나 서버 이름을 바꿨을 때보다 흔들림이 컸고, 작업이 바뀌어도 방향이 쉽게 뒤집히지 않았다는 점이 눈에 띕니다.

표면적으로 보면 단순합니다. 실제로는 그렇지 않습니다. 스키마는 보통 호출 단계의 문제로 여겨졌기 때문입니다. 인자를 어떻게 넘길지의 약속이지, 어떤 도구를 고를지의 이유가 아니라고 생각했던 것이죠. 그런데 이번 결과는 그 경계를 허뭅니다. 스키마가 호출 방식뿐 아니라 선택 여부 자체에 영향을 준다는 것입니다. 메뉴판의 알레르기 표시가 주문 방식을 바꾸는 데 그치지 않고, 메뉴 선택 자체를 바꾸는 것과 비슷합니다.

개인적으로 인상 깊었던 점은, 이 효과가 특정 모델의 기벽처럼 보이지 않았다는 것입니다. 다섯 가지 모델에서 비슷한 결이 반복됐기 때문입니다.もちろん 모든 조건에서 똑같은 크기로 나타났다는 뜻은 아닙니다. 효과의 크기는 작업과 모델에 따라 달라질 수 있습니다. 그럼에도 스키마가 다른 요인보다 더 자주, 더 크게 움직였다는 순서는 꽤 또렷합니다. 이제 궁금해지는 것은 스키마 안에서도 어떤 모양이 더 잘 뽑히는지입니다.

낱개로 풀어놓은 파라미터가 더 잘 뽑힙니다

스키마 안을 더 들여다보면, 모델들은 묶음보다 낱개를 좋아하는 쪽으로 기울었습니다. 같은 일을 하는 도구라도, 인자를 최상위에 낱개로 펼쳐놓은 형태가 하나의 객체 안에 묶어두거나 합성된 형태로 감싼 경우보다 더 자주 선택됐습니다. 설명이 파라미터를 풀어줄 때도 선택이 올라가는 쪽으로 움직였고요.

왜 그럴까요. 저는 여기서 사람의 읽기 습관을 떠올렸습니다. 신청서에 적을 칸이 처음부터 나눠져 있으면 무엇을 적어야 할지 바로 감이 오는데, 기타 의견란 하나에 다 적으라고 하면 잠시 망설여집니다. 모델도 비슷한 것 아닐까요. 낱개로 펼쳐진 파라미터는 무엇을 채워야 하는지가 겉으로 드러나서, 요청과 대조하기가 쉽습니다. 반면 묶음 형태는 한 번 더 풀어봐야 해서, 그만큼 머뭇거림이 생기는 것이죠.

물론 낱개가 언제나 정답이라는 뜻은 아닙니다. 인자가 많아지면 명세가 길어지고, 토큰도 늘고, 관리도 귀찮아집니다. 실제 시스템 관점에서 보면 다음 질문이 바로 생깁니다. 선택은 잘 되는데 호출 비용이 늘어난다면 어디까지 풀어야 할까요. 그럼에도 선택 단계에서만큼은 또렷함이 이득이라는 신호는 분명합니다. 모호함을 줄이고 대조할 단서를 늘리면, 모델이 그 도구를 집어 들 확률이 올라갑니다.

이름을 아무리 다듬어도 선택은 잘 안 바뀝니다

반면 이름의 힘은 생각보다 약했고, 일관되지도 않았습니다. 서버 이름을 바꾸거나 도구 이름을 다듬어도 선택이 크게 움직이지 않거나, 움직이더라도 작업에 따라 방향이 달랐습니다. 설명도 파라미터를 풀어주는 경우가 아니라면, 이름과 비슷한 정도로 밋밋했습니다.

이 대목은 처음에 조금 의외로 느껴질 수도 있습니다. 우리는 이름을 짓는 데 많은 시간을 쓰기 때문입니다. 직관적인 이름이 좋은 도구라는 믿음이 있고, 실제로 사람에게는 그 믿음이 통합니다. 하지만 모델의 선택 화면에서 이름은 생각보다 얇은 단서인지 모릅니다. 이름이 그럴듯해도 인자를 어떻게 받는지가 불투명하면 손이 가지 않는 것이죠. 옷가게 간판이 예뻐도, 치수가 어떻게 나오는지 알 수 없으면 선뜻 고르지 못하는 것과 비슷합니다.

그렇다면 이름은 아무래도 좋은 걸까요. 저는 그렇게까지 읽지 않습니다. 이름이 전혀 쓸모없다는 이야기가 아니라, 선택을 뒤집을 만큼의 힘이 없다는 뜻에 가깝기 때문입니다. 여기서 조심할 점이 있습니다. 이름 효과가 작다고 해서 이름을 막 지어도 된다는 결론으로 뛰어가면 안 됩니다. 사람이 읽고 관리하는 데는 여전히 이름이 중요합니다. 다만 모델의 선택을 움직이는 지렛대로서는 스키마와 설명의 몫이 더 크다는 것이 이번 실험이 가리키는 방향입니다.

조건이 분명해지면 모델은 길을 찾습니다

이 연구에서 제가 앞으로 보고 싶은 것과 이어지는 장면이 있습니다. 요청에 분명한 조건이 있고, 그 조건을 만족하는 스키마가 하나뿐일 때의 이야기입니다. 이때는 다섯 가지 모델이 모두 위치 취향에도 흔들리지 않고 맞는 도구를 골랐습니다. 앞에 있느냐 뒤에 있느냐가 아니라, 조건에 맞느냐가 선택을 정한 것입니다.

이 결과는 마음에 들지만, 여기까지 일반화하기에는 조건을 봐야 합니다. 모델이 갑자기 똑똑해졌다는 뜻이 아니라, 대조할 단서가 또렷해지면 그 단서를 따라간다는 뜻에 가깝기 때문입니다. 스키마가 조건을 만족하는지가 겉으로 드러나면, 모델은 위치의 유혹을 뿌리치고 맞는 쪽을 집습니다. 반대로 말하면 평소의 흔들림은 모델이 게을러서가 아니라, 단서가 흐릿해서 생기는 것일 수 있습니다.

실제 장면을 하나 그려보면 감이 옵니다. 사용자가 날짜 범위를 따로따로 달라고 했는데, 한 도구는 시작일과 종료일을 낱개로 받고 다른 도구는 기간 객체 하나로 받는다고 해보죠. 이때 전자만 조건을 곧바로 만족한다면 모델은 위치와 상관없이 전자를 고릅니다. 당연해 보이지만, 당연한ことが 당연하게 일어나는 조건을 밝혔다는 데 의미가 있습니다. 조건을 명세에 새기고, 그 조건을 스키마에서 바로 대조할 수 있게 하면 선택은 생각보다 단단해집니다.

다음에 도구를 만들면 어디부터 고쳐야 할까요

이제 실무의 질문으로 돌아올 차례입니다. 그렇다면 다음에 MCP 도구를 만들 때 어디부터 손대야 할까요. 이 논문의 답은 꽤 분명합니다. 이름부터 다듬기 전에 스키마부터 또렷하게 만들라는 것입니다. 받는 값을 낱개로 풀 필요가 있는지, 설명이 각 파라미터의 역할을 풀어주고 있는지, 요청의 조건과 스키마가 바로 대조되는지를 먼저 보는 것이죠.

저희가 시스템을 볼 때 자주 하는 실수 중 하나는, 선택과 호출을 따로 떼어 생각하는 것입니다. 호출이 잘 되면 선택도 따라올 거라고 믿는 것이죠. 그런데 이번 결과는 그 순서를 뒤집습니다. 선택이 먼저 흔들리면 호출은 기회조차 얻지 못합니다. 아무리 잘 만든 함수도 뽑히지 않으면 없는 것과 마찬가지니까요. 그래서 스키마 문서는 호출 안내문을 넘어 선택을 위한 전시이기도 합니다.

물론 남은 질문도 적지 않습니다. 다섯 가지 모델과 다섯 가지 작업 너머에서는 어떻게 될까요. 한국어나 다른 언어로 된 설명에서도 같은 결이 나올까요. 도구가 수십 개로 늘어나는 실제 목록에서는 위치 효과가 더 커질까요. 저는 이 숫자보다 그 뒤의 구조가 더 중요하다고 봅니다. 구조가 말해주는 것은 단순합니다. 모델은 메타데이터로 판단하고, 그중에서도 대조하기 쉬운 스키마를 좋아한다는 것입니다. 다음 도구를 등록하기 전에 스키마를 한 번 더 펼치고, 설명 한 줄을 덧붙이는 일부터 시작하면 어떨까요. 그 작은 차이가 모델의 손을 끄는 힘이 될 수 있습니다.