로컬 대규모 언어 모델(LLM)을 사용하는 개발자들은 사용자가 프롬프트를 입력하기도 전에 단일 Multi-Channel-Protocol (MCP) 서버가 전체 컨텍스트 창을 다 써버릴 수 있다는 사실을 발견합니다. 이들은 기능이 제한된 도구 설명과 끊기는 대화 흐름 사이에서 선택해야만 합니다.
로컬 LLM에서 토큰 팽창(token bloat)이 중요한 이유
MCP는 모델에 각 도구에 대한 설명을 제공함으로써 LLM이 외부 도구(API, 스크립트 또는 파일 시스템 유틸리티)를 호출할 수 있게 합니다. 128k 토큰 창을 가진 클라우드 호스팅 모델은 많은 도구 정의를 수용하고도 사용자 대화를 위한 공간을 남길 수 있습니다. 하지만 8k 토큰 창을 가진 70억 파라미터(7-billion-parameter) 로컬 모델은 도구를 몇 개만 로드해도 공간이 부족해집니다. 트레이드오프는 극명합니다. 짧고 저렴한 설명은 호출 경로를 잘못 지정하고, 길고 상세한 설명은 채팅에 필요한 예산을 소모합니다.
이러한 상황에 이르게 된 일련의 과정
MCP는 맞춤형 통합 코드를 대신하여 다양한 데이터 소스에 대한 단일 모델 주도 인터페이스를 제공하기 위해 구축되었습니다. 대부분의 MCP 서버는 기계가 아닌 사람 운영자를 위해 설계된 REST 엔드포인트의 얇은 래퍼(thin wrapper) 역할을 합니다. 이러한 래퍼가 로컬 LLM 세션에 적용되면, 모델은 어떤 도구를 호출할지 결정하기 전에 모든 도구의 이름, 매개변수 및 사용법 노트를 읽어야 합니다. 좁은 컨텍스트 창은 이러한 "설명 오버헤드(description overhead)"를 구조적 병목 현상으로 만듭니다.
승자와 패자
- 온디바이스 어시스턴트를 구축하는 개발자는 유연성을 잃습니다. 도구 카탈로그를 축소하여 빈번한 오류 위험을 감수하거나, 사용자 입력을 잘라내는 비대해진 프롬프트를 받아들여야 합니다.
- 최종 사용자는 어시스턴트가 잘못된 도구를 선택하거나 컨텍스트가 가득 차서 동작을 거부하는 등 불안정한 동작을 경험하게 됩니다.
- 도구 제공업체는 통일된 진입점을 얻습니다.
비용은 단순히 열악한 경험에 그치지 않고 보안 문제까지 일으킵니다. MCP 에이전트가 모든 로컬 파일을 읽을 수 있게 되면, 권한 모델은 "전부 아니면 전무(all-or-nothing)"로 무너집니다. 샌드박스가 없다면 잘못 구성된 도구가 전체 파일 시스템을 노출할 수 있습니다.
개발자들이 이에 대처하는 방법
커뮤니티에서는 세 가지 우회 방법이 주로 사용됩니다.
- 설명 축소(Trim descriptions) – 도구 메타데이터를 최소한으로 줄입니다. 이는 토큰을 확보하지만, 모델이 잘못된 엔드포인트를 선택할 가능성을 높여 개발자가 오류를 포착하고 재시도해야 하는 상황을 초래합니다.
- 동적 로딩(Dynamic loading) – 현재 대화와 관련된 도구의 하위 집합만 로드합니다. 경량 디스패처(dispatcher)가 사용자의 의도에 따라 어떤 도구 세트를 주입할지 결정합니다. 이는 유휴 토큰 사용량을 줄이지만 지연 시간과 코드 복잡성을 증가시킵니다.
- 활성 서버 제한(Limit active servers) – 세션당 MCP 서버 수를 제한하여 개발자가 가장 필수적인 통합 기능에 우선순위를 두도록 강제합니다. 이는 프롬프트 크기를 관리 가능한 수준으로 유지하지만 기능의 폭을 희생합니다.
이 중 어떤 솔루션도 만능 해결책(silver bullet)은 아닙니다. 설명을 축소하면 신뢰성이 떨어지고, 동적 로딩은 응답 속도를 늦추는 결정 계층을 추가하며, 서버를 제한하면 어떤 데이터 소스를 지원할지에 대한 어려운 선택을 강요합니다.
토큰 문제와 결합된 보안 리스크
로컬 에이전트는 종종 제한 없는 파일 시스템 액세스 권한을 가지고 실행됩니다. MCP 프로토콜은 "이 폴더 읽기"와 "모든 것 읽기" 사이의 세밀한 권한 제어(granularity)를 제공하지 않습니다. 일부 팀은 전체 액세스 문제를 해결하기 위해 게이트웨이 계층을 구축하여 복잡성을 더하기도 합니다. 이러한 게이트웨이는 "전체 제어" 문제를 완화하지만 코드 베이스를 증가시킵니다.
소형 모델을 위한 도구 설계
대규모 클라우드 모델은 잘못된 설명에서도 복구할 수 있으므로, 개발자들은 때때로 정밀한 도구 정의의 필요성을 간과하곤 합니다. 로컬 모델의 경우 다음 원칙을 따르십시오.
- 좁은 기능 범위(Narrow functionality) – 각 도구는 한 가지 일만 수행해야 합니다. 파일 쓰기 기능까지 갖춘 "검색" 도구는 중복되는 책임을 추적할 수 없는 모델을 혼란스럽게 만듭니다.
- 명확한 명명(Unambiguous naming) – "process"나 "handle"과 같은 일반적인 이름을 피하십시오. 이름은 정확한 작업을 전달하여 모델의 인지 부하를 줄여야 합니다.
- 명확하고 간결한 설명(Clear, concise descriptions) – 모델이 결정하는 데 정말로 필요한 매개변수만 포함하십시오. 모델이 패턴을 빠르게 인식할 수 있도록 일관된 형식을 사용하십시오.
반론: 프로토콜은 여전히 가치가 있다
마찰에도 불구하고 MCP는 보일러플레이트 코드(boilerplate code)를 추상화해주기 때문에 여전히 매력적입니다. 단일 모델 주도 인터페이스를 통해 각 서비스에 대한 맞춤형 어댑터를 작성하지 않고도 수십 개의 서비스에 연결할 수 있습니다. 클라우드 규모의 모델을 사용할 여력이 있는 팀에게 토큰 팽창은 문제가 되지 않으며, 편의성이 오버헤드보다 큽니다. 과제는 이러한 편의성을 제약이 많은 온디바이스 LLM의 세계로 어떻게 이식하느냐에 있습니다.
시사점
온디바이스 어시스턴트를 구축하고 있다면, MCP 도구 설명을 희소 자원으로 취급하십시오. 실제 대화를 위한 컨텍스트 창을 확보할 수 있도록 도구 설명을 다듬고, 동적으로 로드하며, 범위를 좁게 설계하십시오. 동시에, 몇 개의 토큰이 더 소모되더라도 권한 계층을 삽입하여 암묵적인 "전체 액세스(full-access)" 보안 모델에 대비하십시오. 여러분이 찾는 균형점에 따라 로컬 LLM이 유용한 동반자가 될지, 아니면 고장 난 챗봇이 될지가 결정될 것입니다.