AI 에이전트 거버넌스 2026 Google Cloud 5계층 체크리스트

AI 에이전트는 이제 데모가 아니라 운영 대상이 됐다.

처음에는 한두 개 스크립트였다.

문서 요약해줘.

슬랙에 보내줘.

GitHub 이슈 정리해줘.

검색해서 표 만들어줘.

이 정도일 때는 프롬프트만 잘 쓰면 되는 것처럼 보인다.

그런데 에이전트가 셋을 넘어가고, 도구가 다섯 개를 넘어가고, MCP 서버와 내부 API가 붙기 시작하면 문제가 바뀐다.

이제 질문은 “에이전트가 똑똑한가”가 아니다.

“이 에이전트가 누구 권한으로, 어떤 도구에, 어느 범위까지, 무슨 로그를 남기며 접근하는가”다.

Google Cloud Next 2026에서 나온 AI 에이전트 거버넌스 메시지도 이쪽에 가깝다.

Gemini Enterprise Agent Platform, Agent Identity, Agent Registry, Agent Gateway, Model Armor, Observability.

제품 이름은 많지만 운영 관점으로 줄이면 하나다.

AI 에이전트를 임시 자동화가 아니라 작은 엔지니어 조직처럼 다루라는 말이다.

TECHTAEK식으로 번역하면 더 간단하다.

에이전트마다 사번을 붙이고, 허용 도구 목록을 만들고, 도구 호출은 게이트를 통과시키고, 위험한 입출력은 필터링하고, 나중에 무슨 일이 있었는지 볼 수 있게 남겨라.

거창해 보이지만 작은 팀도 오늘 바로 시작할 수 있다.

클라우드 제품을 당장 사라는 뜻이 아니다.

먼저 운영표를 만들라는 뜻이다.

결론 먼저

Google Cloud의 AI 에이전트 거버넌스 스택은 개발자에게 이런 질문을 던진다.

질문	Google Cloud 쪽 표현	작은 팀 버전
이 에이전트는 누구인가	Agent Identity	에이전트별 owner, 목적, 권한
어떤 에이전트와 도구가 있는가	Agent Registry	agent/tool/MCP 인벤토리
도구 호출은 어디서 막는가	Agent Gateway	실행 전 승인 게이트
프롬프트 인젝션과 민감정보는 누가 막는가	Model Armor	입출력 필터와 금지 데이터 규칙
사고가 나면 무엇을 복기하는가	Observability	로그, trace, 실행 결과, 변경 기록

핵심은 모델 선택이 아니다.

Claude를 쓰든, Gemini를 쓰든, OpenAI 모델을 쓰든, 로컬 LLM을 쓰든, 운영 문제는 비슷하게 온다.

에이전트가 늘어나면 프롬프트보다 권한표가 중요해진다.

MCP 서버가 늘어나면 도구 설명보다 호출 경계가 중요해진다.

자동 실행이 늘어나면 성공률보다 감사 로그가 중요해진다.

그 지점에서 AI 에이전트 거버넌스 2026의 첫 번째 실무 기준은 다음 문장이다.

허용되지 않은 에이전트는 실행하지 않는다.

허용되지 않은 도구는 호출하지 않는다.

기록되지 않은 자동화는 운영으로 보지 않는다.

왜 지금 거버넌스인가

Google Cloud Next 2026 공식 정리에서 Google은 agentic enterprise 전환을 전면에 세웠다.

공식 컬렉션은 Google Cloud 고객의 AI 제품 사용, 대규모 토큰 처리량, Gemini Enterprise Agent Platform 같은 흐름을 Cloud Next의 핵심 하이라이트로 묶었다.

여기서 중요한 건 숫자 자체보다 방향이다.

에이전트는 이제 개인 생산성 도구에만 머무르지 않는다.

업무 데이터에 접근한다.

내부 API를 호출한다.

다른 에이전트와 통신한다.

장기 메모리를 쌓는다.

코드를 실행한다.

브라우저나 GUI를 조작한다.

그 순간부터 에이전트는 “대화창”이 아니라 권한을 가진 실행 주체가 된다.

실행 주체에는 신원이 필요하다.

신원이 있으면 권한이 필요하다.

권한이 있으면 경계가 필요하다.

경계가 있으면 로그가 필요하다.

로그가 있으면 복기와 개선이 가능해진다.

이게 거버넌스다.

말은 딱딱하지만, 실무에서는 그냥 “사고 났을 때 설명 가능한 상태”다.

