Lazy loading MCP 도구: 어떤 클라이언트가 이를 지원하며 어떻게 사용하는가

저는 AI 에이전트에게 내부 문서 저장소(repo)를 노출하기 위한 MCP 서버를 구축해 왔습니다. 특별할 것은 없습니다. 모델이 문서를 검색하고, 섹션을 읽고, 용어집(glossary) 용어를 찾아볼 수 있게 해주는 몇 가지 도구들뿐입니다. 오후 한나절이면 작성할 수 있는 수준의 작업이죠.

저를 놀라게 한 것은 프로토콜 자체가 아니었습니다. 가장 큰 토큰 비용, 즉 매 턴마다 컨텍스트(context)에 로드되는 도구 정의(tool definitions)가 제 서버가 전혀 제어할 수 없는 영역이라는 사실을 깨달은 것이었습니다. 이를 피할 수 있는지 여부는 하나의 기능, 즉 **지연 로딩 (lazy loading)**에 달려 있으며, 아직 일부 클라이언트만이 이를 지원합니다.

따라서 이 글은 어떤 클라이언트가 이를 지원하는지, 지원하지 않는 경우 어떻게 해야 하는지, 그리고 왜 서버와 클라이언트 사이의 경계가 이 모든 것을 결정하는지에 대한 기록입니다.

MCP란 무엇인가

이미 MCP를 구축해 보셨다면 이 부분은 건너뛰셔도 됩니다. 구축해 본 적이 없다면: MCP (Model Context Protocol)는 AI 에이전트에게 호출 가능한 도구 세트(이 저장소를 검색하거나, 저 API를 쿼리하거나, 이 파일을 읽는 등)를 전달하는 표준화된 방식입니다. 모든 어시스턴트가 각자 자신만의 플러그인 형식을 만드는 대신, 하나의 프로토콜로 대화합니다.

두 가지 구성 요소가 있으며, 이 둘을 혼동하는 것이

공식 @modelcontextprotocol/sdk가 이 작업을 대신 해줍니다. 이것을 매우 까다로운 언어를 위한 회화책이라고 생각하세요. 문법을 배울 필요 없이, 그저 "X를 수행하는 도구가 있습니다"라고 말하기만 하면 SDK가 대화를 처리합니다.

최소한의 서버를 만드는 것은 거의 지루할 정도입니다:

import { McpServer } from '@modelcontextprotocol/sdk/server/mcp.js'
import { StdioServerTransport } from '@modelcontextprotocol/sdk/server/stdio.js'
import { z } from 'zod'
...

네 가지 구성 요소가 있습니다: 서버를 생성하고, 각 도구를 스키마 (schema)와 함께 등록하며, 전송 방식 (transport, 여기서는 호스트가 통신하는 표준 입출력 파이프인 stdio)을 선택한 뒤, 연결하는 것입니다. 그 외의 모든 것 — 즉, 사용자의 Zod 스키마를 클라이언트가 보는 JSON 스키마 (JSON Schema)로 변환하고, 입출력을 검증하는 것 — 은 SDK의 역할입니다. 여러분이 작성해야 하는 부분은 핸들러 (handler) 본문뿐입니다. 나머지는 모두 스캐폴딩 (scaffolding, 뼈대)입니다.

알아둘 만한 세부 사항 하나는, SDK 버전에 따라 사용할 수 있는 기능이 결정된다는 점입니다. 제 환경은 ^1.12.0으로 선언되어 있지만 실제로는 1.29.0으로 해결되어, 구조화된 출력 (outputSchema)과 같은 최신 기능들이 바로 작동합니다. 만약 여러분의 버전이 오래되었다면, 특정 기능이 아예 존재하지 않을 수도 있습니다.

두 가지 비용, 그리고 당신이 해결해야 할 단 하나

MCP 설계를 바라보는 제 사고방식을 재편성해 준 멘탈 모델 (mental model)은, 서버가 두 가지 축을 기준으로 컨텍스트 (context) 비용을 부과한다는 것입니다:

고정 비용 (Fixed cost): 매 턴 (turn)마다 컨텍스트에 로드되는 도구 정의 (tool definitions).
가변 비용 (Variable cost): 도구가 반환하는 각 응답의 크기.

가변 비용 (Variable cost)은 쉬운 부분입니다. 이는 전적으로 핸들러 (handlers) 내부에서 관리됩니다. 출력을 제한하고, 페이지네이션 (paginate)을 적용하며, 모델이 파일 전체 대신 한 섹션만 읽도록 하거나, 목록을 쏟아내기 전에 인덱스 (index)를 먼저 반환하십시오. 이는 컨텍스트 (context)를 느린 네트워크 응답처럼 취급하는 규율입니다. 클라이언트가 한 행을 요청했을 때 테이블 전체를 보내지 마십시오. 두 비용을 모두 줄이는 방법에 대한 상세 내용은 별도로 다루었으므로, 여기서 전술을 반복하지는 않겠습니다. 동일한 직관은 AI 세션을 비대하게 두는 대신 가볍게 유지하는 방법에서도 나타납니다.

