MCP의 토큰 문제는 현실입니다.
전통적인 Model Context Protocol 구현은 비용을 낭비하고 있습니다. AI 에이전트가 문제를 풀기도 전에 이미 어떤 API가 존재하는지 설명하는 데만 55,000개의 토큰을 소모합니다. Anthropic의 일부 엔터프라이즈 설정에서는 단순한 오버헤드만 134,000개의 토큰에 달합니다. 이것은 효율성이 아닙니다. 모든 요청에 부과되는 세금입니다.
문제는 단순합니다. 시스템이 에이전트가 실제로 사용할지 여부와 관계없이 모든 도구 정의를 미리 로드합니다. GitHub, Slack, Sentry, Grafana, Splunk의 58개 도구가 모두 거대한 JSON 페이로드로 모델의 컨텍스트 윈도우에 덤프됩니다. 대부분은 현재 작업과 무관합니다. 이 모든 것이 무의미합니다.
“전통적인 MCP 구현은 모델 컨텍스트에 큰 JSON 페이로드를 주입하는 경우가 많으며, 이는 토큰 소비를 증가시키고 효율성을 저하시킵니다.”
여기서 Code Mode가 등장합니다. 그리고 이것은 게임의 규칙을 완전히 바꿉니다.
Code Mode의 실제 차이점은 무엇인가?
Code Mode는 도구 정의를 미리 로드하지 않습니다. 대신 모델이 온디맨드 방식으로 도구를 호출하는 코드를 생성하도록 합니다. LLM이 사용 가능한 API 레지스트리를 검색하고, 필요한 스키마만 가져오고, 올바른 엔드포인트를 호출하는 Python 코드를 작성하고, 샌드박스 환경에서 해당 코드를 실행합니다. 결과가 반환됩니다. 끝.
효율성 향상은 명백합니다. 컨텍스트 블로트 없음, 무관한 도구 설명으로 인한 할루시네이션 위험 없음, 극적으로 낮아진 토큰 소비. 하지만 아무도 이야기하지 않는 진정한 인사이트는 무엇입니까? 이 접근 방식은 컨텍스트 윈도우 크기를 실행 인텔리전스로 교환합니다. 모델은 단지 할 수 있는 일을 설명하는 것이 아니라 실제로 하는 것입니다.
그리고 이것은 샌드박스가 필요합니다.
LLM 코드를 직접 실행할 수 없는 이유
여기서 날카로운 현실이 드러납니다. AI 모델이 임의의 Python을 생성하고 프로덕션 서버에서 실행하도록 하는 것은 보안 침해로 가는 지름길입니다. 파일 접근. 네트워크 오용. 권한 상승. 시스템 장악.
OpenSandbox는 Alibaba의 오픈소스 플랫폼(현재 CNCF Landscape에 등재됨)으로 격리된 실행 환경을 만들어 이 문제를 해결합니다. 생성된 Python 코드는 제한된 파일시스템 접근, 네트워크 제어, 리소스 제한, 프로세스 격리가 있는 컨테이너 내에서 실행됩니다. 샌드박스는 모델의 의도와 실제 인프라 사이의 보루 역할을 합니다.
이것은 편집증이 아닙니다. 아키텍처입니다.
흐름은 다음과 같습니다. 스타트업이 모든 사용 가능한 OpenAPI 스펙을 발견하고 레지스트리에 로드합니다. 요청이 도착합니다. 시스템이 메타데이터로 관련 도구를 검색합니다. LLM이 get_schema를 통해 선택된 도구의 스키마를 검사합니다. 모델이 엔드포인트를 올바르게 호출하는 Python 코드를 생성합니다. 해당 코드가 execute를 통해 샌드박스로 전송됩니다. 샌드박스가 격리 상태에서 실행하고, 실제 시스템으로의 HTTP 요청을 처리하고, 원본 결과를 반환합니다. LLM이 이를 인간이 읽을 수 있는 응답으로 변환합니다.
세 가지 핵심 도구가 작동합니다: search, get_schema, execute. 이것이 전부입니다.
이것이 전통적인 MCP보다 실제로 나을까요?
네. 하지만 주의사항이 있습니다.
수백 개의 API와 거대한 도구 레지스트리를 보유한 엔터프라이즈의 경우, Code Mode는 토큰 세금을 제거합니다. 컨텍스트 오버헤드 90% 감소는 이론이 아니라, 모든 도구 정의를 미리 로드하는 것을 중단할 때 실제로 발생하는 결과입니다. 규모 측면에서 이는 실제 비용 절감과 더 빠른 추론입니다.
하지만 Anthropic의 마케팅 슬라이드에 나오지 않을 것이 여기 있습니다. Code Mode는 지연 시간을 도입합니다. 샌드박스로의 추가 왕복, 코드 생성, 실행, 결과 파싱에는 시간이 걸립니다. 지연 시간에 민감한 애플리케이션의 경우, 같은 도구를 반복해서 사용한다면 부풀려진 전통적인 MCP가 여전히 더 빠를 수 있습니다.
또한 모든 환경이 이 수준의 최적화가 필요한 것은 아닙니다. 좁은 범위의 API를 실행 중이라면(예를 들어, 총 15K 토큰을 소비하는 5개의 도구), 샌드박싱과 동적 도구 호출의 엔지니어링 복잡성이 가치가 있지 않을 수 있습니다.
더 큰 그림: 경쟁력으로서의 컨텍스트 효율성
흥미로운 점은 이것이 단지 MCP 최적화가 아니라는 것입니다. 그것은 패턴입니다. 모델이 커지고 토큰 윈도우가 확장되면서, 컨텍스트에 모든 것을 던져 버리고 싶은 유혹이 있습니다. Anthropic은 본질적으로 이렇게 말하고 있습니다: 그렇게 하지 마세요. 모델이 보는 것에 대해 의도적이어야 합니다.
Code Mode는 그 의도성을 강제합니다. 더 이상 100개의 도구 정의를 게으르게 로드할 수 없습니다. 발견, 관련성, 모델이 실제로 현재 문제를 해결하기 위해 필요한 것을 생각해야 합니다.
이것이 중요한 이유는 컨텍스트 윈도우 크기가 허례의 지표이기 때문입니다. 진정한 효율성은 신호 대 잡음비입니다. 그리고 Code Mode는 이를 극적으로 개선합니다.
엔터프라이즈 설정에서 .NET 및 C#으로 이를 구현하는 개발자들(원저자가 연구해온)에게는 이 패턴이 가치 있게 연구할 만합니다. 기본 원칙(정적 정의를 주입하는 대신 실행 가능한 코드 생성)은 API를 넘어 확장됩니다. 에이전트가 데이터베이스, 인프라, 내부 도구와 상호작용하는 방식을 재편할 수 있습니다.
OpenSandbox 질문
마지막 한 가지: OpenSandbox는 대부분의 개발자에게 상대적으로 새롭습니다. 견고합니다(CNCF 승인, 다중 언어 SDK, Docker/Kubernetes 지원), 하지만 채택이 주류가 아직 아닙니다. 프로덕션에서 Code Mode를 구현하는 경우, 여전히 생태계를 구축하고 있는 플랫폼에 베팅하는 것입니다.
그것은 절대적인 거래 결렬은 아닙니다. 단지 현실입니다.
여기서의 승리는 실질적입니다. 토큰 낭비 없는 MCP, 실제로 실행 가능한 도구 호출, 속도를 위해 보안을 희생하지 않는 샌드박스 패턴. 하지만 구현에는 전통적인 MCP보다 더 많은 인프라가 필요합니다. 자신의 토큰 오버헤드 문제에 직면하지 않은 경우라면 그것은 잘못된 문제에 대한 올바른 솔루션입니다.
🧬 관련 인사이트
- 더 읽기: Your Access Tokens Are Probably Broken (And Nobody’s Telling You)
- 더 읽기: Azure Kubernetes Service: Why Your Cost Optimization Strategy Is Probably Broken
자주 묻는 질문
Code Mode는 모든 API와 함께 작동합니까? API가 OpenAPI 스펙을 가지고 있고 HTTP를 통해 접근 가능한 한, Code Mode는 그것을 발견하고, 스키마를 검사하고, 호출할 수 있습니다. 샌드박스는 대상 시스템에 도달하도록 네트워크 송신 규칙을 구성해야 합니다.
Code Mode가 기존 MCP 설정을 대체할까요? 반드시 그렇지는 않습니다. 도구 레지스트리가 작고 토큰 소비가 병목이 아니라면, Code Mode로 마이그레이션하면 이익 없이 복잡성을 추가합니다. 실제 토큰 오버헤드와 지연 시간 요구 사항을 기반으로 평가하세요.
OpenSandbox는 프로덕션 준비가 되었습니까? Yes—CNCF Landscape에 있으며 Docker/Kubernetes의 엔터프라이즈 배포를 지원합니다. 하지만 생태계 성숙도와 커뮤니티 지원은 아직 주류 도구 수준에 있지 않습니다.
