에이전트가 자꾸 엉뚱한 짓을 하면 드는 생각이 있다. “기능이 부족한가 보다. 도구를 더 붙이자.” 캘린더도 물리고, 검색도 물리고, 사내 API를 MCP로 통째로 연결한다. 도구 목록이 20개에서 200개가 되면 에이전트는 뭐든 할 수 있을 것 같다. 그런데 실제로는 반대 방향으로 간다. 도구가 늘수록 에이전트는 느려지고, 비싸지고, 더 자주 틀린다. 왜 ‘더 줄수록 멍청해지는’ 일이 벌어지는가.
도구 설명서가 컨텍스트를 다 먹는다
첫 번째 비용은 눈에 안 보인다. 모델이 도구를 쓰려면 각 도구의 이름·설명·인자 스키마가 컨텍스트 창에 먼저 올라가 있어야 한다. 도구 하나당 수백에서 수천 토큰이다. Anthropic이 2025년 11월 공개한 분석에 따르면, 에이전트가 수천 개의 도구에 연결되면 사용자의 요청을 읽기도 전에 수십만 토큰을 처리해야 한다. 여기에 중간 결과가 겹친다. 2시간짜리 회의록을 한 도구로 가져와 다른 도구에 넘기면, 같은 텍스트가 컨텍스트를 두 번 흐르며 5만 토큰을 더 잡아먹는다. 같은 회사가 대안으로 제시한 구조에서는 이 작업의 컨텍스트가 15만 토큰에서 2천 토큰으로, 98.7% 줄었다. 도구가 일을 하기도 전에, 도구의 존재 자체가 예산을 태우고 있었다는 뜻이다.
많아지면 ‘고르는’ 능력이 무너진다
더 나쁜 건 정확도다. 도구가 수십 개일 때는 대부분의 모델이 맞는 도구를 잘 고른다. 그런데 목록이 수백 개로 늘면 선택 정확도가 완만하게가 아니라 급격히 무너진다. 여러 벤치마크가 같은 패턴을 보고한다. 도구 수십 개에선 정확도가 높게 유지되다가, 수백 개를 넘기면 절반 아래로, 거기서 더 늘면 사실상 찍는 수준까지 떨어진다. 원인 중 하나는 ‘중간에서 길을 잃는’ 현상이다(lost in the middle). 긴 목록의 맨 앞과 맨 끝에 놓인 도구는 잘 불리지만, 가운데 파묻힌 도구는 존재해도 선택되지 않는다. 도구를 하나 추가한다는 건 새 능력을 더하는 동시에, 기존 도구들이 선택될 확률을 함께 깎아내리는 일이기도 하다.
답은 '다 주기’가 아니라 ‘제때 주기’
그래서 진짜 레버리지는 도구를 늘리는 데 있지 않다. 필요한 순간에 필요한 도구만 컨텍스트에 올리는 데 있다. 세 가지 방식이 자리를 잡았다.
첫째, 도구 검색(tool retrieval). 모든 도구를 항상 펼쳐 두는 대신, 지금 요청과 의미가 가까운 몇 개만 먼저 추려 준다. 한 연구에선 큰 도구 목록에서 정확도가 10%대까지 떨어졌다가, 관련 도구만 먼저 골라 주자 40%대로 세 배 넘게 회복됐다.
둘째, 코드 실행. 도구를 하나하나 호출하는 대신 모델이 코드를 써서 도구를 부르게 하고, 도구 정의는 필요할 때 파일처럼 불러오게 한다. 안 쓰는 도구는 컨텍스트에 아예 들어오지 않는다.
셋째, 계층화. 도구를 범주로 묶어 두고, 에이전트가 먼저 범주를 고른 뒤 그 안의 도구만 펼쳐 본다.
공통 원리는 하나다. 컨텍스트에 올라간 도구는 공짜가 아니다 — 예산과 정확도를 같이 쓴다. 그러니 기본값을 '전부 로드’에서 '적재적소 로드’로 뒤집어야 한다.
창업자를 위한 결정 규칙
혼자 사업을 굴리며 자동화를 붙이는 사람에게 이건 그대로 비용이자 신뢰도다. 규칙 세 개.
(1) 도구를 추가하기 전에 묻는다 — 이건 항상 떠 있어야 하나, 아니면 특정 작업에서만 필요한가. 후자면 상시 로드하지 말고 필요할 때 꺼내 쓰게 한다.
(2) 도구가 20~30개를 넘어가면 평평한 목록을 버리고 검색이나 범주 계층을 넣는다. 목록이 길수록 가운데 도구는 죽는다.
(3) 도구를 지울 줄도 알아야 한다. 겹치거나 거의 안 쓰는 도구는 능력이 아니라 잡음이다 — 매 요청의 정확도를 조금씩 깎는다.
에이전트를 똑똑하게 만드는 건 더 많은 도구가 아니다. 지금 이 순간에 딱 맞는 도구 하나를 흔들림 없이 고르게 하는 설계다. 도구함이 클수록 그 설계는 더 중요해진다.