기업 AI 팀의 78%가 현재 MCP 기반 에이전트를 프로덕션(production)에서 실행하고 있으며, Fortune 500 기업의 28%가 자체 MCP 서버를 운영하고 있습니다.

생태계는 10,000개 이상의 서버를 돌파했으며, SDK 다운로드 횟수는 월간 약 9,700만 회에 달합니다.

Anthropic이 프로토콜을 오픈 소스로 공개한 지 2년이 채 되지 않았지만, MCP는 더 이상 흥미로운 실험 단계가 아닙니다. 이는 AI 에이전트가 기업 데이터에 도달하는 기본 방식(default way)이 되었습니다.

이것은 좋은 소식입니다.

나쁜 소식은 도입 속도가 보안 성숙도보다 빨랐다는 점입니다. 이러한 프로덕션 배포의 대부분은 데모 시대에 구축되었습니다. 즉, 설정 파일에 공유된 API 키를 사용하거나, 모든 도구를 모든 호출자에게 노출하는 식이었으며, 그 이후로 한 번도 보안 강화(hardened) 과정을 거치지 않았습니다.

그것들은 작동합니다. 하지만 동시에 자율 에이전트에게 여름 인턴에게 허용할 수준보다도 낮은 접근 제어(access control)를 가진 채 기업 데이터의 열쇠를 넘겨주고 있는 셈입니다.

실험에서 인프라로

타임라인을 살펴보는 것은 가치가 있습니다. 왜냐하면 그것이 문제를 설명해주기 때문입니다.

MCP는 기록적인 속도로 참신한 기술에서 인프라(infrastructure)로 변모했습니다. 이제 모든 주요 벤더가 서버를 출시하고 있습니다. Microsoft 한 곳만 해도 Copilot, Copilot Studio, Azure AI Foundry 전반에 걸쳐 60개 이상의 MCP 서버 카탈로그를 제공합니다. 그리고 7월 28일 단 5일 만에, MCP 출시 이후 가장 큰 사양 개정(specification revision)이 공식 스펙이 되었으며, 이는 이전 프로토콜 버전에 대한 12개월의 폐기(deprecation) 카운트다운을 시작했습니다.

공식적인 폐기 정책(deprecation policy)을 가진 프로토콜은 더 이상 실험이 아닙니다. 그것은 배관(plumbing)입니다.

그리고 배관에 관한 중요한 사실이 있습니다. 실험은 공격받지 않지만, 인프라는 공격받습니다.

Fortune 500 기업의 28%가 무언가를 실행하고 있다면, 그 무언가는 공격 대상이 됩니다. 주말 데모용으로는 문제가 없었던 보안 태세(security posture) — 그 뒤에 가치 있는 것이 아무것도 없었기 때문에 — 가 이제는 CRM, ERP, 재무 데이터, 그리고 고객 기록 앞에 놓여 있습니다.

팀들이 잘못하고 있는 세 가지 방식

지난 1년 동안 저는 수많은 MCP 배포 사례를 살펴보았으며, 실패 사례들은 세 가지 패턴으로 모입니다.

1. 과도하게 광범위한 도구 노출 (Over-broad tool exposure)

가장 흔한 실수는 가장 단순한 것입니다. 서버가 연결된 모든 에이전트에게 자신이 가진 모든 도구를 넘겨주는 것입니다.

데이터베이스를 읽으라고요? 물론이죠. 데이터베이스를 삭제하라고요? 그것도 물론이죠. 동일한 카탈로그, 동일한 호출자, 아무런 구분이 없습니다.

이는 보안의 가장 오래된 규칙인 최소 권한 원칙 (least privilege)을 위반하며, 호출자가 언어 모델 (language model)이기 때문에 최악의 계층에서 이 위반이 발생합니다. 올해 발표된 MCP 보안에 관한 모든 진지한 논의들은 동일한 결론에 도달합니다. 에이전트가 보는 도구 카탈로그는 서버가 무엇을 할 수 있느냐가 아니라, 해당 에이전트의 _사용자_가 무엇을 할 수 있도록 허용되었느냐에 따라 범위가 지정되어야 합니다.

