Kong AI Gateway 3.12로 MCP 서버에 OAuth 2.1 인증·토큰 Rate Limiting·팀별 비용 귀속을 코드 수정 없이 적용하기

MCP 서버를 세 개 운영하는 팀이라면, 지금쯤 인증 로직을 세 번 작성하고 있을 가능성이 높습니다. GitHub 이슈를 생성하고, 사내 재고 DB를 조회하고, Slack 메시지를 발송하는 각각의 MCP 서버에 OAuth 토큰 검증 코드가 중복되어 있고, 팀별로 얼마나 토큰을 소비했는지는 여전히 손으로 집계하고 있을지도 모릅니다. 에이전트 수가 늘어날수록 이 문제는 선형이 아니라 기하급수적으로 복잡해집니다.

Kong AI Gateway는 기존 API 게이트웨이 역할(인증·속도 제한·라우팅)을 AI/MCP 트래픽으로 확장한 플랫폼입니다. 2025년 Kong 3.12 버전에서는 MCP 트래픽 전용 플러그인 세트가 추가되어, OAuth 2.1 기반 인증·토큰 단위 Rate Limiting·팀별 비용 귀속을 각 MCP 서버에 코드를 추가하지 않고 게이트웨이 레이어에서 선언적으로 처리할 수 있게 되었습니다. 이 글에서는 Kong AI Gateway를 MCP 서버 앞단에 배치하여 인증·속도 제한·비용 추적을 단일 레이어에서 처리하는 구체적인 방법과, 실무에서 흔히 마주치는 함정을 살펴봅니다. 이 글을 읽고 나면 Kong 3.12의 YAML 선언형 설정을 통해 기존 MCP 서버에 OAuth 2.1 인증과 팀별 쿼터를 적용하는 전체 흐름을 파악하고, 자신의 환경에 이를 적용할 수 있습니다.

사전 지식 안내: MCP와 OAuth 2.1 개념이 이미 익숙하다면 실전 적용 섹션으로 바로 이동해도 됩니다. Kong을 처음 접한다면 핵심 개념 섹션부터 순서대로 읽는 것을 권장합니다.

핵심 개념

세 가지 기술의 역할 관계

본격적인 설명에 앞서, 이 글에서 다루는 세 가지 기술이 각각 어떤 역할을 담당하는지 먼저 살펴보겠습니다.

┌─────────────────────────────────────────────────────────┐
│                    전체 아키텍처                          │
│                                                         │
│  [Authorization Server]  ←─────── 토큰 발급             │
│   Keycloak / Auth0 / Okta                               │
│           │ JWKS 공개키 제공                              │
│           ▼                                             │
│  [Kong AI Gateway 3.12]  ←─────── 토큰 검증·속도 제한    │
│   Resource Server 역할                                   │
│           │ 검증된 요청만 전달                             │
│           ▼                                             │
│  [MCP 서버들]            ←─────── 실제 도구 실행          │
│   GitHub MCP / 사내 API MCP 등                           │
└─────────────────────────────────────────────────────────┘
 
MCP     → AI 에이전트와 도구 서버 간의 표준 통신 프로토콜
OAuth 2.1 → "누가 어떤 권한으로 접근하는가"를 검증하는 인증 표준
Kong    → 위 두 가지를 코드 수정 없이 게이트웨이 레이어에서 처리

MCP: AI 에이전트와 도구를 잇는 표준 프로토콜

MCP(Model Context Protocol)는 Anthropic이 2024년 공개한 오픈 프로토콜로, AI 에이전트(MCP Client)와 외부 도구·데이터 소스(MCP Server) 간의 통신 방식을 표준화합니다. JSON-RPC 2.0을 전송 프로토콜로 사용하며, 파일 시스템·데이터베이스·외부 API 등을 일관된 "Tool" 인터페이스로 호출할 수 있게 합니다.

MCP란? USB-C가 다양한 기기를 하나의 커넥터로 연결하듯, MCP는 AI 에이전트와 도구 서버 사이의 "표준 커넥터" 역할을 합니다. 도구마다 서로 다른 API 형식을 사용하더라도, MCP 위에서는 동일한 방식으로 호출할 수 있습니다.

MCP 사양은 빠르게 성숙하고 있습니다. 초기에는 인증 메커니즘이 없었으나 2025년 3월 OAuth 지원이 추가되었고, 2025년 6월 공식 사양이 확정되었습니다. 이후 발행된 MCP 사양 2025-11-25에서는 비동기 Task와 Resource Indicators가 강화되었으며, OAuth 2.1이 공식 인증 방식으로 자리잡았습니다.

한 가지 주의할 점이 있습니다. MCP 초기 사양은 SSE(Server-Sent Events)를 transport로 사용했으나, 최신 사양에서는 SSE 전용 transport가 deprecated되고 Streamable HTTP가 도입되었습니다. 이 글의 예시는 SSE 기반으로 작성되어 있으므로, 최신 사양을 따르는 환경에서는 transport 설정을 별도로 확인하는 것을 권장합니다.

OAuth 2.1: 현대화된 인증 표준

OAuth 2.1(RFC 9700)은 OAuth 2.0의 보안 취약점을 제거하고 현대화한 사양입니다.

