지연 로딩된 MCP 도구, 이름을 모르면 검색해도 안 나온다

여러 개의 MCP 서버와 수백 개의 스킬을 붙인 에이전트 하네스를 운영하고 있고, 토큰 비용을 아끼려고 도구 스키마를 미리 다 띄우지 않고 필요할 때만 불러오는 지연 로딩(deferred loading)을 쓰고 있거나 도입을 고민 중인 엔지니어라면 이 글이 유용합니다. 이 연구는 지연 로딩이 실제로 얼마나 토큰을 아끼는지가 아니라, 에이전트가 애초에 존재를 모르는 도구를 검색으로 찾아낼 수 있는지를 실측한 결과입니다. 결론부터 말하면, 도구 이름과 작업 어휘가 겹치지 않으면 검색은 거의 작동하지 않습니다.

문제의식: 도구가 있는데 왜 못 쓰나

에이전트가 대형 프로덕션 하네스 안에서 “이 함수 시그니처를 바꾸면 어디가 깨지는지” 묻는 상황을 생각해 보면 이 문제가 선명해집니다. 하네스에는 정확히 이 영향 범위를 심볼 그래프 위에서 계산해 주는 코드그래프 탐색 도구가 이미 연결돼 있습니다. 도구는 살아 있고 한 번의 호출이면 닿습니다. 그런데 에이전트는 이 도구를 쓰지 않습니다. 하네스가 도구 스키마를 지연 로딩하기 때문에, 평소엔 이름만 보이고 실제로 쓰려면 명시적인 검색 호출을 먼저 거쳐야 하기 때문입니다. 에이전트는 자기 말로 “이 함수를 호출하는 곳을 전부 찾아서 뭐가 깨지는지 보자” 같은 질의를 만듭니다. 이 문장은 codegraph_impact라는, 그래프 노드 위의 영향 범위라는 말로 설명된 도구 이름과 어휘적으로 닮은 데가 없습니다. 검색은 엉뚱한 것들을 돌려주고, 에이전트는 결국 수작업 grep 루프로 돌아가 토큰을 훨씬 더 쓰고도 더 부실한 답을 냅니다. 에러는 하나도 나지 않았습니다. 도구는 기능적으로 그냥 없었던 것과 같습니다.

이 실패 양상을 이 연구는 콜드스타트 도구 블라인드니스(cold-start tool blindness)라고 부릅니다. Anthropic의 code-execution-with-MCP 설계는 대표적인 작업의 도구 관련 컨텍스트를 약 15만 토큰에서 약 2천 토큰으로, 98.7% 줄였다고 보고했습니다. 도구 신원을 가볍게 노출하고 정의는 필요할 때 불러오는 이 방식은 이제 프로덕션 하네스의 표준이 되어가고 있습니다. 그런데 이 흐름을 다루는 기존 도구 검색 연구는 거의 전부 질의가 이미 잘 만들어져 있다고, 즉 에이전트가 자신이 뭘 찾는지 최소한 어느 정도는 알고 있다고 가정합니다. 벤치마크에서는 합리적인 가정이지만, 프로덕션에서는 정확히 그 가정이 지연 로딩이 없애버리는 지점입니다. 스키마가 숨겨진 상태에서는 이름이 유일한 신호이고, 에이전트의 작업 어휘와 도구의 명명 어휘가 겹치지 않으면 검색기가 아무리 뛰어나도 순위를 매길 대상 자체가 없습니다.

무엇을 어떻게 측정했나

이 연구는 1,600개 넘는 스킬과 여러 MCP 서버를 함께 호스팅하는 실제 프로덕션 Claude Code 기반 하네스에서, 지연 로딩되는 26개 도구의 진짜 레지스트리를 그대로 가져다 썼습니다. 작업 세션 관리 도구 17개(CronCreate, Monitor, SendMessage 등), 코드그래프 탐색 도구 7개(codegraph_callees, codegraph_impact 등), 일반 웹 도구 2개(WebFetch, WebSearch)로 구성됩니다. 코퍼스 규모가 결과에 영향을 주는지 보기 위해 여기에 관련 없는 합성 더미 도구를 채워 넣어 26개(더미 없음), 61개, 150개, 300개 네 가지 규모로 늘렸습니다.

