Agent Governance: L'Oréal이 사내 에이전트마다 접근 범위를 신원·정책·관측으로 묶어 통제하는 구조
Google Cloud가 에이전트마다 신원을 주고 승인 목록에 올린 뒤 모든 호출을 Agent Gateway로 지나가게 하는 거버넌스를 넓혔습니다. 여기에 에이전트·모델별 토큰 지출 귀속과 예산 가드레일을 더했습니다. L'Oréal은 이 구조로 Beauty Tech Agentic Platform의 에이전트별 접근을 통제한다고 밝혔습니다. 벤더 발표 글이며, 에이전트 대장 필드와 6주 도입 일정을 붙였습니다.
사내 에이전트가 늘어나면 "이 에이전트가 무엇에 닿을 수 있나"와 "토큰을 누가 얼마나 쓰나"를 한곳에서 정해야 합니다. Google Cloud의 답은 세 가지입니다. 에이전트마다 신원을 주고 승인 목록에 올린 뒤 모든 호출을 하나의 관문으로 지나가게 합니다. L'Oréal은 이 구조를 사내 에이전트 플랫폼의 기반으로 쓴다고 밝혔습니다. 옮기려면 제품보다 먼저 에이전트 대장과 에이전트별 허용 표가 있어야 합니다.
요약
이 글은 Google Cloud 인프라 팀(Nirav Mehta, Michael Bachman, Kevin Hutchins)이 2026년 10월 22일 AGNTCon + MCPCon에 맞춰 올린 제품 발표 글입니다. 벤더 블로그이므로 고객 사례도 자사 제품을 소개하는 맥락에서 나옵니다. 발표는 세 갈래입니다. 에이전트 전용 실행 환경인 Agent Compute Engine(앞으로 몇 달 안에 프리뷰), GKE에서 돌리는 오픈소스 실행 층 Agent Substrate, 그리고 Gemini for business 에이전트 거버넌스의 확장입니다. 이 노트는 세 번째 갈래, 곧 기업이 에이전트의 접근과 비용을 어떻게 통제하나에 초점을 둡니다. 거버넌스는 네 부품으로 짜여 있습니다. Agent Identity(에이전트별 신원), Agent Registry(승인 목록), Agent Gateway(모든 트래픽이 지나는 관문), Agent observability(호출 기록)입니다.
Google Cloud는 에이전트가 파일럿을 벗어나 여러 런타임에서 함께 돌기 시작하면 세 가지 과제가 생긴다고 봅니다. 에이전트·도구·모델·데이터 사이를 오가는 경로가 매번 달라 지키기 어렵습니다. 흩어진 런타임마다 기본 거부(default deny)와 최소 권한을 유지해야 합니다. 그리고 사람이 지켜보지 않는 사이에 일어난 행동을 나중에 감사할 수 있어야 합니다. 이를 놓치면 에이전트가 무분별하게 늘고(agent sprawl), 섀도 AI와 데이터 유출이 생긴다는 진단입니다. 이번 확장은 두 방향입니다. 같은 규칙이 닿는 범위를 다른 클라우드와 직원 PC의 코딩 에이전트까지 넓혔습니다. Agent Gateway에는 토큰·비용 거버넌스와 모델 라우팅을 더했습니다(이번 분기 프리뷰 예정). L’Oréal의 AI Lead Engineer Alexandre Frizzo는 사내 Beauty Tech Agentic Platform으로 에이전트가 일상 업무에 들어오고 있다고 말합니다. 그는 Google Cloud의 거버넌스가 Cloud Run 같은 런타임 전반에서 신원·정책·관측을 하나로 묶어 준다고 했습니다. 개발자는 더 빨리 만들고, 회사는 “clear control over what each agent can access”를 유지한다는 설명입니다. 성과 수치는 밝히지 않았습니다. 아래에서는 네 부품의 작동 방식을 풀고 우리 회사에 같은 통제를 세울 때 필요한 대장 필드, 정책 행렬, 예산 규칙, 일정을 덧붙입니다.
핵심 메커니즘
Agent Identity: 에이전트마다 따로 주는 신분증
에이전트 하나하나에 고유한 보안 ID를 주는 장치입니다. 표준은 오픈소스 SPIFFE(워크로드에 신원을 주는 개방형 표준)를 씁니다. 에이전트가 배포되면 ID가 붙습니다. 이 ID가 인증, 접근 제어, 감사 기록의 서명 역할을 합니다. Agent Compute Engine에서는 실행 공간(microVM)마다 그 에이전트의 신원과 짧게 사는 자격 증명이 붙습니다. 서비스 자격 증명은 microVM 밖, 나가는 트래픽(egress) 단계에서 주입됩니다. 에이전트 코드가 비밀 키를 직접 쥐지 않는다는 뜻입니다. 여러 에이전트가 사람 계정이나 공용 서비스 계정을 빌려 쓰고 있다면 이 단계부터 손봐야 합니다. 가상 예시로, 마케팅 카피 에이전트와 성분 조회 에이전트가 같은 계정을 쓰면 로그에서 둘을 구분할 수 없고, 한쪽 권한만 줄일 수도 없습니다.
Agent Registry: 승인된 것만 돌게 하는 단일 목록
승인된 채 돌아가는 에이전트, 도구, MCP 서버, 스킬, 모델, 엔드포인트를 모두 올려 두는 중앙 저장소입니다. 원문은 이를 진실의 원천(source of truth)이라 부릅니다. 그리고 여기에 붙은 정책으로 런타임 접근을 다스린다고 설명합니다. 목록에 없는 에이전트는 누가 만들었는지, 무엇을 부르는지 알 수 없는 섀도 AI가 됩니다. 에이전트가 열 개를 넘기 전에 만들어 두는 편이 쉽습니다. 이미 수십 개가 흩어져 있다면 클라우드 결제 내역과 API 키 발급 기록에서 거꾸로 찾아 등록하는 작업이 먼저 필요합니다.
Agent Gateway: 모든 호출이 지나는 관문과 두 겹 정책
원문은 Agent Gateway를 관제탑에 비유합니다. 사용자가 에이전트를 부르는 트래픽과 에이전트가 바깥 어디로든 나가는 트래픽이 모두 이곳을 지납니다. 여기서 민감 데이터 보호, 에이전트 공격 방어, semantic governance(의미 기반 통제), 자체 정책 연결(bring your own policy)이 적용됩니다. Google Cloud 정책 문서를 보면 정책은 두 겹입니다. IAM 정책은 어느 에이전트가 어느 에이전트·MCP 서버·엔드포인트와 통신해도 되는지를 allow와 deny로 정하고 IAP(Identity-Aware Proxy)로 집행합니다. Semantic governance 정책은 관리자가 자연어 제약(Natural Language Constraints)으로 규칙을 쓰고, 에이전트의 도구 호출이 사용자 의도와 업무 제약에 맞는지 확인합니다. 이번에 더한 Service Extensions bindings로 자사 함수나 파트너 서비스를 이 데이터 경로에 직접 끼울 수 있습니다. 사용자 권한 위임에는 Ping Identity, SailPoint, Saviynt 같은 외부 신원 관리 서비스를 붙입니다. Cloud Run에서는 Express Link로 에이전트가 닿아야 할 대상을 선언하면 인증된 연결과 신원 토큰 주입을 플랫폼이 맡습니다.
Token management와 모델 라우팅: 에이전트별 지출을 묶어 두는 장치
Agent Gateway에 새로 붙는 비용 통제 기능입니다(이번 분기 프리뷰 예정). 에이전트와 모델 전반의 토큰 소비를 관리합니다. 어느 에이전트와 어느 모델에서 지출이 나왔는지 귀속시키고 예산 가드레일을 걸며 토큰 지표의 기준을 한곳에 둡니다. 함께 나온 모델 라우팅 정책은 사용자와 에이전트의 요청을 알맞은 모델로 보내 비용을 줄이고 성능을 올립니다. 게이트웨이가 모든 호출의 길목에 있으니, 신원이 붙은 호출마다 토큰을 세어 에이전트 단위 청구서를 만들 수 있다는 구조입니다. 원문은 구체적인 한도 수치나 한도 도달 시 동작을 밝히지 않았습니다. 그래서 아래 기술 디테일에서 가상 예시로 구간을 정했습니다.
Agent observability: 비동기 행동을 나중에 따라가는 기록
OpenTelemetry(OTel, 관측 데이터의 개방형 표준) 형식으로 기록을 남기는 기능입니다. 생성형 AI용 시맨틱 규약을 따라 모델 호출, 도구 호출, 에이전트 간 이동(hop)마다 메트릭·로그·분산 추적을 Agent Gateway에서 내보냅니다. 에이전트는 사람이 자리를 비운 사이에도 움직이므로, 사후에 “어느 에이전트가 무엇을 근거로 무엇을 불렀나”를 재구성할 수 있어야 감사가 됩니다. 표준 형식이라 이미 쓰는 관측 도구로 보낼 수 있습니다. 반대로 에이전트가 게이트웨이를 거치지 않고 직접 API를 부르면 이 기록에 잡히지 않습니다. 그래서 우회 경로를 막는 일이 기록보다 먼저입니다.
통념과 다른 주장
흔히 이렇게 봅니다에이전트를 안전하게 쓰는 일은 프롬프트 가드레일이나 모델 쪽 필터를 잘 거는 문제라고 봅니다.
저자는 이렇게 봅니다Google Cloud는 자율 에이전트를 안전하게 돌리는 일이 근본적으로 인프라 문제라고 봅니다. 한 번 묻고 답하는 방식에서 상호작용하는 에이전트로 넘어가면 실행과 통제의 방식 자체가 달라져야 한다는 주장입니다.
근거Gemini를 업무용 에이전트로 키우며 얻은 경험을 듭니다. 실행 공간을 하드웨어 수준에서 떼어 놓습니다. 자격 증명은 에이전트 밖에서 넣고 모든 호출을 신원이 붙은 채 한 관문으로 지나가게 하는 설계가 그 결과입니다.
흔히 이렇게 봅니다클라우드 벤더의 거버넌스는 그 벤더의 클라우드 안에서 도는 에이전트에만 걸린다고 봅니다.
저자는 이렇게 봅니다에이전트가 도는 곳이면 어디든 같은 규칙을 걸어야 한다고 봅니다. 대상은 다른 클라우드, 온프레미스, 직원 PC까지입니다.
근거Envoy 프록시 기반의 가벼운 정책 집행점을 다른 클라우드와 하이브리드 환경에 둡니다. Claude Code나 Antigravity CLI 같은 코딩 에이전트에는 관리 대상 단말의 OS 수준 샌드박스로 규칙을 건다고 밝혔습니다(둘 다 프리뷰 예정).
저자가 든 사례
L’Oréal: 사내 에이전트 플랫폼의 접근 통제
- 상황: L’Oréal은 에이전틱 AI를 직원 손에 쥐여 주겠다는 목표를 세웠습니다. Beauty Tech Agentic Platform으로 에이전트가 일상 업무에 들어오고 있습니다.
- 한 일: Google Cloud의 에이전트 거버넌스를 이 목표를 넓히는 기반으로 씁니다. Cloud Run 같은 런타임 전반에서 신원·정책·관측을 하나로 묶었습니다.
- 결과: 개발자는 더 빨리 만들고, 회사는 에이전트마다 무엇에 접근할 수 있는지 분명히 통제한다고 밝혔습니다. 수치·에이전트 수·적용 업무는 원문에서 밝히지 않았습니다.
- 연결: Agent Identity, Agent Gateway 정책, Agent observability가 함께 쓰인 사례입니다. 토큰 예산 기능을 쓴다는 언급은 없습니다.
Gemini 에이전트: Google이 먼저 쓰는 실행 환경
- 상황: Gemini를 업무용 에이전트로 전 세계 사용자에게 제공하려면 빠르게 뜨고 효율적으로 도는 실행 환경이 필요했습니다.
- 한 일: Agent Compute Engine의 microVM 위에서 대화형 에이전트 샌드박스를 돌립니다. 이 환경은 에이전트가 생각하는 동안이나 사람을 기다리는 동안에는 microVM을 멈췄다가 스냅숏에서 다시 띄웁니다.
- 결과: Gemini 담당 VP Gautham Thambidorai는 응답성, 하드웨어 격리, 작업 밀도를 얻었다고 말했습니다. 수치는 원문에서 밝히지 않았습니다.
- 연결: 자격 증명을 실행 공간 밖에서 주입하는 Agent Identity 설계의 출발점입니다.
Nous Research: 고객 인프라 안에서 에이전트별 격리
- 상황: Nous Research는 고객이 자기 인프라에 직접 배포하는 Hermes Enterprise를 만들면서 에이전트별 격리와 확장 가능한 접근 제어가 필요했습니다.
- 한 일: GKE용 오픈소스 Agent Substrate를 써서 두 요구를 애플리케이션이 아니라 플랫폼 층에서 처리했습니다.
- 결과: 컴퓨팅 자원을 아끼면서 에이전트 작업량이 늘어도 확장할 수 있다는 자신감을 얻었다고 CBO Hervé Bizira가 밝혔습니다. 수치는 원문에서 밝히지 않았습니다.
- 연결: 접근 통제를 에이전트마다 따로 짜지 않고 공통 층에 두는 설계의 사례입니다.
기술 디테일: 에이전트 접근과 비용을 실제로 묶으려면
아래 필드명, 임계값, 일정은 모두 가상 예시입니다. Google Cloud 제품을 쓰든 다른 게이트웨이를 쓰든 같은 순서로 준비할 수 있습니다.
Agent Registry를 채우려면 에이전트 한 개당 한 줄짜리 대장 항목을 먼저 정합니다. 최소 필드는 아래와 같습니다. owner가 비어 있거나 allowed_tools가 와일드카드(*)인 항목은 등록을 거부합니다.
{
"agent_id": "spiffe://corp.example/agents/copy-draft",
"display_name": "브랜드 카피 초안",
"owner": "마케팅팀 김OO",
"business_purpose": "제품 상세 문구 초안 작성",
"runtime": "cloud-run",
"allowed_tools": ["brand_copy_db.read"],
"allowed_models": ["model-small", "model-large"],
"data_class_max": "internal",
"write_actions": "human_approval",
"monthly_token_budget": 20000000,
"on_budget_exceeded": "route_to_small_model",
"review_due": "2027-01-31"
}Agent Identity로 바꾸려면 에이전트 코드나 환경 변수에 들어 있는 API 키를 찾아 회수하는 일이 먼저입니다. 에이전트는 자기 ID로만 게이트웨이에 붙습니다. 게이트웨이는 나가는 단계에서 대상 시스템의 자격 증명을 넣습니다. 에이전트가 도는 네트워크에서는 모델 API와 SaaS로 직접 나가는 트래픽을 방화벽으로 막고 게이트웨이 주소만 열어 둡니다. 키를 회수한 뒤 게이트웨이를 거치지 않는 호출이 하루라도 보이면, 아직 남은 키가 있다는 신호입니다.
정책을 기본 거부로 돌리려면 에이전트 × 도구 행렬을 만들고 허용 칸만 엽니다. 읽기와 쓰기를 다른 칸으로 나눕니다. ERP 전표 생성처럼 되돌리기 어려운 쓰기는 사람 승인 뒤에만 열어 둡니다. 처음 2주는 차단 없이 로그만 남기는 모드로 돌려, 정상 업무가 막힐 호출이 몇 건인지 셉니다.
Semantic governance 규칙을 쓰려면 자연어 제약을 짧고 검사 가능하게 씁니다. 가상 예시로 “고객 개인정보가 담긴 필드는 외부 이메일 도구로 보내지 않는다”, “가격 변경은 조회만 하고 제안 문서로 남긴다” 같은 문장입니다. 처음에는 정상 호출 50건과 위반 호출 20건을 섞은 시험 묶음을 만들어, 정상 호출이 막히는 비율(오탐)과 위반이 통과하는 비율(미탐)을 따로 봅니다. 오탐이 5%를 넘으면 문장을 더 좁게 고칩니다.
토큰 예산을 걸려면 지출을 에이전트 ID, 소속 팀, 비용 센터 세 키로 귀속시키고 월 단위로 묶습니다. 구간별 조치는 아래처럼 미리 정합니다. 한도에 닿았을 때 바로 끊으면 업무가 멈추므로, 먼저 작은 모델로 돌리고 상한을 넘을 때만 차단합니다.
기록으로 감사하려면 OTel 생성형 AI 규약의 속성(예: gen_ai.agent.id, gen_ai.request.model, gen_ai.usage.input_tokens, gen_ai.usage.output_tokens, gen_ai.tool.name)을 그대로 받아 에이전트별 일일 표를 만듭니다. 표에는 토큰 사용량, 거부된 호출 수, 대장에 없는 ID의 호출 수가 들어갑니다. 대장에 없는 ID의 호출이 1건이라도 나오면 그날 안에 담당자를 찾습니다.
현업 실행 디테일: 누가, 언제, 무엇을
| 역할 | 담당 | 하는 일 |
|---|---|---|
| AX 추진 PM | AX 추진 조직 | 에이전트 대장 운영, 주간 점검 주관 |
| 플랫폼 엔지니어 | 클라우드·인프라팀 | 신원 발급, 게이트웨이 경유 강제, 키 회수 |
| 보안 담당 | CISO 조직 | 정책 행렬 승인, semantic governance 규칙 검토 |
| 재무 담당 | FinOps·재무 | 팀별 토큰 예산 배정, 월간 지출 검토 |
| 에이전트 오너 | 현업 부서 | 업무 목적·필요 도구 신고, 분기마다 재승인 |
시작 전 준비물: 현재 돌고 있는 에이전트 목록(만든 사람, 쓰는 API 키, 붙은 데이터), 최근 3개월 모델 API 청구서, 데이터 등급표(공개·내부·기밀), 되돌리기 어려운 쓰기 작업 목록.
| 주차 | 할 일 | 산출물 |
|---|---|---|
| 1주 | 에이전트 전수 조사, 오너 지정 | 에이전트 대장 v1 |
| 2~3주 | 에이전트별 ID 발급, 코드 속 키 회수 | 키 회수 목록, 우회 호출 0건 확인 |
| 3~4주 | 정책 행렬을 로그 모드로 운영한 뒤 차단 전환 | 정책 행렬, 막힌 호출 목록 |
| 4~5주 | 토큰 귀속과 예산 구간 적용 | 팀별 예산표, 일일 지출 표 |
| 6주 | 결과 보고와 확대 판정 | 판정 보고서 |
점검 질문 (가상 예시)
- 이 에이전트가 없어지면 누가 알아차립니까? (오너 확인)
- 이 에이전트가 쓰는 도구 중 하나를 막으면 업무가 멈춥니까? (허용 범위 확인)
- 쓰기 작업 중 사람이 되돌릴 수 없는 것은 무엇입니까? (승인 단계 확인)
- 지난달 이 에이전트의 토큰 비용을 팀 단위로 말할 수 있습니까? (귀속 확인)
진행 판정 기준 (가상 예시): 대장에 오른 에이전트 비율 100%, 게이트웨이를 거치지 않는 호출 0건, 정상 업무 호출 차단률 2% 미만, 팀별 월 토큰 지출을 하루 안에 뽑을 수 있으면 다음 런타임이나 부서로 넓힙니다.
적용 제언. 에이전트 도입이 부서마다 따로 진행된 회사라면 이 작업은 보안 과제가 아니라 대장 정리 과제로 시작하는 편이 빠릅니다. 첫 대상은 고객 데이터나 ERP 쓰기에 닿는 에이전트입니다. L’Oréal처럼 사내 공용 에이전트 플랫폼을 이미 운영한다면 플랫폼 입구에 신원 발급과 대장 등록을 묶어, 등록하지 않으면 배포되지 않게 하는 것이 가장 적은 비용으로 섀도 AI를 줄이는 방법입니다. 토큰 예산은 재무가 한도를 정하고 AX 추진 조직이 구간별 조치를 정하는 식으로 역할을 나눠야 분기 말 비용 논쟁이 줄어듭니다. 특정 벤더 제품을 고르기 전에 이 대장과 행렬을 먼저 만들어 두면 어느 게이트웨이를 쓰든 그대로 옮겨 갈 수 있습니다.
원문 사례
| 항목 | 내용 |
|---|---|
| 글 | Google Cloud 블로그, 2026년 10월 22일, AGNTCon + MCPCon 발표 |
| 저자 | Nirav Mehta(VP 제품), Michael Bachman(VP/GM), Kevin Hutchins(VP 제품) |
| 성격 | 벤더 제품 발표 |
| 거버넌스 부품 | Agent Gateway, Agent Registry, Agent Identity(SPIFFE), Agent observability(OTel) |
| 적용 범위 | Agent Runtime, Cloud Run, Gemini 플랫폼 Agent Sandboxes, GKE, Agent Compute Engine(프리뷰), Envoy 기반 멀티클라우드·하이브리드(프리뷰 예정), 단말 코딩 에이전트 Claude Code·Antigravity CLI(프리뷰 예정) |
| Agent Gateway 신규 기능 | 토큰·비용 거버넌스, 모델 라우팅, Service Extensions bindings, 외부 신원 관리 연동(Ping Identity, SailPoint, Saviynt), Express Link for Cloud Run (이번 분기 프리뷰) |
| 실행 환경 | Agent Compute Engine: microVM, Titanium 기반 하드웨어 격리, microVM별 Hyperdisk, 몇 달 안에 프리뷰 |
| Agent Substrate 수치 | 최대 10배 컴퓨팅 밀도, 20만 에이전트 벤치마크에서 초당 500회 활성화, 중지·재개 500ms 미만 |
| 고객 발언 | L’Oréal(Alexandre Frizzo, AI Lead Engineer), Gemini(Gautham Thambidorai, VP & Google Fellow), Nous Research(Hervé Bizira, CBO) |
핵심 개념
- SPIFFE
- 워크로드마다 검증 가능한 신원을 주는 개방형 표준. 사람 계정 대신 에이전트 자체에 ID를 붙일 때 씁니다.
- default deny
- 명시적으로 허용한 것만 통과시키고 나머지는 모두 막는 원칙.
- agent sprawl
- 부서마다 에이전트를 따로 만들어 누가 무엇을 돌리는지 모르게 되는 상태.
- MCP 서버
- 에이전트가 외부 도구·데이터를 부를 수 있게 표준 방식으로 열어 둔 접속점.
- microVM
- 작은 가상 머신. 에이전트마다 따로 띄워 서로의 코드와 데이터를 떼어 놓습니다.
- Envoy
- 오픈소스 네트워크 프록시. 여기서는 다른 클라우드에 두는 정책 집행점으로 쓰입니다.
- Agent Substrate
- GKE에서 에이전트를 돌리는 오픈소스 실행 층. 쉬는 에이전트의 메모리를 스냅숏으로 남기고 머신을 반납합니다.
내 메모
TODO: 내 생각 추가
원문: Nirav Mehta, Michael Bachman, Kevin Hutchins, 「Introducing Agent Compute Engine and expanding agent governance」(Google Cloud 블로그, 2026.10.22). Google Cloud의 제품 발표 글입니다. L’Oréal·Gemini·Nous Research 관련 내용은 원문에 실린 발언에 있는 것만 옮겼습니다. 정책 두 겹(IAM allow·deny, semantic governance의 자연어 제약)은 Google Cloud 문서 「Policies overview」로 보강했습니다. 요약·메커니즘·통념과 다른 주장·사례·원문 사례 표는 원문 내용을 AX Review가 다시 정리했습니다. 기술·현업 디테일, JSON 예시, 정책 행렬, 예산 구간, 일정·판정 기준, 인포그래픽은 새로 작성했으며 그 안의 필드명과 숫자는 가상 예시입니다(OTel 속성 이름은 OpenTelemetry 생성형 AI 규약의 표기). 원문 전체는 Google Cloud 블로그에서 볼 수 있습니다.