2025년 5월에 보안 회사인 인베리언트 랩스(Invariant Labs)는 깃허브(GitHub) 공개 저장소에 올린 이슈로 AI 에이전트가 같은 사용자의 비공개 저장소 내용을 유출하게 만들 수 있다는 것을 공개했습니다. 이때 에이전트는 GitHub MCP(Model Context Protocol) 서버의 도구를 허용된 권한 안에서 호출했을 뿐이고 서버 코드에도 버그가 없었기 때문에 인베리언트 랩스는 깃허브가 서버 쪽만 수정해서는 이 공격을 막을 수 없고 에이전트 시스템 수준에서 다뤄야 한다는 결론을 내렸습니다.

그렇다면 에이전트가 도구를 호출하는 지점에 놓이는 게이트웨이(gateway)는 에이전틱 AI 세계에서 어떤 의미를 가질까요? 이 글에서는 에이전트를 실제 업무에 연결하려는 분들을 위해 시장과 에이전틱 AI 재단(AAIF, Agentic AI Foundation)의 움직임을 살펴보고 재단의 게이트웨이 2개를 직접 설치해서 확인한 결과를 바탕으로 언제 게이트웨이를 고민하면 좋을지 정리해 보겠습니다.

[노트] 전체 내용은 어디에서 볼 수 있나요?
요즘IT에 기고한 글을 블로그에 맞게 줄여서 다시 작성했습니다. 줄인 사례와 게이트웨이 비교 표까지 담긴 전체 내용은 요즘IT에서 보실 수 있습니다.

에이전트의 연결 지점에 제품이 계속 나오는 이유

최근 1년 남짓 사이에 에이전트가 모델, 도구 그리고 다른 에이전트를 호출하는 지점을 다루는 제품이 계속 나왔습니다. 예를 들어 콩(Kong)의 Kong AI Gateway 2.0, AWS의 Amazon Bedrock AgentCore Gateway 그리고 구글(Google)의 Agent Gateway가 정식으로 출시되었습니다. 국내에서는 KT DS가 API 게이트웨이인 BEAST에 AI 게이트웨이 기능을 넣었고 삼성SDS도 2026년 10월 출시를 예고한 AI 플랫폼인 FabriX 2.0에 같은 기능을 추가한다고 밝혔습니다. 이 흐름을 인수 소식과 에이전틱 AI 재단의 주요 사건까지 포함해 정리하면 다음과 같습니다.

에이전트 게이트웨이 시장과 에이전틱 AI 재단의 주요 사건을 시간순으로 놓은 연표
[그림 1] 에이전트 게이트웨이 시장과 에이전틱 AI 재단의 주요 사건

이렇게 여러 회사가 같은 지점에 관심을 보이는 것은 이곳을 거쳐 가는 호출이 빠르게 늘었는데 관리할 체계는 아직 갖춰지지 않았기 때문입니다. 에이전틱 AI 재단의 발표에 따르면 ChatGPT 사용자가 MCP 도구를 호출한 횟수는 2026년 8월에 1월의 98배가 되었다고 합니다. 그에 비해 딜로이트(Deloitte)의 24개국 조사에서 자율적으로 동작하는 에이전트를 관리할 성숙한 체계를 갖췄다는 곳은 21%였습니다. 게이트웨이를 직접 만드는 회사도 있는데 우버(Uber)는 10월에 MCP 서버 800개 이상을 사내 MCP 게이트웨이로 묶은 과정을 공개했습니다.

이러한 게이트웨이의 역할은 MCP 서버를 수정하지 않고도 누가 어떤 도구를 호출할 수 있는지 정하고 그 호출을 기록하는 것입니다. MCP 서버가 팀마다 생기면 클라이언트 설정과 권한을 서버마다 따로 다뤄야 하지만 게이트웨이를 1개 두면 통제와 그에 따른 기록을 한곳에서 관리할 수 있습니다. 이 구조를 그림으로 표현하면 다음과 같습니다.

