Originally published at curatedmcp.com/blog/week-2026-28

MCP 생태계 28주차: IDE 간 표준화가 중요한 이유 — 허용 목록(Allowlist)에 이것이 필요한 이유

MCP 생태계는 대부분의 플랫폼 팀이 추적할 수 있는 속도보다 더 빠르게 파편화되고 있습니다. 이번 주의 데이터는 중요한 변화를 보여줍니다. 개발자들은 GitHub, OpenAI, Figma, Anthropic Claude와 같이 유용성이 높은 소수의 서버 세트로 표준화하고 있지만, 이를 네 가지 서로 다른 AI 코딩 환경(Claude Code, Cursor, Windsurf, GitHub Copilot)에서 실행하고 있습니다. 이는 여러분의 허용 목록(Allowlist) 정책이 단순히 어떤 서버를 승인하느냐의 문제가 아니라, _팀이 어디에서 사용하든 서버가 동일하게 작동하도록 보장하는 것_에 관한 문제임을 의미합니다. 이번 주에 추가된 한 가지 새로운 서버가 바로 이러한 과제를 강조합니다.

이번 주의 MCP 소식

카탈로그에 위험 분류된(risk-classified) 새로운 서버를 하나 추가했습니다:

threadctx-mcp — AI 코딩 에이전트를 위한 공유 메모리(shared memory) 서버입니다. 여기서 거버넌스(governance) 신호는 명확합니다: threadctx-mcp는 설정 드리프트(config drift) 없이 Claude Code와 Cursor에서 동일하게 작동합니다. 만약 여러분의 팀이 두 IDE를 모두 사용한다면(대부분의 팀이 그렇습니다), 이는 핵심 허용 목록(allowlist)의 후보가 될 수 있습니다. 인증이 필요 없고, 외부 데이터 커넥터가 없으며, 공급망 위험(supply-chain risk)이 최소화되어 있습니다. 의사 결정 트리: 팀이 코딩 세션 전반에 걸쳐 지속적인 대화 상태(persistent conversation state)가 필요한가? 만약 그렇다면, 전체 배포 전에 파일럿 그룹에서 테스트하십시오. 만약 아니라면, 에이전트 복잡성을 줄이기 위해 차단하십시오.

현재 카탈로그에는 74개의 위험 분류된 서버가 포함되어 있으며, 모두 무료 티어(free tier)입니다. 이번 주에 등장한 유료 MCP 의존성은 없습니다. 이는 비용 투명성 측면에서 조용한 승리이지만, 진정한 거버넌스 과제는 비용이 아니라 _속도(velocity)_입니다. 개발자들은 마켓플레이스에서 이러한 서버들을 보고 사용을 요청합니다. 여러분의 허용 목록(allowlist)은 이 속도에 발을 맞추거나, 아니면 그림자 MCP(shadow MCP) 채택을 유도하는 마찰 지점이 될 것입니다.

주목할 만한 사항

이번 주 개발자들의 관심을 독점한 다섯 가지 서버는 다음과 같습니다:

1. GitHub Copilot MCP (98k views) — GitHub의 코드 인텔리전스 (code intelligence)를 직접 통합합니다. 거버넌스 (Governance) 고려 사항: 귀하의 조직은 Copilot이 프라이빗 저장소 (private repo) 데이터를 사용하는 것을 허용합니까? 이 서버는 해당 질문을 즉각적으로 제기합니다.

2. OpenAI MCP (87k views) — GPT-4o, DALL-E, Whisper, 그리고 임베딩 (Embeddings). 주의 사항 (Red flag): 토큰 사용량 귀속 (token spend attribution). 만약 이 서버를 통해 호출을 로깅 (logging)하지 않는다면, 청구서에서 제3자 모델 비용을 확인할 수 없습니다.

