MCP 기업 권한 안정화, 에이전트 도구 연결을 SSO로

AI 요약

• 무슨 일: MCP의 Enterprise-Managed Authorization 확장이 2026년 6월 18일 안정화됐습니다.
  • 관리자가 IdP에서 MCP 서버 접근을 승인하면 사용자는 Claude, Claude Code, Cowork, VS Code에서 첫 로그인 때 승인된 서버를 자동으로 받습니다.
• 채택 신호: 공식 발표는 Anthropic, Microsoft, Okta와 Asana, Atlassian, Canva, Figma, Linear, Supabase를 초기 축으로 적었습니다.
• 보안 배경: arXiv 연구는 원격 MCP 서버 7,973개 중 40.55%가 인증 없이 도구를 노출했다고 보고했습니다.
• 주의점: SSO가 연결 피로를 줄여도 세밀한 권한 범위, 감사 로그, 개인·업무 계정 분리는 각 조직의 설계 문제로 남습니다.

Model Context Protocol(MCP)이 기업용 권한 확장인 Enterprise-Managed Authorization을 안정화했습니다. 공식 블로그의 날짜는 2026년 6월 18일입니다. 발표의 직접 메시지는 단순합니다. 기업 관리자가 Okta 같은 신원 제공자(IdP)에서 MCP 서버 접근을 한 번 승인하면, 사용자는 Claude나 Visual Studio Code 같은 클라이언트에 로그인할 때 승인된 서버를 자동으로 받습니다. 서버마다 OAuth 동의 화면을 반복해서 누르는 흐름을 기업 SSO와 중앙 정책으로 바꾸는 발표입니다.

이 뉴스는 새 모델 출시나 코딩 벤치마크와 다릅니다. 에이전트가 업무 도구를 실제로 쓰기 시작하면 가장 먼저 부딪히는 문제는 모델 능력보다 "어떤 서버에, 누구 권한으로, 언제까지 연결할 수 있는가"입니다. MCP는 에이전트와 외부 도구를 잇는 표준 인터페이스로 빠르게 퍼졌지만, 원격 서버가 늘수록 인증과 회수 경로가 병목이 됐습니다. 이번 EMA 안정화는 에이전트 도구 연결을 개인 동의 모음에서 기업 접근 정책으로 끌어올리는 시도입니다.

기존 MCP 권한 모델은 사용자별 서버 연결에 가깝습니다. 직원이 Claude에서 Asana, Figma, Linear, Supabase 같은 MCP 서버를 쓰려면 각 서버의 OAuth 흐름을 따로 거칩니다. 개인용 서비스에서는 이 방식이 자연스럽습니다. 사용자가 자기 데이터에 접근할 애플리케이션을 직접 고르는 구조이기 때문입니다. 그러나 기업 환경에서는 직원 수와 서버 수가 곱해지면서 온보딩이 느려지고, 보안팀은 어떤 사용자가 어떤 개인 계정으로 어떤 서버를 연결했는지 강제하거나 감사하기 어렵습니다.

MCP 공식 글은 이 문제를 세 가지로 정리했습니다. 직원마다 서버를 하나씩 승인해야 하고, 보안팀이 일관된 정책과 감사 경로를 강제하기 어렵고, 업무 계정과 개인 계정이 섞일 수 있다는 점입니다. 이 세 항목은 모두 에이전트 도입의 운영 비용입니다. 코딩 에이전트 한 명이 저장소, 이슈 트래커, 디자인 파일, 문서, 데이터베이스를 오가려면 서버 연결이 여러 개 필요합니다. 연결마다 사람이 계정을 고르고 동의하면 "에이전트가 알아서 일한다"는 제품 경험은 시작 전에 멈춥니다.

EMA는 접근 판단의 위치를 바꿉니다. MCP 블로그는 조직의 IdP가 MCP 서버 접근의 권위 있는 의사결정 지점이 된다고 설명합니다. 관리자는 그룹, 역할, 조건부 접근 규칙에 따라 서버 접근을 승인합니다. 사용자는 MCP 호스트에 기존 기업 신원으로 로그인합니다. 내부적으로는 클라이언트가 SSO 과정에서 Identity Assertion JWT Authorization Grant(ID-JAG)를 받고, MCP 서버의 인가 서버에서 접근 토큰으로 교환합니다. 사용자는 서버별 동의 화면을 거치지 않습니다.

