MCP용 Zero-Touch OAuth — 기업 MCP 배포의 새로운 기준

2026년 6월 현재 MCP(Model Context Protocol) 생태계의 가장 큰 기업 배포 마찰이 마침내 풀렸습니다. Enterprise-Managed Authorization(EMA) 확장이 stable 상태로 전환되면서, 직원은 더 이상 MCP 서버마다 OAuth 동의 버튼을 누르지 않아도 되고, 보안팀은 IdP 한 곳에서 권한 정책을 통제할 수 있게 됐습니다. Anthropic, Okta, Visual Studio Code, 그리고 Asana·Atlassian·Canva·Figma·Linear·Supabase·Granola가 초기 라인업에 합류했고 Slack도 지원 추가 중입니다.

이 글은 EMA 확장이 왜 등장했는지, 어떤 흐름으로 토큰을 교환하는지, 그리고 어떤 기업 시나리오에서 즉시 효과가 나는지 정리합니다. MCP를 회사 도구로 도입하려다 포기한 경험이 있다면, 이번 stable 전환이 그 결정의 분기점이 될 가능성이 높습니다.

• --

기업 MCP 배포를 막던 세 가지 마찰

표준 MCP 권한 모델은 사용자 범위(user-scoped) + 전통적인 대화형 인증 관례 위에 설계됐습니다. 개인이 본인의 데이터 접근 대상을 직접 결정하는 소비자 시나리오에는 자연스럽지만, 조직 단위 도입에서는 다음 세 가지가 바로 부딪힙니다.

• 온보딩 폭증: 새 직원이 합류할 때마다 서버를 하나씩 승인해야 해서, 입사 첫 주에 발생하는 수동 연결이 부담이 됩니다.
• 중앙 제어 부재: 보안팀은 사용자가 어떤 MCP 서버에 OAuth를 줬는지 일괄 감사할 수단이 없습니다. IdP 로그만으로는 부족합니다.
• 계정 혼선: 회사 계정과 개인 계정의 경계가 흐려져, 직원이 개인 Gmail로 업무 도구 Figma에 연결해 두는 일이 흔해집니다.

이런 마찰이 누적되면 결국 MCP는 "기술은 가능하지만 회사 정책상 막아야 하는 것"으로 분류됩니다. 그 자리를 우회 구현이 메우는 게 역사적으로 항상 반복됐고, EMA 확장은 이 패턴을 표준 차원에서 끊는 시도입니다.

• --

EMA 확장의 작동 원리 — SSO 토큰을 MCP 액세스 토큰으로 교환

EMA는 조직의 IdP(Identity Provider)를 권한 결정의 단일 진실 공급원으로 만듭니다. 관리자가 한 번 정책을 정의하면, 사용자는 기존 조직 계정으로 로그인만 하면 되고, 이후 모든 MCP 호스트는 IdP가 내려준 자격을 그대로 상속받습니다.

내부 흐름은 다음 순서로 요약됩니다.

1. 클라이언트(예: Claude, VS Code)가 SSO 흐름 안에서 IdP로부터 Identity Assertion JWT Authorization Grant(ID-JAG) 를 발급받습니다.
2. 클라이언트는 이 ID-JAG를 MCP 서버의 인가 서버(authorization server) 에 제출해 액세스 토큰으로 교환합니다.
3. 사용자는 서버별 동의 화면으로 리다이렉트되지 않습니다. IdP가 그룹 멤버십, 역할, 조건부 접근 규칙을 이미 평가했기 때문입니다.

이 구조에서 IdP 관리자 콘솔은 모든 MCP 커넥터에 대한 하나의 감사 가능한 기록을 남기게 됩니다. 동시에 대화형 계정 선택 단계가 사라지므로, 회사 계정과 개인 계정 사이의 데이터 흐름이 한층 명확해집니다.

ID-JAG가 기존 OAuth grant와 다른 점

| 항목 | 표준 OAuth Authorization Code | EMA (ID-JAG 기반) |

|------|-------------------------------|-------------------|

| 토큰 발급 주체 | 사용자/Resource Owner | 조직 IdP |

| 동의 단계 | 서버별 사용자 동의 화면 | IdP 콘솔의 정책으로 대체 |

| 감사 추적 단위 | 서버별 사용자별 IdP 로그 | IdP 단일 거버넌스 평면 |

| 개인 계정 혼선 가능성 | 높음 | 낮음 (계정 선택 단계 제거) |

| 기업 온보딩 비용 | 사용자당 N회 동의 | 0회 (정책 상속) |

• --

초기 지원 라인업 — IdP, 클라이언트, 서버 3개 레이어

이번 stable 전환에는 세 레이어 모두 동시 합류했습니다. 어느 한쪽만 지원돼도 도입이 막히기 때문에, 동시 출발이 결정적입니다.

• ID 공급자: Okta가 첫 번째 지원 IdP. Okta의 Cross-App Access(XAA) 프로토콜을 통해 클라이언트와 서버 양쪽에 MCP 접근을 프로비저닝할 수 있습니다.
• 클라이언트: Anthropic이 Claude의 공유 MCP 계층에 EMA를 구현. 관리자는 Claude, Claude Code, Cowork 전반에서 사용자용 MCP 서버를 승인할 수 있습니다. Visual Studio Code도 IDE 내부에 EMA 지원을 추가했습니다.
• 서버: Asana, Atlassian, Canva, Figma, Granola, Linear, Supabase가 EMA를 지원. Slack도 지원을 추가 중입니다.

