Anthropic가 MCP의 가장 큰 문제를 해결했습니다

Prompt Engineering 구독자 190,000명

요약

이 영상에서는 Anthropic의 모델 컨텍스트 프로토콜(MCP)에서 서버 연결 시 모든 도구 정의가 미리 로딩돼 컨텍스트 윈도우가 낭비되는 문제를 짚어본다. 신규 "tool search" 기능은 필요 시점에 도구를 동적으로 로딩해 최대 85% 토큰 절감을 가능하게 한다. 또한 정규식 기반 검색과 BM25 키워드 검색의 차이, 도구 정의 최적화와 서버 지시(server instructions) 작성법, 클라이언트 측 4단계 구현 과정, 체크리스트와 주의 사항까지 실전 팁을 제시한다.

주요 키워드

MCP tool search 컨텍스트 윈도우 Deferred Loading 토큰 최적화 Regex-based Search BM25 Server Instructions Input Schema 도구 정의 최적화

하이라이트

🔑 MCP는 서버 연결 시 기본적으로 모든 도구 정의를 불러와 컨텍스트 윈도우의 상당 부분을 차지하는 문제가 있다.
⚡️ GitHub MCP는 91개 도구 로딩으로 약 46,000토큰(컨텍스트 22%)을 사용해 심각하게 낭비되는 사례를 보여준다.
🚀 새로 도입된 MCP tool search는 필요할 때만 3~5개 도구를 동적 로딩해 최대 85% 토큰을 절감할 수 있다.
🔍 검색 메커니즘은 정규식 기반 검색과 BM25 키워드 검색 두 가지로, 도구 이름 규칙성에 따라 선택이 달라진다.
✏️ 도구 설명은 기능 중심으로 간결하게 작성하고 핵심 키워드를 포함해 검색 효율을 높이는 것이 중요하다.
📋 server instructions 필드는 도구 사용 순서를 가이드해 Cloud가 언제 어떤 도구를 찾아야 할지 이해하도록 돕는다.
🛠️ 클라이언트 측 구현은 헤더 활성화, tool search 추가, 비필수 도구 deferred 로딩 설정, 자주 쓰는 도구 유지의 4단계로 구성된다.
⚠️ 주의할 점: tool search 도구 자체는 deferred 로딩하면 안 되며, 설명이 너무 짧으면 검색 효율이 떨어진다.

용어 설명

MCP(Model Context Protocol)

Anthropic이 제안한 언어 모델의 도구 연동 프로토콜로, 도구 정의와 대화 컨텍스트 관리 규격이다.

컨텍스트 윈도우(context window)

언어 모델이 한 번에 처리할 수 있는 토큰 용량을 의미한다. 컨텍스트가 클수록 문맥 이해가 좋아지지만 토큰 비용이 발생한다.

tool search

MCP의 신규 기능으로, 모든 도구를 사전 로딩하지 않고 필요할 때 동적으로 로딩해 토큰 사용량을 줄인다.

Deferred Loading

도구를 초기 연결 시 즉시 로딩하지 않고, 검색될 때 로딩하도록 설정하는 방식이다.

Regex-based Search

정규 표현식 패턴을 이용해 도구 이름 목록에서 일치 항목을 찾는 검색 방법이다.

BM25

키워드 기반의 전통적인 검색 알고리즘으로, 문서(도구 설명)와 쿼리의 키워드 매칭 정도를 계산해 순위를 매긴다.

Server Instructions

MCP 도구 정의에 포함되는 시스템 프롬프트 형태의 필드로, Cloud가 도구 사용 순서나 워크플로우를 이해하도록 돕는다.

Input Schema

도구가 받는 입력 파라미터의 형식·제약을 정의하는 스키마로, 검증(validation) 목적으로 사용된다.

MCP 서버 연결 시 기본으로 모든 도구 정의를 불러와 컨텍스트 윈도우를 차지하는 문제를 소개한다. GitHub MCP 예시(91개 도구, 46,000토큰 사용)로 낭비 규모를 설명하고, 해결 필요성을 강조한다.

[00:00] Anthropic이 MCP의 가장 큰 문제를 해결했다고 소개하며, 툴 정의로 인한 컨텍스트 윈도우 점유 문제를 설명합니다. GitHub MCP의 경우 91개 툴이 46,000 토큰(전체의 22%)을 소비하는 심각한 상황을 예로 듭니다.

