에이전트 병목으로서의 도구 계층

도구가 수백 개로 늘어나면 에이전트의 병목은 모델 추론이 아니라 도구 계층으로 옮겨가고, 선택·신뢰·인증·지연 네 문제가 이 계층에서 함께 터집니다.

에이전트 성능을 올리는 논의는 대개 어떤 모델을 쓸지에서 시작합니다. 그런데 도구가 많은 환경의 실측은 다른 곳을 가리킵니다. 실패가 추론이 아니라 어떤 도구를 후보로 올릴지 정하는 단계에 몰려 있습니다.

이 글은 서로 다른 네 갈래 연구를 하나의 주장으로 묶습니다. 도구 검색, 도구 포이즈닝, 원격 서버 인증, 병렬 실행은 별개의 주제로 다뤄지지만 모두 같은 대상을 건드립니다. 도구 레코드, 즉 이름과 설명과 스키마와 엔드포인트를 담은 그 한 덩어리입니다. 인용한 수치는 2026-09 기준으로 각 논문 원문에서 확인했습니다.

병목이 옮겨간 자리

LiveMCPBench는 서버 70개와 도구 527개 위에서 실사용 과제 95개를 돌린 벤치마크입니다 (arXiv:2508.01780). 최신 LLM 12종을 측정했고 Claude-Sonnet-4가 78.95%로 가장 높았습니다. 나머지 모델 대부분은 30~50%대에 머물렀습니다.

눈여겨볼 것은 점수가 아니라 실패의 분포입니다. 논문은 전체 실패의 거의 절반이 검색 오류에서 나왔다고 밝히고, 검색을 지배적 병목으로 지목합니다. 모델을 더 좋은 것으로 바꿔도 후보 목록에 정답 도구가 없으면 결과는 달라지지 않습니다.

이것이 도구 사용 규칙을 모델 안에 학습시키던 Toolformer 시절과 달라진 지점입니다. 도구가 외부 레지스트리에서 동적으로 공급되면 선택은 모델 안의 능력이 아니라 모델 밖의 검색 문제가 됩니다. 그래서 병목도 함께 밖으로 나옵니다.

먼저 무너지는 선택 단계

대응은 세 연구가 같은 형태로 수렴합니다. 전체 도구를 프롬프트에 넣지 않고, 질의가 들어올 때 관련 도구만 검색해 로드하는 구조입니다.

Semantic Tool Discovery는 도구 이름과 설명과 파라미터를 dense embedding으로 색인합니다. 서버 5개, 도구 121개, 질의 140개 규모에서 도구 관련 토큰 소비를 99.6% 줄였습니다 (arXiv:2603.20313). 같은 조건에서 K=3 적중률 97.1%, 평균 역순위 0.91, 검색 지연 100ms 미만을 기록했습니다.

Dynamic ReAct는 대규모 MCP 환경에서 도구 선택 아키텍처 다섯 가지를 비교했습니다 (arXiv:2509.20386). 최종 선택은 검색으로 후보를 좁힌 뒤 필요한 도구만 로드하는 구조였고, 과제 완료 정확도를 유지하면서 도구 로드량을 최대 50% 줄였습니다.

이 구조는 전제 하나에 기댑니다. 상위 k개 안에 정답 도구가 들어 있어야 하고, 그 순위는 도구 설명 텍스트의 품질이 정합니다. 설명이 부실하면 모델이 아무리 좋아도 그 도구는 후보에 오르지 않습니다.

검색이 읽는 텍스트라는 공격 표면

여기서 두 번째 문제가 붙습니다. 순위를 정하는 그 설명 텍스트는 서버가 자유 형식으로 보내는 값이고, 검증 없이 모델 컨텍스트에 들어갑니다.

MCPTox는 실제 운영 중인 MCP 서버 45개와 정품 도구 353개를 대상으로 삼았습니다. 악성 케이스 1,312건을 만들어 에이전트 20종을 측정했습니다 (arXiv:2508.14925). o1-mini의 공격 성공률은 72.8%였고, 거부율이 가장 높은 Claude-3.7-Sonnet조차 3% 미만이었습니다. 정상 도구를 승인 밖 목적으로 쓰게 만드는 공격이라 콘텐츠 필터가 대상으로 삼지 않습니다.

