18. 두 Agent로 시작하기

내용 검토: 2026. 08. 21.

결론부터

첫 PoC의 목적은 Agent 데모가 아니라 권한·배포·실패 계약이 실제로 지켜지는지 확인하는 것이다

이 장에서 처음 나오는 말3개

walking skeletonWalking Skeleton: 기능은 작지만 등록부터 호출·감사까지 production 경로 전체를 관통하는 첫 구현이다.
acceptance testAcceptance Test: 기능이 있다는 설명이 아니라 조직의 요구조건을 통과했는지 판정하는 실행 가능한 시험이다.
default targetDefault Deployment Target: 특별한 제약이 없을 때 먼저 배포하는 runtime. 운영 중점과 투자 우선순위를 만든다.

기본 target 하나를 먼저 정한다

여러 adapter를 처음부터 같은 깊이로 만들면 platform core보다 provider 차이를 맞추는 데 시간이 든다.

AWS가 승인된 실행·data 경계이고 managed 운영이 우선이면 AgentCore를 default로 둔다.
실행과 data가 온프렘에 남아야 하거나 Kubernetes 기반이 이미 강하면 kagent를 default 후보로 둔다. 단 온프렘의 기준선은 어댑터가 Deployment를 직접 만드는 맨 Kubernetes다 — kagent가 아래 PoC에서 기준선 대비 가치를 증명하지 못하면 온프렘 default는 맨 Kubernetes 어댑터로 한다.
다른 target은 hard constraint가 있는 Agent부터 지원한다.
장기 실행·승인 대기·step 복구 수요는 default 선택의 축이 아니라 보류한 결정 B의 재개 조건으로 기록한다.

선택은 영구 결론이 아니다. 공통 contract test와 stable endpoint가 있기 때문에 default를 바꿀 수 있어야 한다.

PoC Agent 두 개와 MCP 하나

구성 요소	검증 목적	권한
사내 규정 Q&A	구성형, knowledge, streaming, read-only, 기본 catalog	전사 invoke 또는 한 부서
비용 승인 Agent	코드형, private API, write action, OBO/HITL, audit	특정 부서 + 특정 개인
비용 조회 MCP	사용자 source 제출, build·discovery·ToolPublication, Agent allowlist	read tool만 공개, finance egress만 허용

두 번째 Agent가 중요하다. 단순 Q&A만 성공하면 가장 위험한 identity propagation, action policy, side effect와 human approval을 검증하지 못한다. 사용자 MCP 하나도 함께 올려야 승인된 tool을 소비하는 경로뿐 아니라 creator가 tool 공급자가 되는 등록·검증·배포 경로까지 관통한다.

구현 순서

Domain과 identity를 먼저 만든다

Agent, KnowledgeSource, Tool, 각 Version과 binding, Grant, DeploymentTarget, Deployment, Publication schema와 IdP principal 동기화를 만든다.
Portal gateway를 세운다

catalog 조회와 invoke endpoint에서 같은 ACL 결정을 사용하고 session ownership을 저장한다.
첫 adapter의 walking skeleton을 만든다

validate → deploy → status → invoke → stop → delete 한 바퀴를 두 Agent와 한 ToolDeployment로 통과하고, publication pointer 전환·복귀는 platform core의 별도 시험으로 검증한다.
공급망과 승인 gate를 붙인다

Agent와 MCP image의 digest·SBOM·scan·signature, discovery snapshot, tool/data approval과 immutable version을 강제한다.
다음 adapter를 contract test로 추가한다

첫 adapter code를 복사하지 않고 같은 port와 fixture를 구현한다. capability 차이는 명시한다.
운영 실패를 주입한다

IdP group 변경, runtime API timeout, model 429, tool deny, DX 단절, provider resource 수동 삭제를 시험한다.

반드시 통과할 acceptance test

