개요
임직원이 Agent를 만들어 공유하려면 컨테이너를 띄우는 것보다 더 긴 일이 필요하다. 이름과 소유자를 기록하고, 부서와 개인별 권한을 판단하고, code와 tool을 검사하고, 승인된 version만 배포하며, 호출과 action을 감사해야 한다. kagent와 Amazon Bedrock AgentCore는 이 중 실행 상태를 만드는 부분을 나눠 맡지만 전체 포털은 아니다.
이 덱은 먼저 특정 runtime 제품에 속하지 않는 Agent·Knowledge·Tool·Version·Trigger·Grant·Deployment 계약을 만든다
(객체별 정확한 분해는 3장 domain model에 있다). 그다음 같은 계약을
온프렘 Kubernetes의 kagent와 AWS 관리형 AgentCore에 각각 번역한다. 목표는 두 target의 모든 기능을 똑같이 만드는
것이 아니라, Agent의 정체성과 권한을 유지한 채 실행 위치를 바꿀 수 있게 하는 것이다. durable execution 층은
채택하지 않고 보류한 결정으로 관리한다.
전체 지도
섹션 제목: “전체 지도”
배포 흐름은 임직원 → Portal → 제품 중립 계약 → Adapter → Runtime이고, 요청 흐름은
임직원 → Gateway → Runtime → Tool이다. 둘은 같은 Agent ID를 쓰지만 권한과 실패 방식이 다르다.
Runtime target 상자로 드나드는 화살표는 상자 전체에 걸린다 — 어느 runtime을 고르든
배포·호출·tool의 계약이 같다는 뜻이고, 그래서 target 선택을 나중에 바꿀 수 있다.
- 0~1장큰 그림과 plane
왜 runtime만으로 플랫폼이 되지 않는가 · 사용자 경험·control·runtime·foundation plane
제품을 고르기 전에 어떤 경계를 고정해야 하는가
- 2~5장제품 밖의 계약
Agent 종류의 여섯 요구 차원 · Agent·Knowledge·Version·Trigger·Grant·Deployment · 세 lifecycle · invoke와 tool action 권한
무엇을 회사가 소유해야 provider를 바꿔도 의미가 남는가
- 6~7장Adapter와 MCP 공급 계약
runtime adapter operation · capability profile · 사용자 MCP의 등록·검증·배포·공개
여러 backend의 차이를 보존하면서 Agent와 Tool의 공급 계약을 어떻게 안정시키는가
- 8~11장kagent — 온프렘 실행 어댑터
controller·engine 구조 · Agent와 tool 리소스 · 사내 frontend·backend 연결 · 맨 Kubernetes 기준선과 adapter 운영
온프렘 영가설보다 kagent가 실제로 줄이는 비용은 무엇인가
- 구현 참조Next.js에 kagent 채팅 포팅
kagent 0.x UI 코드 재사용 · Controller API 연동 · 직원별 대화 목록·히스토리·스트리밍
기존 포털의 로그인·권한과 kagent 대화 저장을 어떻게 연결하는가
- 12장보류한 execution durability
workload target과 분리한 execution profile · 재개 조건 · Temporal·Dapr 후보
무엇을 지금 도입하지 않으며 어떤 증거가 생기면 다시 여는가
- 13장AgentCore — AWS 실행 어댑터
managed session runtime · Container와 CodeZip · VPC·PrivateLink·JWT·Cedar 경계
AWS target은 제품 중립 계약을 어디까지 구현하고 무엇을 회사에 남기는가
- 실행 플랫폼 비교Google AX — 에이전트 실행 제어
탄생 배경 · 작은 Task와 생성형 환경 준비 · kagent·AgentCore·Temporal과의 책임 비교
대기와 계산을 반복하는 많은 에이전트를 어떻게 운영하려는가
- 14~15장하이브리드 운영
data zone별 target 선택 · network · 감사 · SLO · 장애 격리와 복구
온프렘과 AWS를 한 control plane에서 어떻게 운영하는가
- 16~17장생태계의 인접 층
agentgateway 트래픽 데이터 평면 · agentregistry 유통 catalog · 자체 backend·LiteLLM과의 겹침 경계
같은 생태계의 인접 층 중 무엇이 이 덱이 회사 소유로 둔 자리와 겹치는가
- 프로토콜과 주변 층MCP·A2A 프로토콜과 주변 층
JSON-RPC·stdio·Streamable HTTP의 실제 입출력 · Agent Card·message/send·Task 상태 전이 · MCP proxy 세 뜻의 자리 · WebMCP와 확장을 통한 도구 주입
wire에 실제로 무엇이 오가고, MCP라는 이름이 붙은 주변 층 중 무엇이 새 구성 요소인가
- 18~19장도입과 마무리
두 Agent와 사용자 MCP로 검증하는 PoC · 선택 기준 · 용어 사전 · production checklist
먼저 내릴 결론
섹션 제목: “먼저 내릴 결론”- 온프렘 실행이 보안 경계라면 kagent는 runtime adapter 후보다. 포털·ACL·승인 workflow는 별도로 만든다. 기준선은 어댑터가 Deployment를 직접 만드는 맨 Kubernetes고, kagent는 구성형 engine 같은 남는 가치를 PoC에서 증명해야 한다.
- durable execution 층은 지금 도입하지 않는다. 장기 실행·승인 대기 업무는 backend 상태와 Trigger 재invocation으로 모델링하고, step 복구 수요가 acceptance test로 증명되면 별도 ExecutionProfile로 Temporal·Dapr Agents를 비교한다. 둘은 RuntimeAdapter target이 아니다.
- AWS VPC를 사내망의 신뢰 가능한 확장으로 인정하면 AgentCore는 운영 부담과 session 격리를 크게 줄인다.
- 두 target을 처음부터 같은 수준으로 구현하지 않는다. 하나를 기본 target으로 정하고 나머지는 규제·기능상 필요한 Agent부터 추가한다.
- 사용자의 Agent 접근권한과 Agent가 tool로 행사하는 업무권한을 분리한다.
- provider 교체는
Agent가 아니라Deployment의 변화다. - 구성형·코드형, request·schedule·event, resident·suspendable·ephemeral을 서로 다른 요구 차원으로 관리하고, 함께 성립할 수 있는 상태·위험 값은 set과 구조체로 기록한다.
기준 시점
섹션 제목: “기준 시점”2026년 8월 21일 기준이며 kagent 검토 기준은 v0.9.9다(16~17장의 agentgateway v1.4.1·agentregistry v0.4.0은 2026년 8월 24일 확인). kagent의 인증·인가 경계, AWS Agent Registry의 Preview 상태, Temporal·Dapr Agents 후보의 라이선스·통합 상태처럼 변화가 빠른 항목은 실제 도입 시 선택한 release와 region 문서를 다시 확인한다.