설명할 수 없으면 자동화가 아니라 운이다.

운으로 굴러가는 자동화는 처음엔 빨라 보이고 나중엔 비싸진다.

Google Cloud 5계층을 운영표로 번역하기

Google Cloud 세션 페이지는 AI agents를 신뢰 가능한 구조로 운영하려면 Zero Trust, Agent Identity, IAM, policy-based controls, Model Armor 기반 런타임 방어가 필요하다고 설명한다.

문서 쪽으로 내려오면 Gemini Enterprise Agent Platform은 Agent Registry, Agent Gateway, Observability, Evaluation, Memory Bank, Code Execution 같은 구성요소로 쪼개진다.

이걸 작은 팀 버전으로 바꾸면 다섯 계층이다.

계층	목적	최소 산출물
Identity	에이전트를 식별한다	agent registry 한 줄
Registry	에이전트와 도구 목록을 관리한다	tools inventory
Gateway	실행 경로를 통제한다	allow/deny checklist
Runtime Defense	위험한 입출력을 막는다	prompt injection, PII 규칙
Observability	실행 결과를 복기한다	run log, failure log, trace note

여기서부터는 각 계층을 개발자 관점으로 풀어보자.

1. Agent Identity는 에이전트 사번이다

Agent Identity 문서는 에이전트마다 고유한 cryptographic identity를 부여하고, SPIFFE 기반 식별자를 사용한다고 설명한다.

중요한 포인트는 공유 서비스 계정이 아니라 에이전트 자체를 principal로 본다는 점이다.

이건 꽤 큰 차이다.

예전 자동화에서는 대충 이런 식이 많았다.

하나의 service account를 만들고, 여러 자동화가 같이 쓴다.

환경 변수에 키를 넣는다.

스크립트마다 같은 키를 재사용한다.

잘 돌아가면 아무도 안 건드린다.

문제는 사고가 났을 때다.

어떤 자동화가 호출했는지 모른다.

누가 만든 자동화인지 모른다.

어떤 권한이 실제로 필요한지 모른다.

키가 너무 넓게 열려 있어도 무서워서 못 줄인다.

Agent Identity가 던지는 메시지는 이거다.

에이전트 하나를 하나의 실행 주체로 보라.

작은 팀에서는 SPIFFE나 mTLS까지 당장 붙이지 못해도 된다.

대신 이 표부터 만들면 된다.

agent_id	목적	owner	읽기 범위	쓰기 범위	외부 호출	로그 위치
blog-writer	초안 작성	콘텐츠 담당	Inbox, blog notes	draft path	web search	review log
blog-publisher	발행	운영 담당	reviewed draft	WP/Blogger	Telegram	publish contract
agent-ops	점검	시스템 담당	.claude	report only	none	ops report

이 표가 없으면 에이전트가 늘어날수록 “누가 뭘 할 수 있지?”가 흐려진다.

흐려진 권한은 대체로 넓어진 권한이다.

넓어진 권한은 언젠가 비용이나 사고로 돌아온다.

2. Agent Registry는 에이전트와 도구의 주소록이다

Agent Registry 문서는 조직 안의 AI agents, MCP servers, tools를 저장하고, 찾고, 관리하는 통합 catalog로 설명한다.

이 말도 작은 팀 기준으로 바꾸면 쉽다.

내 에이전트가 어떤 도구를 쓰는지 한 군데서 볼 수 있어야 한다.

MCP 서버가 몇 개인지 한 군데서 볼 수 있어야 한다.

각 도구가 읽기만 하는지 쓰기까지 하는지 한 군데서 볼 수 있어야 한다.

등록되지 않은 도구는 기본적으로 쓰지 않는다고 정해야 한다.

이게 Registry의 실무 의미다.

MCP를 붙일 때 특히 중요하다.

MCP 서버는 편하다.

하지만 편하다는 말은 모델이 더 많은 것을 할 수 있다는 뜻이다.

파일을 읽을 수 있다.

브라우저를 열 수 있다.

데이터베이스를 조회할 수 있다.

티켓을 만들 수 있다.

클라우드 리소스를 건드릴 수 있다.

이걸 전부 “도구가 생겼다”로만 보면 위험하다.

“실행 가능한 권한 표면이 늘었다”로 봐야 한다.

작은 팀용 Registry는 아래 정도면 충분하다.