만약 에이전트가 파괴적인 도구를 열거(enumerate)할 수 있다면, 언젠가 어떤 프롬프트(prompt)가 그 도구를 호출하도록 에이전트를 설득할 것입니다.

2. 사후 부착되었거나 부재하는 인증 (Bolted-on or absent authentication)

두 번째 실패는 진정한 인증이 아닌 인증입니다.

JSON 설정 파일에 붙여넣은 장기 사용 API 키는 신원 (identity)이 아닙니다. 그것은 교체되지도 않고, 설정을 복사하는 모든 사람이 공유하며, 특정 사용자와 연결되지도 않고, 귀하의 ID 제공자 (identity provider)에게는 보이지도 않는 비밀번호일 뿐입니다.

프로토콜 자체는 이미 이를 넘어섰습니다. MCP 팀은 최근 기업 관리형 권한 부여 (Enterprise-Managed Authorization) 확장 기능을 안정화 상태로 승격시켰으며, 이는 조직의 ID 제공자를 통해 MCP 서버 액세스를 라우팅합니다. 이 기능은 이미 Anthropic의 Claude, Claude Code, Cowork을 비롯하여 Visual Studio Code, 그리고 서버 측에서는 Asana, Atlassian, Canva, Figma, Linear, Supabase에서 지원을 시작했습니다.

프로토콜 자체의 "누가 호출하는가?"에 대한 답변이 _사용자의 IdP(Identity Provider, ID 제공자)_일 때, dotfile에 공유된 베어러 시크릿(bearer secret)을 두는 것은 더 이상 실용적인 지름길이 아닙니다. 그것은 폭발 반경(blast radius)을 가진 기술 부채(technical debt)입니다.

3. 대화(conversation)를 신뢰하는 문제

세 번째 실패는 미묘하며, MCP 보안을 API 보안과 진정으로 다르게 만드는 요소입니다.

에이전트(agent)는 구조적으로 '혼란스러운 대리인(confused deputy)'입니다. 에이전트는 도구 결과, 웹 페이지, 이메일, 문서 등을 읽으며, 이 모든 입력값은 잠재적인 지시 채널(instruction channel)이 됩니다. 도구 출력(tool output)을 통한 프롬프트 인젝션(Prompt injection)은 이론적인 공격이 아니라 표준적인 공격입니다.

이는 아키텍처 측면에서 한 가지를 의미합니다: 대화에는 방화벽을 칠 수 없습니다. 어떤 시스템 프롬프트(system prompt), 가드레일(guardrail) 문구, "도구를 책임감 있게만 사용해 주세요"와 같은 서문도 버텨낼 수 없습니다. 보안 검사가 프롬프트 안에 있다면, 그 보안 검사는 단지 제안에 불과합니다.

권한 결정은 서버의 엔드포인트(endpoint)에 존재해야 하며, 모델이 자신이 무엇을 하고 있다고 믿든 상관없이 모든 호출에서 강제되어야 합니다. 저는 이전에도 권한 경계가 없는 에이전트형 AI는 그저 UX가 있는 악성코드일 뿐이라고 쓴 적이 있습니다. 기업 규모의 MCP는 그 말이 단순한 슬로건을 넘어 실제 사고 보고서(incident report)가 되는 바로 그 지점입니다.

올바르게 수행하는 방법

해결책은 생소한 것이 아닙니다. 위에서 언급한 각 실패 사례에 대응하는 세 가지 원칙입니다.

공유된 비밀(shared secrets)이 아닌 신원(Identity). 모든 MCP 세션은 실제 사용자에게 속해야 하며, 만료되는 토큰을 사용하여 실제 신원 인프라(identity infrastructure)를 통해 인증되어야 합니다. 사용자별로 관리되고, 취소 가능하며, 감사(auditable) 가능해야 합니다.

역할 기반의 도구 카탈로그(Role-gated tool catalogs). 에이전트가 받는 tools/list는 에이전트가 확인하기 전에 호출자의 역할(role)에 따라 필터링됩니다. 에이전트는 자신이 열거(enumerate)할 수 없는 도구를 호출하도록 유도될 수 없습니다.

