요약 (TL;DR): 에이전트 게이트웨이(Agent Gateway)는 AI 에이전트를 위해 특별히 구축된 제어 계층(control layer)입니다. 에이전트와 모델 간, 그리고 에이전트와 도구(tool) 간의 통신을 위해 인증(authentication), 라우팅(routing), 정책 집행(policy enforcement), 관측성(observability), 그리고 오케스트레이션(orchestration)을 처리합니다. AI 게이트웨이는 LLM 요청을 라우팅하지만, 에이전트 게이트웨이는 자율적인 에이전트의 행동을 관리합니다. 에이전트가 도구를 호출하고, 하위 에이전트(sub-agents)를 생성하며, 다단계 워크플로우(multi-step workflows)를 실행하기 시작하면 두 가지 모두가 필요합니다.

처음 6개월 동안, 우리의 AI 게이트웨이는 우리가 직면한 모든 문제를 해결해 주었습니다. 모든 LLM 제공업체를 위한 단일 엔드포인트(endpoint), 팀별 속도 제한(rate limiting), 비용 귀속(cost attribution), 프롬프트 및 응답에 대한 가드레일(guardrails)까지 갖추고 있었죠. 깔끔하게 작동했고 우리는 만족했습니다.

그러다 우리는 에이전트를 배포하기 시작했습니다.

첫 번째 에이전트는 간단했습니다. 들어오는 티켓을 분류하고 적절한 팀으로 라우팅하는 지원 분류(support triage) 에이전트였습니다. 이 에이전트는 하나의 모델을 호출하고, 가끔 MCP 도구를 통해 Confluence 문서를 가져오며, Jira에 라벨을 다시 작성했습니다. 괜찮았습니다. 아무런 문제가 없었죠.

두 번째는 데이터 파이프라인 에이전트였습니다. BigQuery에서 데이터를 가져오고, 변환(transformations)을 실행하며, 작업 유형에 따라 두 개의 서로 다른 모델을 호출하고, 작업의 특정 세그먼트를 위해 하위 에이전트(sub-agents)를 생성했습니다. 바로 그때부터 상황이 좋지 않은 방향으로 흥미로워지기 시작했습니다.

AI 게이트웨이는 이 모든 것을 LLM 요청의 스트림(stream)으로만 보았습니다. 게이트웨이는 47번 요청이 12번 요청을 시작한 부모 에이전트에 의해 생성된 하위 에이전트라는 사실을 전혀 알지 못했습니다. 또한 에이전트가 3단계와 7단계 사이에서 무엇을 하기로 결정했는지도 우리에게 알려줄 수 없었습니다. 하위 에이전트가 예상치 못한 루프(loop)에 빠져 40분 만에 토큰 예산을 모두 소진했을 때, 게이트웨이는 사후에 비용 급증을 표시했을 뿐입니다. 4단계에서 이를 잡아낼 수 있는 에이전트별 회로 차단기(circuit breaker)가 없었던 것입니다.

이것이 바로 에이전트 게이트웨이가 해결하는 문제입니다. 그리고 이것들이 진정으로 다른 인프라 요구사항이라는 것을 깨닫기까지, 인정하고 싶지 않을 만큼 긴 시간이 걸렸습니다.

에이전트 게이트웨이(Agent Gateway)란 무엇인가?

에이전트 게이트웨이(Agent Gateway)는 AI 에이전트와 그들이 상호작용하는 모든 것(LLM 모델, 외부 도구, 다른 에이전트, 그리고 내부 API) 사이에 위치하는 중앙 집중식 제어 계층(centralised control layer)입니다.

제가 깨달은 정의는 다음과 같습니다. 마이크로서비스(microservices)를 위해 API 게이트웨이가 수행하는 역할인 중앙 집중식 인증(auth), 라우팅(routing), 속도 제한(rate limiting), 관찰 가능성(observability)을 떠올려 보세요. 이제 동일한 개념을 적용하되, 여러 단계에 걸쳐 상태(state)를 유지하고, 다른 에이전트를 생성할 수 있으며, 단순히 텍스트를 반환하는 것을 넘어 도구(tools)를 통해 세상과 상호작용하는 자율 에이전트(autonomous agents)를 위해 특별히 설계된 것이라고 상상해 보십시오.