tool_id	유형	read/write	허용 agent	금지 경로	승인 필요	비고
obsidian-helper	filesystem	write	inbox-organizer	secrets, env	yes	no-focus 우선
wp-publisher	external API	write	blog-publisher	draft 미검수	yes	publish contract 필요
browser-use	GUI/browser	read/write	QA only	계정 설정	yes	명시 요청 때만
web-search	network	read	writer, reviewer	paywalled copy	no	최신성 검증

이 표 하나만 있어도 에이전트 운영이 훨씬 덜 흐려진다.

문제가 생겼을 때도 어느 도구를 막아야 하는지 보인다.

3. Agent Gateway는 도구 호출 톨게이트다

Agent Gateway 문서는 에이전트와 도구, 에이전트와 다른 시스템 사이의 트래픽을 정책으로 통제하는 지점으로 설명한다.

특히 두 방향이 중요하다.

Client-to-Agent.

즉 사용자나 클라이언트가 에이전트로 들어오는 경로다.

Agent-to-Anywhere.

즉 에이전트가 외부 도구, MCP 서버, 다른 에이전트, API로 나가는 경로다.

실무에서 더 자주 사고가 나는 쪽은 두 번째다.

에이전트가 어디론가 나간다.

검색한다.

파일을 읽는다.

API를 호출한다.

외부 MCP 서버에 요청을 보낸다.

그때 Gateway가 없으면 정책은 프롬프트 안에만 있다.

프롬프트 안의 정책은 운영 정책으로 부족하다.

모델은 지시를 따르지만, 실행 환경이 허용하면 실수도 실행될 수 있다.

작은 팀의 Gateway는 처음부터 대단할 필요가 없다.

아래 세 가지면 시작할 수 있다.

실행 전 체크
위험 작업 승인
실행 후 로그

예를 들어 블로그 발행 에이전트라면 Gateway 체크는 이렇게 된다.

단계	통과 조건	실패 시
draft	idea_id, channel, focus keyphrase 존재	drafting 중단
review	preflight PASS, reviewer PASS	publish 금지
publish	update-url 또는 new-post 경로 명확	수동 확인
post-publish	URL, status, Telegram, contract 기록	mark-published 보류

이 정도만 해도 “초안인데 발행됨”, “리뷰 실패인데 발행됨”, “URL은 있는데 시트는 backlog”, 같은 사고가 줄어든다.

운영에서 진짜 무서운 건 큰 장애 하나보다 작은 불일치가 계속 쌓이는 것이다.

Gateway는 그 불일치를 줄이는 장치다.

4. Model Armor는 프롬프트 인젝션과 민감정보 방어선이다

Model Armor 문서는 Agent Gateway가 관리하는 통신 경로 안에서 요청과 응답을 검사하고, 정책을 위반한 콘텐츠를 차단하거나 민감정보를 redaction할 수 있다고 설명한다.

여기서 중요한 점은 검사가 에이전트 바깥 경로에 붙는다는 것이다.

에이전트에게 “민감정보를 말하지 마”라고 쓰는 것과 게이트웨이에서 실제 payload를 검사하는 것은 다르다.

프롬프트 규칙은 의도다.

런타임 필터는 통제다.

둘 다 필요하지만 역할이 다르다.

작은 팀에서 Model Armor를 그대로 쓰지 않더라도 비슷한 운영 원칙은 만들 수 있다.

먼저 금지 데이터 목록을 둔다.

데이터	본문 사용	로그 저장	외부 전송
API key	금지	금지	금지
env 파일	금지	금지	금지
고객 PII	익명화 후 가능	최소화	승인 필요
계좌 정보	마스킹	마스킹	금지
내부 비용표	요약 가능	제한	승인 필요

그다음 입출력 체크를 둔다.

발행 전에는 source URL이 과도하게 인용되지 않았는지 본다.

코드 리뷰 전에는 .env, token, secret이 diff에 섞이지 않았는지 본다.

브라우저 자동화 전에는 로그인 세션이나 결제 화면을 건드리지 않는지 본다.

리서치 자동화 전에는 저작권 있는 본문을 길게 복사하지 않는지 본다.

이게 작은 팀 버전의 Model Armor다.

화려하지 않지만 잘 먹힌다.

5. Observability는 “에이전트가 뭘 했는지” 보는 눈이다

Observability 문서는 Gemini Enterprise Agent Platform에서 metrics, traces, logs, agent topology, MCP server metrics 같은 신호를 제공한다고 설명한다.

