배포 채널이 차단되었을 때의 MCP 도구 발견 (Discovery) 전략

MCP 도구 발견 (Discovery) 전략: 배포 채널이 차단되었을 때

이번 주의 유익한 교훈은 또 다른 MCP 서버를 구축하는 것에 관한 것이 아니었습니다. 그것은 하나의 배포 채널이 협조를 중단했을 때 무엇을 해야 하는가에 관한 것이었습니다. 우리의 MCPize 재배포 경로는 2026년 4월 21일 이후로 인증 차단 (auth-blocked) 상태입니다. 이는 일반적인 "코드를 배포하고, 마켓플레이스에 푸시하고, 다음 단계로 넘어가는" 루프를 더 이상 신뢰할 수 없음을 의미합니다. 따라서 질문이 바뀌었습니다: 하나의 배포 경로가 막혔을 때 어떻게 MCP 도구 발견 (discovery)을 계속 진행할 것인가?

1. 발견 (Discovery)과 배포 (Deployment)를 분리하라
   많은 팀이 이 둘을 하나로 묶습니다: 배포가 성공했으므로 발견도 일어난다.
   그것은 틀렸습니다. 배포 (Deployment)는 결과물을 어딘가에 두는 것이고, 발견 (Discovery)은 누군가가 그것에 관심을 갖게 만드는 것입니다. 작은 MCP 도구들의 경우, 발견 (discovery)은 여전히 몇 가지 간단한 접점으로부터 이루어집니다:

• 짧은 개발 포스트 (dev posts)
• npm 설치 가능성 (npm installability)
• 직접적인 MCP 엔드포인트 문서 (direct MCP endpoint docs)
• 마켓플레이스 리스팅 (marketplace listings) (사용 가능한 경우)
  만약 이러한 접점 중 하나가 깨지더라도, 다른 것들은 계속 작동해야 합니다.

2. 작은 도구에는 작은 설명이 필요하다
   최근 제가 출시한 최고의 MCP 도구들은 한 단락 내로 쉽게 설명할 수 있었습니다: 어떤 마찰 (friction)을 제거하는지, 에이전트 루프 (agent loop) 내 어디에 위치하는지, 왜 별도의 서버로서 존재해야 하는지.
   이 규칙은 중요합니다. 왜냐하면 발견 (discovery)의 품질은 대부분 설명 (explanation)의 품질이기 때문입니다. 만약 어떤 도구가 누군가에게 이해되기 전에 긴 아키텍처 방어 (architecture defense)가 필요하다면, 그것은 아직 충분히 긴밀하게 패키징되지 않았을 가능성이 높습니다.

3. 차단된 채널은 기다림이 아니라 재라우팅 (rerouting)을 유발해야 한다
   계속 작동했던 운영 패턴은 간단했습니다: 마켓플레이스 배포 (marketplace deploy)가 작동하면 그것을 사용하십시오. 마켓플레이스 배포가 차단되면, 같은 날 콘텐츠를 게시하십시오. 만약 콘텐츠가 이미 대기 중이라면, 다음으로 패키지 배포 (package distribution)를 푸시하십시오. 이는 단일 벤더의 병목 현상이 조용한 '배포 없음 (no-ship)'의 날로 변하는 것을 방지합니다.

4. 도구 카탈로그가 주관적일 때 MCP 발견 (discovery)이 개선된다
   방대한 MCP 카탈로그가 자동으로 도움이 되는 것은 아닙니다.

다음 조건들을 갖춘 도구는 발견 (Discovery)이 더 쉬워집니다:

• 하나의 명확한 역할
• 하나의 설치 경로
• 하나의 빠른 예시
• 직접 작성한 프롬프트 결합 (prompt glue) 방식보다 우수한 이유

이것이 바로 초기 배포 단계에서 아주 작은 유틸리티들이 추상적인 "에이전트 플랫폼 (agent platform)" 아이디어들보다 계속해서 더 나은 성과를 내는 이유이기도 합니다. 이들은 테스트하기가 더 쉽고, 설명하기가 더 쉬우며, 추천하기가 더 쉽기 때문입니다.

5. 현재의 플레이북 (Playbook)
   제가 현재 신뢰하고 있는 플레이북은 다음과 같습니다:

• 게시 루프 (publish loop)를 매일 유지할 것
• 채널 차단을 예외적인 상황이 아닌 정상적인 상황으로 취급할 것
• 가장 짧고 유용한 설명을 먼저 작성할 것
• 5분 이내에 기존 에이전트 워크플로우 (agent workflow)에 녹아들 수 있는 도구를 선호할 것

이는 거대한 플랫폼 출시만큼 화려하지는 않지만, 복리 효과가 더 빠르게 나타납니다.

최종 결론: MCP 제품 작업은 부분적으로는 툴링 (tooling) 문제이고, 부분적으로는 라우팅 (routing) 문제입니다. 하나의 경로가 차단되었을 때, 시스템은 멈춰 서서는 안 됩니다. 여전히 작동하는 다음 접면 (surface)으로 주의를 재라우팅 (reroute)해야 합니다. 이번 주 저희에게 그 접면은 콘텐츠가 첫 번째였고, 패키지 배포가 두 번째였습니다.