MCP(Model Context Protocol)가 등장한 지 약 1년 반이 지났다. Anthropic이 2024년 11월에 공개한 이 오픈 표준은 AI 모델이 외부 도구·데이터·서비스와 직접 연결되도록 설계됐다. 결과는 빠르게 나타났다. awesome-mcp-servers GitHub 저장소는 2026년 6월 기준 83,900개 이상의 스타를 기록했고, 파일 시스템부터 3D 프린터까지 수천 개의 MCP 서버가 커뮤니티에 올라와 있다. 숫자만 보면 생태계가 활발하게 돌아가는 것처럼 보인다.
그런데 현실은 조금 다르다. dev.to에 올라온 「Why MCP servers and Claude Code skills die quiet deaths」는 이 생태계의 불편한 진실을 정확히 짚는다. 새로운 MCP 서버가 매주 출시되고, Discord나 X에 한 번 포스팅되고, 별을 몇 개 받은 뒤 피드에서 조용히 사라진다. 빌더 자신의 피드에서도. 문제는 도구의 품질이 아니다. 분산 레이어(distribution layer)가 없다는 것이다. 이 카테고리에는 도구를 지속적으로 노출시키는 지배적인 집계 플랫폼도, 시간이 지나도 도구를 계속 표면 위로 끌어올리는 알고리즘도, 그 일을 직업으로 삼는 사람도 없다.
반대편에서는 MCP로 무엇을 만들 수 있는가에 대한 탐구가 빠르게 익어가고 있다. dev.to의 「MCP Project Ideas for Improving Efficiency in Daily Work」는 실제로 배포된 워크플로우 사례들을 정리한다. 미팅 후 30~45분이 걸리던 회의록 정리와 태스크 생성을 5분 이내로 줄이는 파이프라인, 경쟁사 가격 조사에 드는 2~3시간을 자동화하는 리서치 에이전트, 음성 메모를 LinkedIn 포스트로 변환하는 콘텐츠 엔진. 기술 스택은 단순하다. Gmail MCP, Google Drive MCP, Notion MCP, Brave Search MCP, Firecrawl MCP를 조합하면 대부분의 지식 노동자 워크플로우를 커버할 수 있다. Memory MCP를 붙이면 대화가 끊겨도 컨텍스트가 누적된다. 만드는 것 자체는 이미 충분히 접근 가능한 문제가 됐다.
여기서 핵심 긴장이 발생한다. MCP 생태계는 '빠른 프로토타이핑'이라는 첫 번째 관문은 낮췄지만, '지속적으로 발견되고 사용되는' 두 번째 관문은 여전히 높다. 이건 단순히 마케팅 문제가 아니다. 프로덕트 관점에서 보면 발견 가능성(discoverability)은 기능 설계만큼 중요한 UX 문제다. 사용자가 도구를 찾지 못하면, 도구는 존재하지 않는 것과 같다.
「Why MCP servers die」의 저자가 만든 marketing-pipeline은 이 문제에 대한 실용적인 응답이다. 온보딩은 커맨드 하나로 끝난다. marketing onboard --name my-tool --repo owner/repo --kind mcp-server를 실행하면 README를 읽고, Claude가 문제 정의·사실·앵글을 추출해 projects.yml에 기록한다. 이후 GitHub Actions 크론이 매 평일 14:00 UTC에 돌면서 프로젝트 × 앵글 × 채널을 순환하며 가장 오래 전에 사용된 앵글을 골라 Bluesky, X, Mastodon, Dev.to, Hashnode에 자동 포스팅한다. 흥미로운 건 여기서 가장 많은 시간을 쓴 부분이 포스팅 자동화가 아니라 안티-슬롭 게이트(anti-slop gate) 라는 점이다. excited, game-changer, unlock, empower, AI-powered, 이모지, 해시태그, 느낌표—이 토큰이 초안에 하나라도 포함되면 게시 전에 재생성된다. 목표는 제품 런치 템플릿이 아니라 실무자가 쓴 것처럼 읽히는 글이다.
이 설계 결정은 단순한 품질 관리 이상의 의미를 갖는다. AI가 생성하는 마케팅 콘텐츠가 넘쳐나는 지금, 역설적으로 'AI가 쓴 것처럼 보이지 않는 글'이 더 잘 발견된다는 통찰이다. 슬롭을 걸러내는 게이트는 기술적 문제가 아니라 신뢰 설계의 문제다. 사람이 읽고 싶은 글을 만들어야 알고리즘도, 사람도 계속 돌아온다.
물론 자동화에는 한계가 있다. awesome-claude-code는 GitHub 이슈 폼을 통한 수동 제출을 명시적으로 요구한다. 파이프라인이 페이로드를 생성해도 제출은 사람이 해야 한다. 이 지점은 상징적이다. 생태계의 신뢰 유지를 위해 인간 개입을 의도적으로 남겨둔 설계—완전한 자동화보다 검증 가능한 자동화를 선택한 것이다.
두 기사가 함께 가리키는 방향은 명확하다. MCP 생태계는 이제 '무엇을 만들 수 있는가'라는 질문에서 '어떻게 살아남게 할 것인가'라는 질문으로 이동하고 있다. 프론트엔드 개발자이자 프로덕트 빌더 관점에서 이건 익숙한 전환점이다. 기능을 만드는 것과 그 기능이 계속 사용되게 만드는 것은 다른 설계 문제다. MCP 서버도 다르지 않다. 배포 이후의 생존 설계—발견 가능성, 지속적 노출, 신뢰 기반의 커뮤니케이션—가 기술 구현만큼, 어쩌면 그 이상으로 중요해지는 시점이 왔다.