핵심 조작은 각 도구마다 과제 문장을 두 벌씩 만든 데 있습니다. 정렬(aligned) 과제는 도구 이름과 설명에 등장하는 어휘를 그대로 써서, 에이전트가 무엇을 찾는지 어느 정도 알고 있는 상황을 흉내 냅니다. 비정렬(unaligned) 과제는 같은 필요를 완전히 다른 어휘로 바꿔 써서, 도구의 존재 자체를 모르는 에이전트가 자기 말로만 필요를 설명하는 상황을 흉내 냅니다. 두 조건 모두에서 검색 질의는 오직 과제 문장의 단어에서만 만들어지고, 도구의 실제 이름은 한 번도 알려주지 않습니다. 조작이 제대로 됐는지 확인하기 위해 질의와 대상 도구 텍스트 사이의 토큰 중복도를 측정했더니, 정렬 조건은 평균 6.42개, 비정렬 조건은 평균 0.038개로 어휘 중복이 약 두 자릿수 차이가 났습니다. 검색은 결정론적인 BM25로 실행했고, 이 모든 측정은 GPU 없이 CPU 컨테이너에서 실측했습니다.

핵심 결과: 정렬 여부가 만드는 벼랑

전체 코퍼스 규모를 통틀어 정렬 조건은 언제나 완벽했습니다. 26개 도구 전부, 26·61·150·300개 어떤 코퍼스 규모에서도 BM25는 정렬 과제의 질의로 정답 도구를 1위에 올렸습니다. 도구 이름과 어휘가 겹칠 때는 지연 로딩이 광고된 그대로 작동합니다.

비정렬 조건은 무너집니다. Recall@1은 0.0769, 26개 중 겨우 2개만 찾아냅니다. Recall@3도 똑같이 0.0769로, 검색창을 3위까지 넓혀도 추가로 찾아지는 게 없습니다. Recall@5가 돼서야 0.1154, 3개로 늘지만, 나머지 23개(88.5%)는 상위 5개 안에 한 번도 등장하지 않습니다. 그것도 코퍼스 규모와 무관하게 26개에서든 300개에서든 완전히 동일합니다.

논문의 실측 결과를 나타낸 그림입니다. 정렬 질의는 모든 k에서 Recall@1=1.0을 유지하는 반면, 비정렬 질의는 같은 k에서 0.0769로 무너지고, 검색 범위를 k=5까지 넓혀도 추가로 회수되는 도구는 1개뿐입니다.

같은 검색기, 같은 26개 대상, 같은 코퍼스 위에서 1.000과 0.0769라는 이 간극은 성능이 조금 떨어지는 정도가 아니라 상전이에 가깝습니다. 차이를 만드는 유일한 변수는 과제 문장이 도구 이름과 어휘를 우연히 공유하느냐인데, 지연 로딩 정책 자체의 설계상 에이전트는 이 사실을 미리 알 방법이 없습니다.

사라지는 도구들, 그리고 규모와 무관하게 평평한 실패

도구별 순위를 뜯어보면 메커니즘이 뚜렷해집니다. CronCreate나 CronList는 비정렬 조건에서도 1위로 살아남는 몇 안 되는 도구입니다. 반복 작업을 다른 말로 풀어써도 스케줄링 관련 단어는 잘 사라지지 않기 때문입니다. 반대로 코드그래프 도구 7개(codegraph_callees, codegraph_impact 등)는 비정렬 질의에서 26개 중 21위에서 26위, 거의 꼴찌권입니다. “코드를 탐색해줘”, “누가 이 함수를 호출하는지 찾아줘”, “이걸 바꾸면 뭐가 깨지는지” 같은 개발자의 자연스러운 표현에는 codegraph, callees, 영향 범위(impact radius) 같은 단어가 전혀 등장하지 않습니다. 그 단어들은 오직 도구 자신의 이름과 설명 안에만 존재합니다. 하필 이 코드그래프 계열이 존재 자체를 가장 짐작하기 어려운 도구군이면서 동시에 어휘가 가장 특수한 도구군이라는 점에서, 지연 로딩 정책이 가장 나쁘게 맞물리는 조합이라 할 수 있습니다.