허용 부서는 catalog에서 Agent를 보고 호출한다.
금지 사용자에게는 검색·직접 endpoint 호출 모두 거부된다.
email 변경 뒤에도 같은 principal 권한이 유지된다.
서로 다른 issuer에서 같은 sub가 와도 principal이 합쳐지지 않는다.
부서 이동 뒤 token refresh 범위 안에 권한이 회수된다.
creator는 새 version을 만들 수 있지만 자기 승인만으로 위험한 write Agent를 공개하지 못한다.
image digest가 바뀌면 새 version 없이는 배포되지 않는다.
prompt·knowledge·skill·policy bundle 중 하나가 바뀌면 새 version 또는 명시적 policy overlay 승인 없이 effectiveConfigHash가 바뀌지 않는다.
Q&A knowledge의 source revision·ACL·index digest가 trace에 남고, 문서 삭제·ACL 축소 뒤 재색인과 기존 publication 영향 판정이 완료된다.
사용자 MCP의 discovery schema가 바뀌면 새 ToolVersion 승인 전에는 신규 binding에 노출되지 않는다.
배포 API 응답 유실 뒤 재시도해도 resource는 하나다.
publication pointer를 직전 READY Deployment로 정해진 시간 안에 되돌린다.
다른 사용자의 session ID 재사용이 거부된다.
금지 tool action이 model 밖에서 차단되고 decision log가 남는다.
prompt·tool input redaction과 retention이 실제 저장소에 적용된다.

kagent PoC에서 볼 것

kagent 고유 검증에 앞서, 맨 Kubernetes 어댑터 대비 정당화를 먼저 판정한다.

구성형 Agent(사내 규정 Q&A)가 회사 runner 개발 없이 engine만으로 사내 model·MCP 조합을 실행하는가
첫 fixture에서는 dashboard·memory를 끄고 CRD lifecycle·engine만으로도 기준선 대비 가치가 남는지 분리해 보는가
controller·engine·DB 운영 비용이 구성형 runner를 직접 만들어 소유하는 비용보다 낮다고 판단할 근거가 남았는가

같은 기간에 맨 Kubernetes adapter로 Q&A fixture를 한 번 배포해 개발 시간, 필요한 회사 code 양, steady-state resource, upgrade rehearsal과 장애 복구 시간을 함께 잰다. 숫자 없이 “CRD라 편하다”는 결론은 통과로 보지 않는다.

이 판정을 통과하지 못하면 온프렘 결정 A는 맨 Kubernetes 어댑터로 돌아간다. 통과하면 kagent 고유 검증을 이어 간다.

namespaced RBAC와 controller watch scope
BYO A2A contract와 signed image
관리형 MCPServer와 RemoteMCPServer의 책임·rollback 차이
MCP discovery snapshot과 tool allowlist, schema drift 차단
ServiceAccount·NetworkPolicy·security context
controller/DB 장애 뒤 reconciliation
portal ACL을 우회하는 controller endpoint가 노출되지 않는지
cluster·model capacity가 noisy Agent를 격리하는지

Agent Memory는 대화 개인화 수요가 있을 때 별도 판정한다

첫 fixture에서 memory를 끄는 것은 기능이 무관해서가 아니라 runtime 판정과 개인정보·DB lifecycle 판정을 한 번에 섞지 않기 위해서다. 실제 후보 Agent가 같은 사용자의 선호나 이전 대화 핵심을 여러 session에 걸쳐 기억해야 한다면, Declarative Agent의 built-in Memory를 별도 capability PoC로 연다.

pgvector가 활성화된 외부 PostgreSQL을 쓰고 embedding model·TTL을 versioned policy로 고정한다.
portal의 검증된 (issuer, subject)와 kagent user_id가 바뀌지 않게 binding하고 다른 사용자의 memory 조회를 거부한다.
자동 추출 내용과 prefetch가 prompt audit·redaction 정책을 우회하지 않는지 본다.
TTL 만료, Agent·사용자 단위 전체 삭제, 부서 이동·퇴사 정리와 backup·restore를 실제 DB에서 검증한다.
controller·PostgreSQL·embedding model 장애가 일반 대화와 memory 저장·조회에 미치는 영향을 분리해 관찰한다.

한 건 단위 삭제, Agent 간 공유, kagent 밖 runtime과 memory portability가 필수라면 built-in Memory를 채택하지 않고 회사 memory service를 MCP capability로 붙여 같은 acceptance test를 실행한다. 업무 Knowledge와 BYO Agent의 transaction state는 이 비교 대상이 아니며 각각 KnowledgeBinding과 외부 DB dependency로 남긴다.

