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

그렇다면 에이전트와 도구 사이, 다시 말해 에이전트가 도구를 호출할 때 그 요청이 거쳐 가는 지점에서는 무엇을 할 수 있을까요? 그리고 에이전틱 AI 세계에서 그 지점에 놓이는 게이트웨이(gateway)는 어떤 의미를 가질까요?

이 글에서는 에이전트를 실제 업무에 연결하려는 분들이 언제 게이트웨이를 고민하면 좋을지 판단하는 데 도움이 되도록 이 질문의 답을 차례로 찾아보겠습니다. 먼저 1) 여러 회사가 왜 지금 이 지점에 제품을 내놓는지 보고, 이 흐름이 마이크로서비스 때와 어디가 같고 어디는 다른지 살펴봅니다. 이어서 2) 에이전틱 AI 재단(AAIF, Agentic AI Foundation)이 이 영역을 어떻게 키우려 하는지, CNCF(Cloud Native Computing Foundation)가 쿠버네티스 생태계를 키운 과정과 비교해 보겠습니다. 마지막으로 3) 재단의 게이트웨이 2개를 직접 설치해 확인한 결과를 바탕으로 언제 게이트웨이를 고민하면 좋을지 정리하겠습니다.

여러 회사가 에이전트의 연결 지점에 제품을 내놓는 이유

최근 1년 사이에 에이전트가 모델과 도구, 그리고 다른 에이전트를 호출하는 지점에 놓이는 제품이 계속 나오고 있습니다.

쉴새없이 커지는 에이전트 게이트웨이 시장

API 게이트웨이를 만드는 콩(Kong)은 2026년 9월 1일에 LLM 호출과 MCP 도구 호출, 에이전트끼리 주고받는 A2A(Agent2Agent) 요청을 한 제품에서 다루는 Kong AI Gateway 2.0을 정식으로 내놓았습니다. AWS는 2025년 10월에 Amazon Bedrock AgentCore Gateway를, 구글(Google)은 2026년 6월에 Agent Gateway를 정식 출시했습니다. 인증 회사인 옥타(Okta)도 2026년 9월에 에이전트와 도구 호출 사이에 놓이는 Agent Gateway를 발표했습니다.

국내에서는 KT DS가 자사 API 게이트웨이인 BEAST에 AI 게이트웨이 기능을 넣었고, 삼성SDS는 2026년 10월 출시 예정인 패브릭스(FabriX) 2.0에 AI 게이트웨이와 스마트 라우터 기능을 넣는다고 합니다.

인수도 이어졌습니다. 보안 회사 팔로알토 네트웍스(Palo Alto Networks)는 AI 게이트웨이를 만드는 Portkey를 약 1억 1,700만 달러(한화 약 1,560억 원)에 인수했고, 스트라이프(Stripe)는 여러 모델로 LLM 호출을 나눠 보내는 OpenRouter를 인수하기로 했습니다.

이처럼 에이전트 게이트웨이 업계에서 생겨난 쉴새없는 흐름을 에이전틱 AI 재단과 이 글에서 다룰 두 게이트웨이의 주요 사건과 함께 시간순으로 정리하면 다음과 같습니다.

2024년 10월 블룸버그·테트레이트의 Envoy AI Gateway 시작부터 2026년 10월 삼성SDS 패브릭스 2.0 예정까지, 솔로닷아이오·GitHub·KT DS·AWS·agentgateway 리눅스 재단 기부·AAIF 출범·구글·팔로알토·스트라이프·콩·옥타 등 에이전트 게이트웨이 시장과 에이전틱 AI 재단(AAIF) 주요 사건을 시간순으로 나열한 타임라인 — 에이전트 게이트웨이 시장과 에이전틱 AI 재단의 주요 사건 <출처: 작가>

왜 모두가 에이전트 게이트웨이에 관심을 가질까?

이렇게 많은 회사가 같은 지점에 관심을 보이는 이유가 있습니다. 이 지점을 지나가는 호출이 정말 빠르게 늘었는데, 그 호출을 관리할 체계는 아직 갖춰지지 않았기 때문입니다.