변경 사항	OAuth 2.0	OAuth 2.1
PKCE	선택 사항	필수
Implicit Grant	허용	제거
Resource Indicators	미정의	RFC 8707로 공식화

PKCE(Proof Key for Code Exchange, RFC 7636)란? 인증 코드 가로채기 공격을 방지하는 메커니즘입니다. 클라이언트가 임의의 code_verifier를 생성하고, 해시값인 code_challenge를 인가 서버에 먼저 전달해 코드 교환 시 검증합니다.

MCP 인증 구조에서 Kong은 토큰을 발급하는 역할이 아닙니다.

Resource Server란? Kong은 OAuth 2.1 구조에서 Resource Server 역할을 담당합니다. 실제 토큰을 발급하는 Authorization Server(Keycloak, Auth0, Okta 등)는 별도로 운영해야 하며, Kong은 발급된 토큰의 유효성을 검증하고 요청을 허용·거부하는 역할만 수행합니다. Authorization Server 없이 Kong만 배치하면 인증 흐름 전체가 동작하지 않으니, 이 점을 먼저 확인해두는 것이 중요합니다.

Kong AI Gateway 3.12의 MCP 전용 플러그인

Kong은 API Gateway 플랫폼으로, 인증·속도 제한·라우팅·모니터링 등을 플러그인 방식으로 조합해 처리합니다. 3.12 버전에서 MCP 트래픽 전용 플러그인 세트가 추가되었습니다.

플러그인	역할	티어
`ai-mcp-proxy`	MCP ↔ HTTP 브리지, 다중 서버 Tool 집계	Enterprise
`ai-mcp-oauth2`	OAuth 2.1 토큰 검증, JWT → 가상 Consumer 매핑	Enterprise
`ai-rate-limiting-advanced`	토큰 기반 쿼터 (Consumer·팀 단위)	Enterprise
`acl` + MCP Tool ACL	MCP Tool 이름 단위 세분화 접근 제어	Enterprise
`prometheus`	MCP Tool 호출 메트릭 수집 (3.12에서 MCP 확장)	Free

오픈소스 한계: ai-mcp-oauth2, ai-rate-limiting-advanced 등 핵심 플러그인은 Kong Enterprise(유료) 또는 Konnect에서만 사용 가능합니다. 오픈소스 버전에서는 이 플러그인들이 포함되지 않으므로, 도입 전 라이선스 조건을 반드시 확인하는 것을 권장합니다.

실전 적용

아래 네 가지 예시는 독립된 시나리오가 아니라 순차적으로 쌓아가는 구조입니다. 예시 1에서 기본 프록시를 구성하고, 예시 2에서 팀별 비용 귀속을 추가하고, 예시 3에서 기존 REST API를 MCP Tool로 변환하고, 예시 4에서 Tool 단위 세분화 제어를 얹는 순서로 이해하면 전체 그림을 그리기 쉽습니다.

예시 1: Kong을 MCP 서버 앞 단일 프록시로 배치 (Passthrough 모드)

가장 일반적인 배치 패턴입니다. 기존 MCP 서버는 그대로 두고, Kong이 앞단에서 인증·속도 제한·모니터링을 처리합니다.

AI 에이전트 (MCP Client)
       │  (OAuth 2.1 Bearer Token 포함)
       ▼
Kong AI Gateway 3.12
  ├─ ai-mcp-oauth2           ← JWT 토큰 검증, sub → 가상 Consumer 매핑
  ├─ ai-rate-limiting-advanced ← 팀별 토큰 쿼터 적용
  ├─ ai-mcp-proxy            ← MCP 트래픽 그대로 업스트림 전달
  └─ prometheus              ← Tool 호출 메트릭 수집
       │
       ▼
 MCP 서버 (GitHub MCP, 사내 API MCP 등)

아래는 Kong deck CLI로 관리하는 YAML 선언형 설정 예시입니다.

yaml

services:
  - name: mcp-github
    url: https://mcp.github.internal
    routes:
      - name: mcp-github-route
        paths:
          - /mcp/github
    plugins:
      - name: ai-mcp-oauth2
        config:
          issuer: https://auth.example.com          # Authorization Server URL
          credential_claim: sub                      # JWT의 sub 클레임 → 가상 Consumer ID
          audience: https://mcp.example.com          # Resource Indicator (RFC 8707)
      - name: ai-rate-limiting-advanced
        config:
          limit_by: consumer
          policy: local                              # ⚠️ 단일 인스턴스 환경에서만 적합
          tokens_count_strategy: total_tokens        # prompt + completion 토큰 합산
          limits:
            - limit: 100000
              window_size: 3600                      # 1시간당 10만 토큰 쿼터
      - name: ai-mcp-proxy
        config:
          mode: passthrough-listener                 # MCP 트래픽 그대로 전달
      - name: prometheus
        config:
          per_consumer: true                         # Consumer별 메트릭 분리 수집

policy: local 주의사항: 위 예시의 policy: local은 Kong 인스턴스 하나에서만 쿼터를 집계합니다. Kong 인스턴스를 여러 개 운영하는 분산 환경에서는 인스턴스별로 쿼터가 독립 집계되어 실제 제한의 N배까지 소비되는 문제가 생길 수 있습니다. 멀티 인스턴스 환경이라면 policy: redis로 변경하고 Redis 클러스터를 함께 구성하는 것을 권장합니다.

