AX LABS
← 블로그 에이전트 제품 설계

Agent Gateway가 검문소다

정책은 프롬프트가 아니라 호출 경로에 둔다

AX LABS 6분 읽기

현장에서 에이전트 PoC가 운영으로 넘어가는 순간 같은 장면이 반복된다. 모델 응답은 그럴듯하다. 데모도 된다. 그런데 도구 호출이 붙는 순간 보안팀, 플랫폼팀, 현업 오너가 모두 멈춘다. 누가 어떤 권한으로 CRM을 읽었는지, Slack에 무엇을 썼는지, 다른 에이전트에게 어떤 컨텍스트를 넘겼는지 설명하지 못한다.

이 문제는 프롬프트로 풀리지 않는다. 호출 경로에서 풀어야 한다.

에이전트의 위험은 말이 아니라 호출에서 터진다

LLM이 텍스트만 생성할 때의 통제 지점은 입력과 출력이다. 에이전트는 다르다. LLM→tool, agent→agent, agent→SaaS 호출이 생긴다. 이 호출은 읽기, 쓰기, 결재, 발송, 삭제 같은 업무 행위로 이어진다.

MCP 2025-11-25 사양은 HTTP 기반 권한 부여 프레임워크와 보호 리소스 메타데이터를 다룬다. A2A는 2025년 6월 Linux Foundation 프로젝트로 출범해 에이전트 간 안전한 통신과 협업을 표방했다. 즉 시장의 방향은 명확하다. 에이전트는 혼자 답하는 소프트웨어가 아니라, 다른 시스템을 호출하는 실행 주체가 됐다. (modelcontextprotocol.io)

그래서 통제도 모델 옆이 아니라 호출 사이에 있어야 한다.

Agent Gateway는 에이전트 시대의 API Gateway가 아니다. 정책을 실행하는 data plane이다.

한 프록시가 세 종류 호출을 같은 언어로 본다

기업 내부에서는 호출 유형마다 다른 팀이 붙는다. SaaS 연동은 보안팀, 내부 API는 플랫폼팀, 에이전트 간 위임은 AI팀이 본다. 이렇게 나뉘면 운영에서 빈틈이 생긴다. Agent Gateway는 이 세 경로를 하나의 프록시로 모은다.

호출 경로 운영 리스크 Gateway 검문 항목
LLM→tool 과도한 도구 선택, 민감 데이터 조회 tool allowlist, schema validation, 목적 기반 scope
agent→agent 책임 경계 붕괴, 컨텍스트 과다 공유 agent identity, delegation policy, context redaction
agent→SaaS 사용자 권한 우회, 외부 기록 오염 delegated auth, DLP, write approval

AWS는 2025년 8월 AgentCore Gateway를 중앙 도구 서버로 설명하며 에이전트가 도구를 발견·접근·호출하는 통합 인터페이스라고 밝혔다. Solo.io도 2025년 10월 enterprise agentgateway를 MCP와 A2A 생산 운영을 위한 보안, 관측, 거버넌스 계층으로 설명했다. 제품명은 달라도 설계 방향은 같다. 도구 호출을 흩어두지 않고 data plane으로 모은다. (aws.amazon.com)

정책은 선언이 아니라 런타임 판정이어야 한다

많은 조직이 첫 설계에서 “민감 정보는 쓰지 말 것”, “삭제 작업은 금지” 같은 프롬프트 정책을 넣는다. 그건 운영 통제가 아니다. 모델이 호출 직전에 어떤 도구를 어떤 파라미터로, 어떤 사용자 권한을 빌려, 어느 시스템에 실행하려는지 Gateway가 판정해야 한다.

Agent Gateway의 기본 정책 단위는 네 가지다.

  1. Identity: 사용자, 에이전트, 도구, SaaS 계정을 분리해 식별한다.
  2. Scope: 호출 목적과 업무 맥락에 맞는 최소 권한만 허용한다.
  3. Inspection: 입력 파라미터, 반환값, 첨부 컨텍스트를 검사한다.
  4. Decision: 허용, 차단, 축소, 사람 승인, 샌드박스 실행을 즉시 결정한다.

OpenAI Agents SDK 문서는 도구 호출 전후의 guardrail과 handoff 경계의 차이를 구분한다. Cloudflare Agents SDK의 2025년 12월 변경 로그도 tool approval과 reliable tool execution을 생산 인터페이스의 핵심으로 다룬다. 운영 설계의 핵심은 “에이전트가 잘 답했는가”가 아니라 “허가된 행동만 했는가”다. (openai.github.io)

AX Ops는 Gateway를 운영 책임으로 고정한다

Agent Gateway는 보안 제품 하나를 꽂는 일이 아니다. 운영 책임을 다시 그리는 일이다. AX Ops에서는 먼저 호출 지도를 만든다. 어떤 에이전트가 어떤 SaaS와 내부 API를 부르는지, 어떤 호출이 쓰기 작업인지, 어떤 호출이 사람 승인을 요구하는지 확정한다.

그 다음 정책을 코드와 운영 절차로 나눈다. 정적 정책은 Gateway에 둔다. 예외 승인, 장애 우회, 권한 회수, 로그 리뷰는 운영 프로세스로 둔다. 둘을 섞으면 보안팀은 모든 일을 수동 승인하고, 현업은 우회 경로를 만든다.

시작점은 단순하다. 가장 위험한 호출 세 개를 고른다. 고객 데이터 조회, 외부 메시지 발송, 금전·계약 관련 쓰기 작업이다. 이 세 호출을 Agent Gateway 뒤로 넣고 identity, scope, inspection, decision 로그를 남긴다. 그때부터 에이전트는 데모가 아니라 운영 대상이 된다.

Agent Gateway의 목적은 에이전트를 막는 것이 아니다. 호출을 설명 가능하게 만들고, 설명 가능한 호출만 확장하는 것이다. AX LABS는 이 설계를 PoC 말미가 아니라 첫 운영 아키텍처에서 고정한다. AX Ops 방법론 →

참고