배경 및 맥락
MCP는 AI 모델과 외부 도구를 연결하는 표준 인터페이스로 빠르게 확산되고 있다. 초기에는 로컬 파일, 개발 도구, 사내 API를 에이전트에 연결하는 용도가 많았지만, 이제 GitHub, Slack, Notion, Stripe, Salesforce 같은 주요 플랫폼이 공식 MCP 접점을 제공하기 시작했다.
X의 hosted MCP 공개는 실시간 소셜 데이터가 agent-native 데이터 소스로 포장되는 사례다. 개발자가 별도 MCP 서버를 직접 만들고 호스팅하는 대신, X가 API와 문서 검색을 MCP 형태로 제공한다.
핵심 내용
X 문서에 따르면 두 개의 MCP 서버가 제공된다. X API용 서버는 https://api.x.com/mcp이며 posts 검색, users 조회, bookmarks 관리, trends와 news 조회, Articles 작성/게시 같은 API 기능을 노출한다. 문서 검색용 서버는 https://docs.x.com/mcp로, 에이전트가 X API 문서를 직접 검색하고 읽을 수 있게 한다.
인증 구조는 두 갈래다. 읽기 중심의 단순 경로는 app-only bearer token으로 remote MCP에 붙을 수 있고, 사용자 컨텍스트가 필요한 쓰기 작업은 xurl mcp 브리지를 통해 OAuth 2.0 PKCE 로그인을 수행한다. X 문서는 first-run browser login, token cache/refresh, headless 인증, Cursor/Claude Desktop/VS Code/Grok Build 설정 예시까지 제공한다.
경쟁 구도 / 비교
기존 API 통합은 SDK, REST 문서, 사내 wrapper 중심이었다. MCP는 이 접점을 에이전트가 바로 발견하고 호출할 수 있는 tool surface로 바꾼다. X가 직접 hosted MCP를 제공하면 개별 개발자가 만드는 비공식 브리지보다 진입 장벽은 낮아지지만, 플랫폼이 허용하는 scope와 정책 안에서만 동작한다.
Microsoft AutoJack 같은 최근 MCP 보안 이슈가 로컬 control plane 노출 위험을 보여줬다면, X 사례는 대형 플랫폼이 MCP를 공식 제품 표면으로 만드는 쪽이다. 즉 MCP의 다음 과제는 기능 연결이 아니라 인증, 권한, 비용, 남용 방지의 제품화다.
의미
실시간 데이터 플랫폼은 AI 에이전트에게 매력적인 맥락 공급원이다. 하지만 검색과 분석 기능이 쉬워질수록 자동 게시, 대량 조회, spam, 계정 권한 오남용 위험도 커진다.
개발팀은 MCP 서버를 붙일 때 단순히 도구가 잘 호출되는지보다 어떤 계정 권한으로 어떤 작업이 수행되는지, 토큰이 어디에 저장되는지, 쓰기 작업이 감사 가능한지 먼저 봐야 한다. 엔터프라이즈 환경에서는 read-only MCP와 write-enabled MCP를 별도 앱과 별도 policy로 분리하는 편이 안전하다.