승인 화면을 믿기도 어렵습니다. Rashidi의 연구는 승인 화면과 모델 토크나이저에 전달되는 바이트가 같아야 한다는 요구가 프로토콜에 없다는 점을 짚습니다. 논문은 이를 승인-보기 충실도 격차라고 부릅니다 (arXiv:2607.05744). 유니코드 TAG 블록(U+E0000~U+E007F)은 주요 렌더러에 글리프가 없어 화면에서는 사라지지만 토크나이저는 그대로 읽습니다.

8가지 은폐 기법을 실제 MCP 프로토콜로 시험한 결과는 다음과 같습니다.

마지막 두 줄이 앞 절과 직접 부딪힙니다. 재승인을 강제하는 구현이 하나도 없다는 것은, 한 번 승인한 도구의 설명이 이후 조용히 바뀌어도 계속 신뢰된다는 뜻입니다. 그런데 검색 기반 동적 로딩은 세션 중에 도구 목록이 바뀌는 것을 정상 동작으로 삼습니다.

판단입니다. 검색 랭킹과 도구 포이즈닝은 같은 필드를 최적화 대상으로 삼습니다. 검색에 잘 걸리도록 쓴 설명은 공격자에게도 유리한 설명이고, 두 목표를 같은 텍스트에 걸어 둔 채로는 한쪽만 개선할 수 없습니다. 공격 경로 자체는 MCP 도구 포이즈닝에서 다뤘습니다.

도구 수와 함께 늘어나는 인증 표면

도구를 수백 개로 만드는 방법은 하나뿐입니다. 서버를 여러 개 붙이는 것이고, 그중 상당수는 원격 서버입니다.

Zhou 등의 측정 연구는 실제로 살아 있는 원격 MCP 서버 7,973개를 식별했습니다 (arXiv:2605.22333). 그중 40.55%가 인증 없이 도구를 노출했습니다. 인증을 건 서버가 다수인 상황이 아닙니다.

인증을 건 쪽도 안전하지 않았습니다. 종단간 테스트가 가능한 OAuth 서버 119개를 정밀 분석한 결과 모든 서버가 결함을 최소 하나 이상 가졌고, 결함은 총 325건이었습니다. 동적 클라이언트 등록 관련 결함이 96.6%에 영향을 미쳤으며 연구팀은 CVE 9건을 받았습니다.

MCP의 원격 배포에서는 서버가 클라이언트에게는 리소스 서버, 업스트림 서비스에게는 OAuth 클라이언트를 겸합니다. 두 역할이 겹치면 누가 누구를 대신하는지가 흐려집니다. 혼동된 대리인에서 정리한 그 문제입니다. 도구 수를 늘릴수록 이 겸직이 늘어납니다.

지연 단축이 지우는 승인 지점

네 번째는 지연입니다. 도구가 많아지면 한 과제에 필요한 호출 수가 늘고, 순차 루프에서는 그것이 그대로 대기 시간이 됩니다. 최근 연구는 서로 다른 두 축에서 이 비용을 줄입니다.

W&D는 한 스텝에서 동시에 부르는 도구 개수, 즉 width를 늘립니다 (arXiv:2602.07359). BrowseComp 100개 샘플에서 스케줄러별 결과는 다음과 같습니다.

초반에 넓게 탐색하고 뒤로 갈수록 좁히는 descending이 고정 폭보다 정확도가 6%p 높으면서 턴 수는 더 적었습니다. 비용도 같이 내려갑니다. 한 스텝에 도구 3개를 병렬로 부르면 100개 과제당 65.7달러로 68% 정확도에 도달해, 단일 도구 방식의 102.5달러보다 35.9% 적게 들었습니다.

PASTE는 다른 축을 건드립니다 (arXiv:2603.18897). 정식 제목은 Parallelizing Tool Execution and LLM Generation for Low-Latency Agent Serving입니다. 모델이 다음 액션을 생성하는 동안 반복 패턴을 근거로 다음 도구 호출을 미리 실행해 둡니다. 평균 과제 완료 시간을 43.5% 줄였고 관측된 도구 실행 지연은 1.8배 빨라졌습니다.

