요약: Google Cloud가 Gemini Enterprise Agent Platform에서 Agent Gateway와 Agent Observability를 GA로 올리면서, 기업용 AI 에이전트 운영의 기준이 “모델 성능”에서 “연결 통제와 실행 추적”으로 이동하고 있습니다. 실무 개발자는 에이전트가 어떤 도구에 접근하고, 어떤 MCP 서버를 호출하며, 실패했을 때 어떤 trace로 원인을 찾을지 먼저 설계해야 합니다.
AI 에이전트 PoC는 보통 빠르게 시작됩니다. 모델 하나를 붙이고, 사내 API 몇 개를 tool로 열고, MCP 서버를 하나 더 연결하면 데모는 금방 나옵니다. 문제는 운영 전환 시점입니다. 에이전트가 사용자 대신 행동하기 시작하면 네트워크 경계, 권한, 감사 로그, 장애 추적이 모두 제품 요구사항이 됩니다.
Google Cloud의 2026년 6월 18일 릴리스 노트에 따르면 Gemini Enterprise Agent Platform의 Agent Gateway가 GA가 됐습니다. 설명은 단순합니다. Agent Gateway는 사용자와 에이전트, 에이전트와 도구, 에이전트와 에이전트 사이의 agentic interaction을 보호하고 관리하는 네트워킹 컴포넌트입니다. 같은 날 Agent Observability도 GA가 되었고, 신규 ADK 에이전트에는 OpenTelemetry tracing이 기본 활성화됩니다.
이 조합은 실무적으로 의미가 큽니다. 지금까지 많은 팀이 “에이전트가 답을 잘하느냐”만 봤다면, 이제는 “에이전트가 어디에 연결됐고, 어떤 순서로 무엇을 실행했으며, 그 경로를 재현할 수 있느냐”가 운영 기준이 됩니다. 특히 MCP 서버가 늘어나는 팀이라면 Gateway 없이 에이전트 연결을 늘리는 방식은 곧 보안 부채가 됩니다.
첫째, 연결 지점이 정책 대상이 됩니다. 에이전트가 사내 검색, 결제, CRM, 배포 시스템에 연결되어 있다면 각 연결은 단순한 HTTP 호출이 아닙니다. 사용자 권한을 위임받는 실행 경로입니다. Agent Gateway 같은 계층은 이 경로를 중앙에서 통제하는 역할을 합니다.
둘째, 관측성이 기본값으로 이동합니다. Google은 신규 ADK 에이전트의 OpenTelemetry tracing을 기본 활성화한다고 밝혔습니다. 이전에는 “문제 생기면 로그를 추가하자”가 흔했습니다. 에이전트는 그 방식이 잘 통하지 않습니다. 한 번의 응답 안에 planning, tool call, MCP round-trip, 모델 재시도, 사용자 컨텍스트 결합이 섞이기 때문입니다.
셋째, 로그 저장소 선택이 아키텍처 결정이 됩니다. 릴리스 노트는 멀티모달 prompt와 response payload 저장에 Google Cloud Storage를 권장하고, Console 기본 저장 선택도 Cloud Logging이 아니라 GCS로 바뀌었다고 설명합니다. 이유는 명확합니다. 텍스트 로그만으로는 이미지, 파일, 대형 tool result가 섞인 에이전트 실행을 충분히 보관하기 어렵습니다.
일반 챗봇은 대부분 request-response 구조입니다. 사용자가 질문하면 모델이 답합니다. 실패 원인도 상대적으로 단순합니다. 프롬프트가 애매했거나, 검색 결과가 틀렸거나, 모델이 잘못 추론했거나입니다.
에이전트는 다릅니다. 한 요청이 여러 시스템을 지나갑니다. 예를 들어 “지난달 매출 이상치를 찾아서 슬랙에 보고해줘”라는 요청은 인증 확인, 데이터 조회, 쿼리 생성, 이상치 분석, 보고서 작성, 슬랙 전송으로 쪼개집니다. 이 중 하나라도 잘못되면 결과만 보고는 원인을 알기 어렵습니다.
그래서 Gateway와 Observability는 따로 볼 기능이 아닙니다. Gateway는 “어디까지 갈 수 있는가”를 제한하고, Observability는 “어디에서 무슨 일이 있었는가”를 보여줍니다. 둘 중 하나만 있으면 운영 대응이 반쪽이 됩니다.
가장 먼저 연결 목록을 만들어야 합니다. 에이전트가 호출하는 API, MCP 서버, 데이터베이스, 브라우저 자동화, 파일 저장소를 전부 적습니다. 그리고 각 연결마다 읽기/쓰기 권한, 사용자 위임 여부, 민감 데이터 포함 여부, 실패 시 롤백 가능 여부를 붙입니다.
두 번째는 trace ID 전파입니다. 프론트엔드 요청 ID, 백엔드 job ID, 모델 호출 ID, tool call ID가 끊기면 장애 분석이 늦어집니다. OpenTelemetry를 쓰더라도 span 이름과 attribute 규칙이 엉망이면 검색 가능한 trace가 되지 않습니다.
세 번째는 payload 보관 정책입니다. 프롬프트와 응답을 전부 저장하면 디버깅은 쉬워지지만 개인정보와 영업기밀 노출 위험이 커집니다. 반대로 아무것도 저장하지 않으면 사고 대응이 안 됩니다. 최소한 보관 기간, 마스킹 필드, 접근 권한, 삭제 요청 처리 방식을 문서화해야 합니다.
MCP는 도구 연결을 표준화해 줍니다. 하지만 표준화는 연결을 쉽게 만든다는 뜻이지, 안전하게 만든다는 뜻은 아닙니다. 사내 MCP 서버가 파일 시스템, 데이터베이스, 배포 API에 접근한다면 에이전트의 tool choice가 곧 운영 작업으로 이어질 수 있습니다.
따라서 MCP 서버별로 allowlist를 두는 편이 안전합니다. 개발 환경에서는 넓게 열어도 되지만, 운영 환경에서는 서버별 기능을 쪼개야 합니다. 예를 들어 “고객 조회 MCP”와 “고객 상태 변경 MCP”를 같은 서버에 넣으면 감사와 권한 분리가 어려워집니다.
또한 tool 결과 크기도 제한해야 합니다. 에이전트가 대량 데이터를 한 번에 받아 모델 컨텍스트로 넘기면 비용과 보안 문제가 동시에 생깁니다. Gateway 계층에서 응답 크기 제한, 민감 필드 제거, rate limit을 걸 수 있는지 확인해야 합니다.
