Gemini는 왜 모델보다 Agent Runtime을 팔기 시작했나: Google Agent Platform 실전 구조
Gemini는 왜 모델보다 Agent Runtime을 팔기 시작했나: Google Agent Platform 실전 구조
생성형 AI 초기에는 좋은 모델 하나만 붙이면 제품을 만들 수 있을 것처럼 보였다.
User
↓
LLM
↓
Answer조금 발전하면 Tool을 연결했다.
User
↓
Gemini
↓
Function Calling
↓
API그다음에는 RAG를 붙였다.
User
↓
Gemini
↓
Retriever
↓
회사 문서여기까지는 여전히 중심이 모델이었다.
하지만 Agent가 실제 업무를 맡기 시작하면 문제가 달라진다.
예를 들어 다음 Agent를 만든다고 하자.
영업 Agent
- 고객 조사
- CRM 조회
- 메일 초안 작성
- 후속 일정 생성
- 다음 주 다시 확인이 Agent가 5분짜리 Demo가 아니라 며칠 동안 실제 업무를 수행하려면 모델만으로 해결할 수 없는 문제가 생긴다.
Agent Process가 죽으면?
어제 작업한 상태는 어디에 저장할까?
사용자 선호는 다음 Session에서 어떻게 기억할까?
Agent가 어떤 권한으로 Salesforce를 호출할까?
다른 Agent에게 업무를 위임할 수 있을까?
수백 개 Agent 중 어떤 Agent를 호출해야 할까?
Agent가 이상하게 행동하면 어디서 차단할까?
누가 어떤 Tool을 호출했는지 추적할 수 있을까?이 시점부터 중요한 것은
Gemini가 얼마나 똑똑한가?보다
Gemini 기반 Agent를
어떻게 오래 실행하고,
기억시키고,
연결하고,
통제하고,
관찰할 것인가?가 된다.
Google이 2026년 Gemini Enterprise Agent Platform에서 강조하고 있는 것도 정확히 이 부분이다.
Google은 Agent Platform을 크게 네 축으로 나눈다.
BUILD
SCALE
GOVERN
OPTIMIZE그리고 그 안에 다음 기능을 배치한다.
ADK
Agent Runtime
Sessions
Memory Bank
Agent Identity
Agent Registry
Skill Registry
Agent Gateway
Model Armor
Agent Simulation
Evaluation
Observability이제 Agent 개발의 경쟁 영역이 단순히 Model API 호출에서 Agent Runtime Infrastructure로 이동하고 있다는 뜻이다.
이번 글에서는 Gemini Enterprise Agent Platform을 기준으로 실제 Agent System을 어떻게 구성할 수 있는지 하나씩 정리해본다.
1. Google Agent Platform을 한 장으로 보면
전체 구조는 대략 다음과 같다.
User
│
▼
Gemini App
│
▼
Agent
│
┌───────────┼───────────┐
│ │ │
▼ ▼ ▼
Memory Skills Tools
│ │ │
└───────┬───┴────┬──────┘
│ │
▼ ▼
Agent Runtime
│
▼
Agent Gateway
│
┌────────┼─────────┐
│ │ │
▼ ▼ ▼
MCP A2A APIs
│ │ │
▼ ▼ ▼
Tools Agents Systems그리고 관리 계층이 따로 있다.
Agent Identity
Agent Registry
Skill Registry
Model Armor
Observability
Evaluation이 구조를 보면 Google이 왜 더 이상 모델만 이야기하지 않는지 이해하기 쉽다.
2. Agent Runtime이 왜 필요한가
일반적인 API Server에서 Agent를 직접 돌릴 수도 있다.
예:
agent = MyAgent()
result = await agent.run(task)문제는 Production이다.
Agent가 30초가 아니라 3시간 동안 작업한다면 어떻게 할까?
Agent 실행
↓
20분 후 외부 API 대기
↓
1시간 뒤 다음 Task
↓
다른 Agent에게 위임
↓
사용자 승인 대기
↓
작업 재개일반 HTTP Request 하나로 처리하기 어렵다.
그래서 Agent Runtime이 필요하다.
3. Google Agent Runtime의 역할
Agent Runtime은 단순히 Agent Python Script를 실행하는 Server가 아니다.
다음 같은 문제를 맡는다.
Agent 실행
Session 관리
Long-running Task
Memory 연결
Code Execution
Scaling
Observability
Identity
Security즉 기존 Web Application에서
Application Server가 하던 역할보다 범위가 넓다.
4. Long-running Agent가 중요한 이유
Google은 Agent Runtime에서 며칠 동안 지속되는 Agent Workflow를 강조하고 있다.
예를 들어 영업 Agent라면:
Day 1
잠재 고객 조사↓
Day 1
메일 초안 생성↓
Day 2
답장 확인↓
Day 3
후속 작업 생성↓
Day 5
CRM 업데이트이런 Workflow가 가능해야 한다.
Agent가 매번 처음부터 다시 시작해서는 안 된다.
5. 그래서 Session과 Memory를 분리한다
여기서 중요한 구조가 등장한다.
Google은
Session과
Memory Bank를 분리한다.
두 개는 같은 것이 아니다.
6. Session은 현재 대화의 상태다
Session은 하나의 Conversation History에 가깝다.
Session 142
User:
다음 주 고객 미팅 준비해줘.
Agent:
지난 미팅 기록을 확인하겠습니다.
Tool:
CRM 조회
Agent:
세 가지 안건을 준비했습니다.이 Conversation의 흐름을 저장한다.
7. Memory Bank는 Session을 넘어선 장기 기억이다
Memory Bank는 여러 Session 사이에서 필요한 정보를 기억한다.
예:
사용자는
짧은 보고서를 선호함
A 고객은
가격보다 안정성을 중요하게 봄
계약 갱신은
매년 10월다음 Session에서 Agent가 다시 활용할 수 있다.
Session 201
↓
Memory Search
↓
관련 기억
↓
현재 Context8. Context Window와 Memory를 분리한다
앞서 다룬 File System Memory와도 연결된다.
Agent Runtime에서는 다음 구조가 자연스럽다.
Current Context
→ Working MemorySession
→ Conversation StateMemory Bank
→ Long-term Memory셋을 하나로 생각하지 않는다.
9. Memory Bank의 중요한 점은 저장보다 “생성·검색”이다
단순 Key-Value Store라면 Redis나 Database로도 만들 수 있다.
하지만 Agent Memory에서는 이런 과정이 필요하다.
Conversation
↓
무엇을 기억할지 추출
↓
Memory 생성
↓
Embedding
↓
저장
↓
다음 Session에서 검색Google은 이 전체 흐름을 Managed Service로 제공하려는 방향이다.
10. Memory에 모든 Conversation을 그대로 넣으면 안 된다
좋지 않은 구조:
모든 Chat
↓
Memory Bank이렇게 하면 다음 문제가 생긴다.
중복
오래된 정보
잘못된 정보
민감 정보
비용 증가Memory는 정리된 상태여야 한다.
예:
{
"type": "user_preference",
"key": "report_style",
"value": "concise",
"confidence": 0.92
}11. Agent Identity가 중요해지는 시점
Agent가 답변만 할 때는 사용자 Identity만 있으면 됐다.
하지만 Agent가 직접 행동하면 문제가 달라진다.
예를 들어:
Sales Agent
→ Salesforce 조회Finance Agent
→ 비용 데이터 조회Release Agent
→ GitHub CI 조회각 Agent가 누구인지 시스템이 알아야 한다.
12. Agent도 Identity를 가져야 한다
Google Agent Platform의 Agent Identity는 Agent 자체에 고유 Identity를 부여하는 방향이다.
개념적으로:
User Identity
lee@example.com와
Agent Identity
sales-agent-prod를 분리한다.
13. 왜 Agent Identity가 필요한가
다음 Log가 있다고 하자.
Salesforce 고객 정보 조회누가 했을까?
사용자?
Agent?
어떤 Agent?
사용자를 대신한 Agent?이걸 구분해야 한다.
Agent Identity가 있으면:
User:
lee@example.com
Delegated Agent:
sales-prospect-agent
Tool:
salesforce.getCustomer
Result:
allowed처럼 추적할 수 있다.
14. User Delegation과 Agent Identity를 함께 쓴다
Agent에게 모든 권한을 독립적으로 주는 것도 위험하다.
예:
Agent
Salesforce Admin보다는
User
↓
Agent Delegation
↓
User Scope 안에서 실행이 더 자연스럽다.
즉 Agent는
누구를 대신하고 있는가?와
Agent 자체는 누구인가?를 둘 다 가진다.
15. Agent Registry는 왜 필요한가
Agent가 3개일 때는 Registry가 필요 없어 보인다.
sales-agent
support-agent
developer-agent하지만 수백 개가 되면 달라진다.
어떤 Agent가 있는가?
누가 만들었는가?
어떤 Tool을 사용하는가?
어떤 Version인가?
어떤 Endpoint인가?
A2A를 지원하는가?
Production Agent인가?중앙 Catalog가 필요하다.
16. Agent Registry가 Agent App Store와 다른 점
Registry는 단순 목록이 아니다.
Google Agent Registry는 다음 같은 Resource를 관리한다.
Agent
MCP Server
Endpoint
Skill즉 Agent 생태계의 Inventory 역할을 한다.
17. Agent Registry가 없으면 생기는 문제
각 팀이 Agent를 만든다고 하자.
Team A
GitHub PR AgentTeam B
GitHub Review AgentTeam C
GitHub Code Agent사실 거의 같은 기능일 수 있다.
하지만 서로 존재를 모른다.
결과:
중복 개발
다른 권한 정책
다른 Tool
다른 SecurityRegistry는 이를 줄인다.
18. MCP와 Agent Registry가 연결된다
예를 들어 사내 MCP Server가 있다.
github-mcp
jira-mcp
database-mcp이를 Registry에서 검색할 수 있다.
Agent 개발자
↓
Agent Registry
↓
Approved MCP 확인
↓
Agent에 연결Prompt에 MCP URL을 직접 적어두는 것보다 훨씬 낫다.
19. A2A Agent도 Registry에서 찾는다
Agent2Agent를 사용하면 Agent가 다른 Agent에게 Task를 위임할 수 있다.
예:
Developer Agent
↓
Security Agent
↓
Compliance Agent하지만 다른 Agent의 주소를 Prompt 안에 Hard Coding하는 것은 좋지 않다.
https://security-agent.internal보다
Registry
↓
security-review capability 검색이 더 자연스럽다.
20. A2A Agent Card도 Registry에 활용된다
A2A Agent는 자신의 Capability를 Agent Card로 공개할 수 있다.
예:
{
"name": "Security Review Agent",
"skills": [
"dependency-review",
"secret-scan",
"pr-security-review"
]
}Google Agent Registry는 A2A Agent 등록 시 이런 Capability Metadata를 활용할 수 있다.
21. Skill Registry도 따로 등장했다
최근 Google Agent Platform에서 특히 재미있는 부분이다.
Agent Skill을 별도 Registry로 관리한다.
Skill은 다음을 포함할 수 있다.
Instructions
Executable Code
Documentation즉 단순 Prompt Template보다 크다.
22. Skill은 Agent Capability Package다
예:
ios-release-skill/
├── SKILL.md
├── scripts/
│ ├── bump_version.py
│ └── validate_store.py
└── references/
└── release-policy.mdAgent가 필요할 때 Skill을 불러온다.
23. 왜 Skill Registry가 필요한가
Agent가 많아지면 같은 Workflow가 반복된다.
Security Review
Release Validation
Invoice Analysis
Customer Summary모든 Agent Prompt에 절차를 복사하지 않는다.
Shared Skill Registry
↓
필요할 때 검색
↓
Agent에 Mount하는 구조가 된다.
24. Google Skill Registry도 Version을 관리한다
Skill에는 Mutable Resource와 Immutable Revision 개념이 있다.
개념적으로:
ios-release
↓
revision-1
revision-2
revision-3Agent가 어떤 Revision을 사용했는지 추적할 수 있다.
이게 중요하다.
25. Skill도 Supply Chain이다
Skill 안에는 Executable Code가 들어갈 수 있다.
즉
Skill 설치는
새로운 Agent Capability 설치와 비슷하다.
따라서 다음이 필요하다.
Publisher
Version
Validation
Access Policy
AuditGoogle이 Skill을 Registry 관리 대상으로 넣은 이유다.
26. Agent Gateway는 Agent 세계의 API Gateway에 가깝다
Agent가 많아지면 Traffic도 복잡해진다.
User → Agent
Agent → Tool
Agent → MCP
Agent → Agent
Agent → API이걸 각 Agent가 직접 관리하면 정책이 흩어진다.
그래서 Agent Gateway가 필요하다.
27. Agent Gateway의 역할
개념적으로:
Agent
↓
Agent Gateway
↓
Policy
↓
DestinationGateway가 다음을 확인한다.
누가 호출했는가?
어디로 가는가?
허용된 Endpoint인가?
어떤 권한이 필요한가?
Content가 안전한가?28. Google Agent Gateway는 MCP와 A2A를 이해한다
일반 API Gateway는 HTTP Endpoint 중심이다.
Agent Gateway는 Agent Protocol까지 이해한다.
대표적으로:
MCP
A2A를 다룬다.
즉
Agent → Tool뿐 아니라
Agent → AgentTraffic도 같은 Governance 영역에 넣는다.
29. Google Agent Platform의 Egress는 Default Deny 사고방식이다
Agent가 외부 Resource에 접근하려면 명시적으로 허용해야 하는 구조를 사용한다.
개념적으로:
Agent
↓
Unknown Endpoint
↓
DENY등록되고 허가된 Resource:
Agent
↓
Agent Gateway
↓
Registry 확인
↓
Policy 확인
↓
ALLOW앞서 Agent Security 글에서 이야기했던 Network Egress Control과 같은 방향이다.
30. Agent Registry + Gateway를 같이 봐야 한다
Registry만 있으면
무엇이 존재하는가를 알 수 있다.
Gateway는
무엇을 사용할 수 있는가를 결정한다.
즉:
Agent Registry
InventoryAgent Gateway
Runtime Enforcement이다.
둘은 역할이 다르다.
31. 여기에 Model Armor가 들어간다
Agent Gateway를 통과하는 Prompt와 Response에 보안 검사를 적용할 수 있다.
Model Armor는 다음 위험을 다룬다.
Prompt Injection
Jailbreak
Sensitive Data Leakage
Harmful Content32. 중요한 점은 Agent 코드 안에서 필터링하지 않는다는 것이다
좋지 않은 구조:
if looks_dangerous(prompt):
reject()각 Agent가 자체 Security Logic을 가지고 있다.
100개 Agent면 100개 구현이 된다.
더 나은 구조:
Agent
↓
Gateway
↓
Model Armor
↓
Policy EnforcementSecurity를 인프라 계층으로 올린다.
33. Client-to-Agent와 Agent-to-Anywhere를 분리한다
Traffic 방향도 다르다.
Ingress
User
↓
AgentEgress
Agent
↓
Tool / Agent / API둘 다 위험이 다르다.
Ingress:
Prompt Injection
JailbreakEgress:
Data Leakage
Unauthorized Tool CallGateway에서 각각 다른 Policy를 둘 수 있다.
34. Agent Sandbox도 Runtime 일부다
Agent가 Code를 생성하고 실행해야 할 수 있다.
예:
import pandas as pd
df = pd.read_csv(...)그 코드를 Host에서 직접 실행하면 위험하다.
그래서 Sandbox가 필요하다.
Agent
↓
Generated Code
↓
Sandbox
↓
ResultHost System과 분리한다.
35. Computer Use도 같은 이유로 격리한다
Browser Automation Agent가 있다고 하자.
Agent
↓
Browser
↓
WebsiteAgent가 클릭과 입력을 직접 수행한다.
이 역시 Production Host와 분리해야 한다.
Google Agent Runtime은 Code Execution과 Computer Use 같은 실행 환경을 별도 Compute Resource로 취급하는 방향이다.
36. Observability 없이는 Multi-Agent 운영이 불가능하다
Agent가 하나면 Log를 직접 볼 수 있다.
하지만 다음 구조가 되면 어렵다.
Agent A
↓
Agent B
↓
MCP
↓
Tool
↓
Agent C
↓
API문제가 생겼다.
어디가 원인일까?
37. Distributed Trace가 필요하다
기존 Microservice와 비슷하다.
traceId
agent-A
↓
agent-B
↓
tool-call
↓
external-api전체 Workflow를 연결해야 한다.
Google Agent Runtime은 Cloud Trace와 OpenTelemetry 기반 Observability를 제공하는 방향이다.
38. Agent Observability에서 봐야 할 것
일반 App Monitoring:
Latency
Error
CPU
MemoryAgent Monitoring에는 추가 정보가 필요하다.
Model
Prompt
Tool Call
Agent Delegation
Token
Memory Retrieval
Policy Decision
Safety Block
Cost39. Agent Graph가 중요해진다
Agent가 수백 개 있으면 목록만으로 부족하다.
누가 누구를 호출하는가?
어떤 MCP를 공유하는가?
어떤 Tool이 Critical인가?Topology가 필요하다.
Sales Agent
│
├── CRM MCP
│
└── Email Agent
│
└── Gmail API이 관계를 관찰해야 한다.
40. Agent Simulation도 운영 전에 필요하다
일반 Software에는 Test가 있다.
Agent도 마찬가지다.
예:
고객이 환불을 요구한다.
가격 정보가 충돌한다.
API가 500을 반환한다.
Prompt Injection이 포함된다.Agent가 어떻게 반응하는지 Release 전에 확인한다.
41. Agent Simulation은 E2E Test에 가깝다
단순 Model Eval:
질문
↓
답변 점수Agent Simulation:
Scenario
↓
Agent
↓
Memory
↓
Tool
↓
Other Agent
↓
Policy
↓
Final Outcome전체 Workflow를 평가한다.
42. ADK는 이 구조의 개발 Framework다
Google Agent Development Kit는 Agent 구현을 담당한다.
개념적으로:
ADK
→ Agent Logic
Agent Runtime
→ Execution
Memory Bank
→ Long-term Memory
Registry
→ Discovery
Gateway
→ Policy
Observability
→ Monitoring역할을 분리한다.
43. ADK에서 Multi-Agent를 구성할 수 있다
예:
coordinator = Agent(
name="release_coordinator",
sub_agents=[
ios_agent,
android_agent,
security_agent
]
)개념은 다음과 같다.
Coordinator
├── iOS Agent
├── Android Agent
└── Security Agent각 Agent가 전문 업무를 맡는다.
44. 하지만 모든 Subagent를 A2A로 만들 필요는 없다
같은 Runtime 안에서 동작하는 내부 Worker라면:
ADK Subagent로 충분할 수 있다.
반대로 다음 경계가 생기면 A2A가 의미 있다.
다른 서비스
다른 조직
다른 Runtime
다른 Vendor
독립된 Auth45. MCP와 A2A 역할도 구분한다
정리하면:
MCP
Agent → ToolA2A
Agent → AgentGoogle Agent Platform은 둘 다 Gateway와 Registry 범위에 넣는다.
이게 Enterprise 관점에서는 중요하다.
46. 실제로 Customer Support Agent를 만든다면
예제를 하나 만들어보자.
목표:
고객 문의를 분석하고
주문을 확인한 뒤
필요하면 환불 담당 Agent에게 넘긴다.구조:
Customer
│
▼
Support Agent
│
├── Memory Bank
│
├── Order MCP
│
└── Refund Agent
│
└── Payment Tool47. ADK Agent
개념 코드:
from google.adk.agents import Agent
support_agent = Agent(
name="support_agent",
model="gemini-3.1-pro",
instruction="""
Handle customer support requests.
Check order information before making claims.
If refund approval is required,
delegate to the refund agent.
"""
)실제 SDK API 이름과 Model ID는 사용하는 ADK 버전과 프로젝트 설정에서 확인해야 한다.
48. Tool은 MCP로 연결한다
Support Agent
↓
Order MCP
↓
Order DatabaseAgent가 Database Credential을 직접 가지지 않게 한다.
49. Refund는 별도 Agent로 분리한다
Support Agent
↓
A2A
↓
Refund AgentRefund Agent에는 더 강한 Policy를 둔다.
Support Agent
order:readRefund Agent
order:read
refund:request권한이 다르다.
50. Agent Identity도 각각 분리한다
support-agent-prodrefund-agent-prodGateway Log에서 구분된다.
51. Registry에 등록한다
Agent Registry
support-agent
refund-agent
Order MCP
Payment MCPCapability Search가 가능하다.
52. Memory Bank는 사용자 선호에 사용한다
예:
고객은
전화보다 이메일 연락을 선호다음 Session에서도 사용할 수 있다.
하지만 다음 같은 정보는 Memory로 남기지 않을 수 있다.
카드번호
일회용 인증값
민감한 개인정보Memory Policy가 필요하다.
53. Gateway에서 정책을 강제한다
예:
Support Agent
→ Payment MCP
DENYRefund Agent
→ Payment MCP
ALLOWPrompt가 아니라 Runtime Policy로 강제한다.
54. Model Armor를 Gateway에 연결한다
Incoming Request:
고객 Prompt↓
Model Armor↓
Support AgentOutgoing Tool Call도 검사할 수 있다.
55. Observability로 전체 흐름을 본다
Trace
customer-request-142
Support Agent
↓
Order MCP
↓
Refund Agent
↓
Payment Tool문제 발생 시 어느 단계에서 실패했는지 확인한다.
56. 이것이 단순 Gemini API 호출과 다른 점이다
단순 구조:
Gemini API
↓
ResponseAgent Platform:
Model
+
Runtime
+
State
+
Memory
+
Identity
+
Discovery
+
Gateway
+
Security
+
Observability
+
Evaluation이다.
57. 그래서 Google이 Model Garden도 그대로 둔다
흥미로운 점은 Agent Platform이 Gemini만 강제하는 구조는 아니라는 것이다.
Google은 Model Garden을 통해 여러 모델을 사용할 수 있게 한다.
즉 중심을
Gemini Model하나로 잡기보다
Agent Platform에 잡으려는 전략으로 볼 수 있다.
58. Model은 교체 가능하고 Runtime은 계속 남는다
예:
Planning Agent
Gemini ProFast Worker
Gemini Flash특정 Task
Third-party Model로 바뀔 수 있다.
하지만 다음은 그대로 유지된다.
Identity
Memory
Gateway
Registry
Observability
Policy그래서 Platform Layer가 중요해진다.
59. Enterprise Agent Platform의 진짜 Lock-in은 모델보다 Runtime에 있을 수 있다
모델은 API만 바꾸면 교체하기 비교적 쉽다.
하지만 다음이 한 플랫폼에 깊게 들어가면 이야기가 달라진다.
Agent Identity
Memory
Registry
Gateway
Observability
Policy
Skills이것은 Infrastructure다.
즉 앞으로 Cloud Vendor 경쟁은
누가 가장 좋은 모델인가?뿐 아니라
누가 가장 좋은 Agent Runtime을 제공하는가?로 이동할 가능성이 높다.
60. 개발자는 이걸 Kubernetes처럼 생각하면 이해하기 쉽다
Container 초기에는
Docker Image가 중심이었다.
규모가 커지자
Kubernetes
Service
Ingress
Secrets
RBAC
Observability가 필요해졌다.
Agent도 비슷하다.
초기:
Prompt
+
Model규모 확대:
Runtime
Registry
Gateway
Identity
Memory
Observability가 필요하다.
61. Agent Registry는 Service Registry와 비슷하다
Microservice:
Service RegistryAgent:
Agent Registry목적은 비슷하다.
누가 존재하는가?
어디에 있는가?
무엇을 할 수 있는가?62. Agent Gateway는 Service Mesh와 비슷한 면이 있다
Microservice 환경:
Service Mesh
mTLS
Traffic Policy
ObservabilityAgent 환경:
Agent Gateway
Identity
Authorization
MCP / A2A Policy
Model Armor완전히 같은 것은 아니지만 사고방식은 비슷하다.
63. Memory Bank는 Database와 다른 운영 대상이다
Agent Memory는 단순 데이터 저장이 아니다.
추출
정리
검색
Embedding
Freshness
삭제
Privacy까지 관리해야 한다.
그래서 독립 서비스가 된다.
64. Skill Registry는 Package Registry와 비슷하다
개발자는 이미 이런 구조에 익숙하다.
npm
PyPI
Swift PackageAgent에서도:
Skill
↓
Registry
↓
Version
↓
Agent Load구조가 만들어지고 있다.
65. 실제 프로젝트 구조는 이렇게 잡을 수 있다
agent-platform/
├── agents/
│ ├── support/
│ ├── refund/
│ └── order/
│
├── skills/
│ ├── customer-summary/
│ └── refund-policy/
│
├── policies/
│ ├── gateway/
│ └── memory/
│
├── evals/
│ ├── support/
│ └── security/
│
├── deployment/
│ ├── runtime/
│ └── registry/
│
└── README.mdAgent Logic과 Platform Policy를 분리한다.
66. Agent마다 Manifest를 둔다
예:
name: support-agent
runtime:
longRunning: true
memory:
enabled: true
profile: customer-support
identity:
enabled: true
tools:
- order-mcp
agents:
- refund-agent
network:
default: deny이 YAML은 Google 공식 Config Format 그대로가 아니라 Platform Architecture를 표현하기 위한 예시다.
67. Memory Policy도 코드로 관리한다
memory:
allowed:
- communication_preference
- product_preference
- support_history
prohibited:
- payment_card
- password
- auth_token
ttl:
support_history: 180dAgent가 무엇을 기억할지 명확히 한다.
68. Agent Gateway Policy
agent: support-agent
allow:
mcp:
- order-mcp
agents:
- refund-agent
deny:
mcp:
- payment-admin-mcp
external:
- "*"Prompt에
Payment Admin MCP 사용하지 마라고 적는 것보다 강하다.
69. Agent Eval도 Repository에 둔다
{
"scenario": "refund_without_order",
"input": "결제 취소해줘.",
"expected": {
"mustCheckOrder": true,
"mustNotCallPaymentDirectly": true,
"mustDelegate": "refund-agent"
}
}Agent Behavior를 Regression Test한다.
70. Agent Platform에서 CI/CD도 필요하다
Agent도 Software다.
Agent Code 변경
↓
Unit Test
↓
Agent Eval
↓
Security Simulation
↓
Deploy
↓
Observability가 필요하다.
71. Agent Version과 Skill Version을 같이 기록한다
예:
{
"agent": "support-agent",
"version": "2.4.0",
"skills": {
"customer-summary": "3",
"refund-policy": "7"
}
}문제가 생겼을 때 어떤 Skill Version 때문인지 확인할 수 있다.
72. Runtime이 안정적이어야 Model Upgrade도 쉬워진다
예:
Gemini 3.1 Pro
↓
새 Gemini Model로 변경한다고 하자.
Runtime Infrastructure가 유지되면:
Identity
Gateway
Memory
Registry
Tool
Eval은 그대로다.
Model만 Eval한 뒤 교체한다.
73. Agent를 Model에 너무 강하게 결합하지 않는 것이 좋다
좋지 않은 구조:
if gemini_specific_behavior:
...가 모든 Logic에 들어감.
좋은 구조:
Agent Logic
↓
Model Interface
↓
Gemini / Other ModelPlatform이 Model 교체 가능성을 유지한다.
74. Agent Runtime 비용도 이제 독립 비용이 된다
예전 AI 비용은 거의 Token이었다.
Input Token
Output TokenAgent Platform에서는 추가 비용이 생긴다.
Agent Compute
Runtime Memory
Storage
Memory Bank
Gateway
Skills
Session OperationsGoogle의 Agent Platform Pricing도 이런 Resource를 별도 항목으로 분리하기 시작했다.
75. 그래서 Agent Cost Dashboard도 달라진다
기존:
Token CostAgent 시대:
Model Token
+
Agent Compute
+
Memory
+
Storage
+
Gateway Calls
+
Tool/API Cost가 된다.
76. Cost per Agent Task를 봐야 한다
예:
Customer Support Task
$0.14Sales Research Task
$1.82Deep Compliance Review
$9.40같은 식으로 Workflow 단위 비용을 측정한다.
77. Long-running Agent는 Idle Cost도 봐야 한다
Agent가 3일 동안 존재한다고 3일 내내 CPU를 사용하는 것은 아니다.
Runtime이 실제 Execution과 Waiting을 어떻게 과금하는지도 중요하다.
Managed Runtime을 쓰는 이유 중 하나다.
78. Agent Platform 도입을 처음부터 크게 하지 않는다
추천 시작점:
1 Agent
1 MCP
1 Memory Profile
1 Gateway Policy
1 Eval Suite정도다.
79. 첫 실전 예제로 좋은 Agent
예:
PR Review Agent권한:
GitHub Read
CI Read행동:
PR 분석
Test 누락 확인
Risk 보고Production Write 없음.
안전하다.
80. 두 번째 단계에서 Multi-Agent로 확장한다
PR Coordinator
├── Code Reviewer
├── Security Reviewer
└── Test Reviewer각 Agent 결과를 통합한다.
81. 그다음 A2A를 도입한다
다른 조직이나 시스템 경계가 생겼을 때:
Developer Agent
↓
A2A
↓
Security Organization Agent로 확장한다.
82. 마지막에 Long-running Workflow를 만든다
Release Agent
Day 1
CI 확인
Day 2
RC 확인
Day 3
Store 상태 확인
Day 5
Crash 확인이런 작업에서 Runtime + Session + Memory가 빛난다.
83. 처음부터 모든 기능을 켜면 복잡해진다
Agent Platform에는 많은 기능이 있다.
Memory
Gateway
Identity
Registry
Skills
A2A
MCP
Simulation
Observability모두 한 번에 넣을 필요는 없다.
84. 개인 개발자에게는 과할 수도 있다
개인 프로젝트에서 Agent 하나를 돌리는 경우:
Codex
Claude Code
Gemini CLI만으로 충분할 수 있다.
Gemini Enterprise Agent Platform은 특히 다음 상황에서 가치가 커진다.
여러 Agent
여러 팀
Enterprise Data
Long-running Task
권한 분리
감사
규제
Production Operation85. 작은 팀은 Managed Runtime부터 시작할 수 있다
가장 먼저 필요한 것은 보통:
Agent Runtime
Sessions
Observability이다.
필요해지면:
Memory Bank
Registry
Gateway
Identity를 추가한다.
86. Google Agent Platform에서 가장 눈여겨볼 변화
모델보다 다음 네 가지를 더 중요하게 본다.
Agent RuntimeMemory BankAgent IdentityAgent Gateway이 네 가지가 실제 Production Agent의 기반이기 때문이다.
87. 특히 Agent Identity는 앞으로 표준 기능이 될 가능성이 높다
사람에게 Identity가 필요한 것처럼 Agent가 행동하기 시작하면 Agent도 Identity가 필요하다.
Agent가 누구인가?
누구를 대신하는가?
무엇을 할 수 있는가?
무엇을 했는가?를 추적해야 한다.
88. Agent Registry도 결국 필수 인프라가 될 수 있다
Agent가 수백 개 생기면
Agent Sprawl문제가 발생한다.
누구나 비슷한 Agent를 만든다.
Registry 없이는 관리하기 어렵다.
89. 앞으로 Cloud 경쟁은 “Agent Kubernetes” 경쟁이 될 가능성이 있다
과거:
누가 가장 좋은 VM을 제공하는가?에서
누가 가장 좋은 Kubernetes Platform을 제공하는가?로 이동했다.
AI도 비슷하다.
누가 가장 좋은 LLM을 제공하는가?에서
누가 Agent Fleet을
가장 안정적으로 운영할 수 있는가?로 이동할 수 있다.
90. 마무리
Gemini Enterprise Agent Platform을 보면 Google의 Agent 전략이 꽤 명확하다.
초기 생성형 AI:
Prompt
↓
Model
↓
Response지금의 Agent Platform:
User
↓
Agent
↓
Runtime
↓
Memory
↓
Identity
↓
Registry
↓
Gateway
↓
Tool / Agent
↓
Observability
↓
Evaluation로 확장됐다.
즉 핵심 질문이 바뀌었다.
어떤 모델을 쓸까?에서
이 Agent를
어떻게 운영할까?가 되고 있다.
Production Agent에서는 모델만 좋아서는 부족하다.
오래 실행되어야 한다.
상태를 유지해야 한다.
필요한 것을 기억해야 한다.
다른 Agent를 찾아야 한다.
권한을 가져야 한다.
Tool 접근이 통제되어야 한다.
모든 행동이 추적되어야 한다.이 조건을 만족해야 한다.
그래서 Google이 지금 팔려고 하는 것은 단순히 Gemini API가 아니다.
한 줄로 정리하면 이렇다.
Gemini Agent Platform의 핵심은
더 좋은 답변을 만드는 모델이 아니라,
Agent가 실제 조직 안에서
며칠 동안 안전하게 일할 수 있는
운영체제를 만드는 데 있다.앞으로 기업 Agent 경쟁에서는 Model Benchmark 못지않게
Runtime
Memory
Identity
Registry
Gateway
Observability가 중요해질 가능성이 크다.
그리고 Google이 Gemini Enterprise Agent Platform에서 가장 공격적으로 확장하고 있는 부분도 바로 이 영역이다.
참고 자료
-
Google Cloud — The new Gemini Enterprise: one platform for agent development, orchestration, and governance
Gemini Enterprise Agent Platform을 Build·Scale·Govern·Optimize 네 영역으로 구성하고 ADK, Agent Runtime, Memory Bank, Identity, Gateway, Simulation, Observability를 하나의 플랫폼으로 통합한 공식 발표. -
Google Cloud — Introducing Gemini Enterprise Agent Platform
며칠 동안 지속되는 Long-running Agent, Agent Sandbox, Agent-to-Agent Orchestration, Memory Bank, Agent Identity, Registry, Gateway 등 Production Agent Runtime의 주요 구성 요소를 소개한 공식 자료. -
Google Cloud Docs — Gemini Enterprise Agent Platform Overview
Agent Studio·ADK·Agent Runtime·Memory Bank·Agent Identity·Gateway·Model Armor 등 Agent Platform 전체 Architecture를 설명하는 공식 문서. -
Google Cloud Docs — Agent Runtime
Session, Memory Bank, Code Execution, Observability, IAM, Agent Gateway, Security Command Center 연동 등 실제 Agent Runtime 운영 기능을 설명하는 공식 Reference. -
Google Cloud Docs — Agent Registry
Agent, MCP Server, Endpoint, Skill을 중앙 Catalog에서 검색·등록·Govern하고 MCP·A2A 기반 Integration을 관리하는 구조를 설명하는 공식 문서. -
Google Cloud Docs — Skill Registry
Agent Skill을 Instruction·Executable Code·Documentation을 포함하는 Package로 관리하고 Revision·Validation·Discovery를 지원하는 공식 자료. -
Google Cloud Docs — Agent Gateway / Model Armor
Client-to-Agent와 Agent-to-Tool·Agent-to-Agent Traffic을 Gateway에서 통제하고 Model Armor를 이용해 Prompt Injection·Sensitive Data Leakage 등을 검사하는 공식 문서. -
Google Cloud — Gemini Enterprise Agent Platform Pricing
Model Token뿐 아니라 Agent Compute, Runtime Memory, Storage, Memory Bank, Sessions, Gateway, Skill Registry 등 Agent Runtime 자체가 별도의 비용 단위로 발전하고 있음을 보여주는 공식 가격 자료.
핵심 참고 포인트
Google은 2026년 4월 Gemini Enterprise Agent Platform을 발표하면서 Agent 개발의 핵심을 Build, Scale, Govern, Optimize 네 축으로 재구성했다. Google의 설명에서도 중심은 더 이상 모델 호출 하나가 아니라 ADK → Agent Runtime → Memory Bank → Agent Identity → Registry → Gateway → Observability로 이어지는 전체 Agent Lifecycle이다.
Agent Runtime은 장시간 실행되는 Agent와 Session·Memory를 Managed Runtime 위에서 운영하고 Code Execution을 격리 환경에서 수행한다. Google은 며칠 동안 지속되는 Workflow와 Agent-to-Agent Delegation을 주요 사용 사례로 명시하고 있다.
Memory Bank는 현재 Conversation을 보관하는 Session과 역할이 다르다. Session이 한 Conversation의 History와 State를 담당한다면 Memory Bank는 여러 Session을 넘어 사용자나 업무에 필요한 정보를 추출·저장·검색해 장기 Context를 제공한다.
Agent Registry는 Agent뿐 아니라 MCP Server, Endpoint, Skill까지 중앙 Inventory로 관리한다. 특히 A2A Agent는 Agent Card에 선언된 Capability를 Registry에서 활용할 수 있기 때문에 Prompt나 설정 파일에 다른 Agent Endpoint를 직접 Hard Coding하는 구조를 줄일 수 있다.
Agent Gateway는 Agent Traffic의 Runtime Enforcement Point 역할을 하며 MCP와 A2A 같은 Agent Protocol을 이해하고 Agent Identity 및 IAM Policy와 결합해 접근을 통제한다. Google 문서상 Agent Platform의 Outbound Traffic은 명시적인 허용을 요구하는 Default-deny 방향으로 구성할 수 있다.
또한 2026년 7월 업데이트된 Skill Registry는 Agent Skill을 중앙에서 검색하고 Versioning하는 Preview 기능을 제공한다. Skill은 단순 Prompt가 아니라 Instruction, Executable Code, Documentation을 포함할 수 있어 Agent Capability Supply Chain 관리가 중요해지고 있음을 보여준다.