API 게이트웨이는 요청을 처리하고 응답을 반환합니다. 에이전트 게이트웨이는 워크플로(workflow)를 처리합니다. 즉, 수 초 또는 수 시간 동안 실행될 수 있으며 각 단계의 출력이 다음 단계의 입력이 되는 결정, 도구 호출(tool invocations), 모델 호출(model calls), 그리고 하위 에이전트 위임(sub-agent delegations)의 연속을 관리합니다.

근본적인 차이점은 다음과 같습니다. LLM 요청은 상태가 없는(stateless) 방식이지만, 에이전트 워크플로는 상태를 유지하는(stateful) 방식입니다. 이 차이가 에이전트 게이트웨이의 거의 모든 아키텍처 결정(architectural decision)을 주도합니다.

에이전트 게이트웨이는 어떻게 작동하는가?

에이전트가 게이트웨이를 통해 요청을 보낼 때 다음과 같은 일이 일어납니다.

1. 신원 및 인증 (Identity and auth)
게이트웨이는 에이전트를 인증합니다. 단순히 "이것이 유효한 API 키인가?"를 확인하는 것이 아니라, "이것은 어떤 에이전트인가? 어떤 사용자나 서비스 계정(service account)이 소유하고 있는가? 그리고 무엇을 할 수 있도록 허용되었는가?"를 확인합니다. 이는 멀티 에이전트 시스템(multi-agent system)에서 매우 중요합니다. 부모 에이전트에 의해 생성된 하위 에이전트는 부모의 전체 권한이 아니라, 부모가 위임하도록 승인된 권한만을 상속받아야 하기 때문입니다. OAuth 2.0 신원 주입(identity injection)은 모든 작업이 모델이나 도구에 도달하기 전에 검증된 신원과 연결되도록 합니다.

2. 정책 집행 (Policy enforcement)
요청이 목적지에 도달하기 전에 게이트웨이는 정책을 평가합니다. 이 에이전트가 이 도구에 접근할 권한이 있는가? 이 워크플로가 토큰 예산(token budget)을 초과했는가? 이 요청이 에이전트에게 정의된 범위(scope) 내에 있는가? 이러한 확인 작업은 사후 감사(post-hoc audit)로서가 아니라, 실행 전의 관문(gate)으로서 핫 패스(hot path) 상에서 이루어집니다.

3. 프로토콜 인식 라우팅 (Protocol-aware routing)
표준 API 게이트웨이가 기본적으로 이해하는 HTTP 요청과 달리, 에이전트 트래픽은 일반적으로 MCP (Model Context Protocol) 또는 A2A (agent-to-agent)와 같은 프로토콜을 사용합니다. 에이전트 게이트웨이는 이러한 프로토콜을 이해합니다. 즉, MCP 도구 호출(tool calls)을 적절한 서버로 라우팅하고, 멀티 에이전트 대화(multi-agent conversations)를 멀티플렉싱(multiplexing)하며, 에이전트가 클라이언트로 다시 보내는 서버 시작 메시지(SSE, 스트리밍 업데이트)를 처리할 수 있습니다. 일반적인 리버스 프록시(reverse proxy)는 이를 수행할 수 없습니다. 리버스 프록시는 MCP 세션이 무엇인지 이해하지 못하기 때문입니다.

4. 상태 및 세션 추적 (State and session tracking)
게이트웨이는 에이전트의 워크플로(workflow) 전반에 걸쳐 컨텍스트(context)를 유지합니다. 게이트웨이는 요청 #47이 요청 #12와 동일한 세션에 속한다는 것을 알고 있습니다. 이것이 단계별 관측성(step-level observability)을 가능하게 합니다. 단순히 LLM 호출의 평면적인 목록을 나열하는 대신, 에이전트의 전체 실행 경로를 보여주는 트레이스(trace)를 얻을 수 있습니다. 즉, 각 단계에서 어떤 모델이 호출되었는지, 어떤 도구가 호출되었는지, 중간 결과는 무엇이었는지, 그리고 워크플로가 어디서 분기되었는지를 보여줍니다.

