1. 네 plane으로 나누기
이 장에서 처음 나오는 말3개
experience planeExperience Plane- creator와 consumer가 보는 portal·catalog·chat·API 경험이다.
runtime planeRuntime Plane- 승인된 Agent version을 실행하고 session·streaming·scale을 처리하는 층이다.
foundation planeFoundation Plane- identity·network·model·tool·secret·observability처럼 모든 runtime이 공유하는 기반이다.
네 plane의 전체 지도
섹션 제목: “네 plane의 전체 지도”
읽는 법은 두 가지다. 위에서 아래로는 사람의 의도가 실행이 되는 경로다 — 모든 진입이 control plane의 catalog를 거친 뒤에야 runtime에 닿는다. 모델·tool·관측으로 가는 화살표는 개별 runtime이 아니라 Runtime plane 상자 전체에서 나간다 — 어느 runtime을 고르든 같은 foundation 계약을 쓴다는 뜻이다. 그래서 runtime 하나를 바꿔도 그 위(경험과 회사 의미)와 아래(공통 기반)는 그대로 남는다.
Experience plane — 사람이 보는 약속
섹션 제목: “Experience plane — 사람이 보는 약속”creator에게는 Agent 생성·version 제출·승인 상태·공유 설정·사용량이 보여야 한다. consumer에게는 자신이 사용할 수 있는 Agent만 검색되고, 설명·owner·data 등급·지원 기능·상태가 보여야 한다.
여기서 검색 결과를 숨기는 것은 사용성일 뿐 보안이 아니다. 사용자가 endpoint를 직접 알아내도 서버의 invoke authorization이 같은 결론을 내야 한다. portal URL을 유일한 보안 경계로 삼지 않는다.
Control plane — 의미와 의도를 보관한다
섹션 제목: “Control plane — 의미와 의도를 보관한다”control plane은 다음을 단일 원본으로 둔다.
- Agent의 회사 ID, owner, 설명과 risk tier
- immutable version과 artifact digest
- knowledge source revision·index artifact와 binding
- user·group별 grant
- 승인된 target policy와 현재 deployment
- 공개·중지·폐기 상태
- 누가 언제 무엇을 바꿨는지에 대한 audit event
provider 상태를 주기적으로 읽어 원하는 상태와 비교하는 reconciler도 이 층에 둔다. 배포 API가 timeout됐을 때 무작정 다시 만드는 것이 아니라 idempotency key와 provider reference로 이미 만들어졌는지 확인한다.
Runtime plane — 실행을 책임진다
섹션 제목: “Runtime plane — 실행을 책임진다”runtime은 image나 선언형 spec을 실제 process로 만들고 다음을 담당한다.
- process·filesystem·network 격리
- health와 restart, replica 또는 session lifecycle
- streaming과 protocol endpoint
- runtime identity와 secret 주입
- provider-native log·metric·trace
맨 Kubernetes adapter는 Deployment·Service를 직접 만들고, kagent에서는 Kubernetes와 controller가 Agent resource를 workload로 맞춘다. AgentCore에서는 AWS 관리형 runtime이 session별 microVM과 version endpoint를 맡는다. 공통 interface는 같아도 lifecycle·격리 단위의 의미는 다르다.
step 단위 복구를 주는 durable execution은 이 셋과 같은 target이 아니다. 현재 execution profile은 none이고,
보류한 결정을 재개하면 Temporal이나 Dapr Agents worker를 이미 고른
workload target 위에 조합한다. 따라서 RuntimeAdapter가 하나 늘어나는 것이 아니라 별도 durability port와
실행 profile이 생긴다.
Foundation plane — 여러 runtime이 공유한다
섹션 제목: “Foundation plane — 여러 runtime이 공유한다”모델, identity, tool, network와 관측을 runtime마다 별도로 만들면 교체 비용이 커진다. 가능한 것은 공통 기반으로 둔다.
| 기반 | 공통 계약 | backend별 차이 |
|---|---|---|
| identity | issuer가 포함된 불변 principal key와 group claim | Keycloak private endpoint, AWS JWT/IAM |
| model | 공개 model alias와 data zone | 온프렘 vLLM, Bedrock·외부 provider |
| tool | MCP/OpenAPI schema, auth mode, risk | cluster service, AgentCore Gateway |
| secret | logical secret reference | Kubernetes Secret/Vault, AWS Secrets Manager |
| trace | agentId, versionId, deploymentId, principalKey | OTel collector, CloudWatch |
배포 흐름과 요청 흐름
섹션 제목: “배포 흐름과 요청 흐름”
배포 권한이 있는 creator와 invoke 권한이 있는 consumer는 다른 principal이다. 운영자는 provider resource를 만질 수 있지만 업무 data를 볼 권한이 없을 수도 있다. plane 분리는 이 차이를 policy에 반영하게 한다.
책임을 문장으로 고정한다
섹션 제목: “책임을 문장으로 고정한다”| 상황 | 최초 책임 plane |
|---|---|
| 검색에 Agent가 안 보인다 | experience/control |
| 허용되지 않은 사용자가 endpoint를 호출한다 | control의 authorization boundary |
| 새 version이 배포 중 멈췄다 | control reconciler → runtime adapter |
| Pod 또는 session이 죽는다 | runtime |
| 모델 429가 난다 | foundation의 model gateway |
| tool이 잘못된 고객 record를 수정한다 | foundation action policy + control audit |
1장 요약
섹션 제목: “1장 요약”- experience는 사람이 보는 경험, control은 회사 의미, runtime은 process, foundation은 공통 기반을 맡는다.
- 배포와 호출은 별도 흐름이며 같은 권한으로 처리하지 않는다.
- durability는 runtime target이 아니라 선택한 workload에 조합하는 execution profile이다.
- 공통 trace field와 logical reference를 먼저 정하면 backend별 구현을 바꿔도 연결이 남는다.