에이전틱 AI 재단의 발표에 따르면 ChatGPT 사용자가 MCP 도구를 호출한 횟수는 2026년 8월, 1월의 98배로 늘었습니다. 호출을 받는 서버 쪽도 비슷합니다. 보안 회사 트렌드마이크로(Trend Micro)가 인터넷에 노출된 MCP 서버를 다시 세어 보니, 2025년 7월 492개에서 2026년 4월 1,467개로 약 3배 가까이 늘었다고 합니다.

반면 관리 체계는 턱없이 부족합니다. 딜로이트(Deloitte)가 24개국 3,235명에게 물어 보니, 2년 안에 에이전틱 AI를 쓰겠다는 곳은 74%였지만, 자율적으로 동작하는 에이전트를 관리할 성숙한 체계를 갖췄다는 곳은 21%에 그쳤습니다.

제품을 사서 쓰는 대신 직접 만드는 회사도 있습니다. 우버(Uber)는 2026년 10월 1일에 사내 MCP 게이트웨이를 설계한 과정을 엔지니어링 블로그에 공개했습니다. MCP 서버 800개 이상과 도구 5,000개 이상을 게이트웨이 하나로 묶은 사례입니다. 만든 이유는 팀마다 따로 연결을 만들다 보니 도구가 흩어지고 같은 인프라가 중복됐기 때문이라고 설명했습니다. 이 게이트웨이에서는 새로 찾은 도구도 꺼진 상태로 등록되고, 그 도구를 소유한 팀이 켜야 에이전트에 보입니다.

도어대시(DoorDash)도 7월에 MCP 서버 200개 이상을 연결하는 에이전트 게이트웨이를 만든 과정을 공개하면서, MCP는 호출하는 방법을 정해 줄 뿐 누가 무엇을 해도 되는지까지 정해 주지는 않는다고 정리했습니다.

오픈 소스 쪽에서도 같은 흐름이 보입니다. 깃허브에서 이름이나 설명에 “MCP gateway”가 들어간 저장소는 2024년 3개에서 2025년 306개, 2026년에는 9월까지만 1,764개까지 새로 생겼습니다. 대부분은 개인이 실험 삼아 만든 저장소라 시장 규모로 읽을 수는 없지만, 이 지점에 대한 관심이 늘어나는 속도는 확인할 수 있습니다.

GitHub에서 설명·이름에 MCP gateway, agent gateway가 들어간 신규 저장소 수를 월별 막대그래프로 나타낸 그래프: MCP gateway는 2024년 3개에서 2025년 306개, 2026년 1~9월 1,764개로 급증하고 agent gateway도 함께 늘어나는 추세 — 깃허브에 새로 만들어진 MCP 게이트웨이와 에이전트 게이트웨이 저장소 수 <출처: 작가>

에이전트 게이트웨이가 필요한 진짜 이유

에이전틱 AI 재단은 이 상황을 조금 다르게 설명합니다. 이를테면 블룸버그(Bloomberg) 엔지니어들이 외부 모델과 자체 운영 모델을 연결하기 시작했을 때 부딪힌 문제는 모델 자체와는 별로 관계가 없었다고 합니다. 오히려 업계가 이미 10년 동안 풀어 온 트래픽 문제에 가까웠다는 것입니다. 에이전트가 무언가를 호출하는 요청도 결국 네트워크를 지나가는 트래픽이므로, 그 길목에서 관리하면 된다는 뜻으로 볼 수 있습니다.

이미 많은 분이 아시는 것처럼, 게이트웨이의 역할은 MCP 서버를 고치지 않고도 누가 어떤 도구를 호출할 수 있는지 정하고 그 호출을 기록하는 것입니다.

이런 게이트웨이가 필요해지는 때는 에이전트가 호출하는 도구를 제공하는 MCP 서버가 팀마다 생길 때입니다. (여기서 도구란 사내 데이터를 조회하거나 배포를 실행하는 것처럼 에이전트에 실제 작업을 시키는 기능을 말합니다.) 서버가 늘어나면 클라이언트 설정이 서버 수만큼 많아지고, 누가 어떤 도구를 호출할 수 있는지도 서버마다 따로 관리해야 합니다. 게이트웨이를 1개 두면 클라이언트는 주소 1개만 알면 되고, 통제와 이에 따른 기록을 한곳에서 관리할 수 있습니다.