게이트웨이가 없을 때는 에이전트가 MCP 서버마다 따로 연결하고 게이트웨이가 있을 때는 게이트웨이 1개에 연결하는 구조
[그림 2] 게이트웨이가 없을 때와 있을 때의 MCP 서버 연결 구조

마이크로서비스 때와 비교

사실 호출이 거쳐 가는 곳에 공통 계층을 두는 흐름은 마이크로서비스 때도 있었고 서비스마다 넣던 인증과 관측을 서비스 밖의 API 게이트웨이와 서비스 메시(service mesh)에서 처리하게 되었습니다. 다만 게이트웨이인 agentgateway를 만든 솔로닷아이오(Solo.io)의 램 베남(Ram Vennam)은 에이전트가 같은 요청에도 매번 다른 도구를 다른 순서로 호출할 수 있다는 점에서 예측 가능성에 차이가 있다고 설명했습니다. 따라서 미리 정해 둔 호출만 허용하기보다 호출이 있을 때마다 확인하고 기록하는 일이 더 중요해집니다.

이 지점을 다루는 표준은 이제 막 만들어지기 시작했지만 프로토콜은 먼저 바뀌고 있습니다. 2026년 7월에 개정된 MCP 스펙에서는 메서드와 도구 이름을 요청 헤더에 넣도록 했는데, 게이트웨이 같은 중간 계층이 본문을 해석하지 않고도 요청을 확인할 수 있게 하려는 것이라고 스펙 문서에 적혀 있습니다.

에이전틱 AI 재단이 키우려는 생태계

우선 CNCF(Cloud Native Computing Foundation)는 2015년 7월에 구글이 쿠버네티스(Kubernetes)를 기부하면서 만들어졌습니다. 그 뒤로 쿠버네티스를 중심으로 프로젝트가 차례로 더해져 2026년 10월 기준 호스티드 프로젝트(hosted project, 재단이 상표와 저장소를 넘겨받아 중립적으로 관리하는 프로젝트)는 230개, 회원사는 723곳입니다.

에이전틱 AI 재단도 2025년 12월에 앤트로픽(Anthropic)의 MCP, 블록(Block)의 goose 그리고 오픈AI(OpenAI)의 AGENTS.md를 창립 프로젝트로 두고 같은 방식으로 출범했고 2026년 8월에는 구글이 시작한 A2A(Agent2Agent)도 호스티드 프로젝트가 되었습니다. 2026년 10월 기준 회원사가 270곳인 이 재단과 CNCF의 구성을 비교하면 다음과 같습니다.

CNCF와 에이전틱 AI 재단을 출범, 중심이 되는 프로젝트, 트래픽을 다루는 계층, 그 밖의 대표 프로젝트 그리고 지금의 규모로 나누어 비교한 표
[그림 3] CNCF와 에이전틱 AI 재단의 생태계 구성 비교

그림에서 트래픽을 다루는 계층에 해당하는 게이트웨이도 이 재단에 2개가 있습니다. 솔로닷아이오의 agentgateway가 2026년 6월에 호스티드 프로젝트로 받아들여졌고 블룸버그(Bloomberg)와 테트레이트(Tetrate)가 프록시인 Envoy의 하위 프로젝트로 시작한 Envoy AI Gateway도 2026년 8월 재단 이사회 승인을 거친 뒤 9월에 Agent Router로 이름을 바꿨습니다. 솔로닷아이오와 테트레이트 모두 상용 제품을 따로 팔면서도 오픈 소스는 중립적인 재단에 기부했다는 점에서 저는 이 지점을 두고 벌어지는 경쟁이 매우 치열하다고 생각합니다. 한편 재단 쪽에서 보면 CNCF에서 Envoy가 여러 게이트웨이의 공통 바탕이 되었던 것처럼 MCP와 A2A에 더해 트래픽을 다루는 계층까지 함께 키우려는 것으로 보입니다.

agentgateway와 Agent Router를 직접 설치해서 확인한 것