주목할 것은 예측 정확도입니다. top-1 정확도는 27.8%에 그치지만 전체 적중률은 93.8%입니다. 틀린 예측을 버리는 비용이 맞은 예측의 이득보다 작기 때문에 성립하는 구조입니다.

그래서 이 축은 승인 문제와 정면으로 만납니다. 투기적 실행은 모델이 확정하기 전에 도구를 실제로 부르므로, 부작용이 있는 액션을 걸러 낼 별도 장치가 필요합니다. PASTE는 2만 건이 넘는 투기적 액션 중 602건을 부작용 가능성으로 커밋 전에 차단했습니다.

네 문제가 겹치는 지점

네 문제는 모두 도구 레코드 하나를 놓고 서로 다른 것을 요구합니다.

• 네 경로가 읽는 원본은 하나이므로, 설명을 고치면 검색 순위와 공격 표면이 동시에 바뀝니다.
• 색인 시점, 승인 시점, 토큰 발급 시점, 실행 시점이 다르면 같은 레코드의 서로 다른 버전이 각 경로에 남습니다.
• 재승인 강제가 0/8이라는 결과는 이 버전 불일치를 잡아 줄 기본값이 프로토콜에 없다는 뜻입니다.

각 문제가 조작하는 대상과 충돌 지점을 정리하면 다음과 같습니다.

반례와 한계

주장이 성립하지 않는 조건이 있습니다. 도구가 열 개 미만이고 전부 1차 서버이며 목록이 고정된 환경에서는 검색 계층이 필요 없고, 병목은 다시 모델로 돌아갑니다. 망분리된 사내 환경도 마찬가지입니다. 인증 결함의 상당 부분은 노출 자체를 차단하는 방식으로 우회되며, 이때 인증 축의 근거는 힘을 잃습니다.

소스가 답하지 못하는 것도 분명합니다. 네 문제를 한 시스템에서 동시에 측정한 연구는 확인하지 못했습니다. 이 글이 묶는 방식은 각 연구의 결과를 나란히 놓고 도출한 판단이며, 결합 효과의 크기는 측정된 바가 없습니다.

개별 수치의 적용 범위도 좁습니다. LiveMCPBench의 검색 실패 비율은 그 벤치마크의 하네스 구성에서 나온 값이고, PASTE의 수치는 특정 서빙 스택과 세 가지 워크로드에서 얻은 값입니다. 인증 측정은 검색엔진으로 발견 가능한 공개 원격 서버를 모집단으로 삼으므로, 사내 배포의 인증 수준을 대표하지 않습니다.

어디부터 손댈지 정하는 기준

규모에 따라 먼저 해결할 축이 달라집니다.

도입 순서와 무관하게 확인할 항목은 다음과 같습니다.

• 승인 화면에 표시한 바이트와 모델에 전달한 바이트가 같은지 검사합니다.
• 도구 정의의 digest를 승인 기록에 묶고, 값이 바뀌면 재승인을 요구합니다.
• 검색 색인을 갱신할 때 정적 검증을 함께 돌려 색인과 승인 상태를 어긋나지 않게 둡니다.
• 서버별로 토큰을 분리하고 audience를 검증해 하나의 토큰이 여러 서버로 흐르지 않게 합니다.
• 투기적 실행과 병렬 폭 확장은 부작용 없는 읽기 도구에 한정해 켭니다.

정리

도구가 수백 개로 늘어난 에이전트에서 결과를 가르는 것은 모델 추론이 아니라 도구 계층입니다. LiveMCPBench는 실패의 절반 가까이가 검색 단계에서 났다고 보고했고, 검색이 순위를 매기는 그 설명 텍스트가 곧 포이즈닝의 통로입니다. 도구를 늘리려면 원격 서버를 늘려야 하는데 그 모집단의 40.55%는 인증조차 없었고, 지연을 줄이는 병렬 폭과 투기 실행은 사람이 개입할 지점을 앞질러 갑니다. 네 문제는 같은 도구 레코드를 서로 다른 방향으로 잡아당기므로, 검색기와 승인 화면과 자격증명 저장소와 스케줄러를 각각 고르지 말고 하나의 계층으로 함께 설계해야 합니다. 규모가 작고 목록이 고정된 환경이라면 이 주장은 적용되지 않으며, 그때는 모델 선택이 여전히 가장 큰 변수입니다.