더 반직관적인 관찰은 비정렬 recall이 코퍼스 규모에 완전히 무관하다는 점입니다. 26개에서든 300개에서든 Recall@1은 0.0769, Recall@5는 0.1154로 그대로입니다.

논문의 실측 결과를 나타낸 그림입니다. 더미 도구 274개를 추가해도 비정렬 조건의 Recall@5는 0.1154에서 전혀 움직이지 않습니다. 실패의 원인이 건초더미 속 희석이 아니라 어휘 불일치 자체임을 보여줍니다.

BM25는 어휘가 겹치는 문서만 점수를 매기기 때문에, 어휘를 전혀 공유하지 않는 더미 도구들은 점수가 거의 0으로 수렴해 정답 도구의 순위를 밀어내지도, 경쟁하지도 않습니다. 26개 중 24위였던 도구는 더미 274개를 더 넣어도 여전히 실제로 점수가 매겨지는 도구들 사이에서 24위입니다. 즉 이 실패는 도구가 군중 속에 묻혀서 못 찾는 게 아니라, 질의와 도구가 애초에 서로 다른 어휘 공간에 살고 있어서 생기는 문제입니다. 그래서 도구 목록을 줄이는, 검색 문제에서 흔히 시도하는 첫 번째 해법은 이 실패를 완화하지 못합니다.

토큰 비용의 진짜 의미

토큰 절감 자체는 과장이 아닙니다. 300개 코퍼스에서 정렬 질의는 전량 preload 대비 91.4%를 아낍니다.

논문의 실측 결과를 나타낸 그림입니다. 300개 도구 규모에서 정렬 질의는 전량 preload 대비 91.4%의 토큰을 아끼지만, 이 절감폭은 어휘 정렬이라는 조건이 성립할 때만 유효합니다.

문제는 이 절감이 철저히 조건부라는 데 있습니다. 비정렬 조건은 검색이 실패해도 시도 자체의 토큰 비용은 그대로 발생합니다. 논문은 이걸 도구군 전체 수준의 통계값 하나로 정리합니다. 26개 도구 전부에 대해 검색을 시도한 총 토큰 비용을, 실제로 회수에 성공한 도구 수(2/26)로 나눈 값입니다. 회수 비율의 역수(13배)를 곱한 것과 같은데, 이 성공당 상각 비용은 모든 코퍼스 규모에서 전량 preload 비용을 넘어섭니다. 이건 재시도 비용이 아닙니다. 결정론적인 BM25는 같은 질의에 대해 실패하면 항상 똑같이 실패하기 때문에 다시 검색해 봐야 나아지지 않습니다. 비정렬 영역에서 지연 로딩은 할인을 사는 게 아니라 대부분 실패하는 검색에 토큰을 쓰고 있는 셈이고, 못 찾은 도구는 성능이 떨어진 게 아니라 그냥 없는 것과 같습니다.

회사, 사회, 과학에 남는 것

이 결과는 세 갈래로 쓸모가 있습니다. 회사 차원에서는 1,600개 넘는 스킬과 여러 MCP 서버를 계속 늘려가는 하네스에서 어떤 도구를 즉시 프리로딩하고 어떤 도구를 지연 로딩할지에 대한 구체적 기본 정책을 데이터로 뒷받침합니다. 논문은 이 오프라인 계산 가능한 기준을 그대로 제시합니다. 각 도구에 대해 의도적으로 어휘가 겹치지 않는 과제 문장을 써보고, 그 도구가 상위 k 안에 살아남는지 확인하는 것입니다. 살아남지 못하는 도구, 이번 실측에서는 코드그래프 계열 7개가 대표 사례인데, 이런 도구는 항상-노출 소집합으로 즉시 프리로딩합니다. 스키마당 약 80토큰이라 7개를 다 올려도 턴당 560토큰 정도로, 300개 도구 전체를 프리로딩할 때의 24,800토큰에 비하면 미미합니다. 반대로 스케줄링 계열처럼 작업 어휘 안에 도구 어휘가 자연스럽게 녹아 있는 롱테일은 그대로 지연 로딩을 유지해도 됩니다. 더 저렴한 보완책으로는 지연 인덱스의 한 줄 설명에 작업 측 동의어를 몇 토큰만 추가하는 어휘 보강도 있습니다.