이 구조의 의미는 "클릭 수 감소"보다 큽니다. 첫째, 서버 허용 여부가 개인 선택이 아니라 조직 정책으로 남습니다. 둘째, 접근 로그와 회수 경로가 IdP 관리 콘솔로 모입니다. 셋째, 사용자가 업무 도구에 개인 계정을 연결하는 실수를 줄일 수 있습니다. 에이전트가 많은 도구를 호출할수록 권한은 UI 편의 기능이 아니라 감사 가능한 운영 데이터가 됩니다. EMA는 그 데이터를 MCP 클라이언트 밖의 중앙 신원 계층으로 올려놓습니다.

초기 채택자 목록은 이 발표의 무게를 키웁니다. MCP 공식 글은 Okta를 첫 지원 신원 제공자로 적었고, 클라이언트 쪽에서는 Anthropic의 Claude 공유 MCP 계층과 Visual Studio Code를 언급했습니다. Anthropic 구현은 Claude, Claude Code, Cowork에 걸쳐 관리자가 사용자에게 MCP 서버를 승인할 수 있게 합니다. 서버 쪽에서는 Asana, Atlassian, Canva, Figma, Granola, Linear, Supabase가 EMA를 지원하고, Slack도 추가 중이라고 발표했습니다. 단일 공급사의 통합 기능이 아니라 MCP 생태계 확장으로 발표된 이유입니다.

Okta의 2026년 6월 18일 보도자료는 Claude Enterprise 베타 프로그램의 형태를 더 구체적으로 설명합니다. Okta는 Ramp, Webflow, HubSpot 등 공동 고객이 Claude와 참여 MCP 제공자의 애플리케이션 접근을 관리할 수 있다고 밝혔습니다. 또한 관리자가 조직용 MCP 커넥터를 한 번 승인하고, Okta 그룹이나 역할로 범위를 정하며, 사용자가 비활성화되거나 에이전트 역할이 바뀔 때 표준 회수 경로로 접근을 끊는다고 설명했습니다.

여기서 중요한 단어는 Cross App Access(XAA)입니다. Okta는 XAA를 AI 에이전트와 애플리케이션 사이의 접근을 OAuth 위에서 다루는 개방형 프로토콜로 설명합니다. MCP 공식 발표에서는 이 흐름이 Enterprise-Managed Authorization이라는 MCP 권한 확장 이름으로 들어왔습니다. 즉, Okta의 신원 제품과 Anthropic의 Claude Enterprise 기능만의 발표가 아니라, MCP 서버와 클라이언트가 같은 권한 계약을 구현할 수 있도록 표준화된 연결점입니다.

보안 배경을 보면 이 발표는 더 시급해집니다. arXiv에 2026년 5월 21일 제출된 원격 MCP 서버 인증 보안 측정 연구는 7,973개 라이브 원격 MCP 서버를 식별했고, 그중 40.55%가 인증 없이 도구를 노출한다고 보고했습니다. 인증을 쓰는 서버 중에서도 OAuth가 주요 방식이었고, 연구진은 테스트 가능한 OAuth 기반 서버 119개에서 총 325개 결함을 찾았습니다. 동적 클라이언트 등록 결함은 테스트 대상의 96.6%에 영향을 줬다고 논문 초록이 적었습니다.

이 논문 수치는 EMA가 모든 문제를 해결한다는 증거가 아닙니다. 오히려 반대입니다. MCP 서버가 업무 앱, 생산성 도구, 금융 서비스, 소셜 서비스와 연결될수록 인증 경계는 더 공격받는 표면이 됩니다. 인증 없이 도구를 여는 서버, 잘못 구성된 OAuth, 동적 클라이언트 등록 오류가 동시에 존재하는 생태계에서는 "사용자가 동의했으니 안전하다"는 말이 약합니다. EMA는 그런 환경에서 기업이 승인한 클라이언트와 서버 조합을 중앙에서 좁히려는 대응입니다.

