아무도 말하지 않는 MCP 서버 디렉토리 문제

문제가 발생하는 지점은 이렇습니다: 당신은 MCP 서버를 구축했습니다. 잘 작동합니다. 사람들이 이것을 찾기를 원합니다. 하지만 발견(Discovery) 과정이 엉망입니다.

GitHub 검색은 무작위 레포지토리(repos) 47페이지를 결과로 내놓습니다. Twitter 스레드는 묻혀버립니다. Discord 채널에서는 몇 시간 만에 지나쳐 버립니다. 당신의 서버는 별(star) 3개와 사용자 0명인 레포지토리에 놓여 있습니다.

이건 정말 별로입니다. 저도 압니다. 저도 그런 경험이 있습니다.

발견이 중요한 이유 (그리고 왜 망가졌는가)

MCP (Model Context Protocol)는 빠르게 성장하고 있습니다. 매주 데이터베이스, API, 파일 시스템 등 온갖 종류의 새로운 서버가 등장합니다. 하지만 생태계는 파편화되어 있습니다.

기술적인 현실은 다음과 같습니다:

• 중앙 집중식 레지스트리(registry)가 존재하지 않음
• GitHub 토픽(topics)이 일관되지 않음 (mcp-server, mcp-server-tool, mcp 등)
• 패키지 매니저(Package managers)가 MCP 서버를 특정하여 인덱싱하지 않음
• 검색 엔진은 유의미한 정보(signal)가 아닌 노이즈(noise)를 반환함

그다음 어떤 일이 벌어질까요? 개발자들은 적절한 서버를 찾는 데 몇 시간을 허비합니다. 혹은 더 나쁜 경우, 이미 존재하는 서버를 또 만듭니다.

수동적인 해결책: 디렉토리가 없을 때 당신이 하게 될 일

PostgreSQL을 위한 MCP 서버를 찾는다고 가정해 봅시다. 당신의 워크플로우는 다음과 같습니다:

# 1단계: GitHub 검색
gh search repos "mcp postgresql" --limit 50

...

익숙한 느낌인가요? 30분을 소비하고 나서 아마 3개 정도의 실행 가능한 서버를 찾았을 것입니다.

만약 당신의 서버를 제출하려 한다면:

# GitHub 레포지토리 생성
# 문서 작성
# Hacker News에 게시
...

이것은 워크플로우가 아닙니다. 도박입니다.

진짜 해결책: 실제로 작동하는 디렉토리

mcp.so가 이 문제를 해결하려 노력하고 있습니다. 그들은 MCP 서버의 큐레이션된 디렉토리를 구축하고 있습니다. 아이디어는 간단합니다: 서버를 찾고 제출할 수 있는 단 한 곳을 만드는 것입니다.

지금 바로 당신의 서버를 제출하는 방법은 다음과 같습니다:

1. GitHub issue로 이동

URL: https://github.com/chatmcp/mcpso/issues/1

2. 서버 링크 남기기

## My MCP Server

**Name:** postgres-mcp  
...

3. 나타날 때까지 기다리기

메인테이너(maintainers)가 검토 후 디렉토리에 추가합니다.

그게 전부입니다. API도 필요 없고, 인증(auth)도 필요 없습니다. 그저 GitHub issue 하나면 됩니다.

이 패턴이 작동하는 이유 (그리고 작동하지 않는 경우)

GitHub issue 제출 패턴에는 트레이드오프(tradeoffs)가 있습니다:

장점:

• 낮은 마찰(Low friction) — GitHub 계정이 있는 사람이라면 누구나 제출 가능
• 투명성(Transparent) — 모든 제출 내용을 확인할 수 있음
• 커뮤니티 검증(Community vetted) — issue에 댓글과 피드백이 달림

단점:

• 수동 검토(Manual review) — 시간이 소요됨
• 자동화 부재(No automation) — CI/CD나 검증(validation) 과정이 없음
• 확장성 부족(Scales poorly) — 서버가 1,000개라면 1,000개의 issue가 생김

v1 버전으로서는 괜찮습니다. 하지만 프로덕션(production) 환경을 위해서는 더 나은 무언가가 필요할 것입니다.

대신 내가 구축한다면

만약 제가 이것을 만든다면, 제출 흐름(submission flow)은 다음과 같을 것입니다:

// mcp-directory/submit.ts
interface MCPServerSubmission {
  name: string;
...

하지만 v0 단계에서 이는 오버엔지니어링(overengineering)입니다. GitHub issue만으로도 충분합니다. 그냥 사용하세요.

TracePilot이 어떻게 부합하는가 (네, 연결 고리가 있습니다)

당신은 MCP 서버를 구축하고 있습니다. 이 서버들은 LLM(Large Language Models)을 호출합니다. 그리고 그 LLM 호출들은 기이한 방식으로 실패하곤 합니다.

TracePilot은 당신의 MCP 서버 내 모든 LLM 호출을 캡처합니다 — 입력(input), 출력(output), 토큰(tokens), 지연 시간(latency)까지 말이죠. 무언가 고장 나면, 정확히 그 단계에서 실행을 포크(fork)하여 수정 사항과 함께 다시 재생(replay)할 수 있습니다.

// 당신의 MCP 서버 + TracePilot
import { TracePilot } from 'tracepilot-sdk';

...

당신의 MCP 서버는 mcp.so에서 발견됩니다. 그리고 당신의 LLM 호출은 TracePilot으로 디버깅(debugged)됩니다. 두 가지 문제를 단 한 오후 만에 해결하는 셈입니다.

지금 제출하세요

여기에서 당신의 MCP 서버를 제출하세요. 링크를 남기세요. 가시성(visibility)을 확보하세요.

그리고 하는 김에, 당신의 서버에 TracePilot을 추가하세요. 새벽 2시에 서버가 터질 때 저에게 고마워하게 될 것입니다.

AI 에이전트(AI agents)를 디버깅하는 것이 마치 매트릭스(The Matrix)를 읽는 것처럼 느껴져서는 안 됩니다.
우리 커뮤니티에서 신뢰할 수 있는 자율 워크플로우(autonomous workflows)를 구축하고 있는 다른 엔지니어들과 함께하세요: TracePilot Discord