이 구조를 그림으로 표현하면 다음과 같습니다.

게이트웨이가 없을 때는 에이전트 1·2가 팀 A·B·C의 MCP 서버 각각에 직접 연결돼 권한 설정과 기록을 서버마다 따로 관리하지만, 게이트웨이가 있을 때는 에이전트가 MCP 게이트웨이 하나에만 연결되고 게이트웨이가 도구 호출 권한 통제·호출 기록·서버 3개를 1개로 제공하는 구조를 좌우로 비교한 도식 — 게이트웨이가 없을 때와 있을 때의 MCP 서버 연결 구조 <출처: 작가>

앞에서 본 깃허브 사례도 이 그림으로 다시 보면 이해하기 쉽습니다. 문제가 서버 1개의 코드에 있지 않았으니 서버를 하나씩 고쳐서는 막기 어렵습니다. 여러 서버로 가는 호출이 모두 지나가는 자리에서 누가 무엇을 호출하는지 보고 정해야 합니다.

마이크로서비스 때와 같은 점, 그리고 다른 점

사실 호출이 거쳐 가는 자리에 공통 계층을 두는 이 흐름은 처음 보는 것이 아닙니다. 마이크로서비스가 늘어났을 때도 서비스마다 인증, 재시도, 관측을 따로 넣다가 그 일을 서비스 밖으로 꺼내 한곳에서 처리하는 API 게이트웨이와 서비스 메시(service mesh)가 자리 잡았습니다.

이 글에서 다룰 게이트웨이 가운데 하나인 agentgateway를 만든 솔로닷아이오(Solo.io)도 같은 이야기를 합니다. 2025년 4월 agentgateway를 발표하면서, 마이크로서비스에 서비스 메시가 필요했던 것처럼 에이전트에도 보안, 관측, 가드레일을 위한 연결 계층이 필요하다고 설명한 것입니다. 같은 회사의 램 베남(Ram Vennam)은 2026년 5월에 쓴 글에서 이 비유에 중요한 차이가 하나 있다고 덧붙였습니다. 바로 예측 가능성입니다. 마이크로서비스는 호출 경로가 코드로 정해져 있지만, 에이전트는 같은 요청을 받아도 매번 다른 도구를 다른 순서로 호출할 수 있습니다. 그래서 미리 정해 둔 호출만 허용하는 방식으로는 부족하고 호출이 지나갈 때마다 확인하고 기록하는 지점이 더 중요해집니다.

쿠버네티스 쪽을 보면 이 계층이 표준이 되기까지 시간이 꽤 걸렸다는 것도 알 수 있습니다. 쿠버네티스는 처음에 인그레스(Ingress)로 외부 트래픽을 받았지만 기능이 부족해 구현체마다 설정 방식이 달라졌습니다. 그러자 이를 정리한 Gateway API가 등장해 2023년 10월에야 정식 버전이 되었습니다. 결국 현재 쿠버네티스 공식 문서에는 인그레스는 더 이상 기능이 추가되지 않으니 Gateway API를 쓰라고 적혀 있습니다.

AI 트래픽 쪽에서도 같은 일이 벌어지고 있습니다. 모델 추론 요청을 다루는 Gateway API Inference Extension이 2025년 9월에 정식 버전이 되었고, 같은 달에는 쿠버네티스에 AI 게이트웨이를 다루는 워킹그룹도 생겨 2026년 3월에 이를 공식적으로 알렸습니다. 즉, 에이전트가 도구를 호출하는 지점을 다루는 표준도 이제 막 만들어지기 시작한 단계라고 보시면 됩니다.