개발팀에는 두 가지 작업이 생깁니다. MCP 서버를 만드는 팀은 EMA 사양을 읽고 서버의 인가 서버가 ID-JAG 교환을 어떻게 처리할지 결정해야 합니다. 클라이언트나 에이전트 제품을 만드는 팀은 "사용자가 URL을 붙여 넣으면 아무 MCP 서버나 연결"하는 흐름과 "조직 관리자가 허용한 서버만 자동으로 연결"하는 흐름을 분리해야 합니다. 개인 개발자 도구와 기업 배포판의 권한 모델이 달라지는 지점입니다.

커뮤니티 반응도 이 긴장을 반영합니다. Hacker News 토론에서 일부 사용자는 기업 IdP가 허용한 에이전트와 MCP 서버만 사용할 수 있게 되면 채택 문턱이 높아질 수 있다고 봤습니다. 반대로 대기업에서 여러 서비스 재인증을 반복하는 경험을 겪은 사용자는 중앙 회수와 정책 집행을 긍정적으로 평가했습니다. 토론에는 세밀한 서비스 권한, 사용자 책임, compromised user 대응, Okta 같은 IdP의 역할을 둘러싼 의견이 섞였습니다.

이 논쟁은 제품 UX의 질문으로 이어집니다. 기업 관리형 권한이 강해질수록 사용자는 더 적은 동의 화면을 보지만, 자신이 어떤 서버에 어떤 권한을 가진 에이전트를 붙였는지 덜 의식할 수 있습니다. 보안팀은 중앙 정책을 얻지만, 업무별 세부 권한 모델을 설계해야 합니다. "모든 Linear 접근"과 "특정 프로젝트의 이슈 읽기"는 다릅니다. EMA는 중앙 승인 경로를 제공하지만, 각 서버가 얼마나 세밀한 범위를 표현하는지는 별도의 구현 품질입니다.

Claude Code와 Visual Studio Code 같은 개발자 도구에서는 변화가 더 직접적입니다. 코딩 에이전트가 PR을 만들려면 GitHub, Jira, Linear, Figma, 내부 문서, 배포 로그 같은 도구를 읽고 써야 합니다. 지금까지는 각 도구의 MCP 서버를 사용자가 직접 연결하거나, 팀이 API 토큰과 프록시를 별도로 준비하는 일이 많았습니다. EMA를 지원하는 조직에서는 관리자가 승인한 서버가 로그인과 함께 내려오므로 에이전트 온보딩 단계가 줄어듭니다. 대신 권한 정책이 틀리면 많은 사용자가 동시에 잘못된 접근을 받을 수 있습니다.

운영팀이 봐야 할 체크리스트는 모델 선택표보다 구체적입니다. 첫째, 어떤 MCP 서버를 조직 승인 목록에 올릴지 정해야 합니다. 둘째, 승인 기준을 사용자 그룹과 역할에 어떻게 매핑할지 정해야 합니다. 셋째, 오프보딩과 역할 변경 때 MCP 접근 토큰이 실제로 끊기는지 테스트해야 합니다. 넷째, 감사 로그가 IdP, MCP 클라이언트, MCP 서버 중 어디에 남는지 확인해야 합니다. 다섯째, 개인 계정으로 연결할 수 있는 우회 경로를 막을지 허용할지 정책으로 적어야 합니다.

이번 발표는 MCP와 Skills 같은 에이전트 확장 방식의 비교에도 영향을 줍니다. Skills는 파일과 스크립트로 지식을 점진적으로 제공하는 방식에 강점이 있고, MCP는 원격 도구와 데이터 접근에 초점을 둡니다. 기업 환경에서 MCP가 살아남으려면 원격 서버 인증, 중앙 회수, 감사 가능성이 필수입니다. EMA는 바로 그 약한 고리를 보강합니다. 그래서 이 발표는 "MCP가 또 하나의 확장을 냈다"보다 "MCP가 기업 보안팀의 구매 기준에 한 칸 가까워졌다"로 읽어야 합니다.