5. 서킷 브레이커 및 실행 제어 (Circuit breakers and execution controls)
만약 에이전트가 루프(loop)에 빠져 동일한 도구를 반복적으로 호출하거나, 하위 에이전트를 생성하고 그 하위 에이전트가 또 다른 하위 에이전트를 생성하는 경우, 게이트웨이는 이를 감지하여 '$400 Tuesday' 사고(막대한 비용 발생 사고)로 이어지기 전에 개입합니다. 에이전트별, 워크플로별, 팀별로 엄격한 예산 상한선(budget caps)이 적용됩니다. 재시도 제한(retry limits) 및 타임아웃 제어는 개별 요청 단위가 아닌 워크플로 수준에서 적용됩니다.

6. 감사 추적 (Audit trail)
모든 에이전트 작업, 도구 호출, 모델 호출 및 하위 에이전트 위임은 구조화된 메타데이터와 함께 기록됩니다. 즉, 어떤 에이전트가, 어떤 단계에서, 어떤 사용자 ID로, 어떤 도구를 사용했으며, 파라미터(parameters)는 무엇이었고, 결과는 무엇이었는지가 기록됩니다. 이것이 컴플라이언스 감사(compliance audit)에 실제로 필요한 정보입니다. 단순히 "모델 X가 4,000번 호출되었습니다"가 아니라, "사용자 Z의 신원으로 동작하는 에이전트 Y가 14:23:07에 테이블 T에서 이러한 파라미터로 delete_record 도구를 호출했습니다"라는 정보가 필요합니다.

에이전트 게이트웨이 vs AI 게이트웨이 vs API 게이트웨이

이것은 제가 우리가 무엇을 만들었는지 설명할 때 가장 자주 받는 질문이므로, 직접적으로 답변해 보겠습니다.

요약하자면: 세 가지 모두 필요하며, 이들은 스택의 서로 다른 계층(layers)에 존재합니다. API 게이트웨이는 마이크로서비스를 처리합니다. AI 게이트웨이는 LLM 트래픽을 처리합니다. 에이전트 게이트웨이는 자율 에이전트를 처리합니다. 실제로 AI 게이트웨이와 에이전트 게이트웨이는 종종 동일한 시스템인 경우가 많지만, 에이전트 기능이 단순히 덧붙여진(bolted on) AI 게이트웨이가 아니라, 두 가지 모두를 위해 설계된 (designed) 동일한 시스템이어야 합니다.

하나가 없을 때 발생하는 구체적인 문제들

현재 에이전트를 운영하면서 "우리는 에이전트 게이트웨이가 없지만 별문제 없어 보이는데"라고 생각하고 있다면, 결국 당신을 붙잡게 될 네 가지 문제는 다음과 같습니다.

멀티 에이전트 시스템에서의 자격 증명 확산 (Credential sprawl). 각 에이전트는 도구(tools), 모델(models), 그리고 API에 접근할 권한이 필요합니다. 게이트웨이가 없다면 각 에이전트가 자신의 자격 증명을 직접 관리하게 됩니다. 12개의 에이전트가 있는 시스템이라면, 추적, 교체(rotate), 폐기(revoke)해야 할 자격 증명 관계가 잠재적으로 12 × 6개가 됩니다. 에이전트가 폐기될 때, 당신은 해당 에이전트가 접촉했던 모든 시스템을 뒤지며 API 키를 찾아다녀야 합니다.

M×N 통합 폭발 (The M×N integration explosion). 도구를 호출해야 하는 각 에이전트는 해당 도구와 직접적인 통합이 필요합니다. 10개의 에이전트와 8개의 도구가 있다면, 구축, 유지 관리 및 모니터링해야 할 잠재적 통합 지점이 80개가 됩니다. 에이전트 게이트웨이 — 구체적으로 그 내부의 MCP 게이트웨이 계층 — 는 이를 각 에이전트가 하나의 엔드포인트(endpoint)만 알고, 각 도구가 한 번만 등록되는 방식으로 축소시킵니다.