그런데 에이전트 쪽에서는 프로토콜에서 먼저 변화가 생기고 있습니다. 2026년 7월에 개정된 MCP 스펙은 호출하는 메서드와 도구 이름을 요청 헤더에 따로 넣도록 했습니다. 스펙 문서에 따르면 게이트웨이 같은 중간 계층이 본문을 해석하지 않고도 요청을 확인할 수 있게 하려는 것입니다. 반면 에이전트 사이의 대화를 이어 가는 프로토콜을 다룰 IETF(Internet Engineering Task Force) 워킹그룹은 2026년 10월 8일에야 승인되었고, 첫 문서 제출 목표도 2028년 3월입니다.

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

CNCF가 쿠버네티스 생태계를 키웠을 때와의 비교

앞에서 본 Gateway API 프로젝트는 CNCF가 관리합니다. 이 재단은 2015년 7월에 구글이 쿠버네티스를 기부하면서 만들어졌습니다. 그 뒤로 처음에는 쿠버네티스뿐이던 재단에 모니터링, 서비스 메시, 게이트웨이 같은 프로젝트가 차례로 더해졌습니다. 2017년에는 지금 많은 게이트웨이의 바탕이 되는 Envoy도 CNCF 프로젝트가 되었습니다.

2026년 10월 기준으로 CNCF의 호스티드 프로젝트(hosted project)*는 졸업, 인큐베이팅, 샌드박스(Sandbox) 단계를 합쳐 230개이고 회원사는 723곳입니다. 쿠버네티스라는 중심이 먼저 있었고 그 주변에서 필요한 계층이 하나씩 채워지면서 지금의 클라우드 네이티브 생태계가 만들어졌습니다.

*호스티드 프로젝트: 재단이 상표와 저장소를 넘겨받아 중립적으로 관리하는 프로젝트를 말합니다.

에이전틱 AI 재단은 2025년 12월에 리눅스 재단(Linux Foundation) 산하에서 같은 방식으로 출발했습니다. 앤트로픽(Anthropic)의 MCP, 블록(Block)의 goose, 오픈AI(OpenAI)의 AGENTS.md를 창립 프로젝트로 두었고 이후 2026년 8월에는 구글이 시작한 A2A도 호스티드 프로젝트가 되었습니다.

이때 재단은 자신을 에이전틱 스택(agentic stack)이 만들어지는 개방적이고 중립적인 곳이라고 소개하면서, 도구 연결부터 에이전트 간 통신과 운영까지 전체 스택을 같은 방식으로, 같은 곳에서 관리하겠다고 밝혔습니다. 회원사는 2026년 10월 기준, 벌써 270곳에 달합니다. 출범 4개월 만에 이미 같은 시기 CNCF 회원 수의 두 배를 넘은 수치를 달성했습니다.

두 재단의 구성을 비교해서 정리하면 다음과 같습니다.

CNCF와 에이전틱 AI 재단(AAIF)의 생태계를 출범 시기, 중심 프로젝트(쿠버네티스 대 MCP·A2A), 트래픽 계층(Envoy·Gateway API 대 agentgateway·Agent Router), 그 밖의 대표 프로젝트, 호스티드 프로젝트·회원사 규모 순으로 나란히 비교한 표 — CNCF와 에이전틱 AI 재단의 생태계 구성 비교 <출처: 작가>

에이전틱 AI 재단에서 관리하는 두 개의 게이트웨이

여기서 운영 계층에 해당하는 것이 게이트웨이입니다. agentgateway를 만든 솔로닷아이오는 구글과 함께 만든 앰비언트 메시(ambient mesh)를 이스티오(Istio)에 기여했고, 자사 게이트웨이를 kgateway라는 이름으로 CNCF에 기부해 샌드박스 프로젝트가 된 이력이 있습니다. 이 회사가 2025년 4월에 발표한 agentgateway도 4개월 뒤인 8월에 리눅스 재단에 기부되었으며, 2026년 6월에는 에이전틱 AI 재단의 호스티드 프로젝트가 되었습니다.

한편, 블룸버그와 테트레이트(Tetrate)가 시작한 Envoy AI Gateway도 2026년 9월 Agent Router로 이름을 바꾸면서 같은 재단의 프로젝트가 되었습니다.