운영자는 특정 agent를 Registry에서 선택해 상태와 성능, 인프라 사용량을 볼 수 있다.

이걸 개인 또는 작은 팀 기준으로 바꾸면 실행 기록과 실패 기록이다.

에이전트가 뭘 했는지 남겨야 한다.

어떤 입력을 받았는지 남겨야 한다.

어떤 도구를 호출했는지 남겨야 한다.

어디서 실패했는지 남겨야 한다.

어떤 복구를 했는지 남겨야 한다.

그리고 다음번에 같은 실패를 줄일 수 있어야 한다.

예를 들어 블로그 파이프라인에서는 이런 로그가 필요하다.

이벤트	남길 값
draft_started	idea_id, file path, channel
preflight	PASS/FAIL, fail reason
review	PASS/FAIL, channel_fit, report path
publish	platform, post_id, URL
push	Telegram success/fail
sheet_sync	backlog count, published count
contract	open/closed, missing item

이런 값이 있으면 발행 파이프라인이 “잘 된 것 같다”에서 “어디까지 닫혔다”로 바뀐다.

운영자는 감으로 일하지 않는다.

체크포인트로 일한다.

개인 자동화에 바로 적용하는 최소 거버넌스

이제 제품 이야기를 내려놓고 내 워크스페이스에 바로 적용해보자.

아래 네 파일이면 시작할 수 있다.

agents-inventory.md
tools-inventory.md
execution-gateway.md
run-log.md

내용은 단순하게 간다.

agents-inventory.md에는 에이전트 이름, 목적, owner, 읽기 범위, 쓰기 범위, 외부 API 사용 여부를 쓴다.

tools-inventory.md에는 도구 이름, 읽기/쓰기, 허용 에이전트, 승인 필요 여부, 금지 경로를 쓴다.

execution-gateway.md에는 실행 전 조건, 실행 중 금지 행동, 실행 후 기록 조건을 쓴다.

run-log.md에는 날짜, 작업, 도구, 결과, 실패, 다음 조치를 쓴다.

이 네 개가 있으면 작은 팀에서도 거버넌스의 뼈대가 생긴다.

처음부터 완벽한 보안 플랫폼이 없어도 된다.

대신 아래 질문에 답할 수 있어야 한다.

오늘 실행한 에이전트는 누구인가.

무슨 권한으로 실행했는가.

어떤 도구를 호출했는가.

어떤 데이터를 읽거나 썼는가.

실패하면 어디서 멈췄는가.

다시 실행해도 같은 결과가 나는가.

이 질문에 답하지 못하면 거버넌스가 없는 상태다.

Google Cloud식 계층을 .claude 운영에 대입하면

이 워크스페이스처럼 .claude/agents, .claude/skills, .claude/commands, .claude/rules, .claude/scripts가 있는 구조라면 거버넌스 매핑이 꽤 자연스럽다.

Google Cloud 개념	.claude 운영 매핑
Agent Identity	agent md의 name, owner, scope
Agent Registry	`.claude/agents/`, `.claude/skills/` 목록
Agent Gateway	AGENTS.md, rules, script preflight
Policy controls	허용 도구, 금지 경로, no-focus 규칙
Model Armor	secret/PII/저작권/외부 발행 체크
Observability	review report, publish contract, sync log

핵심은 문서가 실행과 연결되어야 한다는 점이다.

역할 설명만 있으면 약하다.

하네스가 있어야 한다.

검증 스크립트가 있어야 한다.

상태 파일이 있어야 한다.

실패했을 때 다시 이어갈 수 있어야 한다.

Google Cloud가 Agent Platform에서 말하는 runtime, gateway, registry, observability도 결국 이 구조다.

큰 조직은 클라우드 제품으로 한다.

작은 팀은 파일과 스크립트로 시작한다.

목적은 같다.

자동화를 설명 가능한 시스템으로 만드는 것.

도입 순서는 이렇게 잡는 게 안전하다

처음부터 모든 걸 다 만들려고 하면 거버넌스가 또 하나의 거대한 문서 무덤이 된다.

작게 시작하자.

1단계: 에이전트 목록부터 고정한다

현재 실제로 쓰는 에이전트만 적는다.

안 쓰는 에이전트는 빼라.

미래에 쓸지도 모르는 것은 빼라.

운영표는 욕망의 박물관이 아니라 오늘의 통제판이어야 한다.