다만 표준 안정화와 실제 배포 안정성은 다릅니다. 공식 글은 더 많은 신원 제공자, 클라이언트, 서버가 EMA를 채택하기를 권한다고 적었습니다. 현재 초기 목록은 인상적이지만, 기업마다 쓰는 내부 도구와 SaaS 조합은 훨씬 넓습니다. 사내 MCP 서버가 많다면 표준 지원보다 마이그레이션 작업이 더 큽니다. 토큰 수명, 권한 범위, 감사 로그 형식, 장애 때 재인증 동작까지 사내 보안 기준에 맞춰 검증해야 합니다.

한국 기업 관점에서는 업무 계정과 개인 계정 분리가 특히 중요합니다. 개발자가 개인 Figma나 개인 GitHub 계정으로 MCP 서버를 붙인 뒤 Claude나 IDE 에이전트가 업무 자료와 함께 쓰면, 데이터 경계가 흐려집니다. EMA는 interactive account selection 단계를 없애 기업 신원으로 접근을 제한하기 쉽게 만든다고 공식 글은 설명했습니다. 그러나 실제로는 클라이언트 설정, 브라우저 세션, 기존 개인 연결을 정리하는 운영 절차가 필요합니다.

가격과 비용도 간접 변수입니다. 서버별 OAuth를 줄이면 온보딩 비용은 낮아질 수 있지만, 승인된 도구가 많아질수록 에이전트 호출 범위도 넓어집니다. 개발자는 에이전트가 Figma, Jira, 문서, 저장소를 한 번에 읽는 편의성을 얻지만, 보안팀은 호출 로그와 데이터 이동량을 봐야 합니다. MCP 서버가 감사 이벤트를 충분히 남기지 않으면 중앙 SSO만으로는 사고 분석이 어렵습니다. 접근 허용과 데이터 사용 관측은 같은 문제가 아닙니다.

경쟁 구도도 바뀝니다. Anthropic은 Claude와 Claude Code의 MCP 연결 경험을 기업 신원 계층과 묶으려 하고, Microsoft는 Visual Studio Code 지원으로 IDE 경로를 열었습니다. Okta는 XAA와 IdP를 에이전트 보안의 중심으로 포지셔닝합니다. OpenAI, Google, AWS, Cloudflare도 각자 에이전트 권한과 도구 연결 경계를 제품화하고 있습니다. 에이전트 플랫폼 경쟁은 모델 API 호출뿐 아니라 "기업이 어떤 권한 모델을 승인할 수 있는가"로 이동하고 있습니다.

실무적으로는 작은 실험부터 시작하는 편이 낫습니다. 예를 들어 이슈 트래커 읽기, 디자인 파일 읽기, 내부 문서 검색처럼 쓰기 권한이 낮은 서버를 먼저 EMA 목록에 올릴 수 있습니다. 이후 PR 생성, 이슈 수정, 배포 트리거처럼 쓰기 권한이 있는 서버는 별도 그룹과 승인 절차를 둡니다. 관리자가 한 번 승인하면 모든 사용자가 자동 연결되는 장점은, 잘못 승인하면 잘못된 접근도 빠르게 퍼진다는 뜻입니다. 표준이 줄여 주는 것은 연결 마찰이지 권한 설계 책임이 아닙니다.

MCP EMA의 뉴스 가치는 여기에 있습니다. 에이전트가 사람 대신 도구를 쓰는 순간, 인증은 뒷단 설정이 아니라 제품 기능이 됩니다. 서버별 OAuth 동의는 개인용 앱에서는 받아들일 수 있지만, 수백 명이 쓰는 Claude Enterprise나 IDE 에이전트에서는 운영 병목이 됩니다. 6월 18일 안정화된 EMA는 MCP가 그 병목을 인정하고 기업 신원 체계와 연결한 사건입니다.

앞으로 볼 지표는 채택 서버 수보다 운영 품질입니다. 초기 발표 목록에 있는 Asana, Atlassian, Figma, Linear, Supabase가 어떤 범위 단위를 제공하는지, Visual Studio Code와 Claude Code가 감사 정보를 어떻게 드러내는지, Okta 외 다른 IdP가 얼마나 빨리 붙는지가 중요합니다. arXiv 연구가 보여준 인증 취약성 수치는 MCP 생태계가 아직 빠르게 자라는 중임을 말합니다. EMA는 그 성장 위에 중앙 권한 레일을 놓는 첫 안정화 신호입니다.