그 결과 지금 에이전틱 AI 재단의 호스티드 프로젝트 6개 가운데 2개가 유사한 역할을 하는 게이트웨이입니다. 솔로닷아이오와 테트레이트는 모두 각자의 프로젝트를 바탕으로 한 상용 제품을 따로 팔면서도, 오픈 소스는 중립적인 재단에 기부했습니다. 저는 이런 기부가 어쩌면 이 지점을 두고 벌어지는 매우 치열한 경쟁을 그대로 보여준다고 생각합니다.

재단 쪽에서 보면, CNCF에서 Envoy가 여러 게이트웨이의 공통 바탕이 되었던 것처럼 에이전틱 AI 재단도 MCP와 A2A 옆에 운영 계층을 함께 두려는 것으로 보입니다. 에이전트 생태계 전체를 한곳에서 키우겠다는 것이죠.

다만 두 게이트웨이는 배치 방식이 다릅니다. agentgateway는 요청을 직접 처리하는 단독 프록시이고, Agent Router는 Envoy를 확장한 구조라 요청이 Envoy를 2번 지나갑니다. 이를 그림으로 표현하면 다음과 같습니다.

agentgateway는 에이전트의 MCP 요청을 Rust로 작성된 데이터 플레인이 직접 해석해 MCP 서버로 보내 게이트웨이 구간을 1번만 지나가는 반면, Agent Router는 Envoy 수신 리스너·Go로 만든 MCP 프록시 사이드카·Envoy MCP 리스너로 이어지는 Envoy 프록시 파드를 통해 Envoy를 2번 지나가는 구조 차이를 비교한 도식 — 에이전트와 MCP 서버 사이에 놓이는 게이트웨이 2개의 배치 차이 <출처: 작가>

두 게이트웨이를 직접 설치해 확인한 4가지

그러면 실제로, 이 두 가지 게이트웨이를 써 보면 어떨까요?

두 프로젝트를 쿠버네티스 클러스터에 직접 설치하고 정책을 걸어 가며 호출해 봤습니다. 결론부터 말씀드리면, 이 글에서 확인한 버전(agentgateway v1.5.0, Agent Router v1.1.0)을 기준으로 두 프로젝트가 통제하는 범위는 서로 꽤 다릅니다.

도구 이름 단위로 막는 것은 양쪽 모두 쓴 대로 동작하지만, 호출할 때 넘긴 값까지 보고 판단하는 통제에서는 갈립니다. 예를 들어 삭제 도구를 아예 막는 대신 운영 환경의 레코드를 지우는 호출만 막고 싶다고 해 보죠. Agent Router는 인가(authorization, 누가 무엇을 해도 되는지 판단하는 것) 정책만으로 처리할 수 있지만, agentgateway는 v1.5.0에서 외부 검사 서버를 따로 두어야 했습니다.

여기에 더해 사용자가 주로 보는 설정 문서에는 별다른 언급이 없지만, 실제로는 문서나 설정에 적은 대로 동작하지 않는 경우도 있었습니다. 확인한 것을 정리하면 다음과 같습니다.

agentgateway와 Agent Router 설치 후 확인한 4가지 동작 비교표: 도구 이름 단위 통제는 둘 다 쓴 대로 동작하지만, 넘긴 값을 조건으로 쓰는 통제는 agentgateway가 외부 검사 서버 없이 적으면 도구 목록이 비고 Agent Router는 문서 예시 그대로 쓰면 도구 목록이 비어 돌아오며, 게이트웨이를 거치며 늘어나는 시간은 agentgateway가 호출당 1ms 아래, Agent Router는 기본 설정에서 약 20ms이고, A2A 요청은 agentgateway가 기록은 남기되 전용 인가가 없고 Agent Router는 이번에 측정하지 않았다는 내용의 표

*표의 시간은 같은 클러스터에서 게이트웨이를 거치지 않고 직접 호출한 경우와 비교해 늘어난 값(p50, 응답 시간을 줄 세웠을 때 가운데 값)입니다. 두 게이트웨이를 같은 조건에 두고 비교한 것은 아닙니다.