[00:53] 새로운 MCP 툴 검색 기능을 통해 모든 툴을 미리 로드하는 대신 필요할 때 동적으로 로드할 수 있게 되었다고 설명합니다. 이 영상에서는 개발자를 위한 툴 검색 사용법을 다룰 것이라고 안내합니다.

Anthropic이 발표한 'tool search' 기능을 설명한다. 사전 로딩 대신 클라우드가 도구 카탈로그에서 3~5개의 관련 도구만 동적으로 선택해 로딩하는 방식을 개괄한다.

타임라인 정보가 없습니다.

클라이언트가 tool search 도구만 먼저 로딩하면, 질문이 오면 내부 검색을 거쳐 필요한 도구 정의만 불러온다. 이를 통해 컨텍스트 낭비를 크게 줄일 수 있음을 보여준다.

[01:24] MCP 서버 연결 시 발생하는 컨텍스트 윈도우 오염 문제를 재확인하며, Anthropic이 이전에 권장했던 코드 실행 방식과 현재 툴 검색의 차이점을 설명합니다.

정규 표현식 기반 검색은 도구 명이 일관적일 때, BM25 키워드 검색은 설명이 다양할 때 효과적임을 설명한다. 두 방법 중 상황에 맞춰 선택하도록 가이드한다.

[01:56] 툴 검색의 작동 방식을 구체적으로 설명합니다. 10% 이상 컨텍스트를 차지할 때 활성화되며, 85% 토큰 감소 효과와 3-5개 툴을 동적으로 로드하는 방식을 다룹니다.

[02:48] 툴 검색의 구체적인 작동 메커니즘을 설명합니다. Claude가 먼저 툴 검색만 단일 툴로 로드하고, 쿼리 생성 시 카탈로그를 검색하여 관련 툴 3-5개를 찾아 정의를 로드하는 과정을 다룹니다.

[03:15] 도구 검색에는 두 가지 접근법이 있습니다. 정규 표현식 패턴 매칭은 일관된 명명 규칙을 따르는 도구에 적합하고, BM25 키워드 검색은 도구 이름과 설명이 다양할 때 효과적입니다.

[04:02] 개발자의 핵심 역할은 도구를 찾을 수 있게 만드는 것입니다. 도구 설명 최적화가 가장 중요한 수단이며, 간결하고 효과적인 설명 작성이 필요합니다.

도구 설명은 기능 중심으로 1~2문장으로 간결하게 작성하고, 핵심 키워드를 추가해 검색 효율을 높인다. 불필요한 반복을 제거하고, 토큰 비용을 최소화하는 팁을 제시한다.

[04:46] 도구 설명 작성의 모범 사례에는 기능을 먼저 제시하기, 1-2문장으로 간단히 유지하기, 검색 가능한 키워드 추가하기, 제약 조건은 스키마에 넣기, 토큰 비용을 고려한 최적화가 포함됩니다.

[05:29] 서버 지시사항은 클로드가 도구를 사용하는 워크플로를 안내하는 시스템 프롬프트 역할을 합니다. PR 작업 예시처럼 순서가 중요하며, 도구 검색 시 언제 어떤 도구를 사용할지 결정하는 데 도움이 됩니다.

서버 인스트럭션 필드로 도구 사용 순서와 워크플로우를 명확히 안내하는 방법을 설명한다. PR 처리 예시로 순서가 검색 정확도에 미치는 영향을 강조한다.

타임라인 정보가 없습니다.

도구 검색 구현을 위한 네 단계: 베타 헤더 활성화, tool search 도구 추가, 비필수 도구 deferred 로딩 설정, 자주 쓰는 도구 즉시 로딩 유지 과정을 차례로 설명한다.

[06:12] MCP 클라이언트에서 도구 검색을 구현하는 것은 4단계 프로세스입니다. 첫 번째로 API 요청 헤더에 베타 활성화를 추가해야 하며, 이 헤더 없이는 도구 검색이 작동하지 않습니다.

[06:31] MCP 도구 검색 기능 구현을 위한 필수 헤더 설정과 도구 추가 과정을 설명합니다.

