AI 에이전트는 연구 데모에서 실제 엔터프라이즈 애플리케이션으로 빠르게 전환되고 있으며, 대규모 언어 모델(LLM)을 회사 데이터 및 서비스와 연결하고 있습니다. 일반적인 접근 방식은 도구나 플러그인을 사용하여 LLM이 컨텍스트를 가져오거나 작업을 수행하도록 하는 것입니다. 하지만 일부에서는 이를 단순히 \"미화된 API 호출\"이라고 폄하합니다. 실제로 AI를 비즈니스 시스템과 안전하게 통합하는 것은 훨씬 더 복잡합니다. 이것이 바로 Model Context Protocol(MCP)이 등장한 이유이며, 엔터프라이즈 규모 배포를 위해 OpenID Connect(OIDC) 신원을 갖춘 강력한 프록시 아키텍처가 중요한 이유입니다.
\n\ngraph TB\n User[사용자] --> |상호작용| AIAgent[AI 에이전트]\n AIAgent --> |MCP 요청| Proxy[API 게이트웨이/프록시]\n Proxy --> |인증| OIDC[신원 제공자/OIDC]\n Proxy --> |라우팅| Tools[MCP 도구/서버]\n Tools --> |접근| Backend[백엔드 시스템]\n \n subgraph \"보안 경계\"\n Proxy\n OIDC\n end\n \n classDef security fill:#f96,stroke:#333,stroke-width:2px;\n class Proxy,OIDC security;\n위 다이어그램은 안전한 MCP 구현의 고수준 아키텍처를 보여줍니다. 이 아키텍처의 핵심은 AI 에이전트와 MCP 도구 사이의 중앙 보안 제어 지점으로 API 게이트웨이/프록시를 배치하는 것입니다. 프록시는 OIDC를 지원하는 신원 제공자와 함께 작동하여 인증, 권한 부여 및 접근 제어를 시행하는 보안 경계를 만듭니다. 이를 통해 AI 에이전트의 모든 MCP 요청이 실제 MCP 도구에 도달하기 전에 적절하게 인증되고 권한이 부여되며, 이러한 도구는 다양한 백엔드 시스템에 접근합니다.
\n\nMCP는 AI 어시스턴트가 외부 데이터 소스 및 도구와 상호 작용할 수 있는 일관된 방법을 제공하는 개방형 표준입니다(원래 Anthropic에서 도입). 각 시스템에 대한 맞춤형 통합 대신, MCP는 범용 커넥터처럼 작동하여 AI 모델이 표준화된 JSON-RPC 인터페이스를 통해 컨텍스트를 검색하거나 작업을 실행할 수 있도록 합니다. 중요한 점은 MCP가 보안을 염두에 두고 구축되었다는 것입니다. 기본적으로 AI에 아무것도 노출되지 않으며, 명시적으로 허용한 것에만 접근할 수 있습니다. 그러나 실제로 많은 도구와 사용자에 걸쳐 이러한 \"허용 목록\" 원칙을 보장하려면 신중한 인프라가 필요합니다. 프로덕션급 API 게이트웨이(프록시)는 AI 에이전트(MCP 클라이언트)와 도구 또는 데이터 소스(MCP 서버) 사이의 게이트키퍼 역할을 하여 인증, 권한 부여 및 라우팅 규칙을 시행할 수 있습니다.
\n\n솔루션을 살펴보기 전에 Envoy에 대한 간단한 참고 사항: Envoy Proxy를 MCP 게이트웨이의 참조 구현으로 사용하자는 활발한 제안이 있습니다. Envoy의 풍부한 L7 라우팅 및 확장성은 강력한 후보이며, 곧 일급 MCP 지원을 포함할 수 있습니다. 그러나 여기서 논의하는 패턴은 프록시에 구애받지 않습니다. 유사한 기능을 제공하는 모든 최신 HTTP 리버스 프록시 또는 API 게이트웨이(Envoy, NGINX, HAProxy, Kong 등)를 사용할 수 있습니다. 목표는 Envoy 구성의 세부 사항보다는 MCP를 위한 안전한 아키텍처를 개괄하는 것입니다.
\n\n언뜻 보기에 MCP를 통해 AI 도구를 사용하는 것은 웹 API를 호출하는 것만큼 간단해 보일 수 있습니다. 기본 데모에서 LLM 에이전트는 REST 엔드포인트를 호출하고 일부 JSON을 가져올 수 있으며 그것으로 끝입니다. 그러나 실제 엔터프라이즈 시나리오에서는 배후에서 훨씬 더 많은 일이 일어나고 있습니다:
\n\ngraph LR\n subgraph \"단순 API 호출\"\n A[클라이언트] -->|요청| B[API]\n B -->|응답| A\n end\n \n subgraph \"엔터프라이즈 MCP 현실\"\n C[사용자] -->|상호작용| D[AI 에이전트]\n D -->|신원이 포함된 MCP 요청| E[API 게이트웨이]\n E -->|토큰 검증| F[신원 제공자]\n E -->|요청 라우팅| G[도구 레지스트리]\n E -->|권한 부여된 요청| H[MCP 도구]\n H -->|사용자 컨텍스트로 쿼리| I[백엔드 시스템]\n I -->|데이터| H\n H -->|응답| E\n E -->|필터링된 응답| D\n D -->|결과| C\n \n J[보안 모니터링] -..->|감사| E\n end\n \n classDef security fill:#f96,stroke:#333,stroke-width:2px;\n class E,F,G,J security;\n이 다이어그램은 단순한 API 호출과 엔터프라이즈 MCP 구현의 복잡한 현실을 대조합니다. 단순한 경우 클라이언트가 API에 직접 요청하고 응답을 받습니다. 그러나 엔터프라이즈 MCP 현실에서는 흐름이 훨씬 더 복잡합니다:
\n\n이 프로세스 전반에 걸쳐 보안 모니터링 시스템이 게이트웨이 수준에서 상호 작용을 감사합니다. 이 포괄적인 흐름은 사용자 신원, 권한 및 보안 정책이 모든 단계에서 시행되도록 보장하며, 단순한 API 호출이 수반하는 것을 훨씬 뛰어넘습니다.
\n\n요컨대, 엔터프라이즈는 AI 도구 통합을 다른 프로덕션 서비스 통합과 동일한 엄격함으로 취급해야 하며, 더 많은 엄격함이 필요할 수도 있습니다. 적절한 게이트웨이 계층은 중앙 제어 지점 역할을 하여 이러한 문제를 해결하는 데 도움이 됩니다. 각 AI 에이전트나 도구에 신뢰를 하드코딩하는 대신, 프록시는 조직 전체의 보안 정책을 부과합니다. 이 접근 방식은 \"단순히 API를 호출하는\" 사고방식을 넘어 모든 MCP 호출이 인증되고, 권한이 부여되고, 모니터링되고, 감사되는 구조화된 모델로 이동합니다.
\n\nMCP를 대규모로 배포할 때 발생하는 몇 가지 특정 보안 과제와 그것이 중요한 이유를 살펴보겠습니다:
\n\ngraph TD\n A[컨텍스트 중독] --> |완화| B[콘텐츠 필터링]\n A --> |완화| C[도구 검증]\n \n D[신원 전파] --> |해결| E[토큰 기반 인증]\n D --> |해결| F[위임 체인]\n \n G[동적 도구 프로비저닝] --> |관리| H[도구 레지스트리]\n G --> |관리| I[승인 워크플로]\n G --> |관리| J[버전 추적]\n \n K[원격 MCP 변경] --> |제어| L[프록시 거버넌스]\n \n subgraph \"프록시 보안 제어\"\n B\n C\n E\n F\n H\n I\n J\n L\n end\n \n classDef challenge fill:#f66,stroke:#333,stroke-width:2px;\n classDef solution fill:#6f6,stroke:#333,stroke-width:2px;\n \n class A,D,G,K challenge;\n class B,C,E,F,H,I,J,L solution;\n이 다이어그램은 MCP 워크플로의 주요 보안 과제(빨간색으로 표시)를 프록시 보안 제어 내에서 구현할 수 있는 해당 솔루션(녹색으로 표시)에 매핑합니다. 다이어그램은 다음을 보여줍니다:
\n\n프록시 계층 내에서 이러한 제어를 구현함으로써 조직은 각 도구나 에이전트에 대해 개별적으로 해결하려고 시도하는 대신 중앙 집중식의 일관된 방식으로 이러한 보안 과제를 해결할 수 있습니다.
\n\nsequenceDiagram\n participant User as 사용자\n participant AIAgent as AI 에이전트\n participant Proxy as API 게이트웨이\n participant IdP as 신원 제공자\n participant Tool as MCP 도구\n participant Backend as 백엔드 시스템\n \n User->>IdP: 1. 인증 (사용자명/비밀번호)\n IdP->>User: 2. OIDC 토큰 발급\n User->>AIAgent: 3. AI와 상호작용 (토큰 첨부)\n AIAgent->>Proxy: 4. 토큰이 포함된 MCP 요청\n Proxy->>IdP: 5. 토큰 검증\n IdP->>Proxy: 6. 토큰 유효, 클레임/스코프 포함\n \n alt 필요한 권한이 있는 유효한 토큰\n Proxy->>Tool: 7. 사용자 컨텍스트와 함께 요청 전달\n Tool->>Backend: 8. 위임된 인증으로 쿼리\n Backend->>Tool: 9. 데이터 반환 (사용자 권한으로 필터링)\n Tool->>Proxy: 10. 결과 반환\n Proxy->>AIAgent: 11. 권한 부여된 응답 반환\n AIAgent->>User: 12. 결과 제시\n else 토큰 무효 또는 권한 불충분\n Proxy->>AIAgent: 7. 요청 거부 (401/403)\n AIAgent->>User: 8. 접근 거부 보고\n end\n이 시퀀스 다이어그램은 OIDC를 사용하는 MCP 시스템의 인증 및 권한 부여 흐름을 보여줍니다. 프로세스는 사용자가 신원 제공자에 인증하고 OIDC 토큰을 받는 것으로 시작됩니다. 이 토큰은 AI 에이전트와의 사용자 상호 작용에 첨부됩니다. 에이전트가 MCP 요청을 할 때 이 토큰을 포함하며, API 게이트웨이는 신원 제공자와 함께 이를 검증합니다.
\n\n토큰이 유효하고 필요한 권한(클레임/스코프)을 포함하는 경우 요청은 사용자의 컨텍스트와 함께 적절한 MCP 도구로 전달됩니다. 그런 다음 도구는 위임된 인증을 사용하여 백엔드 시스템을 쿼리할 수 있으며, 반환된 데이터가 사용자의 권한에 따라 필터링되도록 보장합니다. 결과는 시스템을 통해 사용자에게 다시 흐릅니다.
\n\n토큰이 유효하지 않거나 충분한 권한이 없는 경우 요청은 게이트웨이 수준에서 적절한 오류 코드(401 Unauthorized 또는 403 Forbidden)와 함께 거부되고, AI 에이전트는 이 접근 거부를 사용자에게 보고합니다.
\n\n이 흐름은 사용자 신원과 권한이 전체 상호 작용 체인 전반에 걸쳐 일관되게 시행되도록 보장하여 민감한 데이터나 작업에 대한 무단 접근을 방지합니다.
\n\nsequenceDiagram\n participant Admin as 관리자\n participant Registry as 도구 레지스트리\n participant Proxy as API 게이트웨이\n participant Tool as 새 MCP 도구\n participant AIAgent as AI 에이전트\n \n Admin->>Tool: 1. 새 MCP 도구 개발\n Admin->>Registry: 2. 도구 등록 (메타데이터, 엔드포인트, 인증 요구사항)\n Registry->>Registry: 3. 도구 구성 검증\n Registry->>Proxy: 4. 라우팅 구성 업데이트\n \n Note over Registry,Proxy: 도구가 등록되었지만 아직 승인되지 않음\n \n Admin->>Registry: 5. 특정 사용자 그룹에 대해 도구 승인\n Registry->>Proxy: 6. 접근 정책 업데이트\n \n Note over AIAgent,Proxy: 이제 권한이 있는 사용자가 도구를 사용할 수 있음\n \n AIAgent->>Proxy: 7. 사용 가능한 도구 검색\n Proxy->>AIAgent: 8. 사용자에 대해 승인된 도구 반환\n AIAgent->>Proxy: 9. 새 도구 호출\n Proxy->>Tool: 10. 권한이 부여된 경우 요청 라우팅\n이 시퀀스 다이어그램은 안전한 MCP 환경에서 도구 등록 및 승인 워크플로를 보여줍니다. 프로세스는 관리자가 새 MCP 도구를 개발하고 메타데이터, 엔드포인트 및 인증 요구 사항을 제공하여 도구 레지스트리에 등록하는 것으로 시작됩니다. 레지스트리는 도구 구성을 검증하고 API 게이트웨이의 라우팅 구성을 업데이트합니다.
\n\n이 시점에서 도구는 등록되었지만 아직 사용 승인을 받지 않았습니다. 관리자는 특정 사용자 그룹에 대해 도구를 명시적으로 승인해야 하며, 이는 API 게이트웨이의 접근 정책 업데이트를 트리거합니다. 그래야만 권한이 있는 사용자가 도구를 사용할 수 있습니다.
\n\nAI 에이전트가 프록시를 통해 사용 가능한 도구를 검색하면 현재 사용자에 대해 승인된 도구에 대한 정보만 받습니다. 에이전트가 새 도구를 호출하면 프록시는 사용자가 접근 권한이 있는 경우에만 도구로 요청을 라우팅합니다.
\n\n이 워크플로는 새 도구가 사용되기 전에 적절한 검증 및 승인을 거치도록 보장하고, 접근이 권한이 있는 사용자로만 제한되도록 합니다. 또한 도구 거버넌스 프로세스를 중앙 집중화하여 안전한 방식으로 MCP 도구의 수명 주기를 관리하기 쉽게 만듭니다.
\n\n이러한 과제를 인식함으로써 보안 엔지니어와 아키텍트는 문제가 발생하기 전에 방어를 설계할 수 있습니다. 다음으로 신원 인식 프록시가 깔끔하고 중앙 집중식 방식으로 이러한 방어를 제공하는 방법을 살펴봅니다.
\n\n클라우드 아키텍처에서 입증된 설계는 서비스 앞에 리버스 프록시(종종 API 게이트웨이라고 함)를 배치하는 것입니다. MCP 기반 AI 시스템도 예외가 아닙니다. AI 에이전트(클라이언트)와 MCP 서버(도구/백엔드) 사이에 지능형 프록시를 도입함으로써 모든 AI 도구 트래픽이 통과하는 제어된 깔때기를 만듭니다. 이 프록시는 레이어 7(애플리케이션 계층)에서 작동할 수 있으며, 이는 HTTP와 JSON 페이로드까지 이해한다는 것을 의미하여 세밀한 제어가 가능합니다. 아래에서는 이러한 프록시가 MCP 보안에서 수행하는 주요 역할을 개괄합니다:
\n\ngraph TB\n subgraph \"클라이언트 측\"\n User[사용자]\n AIAgent[AI 에이전트]\n User -->|상호작용| AIAgent\n end\n \n subgraph \"보안 계층\"\n Proxy[API 게이트웨이/프록시]\n Auth[인증]\n RBAC[권한 부여/RBAC]\n Registry[도구 레지스트리]\n Audit[감사 로깅]\n \n Proxy -->|사용| Auth\n Proxy -->|시행| RBAC\n Proxy -->|참조| Registry\n Proxy -->|생성| Audit\n end\n \n subgraph \"MCP 도구\"\n Tool1[문서 검색]\n Tool2[데이터베이스 쿼리]\n Tool3[파일 작업]\n Tool4[외부 API]\n end\n \n subgraph \"백엔드 시스템\"\n DB[(데이터베이스)]\n Storage[파일 스토리지]\n APIs[내부 API]\n External[외부 서비스]\n end\n \n AIAgent -->|MCP 요청| Proxy\n Proxy -->|라우팅| Tool1\n Proxy -->|라우팅| Tool2\n Proxy -->|라우팅| Tool3\n Proxy -->|라우팅| Tool4\n \n Tool1 -->|읽기| DB\n Tool1 -->|읽기| Storage\n Tool2 -->|쿼리| DB\n Tool3 -->|관리| Storage\n Tool4 -->|호출| APIs\n Tool4 -->|호출| External\n \n classDef security fill:#f96,stroke:#333,stroke-width:2px;\n class Proxy,Auth,RBAC,Registry,Audit security;\n이 다이어그램은 MCP를 위한 신원 인식 프록시 패턴의 상세한 보기를 제공합니다. 아키텍처는 네 가지 주요 계층으로 나뉩니다:
\n\nAI 에이전트의 모든 MCP 요청은 프록시를 통과해야 하며, 프록시는 요청을 인증하고, RBAC 정책을 시행하고, 도구 레지스트리를 참조하여 라우팅을 결정하고, 감사 로그를 생성합니다. 그런 다음 프록시는 권한이 부여된 요청을 적절한 MCP 도구로 라우팅하고, 이 도구는 백엔드 시스템과 상호 작용합니다.
\n\n이 중앙 집중식 보안 아키텍처는 사용 중인 도구나 접근 중인 백엔드 시스템에 관계없이 모든 MCP 상호 작용에 걸쳐 보안 정책의 일관된 시행을 보장합니다.
\n\n단순한 상태 비저장 API 호출과 달리 MCP 세션은 오래 지속될 수 있으며 스트리밍(출력용 Server-Sent Events 등)을 포함할 수 있습니다. 프록시는 주어진 세션이나 대화에 속하는 모든 요청과 응답이 일관되게 처리되도록 보장해야 합니다. 이것은 종종 세션 어피니티를 구현하는 것을 의미합니다. MCP 서버의 여러 인스턴스가 실행 중인 경우 프록시는 주어진 세션의 트래픽을 매번 동일한 인스턴스로 라우팅합니다. 이렇게 하면 도구 A의 상태(인메모리 캐시, 컨텍스트 창 등)가 요청 2가 요청 1과 다른 인스턴스로 이동했기 때문에 손실되는 문제를 방지합니다. 최신 프록시는 HTTP 헤더나 경로를 사용하여 세션 인식 로드 밸런싱을 수행할 수 있습니다(예: URL의 세션 ID 또는 클라이언트 ID를 특정 백엔드에 매핑). 또한 프록시는 SSE 연결을 우아하게 처리할 수 있으므로 스트리밍 응답이 네트워크 중개자에 의해 실수로 끊어지지 않습니다. 세션을 재개하거나 전달해야 하는 경우 게이트웨이가 이를 조정할 수 있습니다(MCP용 향후 Envoy 기능에서 제안된 대로). 요컨대, 프록시는 MCP의 상태 저장 상호 작용에 대한 안정성과 일관성을 보장하며, 이는 사용자 경험과 올바른 컨텍스트 유지에 중요합니다.
\n\nsequenceDiagram\n participant User as 사용자\n participant AIAgent as AI 에이전트\n participant Proxy as API 게이트웨이\n participant Instance1 as 도구 인스턴스 1\n participant Instance2 as 도구 인스턴스 2\n \n User->>AIAgent: 대화 시작\n AIAgent->>Proxy: MCP 요청 1 (session=abc123)\n \n Note over Proxy: 세션 어피니티 라우팅\n \n Proxy->>Instance1: 인스턴스 1로 라우팅\n Instance1->>Proxy: 상태와 함께 응답\n Proxy->>AIAgent: 응답 반환\n \n User->>AIAgent: 대화 계속\n AIAgent->>Proxy: MCP 요청 2 (session=abc123)\n \n Note over Proxy: 동일한 세션 ID가 동일한 인스턴스로 라우팅\n \n Proxy->>Instance1: 인스턴스 1로 라우팅 (상태 보존)\n Instance1->>Proxy: 업데이트된 상태와 함께 응답\n Proxy->>AIAgent: 응답 반환\n \n Note over User,Instance2: 세션 어피니티가 없으면 요청이 인스턴스 2로 이동하여 상태 손실 가능\n이 시퀀스 다이어그램은 MCP 환경에서 세션 어피니티가 작동하는 방식을 보여줍니다. 사용자가 AI 에이전트와 대화를 시작하면 에이전트는 세션 식별자(이 경우 \"abc123\")와 함께 API 게이트웨이에 MCP 요청을 합니다. 게이트웨이는 이 세션 ID를 사용하여 요청을 특정 도구 인스턴스(인스턴스 1)로 라우팅합니다.
\n\n사용자가 대화를 계속하면 에이전트는 동일한 세션 ID로 다른 MCP 요청을 합니다. 게이트웨이가 세션 어피니티를 구현하기 때문에 이 요청을 동일한 인스턴스(인스턴스 1)로 라우팅하여 이전 상호 작용의 상태를 보존합니다. 이것은 사용자에게 일관되고 일관성 있는 경험을 보장합니다.
\n\n세션 어피니티가 없으면 두 번째 요청이 다른 인스턴스(인스턴스 2)로 라우팅될 수 있으며, 이 인스턴스에는 첫 번째 요청의 상태 정보가 없습니다. 이것은 도구가 이전 상호 작용의 컨텍스트를 갖지 못하기 때문에 끊어진 경험을 초래합니다.
\n\n세션 어피니티는 많은 AI 상호 작용이 상태 저장이고 컨텍스트 종속적이기 때문에 MCP에 특히 중요합니다. 프록시가 이 세션 일관성을 유지하는 능력은 더 간단한 API 통합 접근 방식에 비해 주요 이점입니다.
\n\nMCP 게이트웨이에 도달하는 모든 요청은 유효한 신원 토큰을 전달해야 합니다. 일반적으로 OIDC(OpenID Connect)를 통해 신원 제공자가 발급한 JSON Web Token(JWT)입니다. JWT를 요구함으로써 프록시는 도구 자체에서 인증을 오프로드하고 인증되고 권한이 부여된 호출만 통과하도록 보장합니다. 실제로 이것은 AI 에이전트(또는 에이전트와의 사용자 세션)가 OIDC 토큰(예: ID 토큰 또는 액세스 토큰)을 얻고 각 MCP 요청에 첨부해야 함을 의미합니다(종종 Authorization: Bearer <token>과 같은 HTTP 헤더에). 프록시는 이 토큰을 검증하고 서명 및 클레임(발급자, 대상, 만료 등)을 확인하고 적절하게 인증되지 않은 요청을 거부합니다. 이렇게 하면 MCP 서버는 익명 호출을 볼 수 없습니다. 게이트웨이가 신원을 검증했다고 신뢰합니다.
sequenceDiagram\n participant User as 사용자\n participant App as AI 애플리케이션\n participant IdP as 신원 제공자\n participant Proxy as API 게이트웨이\n participant Tool as MCP 도구\n \n User->>App: AI 애플리케이션 접근\n App->>IdP: 로그인으로 리디렉션\n User->>IdP: 인증\n IdP->>App: 인증 코드\n App->>IdP: 토큰으로 코드 교환\n IdP->>App: ID 토큰 + 액세스 토큰\n \n Note over App: 토큰을 안전하게 저장\n \n User->>App: AI 도구를 사용하여 요청\n App->>Proxy: 액세스 토큰이 포함된 MCP 요청\n \n Proxy->>Proxy: 토큰 검증 (서명, 만료, 대상)\n Proxy->>Proxy: 사용자 신원 및 권한 추출\n \n alt 토큰 유효\n Proxy->>Tool: 사용자 컨텍스트와 함께 요청 전달\n Tool->>Proxy: 응답\n Proxy->>App: 응답 반환\n App->>User: 결과 표시\n else 토큰 무효\n Proxy->>App: 401 Unauthorized\n App->>User: 세션 만료, 다시 로그인하세요\n end\n \n Note over App,Proxy: 토큰 갱신은 백그라운드에서 발생\n App->>IdP: 필요할 때 토큰 갱신\n IdP->>App: 새 액세스 토큰\n이 시퀀스 다이어그램은 MCP 환경에서 OIDC 인증 흐름을 보여줍니다. 프로세스는 사용자가 AI 애플리케이션에 접근할 때 시작되며, 애플리케이션은 인증을 위해 신원 제공자로 리디렉션합니다. 사용자가 인증한 후 신원 제공자는 인증 코드를 발급하고, 애플리케이션은 이를 ID 및 액세스 토큰으로 교환합니다.
\n\n애플리케이션은 이러한 토큰을 안전하게 저장하고 AI 에이전트를 통해 MCP 요청을 할 때 액세스 토큰을 사용합니다. 프록시가 요청을 받으면 서명, 만료, 대상 및 기타 클레임을 확인하여 토큰을 검증합니다. 또한 토큰에서 사용자의 신원과 권한을 추출합니다.
\n\n토큰이 유효하면 프록시는 사용자의 컨텍스트와 함께 요청을 적절한 MCP 도구로 전달합니다. 도구는 요청을 처리하고 응답을 반환하며, 이는 프록시를 통해 애플리케이션으로 다시 흐르고 궁극적으로 사용자에게 전달됩니다.
\n\n토큰이 유효하지 않은 경우(만료, 변조 등) 프록시는 401 Unauthorized 응답을 반환하고 애플리케이션은 사용자에게 다시 로그인하라는 메시지를 표시합니다.
\n\n백그라운드에서 애플리케이션은 갱신 토큰을 사용하여 필요할 때 새 액세스 토큰을 얻을 수 있으며, 사용자가 다시 인증할 필요가 없습니다. 이것은 보안을 유지하면서 원활한 사용자 경험을 보장합니다.
\n\n이 OIDC 통합은 엔터프라이즈 환경에서 널리 채택되고 기존 신원 관리 시스템과 잘 통합되는 강력한 인증 메커니즘을 제공합니다.
\n\n위의 논의는 인간 사용자 인증에 초점을 맞추고 있지만, 프로덕션급 MCP 배포는 두 가지 추가 행위자도 식별해야 합니다:
\n\n우리의 동반 게시물 \"OpenID Connect for Agents (OIDC-A) 1.0 제안\" ({{ site.baseurl }}/2025/04/28/oidc-a-proposal/)은 에이전트 신원, 증명 및 위임 체인을 위한 풍부한 클레임 세트로 OIDC Core 1.0을 확장합니다. 실제로 이것은 다음을 의미합니다:
\n\nagent_type, agent_model, agent_instance_id, delegator_sub, delegation_chain 등)을 포함하는 ID 토큰을 얻습니다. 이 토큰은 모든 MCP 요청에서 사용자의 액세스 토큰과 함께 이동합니다.agent_capabilities, agent_trust_level, agent_attestation)과 같은 메타데이터를 광고합니다.OIDC-A를 채택하면 여러 가지 이점이 있습니다:
\n\nemail:draft 기능을 광고하는 에이전트만 메일 도구를 호출하도록 허용).agent_attestation)을 통해 게이트웨이는 트래픽을 라우팅하기 전에 에이전트와 도구의 무결성과 출처를 확인할 수 있습니다.이 기사의 나머지 부분에서 게이트웨이가 검증하는 \"토큰\"을 언급할 때마다 이제 사용자의 토큰, 에이전트의 OIDC-A 토큰 및 (선택적으로) 도구/리소스 토큰을 포함한다고 가정하십시오. 모두 단일 정책 결정 단계에서 평가됩니다.
\n\n이 패턴은 이미 API 보안에서 널리 사용됩니다: \"API 게이트웨이는 애플리케이션 자체에 부담을 주지 않고 인증을 안전하고 일관되게 구현할 수 있습니다.\" 우리의 컨텍스트에서 MCP 프록시는 사용자 로그인 흐름 및 토큰 검증을 처리하기 위해 OIDC를 통해 엔터프라이즈 SSO(Azure AD, Okta 등)와 통합할 수 있습니다. 많은 게이트웨이가 OIDC를 기본적으로 지원하여 필요한 경우 사용자 로그인을 위한 리디렉션을 시작한 다음 세션 연속성을 위해 결과 토큰을 쿠키에 저장합니다. 헤드리스 에이전트 시나리오(AI가 서버 간 도구를 호출하는 경우)에서 토큰은 대역 외로 프로비저닝될 수 있습니다(예: 사용자가 AI 앱에 로그인했으므로 앱이 에이전트가 사용할 토큰을 주입). 어느 쪽이든 게이트웨이는 토큰 없음 = 접근 없음을 시행합니다. 또한 토큰 클레임을 역할이나 스코프에 매핑하여 권한 부여를 구현할 수 있습니다(예: \"HR_read\" 스코프가 있는 사용자만 \"HR 데이터베이스\" 도구를 사용할 수 있음). 이것은 MCP의 안전한 연결 설계 목표와 완벽하게 일치합니다. MCP를 OIDC 및 OIDC-A와 결합하면 도구 사용을 위한 엔드 투 엔드 인증 채널을 얻을 수 있습니다.
\n\nsequenceDiagram\n participant User as 사용자\n participant Agent as LLM 에이전트 (OIDC-A)\n participant Proxy as API 게이트웨이\n participant Tool as MCP 도구 (OIDC-A)\n participant Backend as 백엔드 시스템\n\n User->>Agent: 1. 상호작용 (채팅, 양식 등)\n Agent->>Proxy: 2. MCP 요청\\nBearer 사용자 토큰 + 에이전트 OIDC-A 토큰\n Proxy->>Proxy: 3. 사용자 토큰 (OIDC) 및 에이전트 토큰 (OIDC-A) 검증\n Proxy-->>Tool: 4. 도구에 대한 선택적 *리소스 토큰*과 함께 요청 전달\n Tool->>Backend: 5. 위임된 인증을 사용하여 쿼리/작업\n Backend-->>Tool: 6. 데이터 / 결과\n Tool-->>Proxy: 7. 응답 (증명 포함 가능)\n Proxy-->>Agent: 8. 권한 부여된 응답\n Agent-->>User: 9. 결과 제시\n프록시의 강력한 장점은 URL뿐만 아니라 요청 내의 메타데이터를 기반으로 라우팅 결정을 내릴 수 있다는 것입니다. MCP를 사용하면 요청과 응답이 JSON-RPC 형식이며, 도구 메서드 이름, 매개변수 및 도구 주석과 같은 필드가 포함됩니다. 신원 인식 프록시는 이러한 세부 정보를 검사하고 정책 규칙을 적용하도록 구성할 수 있습니다. 예를 들어 다음과 같은 규칙을 구성할 수 있습니다:
\n\ngraph TD\n subgraph \"MCP 요청\"\n Request[JSON-RPC 요청]\n Method[도구 메서드]\n Params[매개변수]\n User[사용자 신원]\n end\n \n subgraph \"정책 엔진\"\n Rules[정책 규칙]\n RBAC[역할 기반 접근]\n Audit[감사 로깅]\n Transform[응답 변환]\n end\n \n Request --> Method\n Request --> Params\n Request --> User\n \n Method --> Rules\n Params --> Rules\n User --> RBAC\n \n Rules --> Decision{허용/거부}\n RBAC --> Decision\n \n Decision -->|허용| Forward[도구로 전달]\n Decision -->|거부| Reject[요청 거부]\n \n Forward --> Audit\n Reject --> Audit\n \n Forward --> Tool[MCP 도구]\n Tool --> Response[도구 응답]\n Response --> Transform\n Transform --> Filtered[필터링된 응답]\n \n classDef request fill:#bbf,stroke:#333,stroke-width:1px;\n classDef policy fill:#fbf,stroke:#333,stroke-width:1px;\n classDef action fill:#bfb,stroke:#333,stroke-width:1px;\n \n class Request,Method,Params,User request;\n class Rules,RBAC,Audit,Transform policy;\n class Decision,Forward,Reject,Filtered action;\n이 다이어그램은 MCP 프록시에서 도구 메타데이터 필터링 및 정책 시행이 작동하는 방식을 보여줍니다. 프로세스는 도구 메서드, 매개변수 및 사용자 신원 정보를 포함하는 JSON-RPC 형식의 MCP 요청으로 시작됩니다. 이러한 구성 요소가 추출되어 정책 엔진에 공급됩니다.
\n\n정책 엔진은 정책 규칙, 역할 기반 접근 제어(RBAC), 감사 로깅 및 응답 변환 구성 요소로 구성됩니다. 도구 메서드와 매개변수는 정책 규칙에 대해 평가되고, 사용자 신원은 RBAC 권한에 대해 확인됩니다.
\n\n이러한 평가를 기반으로 정책 엔진은 허용/거부 결정을 내립니다. 요청이 허용되면 MCP 도구로 전달되고, 거부되면 거부됩니다. 어느 경우든 작업은 감사 목적으로 기록됩니다.
\n\n요청이 허용되고 도구에서 처리되면 응답은 클라이언트에 반환되기 전에 변환 단계를 거칠 수 있습니다. 이 변환은 사용자가 볼 수 없는 민감한 정보를 제거하는 것과 같이 보안 정책에 따라 응답을 필터링하거나 수정할 수 있습니다.
\n\n메타데이터 수준에서의 이러한 세밀한 정책 시행은 단순한 URL 기반 라우팅을 훨씬 뛰어넘는 정교한 보안 제어를 가능하게 합니다. 예를 들어:
\n\ndelete_file이고 사용자가 IT 관리자 그룹에 속하지 않으면 요청을 거부합니다.\"execute_sql 도구를 허용하고 모든 쿼리를 기록합니다.\"이것은 웹 애플리케이션 방화벽(WAF) 또는 API 게이트웨이가 콘텐츠 필터링을 수행하는 것과 유사하지만 AI 도구 사용에 맞게 조정되었습니다. Envoy MCP 제안에서 이것은 MCP 메시지를 구문 분석하고 RBAC 필터를 사용하는 것에 해당합니다. 프록시는 본질적으로 각 도구 호출의 의도를 이해하고 적절하게 게이트할 수 있습니다. 또한 필요한 경우 데이터를 수정하거나 변환할 수 있습니다. 예를 들어 사용자가 볼 수 없는 응답에서 특정 필드를 제거하거나 개인 식별 정보를 마스킹합니다. 게이트웨이에서 이를 중앙 집중화함으로써 각 도구 서비스에서 검사를 구현하는 것을 피할 수 있습니다(일관성이 없거나 잊혀질 수 있음). 감사는 또 다른 이점입니다. 프록시는 사용자 신원 및 매개변수와 함께 모든 도구 호출을 기록하여 모니터링을 위해 SIEM 시스템에 공급할 수 있습니다. 그렇게 하면 AI가 언젠가 해서는 안 되는 일을 하면 어떤 도구 호출이 관련되었고 누가 프롬프트했는지에 대한 명확한 추적이 있습니다. 요컨대, 메타데이터 기반 필터링은 프록시를 스마트 정책 시행 지점으로 전환하여 MCP의 기본 기능 위에 안전 계층을 추가합니다.
\n\n엔터프라이즈는 서비스를 지속적으로 발전시킵니다. 새 버전, A/B 테스트, 스테이징 대 프로덕션 배포 등. 프록시는 AI 에이전트가 이러한 변경 사항을 처리하는 방법을 크게 단순화할 수 있습니다. AI가 호출할 도구의 버전을 알 필요 없이 게이트웨이가 버전 인식 라우팅을 구현할 수 있습니다. 예를 들어 \"문서 검색\" 도구의 MCP 엔드포인트는 에이전트에 대해 동일하게 유지될 수 있지만 프록시는 요청의 90%를 서비스의 v1로 라우팅하고 10%를 새 v2로 라우팅할 수 있습니다(카나리 롤아웃의 경우). 또는 내부 사용자를 \"베타\" 인스턴스로 라우팅하고 외부 사용자는 안정 버전으로 라우팅합니다. 이것은 요청 속성을 일치시키거나 사용자 대상 및 도구 식별자를 포함하는 라우팅 규칙을 사용하여 수행됩니다.
\n\ngraph TB\n AIAgent[AI 에이전트] -->|MCP 요청| Proxy[API 게이트웨이]\n \n Proxy -->|\"90% 트래픽\"| V1[도구 v1]\n Proxy -->|\"10% 트래픽\"| V2[도구 v2 - 카나리]\n \n Proxy -->|\"내부 사용자\"| Beta[베타 버전]\n Proxy -->|\"외부 사용자\"| Stable[안정 버전]\n \n Proxy -->|\"작은 요청\"| Standard[표준 인스턴스]\n Proxy -->|\"큰 요청\"| HighMem[고메모리 인스턴스]\n \n Proxy -->|\"미국 사용자\"| US[미국 지역]\n Proxy -->|\"EU 사용자\"| EU[EU 지역]\n \n classDef proxy fill:#f96,stroke:#333,stroke-width:2px;\n classDef version fill:#bbf,stroke:#333,stroke-width:1px;\n classDef audience fill:#bfb,stroke:#333,stroke-width:1px;\n classDef size fill:#fbf,stroke:#333,stroke-width:1px;\n classDef region fill:#ff9,stroke:#333,stroke-width:1px;\n \n class Proxy proxy;\n class V1,V2 version;\n class Beta,Stable audience;\n class Standard,HighMem size;\n class US,EU region;\n이 다이어그램은 API 게이트웨이가 MCP 요청에 대해 구현할 수 있는 다양한 라우팅 전략을 보여줍니다. 게이트웨이는 여러 요인에 따라 트래픽을 라우팅할 수 있습니다:
\n\nAI 에이전트는 이러한 라우팅 결정을 인식할 필요가 없습니다. 논리적 도구 이름에 대한 요청만 하면 게이트웨이가 적절한 백엔드로 라우팅하는 복잡성을 처리합니다. 이 추상화는 강력한 운영 기능을 제공하면서 에이전트의 구현을 단순화합니다.
\n\n마찬가지로 라우팅은 컨텍스트를 고려할 수 있습니다. 예를 들어 사용자의 위치를 알고 있는 경우 대기 시간을 줄이기 위해 가장 가까운 지역 서버로 요청을 전달하거나 요청 크기에 따라 다른 백엔드를 선택합니다(아마도 매우 큰 파일의 경우 특수 고메모리 인스턴스). 이 모든 것은 프록시 수준에서 구성할 수 있습니다. AI 에이전트는 단순히 논리적 도구 이름을 호출하고 게이트웨이가 올바른 백엔드를 찾는 것을 처리합니다. 이것은 운영을 용이하게 할 뿐만 아니라(AI의 인터페이스를 깨지 않고 백엔드 도구를 업그레이드할 수 있음) 보안도 추가합니다. 테스트를 위해 특정 버전을 격리하거나 실험적 도구가 특정 조건에서만 접근 가능하도록 보장할 수 있습니다. 트래픽 흐름을 제어함으로써 프록시는 매크로 규모에서 최소 권한 원칙을 유지하는 데 도움이 됩니다. AI는 현재 컨텍스트에 적합한 경로를 통해 도달해야 하는 백엔드에만 도달합니다.
\n\n이제 주요 보안 패턴을 다루었으므로 신원 인식 프록시를 사용하여 MCP 보안을 구현하는 실용적인 접근 방식을 살펴보겠습니다. 이 섹션에서는 구성 요소 간의 통합 지점에 초점을 맞춰 안전한 MCP 환경을 설정하는 단계를 개괄합니다.
\n\ngraph TB\n subgraph ImplementationSteps[\"구현 단계\"]\n Step1[1. 신원 제공자 설정]\n Step2[2. API 게이트웨이 구성]\n Step3[3. 도구 레지스트리 구현]\n Step4[4. 보안 정책 정의]\n Step5[5. AI 에이전트 통합]\n Step6[6. 모니터링 및 감사]\n \n Step1 --> Step2\n Step2 --> Step3\n Step3 --> Step4\n Step4 --> Step5\n Step5 --> Step6\n end\n \n classDef step fill:#beb,stroke:#333,stroke-width:1px\n class Step1,Step2,Step3,Step4,Step5,Step6 step\n이 다이어그램은 프록시를 사용하여 MCP 보안을 구현하는 6가지 주요 단계를 개괄합니다. 프로세스는 논리적 진행을 따릅니다:
\n\n각 단계는 이전 단계를 기반으로 하여 포괄적인 보안 구현을 만듭니다. 다음 섹션에서는 각 단계를 자세히 살펴봅니다.
\n\n첫 번째 단계는 MCP 보안에 필요한 OIDC 흐름을 지원하도록 신원 제공자(IdP)를 구성하는 것입니다. 일반적으로 다음이 포함됩니다:
\n\nIdP는 사용자를 인증하고 MCP 요청을 보호하는 데 사용될 토큰을 발급하는 역할을 합니다. 토큰에 권한 부여 결정에 필요한 정보가 포함되도록 적절한 스코프와 클레임을 구성하는 것이 중요합니다.
\n\n다음으로 API 게이트웨이를 MCP 프록시 역할을 하도록 구성해야 합니다. 여기에는 다음이 포함됩니다:
\n\nsequenceDiagram\n participant Admin as 관리자\n participant Gateway as API 게이트웨이\n participant IdP as 신원 제공자\n \n Admin->>Gateway: 1. OIDC 통합 구성\n Gateway->>IdP: 2. OIDC 검색 문서 가져오기\n IdP->>Gateway: 3. 엔드포인트 및 키 반환\n \n Admin->>Gateway: 4. MCP 라우팅 규칙 설정\n Admin->>Gateway: 5. 보안 정책 구성\n \n Note over Gateway: 게이트웨이가 토큰을 검증하고 MCP 트래픽을 라우팅할 준비가 됨\n이 시퀀스 다이어그램은 MCP 보안을 위한 API 게이트웨이 구성 프로세스를 보여줍니다. 프로세스는 관리자가 게이트웨이에서 OIDC 통합을 구성하는 것으로 시작됩니다. 그런 다음 게이트웨이는 신원 제공자로부터 OIDC 검색 문서를 가져오고, 이는 토큰 검증에 필요한 엔드포인트와 키를 반환합니다.
\n\n다음으로 관리자는 다양한 기준에 따라 요청을 다른 MCP 도구로 전달하는 방법을 정의하는 MCP 라우팅 규칙을 설정합니다. 관리자는 또한 누가 어떤 도구에 어떤 조건에서 접근할 수 있는지 지정하는 보안 정책을 구성합니다.
\n\n이러한 구성이 완료되면 게이트웨이는 정의된 규칙과 정책에 따라 토큰을 검증하고 MCP 트래픽을 라우팅할 준비가 됩니다. 이 설정 프로세스는 게이트웨이를 모든 MCP 상호 작용의 중앙 보안 제어 지점으로 설정합니다.
\n\n구성 단계는 다음과 같습니다:
\n\n게이트웨이는 토큰을 검증하고, 보안 정책을 시행하고, MCP 요청을 적절한 백엔드로 라우팅하는 역할을 합니다. 게이트웨이가 MCP JSON-RPC 형식을 처리하고 정책 결정에 필요한 정보를 추출하도록 적절하게 구성되었는지 확인하는 것이 중요합니다.
\n\n도구 레지스트리는 환경에서 MCP 도구의 수명 주기를 관리하는 데 필수적입니다. 여기에는 다음이 포함됩니다:
\n\n도구 레지스트리는 사용 가능한 도구 목록, 엔드포인트 및 접근 요구 사항을 유지 관리하는 역할을 합니다. 또한 라우팅 및 정책 시행을 위해 API 게이트웨이에 필요한 정보를 제공합니다.
\n\ngraph TB\n subgraph \"도구 레지스트리\"\n DB[(도구 데이터베이스)]\n API[레지스트리 API]\n UI[관리 UI]\n \n UI -->|도구 관리| API\n API -->|CRUD 작업| DB\n end\n \n subgraph \"통합 지점\"\n Gateway[API 게이트웨이]\n Agents[AI 에이전트]\n \n API -->|도구 구성| Gateway\n API -->|사용 가능한 도구| Agents\n end\n \n subgraph \"도구 수명 주기\"\n Register[등록]\n Approve[승인]\n Deploy[배포]\n Monitor[모니터링]\n Retire[폐기]\n \n Register --> Approve\n Approve --> Deploy\n Deploy --> Monitor\n Monitor --> Retire\n end\n \n classDef registry fill:#bbf,stroke:#333,stroke-width:1px;\n classDef integration fill:#fbf,stroke:#333,stroke-width:1px;\n classDef lifecycle fill:#bfb,stroke:#333,stroke-width:1px;\n \n class DB,API,UI registry;\n class Gateway,Agents integration;\n class Register,Approve,Deploy,Monitor,Retire lifecycle;\n이 다이어그램은 MCP 환경에서 도구 레지스트리의 구성 요소와 수명 주기를 보여줍니다. 도구 레지스트리는 세 가지 주요 구성 요소로 구성됩니다:
\n\n도구 레지스트리는 두 가지 주요 시스템과 통합됩니다:
\n\n다이어그램은 또한 MCP 도구의 수명 주기를 보여줍니다:
\n\n이러한 포괄적인 도구 관리 접근 방식은 모든 MCP 도구가 수명 주기 전반에 걸쳐 적절하게 검증되고, 배포되고, 모니터링되도록 보장하여 보안 위험과 운영 문제를 줄입니다.
\n\n보안 정책은 MCP 도구에 대한 접근을 관리하는 규칙입니다. 여기에는 다음이 포함됩니다:
\n\n보안 정책은 사용자의 신원과 접근 중인 도구를 기반으로 API 게이트웨이에 의해 시행됩니다. 정책이 포괄적이고 조직의 보안 요구 사항과 일치하는지 확인하는 것이 중요합니다.
\n\n마지막으로 AI 에이전트를 안전한 MCP 환경과 통합해야 합니다. 여기에는 다음이 포함됩니다:
\n\nAI 에이전트는 필요한 토큰을 얻고 MCP 요청에 포함하는 역할을 합니다. 또한 인증 및 권한 부여 오류를 우아하게 처리하여 사용자에게 적절한 피드백을 제공해야 합니다.
\n\nsequenceDiagram\n participant User as 사용자\n participant Agent as AI 에이전트\n participant App as 애플리케이션\n participant IdP as 신원 제공자\n participant Gateway as API 게이트웨이\n participant Tool as MCP 도구\n \n User->>App: AI 애플리케이션 접근\n App->>IdP: 사용자 인증\n IdP->>App: 토큰 발급\n \n User->>Agent: AI 기능을 사용하여 요청\n Agent->>App: MCP용 토큰 요청\n App->>Agent: 토큰 제공\n \n Agent->>Gateway: 토큰이 포함된 MCP 요청\n Gateway->>Gateway: 토큰 검증 및 정책 적용\n Gateway->>Tool: 권한 부여된 요청 전달\n Tool->>Gateway: 응답\n Gateway->>Agent: 응답 반환\n Agent->>User: 결과 제시\n \n Note over App,Gateway: 토큰 갱신 주기\n App->>IdP: 필요할 때 토큰 갱신\n IdP->>App: 새 액세스 토큰\n이 시퀀스 다이어그램은 AI 에이전트를 안전한 MCP 환경과 통합하는 것을 보여줍니다. 프로세스는 사용자가 AI 애플리케이션에 접근할 때 시작되며, 애플리케이션은 신원 제공자와 함께 사용자를 인증하고 토큰을 받습니다.
\n\n사용자가 AI 기능이 필요한 요청을 할 때 AI 에이전트는 애플리케이션에 토큰을 요청하고 애플리케이션이 이를 제공합니다. 그런 다음 에이전트는 API 게이트웨이에 대한 MCP 요청에 이 토큰을 포함합니다.
\n\n게이트웨이는 토큰을 검증하고 보안 정책을 적용하여 요청을 허용할지 결정합니다. 권한이 부여되면 요청이 적절한 MCP 도구로 전달되고, 도구가 이를 처리하고 응답을 반환합니다. 이 응답은 게이트웨이를 통해 에이전트로 다시 흐르고 궁극적으로 사용자에게 전달됩니다.
\n\n백그라운드에서 애플리케이션은 토큰 갱신 주기를 처리하여 필요할 때 신원 제공자로부터 새 액세스 토큰을 요청합니다. 이것은 사용자가 자주 다시 인증할 필요 없이 지속적인 작업을 보장합니다.
\n\n이 통합 접근 방식은 AI 에이전트가 프록시 아키텍처에 의해 설정된 보안 프레임워크 내에서 작동하도록 보장하며, 모든 요청이 적절하게 인증되고 권한이 부여됩니다.
\n\n신원 인식 프록시를 사용하여 안전한 MCP 아키텍처를 구현함으로써 \"미화된 API 호출\"을 훨씬 뛰어넘어 AI 에이전트와 비즈니스 시스템 간의 강력한 엔터프라이즈급 통합으로 이동합니다. 이 접근 방식은 다음을 포함하여 MCP 배포의 주요 보안 과제를 해결합니다:
\n\n프록시 기반 아키텍처는 보안 정책을 시행하고, 도구 접근을 관리하고, AI 에이전트 활동을 모니터링하기 위한 중앙 집중식 제어 지점을 제공합니다. 또한 백엔드 서비스의 복잡성을 추상화하고 AI 에이전트에 일관된 인터페이스를 제공하여 운영을 단순화합니다.
\n\nMCP가 계속 발전하고 채택됨에 따라 이 기사에서 설명한 보안 패턴은 엔터프라이즈 배포에 점점 더 중요해질 것입니다. 지금 이러한 패턴을 구현함으로써 AI 에이전트 인프라가 안전하고 확장 가능하며 미래에 대비할 수 있도록 보장할 수 있습니다.
\n\ngraph LR\n A[미화된 API 호출] -->|진화| B[안전한 MCP 아키텍처]\n \n subgraph \"주요 이점\"\n C[중앙 집중식 보안]\n D[신원 전파]\n E[정책 시행]\n F[감사 및 규정 준수]\n G[운영 단순성]\n end\n \n B --> C\n B --> D\n B --> E\n B --> F\n B --> G\n \n classDef benefit fill:#bfb,stroke:#333,stroke-width:1px;\n class C,D,E,F,G benefit;\n이 최종 다이어그램은 \"미화된 API 호출\"에서 안전한 MCP 아키텍처로의 진화를 요약하며, 이 접근 방식의 주요 이점을 강조합니다:
\n\n이 아키텍처를 채택함으로써 조직은 MCP 상호 작용이 안전하고 감사 가능하며 대규모로 관리 가능하다는 것을 알고 엔터프라이즈 환경에 AI 에이전트를 자신 있게 배포할 수 있습니다. 이것은 AI 도구를 단순한 API 호출로 보는 단순한 관점을 넘어 프로덕션 AI 시스템의 복잡한 보안 요구 사항을 인식하는 중요한 발전을 나타냅니다.
", "source_hash": "sha256:2e298f37ca328b0eb320a81887dd3640aeb212ad3bf1d820c547bb98ab9e3b19", "model": "claude-sonnet-4-5-20250929", "generated_at": "2026-01-02T03:20:36.530636+00:00" }