사회 차원에서는 더 많은 에이전트 플랫폼이 비용 절감을 위해 온디맨드 도구 탐색을 채택하는 지금, 지연 로딩이 조용히 성능을 깎아 먹는 시점을 미리 특성화해 두면 프로덕션에 닿기 전에 이런 부류의 보이지 않는 실패를 피하는 데 도움이 됩니다. 과학 차원에서는 질의가 이미 잘 만들어져 있다고 가정하는 기존 스킬·RAG 라우팅 문헌의 전제를 도구 스키마 검색이라는 영역으로 확장해, 검색하는 에이전트가 애초에 어떤 후보 도구의 존재조차 모를 수 있는 상황을 이름 붙이고 실측했다는 데 의의가 있습니다. 같은 하네스에서 스킬 계층의 BM25 검색을 다뤘던 이전 연구는 질의 분해보다 검색기 자체의 동의어 확장이 라우팅 품질의 더 결정적인 병목이었다는 결과를 냈는데, 이번 논문이 관찰한 어휘 불일치 메커니즘과 정확히 같은 층위의 이야기입니다.

한계

이 연구는 스스로 하한값이라고 밝히고 있습니다. 측정은 에이전트가 항상 정직하게 검색을 시도한다고 관대하게 가정합니다. 콜드스타트 블라인드니스의 더 심각한 변형, 즉 애초에 어떤 도구가 있을 수도 있다는 생각조차 들지 않아 검색을 아예 시도하지 않는 경우는 recall 지표로는 잡히지 않고, 이번 측정 범위 밖입니다. 실제 배포에서 이 두 요소는 함께 나타나므로, 여기 보고된 수치는 총 콜드스타트 블라인드니스의 추정치가 아니라 하한선입니다.

recall이 코퍼스 규모와 무관하게 평평했던 결과도 조심스럽게 읽어야 합니다. 이번 더미 도구는 질의와 대상 어느 쪽과도 주제상 관련이 없도록 일부러 만들어졌는데, 이는 어휘 정렬 효과를 깔끔하게 격리하는 데는 좋지만 실제 MCP 레지스트리를 대표하지는 않습니다. 실제 환경에서는 독립적으로 만들어진 서버들이 search, list, get, status, run 같은 범용 어휘를 자주 재사용하고, 이런 더미는 실제 질의에 대해 의미 있게 점수를 받아 이미 낮은 순위의 대상을 더 밀어낼 수 있습니다. 그렇다면 recall은 규모가 커질수록 평평하지 않고 더 나빠질 수도 있습니다. 또한 이번 측정은 어휘 기반 검색기인 BM25 하나로만 이뤄졌고, recall은 어디까지나 실제 과제 성공의 대리 지표입니다. 임베딩 기반 밀집 검색기는 “이 함수를 호출하는 게 뭐지”와 “심볼의 호출자”처럼 어휘가 겹치지 않아도 의미로 다리를 놓을 수 있어 비정렬 recall을 상당히 끌어올릴 가능성이 있지만, 구현 어휘로 서술된 도구는 사용자 필요 어휘와는 여전히 의미적으로 멀 수 있어 현상 자체가 사라지지는 않을 것으로 예상되며, 이는 측정하지 않은 채로 남겨둔 주장입니다. 마지막으로 이번 26개 도구 베이스 코퍼스는 단일 프로덕션 하네스에서 나온 것이라, 세 기능군 중 하나(코드그래프)가 특히 특수한 어휘를 쓴다는 구성 자체가 88.5%라는 구체적인 수치를 결정짓습니다. 정성적 주장, 즉 과제 어휘와 도구 정체성 사이의 어휘 거리가 지연 로딩 아래에서 거의 전면적인 검색 실패를 낳는다는 결론은 이 구성에 의존하지 않지만, 정확한 수치는 다른 하네스에서는 달라질 수 있습니다.

논문 상세 정보는 다음 링크에서 확인할 수 있습니다: https://huggingface.co/datasets/thaki-AI/daily-paper-2026-08-03-deferred-tool-schema-discovery-cost