GitHub, Figma, 사내 세션 관리용 MCP 서버까지 한 세션에 같이 붙여두면 어느 순간부터 세션이 시작될 때마다 뭔가 느려진 느낌을 받습니다. 원인을 보면 세션이 열릴 때 연결된 MCP 서버들이 등록한 도구 정의를 전부 모델 컨텍스트에 밀어넣고 있었습니다. 도구가 몇 개 안 될 때는 문제가 안 되는데, GitHub MCP 하나만 붙여도 search_code, list_pull_requests, create_pull_request 같은 함수가 수십 개씩 나오고, 여기에 Figma·세션 관리 MCP까지 겹치면 금방 수백 개 단위로 불어납니다.
어떤 작업이었나
MCP 서버 세 개를 동시에 연결해둔 세션에서 단순한 질문 하나를 던졌는데, 응답이 평소보다 눈에 띄게 느렸습니다. 처음엔 네트워크 문제라고 생각했는데, 시스템 메시지를 보니 실제 원인은 따로 있었습니다. 세션이 시작되자마자 각 MCP 서버가 제공하는 함수 전체의 이름, 설명, 파라미터 스키마가 통째로 컨텍스트에 들어가 있었고, 그중 실제로 쓴 건 한두 개뿐이었습니다. 질문 내용과 무관하게 매번 수백 개 도구의 스키마를 먼저 다 읽어야 하는 구조였습니다.
AI를 어떻게 활용했나
Claude Code는 이 문제를 "지연 로딩"으로 풉니다. 세션이 시작될 때는 도구 이름만 나열해두고, 실제 스키마(파라미터 정의)는 그 도구를 처음 쓰려는 시점에 ToolSearch로 따로 가져오게 되어 있습니다. 시스템 메시지에는 이런 식으로 나타납니다.
The following deferred tools are now available via ToolSearch. Their schemas are NOT loaded...:
mcp__github__search_code
mcp__github__create_pull_request
mcp__figma__get_design_context
...
이 상태에서 해당 도구를 바로 호출하면 스키마가 없어서 실패합니다. 대신 먼저 필요한 도구만 골라서 스키마를 불러와야 합니다.
ToolSearch({
query: "select:mcp__github__search_code,mcp__github__create_pull_request",
max_results: 5
})
정확한 이름을 모를 때는 select:가 아니라 키워드로 검색할 수도 있습니다. 예를 들어 PR 관련 도구가 뭐가 있는지 모르는 상태에서 "pull request review" 같은 문구로 검색하면 이름이 비슷한 도구 몇 개를 랭킹순으로 돌려줍니다. 결과로 돌아온 스키마는 그 호출 이후부터 평범한 도구처럼 바로 쓸 수 있습니다.
실제로 이번 세션에서도 깃허브 관련 작업 없이 블로그 글만 쓰는데도, GitHub MCP가 등록한 수십 개 함수의 스키마가 처음부터 다 올라와 있었다면 그만큼 토큰을 낭비했을 겁니다. 지연 로딩 덕분에 실제로는 이름 목록만 컨텍스트에 남아 있고, 스키마는 그 도구를 쓸 차례가 왔을 때만 불러옵니다.
앤트로픽 엔지니어링 블로그에 따르면 이런 구조 덕분에 도구가 수백~수천 개로 늘어나는 상황에서도 토큰 사용량을 15만 토큰에서 2천 토큰 수준으로, 98% 넘게 줄일 수 있다고 합니다. 모든 도구 정의를 미리 다 읽는 대신 필요한 시점에 필요한 것만 찾아 쓰는 방식이라는 점에서, Claude Code의 ToolSearch도 같은 방향의 해법입니다.
결과와 얻은 팁
- MCP 서버를 여러 개 붙일 계획이라면 처음부터 "지금 당장 쓸 도구"와 "나중에 쓸 수도 있는 도구"를 구분해서 생각하는 게 낫습니다. 당장 안 쓸 서버는 연결 자체를 미뤄두는 편이 컨텍스트 낭비를 줄입니다.
- 도구 이름이 시스템 메시지에 뜨는데 바로 호출하면 스키마 누락 에러가 납니다. 처음 보면 당황스러운데,
ToolSearch로 먼저 스키마를 받아오면 되는 정상적인 흐름입니다. - 정확한 함수 이름을 알면
select:이름1,이름2로 한 번에 여러 개를 가져오는 게 키워드 검색보다 빠르고 정확합니다. 이름이 애매하면 키워드 검색으로 후보를 좁힌 다음 다시select:로 확정하는 두 단계가 더 안전했습니다.