MCP 엔터프라이즈 SSO와 감사·게이트웨이 아키텍처

기업 보안 문턱에서 막히는 MCP

Model Context Protocol(MCP)의 2026 로드맵은 프로토콜을 엔터프라이즈 환경에서 실제로 운영하기 어렵게 만드는 문제에 초점을 맞춘다. SSO 인증의 부재, 충분하지 않은 감사 추적, 불안정한 게이트웨이가 핵심 과제다. 현재는 기본 인증 없이 동작하는 MCP 서버도 많아 기업 보안 정책을 통과하기 어렵다.

MCP는 2024년 말 Anthropic이 발표한 뒤 빠르게 확산됐다. 2025년 6월에는 OAuth 2.1이 MCP 명세에 추가됐고, OpenAI·Google·Microsoft를 비롯한 주요 AI 플랫폼이 네이티브 MCP 지원을 발표했다. GitHub Copilot, Cursor, Claude Code 같은 개발 도구도 MCP 서버와 직접 통신한다.

MCP 1.0 스펙에서 인증은 선택 사항이다. 이 때문에 토큰을 요구하지 않거나 단순 API 키 하나에 의존하는 서버가 적지 않다. 내부 코드 저장소나 데이터베이스, 외부 SaaS와 연결된 서버가 이런 상태로 노출된다면 보안 감사에서 곧바로 문제가 된다.

로드맵이 제시한 인증 방향은 SSO/OIDC 통합, OAuth 2.0 위임 흐름, 서버 간 mTLS로 나뉜다.

MCP 서버는 OIDC Discovery Endpoint를 통해 기업의 IdP(Identity Provider)와 직접 연동한다. 표준 스펙에는 Okta, Azure AD, Google Workspace 등 주요 IdP와의 통합이 포함된다.

AI 에이전트가 사용자를 대신해 외부 서비스에 접근할 때는 사용자의 자격 증명을 직접 보유하지 않고 OAuth 2.0 위임 토큰을 사용하도록 한다. GitHub에 코드를 커밋하거나 Jira 티켓을 생성하는 작업도 사용자 계정에 직접 접근하는 대신 제한된 스코프의 위임 토큰으로 처리한다.

Cross-App Access는 하나의 사용자 세션과 권한 범위를 여러 애플리케이션의 MCP 호출에 안전하게 전달하는 과제다. 여기에 SAML 기반 기업 인증 환경을 OIDC 흐름과 연결하는 SAML 브리지, 사용자 없이 자동화 작업을 수행하는 서비스 계정용 OAuth 흐름도 함께 표준화 대상에 포함된다. 이를 통해 기존 기업 IdP와 신규 MCP 클라이언트·서버가 인증 체계를 다시 구축하지 않고 연동할 수 있다.

게이트웨이와 업스트림 MCP 서버 사이에는 상호 TLS를 적용한다. 양쪽이 인증서를 검증하도록 해 서버 간 신뢰를 형성하고 중간자 공격을 차단하는 방식이다. 이 구간에서는 게이트웨이-서버 간 Auth Chain을 표준화해, 사용자 신원·위임 범위·서비스 계정 주체·정책 결정 결과가 각 도구 호출까지 일관되게 전달되도록 해야 한다.

⤢✕

API 키 대신 동적 시크릿을 다루는 방식

MCP 서버를 배포하면서 API 키를 환경 변수에 하드코딩하는 실수가 흔히 발생한다. 2026 로드맵은 HashiCorp Vault, AWS Secrets Manager, Azure Key Vault 같은 시크릿 관리 시스템과 MCP 서버를 연결하는 표준 인터페이스를 정의한다.

이 구조의 중심은 동적 시크릿이다. 서버가 외부 서비스를 호출할 때 단기 유효 토큰을 발급받고, 작업을 마치면 바로 폐기한다. 토큰이 유출되더라도 피해가 퍼질 수 있는 범위를 줄일 수 있다.

# MCP 서버의 시크릿 로테이션 통합 패턴
class SecretManager:
    def __init__(self, vault_client):
        self.vault = vault_client
        self._token_cache = {}

    async def get_dynamic_token(self, service: str, scope: str) -> str:
        cache_key = f"{service}:{scope}"
        if cache_key in self._token_cache:
            token, expires_at = self._token_cache[cache_key]
            if expires_at > time.time() + 60:  # 만료 60초 전 갱신
                return token

        # Vault에서 단기 토큰 발급
        secret = await self.vault.secrets.kv.v2.read_secret(
            path=f"mcp/{service}",
            mount_point="secret"
        )
        token = secret["data"]["data"]["token"]
        ttl = secret["data"]["metadata"]["ttl"]
        self._token_cache[cache_key] = (token, time.time() + ttl)
        return token