[06:49] 지연 로딩 설정을 통해 필요한 도구만 선택적으로 로드하여 토큰 사용량을 크게 절약할 수 있는 방법을 안내합니다.

[07:13] 필수 도구는 즉시 로드하고 나머지는 검색 기반으로 처리하는 균형잡힌 접근 방식을 제시합니다.

[07:54] 도구 검색 구현을 위한 8단계 체크리스트를 제공하며, 헤더 설정부터 서버 지침까지의 상세 단계를 설명합니다.

8단계 구현 체크리스트를 제시하고, 10% 이상 컨텍스트 점유 시 tool search 사용 권장, 소수 도구·저지연 환경에서는 생략해야 할 조건 등을 안내한다. 대표적인 실수도 짚어본다.

[08:41] 10개 이상의 도구가 컨텍스트의 10% 이상을 차지할 때 도구 검색을 사용하고, 소규모 도구셋이나 지연시간이 중요한 경우는 피해야 함을 조언합니다.

[09:12] 도구 검색 툴 자체의 지연 로딩 금지, 충분한 키워드 포함, 적절한 지연 로딩 도구 수 유지 등 주요 함정들을 경고합니다.

[00:00] 좋아요, Anthropic에서 모델 컨텍스트

[00:02] 프로토콜의 가장 큰 문제 중 하나를

[00:03] 해결했는데, MCP 서버를 연결할 때

[00:06] 툴 정의를 처리하는 방식과 관련된 문제입니다.

[00:08] 기본적으로 새로운 MCP 서버를 연결하면

[00:10] 해당 서버에서 사용 가능한 모든 툴의

[00:13] 정의를 로드하게 되는데, 이로 인해

[00:15] 대화 메시지를 보내기도 전에 이미

[00:17] 컨텍스트의 상당 부분이 이러한 툴들로

[00:20] 점유되게 됩니다.

[00:22] 이 현상이 더 심한 경우들도 있습니다.

[00:24] 예를 들어 GitHub MCP가

[00:26] 이 현상의 좋은 예입니다.

[00:29] 약 91개의 서로 다른 툴을 가지고 있어서

[00:32] MCP 서버 연결 시 로드되며,

[00:36] 약 46,000개의 토큰을 소비했습니다.

[00:40] 이는 Opus 45에서 사용 가능한

[00:42] 전체 컨텍스트 윈도우의 거의 22%에 해당합니다.

[00:46] 제가 여러 영상에서 언급한 바 있는

[00:50] 큰 문제였는데,

[00:51] 마침내 MCP 툴 검색으로 해결했습니다.

[00:53] 이를 통해 MCP에서 사용하는 컨텍스트를

[00:57] 상당히 줄일 수 있습니다.

[00:59] 모든 툴 정의를 로드하는 대신,

[01:02] 이제 툴 검색을 통해 Claude가

[01:05] 필요할 때 동적으로

[01:06] 툴을 컨텍스트에 로드할 수 있습니다.

[01:09] 이번 영상에서는 이 새로운

[01:12] 툴 검색 기능이 정확히 무엇인지와

[01:15] 개발자로서 어떻게 사용하는지 보여드리겠습니다.

[01:18] MCP 클라이언트를 구축하든

[01:20] MCP 서버를 구축하든 모두 해당됩니다.

[01:24] 문제가 정확히 무엇인지는 이미 얘기했습니다.

[01:26] 많은 툴을 가진 MCP 서버를 연결하면

[01:30] 컨텍스트 윈도우가 정말 오염될 수 있습니다.

[01:32] Anthropic에서는 이전에

[01:34] 코드 실행 사용을 권장했는데,

[01:37] 이것도 토큰 수를

[01:39] 상당히 줄여주고

[01:41] MCP를 파일 시스템처럼 취급하여

[01:44] 툴을 찾는 방식으로 작동합니다.

[01:48] 이 작업은 실제로 이전 코드 실행

[01:51] 워크플로우의 확장이지만

[01:53] 두 가지 다른 유형의 검색

[01:56] 메커니즘을 사용합니다.

[01:58] 자, 여기서 5~10개의 서로 다른

[02:00] MCP 서버를 10~20개의 서로 다른

[02:03] 툴과 함께 연결할 때

[02:06] 컨텍스트 윈도우가 어떻게 보이는지 설명하겠습니다.

