How to Save Bloated MCP with Code Mode
Is MCP Dead Because of Agent Skills? It sometimes feels like AI is not just disrupting the...
Agent Skills 때문에 MCP는 죽었는가? #
AI가 SaaS 같은 구세계만 파괴하는 게 아니라 자신이 낳은 신세계의 자식들까지 잡아먹고 있다는 느낌이 들 때가 있다. 1년도 안 돼 MCP(Model Context Protocol — AI 에이전트와 외부 도구를 연결하는 표준 프로토콜)는 업계의 "황금 아이"였고, 모든 벤더와 플랫폼이 통합에 열을 올렸다. 그런데 6개월 후 스포트라이트는 다시 이동했다 — 이번엔 Agent Skills로, MCP의 영광을 꽤 많이 가져간 동생이 등장했다.
소셜 미디어에는 "MCP is dead"가 넘쳐났다. 이전의 "SaaS is dead"처럼. 하지만 이건 바이럴을 위한 극단적 표현이다. Anthropic이 2025년 말 MCP를 Linux Foundation에 기증하고 Agent Skills를 오픈 스탠다드로 공개할 때 한 발언을 먼저 들어보자.
Skills와 MCP 서버가 얼마나 상호 보완적인지도 확인했습니다. MCP는 외부 소프트웨어와 데이터에 대한 안전한 연결을 제공하고, Skills는 해당 도구들을 효과적으로 활용하기 위한 절차적 지식을 제공합니다. 강력한 MCP 통합에 투자한 파트너들이 자연스러운 출발점이었습니다. — Mahesh Murag, Anthropic Product Manager
실제 산업 현장에서 이것이 어떻게 작동하는지는 Skills vs MCP tools for agents: when to use what에서 확인할 수 있다.
remote HTTP MCP 서버는 vibe-coding에서 agentic engineering으로의 전환에서 조직·엔터프라이즈 도입의 핵심 연결고리가 될 것이라는 시각도 제시되어 있다.
OAuth 기본 지원이 추가된 점도 중요하다. 조직 도입에서 가장 실용적인 부분 중 하나다.
엔지니어가 팀을 떠났나요? 그들의 OAuth 토큰을 취소하면 MCP 서버 접근이 차단됩니다. 처음부터 다른 키나 시크릿에 대한 접근 권한이 없었으니까요.
MCP는 비대해진다 #
ZenStack 커뮤니티 내에서 관련 블로그 포스트가 꽤 주목을 받았다. 깔끔한 ZenStack 솔루션을 감안하면 Auth가 통합된 다양한 MCP 서버가 나올 줄 알았다.
그런데 그런 일은 없었다. 한 사용자가 GitHub 이슈를 올리고 나서야 이유를 알게 됐다.
요약하면, MCP 서버가 제공하는 도구 단 하나를 로드하려 했는데도 context window가 40만 토큰으로 부풀어 올라 실사용이 불가능해진 것이다. 이 "context bloating" 문제는 MCP에서 가장 많이 지적받는 단점이고, 사람들이 Skills로 갈아타는 이유 중 하나다. 공식 Playwright GitHub도 Playwright CLI와 Playwright MCP를 비교하며 이렇게 설명한다.
현대의 코딩 에이전트는 MCP보다 SKILL로 노출된 CLI 기반 워크플로우를 점점 더 선호합니다. CLI 호출이 더 토큰 효율적이기 때문입니다. 큰 tool schema와 장황한 accessibility tree를 모델 컨텍스트에 로드하는 것을 피할 수 있고, 에이전트가 간결하고 목적에 맞는 명령을 통해 행동할 수 있습니다.
ZenStack의 접근 방식은 이 문제를 최대한으로 증폭시켰다. ZenStack MCP 서버가 노출하는 도구가 ORM의 쿼리 API인데, 이는 Prisma ORM 쿼리 API의 상위 집합(superset)이기 때문이다. 이 API의 강점 중 하나는 중첩 관계 쿼리(nested relation queries)를 허용한다는 점이다. 단일 함수 호출로 전체 데이터베이스의 모든 모델을 순회할 수 있다.
물이 배를 띄울 수도 있지만 뒤집을 수도 있다. 단 하나의 MCP server tool에 대해 생성된 JSON schema조차도 애플리케이션 전체 schema를 담아 비대해진다.
간단한 해결책은 중첩 관계 순회 깊이를 제한해 JSON schema를 단순화하는 것이다. 하지만 이건 근본적인 해결책이 아니라 임시방편이다.
- 모델의 일부만 선택할 수 있어 실용적이지도 않고 확장하기도 어렵다. 대규모 프로젝트에서는 아예 쓸 수 없다.
- 쿼리 API의 강점 자체를 잃게 된다.
Code Mode MCP의 등장 #
소프트웨어 개발의 좋은 점 중 하나는, 어떤 문제를 만나도 대부분 처음 겪는 게 아니라는 점이다. 여기서 Cloudflare가 내놓은 솔루션이 있다: Code Mode MCP
Cloudflare의 접근법은, 모든 작업을 별도의 tool로 기술하는 대신 LLM이 코드를 직접 작성하게 하는 것이다. 이를 Code Mode라고 부른다. 구체적으로는, Cloudflare API 전체를 위한 MCP 서버가 단 두 개의 tool만 노출한다: search와 execute. API 엔드포인트가 아무리 늘어나도 footprint는 고정된다. 결과적으로 입력 토큰 사용량을 99.9% 줄여 약 1천 토큰 수준으로 낮추는 데 성공했다.
ZenStack의 솔루션 #
Cloudflare와 똑같이 search와 execute tool을 노출하는 방법도 있었다. 하지만 ZenStack은 두 가지 특성 덕분에 더 잘할 수 있었다.
- 하나의 모델은 기술적으로 전체 데이터베이스의 모든 다른 모델과 연결되어 있다.
- LLM은 이미 Query API 작성 방법을 꽤 안다. Prisma 덕분에 훈련 데이터셋의 GitHub과 블로그 포스트에서 수많은 예시를 접했기 때문이다.
그래서 3개의 tool을 제공한다.
schema #
search tool 대신, 애플리케이션 전체 그림과 간단한 예시를 포함한 전체 schema를 LLM에 넘기는 schema tool을 제공한다.
execute #
execute는 그 이상을 하지 않는다. 오히려 더 단순하다. 임의의 코드 대신 findMany, createMany, updateMany 같은 쿼리 API에 해당하는 고정된 수의 함수 호출만 실행하기 때문이다.
check #
execute 전에 LLM이 구성한 함수 호출의 파라미터가 유효한지 확인하는 tool이다. execute의 오류 메시지만으로도 LLM이 올바른 파라미터를 파악할 수 있으니 일종의 보너스(icing on the cake)이기도 하다.
execute의 prompt에는 다음 내용을 반드시 추가해야 한다.
You MUST use the "check" tool first to validate the query before calling this tool
check를 추가한 이유는 사람과 AI 모두에게 통하는 소프트웨어 엔지니어링 원칙, 즉 "높은 응집도와 낮은 결합도(High cohesion and low coupling)"를 지키기 위해서다.
Claude로 테스트 #
50개 이상의 모델과 AI 생성 목(mock) 데이터로 복잡한 헬스장 애플리케이션을 시뮬레이션하고, Claude 데스크탑(Sonnet 4.6)으로 직접 테스트했다. 결과는 꽤 견고하다.
10개 이상의 모델이 관련된 복잡한 중첩 쿼리도 생성할 수 있었고, 렌더링된 결과도 양호했다.
한 번에 완료할 수 없는 경우에는 여러 작업으로 나눠 처리하는 방법을 스스로 찾아냈다.
더 인상적인 부분은, 전체 실험에서 LLM이 생성한 초기 함수 호출이 잘못된 경우가 딱 한 번뿐이었는데 check tool이 이를 잡아냈고, LLM은 그냥 다른 경로로 작업을 완료했다.
직접 애플리케이션에서 시도해보기 #
로컬에서 실행해볼 수 있는 간단한 프로젝트가 있다: zenstack-code-mode-mcp
schema.zmodel을 자신의 애플리케이션에 맞게 바꾸면 바로 테스트해볼 수 있다.
이 글은 위 출처의 내용을 바탕으로 작성된 초안입니다. 원문의 의견과 정보를 그대로 전달하며, 별도의 견해를 포함하지 않습니다.