API 기록만으로는 부족한 감사 추적

일반적인 API 감사는 "누가 무엇을 했는가"를 남기는 데 집중한다. MCP에서는 한 단계 더 들어가야 한다. AI 에이전트가 어떤 판단을 거쳐 도구를 골랐는지, 어떤 파라미터를 전달했는지까지 이어서 추적할 수 있어야 한다.

감사 로그에는 먼저 에이전트 의도(agent intent)가 담겨야 한다. 사용자의 자연어 요청과 에이전트가 결정한 도구 호출 사이의 연결 관계를 보존하는 것이다.

여러 MCP 툴을 연속으로 실행한 작업이라면 툴 호출 체인(tool call chain)도 기록해야 한다. 각 호출의 입력과 출력, 소요 시간을 하나의 흐름으로 연결해 저장하면 개별 API 로그만으로는 보이지 않던 에이전트의 실행 과정을 재구성할 수 있다.

이상 감지(anomaly detection)를 위한 기준선도 필요하다. 특정 MCP 서버의 호출량이 평소보다 10배 증가하거나 야간에 대용량 데이터 조회가 발생하면 즉시 알림을 보내도록 설계한다.

정책 집행 지점이 되는 MCP 게이트웨이

MCP 게이트웨이는 요청을 전달하는 프록시에 그치지 않는다. 여러 MCP 서버를 한곳에서 관리하면서 접근 정책을 적용하고 트래픽을 조율하는 컴포넌트다. 2026 로드맵은 벤더와 관계없이 여러 구현체가 호환될 수 있도록 게이트웨이 스펙을 표준화하는 방향을 제시한다.

라우팅에는 서버 태그를 활용할 수 있다. 각 MCP 서버에 env:production, domain:code, sensitivity:high 같은 태그를 부여하고, 요청 조건에 맞는 서버로 자동 전달한다. 개발 환경의 에이전트에는 env:development 태그가 붙은 서버만 허용하고, 별도 승인 없이 프로덕션 서버에 접근하지 못하도록 통제하는 식이다.

⤢✕

여러 MCP 서버를 거치는 세션과 데이터 경계

현재 MCP 클라이언트는 단일 서버와 맺는 세션을 기준으로 설계됐다. 기업 환경에서는 하나의 에이전트가 수십 개의 MCP 서버를 동시에 사용할 수 있으므로 세션 의미론(Session Semantics)을 게이트웨이 수준에서 통합 관리해야 한다.

게이트웨이의 권한과 가시성도 명세로 구분할 필요가 있다. 요청 내용을 검사할 수 있는지, 도구의 입력과 출력을 기록할 수 있는지, 민감한 정보가 포함된 응답을 마스킹할 수 있는지가 모두 이 경계에 해당한다. 확인된 사용자 신원과 권한 범위가 서버 호출까지 이어져야 인증 주체와 실제 도구 실행 기록을 연결할 수 있고, SIEM과 컴플라이언스 파이프라인에서도 호출 경로를 추적할 수 있다.

에이전트 폭주를 격리하는 쿼터

AI 에이전트의 API 호출 속도는 사람보다 훨씬 빠르다. 루프에 빠진 에이전트 하나가 수천 번의 MCP 툴 호출을 순식간에 실행할 수도 있다. 이를 막는 레이트 리미팅은 에이전트, 사용자, 서비스 단위로 구분한다.

에이전트 레벨에서는 개별 세션의 호출 횟수를 분당 최대 N회로 제한한다. 사용자 레벨에서는 한 계정에서 실행되는 모든 에이전트의 호출량을 합산하고, 정해진 쿼터를 넘으면 추가 요청을 차단한다. 서비스 레벨에서는 특정 MCP 서버가 받을 수 있는 전체 요청 수를 제한한다. 한 에이전트의 폭주가 다른 사용자의 요청까지 밀어내는 상황을 막기 위한 경계다.

반복 오류를 끊는 서킷 브레이커

응답하지 않거나 오류를 반복하는 MCP 서버에 에이전트가 계속 재시도하면 장애가 더 커질 수 있다. 게이트웨이에서 서킷 브레이커 패턴을 적용하면 이런 연쇄 실패를 차단할 수 있다.

Closed 상태에서는 요청을 정상적으로 통과시킨다. 오류율이 임계값인 예를 들어 50%를 넘으면 Open 상태로 전환하고 요청에 즉시 에러를 반환한다. 일정 시간이 흐른 뒤에는 Half-Open 상태에서 제한된 요청만 보내 서버 상태를 확인한다. 요청이 성공하면 다시 Closed로 돌아간다.