고정 비용 (Fixed cost)은 흥미로운 부분인데, 왜냐하면 이는 서버가 완전히 제어할 수 없는 부분이기 때문입니다.

고정 비용은 호스트의 결정 사항입니다

고정 비용 — 즉, 매 턴마다 컨텍스트에 자리 잡고 있는 도구 정의 (tool definitions) — 은 모델이 도구를 호출하든 안 하든 지불해야 합니다. 짧은 설명을 가진 6개의 작은 도구는 600~800 토큰(tokens) 정도일 수 있습니다. 수십 개의 도구를 가진 10개의 서버는 4만 개 이상의 토큰에 달할 수 있으며, 이는 모델이 당신의 첫 메시지를 읽기도 전에 사라져 버립니다.

그리고 여기서 사람들을 당황하게 만드는 부분은, 이러한 정의들이 어떻게 로드되는지가 당신이 아닌 주로 호스트 (host)의 결정에 달려 있다는 점입니다.

이상적인 해결책은 _지연 로딩 (lazy loading)_입니다. 모든 도구 정의를 미리 로드하지 않고, 아주 작은 검색 도구만 로드한 뒤 모델이 필요할 때 나머지를 발견하도록 하는 것입니다. 40개의 도구 카탈로그가 있더라도, 모델은 실제로 사용하는 두 개의 도구에 대해서만 비용을 지불합니다.

당신의 서버는 지연 로딩을 강제할 수 없습니다. 호스트가 이를 지원해야 합니다. 따라서 솔직한 질문은 이것입니다. 현재 (2026년 중반) 이를 지원하는 곳은 어디인가요?

Claude Code가 실제로 이를 구현하는 곳입니다: 도구들이 로딩을 지연하도록 표시되고, 검색 도구가 필요할 때마다(on demand) 해당 도구들을 표출합니다. 다른 모든 곳은 당신의 사용량을 제한하거나, 항상 해오던 방식으로 모든 것을 로드합니다.

이 전체 영역은 새롭고 매달 변화하고 있습니다. 위에 제시된 특정 내용은 절대적인 진리가 아니라

규모가 커질 때 실제로 제가 취할 조치

Lazy proxy (지연 프록시)는 여러 서버가 동시에 연결되어 있을 때 빛을 발합니다. 규모가 커지는 단일 서버의 경우, 프록시가 전혀 필요 없는 더 깔끔한 해결책이 있습니다:

• 도구가 약 6~15개일 때: 특별한 조치를 취하지 마세요. 고정 비용 (fixed cost)이 적습니다. 아직 발생하지 않은 문제를 해결하기 위해 복잡한 장치를 추가하지 마세요.
• 도구가 많아질 때: 자체 서버 내에서 router (라우터) 도구로 통합하세요. 25개의 개별 도구 대신, op 파라미터("list" | "get" | "search" | "glossary")를 가진 하나의 docs 도구를 사용하는 방식입니다. 스키마 (schema) 수가 줄어들고 고정 비용이 낮아지며, 100% 제어할 수 있습니다. 트레이드오프 (tradeoff)는 설명이 더 밀집되어 모델의 발견 가능성 (discoverability)이 약간 저하될 수 있다는 점입니다.
• 프록시를 도입하는 시점은 단일 서버의 문제가 아니라, 여러 서버의 합계가 고통으로 다가올 때뿐입니다.

깔끔한 장기적 경로는 서버가 선언하고 호스트 (host)가 준수하는 표준화된 tools/search 기능입니다. 이 기능이 도입되면, Lazy loading (지연 로딩)은 클라이언트를 기다리는 대신 당신의 서버가 선택할 수 있는 옵션이 됩니다. 호스트가 이를 지원하기 전까지는 실행 가능한 단계가 아니므로, 저는 아직 이를 위해 구축하고 있지 않습니다.

이 부분이 MCP 기반 워크플로우 (MCP-driven workflows)에 대해 저를 계속 놀라게 하는 지점입니다. 프로토콜은 쉽지만, 서버의 점유율 (footprint)을 위한 가장 중요한 최적화는 서버 자체에 있지 않습니다.

그러므로 도구 정의에서 토큰 (token)을 줄이느라 오후 시간을 허비하기 전에, 클라이언트가 도구를 어떻게 다루는지 먼저 확인하세요. Claude Code에서는 Lazy loading이 이미 이를 처리합니다. 그 외의 모든 곳에서는 프록시가 해결책이며, 만약 자체 서버가 비대해지고 있다면 도구들을 라우터로 접어 넣는 것이 해결책입니다. 비용이 실제로 발생하는 지점에 맞춰 해결책을 선택하세요.