[02:09] 이는 컨텍스트 윈도우의

[02:11] 상당한 비율을 차지합니다.

[02:13] 하지만 툴 검색 기능을 사용하면

[02:16] 모든 것을 미리 로드하는 대신

[02:18] 특정 툴을 찾아서

[02:20] 동적으로 로드하게 됩니다.

[02:22] 하지만 염두에 두어야 할 몇 가지가 있습니다.

[02:26] MCP 툴 정의가 컨텍스트 윈도우의

[02:29] 10% 이상을 차지할 때만 사용됩니다.

[02:32] 이론적으로 약 85%의

[02:35] 토큰 감소를 얻을 수 있고,

[02:38] 동적으로 3~5개의 서로 다른 툴을

[02:40] 한 번에 사용하거나 로드합니다.

[02:43] 툴 검색 기능을 사용한 후

[02:45] 컨텍스트 윈도우가 어떻게 보일지 설명하겠습니다.

[02:48] 작동 방식은 다음과 같습니다.

[02:51] 먼저 Claude나 다른 클라이언트는

[02:53] 컨텍스트 윈도우에서 툴 검색 기능만

[02:56] 단일 툴로 로드합니다.

[02:58] Claude가 쿼리를 생성하면 시스템은

[03:01] 툴 카탈로그를 검색하여

[03:04] 3~5개의 관련 툴을 찾으려고 시도하고

[03:06] 그 후에만 해당 3~5개

[03:08] 관련 툴의 전체 정의를 로드합니다.

[03:11] 이 접근법에는 두 가지

[03:13] 다른 변형이 있습니다. 첫 번째는 정규 표현식 기반입니다.

[03:15] 이 경우 클로드는 weather나 get star data와 같은 패턴을 작성합니다.

[03:18] 이런 방식은 도구가 일관된 명명 규칙을 따를 때 가장 효과적입니다.

[03:22] 반면에 BM25와 같은 키워드 기반 검색 메커니즘도 있습니다.

[03:26] 클로드는 'tool for weathers'나

[03:28] 'database operations'와 같은

[03:30] 자연어 쿼리를 작성합니다.

[03:33] 이는 관련성 순위가 있는 의미적 검색입니다.

[03:35] 다시 말하지만, 여기서는 임베딩을 사용하지 않습니다.

[03:37] 주로 키워드 기반 검색 메커니즘이며,

[03:40] 도구 이름과 설명이 다양할 때 더 효과적입니다.

[03:42] 따라서 도구 정의가 일관된 이름을 따르는지,

[03:44] 아니면 더 서술적이고 이름 정의가 다양한지에 따라

[03:48] 이 두 접근법 중 하나를 선택해야 합니다.

[03:49] 도구 정의가 일관된 이름을 따르는지,

[03:53] 아니면 더 서술적이고 이름 정의가 다양한지에 따라

[03:55] 결정하면 됩니다.

[03:58] 이제 도구 구현에 대해 이야기해보겠습니다.

[04:00] 서버와 클라이언트 모두에서

[04:02] 이 도구를 사용하고 싶다면 어떻게 해야 하는지 말이죠.

[04:05] 개발자로서 여러분의 역할은 도구를 찾을 수 있게 만드는 것입니다.

[04:07] 클로드가 도구를 검색할 때

[04:09] 올바른 도구를 찾아야 하는데, 어떻게 도울 수 있을까요?

[04:12] 가장 먼저 고려할 것은 도구 설명 최적화입니다.

[04:16] 이는 여러분이 가진 가장 강력한 수단입니다.

[04:18] 이전과 이후의 두 예시를 보세요.

[04:21] 완전히 동일한 아이디어를 전달하려는

[04:23] 두 가지 설명입니다.

[04:25] 첫 번째는 반복적이고 장황하며

[04:28] 많은 토큰을 사용합니다.

[04:31] 반면 두 번째는 훨씬 간결합니다.

[04:33] 기본적으로 '현재 날씨, 예보 또는 과거 데이터 가져오기'라고 하고

[04:36] 이 도구의 기능을 먼저 제시한 다음

[04:38] 두 번째 부분에서는

[04:40] 시스템이 찾을 수 있는 키워드만 간단히 넣었습니다.

[04:44] 도구 정의를 위한 설명의 모범 사례를 소개하겠습니다.