최후의 보루로서의 서버 측 강제 적용 (Server-side enforcement). 설령 카탈로그가 유출되거나 모델이 도구 이름을 환각(hallucination)하더라도, 엔드포인트 자체가 모든 호출 시 권한 부여(authorization)를 확인합니다. 프롬프트는 제안할 뿐이며, 서버가 결정합니다.

이것이 Magic Cloud의 MCP 서버가 구축된 방식입니다. 이는 제품 홍보가 아니라 이 패턴의 실제 작동 사례로서 설명할 가치가 있습니다. 왜냐하면 Magic은 MCP에 보안을 추가한 것이 아니라, MCP가 보안을 상속받도록 했기 때문입니다.

Magic의 모든 MCP 도구는 고유한 권한 요구 사항을 가진 HTTP 엔드포인트입니다. 액세스 토큰(access token)은 실제 역할(role)을 가진 실제 Magic 사용자와 연결된 실제 JWT입니다. API를 보호하는 것과 동일한 인증(auth) 시스템이 MCP 표면(surface)을 보호하는데, 이는 두 표면이 동일하기 때문입니다. 에이전트가 연결될 때, 에이전트가 받는 도구 목록은 해당 사용자의 역할이 허용하는 엔드포인트 목록일 뿐 그 이상도 아닙니다. 그리고 에이전트가 도구를 호출할 때, 역할 확인은 모든 단일 호출에 대해 엔드포인트 로직이 실행되기 전 서버 측에서 수행됩니다.

설정하거나, 드리프트(drift)되거나, 잊어버려야 할 별도의 "MCP 보안 모델"은 존재하지 않습니다. 사용자가 HTTP를 통해 엔드포인트를 호출할 수 없다면, 그들의 에이전트도 MCP를 통해 호출할 수 없습니다. 하나의 계약이 한 곳에서 한 번에 강제됩니다.

이것이 최첨단 코딩 에이전트가 세션 동안 이를 적극적으로 깨뜨리려고 시도했을 때 버텨낼 수 있었던 이유이며, 에이전트가 단 한 번의 대화로 역할 보안이 적용된 전체 CRM을 구축하도록 허용할 수 있게 만드는 동일한 경계입니다. 프롬프트가 아니라 플랫폼이 에이전트가 무엇을 건드릴 수 있는지 결정합니다.

창문이 닫히고 있습니다

이것이 나중이 아니라 지금 중요한 이유는 다음과 같습니다.

7월 28일 사양(spec) 릴리스로 인해 12개월의 지원 종료(deprecation) 시계가 작동하기 시작했습니다. 프로덕션에서 MCP를 실행 중인 모든 팀은 원하든 원치 않든 향후 1년 내에, 최소한 지원이 종료되는 프로토콜 버전에서 벗어나기 위해서라도 자신들의 스택(stack)을 수정해야 할 것입니다.

이러한 마이그레이션(migration)은 데모 시대가 남긴 문제점들을 바로잡을 수 있는 자연스러운 시점입니다. 공유 키(shared key)를 신원 기반 토큰(identity-backed tokens)으로 교체하십시오. 역할(role)에 따라 도구 카탈로그(tool catalog)의 범위를 제한(scope)하십시오. 권한 확인(permission check)을 원래 있어야 할 곳인 서버로 내려보내십시오. 이미 수행해야 하는 마이그레이션의 일부로 이를 처리하는 것은 비용이 적게 듭니다. 하지만 광범위하게 열려 있는 카탈로그를 가진 에이전트가 오염된 도구 결과(poisoned tool result)에 의해 주입(injected)된 이후에 이를 처리하는 것은 비용이 매우 많이 듭니다.

78%에 속해 있다는 것은 더 이상 차별화 요소가 아닙니다. 모두가 그 78%에 속해 있습니다.

차별화 요소는 에이전트가 프로덕션에 투입되었을 때 가장 중요한 단 하나의 질문에 대해, 사용자별로 정확하게 답할 수 있는 소수에 속하는 것입니다:

이 에이전트가 정확히 무엇을 할 수 있으며, 누가 그렇게 허용했는가?

Magic은 MIT 라이선스이며 오픈 소스입니다 — 저장소는 github.com/polterguy/magic에 있으며, 문서는 docs.ainiro.io에서 확인할 수 있습니다.

원문은 hyperlambda.dev에 게시되었습니다.