이 YAML을 실제 Kong에 반영하려면 deck CLI를 사용합니다.

# 설정 적용
deck gateway sync kong.yaml
 
# 연결 확인
deck gateway ping

설정 키	설명
`issuer`	JWT를 발급한 Authorization Server의 URL. Kong이 이 서버의 JWKS 엔드포인트에서 공개키를 가져와 토큰을 검증합니다
`credential_claim`	JWT 페이로드에서 어떤 클레임을 Consumer ID로 사용할지 지정. `sub`, `email`, `team` 등 사용 가능
`tokens_count_strategy`	Rate Limiting 기준 토큰 종류. `total_tokens`, `prompt_tokens`, `completion_tokens` 중 선택
`window_size`	쿼터 초기화 주기(초). 3600 = 1시간, 86400 = 1일

예시 2: 팀별 비용 귀속 파이프라인

JWT 토큰의 team 클레임을 Consumer Group으로 매핑하면, 팀 단위 토큰 소비량과 비용을 추적할 수 있습니다.

yaml

# 1단계: Consumer Group 정의
consumer_groups:
  - name: team-platform
  - name: team-data
  - name: team-frontend
 
# 2단계: Consumer Group별 Rate Limit 정책 (Override)
plugins:
  - name: ai-rate-limiting-advanced
    consumer_group: team-platform
    config:
      limits:
        - limit: 500000      # 플랫폼 팀: 시간당 50만 토큰
          window_size: 3600
  - name: ai-rate-limiting-advanced
    consumer_group: team-data
    config:
      limits:
        - limit: 1000000     # 데이터 팀: 시간당 100만 토큰
          window_size: 3600

yaml

# 3단계: ai-mcp-oauth2에서 team 클레임을 Consumer Group으로 매핑
plugins:
  - name: ai-mcp-oauth2
    config:
      issuer: https://auth.example.com
      credential_claim: sub
      consumer_group_claim: team   # JWT의 team 클레임 → Consumer Group 자동 매핑
                                   # 공식 문서에서 설정 키 이름을 반드시 확인하는 것을 권장합니다

consumer_group_claim 확인 권장: consumer_group_claim은 Kong 공식 ai-mcp-oauth2 플러그인 문서에서 실제 설정 키 이름과 지원 버전을 확인하는 것을 권장합니다. 플러그인 버전에 따라 키 이름이 다를 수 있습니다.

이 파이프라인이 완성되면 다음 흐름으로 비용 귀속이 이루어집니다.

sql

JWT 토큰 (team: "data") 수신
        │
        ▼
ai-mcp-oauth2: team 클레임 → "team-data" Consumer Group으로 매핑
        │
        ▼
ai-rate-limiting-advanced: "team-data" 그룹의 쿼터 차감
        │
        ▼
prometheus 메트릭: team="team-data" 레이블로 토큰 소비량 기록
        │
        ▼
Grafana 대시보드: 팀별 토큰 소비량 / 비용 시각화

토큰 소비량은 어떻게 집계되나요? Kong은 업스트림 LLM Provider(예: OpenAI, Anthropic)의 응답 바디에서 토큰 사용량(usage.total_tokens 등)을 파싱해 집계합니다. 단, MCP 서버 자체가 LLM을 직접 호출하지 않고 Tool만 중개하는 구조라면, "토큰 집계 지점"이 MCP 레이어가 아닌 LLM API 레이어에 있다는 점을 유의해야 합니다. MCP Tool 실행 비용(외부 API 호출 비용 등)은 이 방식으로는 추적되지 않으며, 해당 서비스의 청구 데이터와 별도로 집계해 FinOps 보고서에서 통합하는 방식이 현실적입니다.

예시 3: REST API를 코드 변경 없이 MCP Tool로 변환

기존 Kong에서 관리 중인 RESTful API를 MCP Tool로 노출하는 방법입니다. http-to-mcp 모드를 활성화하면 OpenAPI 스펙을 기반으로 Tool 스키마가 자동 생성됩니다.

yaml

services:
  - name: inventory-api
    url: https://inventory.internal/api
    plugins:
      - name: ai-mcp-proxy
        config:
          mode: http-to-mcp                          # REST → MCP Tool 변환 모드
          openapi_spec_url: https://inventory.internal/openapi.json
          tool_name_prefix: inventory_               # Tool 이름 prefix (충돌 방지)