[04:46] 첫 번째는 기능을 먼저 제시하는 것입니다.

[04:49] 이것이 첫 번째 문장이어야 합니다.

[04:51] 한두 문장으로 간단히 유지하세요.

[04:54] fetch, get, retrieve 등과 같은

[04:57] 검색 가능한 키워드를 추가하세요.

[04:59] 동의어도 클로드가 도구를 찾는 데 도움이 됩니다.

[05:02] 제약 조건은 설명이 아닌 입력 스키마에 넣으세요.

[05:05] 설명은 발견을 위한 것이고,

[05:07] 스키마는 검증을 위한 것입니다.

[05:09] 이것은 정말 주의해야 할 부분입니다.

[05:11] 다섯 번째로, 모든 단어가 토큰 비용이라는 점입니다.

[05:13] 따라서 도구 설명 최적화에 무자비할 정도로 신경 써야 합니다.

[05:15] 알아둬야 할 또 다른 필드가 있습니다.

[05:18] 바로 서버 지시사항입니다.

[05:21] 이는 클로드가 도구를 사용하는 방법을 안내하는

[05:25] 시스템 프롬프트와 같은 필드입니다.

[05:27] 이 간단한 예시를 보세요.

[05:29] PR 작업의 경우

[05:30] 먼저 PR 상태를 확인한 다음 PR을 보거나 승인하라고 되어 있습니다.

[05:34] 이렇게 클로드에게 워크플로를 알려주는 것입니다.

[05:37] 도구 검색이 활성화되었을 때 순서가 매우 중요합니다.

[05:40] 이는 클로드가 언제 어떤 도구를 검색해야 하는지

[05:41] 이해하는 데 도움이 됩니다.

[05:44] MCP 클라이언트를 구축하는 클라이언트 사이드 개발자라면,

[05:47] 도구 검색을 구현하는 정확한 방법은 다음과 같습니다.

[05:52] 간단한 4단계 프로세스입니다.

[05:55] 첫 번째 단계는 베타를 활성화하는 것입니다.

[05:58] API 요청의 헤더에 이것을 추가하세요.

[06:01] 이 헤더 없이는 도구 검색이 작동하지 않습니다.

[06:05] 현재는 필수입니다.

[06:07] 두 번째 단계는

[06:09] 도구 영역에 도구 검색 도구를 추가하는 것입니다.

[06:12] 이는 추가적인 도구로서

[06:15] 정확히 도구 검색을 구현하는 방법입니다.

[06:17] 간단한 4단계 프로세스입니다.

[06:21] 1단계, 베타를 활성화해야 합니다.

[06:22] API 요청의 헤더에 이것을 추가하세요.

[06:25] 이 헤더 없이는 도구 검색이 작동하지 않습니다.

[06:28] 현재는 필수 항목입니다.

[06:31] 현재로서는 필수입니다. 이제 두 번째 단계는

[06:33] 도구 영역에 도구 검색 툴을 추가하는 것입니다.

[06:35] 이것은 여러분이 사용하게 될 추가적인 도구이고

[06:37] 정규 표현식 기반 또는

[06:39] BM25 기반 도구 검색 툴 중 하나를 선택할 수 있습니다.

[06:41] 가장 중요한 것 중 하나는

[06:44] 이 도구에는 지연 로딩을 설정하지 않는 것입니다.

[06:46] 즉시 로드되어야 합니다.

[06:49] 세 번째 단계는 도구를 지연 로딩으로 표시하는 것입니다.

[06:52] 이제 MCP 서버가 연결될 때

[06:54] 즉시 로드하고 싶지 않은 도구에

[06:56] 이 특정 키워드를 추가해야 합니다.

[06:59] 이것은 시스템에 다음과 같이 알립니다:

[07:02] 이 도구를 미리 로드하지 말고,

[07:04] Claude가 검색할 때 로드해라.

[07:07] 그리고 이때가 토큰 사용량에서

[07:10] 가장 많은 절약을 얻게 되는 시점입니다.

[07:13] 네 번째 단계는 필수 도구를 로드된 상태로 유지하는 것입니다.

[07:16] 모든 것이 지연되어서는 안됩니다.

[07:18] 가장 자주 사용하는 도구 3-5개는

[07:20] 지연 로딩 없이 유지하세요.