Agent Substrate는 kagent 통과 뒤 따로 판정한다

Substrate는 kagent 채택의 필수 조건이나 별도 target adapter가 아니다. 기본 Agent가 통과한 같은 cluster에 선택 runtime으로 추가하고, 일반 Agent와 SandboxAgent를 같은 model·instructions·controller A2A client로 비교한다. 그래야 adapter contract는 그대로 둔 채 workload placement만 달라지는지 확인할 수 있다.

golden snapshot 준비 시간과 Suspended→restore p50·p95·max·실패 수
idle 전용 Pod·memory 절감에서 Substrate control/data plane·Valkey·object storage 고정비를 뺀 순효과
WorkerPool replica 1·2의 burst, worker/node 손실, snapshot storage 장애와 복구
sandbox egress 기본 거부와 model·MCP host allowlist, snapshot encryption·retention·삭제
기존 일반 Agent의 deploy/status/A2A/rollback 회귀 여부
gVisor node pool·외부 object storage·version pair upgrade의 운영 owner

restore SLO와 idle 절감이 고정비를 이기고 강한 sandbox가 필요한 Agent class가 있을 때만 제한적으로 채택한다. 상주 latency가 중요한 Agent는 기본 Agent에 남기고, coding workspace는 AgentHarness 별도 보안 PoC로 연다. 실행 절차와 판정표는 kagent-lab 11~13장에서 그대로 재사용한다.

AgentCore PoC에서 볼 것

OCI와 CodeZip 중 허용할 artifact policy, digest·provenance와 ARM64 native dependency
PrivateLink를 통한 invoke, VPC에서 private API로 egress
private IdP의 discovery/JWKS와 custom claim
user-session binding과 microVM lifecycle
새 Runtime version·endpoint 준비와 publication pointer 전환·복귀
ECR·S3·CloudWatch endpoint와 DX 단절 behavior
Registry Preview를 빼도 core workflow가 동작하는지

결정 기록

PoC 결과는 “기능 있음” 표보다 운영 증거로 남긴다.

결정	기록할 증거
default target	acceptance 통과율, 운영 인력, data boundary, 비용 model
secondary target	필요한 hard constraint와 추가 운영비
portable 범위	adapter contract test에서 실제로 공통인 항목
provider extension	어느 Agent가 왜 lock-in을 수용하는지
kagent execution class	기본 `Agent`와 `SandboxAgent`의 적용 조건, restore SLO, WorkerPool·snapshot owner
GA 전 의존성	Preview 기능 제거 시 fallback path
durability 재개	실패한 실제 Agent, 재개 조건, Temporal·Dapr 비교 weight와 운영 증거

단계적 도입

1단계는 read-only 구성형 Agent와 플랫폼이 미리 승인한 MCP만 받는다. 2단계에서 사용자 제작 read-only MCP와 code형 Agent의 sandbox pipeline을 연다. 3단계에서 write tool·OBO·HITL을 제한된 부서에 연다. 4단계에서 secondary target과 검증된 failover를 추가한다.

자유로운 업로드보다 빠른 feedback이 중요하다. 거부 reason과 고칠 방법을 creator에게 자동으로 돌려줘야 안전한 경로를 우회하지 않는다.

18장 요약

기본 target 하나로 end-to-end walking skeleton을 먼저 만든다.
read-only·write Agent 두 개와 사용자 MCP 하나가 소비·공급 양쪽의 권한·action·audit 차이를 드러낸다.
맨 Kubernetes와 kagent를 같은 fixture의 개발·운영 수치로 비교하고 provider 설명이 아니라 실패 주입과 contract test로 선택한다.
Substrate는 kagent의 별도 challenger로 A/B 검증하고, 순효과가 증명된 Agent class에만 제한한다.
승인된 tool 소비 → 사용자 MCP·코드형 → write action → secondary target 순으로 위험을 연다.

용어 사전domain·runtime·identity·lifecycle 용어를 제품 중립 경계로 빠르게 다시 찾는다.