수치는 긱뉴스 본문 기준으로 8개사 서버 + 2개 주요 클라이언트 + 1개 IdP(Okta) 가 첫 stable 라인업입니다. Okta 외 IdP(예: Microsoft Entra ID, Google Cloud Identity)가 곧 합류할 가능성이 높고, MCP 공식 문서는 extensions/auth/enterprise-managed-authorization 페이지에서 호환성 보고를 받고 있습니다.

도입 시나리오별 효과

| 시나리오 | 기존 MCP 흐름 | EMA 적용 후 | 감소/개선 효과 |

|----------|---------------|-------------|----------------|

| 신규 직원 50명 온보딩 | 서버 5~10개 × 50명 = 250~500회 수동 승인 | IdP 그룹 멤버십 한 번 설정 | 수동 승인 0회 |

| 보안 감사 (분기 1회) | 사용자별 OAuth 로그 수집·정규화 | IdP 콘솔 단일 조회 | 감사 시간 ~90%↓ |

| 개인 계정 ↔ 회사 계정 분리 | 사용자 본인이 구분 | IdP가 회사 계정만 발급 | 데이터 혼선 위험 제거 |

| 퇴사자 권한 회수 | 각 서버에서 OAuth 해제 추적 | IdP 그룹 제거 한 번 | 즉시 무효화 |

• --

도입 시 알아둘 흐름 요구사항

EMA 확장은 optional + additive + composable + independently versioned 네 가지 원칙을 따릅니다. 이 원칙들은 ext-auth repository 의 README에 명시되어 있습니다.

• Optional: 구현체가 채택 여부를 자율 결정. 코어 프로토콜을 강제하지 않습니다.
• Additive: 기존 core 동작을 깨지 않고 위에 얹는 방식. 이미 classic OAuth를 쓰던 클라이언트/서버도 그대로 호환됩니다.
• Composable: 다른 authorization 확장과 충돌 없이 조합 가능. 예컨대 EMA와 Client Credentials draft를 동시에 활성화할 수 있습니다.
• Versioned independently: 코어 MCP와 분리된 버전 사이클.

EMA 페이지는 클라이언트/서버/인가 서버 각각에 대해 흐름 요구사항을 문서화하고 있고, draft specification은 SEP-990 작성자와 ext-auth 저장소 유지관리자가 주도합니다. 반복 개선은 EMA Interest Group 채널에서 이뤄지므로, 제품 팀은 그곳에 합류해 호환성 보고를 남기는 것이 안전합니다.

C# SDK와 Visual Studio Code 사례

Microsoft 진영의 C# SDK 문서 도 EMA를 identity 개념 차원에서 정리하고 있어, .NET 환경에서 MCP 서버를 노출하는 팀은 이 문서를 첫 진입점으로 삼으면 됩니다. Visual Studio Code 측은 IDE 단에서 EMA를 활성화하는 옵션을 제공해, 개발자가 별도 확장을 설치하지 않아도 IdP 정책이 자동 적용됩니다.

• --

다른 확장과 어떻게 다른가 — Client Credentials draft와의 관계

ext-auth 저장소에는 현재 두 개의 확�이 있습니다.

• Stable: Enterprise-Managed Authorization (이번 글의 EMA)
• Draft: OAuth Client Credentials

Client Credentials는 머신-투-머신(M2M) 케이스를 다룹니다. 즉, 사용자가 로그인하지 않고 서비스 계정으로 MCP 서버에 접근하는 시나리오입니다. EMA는 사람 사용자 + IdP 정책 케이스를 다루므로, 둘은 대체 관계가 아니라 보완 관계입니다. 사내 자동화 에이전트가 사용자 대신 MCP를 두드리는 워크플로가 있다면, EMA로 사용자 흐름을 정리한 다음 Client Credentials를 켜는 순서가 자연스럽습니다.

이 분리는 SEP-990 작성자들이 처음부터 의도한 설계입니다. 단일 확장으로 모든 권한 케이스를 처리하려고 하면 옵션이 폭발하고, 결국 둘 다 채택하지 않는 방향으로 흐르기 쉽습니다. EMA와 Client Credentials를 별도 드래프트로 유지한 결정이, 오히려 빠른 stable 전환을 가능하게 했습니다.

• --

결론 — 2026년 6월을 기점으로 MCP 도입의 기준이 바뀐다

2026년 6월을 기준으로 MCP의 기업 배포 비용 곡선이 한 번 꺾였습니다. EMA 확장이 stable로 전환됨으로써, IdP에 정책 한 줄 추가하는 것만으로 수백 명 규모의 MCP 커넥터 접근을 통제할 수 있게 됐습니다. Anthropic·Okta·VS Code·8개 서버사로 시작된 첫 라인이 안정 궤도에 진입했고, Microsoft Entra ID·Google Cloud Identity 등 후속 IdP가 합류하면 도입 장벽은 더 빠르게 낮아질 전망입니다.

MCP 도입을 망설이고 있었다면, 2026년 6월 현재는 그만 시작해도 되는 시점입니다. 도입 순서는 1) IdP 그룹/역할 정의 → 2) Okta XAA 활성화 → 3) 서버(예: Linear, Figma) 측 EMA 활성화 → 4) 클라이언트(Claude/VS Code) 정책 배포 순서로 잡으면 됩니다. EMA Interest Group에 합류해 호환성 피드백을 남기면, 본 조직의 우선순위가 표준에 반영될 가능성도 함께 열립니다.