각 에이전트마다 목적, owner, 읽기 범위, 쓰기 범위, 외부 호출 여부를 적는다.

2단계: 쓰기 권한 도구만 먼저 관리한다

모든 도구를 한 번에 정리하려고 하면 지친다.

먼저 쓰기 권한이 있는 도구만 본다.

파일을 수정하는 도구.

글을 발행하는 도구.

브라우저에서 클릭하는 도구.

외부 API를 호출하는 도구.

이 네 종류만 먼저 잡아도 위험이 많이 줄어든다.

3단계: 승인 게이트를 문장으로 만든다

복잡한 정책 엔진이 없어도 된다.

처음에는 문장으로 충분하다.

리뷰 PASS 전에는 발행하지 않는다.

secret이 보이면 즉시 중단한다.

외부 브라우저 조작은 명시 요청 때만 한다.

유료 리소스 생성은 승인 없이 하지 않는다.

운영 규칙은 짧고, 테스트 가능하고, 실패 조건이 분명해야 한다.

4단계: 로그를 표준화한다

로그는 길 필요가 없다.

하지만 매번 같은 형식이어야 한다.

date:
agent:
task:
tools:
result:
blocked_by:
next_action:

이 정도면 된다.

이 형식이 쌓이면 나중에 대시보드로 바꿀 수 있다.

처음부터 대시보드를 만들 필요는 없다.

로그가 먼저다.

언제 Google Cloud 같은 플랫폼이 필요한가

작은 팀은 파일과 스크립트로 시작해도 된다.

하지만 아래 조건이 생기면 플랫폼형 거버넌스를 검토할 때다.

신호	이유
에이전트가 10개 이상	수동 inventory가 자주 틀린다
외부 MCP 서버가 많다	도구 신뢰 경계가 흐려진다
고객 데이터에 접근한다	PII, 감사, 접근제어가 필요하다
사용자 대신 OAuth 작업을 한다	delegated authority 추적이 필요하다
여러 팀이 같은 agent/tool을 쓴다	registry와 owner 충돌이 생긴다
장애 복기가 반복된다	trace, logs, metrics가 필요하다

반대로 아래 상태라면 아직 거창한 플랫폼은 과할 수 있다.

에이전트가 한두 개다.

모두 로컬 파일만 읽는다.

외부 쓰기 작업이 없다.

고객 데이터가 없다.

수동 승인 후에만 실행한다.

로그가 충분히 남는다.

이 경우에는 먼저 운영표부터 만들면 된다.

도구를 사기 전에 운영 습관을 사야 한다.

이상한 말 같지만 대체로 맞다.

가장 자주 생기는 실패 패턴

1. 에이전트를 사람처럼 믿는다

에이전트는 협업자처럼 보이지만 운영에서는 권한을 가진 프로세스다.

사람처럼 믿기 전에 프로세스처럼 제한해야 한다.

칭찬은 나중에 하고 권한표부터 줘라.

2. MCP 서버를 기능 목록으로만 본다

MCP 서버는 기능 목록이 아니다.

실행 가능한 도구 경계다.

특히 filesystem, browser, database, cloud, publisher 계열은 쓰기 권한을 따로 표시해야 한다.

3. 프롬프트 정책을 보안 정책으로 착각한다

프롬프트에 “하지 마”라고 쓰는 건 필요하다.

하지만 충분하지 않다.

실행 환경에서 막을 수 있는 것은 실행 환경에서 막아야 한다.

4. 로그가 산문으로만 남는다

복기는 산문으로 해도 된다.

하지만 운영 로그는 구조화되어야 한다.

날짜, 에이전트, 도구, 결과, URL, 실패 이유.

이 값들은 나중에 검색 가능해야 한다.

5. owner가 없다

에이전트에 owner가 없으면 개선도 없다.

누가 권한을 줄이고, 누가 로그를 보고, 누가 실패를 고칠지 정해야 한다.

owner 없는 자동화는 대부분 방치된다.

30분 점검표

오늘 바로 할 수 있는 점검은 이 정도다.

점검	통과 기준
에이전트 목록	실제 운영 중인 agent만 적혀 있다
owner	각 agent마다 담당자가 있다
읽기 범위	어떤 폴더와 서비스에 접근하는지 적혀 있다
쓰기 범위	파일 수정, 발행, API 호출 여부가 분리되어 있다
도구 목록	MCP, script, browser, publisher가 한 표에 있다
승인 게이트	발행, 결제, 삭제, 외부 전송 전 조건이 있다
민감정보 규칙	secret, PII, 계좌, 내부 비용표 처리 기준이 있다
로그 위치	성공과 실패가 같은 위치에 쌓인다
복구 절차	실패 후 재시작 기준이 있다
비활성화 기준	오래 안 쓰는 agent를 끄는 기준이 있다