[07:22] 패턴이 어떻게 보이는지 설명하겠습니다.

[07:25] 필수 도구의 경우

[07:27] 지연 로딩을 false로 설정하면

[07:29] 이것들이 자동으로 로드될 도구들입니다.

[07:31] 그리고 검색하고 싶은 도구들의 경우

[07:33] 간단히 이 지연 로딩을

[07:34] true로 설정하면 됩니다.

[07:37] 여기서 균형은 일반적인 작업에 대한 즉각적인 접근과

[07:40] 나머지 모든 것에 대한 검색 기반입니다.

[07:42] 다양한 MCP 서버 내의

[07:44] 다양한 도구에서 이를 수행할 수 있습니다.

[07:46] 이것을 사용할 예정이라면

[07:49] 빠른 구현 체크리스트가 있습니다.

[07:52] 8가지 단계가 있습니다.

[07:54] 첫 번째는 헤더를 활성화하는 것입니다.

[07:56] 두 번째는 도구 검색 툴을 추가하는 것으로,

[07:59] 정규식 또는 BM25 중 선택하세요.

[08:02] 이것은 여러분의 선택입니다.

[08:04] 세 번째는 비필수 도구를

[08:07] 지연 로딩 true로 표시하는 것입니다.

[08:09] 3-5개의 필수 도구는 지연 로딩 없이 유지하고

[08:12] 도구 설명을 최적화하세요.

[08:14] 기능을 먼저 제시하고 키워드를 추가하세요.

[08:17] 여섯 번째는 서버 지침을 추가하는 것입니다.

[08:18] 이것은 Claude가 워크플로우를 이해하는 데 도움이 됩니다.

[08:22] 일곱 번째는 30개 이상의 도구로 테스트하는 것입니다.

[08:24] 여기서 가장 큰 개선을 볼 수 있을 것입니다.

[08:27] 마지막은

[08:29] 사용량을 통해 컨텍스트를 모니터링해야 한다는 것입니다.

[08:31] 전후를 추적해야 합니다.

[08:34] 더 널리 사용 가능해지면

[08:36] 이를 수행하는 방법에 대한

[08:38] 다른 영상을 만들 예정입니다.

[08:41] 그런데 도구 검색을 언제 사용해야 할까요?

[08:48] 10개 이상의 MCP 도구가 있고

[08:51] 에이전트 컨텍스트의 10% 이상을

[08:54] 차지한다면 반드시

[08:56] 도구 검색 툴 사용을 고려해야 합니다.

[08:59] 도구가 3-5개만 있거나

[09:01] 모든 도구가 자주 사용되거나

[09:03] 지연 시간이 절대적으로 중요하다면

[09:05] 건너뛰세요. 검색 기반

[09:09] 탐색은 지연 시간도 증가시키기 때문입니다.

[09:12] 고려해야 할 일반적인 함정이 있습니다.

[09:14] 첫 번째는 도구 검색 툴 자체를

[09:16] 지연 로딩하지 마세요.

[09:18] 이는 목적을 무력화시킵니다.

[09:20] 설명을 너무 짧게 만들지 마세요.

[09:22] 검색에는 키워드가 중요합니다.

[09:25] 단순한 'get weather'보다는

[09:27] '현재 날씨 예보 가져오기' 또는

[09:29] '과거 데이터'가 더 좋습니다.

[09:31] 세 번째는 지연 로딩 없이

[09:33] 너무 많은 도구를 유지하지 마세요.

[09:37] 아무것도 지연 로딩하지 않으면

[09:39] 전혀 이점을 얻을 수 없습니다.

[09:41] 이것이 바로 도구 검색 툴입니다.

[09:43] 가서 구현해 보세요. 컨텍스트 창이

[09:46] 감사할 것입니다. 특정 구현에 대한

[09:48] 질문이 있으면

[09:50] 댓글에 남겨주세요.

[09:52] 답변하려고 노력하겠습니다.

[09:55] MCP 도구를 구축하고 있고

[09:58] 이 콘텐츠가 유용했거나

[10:01] MCP 도구를 사용하고 있다면

[10:03] 채널 구독을 고려해 주세요.

[10:04] 어쨌든, 이 영상이 유용했기를

[10:06] 바랍니다. 시청해 주셔서 감사하고,