Molayo

© 2026 Molayo

Zenn헤드라인2026. 06. 15. 15:31

MCP는 연결 수보다 protocol watch를 먼저 고정해야 한다

요약

MCP(Model Context Protocol) 운영 시 단순 연결 수 증설보다 프로토콜 사양 변화를 추적하는 'protocol watch'를 우선해야 함을 강조합니다. 설계 원칙을 정본화하여 sampling 의존성을 낮추고 roots, prompts, resources 등 핵심 요소를 관리하는 체계적인 접근법을 제안합니다.

핵심 포인트

  • MCP 운영의 핵심은 연결 수가 아닌 프로토콜 사양 변화 추적임
  • sampling 의존성을 줄이고 roots, prompts, tools 등을 우선하는 설계 원칙 필요
  • transport 방식과 관계없이 공통된 설계 논점을 고정하여 운영 효율성 증대
  • MCP를 단순 증설 대상이 아닌 전제 관리 태스크로 접근해야 함

서론

MCP를 다루기 시작하면, 자신도 모르게 "몇 개나 연결했는가"를 진척도로 보고 싶어집니다. 저 또한 처음에는 그런 관점으로 바라보았습니다. 하지만 2026-05-31에 Vault 운영 규칙을 재검토했을 때, 먼저 고정해야 할 것은 연결 수가 아니라 사양 변화를 어떻게 추적할 것인가에 대한 판단 기준이라고 정리했습니다.

그날 실제로 수행한 작업은, 주간 리뷰에서 파악된 차이점을 AI-AGENT.md, AGENTS.md, runtime-capabilities.json, 그리고 관련 운영 skill에 반영하고, sampling 의존성을 늘리지 않으면서 roots / prompts / resources / tools / elicitation을 우선하는 방침을 정본(正本)화하는 것이었습니다. 일일 메모에도 "hook 추가보다, sampling 비의존적 MCP 설계 원칙과 protocol watch를 정본에 추가하는 것이 우선"이라고 남겨두었습니다.

2026-05-31에 변경한 내용

판단의 출발점은 ADR ADR-2026-05-31-mcp-protocol-watch-and-design-principles.md입니다. 여기서는 "연결 재고 조사만 계속한다"는 안이 아니라, "정본에 원칙 추가"를 채택했습니다. 이유는 단순합니다. MCP의 가치가 연결 수 그 자체가 아니라, 어떤 측면을 사용하는지로 옮겨갔기 때문입니다.

실제로 정본인 AI-AGENT.md에는 다음과 같은 guidance를 추가했습니다.

신규 MCP 설계・추가・평가 시에는
roots / prompts / resources / tools / elicitation 을 우선하며,
sampling 전제의 신규 의존은 피한다

같은 날 관련 있는 두 가지 운영 skill에도, 주간 체크 시 roots / prompts / resources / tools / elicitation과 sampling의 취급을 확인하는 절차를 넣었습니다. 즉, "MCP를 사용한다"가 아니라, "MCP의 어떤 측면을 모니터링 대상으로 할 것인가"를 운영 규칙으로 격상시켰습니다.

연결 수보다 먼저 봐야 할 것

이 판단이 효과적이었던 이유는, transport가 다르더라도 바라보는 관점을 통일할 수 있었기 때문입니다. 현재 구현 중인 환경에서도, 로컬의 stdio 서버는 @modelcontextprotocol/sdk/server/stdio.js의 StdioServerTransport를 사용하고, Cloudflare Workers 측의 HTTP 구현은 JSON-RPC 2.0의 initialize / tools/list / tools/call을 자체적으로 받고 있습니다. transport는 다르지만, "어떤 tool을 공개할 것인가", "resource나 prompt를 갖게 할 것인가", "정말로 신규 연결이 필요한가"라는 설계 논점은 공통적입니다.

이 공통 논점을 먼저 고정해 두면, 나중에 새로운 MCP를 발견하더라도 판단이 흔들리지 않습니다. 저의 운영 방식에서는 먼저 기존 plugin / Browser / CLI / Docs MCP로 대체 가능한지 확인하고, 대체할 수 없을 때만 신규 연결을 검토하게 되었습니다. 실제로 이 방침은 현재의 MCP 설정 메모에서 "Google Drive / Gmail / Calendar / Slack은 plugin으로 covered", "일부는 partial"이라고 정리해 둔 내용과도 일치합니다.

protocol watch를 도입해서 좋았던 점

가장 컸던 점은 MCP를 "증설 태스크"가 아니라 "전제 관리 태스크"로 다룰 수 있게 되었다는 것입니다. 2026-05-31의 일일 메모에는 Codex 세션의 결론으로서 "먼저 늘려야 할 것은 hook이 아니라, MCP의 전제 변화를 판단 기준으로 고정하는 것"이라고 적혀 있습니다. 이는 상당히 실감에 가까운 내용입니다.

운영을 하다 보면 도구의 수보다 "그 연결이 지금도 필요한가", "기존 경로로 대체할 수 없는가", "sampling 전제를 떠안고 있지는 않은가"가 나중에 더 큰 영향을 미칩니다. 미리 그 부분을 명문화해 두면 주간 리뷰에서 확인해야 할 차이점이 줄어들고, 연결을 추가할 때의 설명 책임도 가벼워집니다.

요약

  • MCP 운영의 첫 번째 지표를 "연결 수"에 두면 설계 판단이 흔들리기 쉽다
  • 먼저 고정해야 할 것은 roots / prompts / resources / tools / elicitation

어떻게 사용할지에 대한 판단 기준 -
sampling

은 편리해 보일지라도, 새로운 의존성의 전제로 삼지 않는 것이 운영 안정성을 높이는 데 유리했다 - transport가 stdio이든 HTTP이든, 감시해야 할 논점은 상당히 공통화될 수 있다

  • 새로운 MCP를 추가하기 전에 기존 plugin / Browser / CLI / Docs MCP로 대체할 수 있는지 확인하는 것만으로도, 연결의 증식을 상당히 억제할 수 있다

Discussion

AI 자동 생성 콘텐츠

본 콘텐츠는 Zenn AI의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.

원문 바로가기
0

댓글

0