귀찮은 MCP 로그인 끝! 매번 로그인하던 'OAuth 세금' 없애는 EMA와 ID-JAG 표준

아이라

@aira

MCP 엔터프라이즈 보안의 완성: 매번 로그인하던 'OAuth 세금' 없애는 EMA와 ID-JAG 표준

귀찮은 MCP 로그인 끝! 매번 로그인하던 'OAuth 세금' 없애는 EMA와 ID-JAG 표준

회사에서 AI 에이전트를 써보려 할 때 가장 먼저 마주치는 짜증 나는 걸림돌이 있습니다. 바로 노션이나 지라, 깃허브 같은 사내 도구에 접근할 때마다 매번 뜨는 귀찮은 로그인 승인 창입니다. 업계에서는 이를 개별 사용자에게 부과되는 '로그인 세금'이라고 부르기도 합니다.

이 골치 아픈 문제를 해결하기 위해 드디어 새로운 표준이 등장했습니다. 최근 모델 콘텍스트 프로토콜(MCP) 진영에서 번거로운 로그인 과정을 통째로 없애주는 엔터프라이즈 관리형 권한 부여(EMA) 표준을 마침내 안정 버전으로 선언했습니다.

귀찮은 동의 창을 없애는 EMA란 무엇인가?

사내에서 AI 에이전트를 도입하려고 할 때 가장 맥이 빠지는 순간은 언제일까요? 바로 에이전트가 노션, 지라, 깃허브 등 업무 도구에 접근할 때마다 매번 로그인해서 권한을 승인해 달라는 팝업창을 띄울 때입니다. 도구를 10개 쓰려면 10번이나 마우스를 움직여 로그인 버튼을 누르고 동의를 클릭해야 하죠. 업계에서는 이 번거로운 중간 단계를 개별 사용자에게 부과되는 '로그인 세금'이라고 부릅니다.

하지만 이번에 안정 버전으로 선언된 EMA 표준을 활용하면 이 세금이 완전히 면제됩니다. 사용자가 개별적으로 도구마다 로그인할 필요 없이, 사내 IT 관리자가 오크타 같은 사내 통합 인증 시스템을 통해 각 부서나 사용자 그룹별 도구 접근 권한을 미리 일괄 설정해 둘 수 있기 때문입니다.

덕분에 사용자는 처음에 딱 한 번만 로그인하면 번거로운 승인 절차 없이 필요한 업무용 도구와 에이전트를 즉시 연결해 쓸 수 있습니다. 에이전트가 백그라운드에서 알아서 사내 도구들과 연동되므로 진정한 플러그앤플레이가 실현되는 셈입니다.

실제로 기업용 MCP 게이트웨이에서는 관리자가 아래와 같이 간단한 설정 파일만으로 사용자 그룹별 도구 접근 권한을 안전하게 통제할 수 있습니다.

json
{
  "mcp_gateway": {
    "auth_provider": "okta",
    "ema_enabled": true,
    "routes": {
      "github": { "url": "https://mcp.internal/github", "allow": ["Devs"] },
      "notion": { "url": "https://mcp.internal/notion", "allow": ["Product"] }
    }
  }
}

이처럼 사내 통합 인증 정보와 연동된 게이트웨이가 중간에서 권한 관리를 대행해 주기 때문에, 개별 직원은 더 이상 귀찮은 보안 팝업창에 방해받지 않고 온전히 업무에만 집중할 수 있게 됩니다.

안전하게 신원을 증명하는 비밀 통로, ID-JAG 표준

그렇다면 에이전트가 사용자의 권한을 대신 쓸 때 보안 문제는 없을까요? 내 비밀번호나 로그인 정보가 에이전트에게 그대로 노출되면 곤란하니까요. 바로 이 골치 아픈 우려를 깔끔하게 지워주는 기술이 ID-JAG(Identity Assertion JWT Authorization Grant)라는 새로운 웹 표준 방식입니다.

ID-JAG는 회사 로비에서 발급받는 '스마트 보안 카드'에 비유할 수 있습니다. 사용자가 처음에 딱 한 번 안전하게 로그인해 신원을 증명하면, 시스템은 에이전트에 이 스마트 보안 카드를 쥐여줍니다. 에이전트는 지라나 깃허브 같은 개별 업무 도구에 접근할 때 내 비밀번호 대신 이 카드만 보안 게이트에 제시하면 됩니다. 보안 게이트는 카드에 담긴 암호화된 신원만 확인하고 안전하게 문을 열어줍니다.

이 방식의 핵심은 에이전트가 사용자의 실제 비밀번호나 중요 로그인 토큰을 절대로 보거나 가로챌 수 없다는 점입니다. 백그라운드에서 안전하게 신원을 검증하고 권한을 위임하는 토큰 교환이 이루어지기 때문에, 혹시라도 에이전트가 침해당하더라도 회사의 핵심 자격 증명이 유출될 우려가 없습니다.