openapi_spec_url 네트워크 접근성: openapi_spec_url에 지정하는 URL은 Kong 인스턴스에서 직접 접근할 수 있어야 합니다. 외부 URL을 사용하는 경우 Kong이 시작 시점에 스펙을 가져오는지, 요청마다 가져오는지 동작 방식이 다를 수 있으니 공식 문서에서 확인하는 것을 권장합니다. 내부 네트워크 환경이라면 Kubernetes FQDN 형식(https://inventory-svc.default.svc.cluster.local/openapi.json)으로 지정할 수 있습니다.

변환 결과, AI 에이전트는 GET /api/products/{id} 대신 inventory_get_product MCP Tool을 호출하게 됩니다. 기존 API 코드는 전혀 수정할 필요가 없습니다.

예시 4: MCP Tool 단위 세분화 접근 제어

특정 팀만 위험한 Tool(create_issue, delete_branch)을 호출하도록 제한할 수 있습니다. 이 기능은 Kong 3.12에서 도입된 MCP Tool ACL 패턴으로, Kong 공식 블로그의 "Introducing MCP Tool ACLs" 발표를 통해 확인할 수 있습니다.

yaml

plugins:
  - name: acl
    config:
      allow:
        - team-platform                              # 기본 접근 허용 그룹
  - name: mcp-tool-acl                              # Tool 단위 세분화 제어
    config:
      rules:
        - tool: create_issue
          allow_groups:
            - team-platform
            - team-data
        - tool: delete_branch
          allow_groups:
            - team-platform                          # 플랫폼 팀만 브랜치 삭제 가능
        - tool: read_file
          allow_groups:
            - team-platform
            - team-data
            - team-frontend                          # 읽기 권한은 모든 팀에 허용

MCP Tool ACL이란? 기존 API Gateway의 경로(path) 단위 접근 제어와 달리, MCP Tool 이름(create_issue, read_file 등) 단위로 권한을 정의하는 패턴입니다. "읽기는 허용, 쓰기는 시니어 팀만"과 같은 세분화된 정책을 선언적으로 관리할 수 있습니다.

장단점 분석

장점

항목	내용
단일 제어 평면	인증·속도 제한·비용 추적·로깅을 하나의 레이어에서 처리. 각 MCP 서버에 보안 로직을 중복 구현할 필요가 없습니다
기존 Kong 인프라 재사용	이미 Kong을 API 게이트웨이로 운영 중인 조직이라면 추가 인프라 없이 MCP 트래픽 관리를 확장할 수 있습니다
MCP 사양 준수	OAuth 2.1 Resource Server, PKCE, Resource Indicators(RFC 8707) 지원으로 최신 MCP 사양과의 호환성이 확보됩니다
세분화된 Tool ACL	API 경로 단위가 아닌 MCP Tool 이름 단위로 접근 제어가 가능합니다
FinOps 가시성	Tool 호출 단위의 Prometheus 메트릭과 Konnect Analytics로 팀별 AI 비용을 파악할 수 있습니다
Kubernetes 친화적	Kong Data Plane과 MCP 서버를 동일 클러스터에 배치하면 Kubernetes FQDN으로 내부 통신이 가능합니다

단점 및 주의사항

항목	내용	대응 방안
엔터프라이즈 라이선스 비용	`ai-rate-limiting-advanced`, `ai-mcp-oauth2` 등 핵심 플러그인은 엔터프라이즈 전용. 중견 규모 기준 연 $50,000 이상이 될 수 있습니다	LiteLLM, IBM ContextForge, Envoy AI Gateway 등 오픈소스 대안과 기능·비용을 비교한 뒤 도입을 결정하는 것을 권장합니다
Kong 3.12 이상 필수	AI MCP 플러그인은 3.12 미만에서는 지원되지 않습니다	스테이징 환경에서 버전 업그레이드를 충분히 검증한 뒤 프로덕션에 적용하는 것을 권장합니다
Stateful SSE 세션	SSE 기반 장기 연결을 올바르게 프록시하려면 세션 친화성(Session Affinity) 설정이 필요합니다	Kong의 `hash_on: consumer` 또는 `hash_on: ip` 로드밸런싱 설정으로 동일 세션이 같은 인스턴스로 라우팅되도록 구성할 수 있습니다
별도 Authorization Server 필요	Kong은 Resource Server 역할만 수행. Keycloak, Auth0, Okta 등 별도 IdP 운영이 전제 조건입니다	기존 조직의 IdP가 있다면 연동이 수월합니다. 신규 도입이라면 오픈소스 Keycloak을 함께 구성하는 방법이 있습니다
MCP Tool 실행 비용 미추적	비용 계산은 LLM Provider 응답의 토큰 수에만 의존. 외부 API 호출 등 Tool 자체 실행 비용은 별도 집계가 필요합니다	해당 서비스의 청구 데이터를 별도로 수집하고 FinOps 보고서에서 통합하는 방식을 고려할 수 있습니다
빠른 MCP 사양 변화	MCP 사양이 2025년 한 해에만 수차례 개정되었으며, Kong 플러그인의 사양 반영 속도를 지속 확인해야 합니다	Kong Gateway Changelog와 MCP 공식 사양 페이지를 정기적으로 확인하는 것을 권장합니다

Session Affinity(세션 친화성)란? 로드밸런서가 동일 클라이언트의 요청을 항상 같은 서버 인스턴스로 보내는 설정입니다. SSE처럼 연결을 유지하는 프로토콜에서는 이 설정이 없으면 연결이 끊기거나 상태가 유실될 수 있습니다.

실무에서 가장 흔한 실수

Authorization Server 없이 Kong만 배치하는 경우 — Kong의 ai-mcp-oauth2 플러그인은 토큰 검증(Resource Server)만 담당합니다. 토큰을 발급하는 Keycloak, Auth0 등의 Authorization Server가 별도로 필요하며, 이를 간과하면 인증 흐름 전체가 동작하지 않습니다.
SSE 세션에 Session Affinity를 설정하지 않는 경우 — MCP 클라이언트가 SSE로 장기 연결을 유지하는데 Kong이 기본 라운드로빈 방식으로 로드밸런싱을 하면, 같은 세션의 요청이 서로 다른 인스턴스로 분산되어 연결이 끊길 수 있습니다.
Rate Limiting을 요청 수(Request Count) 기준으로 설정하는 경우 — MCP 트래픽에서 비용은 요청 수가 아닌 토큰 소비량에 비례합니다. tokens_count_strategy: total_tokens 설정을 활용해 토큰 기반 쿼터를 적용하는 것이 실질적인 비용 통제에 효과적입니다.

마치며

Kong AI Gateway 3.12는 기존 Kong 인프라를 운영 중인 조직이 MCP 트래픽의 인증·속도 제한·비용 귀속을 단일 레이어에서 선언적으로 관리할 수 있는 현실적인 선택지입니다. 단, 엔터프라이즈 라이선스 비용, 별도 Authorization Server 운영, Kong 버전 업그레이드라는 선행 조건이 필요합니다. 이미 Kong과 IdP를 운영 중이고 빠른 통합이 필요한 환경이라면 YAML 선언 몇 줄로 전체 흐름을 구성할 수 있지만, 이 세 가지 전제가 충족되지 않는다면 LiteLLM, IBM ContextForge 등 오픈소스 대안과 비교 검토해보는 것을 권장합니다.

지금 바로 시작할 수 있는 3단계:

Kong Gateway 3.12 설치 및 deck CLI 준비 — Kong 공식 Gateway Changelog에서 최신 버전과 설치 방법을 확인할 수 있습니다. Docker 또는 Kubernetes에 Kong 3.12를 배포한 뒤, deck gateway ping으로 연결을 확인해보는 것을 권장합니다.
GitHub MCP 서버 보안 튜토리얼 실습 — Kong 공식 문서의 "Secure GitHub MCP Server traffic with Kong Gateway" 튜토리얼을 따라가시면 OAuth 2.1 검증과 ACL 설정을 실제로 체험해볼 수 있습니다. 로컬 Keycloak과 GitHub MCP 서버를 Docker Compose로 구성하면 외부 의존 없이 전체 흐름을 테스트해볼 수 있습니다.
Prometheus + Grafana로 팀별 메트릭 시각화 — prometheus 플러그인을 활성화하고 /metrics 엔드포인트를 Grafana에 연결하면 kong_ai_llm_provider_latency_ms, kong_ai_requests_total 등 MCP 관련 메트릭을 실시간으로 확인할 수 있습니다. consumer_group 레이블로 필터링하면 팀별 토큰 소비 현황을 대시보드로 구성하는 데 도움이 됩니다.

참고 자료

Kong AI Gateway 3.12로 MCP 서버에 OAuth 2.1 인증·토큰 Rate Limiting·팀별 비용 귀속을 코드 수정 없이 적용하기

사전 지식 안내: MCP와 OAuth 2.1 개념이 이미 익숙하다면 실전 적용 섹션으로 바로 이동해도 됩니다. Kong을 처음 접한다면 핵심 개념 섹션부터 순서대로 읽는 것을 권장합니다.

핵심 개념

세 가지 기술의 역할 관계

본격적인 설명에 앞서, 이 글에서 다루는 세 가지 기술이 각각 어떤 역할을 담당하는지 먼저 살펴보겠습니다.

┌─────────────────────────────────────────────────────────┐
│                    전체 아키텍처                          │
│                                                         │
│  [Authorization Server]  ←─────── 토큰 발급             │
│   Keycloak / Auth0 / Okta                               │
│           │ JWKS 공개키 제공                              │
│           ▼                                             │
│  [Kong AI Gateway 3.12]  ←─────── 토큰 검증·속도 제한    │
│   Resource Server 역할                                   │
│           │ 검증된 요청만 전달                             │
│           ▼                                             │
│  [MCP 서버들]            ←─────── 실제 도구 실행          │
│   GitHub MCP / 사내 API MCP 등                           │
└─────────────────────────────────────────────────────────┘
 
MCP     → AI 에이전트와 도구 서버 간의 표준 통신 프로토콜
OAuth 2.1 → "누가 어떤 권한으로 접근하는가"를 검증하는 인증 표준
Kong    → 위 두 가지를 코드 수정 없이 게이트웨이 레이어에서 처리

MCP: AI 에이전트와 도구를 잇는 표준 프로토콜

MCP란? USB-C가 다양한 기기를 하나의 커넥터로 연결하듯, MCP는 AI 에이전트와 도구 서버 사이의 "표준 커넥터" 역할을 합니다. 도구마다 서로 다른 API 형식을 사용하더라도, MCP 위에서는 동일한 방식으로 호출할 수 있습니다.

OAuth 2.1: 현대화된 인증 표준

OAuth 2.1(RFC 9700)은 OAuth 2.0의 보안 취약점을 제거하고 현대화한 사양입니다.

변경 사항	OAuth 2.0	OAuth 2.1
PKCE	선택 사항	필수
Implicit Grant	허용	제거
Resource Indicators	미정의	RFC 8707로 공식화

PKCE(Proof Key for Code Exchange, RFC 7636)란? 인증 코드 가로채기 공격을 방지하는 메커니즘입니다. 클라이언트가 임의의 code_verifier를 생성하고, 해시값인 code_challenge를 인가 서버에 먼저 전달해 코드 교환 시 검증합니다.

MCP 인증 구조에서 Kong은 토큰을 발급하는 역할이 아닙니다.

Resource Server란? Kong은 OAuth 2.1 구조에서 Resource Server 역할을 담당합니다. 실제 토큰을 발급하는 Authorization Server(Keycloak, Auth0, Okta 등)는 별도로 운영해야 하며, Kong은 발급된 토큰의 유효성을 검증하고 요청을 허용·거부하는 역할만 수행합니다. Authorization Server 없이 Kong만 배치하면 인증 흐름 전체가 동작하지 않으니, 이 점을 먼저 확인해두는 것이 중요합니다.

Kong AI Gateway 3.12의 MCP 전용 플러그인

플러그인	역할	티어
`ai-mcp-proxy`	MCP ↔ HTTP 브리지, 다중 서버 Tool 집계	Enterprise
`ai-mcp-oauth2`	OAuth 2.1 토큰 검증, JWT → 가상 Consumer 매핑	Enterprise
`ai-rate-limiting-advanced`	토큰 기반 쿼터 (Consumer·팀 단위)	Enterprise
`acl` + MCP Tool ACL	MCP Tool 이름 단위 세분화 접근 제어	Enterprise
`prometheus`	MCP Tool 호출 메트릭 수집 (3.12에서 MCP 확장)	Free

오픈소스 한계: ai-mcp-oauth2, ai-rate-limiting-advanced 등 핵심 플러그인은 Kong Enterprise(유료) 또는 Konnect에서만 사용 가능합니다. 오픈소스 버전에서는 이 플러그인들이 포함되지 않으므로, 도입 전 라이선스 조건을 반드시 확인하는 것을 권장합니다.

실전 적용

예시 1: Kong을 MCP 서버 앞 단일 프록시로 배치 (Passthrough 모드)

가장 일반적인 배치 패턴입니다. 기존 MCP 서버는 그대로 두고, Kong이 앞단에서 인증·속도 제한·모니터링을 처리합니다.

AI 에이전트 (MCP Client)
       │  (OAuth 2.1 Bearer Token 포함)
       ▼
Kong AI Gateway 3.12
  ├─ ai-mcp-oauth2           ← JWT 토큰 검증, sub → 가상 Consumer 매핑
  ├─ ai-rate-limiting-advanced ← 팀별 토큰 쿼터 적용
  ├─ ai-mcp-proxy            ← MCP 트래픽 그대로 업스트림 전달
  └─ prometheus              ← Tool 호출 메트릭 수집
       │
       ▼
 MCP 서버 (GitHub MCP, 사내 API MCP 등)

아래는 Kong deck CLI로 관리하는 YAML 선언형 설정 예시입니다.

yaml

services:
  - name: mcp-github
    url: https://mcp.github.internal
    routes:
      - name: mcp-github-route
        paths:
          - /mcp/github
    plugins:
      - name: ai-mcp-oauth2
        config:
          issuer: https://auth.example.com          # Authorization Server URL
          credential_claim: sub                      # JWT의 sub 클레임 → 가상 Consumer ID
          audience: https://mcp.example.com          # Resource Indicator (RFC 8707)
      - name: ai-rate-limiting-advanced
        config:
          limit_by: consumer
          policy: local                              # ⚠️ 단일 인스턴스 환경에서만 적합
          tokens_count_strategy: total_tokens        # prompt + completion 토큰 합산
          limits:
            - limit: 100000
              window_size: 3600                      # 1시간당 10만 토큰 쿼터
      - name: ai-mcp-proxy
        config:
          mode: passthrough-listener                 # MCP 트래픽 그대로 전달
      - name: prometheus
        config:
          per_consumer: true                         # Consumer별 메트릭 분리 수집

policy: local 주의사항: 위 예시의 policy: local은 Kong 인스턴스 하나에서만 쿼터를 집계합니다. Kong 인스턴스를 여러 개 운영하는 분산 환경에서는 인스턴스별로 쿼터가 독립 집계되어 실제 제한의 N배까지 소비되는 문제가 생길 수 있습니다. 멀티 인스턴스 환경이라면 policy: redis로 변경하고 Redis 클러스터를 함께 구성하는 것을 권장합니다.

이 YAML을 실제 Kong에 반영하려면 deck CLI를 사용합니다.

# 설정 적용
deck gateway sync kong.yaml
 
# 연결 확인
deck gateway ping

설정 키	설명
`issuer`	JWT를 발급한 Authorization Server의 URL. Kong이 이 서버의 JWKS 엔드포인트에서 공개키를 가져와 토큰을 검증합니다
`credential_claim`	JWT 페이로드에서 어떤 클레임을 Consumer ID로 사용할지 지정. `sub`, `email`, `team` 등 사용 가능
`tokens_count_strategy`	Rate Limiting 기준 토큰 종류. `total_tokens`, `prompt_tokens`, `completion_tokens` 중 선택
`window_size`	쿼터 초기화 주기(초). 3600 = 1시간, 86400 = 1일

예시 2: 팀별 비용 귀속 파이프라인

JWT 토큰의 team 클레임을 Consumer Group으로 매핑하면, 팀 단위 토큰 소비량과 비용을 추적할 수 있습니다.

yaml

# 1단계: Consumer Group 정의
consumer_groups:
  - name: team-platform
  - name: team-data
  - name: team-frontend
 
# 2단계: Consumer Group별 Rate Limit 정책 (Override)
plugins:
  - name: ai-rate-limiting-advanced
    consumer_group: team-platform
    config:
      limits:
        - limit: 500000      # 플랫폼 팀: 시간당 50만 토큰
          window_size: 3600
  - name: ai-rate-limiting-advanced
    consumer_group: team-data
    config:
      limits:
        - limit: 1000000     # 데이터 팀: 시간당 100만 토큰
          window_size: 3600

yaml

# 3단계: ai-mcp-oauth2에서 team 클레임을 Consumer Group으로 매핑
plugins:
  - name: ai-mcp-oauth2
    config:
      issuer: https://auth.example.com
      credential_claim: sub
      consumer_group_claim: team   # JWT의 team 클레임 → Consumer Group 자동 매핑
                                   # 공식 문서에서 설정 키 이름을 반드시 확인하는 것을 권장합니다

consumer_group_claim 확인 권장: consumer_group_claim은 Kong 공식 ai-mcp-oauth2 플러그인 문서에서 실제 설정 키 이름과 지원 버전을 확인하는 것을 권장합니다. 플러그인 버전에 따라 키 이름이 다를 수 있습니다.

이 파이프라인이 완성되면 다음 흐름으로 비용 귀속이 이루어집니다.

sql

JWT 토큰 (team: "data") 수신
        │
        ▼
ai-mcp-oauth2: team 클레임 → "team-data" Consumer Group으로 매핑
        │
        ▼
ai-rate-limiting-advanced: "team-data" 그룹의 쿼터 차감
        │
        ▼
prometheus 메트릭: team="team-data" 레이블로 토큰 소비량 기록
        │
        ▼
Grafana 대시보드: 팀별 토큰 소비량 / 비용 시각화

예시 3: REST API를 코드 변경 없이 MCP Tool로 변환

yaml

services:
  - name: inventory-api
    url: https://inventory.internal/api
    plugins:
      - name: ai-mcp-proxy
        config:
          mode: http-to-mcp                          # REST → MCP Tool 변환 모드
          openapi_spec_url: https://inventory.internal/openapi.json
          tool_name_prefix: inventory_               # Tool 이름 prefix (충돌 방지)

openapi_spec_url 네트워크 접근성: openapi_spec_url에 지정하는 URL은 Kong 인스턴스에서 직접 접근할 수 있어야 합니다. 외부 URL을 사용하는 경우 Kong이 시작 시점에 스펙을 가져오는지, 요청마다 가져오는지 동작 방식이 다를 수 있으니 공식 문서에서 확인하는 것을 권장합니다. 내부 네트워크 환경이라면 Kubernetes FQDN 형식(https://inventory-svc.default.svc.cluster.local/openapi.json)으로 지정할 수 있습니다.

변환 결과, AI 에이전트는 GET /api/products/{id} 대신 inventory_get_product MCP Tool을 호출하게 됩니다. 기존 API 코드는 전혀 수정할 필요가 없습니다.

예시 4: MCP Tool 단위 세분화 접근 제어

yaml

plugins:
  - name: acl
    config:
      allow:
        - team-platform                              # 기본 접근 허용 그룹
  - name: mcp-tool-acl                              # Tool 단위 세분화 제어
    config:
      rules:
        - tool: create_issue
          allow_groups:
            - team-platform
            - team-data
        - tool: delete_branch
          allow_groups:
            - team-platform                          # 플랫폼 팀만 브랜치 삭제 가능
        - tool: read_file
          allow_groups:
            - team-platform
            - team-data
            - team-frontend                          # 읽기 권한은 모든 팀에 허용

MCP Tool ACL이란? 기존 API Gateway의 경로(path) 단위 접근 제어와 달리, MCP Tool 이름(create_issue, read_file 등) 단위로 권한을 정의하는 패턴입니다. "읽기는 허용, 쓰기는 시니어 팀만"과 같은 세분화된 정책을 선언적으로 관리할 수 있습니다.

장단점 분석

장점

항목	내용
단일 제어 평면	인증·속도 제한·비용 추적·로깅을 하나의 레이어에서 처리. 각 MCP 서버에 보안 로직을 중복 구현할 필요가 없습니다
기존 Kong 인프라 재사용	이미 Kong을 API 게이트웨이로 운영 중인 조직이라면 추가 인프라 없이 MCP 트래픽 관리를 확장할 수 있습니다
MCP 사양 준수	OAuth 2.1 Resource Server, PKCE, Resource Indicators(RFC 8707) 지원으로 최신 MCP 사양과의 호환성이 확보됩니다
세분화된 Tool ACL	API 경로 단위가 아닌 MCP Tool 이름 단위로 접근 제어가 가능합니다
FinOps 가시성	Tool 호출 단위의 Prometheus 메트릭과 Konnect Analytics로 팀별 AI 비용을 파악할 수 있습니다
Kubernetes 친화적	Kong Data Plane과 MCP 서버를 동일 클러스터에 배치하면 Kubernetes FQDN으로 내부 통신이 가능합니다

단점 및 주의사항

항목	내용	대응 방안
엔터프라이즈 라이선스 비용	`ai-rate-limiting-advanced`, `ai-mcp-oauth2` 등 핵심 플러그인은 엔터프라이즈 전용. 중견 규모 기준 연 $50,000 이상이 될 수 있습니다	LiteLLM, IBM ContextForge, Envoy AI Gateway 등 오픈소스 대안과 기능·비용을 비교한 뒤 도입을 결정하는 것을 권장합니다
Kong 3.12 이상 필수	AI MCP 플러그인은 3.12 미만에서는 지원되지 않습니다	스테이징 환경에서 버전 업그레이드를 충분히 검증한 뒤 프로덕션에 적용하는 것을 권장합니다
Stateful SSE 세션	SSE 기반 장기 연결을 올바르게 프록시하려면 세션 친화성(Session Affinity) 설정이 필요합니다	Kong의 `hash_on: consumer` 또는 `hash_on: ip` 로드밸런싱 설정으로 동일 세션이 같은 인스턴스로 라우팅되도록 구성할 수 있습니다
별도 Authorization Server 필요	Kong은 Resource Server 역할만 수행. Keycloak, Auth0, Okta 등 별도 IdP 운영이 전제 조건입니다	기존 조직의 IdP가 있다면 연동이 수월합니다. 신규 도입이라면 오픈소스 Keycloak을 함께 구성하는 방법이 있습니다
MCP Tool 실행 비용 미추적	비용 계산은 LLM Provider 응답의 토큰 수에만 의존. 외부 API 호출 등 Tool 자체 실행 비용은 별도 집계가 필요합니다	해당 서비스의 청구 데이터를 별도로 수집하고 FinOps 보고서에서 통합하는 방식을 고려할 수 있습니다
빠른 MCP 사양 변화	MCP 사양이 2025년 한 해에만 수차례 개정되었으며, Kong 플러그인의 사양 반영 속도를 지속 확인해야 합니다	Kong Gateway Changelog와 MCP 공식 사양 페이지를 정기적으로 확인하는 것을 권장합니다

Session Affinity(세션 친화성)란? 로드밸런서가 동일 클라이언트의 요청을 항상 같은 서버 인스턴스로 보내는 설정입니다. SSE처럼 연결을 유지하는 프로토콜에서는 이 설정이 없으면 연결이 끊기거나 상태가 유실될 수 있습니다.

실무에서 가장 흔한 실수

Authorization Server 없이 Kong만 배치하는 경우 — Kong의 ai-mcp-oauth2 플러그인은 토큰 검증(Resource Server)만 담당합니다. 토큰을 발급하는 Keycloak, Auth0 등의 Authorization Server가 별도로 필요하며, 이를 간과하면 인증 흐름 전체가 동작하지 않습니다.
SSE 세션에 Session Affinity를 설정하지 않는 경우 — MCP 클라이언트가 SSE로 장기 연결을 유지하는데 Kong이 기본 라운드로빈 방식으로 로드밸런싱을 하면, 같은 세션의 요청이 서로 다른 인스턴스로 분산되어 연결이 끊길 수 있습니다.
Rate Limiting을 요청 수(Request Count) 기준으로 설정하는 경우 — MCP 트래픽에서 비용은 요청 수가 아닌 토큰 소비량에 비례합니다. tokens_count_strategy: total_tokens 설정을 활용해 토큰 기반 쿼터를 적용하는 것이 실질적인 비용 통제에 효과적입니다.

마치며

지금 바로 시작할 수 있는 3단계:

Kong Gateway 3.12 설치 및 deck CLI 준비 — Kong 공식 Gateway Changelog에서 최신 버전과 설치 방법을 확인할 수 있습니다. Docker 또는 Kubernetes에 Kong 3.12를 배포한 뒤, deck gateway ping으로 연결을 확인해보는 것을 권장합니다.
GitHub MCP 서버 보안 튜토리얼 실습 — Kong 공식 문서의 "Secure GitHub MCP Server traffic with Kong Gateway" 튜토리얼을 따라가시면 OAuth 2.1 검증과 ACL 설정을 실제로 체험해볼 수 있습니다. 로컬 Keycloak과 GitHub MCP 서버를 Docker Compose로 구성하면 외부 의존 없이 전체 흐름을 테스트해볼 수 있습니다.
Prometheus + Grafana로 팀별 메트릭 시각화 — prometheus 플러그인을 활성화하고 /metrics 엔드포인트를 Grafana에 연결하면 kong_ai_llm_provider_latency_ms, kong_ai_requests_total 등 MCP 관련 메트릭을 실시간으로 확인할 수 있습니다. consumer_group 레이블로 필터링하면 팀별 토큰 소비 현황을 대시보드로 구성하는 데 도움이 됩니다.