MCP 서버 보안: Zero-Touch OAuth가 콘텐츠 스택에 의미하는 것

Model Context Protocol 커뮤니티가 중요한 보안 업데이트를 출시했습니다: Enterprise-Managed Authorization (EMA)가 이제 안정화되었습니다. 이번 주 MCP 블로그에 공식 발표가 올라왔으며, Anthropic, Microsoft, Okta, Figma, Asana, Atlassian, Linear, Supabase가 출시와 동시에 지원을 추가함에 따라 이미 개발자 커뮤니티에서 가장 주목받는 소식이 되었습니다.

만약 귀하의 팀이 AI 에이전트를 콘텐츠, 코드 또는 데이터에 연결하기 위해 MCP 서버를 사용하고 있다면, 이는 접근 제어(access control)에 대한 사고방식을 변화시킵니다. 어떤 일이 일어났는지, 이것이 왜 중요한지, 그리고 Cosmic의 MCP 서버가 이 그림에서 어떤 역할을 하는지 설명하겠습니다.

EMA가 해결하는 문제

표준 MCP 권한 부여(authorization) 모델은 개별 사용자를 위해 설계되었습니다. MCP 서버에 접근해야 하는 모든 직원은 한 번에 하나의 서버씩 수동으로 권한을 부여해야 합니다. 직원이 50명이고 연결된 MCP 서버가 10개인 회사라면, 누군가 실제 업무를 시작하기 전에 500개의 개별 OAuth 흐름(flows)을 거쳐야 합니다.

규모가 커질수록 고통은 가중됩니다:

모든 신입 사원이 동일한 수동 권한 부여 과정을 거쳐야 함
보안 팀이 누가 무엇을 승인했는지에 대한 중앙 집중식 뷰를 가질 수 없음
강제 적용 계층(enforcement layer)이 없기 때문에 개인 계정과 기업 계정의 경계가 모호해짐
퇴사 프로세스(Offboarding)가 임시방편적임: 누군가 퇴사해도 그들의 승인된 세션이 계속 유지될 수 있음

이것들은 예외적인 사례가 아닙니다. 이는 기업 환경에서 MCP 도입을 늦추는 정확한 마찰 지점들입니다.

Zero-Touch OAuth의 작동 방식

Enterprise-Managed Authorization은 조직의 ID 제공자(Identity Provider, IdP)를 모든 MCP 서버 접근에 대한 권위 있는 결정권자로 만듭니다. 관리자는 정책을 한 번만 정의합니다. 사용자는 기존의 기업 ID로 인증합니다. 올바른 서버들은 첫 로그인 시 자동으로 연결됩니다.

기술적 흐름은 Identity Assertion JWT Authorization Grant (ID-JAG)를 사용합니다. 클라이언트는 싱글 사인온 (SSO) 과정에서 IDP (Identity Provider, ID 제공자)로부터 JWT를 획득한 다음, 이를 MCP 서버의 권한 부여 서버 (Authorization Server)로부터 액세스 토큰 (Access Token)으로 교환합니다. 서버별 동의 화면이 필요 없습니다. 리다이렉트 (Redirect)도 없습니다. 최종 사용자가 수행해야 할 설정도 필요하지 않습니다.

이로부터 세 가지 특성이 도출됩니다:

한 번의 승인으로 어디서나 상속: 관리자가 조직을 위해 서버를 활성화하면, 사용자는 기존의 그룹 및 역할 (Role) 범위 내에서 자동으로 이를 사용할 수 있습니다.
중앙 집중식 정책 및 감사 (Audit): 액세스 결정은 IDP 관리 콘솔에서 이루어지며, 연결된 모든 서버에 대해 단일한 감사 추적 (Audit Trail)을 제공합니다.
깔끔한 계정 분리: 대화형 계정 선택 단계를 제거함으로써 개인 자격 증명 (Credentials)이 기업 워크플로로 유출되는 것을 훨씬 어렵게 만듭니다.

Okta는 Cross App Access (XAA)를 메커니즘으로 사용하는 첫 번째 지원 IDP입니다. Anthropic은 Claude, Claude Code, Cowork 전반에 걸쳐 EMA를 구현했습니다. VS Code는 IDE에 직접 지원 기능을 추가했습니다.

콘텐츠 팀에 미치는 의미

AI 에이전트를 콘텐츠 인프라에 연결하기 위해 MCP 서버를 사용하고 있다면, EMA는 대부분의 팀이 임시방편 (Workaround)으로 가려왔던 격차를 해소해 줍니다.

EMA 도입 전, 전형적인 기업 환경은 다음과 같았습니다. 수명이 긴 API 토큰을 가진 공유 서비스 계정을 사용하고, 이를 .env 파일에 담아 전달하며, 감사 추적도 없고 역할별로 액세스 범위를 제한할 방법도 없었습니다. 이는 누군가 퇴사하거나, 토큰이 유출되거나, 보안 팀에서 운영 콘텐츠에 쓰기 권한을 가진 사람이 몇 명인지 묻기 전까지는 문제없이 작동합니다.

EMA를 사용하면, MCP가 연결된 콘텐츠 서버에 대한 액세스를 다른 모든 것에 적용되는 것과 동일한 IDP 정책으로 제어할 수 있습니다. 즉, 그룹 멤버십, 역할, 조건부 액세스 규칙 (Conditional Access Rules), 그리고 퇴사 시 자동 계정 회수 (Deprovisioning) 등이 적용됩니다.

Cosmic의 MCP 서버 및 범위 지정된 액세스 (Scoped Access)