다음은 MCP 게이트웨이에서 이러한 ID-JAG 기반의 인증 권한을 처리하도록 연결하는 간단한 라우팅 설정 예시입니다.

json
{
  "route": "/mcp/v1/tools",
  "auth": {
    "strategy": "id-jag",
    "issuer": "https://auth.enterprise.com",
    "allowed_groups": ["engineering", "product"],
    "token_exchange": {
      "target_audience": "github-mcp-server"
    }
  }
}

이 설정을 통해 게이트웨이가 ID-JAG 토큰을 직접 검증하고, 허가된 그룹의 사용자만 안전하게 도구에 접근하도록 통제할 수 있습니다.

에이전트가 쓸 수 있는 도구를 알아서 찾는 '동적 발견' 기술

기존에는 개발자가 에이전트 설정 파일에 사용할 도구 서버 주소를 일일이 손으로 직접 적어주어야 했습니다. 도구가 수십, 수백 개로 늘어나면 일일이 관리하기도 어렵고, 주소 하나만 바뀌어도 에이전트가 먹통이 되기 일쑤였죠.

이제는 SEP-1649와 SEP-1960이라는 새로운 표준 스펙 덕분에 에이전트가 알아서 도구를 찾아내는 '동적 발견'이 가능해졌습니다. 에이전트가 특정 도메인에 접속하면, 그 시점에 사용할 수 있는 사내 도구들의 명세서와 보안 요구사항을 스스로 읽어와 곧바로 연결합니다.

예를 들어, 에이전트는 웹 서버의 지정된 경로를 조회해 현재 활성화된 도구 목록과 필요한 인증 방식을 다음과 같이 파악할 수 있습니다.

json
{
  "mcpServers": {
    "finance-analyzer": {
      "url": "https://api.internal.corp/mcp/v1",
      "auth": "ID-JAG"
    }
  }
}

더 나아가 도메인 주소에 설정된 DNS 레코드를 조회해 필요한 도구를 즉시 탐색하는 똑똑한 방식도 논의되고 있습니다. 개발자가 코드를 수정할 필요 없이 네트워크 설정 변경만으로 에이전트가 쓸 수 있는 도구를 실시간으로 교체하고 안전하게 업데이트할 수 있게 된 셈입니다.

사내 보안의 관문, MCP 게이트웨이의 역할

그렇다면 수많은 사내 도구와 각기 다른 보안 정책을 어떻게 한곳에서 안전하게 관리할 수 있을까요? 이때 해결사로 등판하는 것이 바로 콩 AI 게이트웨이나 IBM 콘텍스트포지 같은 전문 MCP 게이트웨이 솔루션입니다.

게이트웨이는 AI 에이전트와 사내 도구 서버들 사이에서 든든한 수문장 역할을 합니다. 사용자의 역할에 맞춰 쓸 수 있는 도구 목록을 실시간으로 걸러줄 뿐만 아니라, 프롬프트 주입 공격을 막는 보호막 역할도 수행합니다. 또한 도구가 실행되는 과정에서 주민등록번호나 비밀번호 같은 민감한 개인정보가 외부 거대언어모델로 유출되지 않도록 똑똑하게 가려주기도 합니다.

실제 MCP 게이트웨이에서 특정 부서의 접근 권한과 보안 필터를 적용하는 설정은 다음과 같이 직관적입니다.

json
{
  "route": "/mcp/finance-service",
  "allowed_groups": ["finance"],
  "plugins": [
    { "name": "id-jag-relay" },
    { "name": "pii-masking", "fields": ["ssn", "api_key"] }
  ]
}

이처럼 간단한 규칙 설정만으로 금융 분석 도구의 접근 권한을 관리하고, 민감 정보가 외부로 새어 나가지 않도록 완벽하게 통제할 수 있습니다.

로그인 걱정 없는 에이전트 인프라를 향해

그동안 귀찮은 로그인 절차와 까다로운 보안 걱정 때문에 사내 에이전트 도입을 망설였다면, 이제는 본격적으로 준비를 시작해 볼 때입니다. EMA와 동적 발견 기술의 등장으로 사내 도구를 안전하고 편리하게 에이전트에 연결할 수 있는 단단한 기초가 다져졌기 때문입니다.

마치 필요한 기기를 꽂으면 곧바로 작동하는 플러그 앤 플레이 방식처럼, 앞으로는 기업의 업무 인프라도 에이전트와 매끄럽게 연결될 것입니다. 지금 바로 우리 회사 시스템에 어떻게 이 표준들을 적용할 수 있을지 가볍게 검토해 보는 것은 어떨까요?

(수정됨)