Google Cloud Agent Governance Stack - 에이전트 함대를 엔지니어링 조직처럼 다루는 5계층
목차
개요
Google Cloud가 Cloud Next 26에서 Gemini Enterprise Agent Platform을 위한 거버넌스 스택을 공개했다. “잘못 설정된 SaaS 도구가 데이터를 수동적으로 흘린다면, 잘못 설정된 에이전트는 능동적으로 나쁜 행동을 한다”는 문제 인식에서 출발한다. 2015년 섀도 IT의 패턴이 AI 에이전트에서 반복되고 있으며, 에이전트 함대(fleet)를 엔지니어링 조직처럼 다뤄야 한다는 주장이다.
배경
지금 많은 조직의 에이전트는 프로덕션 DB, 고객 PII, 재무 시스템에 접근한다. 그럼에도 고유 ID, 범위가 지정된 권한, 행동 모니터링이 없는 경우가 많다. 엔지니어링 팀을 그렇게 운영하지 않듯이 에이전트 함대 역시 그렇게 운영해서는 안 된다는 것이다.
Google은 다섯 계층의 거버넌스 스택을 제안한다. 각 계층은 아래 계층 위에 쌓이며, Identity가 가장 먼저 정착되어야 한다.
핵심 내용
Layer 1: Identity
엔지니어가 입사하면 고유 ID와 인증 정보를 받는다. 문제가 생기면 특정 개인으로 행동을 추적할 수 있다. 대다수 에이전트 배포는 이 단계를 생략한다. 조직 전체의 에이전트가 agent-service@project.iam.gserviceaccount.com 같은 단일 서비스 계정을 공유한다. 사고가 나면 감사 로그는 공유 자격 증명에서 끊긴다.
Agent Identity는 에이전트마다 고유한 암호학적 ID와 권한 정책을 부여한다. 각 ID는 추적 가능하고 감사 가능하며 개별적으로 폐기 가능하다. Principle of Least Privilege를 에이전트 수준으로 내린다.
| 역할 | 접근 가능 데이터 | 접근 불가 데이터 |
|---|---|---|
| Finance Agent | 급여 데이터 | 직원 복리후생 정보 |
| HR Agent | 복리후생 데이터 | 재무 기록 |
Finance Agent가 프롬프트 인젝션이나 모델 업데이트로 행동이 바뀌면 해당 ID만 폐기해도 나머지 함대는 영향받지 않는다. 금융, 의료처럼 규제가 강한 산업에서는 선택이 아니라 요건이다.
Layer 2: 중앙 집중 도구 거버넌스
엔지니어가 프로덕션 서버에 임의로 패키지를 설치하지 않듯이 에이전트 도구도 같은 규율이 필요하다. 중앙 거버넌스가 없으면 팀마다 각자의 도구를 만들어 연결하는 섀도 AI가 발생한다. 섀도 AI는 중복, 보안 공백, 가시성 부재 같은 섀도 IT의 문제를 그대로 가진다.
Agent Registry는 조직의 모든 에이전트, MCP 도구, 엔드포인트의 중앙 카탈로그다. 플랫폼 팀이 사용 가능 항목을 통제하고 개발자는 필요한 것을 발견하는 “에이전트 역량의 사내 npm”이다. Cloud API Registry와 통합되어 관리형 API를 Apigee와 MCP 서버를 통해 에이전트 접근 가능 도구로 노출한다.
개발자는 커스텀 도구를 만들 수 있지만, 프로덕션 에이전트에서 사용하려면 등록과 승인을 거쳐야 한다. 각 도구에는 접근 데이터, 필요 권한, 레이트 리밋, 사용 에이전트 메타데이터가 붙는다. 도구에 취약점 패치가 필요할 때 어떤 에이전트가 영향을 받는지 즉시 확인할 수 있다.
Layer 3: 정책 집행
대부분의 에이전트 배포는 정책을 시스템 프롬프트나 애플리케이션 로직에 하드코딩한다. 새 정책을 추가하려면 에이전트마다 코드 변경, 배포, 테스트를 반복해야 한다. 50개 에이전트면 50번의 변경과 50번의 누락 기회가 생긴다.
Agent Gateway는 중앙 집행 지점에서 자연어로 보안 정책을 정의하고 통과하는 모든 에이전트에 일괄 적용한다. 정책을 한 번 작성하면 모든 에이전트에 즉시 반영되며, 수정하면 즉시 전파된다. Model Armor를 통합해 프롬프트 인젝션과 민감 데이터 유출을 방어한다. 자연어 정책은 알려진 위험을, Model Armor는 미지의 공격을 담당하는 방어-심층 구조다.
Layer 4: 행동 이상 탐지
정책은 “해야 할 일과 하지 말아야 할 일”을 정의한다. 이상 탐지는 “정책을 위반하지는 않지만 예상에서 벗어난 행동”을 잡는다.
Agent Anomaly Detection은 두 가지 접근을 병용한다. 통계 모델은 각 에이전트의 정상 베이스라인을 학습한다. 응답 시간, 전형적 도구 호출 패턴, 예상 데이터 접근 볼륨, 표준 추론 체인 길이 같은 지표가 기준이다. 베이스라인에서 크게 벗어나면 검토 대상으로 플래그된다.
두 번째 접근은 LLM-as-a-judge 프레임워크다. 별도 모델이 에이전트의 추론 체인을 검토해 근거로부터 논리적으로 도출되지 않는 결론, 명시된 목표와 모순되는 권고, 범위 외 요인에 영향받은 결정을 플래그한다.
Agent Threat Detection은 의도적 공격에 초점을 둔 별도 계층이다. 역방향 쉘, 알려진 악성 IP 연결, 권한 상승 시도, 침해 지표를 감지한다. 두 기능 모두 Security Command Center와 통합되어 경보와 사고 대응을 일원화한다.
Layer 5: 통합 보안 포스처
엔지니어링 조직이 가동 시간 대시보드와 보안 스코어카드로 전체 건강성을 보듯이 에이전트 함대에도 같은 뷰가 필요하다. Agent Security Dashboard는 Security Command Center를 기반으로 위협 탐지, 이상 탐지, 정책 집행, 위험 분석을 하나의 인터페이스로 통합한다.
보안 팀은 이 대시보드에서 다음 작업을 수행한다.
- 에이전트와 모델의 관계 맵핑
- 새 에이전트 자동 인벤토리와 평가
- OS와 언어 패키지의 CVE 스캔
- 다섯 계층 전체의 신호 상관 분석
“현재 AI 에이전트로부터의 전체 위험은 얼마인가”라는 CISO 질문에 단일 대시보드로 답한다.
의미와 시사점
다섯 계층은 Identity → Registry → Gateway → Detection → Unified Posture 순서로 쌓아야 한다.
| 계층 | 역할 | 전제 |
|---|---|---|
| Identity | 고유 ID와 권한 | 모든 상위 계층의 기반 |
| Registry | 도구 카탈로그와 승인 | Identity 기반 접근 통제 |
| Gateway | 중앙 정책 집행 | 정책 적용 대상 식별 필요 |
| Detection | 이상과 위협 탐지 | 에이전트별 베이스라인 필요 |
| Posture | 통합 가시성 | 하위 네 층의 신호 통합 |
조기 도입 조직은 복리식 이점을 얻는다. 새 에이전트가 자동으로 ID 모델, 정책 프레임워크, 모니터링 인프라를 상속하기 때문에 50번째 에이전트의 한계 비용이 거의 0에 수렴한다. 반대로 미루는 조직은 섀도 IT 때와 같은 함정을 반복한다. 관리되지 않는 에이전트가 늘어날수록 공격 표면, 감사 복잡도, 이행 비용이 함께 증가한다.
결론
Agent Governance Stack은 에이전트 배포를 “모델과 프롬프트 엔지니어링”에서 “IAM, 레지스트리, 게이트웨이, 관측”의 엔터프라이즈 운영 문제로 재정의한다. Google Cloud는 2015년 섀도 IT의 교훈을 반복하지 말고, 에이전트 함대를 엔지니어링 조직처럼 운영하자는 강력한 서사를 제시했다. Gemini Enterprise Agent Platform에 탑재된 다섯 계층은 컴플라이언스 중심 산업에서 에이전트 채택을 위한 현실적 기준선 역할을 맡을 것으로 보인다.