에이전트가 실제로 무엇을 했는지에 대한 가시성 부재. AI 게이트웨이는 "오늘 4,000건의 모델 호출이 발생했습니다"라고 말해줄 수 있습니다. 하지만 "데이터 파이프라인 에이전트가 BigQuery에 12번 호출한 뒤, 그 결과로 GPT-4o를 세 번 호출했고, 그 후 출력을 생성하기 전 6번의 추가 호출을 수행하는 서브 에이전트(sub-agent)를 생성했습니다"라고는 말해줄 수 없습니다. 프로덕션 환경의 에이전트 장애를 디버깅(debug)하는 데 실제로 필요한 것은 바로 두 번째 종류의 추적(trace)입니다.

폭주하는 워크플로 (Runaway workflows). 에이전트는 루프(loop)에 빠질 수 있습니다. 하위 에이전트(sub-agent)를 생성하고, 그 하위 에이전트가 또 다른 하위 에이전트를 생성할 수도 있습니다. 토큰을 무한정 소모하는 재시도(retry) 패턴에 갇힐 수도 있습니다. 워크플로 수준의 서킷 브레이커(circuit breaker)가 없다면, 피해가 발생한 후에야 비용 급증 알림을 통해 상황을 인지하게 될 것입니다.

우리가 최종적으로 선택한 것

세 번째와 네 번째 문제(감사 요청에 응답할 수 없는 상황과 동시에 발생한 폭주하는 하위 에이전트 루프)를 동시에 겪은 후, 우리는 선택지를 검토했고 최종적으로 TrueFoundry의 Agent Gateway를 선택했습니다.

우리가 중요하게 고려했던 몇 가지 구체적인 사항은 다음과 같습니다:

프레임워크에 구애받지 않는 등록 (Framework-agnostic registration). 우리는 LangGraph 기반의 에이전트, CrewAI 기반의 에이전트 하나, 그리고 두 개의 커스텀 HTTP 에이전트를 보유하고 있습니다. 에이전트 게이트웨이는 단일 등록 인터페이스를 통해 이들 모두를 지원합니다. 에이전트가 등록되면 관리되는 신원(governed identity)을 부여받고 중앙 레지스트리(central registry)에 나타나며, 어떤 프레임워크로 구축되었든 상관없이 동일한 정책 엔진(policy engine)을 통해 트래픽이 흐르게 됩니다.

OAuth 2.0 주입을 통한 에이전트별 신원 부여 (Per-agent identity with OAuth 2.0 injection). 모든 에이전트 작업은 해당 에이전트의 세션을 소유한 인증된 사용자 또는 서비스 계정(service account)과 연결됩니다. 하위 에이전트가 생성될 때, 해당 에이전트는 부모 에이전트가 전달하도록 권한을 부여받은 위임된 권한(delegated permissions)만을 상속받습니다. 하위 에이전트가 워크플로를 시작한 사람보다 더 넓은 접근 권한을 갖게 되는 "과도한 권한을 가진 하위 에이전트 (over-privileged sub-agent)" 패턴은 설계 단계에서부터 차단됩니다.

전체 워크플로에 걸친 단계별 추적 (Step-level traces across the full workflow). 관측성(observability)은 모델 호출 로그(model call logs) 그 이상을 제공합니다. 우리는 전체 실행 추적(execution trace)을 볼 수 있습니다: 모든 결정 지점, 모든 도구 호출(tool invocation), 모든 하위 에이전트 위임, 그리고 모든 중간 결과물까지 말입니다. 프로덕션 환경에서 문제가 발생했을 때, 모델 호출 로그를 통해 무슨 일이 일어났는지 추론하는 대신 실제 실행 추적을 읽음으로써 디버깅 시간이 크게 단축되었습니다.

워크플로 수준의 서킷 브레이커 (Workflow-level circuit breakers). 예산 제한 (Budget caps)은 단순히 팀 단위가 아니라 워크플로 (workflow)별로 적용됩니다. 루프 탐지 (Loop detection)는 폭주하는 에이전트가 사고를 일으키기 전에 게이트웨이 수준에서 작동합니다. 우리는 안전 장치로서 장시간 실행되는 워크플로에 대해 최대 단계 (max-steps) 제한을 설정했습니다. 이러한 제어 기능은 우리의 AI 게이트웨이에는 존재하지 않았으며, 14개의 서로 다른 에이전트 구현체에 걸쳐 애플리케이션 계층 (application layer)에서 이를 구현하려 했다면 정말 고통스러웠을 것입니다.

