기업의 AI 트래픽은 LLM 호출 한 가지로 구성되지 않습니다. 여러 프로바이더의 모델을 함께 쓰고, MCP(Model Context Protocol) 서버를 통해 사내 도구와 데이터를 연결하며, 에이전트가 다른 에이전트를 호출하는 흐름까지 더해집니다. 연결 대상이 늘어날수록 인증, 접근 통제, 비용 귀속, 로깅을 어디에서 처리할지가 운영의 과제로 남습니다.
콩(Kong)은 2026년 7월 16일 AI Gateway 2.0을 비공개 베타로 공개했고, 9월 1일 정식 출시를 발표했습니다. 이번 릴리스로 AI 게이트웨이는 Kong API Gateway 안의 기능 집합이 아니라 자체 런타임과 컨트롤 플레인, 자체 관리 API를 갖는 별도 제품이 됐습니다. 이 글에서는 Kong AI Gateway가 어떤 제품이고, 2.0에서 설정 방식이 어떻게 바뀌었으며, 새로 추가된 기능이 무엇인지, 기존 환경에서 전환을 검토할 때 확인해야 할 조건은 무엇인지 정리합니다.
☑️ Kong AI Gateway 2.0은 무엇인가
Kong AI Gateway는 애플리케이션과 LLM, MCP 서버, AI 에이전트 사이에 위치해 AI 트래픽의 라우팅, 인증, 접근 통제, 비용 관리, 관측을 하나의 계층에서 처리하는 AI 연결·거버넌스 제품입니다. AI Gateway 2.0은 이 제품이 Kong API Gateway의 플러그인 묶음에서 벗어나 전용 런타임과 전용 컨트롤 플레인, 자체 관리 API와 자체 버전 체계를 갖게 된 릴리스이며, 2026년 9월 1일 정식 출시되어 Kong Konnect에서 별도의 베타 활성화 없이 사용할 수 있습니다.
기존과 달라진 지점은 관리 단위입니다. 모델과 MCP 서버, 에이전트를 설정 화면과 관리 API에서 각각 독립된 관리 대상으로 다룹니다. 서비스와 라우트를 만들고 플러그인을 붙여 AI 동작을 구성하는 방식이 아니라, 필요한 AI 리소스를 선언하면 컨트롤 플레인이 하위 구성을 대신 생성하는 방식입니다.
☑️ AI 게이트웨이가 별도 제품으로 분리된 이유
Kong AI Gateway는 출시 이후 Kong API Gateway의 일부로 배포되어 왔습니다. LLM 라우팅, 프롬프트 가드, 시맨틱 캐싱, 토큰 기반 요청 제한 같은 기능이 모두 API 게이트웨이와 같은 릴리스 일정을 따랐습니다.
분리의 배경은 두 워크로드의 변화 속도 차이입니다. 미션 크리티컬한 API 인프라는 안정성을 우선한 보수적인 릴리스 주기가 요구되는 반면, 새로운 모델 프로바이더가 계속 등장하고 MCP나 A2A 같은 프로토콜이 진행 중에 바뀌는 AI 환경은 주 단위로 움직입니다. 하나의 코드베이스로 두 주기를 모두 맞추기는 어렵다는 것이 분리의 이유입니다.
그 결과 AI Gateway는 자체 런타임과 컨트롤 플레인, 자체 관리 API를 갖고 2.0부터 독립된 버전 체계로 이동했습니다. Kong Gateway는 검증된 안정성 중심의 주기를 그대로 유지하고, AI Gateway는 AI 생태계 속도에 맞춰 별도로 배포됩니다. 거버넌스 운영 모델은 하나로 유지하면서 릴리스 주기만 워크로드에 맞게 나눈 구조입니다.
☑️ 플러그인에서 AI 엔티티로 바뀐 설정 방식
Kong AI Gateway 2.0에서 달라진 부분은 설정 방식입니다.
Kong Gateway 위에서 동작하던 방식에서는 AI 기능이 세 개의 프록시 플러그인으로 제공됐습니다. AI Proxy Advanced가 모델 프록시와 변환, 프로바이더·모델 간 로드 밸런싱을 담당하고, AI MCP Proxy가 Kong이 관리하는 서비스를 MCP로 연결하거나 상위 MCP 서버 앞단에 위치했으며, AI A2A Proxy가 에이전트 간 프로토콜 트래픽에 대한 관측과 통제를 맡았습니다. 이 구조에서는 서비스와 라우트를 먼저 만들고 플러그인을 붙여야 했고, 논리적으로 모델 하나를 정의하는 데 서비스와 라우트, AI Proxy Advanced 플러그인, 여러 보조 플러그인이 함께 필요했습니다. AI 관련 설정이 여러 개체에 나뉘어 들어가는 구조였습니다.
AI Gateway 2.0은 이 플러그인들을 전용 엔티티 모델로 추상화했습니다. 서비스나 라우트에 붙이던 AI Proxy Advanced는 AI Model 엔티티가 되어, 가상 모델 하나당 하나의 엔티티를 두고 그 안에 하나 이상의 타깃을 정의합니다. 플러그인 설정에 인라인으로 넣던 프로바이더 자격 증명은 AI Model Provider라는 재사용 가능한 엔티티로 분리되어, 프로바이더를 한 번 선언해 두고 여러 AI Model에서 이름으로 참조하게 됩니다. 기존의 route_type 설정은 capabilities 배열과 formats의 type으로 나뉩니다.
AI MCP Proxy는 AI MCP Server 엔티티가 됩니다. 플러그인의 각 모드가 그대로 type 값으로 대응되며 upstream-server라는 새 유형이 추가됐고, 플러그인 설정에 있던 default_acl과 tools.acl은 AI MCP Server의 access 또는 tools.access 필드로 올라와 접근 제어 목록이 엔티티의 기본 설정 항목이 됩니다. AI A2A Proxy는 AI Agent 엔티티가 되며 URL 재작성과 A2A 분석이 기본 제공됩니다.
플러그인 자체는 AI Policy로 대체됩니다. 각 정책에는 type 필드가 있고 이 값이 기존 플러그인에 대응하며 설정 내용은 동일합니다. 컨슈머와 컨슈머 그룹은 AI Consumer와 AI Consumer Group으로, Vault는 AI Vault와 AI Data Plane Certificates로 컨트롤 플레인에서 관리되고, 볼트 참조 문법은 기존과 같은 형식을 유지합니다.
기존에 쓰던 기능은 그대로 이어집니다. 로드 밸런싱 알고리즘은 동일하게 제공되고, 시맨틱 캐싱의 Redis와 pgvector 전략도 같은 방식으로 유지됩니다. 달라진 것은 이를 선언하는 단위입니다.
☑️ Kong AI Gateway 2.0에 새로 추가된 5가지 기능
AI 트래픽 전용 런타임과 컨트롤 플레인, Konnect 사용 환경에 더해 이번 정식 출시에는 다음 다섯 가지가 새로 포함됐습니다.
1. MCP 서버 번들링
에이전트를 운영 환경에 올리면 에이전트마다, LLM 애플리케이션마다, MCP 클라이언트마다 늘어나는 MCP 서버를 각각 설정해야 하는 문제가 생깁니다. 서버마다 엔드포인트가 다르고 핸드셰이크가 다르며 접근 권한 체계도 제각각입니다. 팀 단위로 늘어나면 MCP 연결 자체가 플랫폼 팀의 상시 업무가 됩니다.
MCP Server Bundling은 이 구성을 하나의 접점으로 모읍니다. 사용자나 LLM, 에이전트가 Kong 라우트 하나에 연결하면 MCP 도구 호출에 사용되는 JSON-RPC 전체가 그 경로를 지나고, Kong이 해당 라우트 뒤에서 MCP 핸드셰이크를 처리한 뒤 매핑된 상위 MCP 서버 전체에 tools/list를 실행한 결과를 하나의 통합 도구 카탈로그로 제시합니다.
여기서 중요한 부분은 카탈로그에 무엇이 담기는가입니다. 번들링은 MCP ACL 플러그인과 연동되어 있어 게이트웨이는 각 호출자가 조회하고 실행할 권한이 있는 도구만 노출합니다. 같은 번들 라우트에 연결해도 호출자가 다르면 서로 다른 도구 목록을 받습니다. 인가되지 않은 도구는 실행 단계에서 차단되는 것이 아니라 도구 목록을 조회하는 단계에서부터 보이지 않으므로, 에이전트가 인식하고 판단 대상으로 삼을 수 있는 범위 자체가 줄어듭니다. 에이전트가 침해된 경우에도 마찬가지입니다.
플랫폼 팀 관점에서 이 구조는 MCP 거버넌스를 API 거버넌스와 같은 방식으로 다룰 수 있게 합니다. 게시할 엔드포인트가 하나이고, 정책을 적용하는 지점이 하나이며, 호출자별 접근 통제가 클라이언트마다의 설정 상태에 좌우되지 않습니다.
2. 모달리티 단위 비용 관리
AI 비용 관리는 게이트웨이가 인식하는 과금 모델이 실제 프로바이더의 과금 모델보다 단순할 때 무너집니다. 최근 모델은 토큰 단위로만 과금하지 않습니다. 텍스트와 오디오, 이미지, 비디오의 단가가 다르고, 캐시 읽기와 캐시 쓰기의 단가가 다르며, 실시간 요청과 표준 요청의 단가도 다릅니다. 게이트웨이가 입력과 출력 비용만 단일하게 추적한다면 비용 귀속 결과는 실제와 어긋납니다.
이번 릴리스에서 ai-proxy-advanced에 동적 모달리티 인식 LLM 프라이싱이 추가됐습니다. 가격 정보를 한 번 정의해 두고 Konnect 프라이싱 카탈로그를 통해 여러 설정에서 재사용하는 방식으로, 카탈로그는 텍스트와 오디오, 이미지, 비디오의 가격 항목과 캐시 읽기, 캐시 쓰기 항목을 지원하며 동일한 카탈로그 항목이 실시간 요청과 표준 멀티모달 요청에 함께 적용됩니다.
우선순위는 기본값이 정해져 있습니다. 카탈로그가 공통 기준선 역할을 하고, 타깃별로 설정한 model.options의 input_cost와 output_cost가 기본적으로 우선하며, 카탈로그 항목별로 이 순서를 뒤집는 재정의 옵션을 선택적으로 켤 수 있습니다. 중앙 플랫폼 팀이 가격 기준을 관리하면서도 개별 팀이 자기 배포 환경에 맞게 값을 조정할 수 있는 구조입니다.
이 구성은 게이트웨이의 비용 분석과 토큰 기반 정책이 참조하는 가격 정보를 하나의 기준으로 관리하게 합니다.
3. 모델과 프로바이더 지원 확대
AI 게이트웨이의 활용 범위는 연결할 수 있는 모델과 플랫폼의 범위에 따라 결정됩니다. 이번 릴리스에서는 Kimi와 Microsoft Foundry, Amazon SageMaker가 지원 대상에 추가됐습니다.
Kimi는 네이티브로 지원되며, AI Gateway의 정책은 다른 프로바이더와 마찬가지로 Kimi 트래픽에도 동일하게 적용됩니다.
Microsoft Foundry는 마이크로소프트가 Azure OpenAI Service와 Azure AI Studio, Azure AI Services를 통합한 플랫폼으로, services.ai.azure.com 엔드포인트에서 경로 프리픽스 라우팅으로 여러 모델 계열을 제공합니다. OpenAI 호환 배포는 /openai/v1/ 경로를, Claude 배포는 /anthropic/v1/messages 경로를 사용합니다. Kong의 Azure 프로바이더는 기존 Azure OpenAI URL 구조를 기준으로 만들어져 있었고 Foundry 엔드포인트는 임시 우회 방식으로 연결됐는데, 이 방식은 모델 이름에서 형식을 유추하는 구조여서 오설정이 발생하기 쉬웠습니다. 이번 릴리스는 이를 스키마 검증이 적용된 azure_service 셀렉터로 대체하고 전송 형식을 설정된 경로 프리픽스에서 결정하도록 바꿨으며, Foundry를 통해 제공되는 Claude 모델도 지원 대상에 포함됩니다.
AWS 환경을 중심으로 구성된 조직 다수는 Amazon SageMaker에서 파운데이션 모델을 서빙합니다. TGI와 TEI, HuggingFace Inference, LMI(vLLM/DJL)를 포함한 ECR 추론 컨테이너 전반이 지원 대상입니다. SageMaker 전용 포맷을 새로 만드는 대신 애플리케이션이 보내는 요청을 OpenAI 형식으로 표준화하고 대상 컨테이너가 지원하는 경우 내부적으로 HuggingFace 형식으로 변환하는 방식이어서, 애플리케이션을 OpenAI 호환 호출로 구성해 둔 환경이라면 코드 변경 없이 SageMaker에서 서빙되는 모델에 연결할 수 있고 다른 프로바이더와 동일한 거버넌스가 적용됩니다.
4. Kong Identity Principal 기반 정책
Kong Identity는 여러 게이트웨이에서 공유되고 자체 메타데이터를 갖는 인증 주체로 Principal을 도입했습니다. Principal은 개별 게이트웨이가 아니라 중앙에서 정의합니다. 이번 릴리스에서 이 개념이 AI Gateway에 적용됩니다.
기존에는 AI Gateway 정책이 호출자를 컨슈머로만 식별했습니다. 컨슈머는 게이트웨이 단위 개념이어서 조직 전체에 걸친 아이덴티티를 담지 못했습니다. 이제 AI Gateway는 Principal을 인식하며, 요청 제한과 분석, 비용 귀속, 모델과 라우트 접근 제어를 컨슈머가 아니라 인증된 Principal 기준으로 적용할 수 있습니다.
에이전트 환경에서는 이 구분의 의미가 커집니다. 호출 주체가 사용자나 팀, 다른 시스템을 대신해 동작하는 에이전트일 때 누가 이 호출을 하고 있는가는 비용 쇼백과 접근 판단, 감사 추적 모두에서 기준이 되는 정보이기 때문입니다. Principal을 기준으로 삼으면 Kong 환경 전체에서 동일한 아이덴티티 정의를 사용해 이 질문에 답할 수 있습니다.
이 기능은 기존 설정에 더해지는 방식이며 기본적으로 비활성 상태입니다. 기존의 컨슈머 기반 설정은 그대로 동작하고, 필요한 지점부터 Principal을 적용하는 방식으로 도입할 수 있습니다.
5. Bedrock AgentCore 대상 AWS IAM 인증
ai-a2a-proxy와 ai-mcp-proxy 플러그인에는 AWS에서 호스팅되는 Bedrock AgentCore 에이전트나 MCP 서버로 나가는 요청을 인증하는 내장 수단이 없었습니다. 그래서 요청 서명을 위해 pre-function을 직접 작성하는 방식이 사용됐습니다.
이번 릴리스는 플러그인에 종속되지 않는 업스트림 인증 프레임워크를 도입하고, AgentCore 엔드포인트를 대상으로 AWS SigV4(IAM) 인증을 두 플러그인에 연결했습니다. 운영자는 AgentCore 에이전트와 MCP 서버에 대한 인증을 선언적으로 구성할 수 있으며, 자격 증명은 플랫폼의 다른 자격 증명과 동일한 방식으로 처리됩니다.
☑️ 기존 환경에서 전환을 검토할 때 확인할 조건
정식 출시는 Kong AI Gateway 2.0이 프로덕션 지원 대상이 되었다는 의미이며, Kong이 제공하는 컴플라이언스 및 지원 체계가 적용됩니다.
현재 Kong Gateway에서 AI Gateway 플러그인을 운영하고 있다면 기존 구현은 그대로 동작합니다. AI 플러그인은 LTS 릴리스인 Kong Gateway 3.14에서 계속 지원되며, 기준이 되는 시점은 Kong Gateway 3.18입니다. 이 릴리스부터 AI 플러그인이 기본 번들에서 제외되고 필요한 경우 선택해 사용하는 방식으로 바뀌므로, 그 이전에 마이그레이션을 계획하는 것이 권고되고 있습니다.
마이그레이션 도구는 이미 제공되고 있습니다. kongctl이 기존 decK 설정을 AI Gateway 2.0 네이티브 설정으로 변환하며, kongctl을 통해 2.0 설정을 선언적으로 관리할 수 있어 기존 GitOps 워크플로에 그대로 연결됩니다. 환경의 decK 덤프를 기준으로 Kong 계정 팀이 마이그레이션을 직접 수행하는 방식도 함께 제공됩니다.
☑️ 자주 묻는 질문
Kong AI Gateway 2.0은 무엇인가요?
Kong AI Gateway 2.0은 AI 트래픽을 위한 전용 런타임과 컨트롤 플레인, 자체 관리 API를 갖춘 AI 게이트웨이 제품입니다. 2026년 9월 1일 정식 출시됐으며 Kong Konnect에서 별도의 베타 활성화 없이 사용할 수 있습니다. 모델과 MCP 서버, 에이전트를 각각 독립된 관리 대상으로 다룹니다.
기존 AI Gateway 플러그인을 쓰고 있으면 지금 바로 옮겨야 하나요?
그렇지 않습니다. Kong Gateway에서 운영 중인 구현은 그대로 동작하며, AI 플러그인은 LTS 릴리스인 3.14에서 계속 지원됩니다. 다만 3.18부터 AI 플러그인이 기본 번들에서 제외되고 선택 적용 방식으로 바뀌므로 그 이전에 전환을 계획하는 것이 권고되고 있습니다.
MCP Server Bundling은 어떤 문제를 해결하나요?
여러 MCP 서버를 클라이언트마다 개별 설정해야 하는 문제를 해결합니다. 하나의 Kong 라우트로 연결하면 Kong이 상위 MCP 서버 전체의 도구 목록을 조회해 통합 카탈로그로 제시하며, MCP ACL과 연동되어 호출자가 인가받은 도구만 목록에 나타납니다.
컨슈머와 Principal은 무엇이 다른가요?
컨슈머는 게이트웨이 단위 개념이고 Principal은 중앙에서 정의해 여러 게이트웨이가 함께 사용하는 인증 주체입니다. Principal을 기준으로 하면 요청 제한과 비용 귀속, 접근 제어를 조직 전체에 걸쳐 동일한 아이덴티티 정의로 적용할 수 있습니다. 기본은 비활성 상태이며 기존 컨슈머 기반 설정은 그대로 유지됩니다.
AI Gateway 2.0 설정은 어떻게 관리하나요?
kongctl을 통해 선언적으로 관리할 수 있어 기존 GitOps 워크플로에 그대로 연결됩니다. kongctl은 마이그레이션 도구이기도 해서, 기존 decK 설정을 AI Gateway 2.0 네이티브 설정으로 변환합니다.
☑️ 마무리
Kong AI Gateway 2.0은 AI 게이트웨이를 API 게이트웨이의 기능 집합에서 분리해 자체 런타임과 릴리스 주기를 갖는 제품으로 재정의한 릴리스입니다. 설정 단위가 플러그인에서 AI Model, AI Model Provider, AI MCP Server, AI Agent 같은 엔티티로 바뀌었고, 정식 출시와 함께 MCP 서버 번들링과 모달리티 단위 비용 관리, 프로바이더 지원 확대, Principal 기반 정책, AgentCore 대상 IAM 인증이 추가됐습니다.
도입이나 전환을 검토한다면 확인할 항목은 다음과 같습니다. 현재 사용 중인 모델과 프로바이더, MCP 서버가 어디까지 지원 범위에 들어오는지, 호출자별 도구 접근 통제를 어떤 아이덴티티 기준으로 설계할지, 기존 Kong Gateway 환경에서 운영 중인 AI 플러그인 구성을 언제 전환할지가 출발점이 됩니다.
클라우드네트웍스는 고객 환경의 AI 트래픽 구성과 MCP 서버 현황을 확인하고, Kong AI Gateway 기준으로 적용 범위와 배포 형태를 검토하는 과정부터 구축까지 지원합니다. AI 게이트웨이 도입이나 기존 환경의 전환을 검토하고 계시다면 클라우드네트웍스로 문의해 주시기 바랍니다.
▶ Kong AI Gateway 자세히보기
[출처 : Kong, "Kong AI Gateway 2.0 Is Now GA — And It's Already Moving Faster", https://konghq.com/blog/product-releases/kong-ai-gateway-2-0-ga, Kong, "Announcing Kong AI Gateway 2.0: Built for the Pace of Agentic AI", https://konghq.com/blog/product-releases/kong-ai-gateway-2-0-agentic-ai, Kong, "AI Gateway 2.x concepts", https://developer.konghq.com/ai-gateway/ai-gateway-v2-concepts/]