다만 두 프로젝트 모두 빠르게 바뀌고 있습니다. 이 글을 작성하던 2026년 10월에도 agentgateway v1.6.0(10월 2일)과 Agent Router v1.2.0(10월 7일)이 나왔습니다. agentgateway에서는 라우트 단위 인가 정책으로 넘긴 값 조건을 적용할 수 있게 되었고, 외부 검사 서버 없이도 막아야 할 호출이 막히는 것을 다시 확인했습니다. Agent Router에서는 세션 암호화에 쓰는 시드(seed, 암호화에 쓰는 초기값)의 기본값이 무작위로 만들어지도록 바뀌었습니다.

그러니 위 표는 고정된 차이가 아니라, 계속 개발 중인 두 프로젝트의 현재 모습으로 읽어 주시기 바랍니다. 측정 조건과 항목별 결과는 공개 저장소의 agentgateway 쪽과 Agent Router 쪽에 정리해 두었으니 참고하면 좋겠습니다.

게이트웨이 도입을 고민하면 좋은 시점

그럼 이제 어떤 경우에 게이트웨이 도입을 고민하면 될까요?

도구를 제공하는 MCP 서버가 여럿이 되고 누가 무엇을 호출할 수 있는지를 서버마다 따로 관리하기 어려워졌다면 그때부터 검토해 보면 됩니다. 반대로 MCP 서버가 1개뿐이거나 도구 이름 단위로 막는 것으로 충분하다면 굳이 넣지 않아도 됩니다. 이번에 확인한 두 게이트웨이를 거쳐도 도구 호출이 빨라지지는 않았고 한 번 더 거치는 시간만 늘었기 때문입니다.

도입하기로 정하셨다면 다음 3가지는 꼭 확인해 보시길 권합니다.

1) 정책을 넣은 뒤에 에이전트가 받는 도구 목록 확인하기

에이전트는 게이트웨이에서 도구 목록을 먼저 받고 그 안에서 호출할 도구를 정합니다. 그런데 이번에 확인해 보니, 정책을 넣은 다음 게이트웨이 상태에는 아무 문제가 없는데도 이 목록이 빈 채로 돌아오는 경우가 있었습니다. 이렇게 되면 에이전트 입장에서는 도구가 전혀 없는 것과 같습니다. 그러니 정책을 넣은 뒤에는 목록을 한 번 받아서 도구가 제대로 남아 있는지 확인해 보셔야 합니다.

2) 막으려던 호출이 실제로 막히는지 직접 호출해 보기

정책이 오류 없이 등록되었다고 해서 그 조건이 실제로 적용된다는 뜻은 아니었습니다. 예를 들어 호출할 때 넘긴 값을 조건으로 적은 정책이 문제없이 등록되었지만, 실제로는 그 조건이 평가되지 않아 의도와 다르게 동작했습니다. 그래서 막아야 하는 호출과 허용해야 하는 호출을 각각 직접 보내서 결과가 정책에 적은 대로 나오는지 확인하는 것이 좋습니다.

3) 기본값으로 둔 설정이 운영 환경에 맞는지 확인하기

이번에 Agent Router에서 확인한 약 20ms의 지연은 대부분 구조 때문이 아니라 세션 암호화 반복 횟수라는 설정의 기본값에서 나왔습니다. 이 값을 낮추자 늘어나는 시간이 약 0.5ms로 줄었습니다. 다만 이 값은 보안과도 관련이 있어 무조건 낮추면 되는 것은 아닙니다. 따라서 기본값을 그대로 쓰는 설정이 있다면, 그 값이 왜 그렇게 정해져 있는지와 운영 환경에 맞는지를 함께 확인해 보시면 됩니다.

마치며

처음의 질문으로 돌아가 보겠습니다. 에이전틱 AI 세계에서 게이트웨이는 어떤 의미를 가질까요?

제가 확인한 범위에서 답을 하자면, 게이트웨이를 두면 에이전트가 늘어날수록 함께 늘어나는 호출을 서버를 하나하나 고치지 않고도 한곳에서 통제하고 기록할 수 있습니다. 깃허브 사례처럼 서버 1개를 고쳐서는 막기 어려운 문제가 생기고, 호출은 몇 달 만에 수십 배로 늘고 있습니다. 여러 회사가 이 영역에 제품을 내놓고 에이전틱 AI 재단이 게이트웨이 프로젝트를 2개나 받아들인 이유도 여기에 있다고 생각합니다.