Cosmic은 콘텐츠 읽기, 쓰기, 미디어 관리 및 객체 유형 작업을 수행하는 18개의 도구를 포함한 프로덕션 준비 완료(production-ready) MCP 서버를 제공합니다. 이 서버는 Claude, Cursor, Windsurf, VS Code 및 모든 MCP 호환 클라이언트에 직접 연결됩니다.

Cosmic의 액세스 모델은 EMA(Entity Management Authorization)를 깔끔하게 보완합니다:

버킷 수준 격리 (Bucket-level isolation): 각 Cosmic 버킷은 고유한 읽기 및 쓰기 키를 가집니다. 에이전트(Agent)는 전역 관리자 권한이 아닌 범위가 지정된 자격 증명(scoped credentials)을 부여받습니다.
읽기 vs 쓰기 분리 (Read vs write separation): 읽기 키는 콘텐츠 가져오기만 허용하며, 모든 변경(mutation)에는 쓰기 키가 필요합니다. 에이전트에게 프로덕션(production) 환경에 대한 읽기 권한과 스테이징(staging) 버킷에 대한 쓰기 권한만 부여할 수 있습니다.
환경별 키 (Per-environment keys): 스테이징(staging), 프리뷰(preview), 프로덕션(production) 버킷은 각각 별도의 자격 증명을 가집니다. 설정이 잘못된 에이전트가 실수로 프로덕션에 데이터를 쓰는 일을 방지할 수 있습니다.
인간 검토 게이트 (Human review gates): Cosmic의 대시보드는 초안(draft) 또는 게시(published) 상태인 모든 객체를 보여줍니다. 에이전트는 초안을 작성하고, 인간이 게시합니다. 이러한 검토 계층은 인증(auth) 계층과 독립적으로 작동합니다.

MCP 클라이언트와 서버 전반에서 EMA 채택이 증가함에 따라, Cosmic의 버킷 범위 지정 키 모델은 해당 신뢰 계층(trust hierarchy)에 직접적으로 통합됩니다. 즉, 귀하의 IdP(Identity Provider)는 어떤 사용자가 MCP 서버에 도달할 수 있는지를 제어하고, Cosmic의 범위 지정 키는 사용자가 서버에 접속한 후 무엇을 할 수 있는지를 제어합니다.

Cosmic의 MCP 서버 연결하기

단일 설정 블록을 사용하여 호환 가능한 모든 클라이언트에 Cosmic의 MCP 서버를 추가할 수 있습니다:

import { createBucketClient } from '@cosmicjs/sdk'

// 환경별로 읽기/쓰기 키의 범위를 지정합니다
...

Claude Desktop 또는 Cursor의 경우, MCP 설정에 Cosmic을 추가하세요:

{
  "mcpServers": {
    "cosmic": {
...

이 설정을 통해 연결된 에이전트는 해당 버킷으로 범위가 지정된 18개의 모든 Cosmic 도구에 접근할 수 있습니다. 이를 클라이언트 수준의 EMA와 결합하면 완전한 엔터프라이즈 인증 체인을 구축할 수 있습니다: IdP는 누가 연결할 수 있는지를 제어하고, Cosmic 키는 그들이 무엇을 할 수 있는지를 제어합니다.

실무 체크리스트

현재 팀 환경에서 MCP 서버를 운영하고 있다면, 다음 사항에 집중하십시오:

현재 자격 증명 감사 (Audit your current credentials): 특정 환경이나 역할에 범위가 제한되지 않은 공유 서비스 계정 토큰 또는 장기 유지 키 (long-lived keys)가 있는지 식별하십시오.
환경별로 Cosmic 키 범위 지정 (Scope your Cosmic keys by environment): 운영 환경 읽기 전용 키 (production read key), 운영 환경 쓰기 전용 키 (production write key, 에이전트 전용), 스테이징 환경 쓰기 전용 키 (staging write key, 더 넓은 액세스 권한)로 구분하십시오. 여러 환경에서 동일한 키를 절대 사용하지 마십시오.
IdP의 EMA 지원 여부 확인: Okta는 현재 지원 중이며, 다른 제공업체들도 지원을 추가하고 있습니다. 조직에서 Okta를 사용하는 경우, Cross App Access를 통해 오늘 바로 EMA를 사용할 수 있습니다.
MCP 클라이언트 확인: Anthropic (Claude, Claude Code, Cowork) 및 VS Code는 이미 EMA를 지원합니다. 다른 클라이언트들도 현재 지원을 추가하고 있습니다.
EMA 사양 검토: Enterprise-Managed Authorization extension 문서와 ext-auth 리포지토리에 구현 평가에 필요한 모든 정보가 있습니다.

다음 단계

EMA는 초안이 아닌 안정적인 확장 기능입니다. 이를 뒷받침하는 모멘텀은 실재합니다. 초기 도입자 목록(Okta, Anthropic, Microsoft, Figma, Asana, Atlassian, Linear, Supabase, Slack은 진행 중)은 개발자들이 이미 매일 사용하는 대부분의 도구를 포함하고 있습니다. 향후 몇 분기 내에 EMA 지원이 엔터프라이즈 MCP 배포의 기본 기대 사항이 될 것으로 예상됩니다.

콘텐츠 팀에게 지금은 인증 기반을 올바르게 구축해야 할 시점입니다. 어떤 IdP를 사용하든, 팀이 어떤 MCP 클라이언트를 채택하든 관계없이 범위가 지정된 키 (Scoped keys), 환경 격리 (environment isolation), 그리고 인간의 검토 단계 (human review gates)가 올바른 빌딩 블록입니다.

Cosmic의 MCP 서버는 지금 바로 사용할 수 있습니다. 무료 계정을 생성하고 5분 이내에 에이전트 스택에 연결하십시오. Cosmic 블로그에서 전체 게시물을 읽어보십시오.