이때 에이전트는 게이트웨이가 반환한 503 Service Unavailable과 Retry-After 헤더를 받아 대기한 뒤 재시도한다.

서로 다른 MCP 버전을 연결하려면

스펙이 갱신된 뒤에도 기존 에이전트는 계속 동작해야 한다. 게이트웨이는 에이전트가 요청한 MCP 버전과 서버가 지원하는 버전을 비교하고 버전 협상(version negotiation)을 처리한다.

예를 들어 MCP-Version: 2025-11 헤더를 지원하는 서버만 선택해 요청을 보내거나, 하위 호환 변환 레이어를 거쳐 구버전 클라이언트와 최신 서버가 통신하도록 구성할 수 있다.

프로덕션 채택을 늦추는 운영 공백

2026년 초를 기준으로 MCP를 실제 프로덕션에 배포한 기업은 소수다. Anthropic 공식 파트너사 일부가 내부 도구 통합에 MCP를 사용하지만 대규모 엔터프라이즈 배포 사례는 드물다.

가장 먼저 부딪히는 장벽은 보안 인증이다. 기본 인증 없이 운영되는 MCP 서버가 많아 기업 보안팀이 배포를 승인하기 어렵다.

관찰 가능성(Observability)도 충분하지 않다. AI 에이전트가 특정 MCP 툴을 얼마나 호출하는지, 실패율이 어느 정도인지 측정하는 표준 메트릭이 없다. OpenTelemetry 통합이 없어 기존 APM 도구와 연결하기도 어렵다.

상태 관리 역시 구현체의 몫으로 남아 있다. MCP는 기본적으로 스테이트리스(stateless) 프로토콜이지만 멀티턴 에이전트 대화에는 상태 유지가 필요하다. 이를 처리하는 표준 패턴이 없어 구현체마다 서로 다른 방식을 사용한다.

A2A·함수 호출과 비교한 MCP의 위치

MCP와 함께 비교되는 프로토콜과 생태계에는 Google의 Agent-to-Agent(A2A), OpenAI의 함수 호출(Function Calling)이 있다. A2A는 멀티 에이전트 조율에 특화되어 있다. OpenAI 함수 호출은 단일 모델과 도구를 통합하는 영역에서 가장 성숙한 생태계를 보유한다.

MCP가 내세우는 차이는 벤더 중립성이다. 특정 AI 모델에 묶이지 않고 모든 LLM이 같은 도구를 표준 프로토콜로 사용할 수 있다. 주요 AI 플랫폼과 개발 도구가 MCP 지원을 발표한 맥락에서, 이 중립성은 도구와 게이트웨이 구현이 특정 공급업체에 묶이지 않고 함께 경쟁할 수 있게 하는 생태계 경쟁력으로 이어진다. 다만 이 특성이 실제 장점이 되려면 2026 로드맵에 포함된 엔터프라이즈 기능이 완성되어야 한다.

표준화의 우선순위와 도입 준비

로드맵은 SSO 통합과 감사 로그를 엔터프라이즈 도입의 전제 조건으로 둔다. 이 기반이 없으면 다른 기능이 갖춰져도 기업 환경에서 사용하기 어렵다.

엔터프라이즈 워킹 그룹을 신설해 실제 도입 기업, IdP·보안 벤더, 게이트웨이·서버 구현체의 요구를 표준화 논의에 반영하는 것도 실행 전략이다. 로드맵은 기업별 요구를 코어 스펙에 모두 넣기보다, 인증 연동·감사·게이트웨이 기능을 확장(Extension)으로 제공하는 방향을 택한다. 코어의 단순성과 기존 구현체 호환성을 유지하면서도, 필요한 조직은 검증된 확장을 선택해 도입할 수 있게 하려는 접근이다.

게이트웨이 표준화는 MCP 생태계를 넓히는 인프라 레이어에 해당한다. 단일 구현에 종속되지 않고 여러 벤더가 서로 호환되는 게이트웨이를 만들 수 있어야 MCP가 실질적인 표준으로 자리 잡을 수 있다.

2026 하반기까지 SSO 인증, 감사 추적, 게이트웨이 안정성 과제가 완성되면 MCP는 실험적 단계에서 벗어나 엔터프라이즈 AI 인프라의 핵심 레이어로 자리 잡을 가능성이 높다. 도입을 검토하는 팀은 게이트웨이 아키텍처와 IdP 통합 방식을 정하고, 에이전트 의도와 툴 호출 체인을 남길 감사 로그 스키마를 준비할 필요가 있다.