하지만 아직은 시작 단계입니다. 쿠버네티스에서 인그레스가 Gateway API로 정리되기까지 몇 년이 걸렸던 것처럼 에이전트가 도구를 호출하는 지점을 다루는 표준도 이제 막 만들어지는 중입니다. 심지어 재단의 두 프로젝트조차도 통제하는 범위와 기본값이 서로 달랐습니다. CNCF가 쿠버네티스를 중심으로 생태계를 키워 온 것처럼 에이전틱 AI 재단이 MCP와 A2A를 중심으로 이 계층을 어떻게 키워 갈지 계속 지켜보시면 좋을 것 같습니다.

이 글이 에이전트를 실제 업무에 연결하려는 분들께 조금이나마 도움이 되었으면 좋겠습니다.

저는 에이전틱 AI 재단의 앰배서더로 활동하고 있고, 이 글에서 다룬 agentgateway와 Agent Router는 그 재단의 프로젝트입니다. 그런 만큼 좋은 점만 쓰기보다 문서에 적힌 대로 되지 않는 부분까지 직접 확인해서 담았습니다.

작가

조훈 (CNCF&AAIF 앰버서더)

쿠버네티스 및 AI 네이티브 기술 전문가로, CNCF와 에이전틱 AI 재단(AAIF) 글로벌 앰버서더이자 Kubestronaut이다. 쿠버네티스랩을 운영하며 인프라 자동화 기술을 연구하고 공유한다. ‘IT 인프라 엔지니어 그룹’ 운영진이자 오픈소스 컨트리뷰터로 활동 중이며, 맞춤형 인프라 교육, 쿠버네티스 비용 최적화, 멀티 LLM 및 AI 에이전트 비교 검증 등 다양한 실무 PoC를 수행하고 있다. 최근 출간한 『AI 시대에 개발자가 알아야 할 인프라 구성 배포 with 클로드 코드』를 포함해 총 5권의 IT 서적을 집필했으며, 인프런 강의 및 요즘IT 기고 등 지식 공유 활동을 이어가고 있다.

심근우

LG유플러스 CTO부문에서 대고객 비즈니스 시스템의 DevOps를 담당하는 UcubeDAX팀의 팀장으로 일하고 있다. 퍼블릭 클라우드와 프라이빗 클라우드에 걸친 쿠버네티스 클러스터를 안정적으로 운영하기 위해 노력하고 있으며, 특히 주니어 DevOps 엔지니어들의 육성에 큰 관심을 가지고 있다.

문성주

체커(CHEQUER) 사의 DevOps Engineer로서 쿠버네티스의 멀티 클러스터 관리 방법론과 쿠버네티스 구현체(CAPI, OCI)에 대한 명세와 컨테이너 리소스 격리 방법에 대한 연구를 병행하고 있다. 이런 연구 활동을 기반으로 쿠버네티스 볼륨 테스트 파트에 컨트리뷰션했다. 본업은 쿠버네티스 오퍼레이터와 같은 CRD(커스텀 리소스)를 개발해 현업에서 쿠버네티스를 좀 더 편리하게 사용할 수 있도록 돕는 일이다. 또한, 페이스북 그룹 ‘코딩이랑 무관합니다만'과 ‘IT 인프라 엔지니어 그룹'의 운영진을 맡고 있다.

이성민

미국 넷플릭스(Netflix) 사의 Data Platform Infrastructure 팀에서 사내 플랫폼 팀들과 데이터 사용자들을 어우르기 위한 가상화 및 도구들을 개발하는 일들을 하고 있다. 과거 컨테이너와 쿠버네티스에 큰 관심을 두고 ingress-nginx를 비롯한 오픈 소스에 참여했으며, 현재는 데이터 분야에 일하게 되면서 stateful 한 서비스들이 컨테이너화에서 겪는 어려움을 보다 근본적으로 해결하기 위한 많은 노력을 하고 있다.