다 통과하지 않아도 된다.

처음에는 절반만 통과해도 이미 많은 팀보다 앞서 있다.

중요한 건 안 보이던 권한을 보이게 만드는 것이다.

TECHTAEK 운영 판단

이 주제는 단순히 “Google Cloud가 새 제품을 냈다”로 끝내면 약하다.

검색 수요도, 실무 가치도, TECHTAEK 허브 가치도 운영표로 바꿀 때 살아난다.

독자가 궁금한 건 제품명이 아니다.

내 Claude Code 팀에도 필요한가.

내 MCP 서버도 registry가 필요한가.

작은 팀도 gateway를 만들어야 하나.

Model Armor 같은 런타임 필터가 없으면 뭘 해야 하나.

발행, 배포, 브라우저 자동화 전에 뭘 막아야 하나.

이 질문에 답해야 한다.

그래서 이 글의 결론은 제품 추천이 아니다.

에이전트가 셋 이상이면 inventory를 만들고, 쓰기 도구가 하나라도 있으면 gateway 체크를 만들고, 외부 데이터가 오가면 runtime defense를 만들고, 반복 작업이면 observability를 만들자.

이 네 줄이면 AI 에이전트 거버넌스의 첫 단추는 채운 것이다.

FAQ

AI 에이전트 거버넌스는 대기업만 필요한가?

아니다.

대기업은 플랫폼이 필요하고, 작은 팀은 운영표가 먼저 필요하다.

에이전트가 파일을 쓰거나, 외부 API를 호출하거나, 발행 버튼을 누른다면 작은 팀도 최소한의 거버넌스가 필요하다.

Agent Identity를 꼭 SPIFFE로 구현해야 하나?

처음부터 그럴 필요는 없다.

Google Cloud 문서는 SPIFFE 기반 identity와 cryptographic credential을 설명하지만, 작은 팀은 먼저 agent_id, owner, scope, allowed tools부터 고정하면 된다.

다만 고객 데이터나 여러 팀이 얽히는 순간에는 플랫폼 수준의 identity를 검토할 만하다.

Agent Registry는 MCP 서버 목록과 같은 말인가?

부분적으로는 맞다.

하지만 더 넓다.

Agent Registry는 에이전트, MCP 서버, tools, 엔드포인트를 함께 보는 catalog에 가깝다.

작은 팀에서는 도구 목록과 에이전트 목록을 한 표로 묶는 것부터 시작하면 된다.

Gateway가 없으면 프롬프트로 막으면 되지 않나?

프롬프트는 필요하지만 그 자체로 충분한 통제 장치는 아니다.

위험한 쓰기 작업, 외부 전송, 고객 데이터 접근, 발행, 삭제 같은 행동은 실행 전 체크와 권한 제한으로 막는 편이 안전하다.

Model Armor 같은 기능이 없으면 무엇을 해야 하나?

먼저 금지 데이터 목록을 만들면 된다.

API key, env, PII, 계좌 정보, 내부 비용표 같은 항목을 정하고 본문, 로그, 외부 전송에서 어떻게 처리할지 표로 고정한다.

그다음 preflight, review, publisher 단계에 체크를 넣으면 된다.

이 구조가 Claude Code나 Codex에도 적용되나?

적용된다.

제품 이름은 달라도 에이전트 운영 문제는 비슷하다.

subagents, skills, MCP servers, browser automation, publisher scripts가 붙는 순간 신원, 권한, 게이트, 로그가 필요해진다.

참고 자료

핵심은 단순하다.

AI 에이전트가 많아질수록 똑똑함보다 설명 가능성이 먼저다.

설명 가능한 에이전트만 오래 운영할 수 있다.

운영표 없이 자동화만 늘리면 처음엔 빨라지고 나중엔 불안해진다.

그러니 오늘 할 일은 하나다.

에이전트에게 이름표를 붙이자.

그 다음에 도구를 붙여도 늦지 않다.

Google Cloud AI 에이전트 거버넌스 5계층 2026 – Agent Identity·Registry·Gateway·Model Armor 운영 체크리스트