3. Figma MCP (82k views) — 디자인 시스템 (design system) 접근. 인증 (Auth) 모델: 일반적으로 Figma 워크스페이스에 대한 OAuth를 사용합니다. 허용 목록 (allowlisting)에 추가하기 전에 IT 팀이 토큰 범위 (token scope)를 감사 (audit)했는지 확인하십시오.

4. GitHub MCP (76k views) — 저장소 (Repo) 및 워크플로 (workflow) 관리. 영향력은 높지만, 승인 프로세스 (approval flows)가 취약할 경우 위험도 높습니다. 잘못 설정된 에이전트 (agent)가 승인되지 않은 PR을 머지 (merge)할 수 있습니다.

5. Anthropic Claude MCP (76k views) — 하위 에이전트로서의 Claude (Claude-as-sub-agent). 중첩된 모델 호출 (Nested model calls)은 토큰 사용량과 지연 시간 (latency)을 배가시킵니다. Claude 사용량을 측정하고 있다면, 이 서버는 호출당 관찰 가능성 (per-call observability)이 필요합니다.

이 다섯 가지 모두 신호가 높고(high-signal) 밀접한 관리가 필요한(high-touch) 항목들입니다. 귀하의 조직의 인증 모델 (auth model), 데이터 분류 (data classification), 그리고 감사 태세 (audit posture)에 특화된 위험 검토 없이 그 어느 것도 허용 목록에 추가해서는 안 됩니다.

거버넌스 핵심 요약 (Governance Take)

여기 냉혹한 현실이 있습니다: 대부분의 플랫폼 팀은 _하나_의 AI 코딩 환경에 대한 허용 목록을 가지고 있으며, 그것이 모든 곳에 적용된다고 가정합니다. 하지만 그렇지 않습니다. Cursor는 하나의 설정 파일 (config file)을 읽습니다. Claude Code는 다른 파일을 읽습니다. GitHub Copilot은 허용 목록을 전혀 읽지 않습니다. 조직 수준의 정책 (org-level policy)을 준수하지만, 이는 세밀하지 않은 (coarse-grained) 방식입니다. Windsurf는 자체적인 모델을 가지고 있습니다. 결과적으로: 개발자들은 서로 다른 머신에서 서로 다른 MCP 스택을 실행하게 되며, 귀하의 중앙 감사 로그 (central audit log)에는 사각지대가 발생하게 됩니다.

지금 바로 시작하세요: 이번 주 귀하의 4가지 주요 IDE 전반에서 실제로 어떤 MCP 서버들이 실행되고 있는지 인벤토리(inventory)를 작성하십시오. 다 알고 있다고 가정하지 마십시오. 가능하다면 머신 레벨의 텔레메트리 (machine-level telemetry)를 사용하거나, 자발적인 감사 스윕 (audit sweep)을 실행하십시오. 그런 다음 가장 영향력이 큰 5개의 서버를 선정하십시오 (GitHub, Anthropic Claude, OpenAI는 안전한 삼인조입니다). 그리고 4개의 IDE 모두에 대해 동일한 위험 분류 (risk classification)를 적용하십시오. 예외 사항은 문서화하십시오. TokenShield를 사용하여 IDE 및 서버별 실시간 지출 원장 (spend ledger)을 구축하십시오. 그러면 누군가 "왜 우리의 Claude 지출이 40%나 늘었나요?"라고 물었을 때, 특정 서버와 특정 개발자 그룹 (cohort)으로 그 원인을 추적할 수 있습니다.

이 분야에서 승리하는 팀들은 모든 것을 차단하려고 하지 않습니다. 그들은 무엇이 실행되고 있는지 알고, 허용 목록 (allowlist)을 동기화 상태로 유지함으로써 승리합니다. 그것이 바로 대규모 거버넌스 (governance at scale)입니다.

CuratedMCP를 통해 팀 전체의 MCP 사용을 관리하십시오 — 또는 https://www.curatedmcp.com/auditor에서 귀하의 스택을 무료로 스캔하십시오.