동일한 시스템 내의 MCP 도구 거버넌스 (MCP tool governance). TrueFoundry의 에이전트 게이트웨이는 MCP 게이트웨이와 나란히 위치하기 때문에, 에이전트의 도구 액세스 정책 (tool access policies)은 모델 액세스 정책 (model access policies)과 동일한 제어 평면 (control plane)에 존재합니다. 새로운 에이전트가 온보딩될 때, 우리는 다음 사항들을 한 곳에서 정의합니다: 어떤 모델을 호출할 수 있는지, 어떤 도구를 사용할 수 있는지, 예산은 얼마인지, 누가 이를 수정할 수 있는지. 하나의 시스템, 하나의 감사 추적 (audit trail).

솔직한 트레이드오프 (tradeoff)를 말씀드리자면, 단순한 AI 게이트웨이 설정보다 초기에 구성해야 할 것이 더 많습니다. 만약 에이전트가 두 개뿐이고 복잡한 작업을 수행하지 않는다면, 이는 아직 필요하지 않은 오버헤드 (overhead)일 것입니다. 우리가 느낀 변곡점은 도구 액세스 권한이 중첩되는 에이전트가 약 4개 정도 되고, 적절한 감사 추적이 필요한 컴플라이언스 (compliance) 요구사항이 생겼을 때였습니다. 그때부터 추가적인 구성이 가치를 발휘하기 시작했습니다.

실제로 에이전트 게이트웨이가 필요한 시점

질문은 에이전트에게 거버넌스 (governance)가 필요한가 하는 것이 아닙니다. 필요합니다. 질문은 거버넌스의 복잡성이 전용 인프라를 구축할 만큼 정당화되는 시점이 언제인가 하는 것입니다.

다음과 같은 경우라면 아마 아직 에이전트 게이트웨이가 필요하지 않을 것입니다:

• 도구 액세스나 하위 에이전트 위임 (sub-agent delegation)이 없는 한두 개의 단순한 에이전트를 운영 중인 경우
• 에이전트가 순수하게 내부용이며, 컴플라이언스 요구사항이 없고, 리스크가 낮은 경우
• 아직 프로토타이핑 (prototyping) 단계에 있으며 거버넌스를 나중으로 미뤄도 되는 경우

다음과 같은 경우에는 에이전트 게이트웨이가 필요합니다:

• 여러 에이전트가 동일한 도구 (tools)에 대한 액세스 권한을 공유하며, 누가 무엇을 할 수 있는지 제어해야 하는 경우
• 통제 불능의 에이전트 루프 (runaway agent loop)가 실제 운영상 또는 재무적 사고를 유발할 수 있는 경우
• 누군가 (보안 담당자, 컴플라이언스 담당자, 고객 등) 에이전트 작업에 대한 감사 추적 (audit trail)을 요청한 경우
• 하위 에이전트 (sub-agents)가 관여되어 있으며, 위임된 권한 (delegated permissions)에 대한 추론이 필요한 경우
• 여러 팀에 걸쳐 에이전트를 배포하고 있으며, 각 팀이 이를 재구현하지 않고도 일관된 거버넌스 (governance)를 유지해야 하는 경우

M×N 통합 폭발 (integration explosion)이 보통 첫 번째 구체적인 강제 요인 (forcing function)이 됩니다. 감사 추적 (audit trail) 요청은 보통 두 번째 요인이 됩니다.

현재 귀하의 에이전트 설정은 어떠한가요? 애플리케이션 계층 (application layer)에서 거버넌스를 처리하고 계신가요, 아니면 전용 에이전트 게이트웨이 계층 (agent gateway layer)으로 이동하셨나요? 인프라 수준의 서킷 브레이커 (circuit breakers) 없이 팀들이 통제 불능의 루프 (runaway loop) 문제를 어떻게 해결하고 있는지 듣고 싶습니다. 댓글로 남겨주세요.