그러면 실제로 사용해 보면 어떨까요? 쿠버네티스 클러스터에 각각 설치하고 정책을 걸어 가며 호출해 봤는데, 결론부터 말씀드리면 확인한 버전(agentgateway v1.5.0, Agent Router v1.1.0)에서는 통제하는 범위가 서로 달랐습니다. 도구 이름 단위로 차단하는 정책은 양쪽 모두 설정한 대로 동작했지만 호출할 때 넘긴 값을 조건으로 지정한 정책은 Agent Router에서는 인가(authorization, 누가 무엇을 해도 되는지 판단하는 것) 정책만으로 처리할 수 있었고 agentgateway v1.5.0에서는 외부 검사 서버가 따로 필요했습니다. 그리고 사용자가 주로 보는 설정 문서에는 특별한 문제에 대해 언급은 없으나, 이러한 정책을 넣으면 에이전트가 받는 도구 목록이 빈 채로 돌아오는 경우도 있었습니다. 그 뒤 2026년 10월 2일에 나온 agentgateway v1.6.0에서는 라우트 단위 인가 정책으로 넘긴 값 조건을 적용할 수 있게 되어 외부 검사 서버 없이도 막아야 할 호출만 차단되는 것을 다시 확인했습니다.

또한 게이트웨이를 거치면서 늘어난 시간(게이트웨이 없이 직접 호출한 경우와 비교한 중간값)은 agentgateway가 도구 호출당 1ms 아래였고 Agent Router는 기본 설정에서 약 20ms였습니다. 이 20ms는 대부분 세션 암호화 반복 횟수의 기본값에서 나왔고 이 값을 낮추자 약 0.5ms로 줄었습니다. 다만 각 게이트웨이를 따로 측정한 값이라 양쪽을 같은 조건에서 비교한 것은 아닙니다. 측정 조건과 항목별 결과는 agentgateway 글과 Agent Router 글에 정리해 두었으니 참고하시기 바랍니다.

게이트웨이를 고민하면 좋은 시점

그럼 언제 게이트웨이를 고민하면 될까요? MCP 서버가 여럿이 되어 누가 무엇을 호출할 수 있는지를 서버마다 관리하기 어려워졌다면 검토해 보시면 됩니다. 반대로 MCP 서버가 1개뿐이거나 도구 이름 단위로 차단하는 것으로 충분하다면 넣을 필요는 없습니다. 이번에 확인한 게이트웨이를 거쳐도 호출이 빨라지지는 않았고 지연 시간만 늘었기 때문입니다.

도입하기로 하셨다면 정책을 넣은 뒤에 에이전트가 받는 도구 목록이 비어 있지 않은지, 차단하려던 호출이 실제로 차단되는지 그리고 기본값으로 둔 설정이 운영 환경에 맞는지를 직접 확인해 보시는 게 좋을 것 같습니다. 특히 세션 암호화 반복 횟수처럼 보안과 관련된 기본값은 무조건 낮추기보다 정해진 이유부터 살펴보셔야 합니다.

마치며

처음 질문으로 돌아가면, 제가 확인한 범위에서 에이전틱 AI 세계의 게이트웨이는 에이전트가 많아질수록 함께 늘어나는 호출을 서버마다 수정하지 않고도 한곳에서 통제하고 기록할 수 있게 해 주는 계층입니다. 여러 회사가 제품을 내놓고 에이전틱 AI 재단이 게이트웨이 프로젝트를 2개나 받아들인 이유도 여기에 있다고 생각합니다. 하지만 표준은 아직 자리 잡지 않았고 같은 재단의 게이트웨이끼리도 통제하는 범위와 기본값이 달랐으므로, 에이전틱 AI 재단이 CNCF처럼 MCP와 A2A를 중심으로 이 계층을 어떻게 키워 갈지 계속 지켜보시면 좋을 것 같습니다.

끝으로 저는 에이전틱 AI 재단의 앰버서더로 활동하고 있고 agentgateway와 Agent Router는 이 재단의 프로젝트입니다. 그런 만큼 좋은 점만 소개하기보다 문서에 적힌 대로 동작하지 않는 부분까지 직접 확인해서 담았습니다. 이 글이 에이전트를 실제 업무에 연결하려는 분들께 조금이나마 도움이 되었으면 좋겠습니다.

참고 자료