본 포스트에 대한 요약으로, 서비스 ownership 기반 multi-agent 아키텍처 및 release 방법을 축약한다.
Introduction
Note AI assisted다수의 microservice로 이루어진 Kubernetes / Istio 환경의 인터넷 서비스에 대한 AI로의 서비스 운영 위임 방법에 대한 논의로, 이를 위한 아키텍처 제안과 함께 구현 방법으로서의 kagent(kagent.dev)를 설명한다.
핵심 아이디어는 단순하다. “기존 인간의 운영 구조를 그대로 agent 구조로 옮긴다”.
각 서비스는 팀 별로 ownership이 나뉘어 있고, 장애 시 담당 팀이 리드하며, 필요 시 타 팀에 위임하는 방식으로 운영은 돌아간다. 이 구조를 agent 레이어에 이식하면 조직 거버넌스, 권한 경계, 품질 책임이 자연스럽게 따라온다. 위임에 따른 부가적 비용이 최소화된다는 뜻이다. 그리고 이 구조는 충분히 효과, 효율적으로 동작 가능해보인다(실증 중이다).
Summary
앞선 그림에 대한 설명으로 본 포스트 내용의 압축이다.
•
서비스 별 agent 및 agent 간 협업
◦
서비스 별 agent 배치 및 A2A 기반 agent 간 협업 구조. platform agent 역시 platform 팀 그대로의 R&R을 갖고 서비스 agent 지원
◦
→ 조직 구조 미일치로 인한 복잡성 이슈 제거, 각 서비스 별 확장 용이
•
각 agent 모두가 leader
◦
어떤 서비스 agent 건 해당 agent를 중심으로 사안 별로 타 agent를 orchestration
◦
→ 인간의 사안별 대응 practice 그대로 유지. e.g., 장애를 최초 발견한 agent가 leader
•
platform 팀의 생성, 서비스 팀의 지속 보강
◦
Platform 팀
▪
kagent를 통해 OpenAPI를 포함한 표준 spec으로 서비스별 agent 일괄 생성
▪
→ 표준 구조와 최소 품질선 보장과 서비스팀의 agent 생성 부하 제거 효과
◦
Service 팀
▪
각 service 팀 및 platform팀은 자신의 서비스에 특화된 context, known issues, runbooks, harness를 자기 agent에 지속 반영
▪
→ 운영 질의, 영향 분석, 장애 대응 같은 실제 task에 맞춘 품질 누적 효과
이를 통해 얻는 최대 효과는 최소 인지 비용, 부가 관리 비용, 유연성, 그리고 확장성이다.
Details
앞선 핵심 아이디어의 3가지 상세 아이디어 각각에 대한 상세 설명이다.
서비스 별 agent 및 agent 간 협업
현재 서비스 운영의 R&R이 서비스 팀 단위로 나뉘어 있다는 사실을 agent 레이어에 그대로 옮긴 구조임.
•
Agent 단위 = 서비스 단위: 하나의 서비스에는 해당 서비스의 context(runbook, known issue, 배포 이력, 의존 관계)를 기본 문맥으로 갖는 agent가 1:1로 대응됨. agent는 기본적으로 자기 서비스 관점에서 먼저 판단함.
•
Platform Agent도 동일 패턴: 상위 조정자가 아니라, ownership 범위만 다른 peer agent. Platform 팀이 공통 운영(표준, 정책, cross-service 조율)에 대해 수행하던 R&R을 Platform Agent로 옮긴 것.
•
A2A 기반 Agent 간 협업: agent 간 직접 통신 및 위임. downstream 영향 확인, 장애 전파 분석, 공통 정책 검증 같이 여러 서비스에 걸친 task에서 사용.
◦
참고: kagent에서는 MCP 프로토콜을 통해 agent 호출 가능하여, MCP client는 agent를 MCP server로도 활용 가능함•
기존 운영 경계가 그대로 유지됨: A 팀은 A agent만, B 팀은 B agent만 관리. 권한 범위, 승인 경계, 품질 책임이 기존 조직 구조와 일치하므로 blast radius와 ownership이 모호해지지 않음.
각 agent 모두가 leader
중앙 orchestrator를 두지 않고, 상황에 따라 leader가 동적으로 정해지는 구조.
•
Leader는 상황 기반으로 결정됨
◦
사안을 최초로 감지했거나, 사안의 기본 문맥을 가장 잘 아는 agent가 leader가 됨
◦
예: 장애를 최초 감지한 Service A agent가 leader가 되어 Service B agent에 downstream 영향 확인을 요청하고, Platform Agent에 공통 정책 점검을 위임.
•
모든 agent가 동등한 역량 보유
◦
로컬 판단, 외부 agent 호출, 결과 취합을 모두 할 수 있음. 특정 agent만 orchestration 가능한 비대칭 구조가 아님.
◦
Platform Agent 역시 다수의 agent 중 하나
▪
Platform 팀이 제공하는 각종 platform 서비스(e.g., Kubernetes, observability, , 문서, CI/CD 운영 도구 등) 담당. 하지만 여전히 다수의 agent 중 하나
•
중앙 조정 agent를 두지 않는 이유
◦
중앙 조정자는 모든 서비스 문맥을 알아야 하는 generalist가 되기 쉬움
◦
[[# Q1. 서비스 별 agent를 운용할 이유가 무엇인가? 서비스 별 특화 지식은 서비스 별 MCP server 운용으로 충분하지 않나?]]에서 언급한 단일 agent 문제와 동일.
◦
Single point of failure, prompt/toolset 비대화, 팀 간 ownership 불명확 문제가 따라옴
•
인간 운영 구조와 일치
◦
실제 서비스 팀도 “장애를 최초 감지한 팀이 리드하고, 필요시 타 팀을 끌어들이는” 방식으로 움직이는 경우가 많음. 이 구조를 agent로 그대로 투영한 것
Platform 팀의 생성, service 팀의 지속 보강
Agent에 대한 책임을 두 단계로 분리하여, platform 팀이 생성을, 지속 보강은 service 팀이 담당한다.
•
① Bootstrap — Platform 팀이 일괄 생성
◦
입력: 공통 context, runbook, harness 및 각 서비스의 OpenAPI spec.
◦
산출물: 각 서비스 별 agent 및 MCP Server
◦
보장 범위: 표준 구조, 최소 품질선, 공통 tool 연결(MCP Servers), 기본 권한 경계.
◦
이유
▪
agent 간 구조적 일관성 확보 / 표준화
▪
서비스 팀의 agent 환경 진입 비용 최소화
•
② 지속 보강 — 서비스 팀이 자기 agent를 키움 (ongoing)
◦
Context: 서비스 도메인 지식, 배포 이력, 의존 관계, 고유 용어.
◦
Runbook: 장애 대응 절차, 우선순위, 위임 규칙 (→ [[# Q2. Agent와 MCP Server의 ‘구체적’ 차이는?]]에서 언급한 agent 행동 지침에 해당).
◦
Harness: eval set. "이 질문/상황에는 이렇게 답/행동해야 함"의 검증 묶음.
◦
보강 주기: 실제 운영 task와 연동. 운영 질의·영향 분석·장애 대응에서 발견한 gap이 다음 보강의 입력이 됨.
◦
Platform Agent도 같은 패턴: Platform Agent는 Platform 팀이 동일 방식으로 보강함. Platform Agent만 "생성자 = 보강자"가 같음.
•
이 분담의 효과
◦
Platform 팀의 병목을 제거: 각 서비스 agent의 도메인 품질은 해당 서비스 팀이 책임
◦
조직 운영 구조와 agent 운영 구조가 일치: 기존 on-call, 배포 책임 경계와 동일
◦
Agent 평가가 단위별로 가능: "A 서비스 질문에 A agent가 제대로 답했는가"로 분해 가능
Why kagent
kagent는 위에서 정의한 구조(서비스별 agent · 모든 agent가 leader · platform 생성/서비스 보강)를 Kubernetes 환경에서 가장 직접적으로 구현할 수 있는 오픈소스 runtime이다. 상세 분석은 AI Agents Platform via kagent, agentgateway 참조.
AI Agents Platform via kagent, agentgateway 참조.
•
Kubernetes-native runtime
◦
Agent, tool, skill, MCP server가 CRD로 관리됨. Kubernetes 환경에서는 별도 런타임 plane을 추가하지 않고 기존 플랫폼 스택에 통합 가능.
•
Declarative / GitOps 친화
◦
CRD 기반이라 ArgoCD 등으로 agent 정의를 코드처럼 관리 가능. "Platform이 일괄 생성, 서비스가 각자 보강"이라는 분담 구조와 자연스럽게 맞음.
•
A2A · MCP 표준 프로토콜 지원
◦
Agent 간 통신과 외부 tool/data 접근이 open spec. 기반. 프로토콜 레벨 vendor lock-in 위험이 낮음.
•
Agent & Tool 레지스트리
◦
클러스터 내의 agent와 tool의 등록 및 탐색 기능(Service annotation 및 ToolServer CRD 기반)
◦
조직 내 agent와 tool이 증가할수록, 이들은 서로 분리된 스크립트가 아니라 조합 가능한 빌딩 블록이 됨
•
멀티 프레임워크 지원
◦
Kagent는 CRD 기반의 선언적 agent뿐 아니라, Google ADK, LangGraph 등으로 만든 BYO(Bring Your Own) agent도 A2A를 통해 통합 지원. 기존 agent 로직 재작성 불필요
•
통합 트레이싱 및 관찰성
◦
OTEL 기반 distributed tracing 기반 프롬프트 감사 기능을 통해 agent 동작에 대한 end-to-end 가시성
◦
어떤 tool이 호출되었는지, 어떤 reasoning 과정을 거쳤는지, 어떤 데이터에 접근했는지 추적 가능
◦
참고: 대부분의 agent 프레임워크는 이러한 기능이 없음
•
운영 트러블슈팅 (현재의 “킬러 앱”)
◦
Kubernetes, Helm, Istio, Cilium, Argo, Grafana, Prometheus, Loki 등을 위한 사전 구축된 tool
◦
Agent는 다단계 작업을 자율적으로 연결 수행(예: CrashLoopBackOff 발생 → 로그 조회 → Prometheus 메트릭 상관 분석 → 해결 방안 제시)
•
기타
◦
CNCF sandbox 프로젝트 (Linux Foundation 거버넌스)
◦
멀티 LLM provider 지원 (OpenAI, Anthropic, Vertex AI, Azure, Ollama)
◦
MCP 서버 구축 및 lifecycle 관리를 위한 kmcp
kagent의 포지셔닝: kagent 비교 대상의 카테고리 구분
kagent와 흔히 비교되는 제품들은 대부분 같은 레이어의 대체재가 아니다. 카테고리를 먼저 분리해야 "왜 kagent인가"가 성립한다.
카테고리 | 대표 제품 | 설명 |
AI app / agent SDK | - 애플리케이션 코드 안에서 모델, tool, memory, agent 로직을 작성하는 SDK/프레임워크
- agent를 어떻게 구현할지의 레이어
- kagent처럼 운영 런타임 자체를 제공하는 레이어는 아님 | |
Agent orchestration framework / runtime | - 장기 실행, state, handoff, durable execution, workflow control 같은 오케스트레이션 기능 제공
- kagent와 일부 겹치지만 대체로 앱/워크플로우 실행 엔진에 가까움
- K8s CRD 기반 운영 모델과는 다름 | |
Low-code AI app / automation platform | - GUI 중심으로 AI 앱이나 업무 자동화를 만드는 플랫폼
- Dify는 AI 앱/agentic workflow 쪽이 강함
- n8n은 업무 자동화 + AI 확장 쪽이 강함
- 조직 단위 service agent 운영 인프라와는 목적이 다름 | |
Managed cloud agent platform / service | - 클라우드 벤더가 agent의 호스팅·실행·관리 레이어를 제공하는 managed 서비스
- kagent와 가장 직접적으로 비교되는 축
- 선택 기준은 대체로 managed vs self-hosted | |
Kubernetes-native agent runtime | - agent·tool·skill·MCP server를 K8s 리소스/CRD로 관리하는 runtime
- Kubernetes / Istio / GitOps / service ownership과 정합되게 agent를 운영하려는 경우 가장 직접적인 레이어 |
→ 따라서 제품 선택 축은 kagent (self-hosted) vs 클라우드 벤더 agent 서비스 (managed) 둘. 나머지 도구는 "대신 쓰는 것"이 아니라 “함께 쓰거나 다른 목적에 쓰는 것”. 이들 둘에 대한 비교는 [[#Appendix A. kagent vs AWS Bedrock Agents에 대한 Claude 답변]] 참고.
Conclusion
•
Agent ownership 매핑: Conway’s law를 그대로 받아들여 조직 구조 = 서비스 구조 = agent 구조로 정렬. 이 정렬이 안 되면 multi-agent 아키텍처는 무너지기 쉬움.
•
Generalist mega-agent 지양: [[# Q1. 서비스 별 agent를 운용할 이유가 무엇인가? 서비스 별 특화 지식은 서비스 별 MCP server 운용으로 충분하지 않나?]]의 논거 참조.
•
Bootstrap vs 서비스 특화 보강의 주체 분리: Agent 생성, 관리의 병목 제거 및 서비스 별 context 고려. GitOps/CRD와도 잘 맞음.
•
kagent 기반 구현: Kubernetes / Istio 환경에서 가장 잘 구현할 수 있는 opensource 제품
Q&A
Q1. 서비스 별 agent를 운용할 이유가 무엇인가? 서비스 별 특화 지식은 서비스 별 MCP server 운용으로 충분하지 않나?
•
로컬 기본 판단이 고정됨: A 서비스 agent는 기본적으로 A의 runbook, A의 known issue, A의 downstream, A의 운영 규칙부터 봄. 단일 agent는 매번 "어느 서비스 관점으로 볼지"부터 다시 판단해야 함.
•
tool 선택 공간을 줄일 수 있음: agent마다 자기 서비스 MCP를 우선 연결하면 tool 선택 공간이 줄어서 오동작 가능성도 같이 줄어듦. 단일 agent + 모든 MCP 구조는 결국 tool overload가 생기기 쉬움.
•
권한/승인 경계를 나누기 쉬움: A 서비스 agent는 A namespace, A 운영 tool만 갖고, B 서비스 agent는 B만 갖게 할 수 있음. 단일 agent는 권한 범위가 넓어져 blast radius가 커짐.
•
서비스 팀 ownership과 바로 매핑됨: A 팀은 A agent 품질만 책임지면 됨. 단일 agent 구조에서는 여러 팀이 하나의 prompt, toolset, 행동 규칙을 같이 만지게 되어 운영 주체가 흐려짐.
•
평가와 개선이 쉬움: "A 서비스 장애 질문에 A agent가 제대로 답했는가"는 비교적 쉽게 측정할 수 있음. 반면 단일 agent는 어느 서비스 문맥 때문에 잘했는지, 또는 왜 실패했는지 분해하기가 더 어려움.
•
agent 간 위임 구조를 만들기 쉬움: A agent가 자기 범위를 먼저 판단하고, 필요하면 B agent나 Platform Agent에 넘기는 구조가 자연스러움. 단일 agent는 처음부터 모든 걸 다 아는 generalist 역할을 떠안게 됨.
Q2. Agent와 MCP Server의 ‘구체적’ 차이는?
Agent에 입력할 내용과 MCP Server가 제공할 내용의 차이가 핵심. 즉, Agent에는 행동 지침이 들어가고, MCP Server는 agent의 행동에 사용될 외부 능력/정보를 제공함.
•
Agent 행동 지침 내용: AGENTS.md, CLAUDE.md의 그것과 유사. 특히 runbook의 절차, 우선순위, 위임 규칙 같은 행동 규칙이 여기에 들어감.
•
MCP Server 제공 내용: 서비스 별 운영 문서(e.g., collab), Argo CD 배포 이력, Observability 데이터, Kubernetes logs 등 agent가 행동에 사용할 외부 정보/도구를 제공함.
•
kagent에서는 어떻게?
◦
agent 지침: Agent.spec.declarative.systemMessage 또는 promptTemplate에 입력
▪
skill 역시 agent에 포함됨. skill은 spec.skills에 넣고, Git/OCI 기반으로 로드하거나 A2A skill metadata로 설명을 붙이는 구조.
◦
MCP server 연결: kmcp를 RemoteMCPServer로 등록한 뒤 tools: - type: McpServer로 agent에 붙여서 사용
Appendix A. 여러 multi-agent 패턴 중 본 설계의 위치에 대한 Claude의 답변
Claude로의 질문(prompt): 본 설계는 어떤 multi-agent 패턴에 속하지? 이미 AWS Bedrock Agents를 논한 점을 고려해서 답해줘
1. 패턴 landscape
Multi-agent는 단일 패턴이 아님. 업계에서 논의되는 주요 패턴은 Orchestrator-Worker(= Hub-and-spoke, Supervisor), Hierarchical, Mesh(Peer-to-Peer), Swarm, Pipeline, Event-driven, Router, Handoffs, Group Chat, 그리고 이들의 Hybrid — 10개 안팎. (세부는 말미 표 참고.)
본 문서의 모델은 이 중 Mesh (Peer-to-Peer)에 해당함. 서비스 agent는 동등한 peer이고, 사안에 따라 어떤 agent든 leader가 되어 타 agent를 호출함. Platform Agent가 존재하나 이는 플랫폼 서비스를 담당하는 peer agent일 뿐, 상위 조정자가 아님 — 즉 hybrid가 아니라 pure mesh.
[[#Appendix A. kagent vs AWS Bedrock Agents에 대한 Claude 답변]]에서 비교한 supervisor 모델은 아래 표의 #1 Orchestrator-Worker에 해당. Bedrock이 이 문서의 설계와 정면 충돌하는 이유는 여기서 다시 자명함.
2. Mesh 패턴의 알려진 단점 — 본 설계에서의 완화
Mesh 패턴이 production에서 드문 이유로 업계가 거론하는 단점은 넷임. 그러나 각각 본 문서 구조에서 상당 부분 해소되거나 원래 해당 없음.
•
O(n²) 연결 폭증: 이론적으로 10 agent면 45, 20이면 190 연결. 본 설계에서 성립하지 않음. Agent 간 연결이 mesh의 전부가 아니라 대부분의 협업이 A2A/MCP 위의 on-demand 호출이라, 사전 연결 유지가 아닌 필요 시 호출 방식임. "잠재 연결"은 많아도 "유지 연결"은 없음.
•
디버깅·관찰성: 여러 agent 쌍을 추적해야 함. 후속 과제의 agent observability(decision trace, A2A call graph, token/cost)로 직접 대응. Istio + OSS observability 스택 위에 OTel 기반으로 붙이면 기존 디버깅 툴체인 재사용 가능. Supervisor 모델에서도 오히려 orchestrator 내부 추론이 블랙박스화되는 반대 문제가 있음.
•
State drift / 일관성: Shared state가 없어 불일치 위험. 본 설계는 shared state 모델이 아님. 각 agent는 자기 서비스 context를 가지고, 협업은 명시적 A2A 호출과 응답으로 이루어짐. Swarm의 blackboard 모델과 구조적으로 다름.
•
수렴 / 무한 루프: Leader 규칙과 guard 없으면 delegation loop. 후속 과제의 delegation 가드레일(depth 제한, circuit breaker, allowed callee, leader 결정 규칙)로 직접 대응.
즉 mesh 패턴의 단점은 대부분 후속 과제 항목들이 정확히 다루는 대상이며, 제거 불가능한 본질적 단점이 아님.
3. 타 패턴 대비 이 패턴의 장점
•
Supervisor/Hierarchical 대비: SPOF·병목 없음. Orchestrator가 모든 서비스 문맥을 알아야 하는 generalist 부담을 지지 않음. 서비스 팀 ownership이 agent 권한 경계와 직접 매핑됨 — 이게 본 문서의 원설계 의도.
•
Swarm 대비: Shared state·환경 신호가 아니라 명시적 A2A 호출로 협업하므로, 수렴과 추적이 상대적으로 수월함.
•
Pipeline / Router 대비: 사안 유형이 사전에 알려지지 않아도 leader가 동적으로 결정됨. 장애·영향 분석처럼 경로가 사전에 정해지지 않는 운영 task에 적합.
4. 포지셔닝
Pure mesh는 2026년 기준 production에서 hub-and-spoke보다 훨씬 드문 패턴으로 평가되며, 이 선택은 frontier에 해당함. 이 문서는 그 포지션을 인지한 상태에서 선택한 것이며, mesh의 알려진 단점은 후속 과제의 observability · delegation 가드레일 · leader 규칙 항목으로 명시적으로 대응됨.
참고 — 패턴 비교표
패턴 | 핵심 구조 | 장점 | 단점 | 프로덕션 빈도 (의견) | 대표 구현 |
Orchestrator-Worker (= Hub-and-spoke, Supervisor, Subagents) | 중앙 orchestrator가 task 분해·위임·종합 | 추적/감사 쉬움, 디버깅 단순, 진입 장벽 낮음 | Orchestrator가 SPOF·병목, 권한 집중 | 가장 지배적 | AWS Bedrock Agents, LangGraph supervisor, CrewAI manager, OpenAI Agents SDK |
Hierarchical | Tree 구조. Root → 도메인 supervisor → worker. 계층별 state isolation | 20+ agents 확장 가능, 도메인 격리 | Supervisor 레이어별 latency 누적, 설계 복잡 | 엔터프라이즈 표준 (IBM 권고) | LangGraph 중첩 supervisor, Microsoft Agent Framework |
Mesh (Peer-to-Peer) | 중앙 없음. 임의 agent가 임의 peer와 직접 통신. state가 handoff로 이동 | SPOF 없음, 국소 결정 빠름, 유연 | O(n²) 연결, 관찰/디버깅 난이도↑, consistency 어려움 | 매우 드묾 — 2026년 production에서 hub-and-spoke보다 훨씬 적음 | 본 문서, CAMEL-AI, OpenAI Swarm (경량) |
Swarm | Peer지만 직접 통신 아님. Shared state(blackboard)·환경 신호로 간접 조정 | 탐색적 task 강함, 개별 agent 약점에 내성 | State drift, 비용 폭증 가능, 수렴 보장 어려움 | 연구/탐색 영역, production 드묾 | OpenAI Swarm, 연구 프로토타입 |
Pipeline | 순차 stage. 각 stage가 결과를 다음 stage로 | 단순, 예측 가능 | 분기·반복 표현 어려움, 실패 시 전체 중단 | 특정 ETL류 task에서 일반적 | ChatDev 등 |
Event-driven | Pub/sub 기반 비동기. Agent 간 직접 참조 없음 | 느슨한 결합, 비동기 throughput | 흐름 추적 매우 어려움 | 일부 플랫폼 | Kafka + agent wrapper류 |
Hybrid (Hierarchical + Mesh) | 상위는 계층, 말단 팀은 mesh로 협업 | 양쪽 장점 절충, 실제 운영 현실에 근접 | 설계·구현 복잡 | production의 실질적 majority (Gurusup 관찰) | LangGraph 중첩 + handoff, 실전 enterprise 조합 |
Router | 초기 분류 → 병렬 specialist 호출 → 결과 합성 | 단순, 병렬 처리 | 라우팅 실패 시 전체 실패 | supervisor의 특수 케이스로 흔함 | LangChain Router, OpenAI Swarm |
Handoffs | 활성 agent가 동적으로 전환(state 승계) | 순차적·단계별 대화 흐름 자연스러움 | State 관리 복잡, loop 위험 | 고객 지원 등 일부 도메인 | LangChain Handoffs, OpenAI Agents SDK |
Group Chat | 공유 대화 공간. manager가 발언권 조정 | 다관점 토론, 검토 사이클 | 토큰 비용↑, 수렴 어려움 | demo·PoC 중심 | AutoGen group chat |
Appendix B. 본 설계의 구축 가능성(feasibility)에 대한 Claude의 답변
Claude로의 질문(prompt): 지금 껏 논한 구조에 대한 feasibility는? 이미 아까 답한 내용이지만 다시한번. 문서에 붙일 예정이야.
결론 (내 의견): 기술적으로 실현 가능하나(feasible), 운영·조직적 리스크가 실제 성패를 좌우함. 방향성은 견고하되 “구축 가능” ≠ "성공적 운영"임을 전제하고 접근해야 함.
Feasibility 평가
기술적 feasibility: 충분히 실현 가능
•
핵심 구성 요소는 이미 존재: kagent(CRD 기반 runtime), A2A/MCP(오픈 프로토콜), Kiali·Tempo API(dependency graph 소스) 모두 사용 가능한 상태. 별도의 R&D가 아닌 기존 요소의 조합.
•
인프라 전제 충족: EKS + Istio + OSS observability 스택이 이미 운영 중이라는 전제가 feasibility의 가장 큰 바탕. 이 조건이 없는 조직은 구축 자체가 수 배로 어려워짐.
•
GitOps/CRD 운영 패턴 재사용: 새 운영 모델을 만드는 것이 아니라 기존 K8s 운영 모델을 agent 레이어로 확장하는 것. 조직 학습 부담이 낮음.
설계상 feasibility: 방향성 견고
•
Ownership 매핑: Conway’s law를 정공법으로 수용. 조직 구조와 agent 구조의 정렬이 없으면 어떤 아키텍처도 운영 단계에서 무너짐. 이 정렬을 설계 출발점으로 삼은 것이 구조적으로 건전.
•
Bootstrap + 지속 보강 분담: Platform 병목을 회피하는 올바른 분담. 서비스 수가 늘어도 수평 확장 가능.
•
Peer 구조의 야심: 상용 제품 대부분이 supervisor-collaborator(hierarchical)인 상황에서 peer 구조는 도전적이지만, 서비스 팀의 on-call 운영 모델을 그대로 투영한다는 점에서 설계 근거가 명확.
리스크 — feasibility를 위협하는 실제 요인
이 세 가지가 “구축은 되지만 작동하지 않는” 실패 모드를 만듦:
•
kagent 성숙도 (pre-v1.0, CNCF Sandbox): API churn 및 운영 기능 공백 가능성. 이식성(CRD·A2A·MCP 오픈 스펙 기반)은 상대적으로 높으므로 exit 경로 설계로 완화 가능하되, 제거 불가능한 리스크.
•
Harness/eval 누락: 서비스 팀에 harness 작성을 일임하면 실제로 만들어지지 않음. Agent는 조용히 degrade함. Platform 팀이 bootstrap 시점에 템플릿·골든셋을 함께 제공하지 않으면 이 구조의 가장 큰 실패 경로가 됨.
•
Peer 구조의 delegation 가드레일: 무한 루프, depth 폭증, context pollution은 프로토콜이 보장하지 않음. Leader 결정 규칙·depth 제한·circuit breaker·call graph 관찰 가능성이 같이 설계되어야 peer 구조가 실제로 작동.
•
조직적 역량: Ownership 매핑은 기존 on-call/서비스 팀 경계가 건강하게 작동하는 조직에서만 성립. 경계가 흐린 조직에서는 agent 구조도 같이 흐려짐 — 기술 문제가 아니라 조직 문제로 실패함.
범위 설정 — 실현 가능성을 높이는 접근
•
전면 도입이 아니라 단계적 도입: 일부 서비스(도메인이 명확하고 ownership이 단단한 곳)부터 시작해 harness·observability·비용 모델을 검증한 뒤 확장.
•
Read-only부터 시작: write 권한을 가진 agent는 human-in-the-loop 경계가 안정화된 후 도입. 운영 agent의 read-only 단계에서도 충분한 가치 확보 가능.
•
Agent 자체의 observability를 인프라로 선행 투자: Agent decision trace, A2A call graph, token/비용 가시화. 이것이 없으면 문제 발생 시 디버깅 불가능.
참조점
•
업계에서 이 수준의 조합(peer 구조 + ownership 매핑 + K8s-native + harness bootstrap)을 production 운영하는 조직은 공개 기준 극소수로, 상용 벤더(예: Komodor)도 2026년 초에야 multi-agent SRE 아키텍처를 제품화하는 단계. **기술적으로 realize 가능한 최전선(frontier)*에 해당하며, 업계 컨센서스가 가리키는 2026–2029년의 방향성과 정합.
종합
기술적 feasibility는 확보됨. 성패를 가르는 것은 harness·delegation 가드레일·조직 ownership 건강성 세 가지이며, 이들은 후속 문서에서 구체화할 과제임. 단계적 도입과 read-only 우선 전략으로 초기 리스크를 낮출 수 있음.
Appendix C. 본 문서 내용대로 구축 시 업계에서의 수준에 대한 Claude의 답변
Claude로의 질문(prompt): 지금껏 논한 내용대로 구축한다면 업계에서 어느정도 수준일까? 이정도 수준으로 구축된 곳이 얼마나 되지?
•
결론: 제대로 구축되면 **업계 최전선(top few percent)*에 해당함. 이 조합으로 프로덕션에 있는 곳은 1% 미만으로 추정함 — 이건 의견이지만 공개 데이터가 이 추정을 지지함.
Fact — 업계 현황 데이터
AI agent 도입 자체는 이미 흔함:
•
“57% of organizations already deploy multi-step agent workflows, 16% have progressed to cross-functional AI agents spanning multiple teams” (G2 2025 / Arcade 분석, arcade.dev)
•
단, 더 엄격한 정의에서는 “only 11% of organizations had deployed agentic AI by mid-2025, according to KPMG” (spaceo.ai)
그러나 인프라 운영(infra ops) 영역은 훨씬 낮음:
•
“By 2029, 70% of enterprises will deploy agentic AI as part of IT infrastructure operations, up from less than 5% in 2025.” (Gartner, itential.com)
•
즉, infra ops 도메인에서는 현재 5% 미만.
지금 인프라 영역에서 하는 일의 대부분은 copilot 수준:
•
“The 2026 reality: AI will suggest remediations, humans will approve them. Fully autonomous action will be limited to narrow, well-defined scenarios” (dzone.com)
상용 제품조차 아직 도달 중인 단계:
•
Komodor가 KubeCon Europe 2026에서 이제서야 multi-agent AI SRE 아키텍처를 발표 — “At KubeCon Europe 2026, Komodor is unveiling a new extensible multi-agent architecture for Klaudia AI.” (komodor.com). 즉 벤더들도 제품화하는 중인 레벨.
의견 — 이 문서 설계의 포지셔닝
이 문서의 제안이 포함한 요소들을 하나씩 보면:
요소 | 업계 일반성 (내 의견) |
AI agent를 운영에 투입 | 증가 중 (Copilot/chatbot 수준) |
Multi-agent 구조 | 도입 중이지만 대부분 supervisor-collaborator (Bedrock 스타일) |
Peer 구조 + 사안별 leader 이동 | 매우 드묾. 상용 제품도 대부분 hierarchical |
서비스 ownership 기반 agent 매핑 | 드묾. 대부분 기능별(monitoring agent, alert agent) 분할 |
K8s-native CRD 기반 운영 | kagent 자체가 pre-v1.0, 얼리어답터 영역 |
A2A + MCP 오픈 프로토콜 조합 | 2025~2026 막 표준화 중 |
Platform bootstrap + 서비스팀 보강 거버넌스 | 조직 설계 차원에서 거의 논의되지 않는 축 |
Istio + OSS observability 통합 | 결합할 수 있는 조직이 한정됨 |
Harness bootstrap 포함 | 업계에서 가장 많이 누락되는 항목 |
각 축은 일부 조직에서 따로따로 하고 있을 수 있음. 그러나 이 조합 전체를 production에서 돌리는 곳은:
•
K8s + Istio + LGTM을 이미 성숙하게 운영 중이어야 하고
•
pre-v1 risk를 감수할 조직 역량이 있어야 하며
•
서비스 팀 ownership 문화가 이미 존재해야 하고
•
Multi-agent peer 구조를 설계할 수 있는 팀이 있어야 함
이 네 조건이 모두 맞는 조직이 현재 매우 적음 (의견). Netflix, Uber, Lyft, 주요 빅테크 platform 팀 정도의 운영 성숙도가 있는 조직이 candidate이고, 그 중에서도 agent에 실제 투자한 팀은 더 적음.
정량 추정 (내 의견, 강한 hedge 필요): 전 세계 기준 이 수준으로 production에 있는 조직은 1% 미만, 아마도 수십~수백 조직 규모로 추정함. Gartner의 "5% infra ops 도입"도 대부분은 훨씬 낮은 수준(copilot, 단일 agent, AIOps)을 포함한 수치이므로, 이 문서 수준의 조합은 그 안에서도 극히 일부일 것.
뉘앙스 (의견)
•
"최전선"이 곧 "성공"은 아님: “Gartner predicts over 40% of agentic AI projects will be canceled by the end of 2027 due to escalating costs, unclear business value, or inadequate risk controls” (spaceo.ai). 최전선에 있다는 것은 취소 위험도 최전선이라는 뜻임.
•
방향성은 업계 컨센서스와 일치: G2/Gartner/PwC 보고서들이 공통적으로 가리키는 다음 방향(multi-agent, infra ops 확장, production reliability 중시)과 이 문서의 방향성은 정합.
•
차별점은 “조직 설계 축”: 업계 담론은 대부분 “어떤 framework를 쓸까”, "어떤 LLM을 쓸까"에 집중됨. 이 문서의 진짜 강점은 ownership 매핑 + bootstrap/보강 분담이라는 조직 축인데, 이건 벤더 자료에서는 거의 다루지 않는 관점임.
Caveat
•
수치는 공개 조사 기반. Netflix/Google/Meta 등이 내부적으로 유사한 것을 이미 운영하고 있을 가능성은 있으나 공개되지 않음.
•
"이 수준으로 구축됨"의 기준을 어떻게 잡느냐에 따라 숫자는 달라짐. 문서 수준의 방향성만이면 수백~수천, 실제로 peer 구조 + ownership 매핑 + harness + observability까지 다 충족하면 수십 단위로 내려간다고 봄.
한 줄 요약: 업계 컨센서스가 가리키는 2026–2029년의 목적지에 지금 도달하려는 시도이고, 이 수준을 프로덕션에 올린 조직은 의견으로 1% 미만. 리스크와 보상이 모두 최전선에 있음.
Appendix D. 본 설계와 동일 또는 유사 사례에 대한 Codex의 답변
Codex로의 질문(prompt): 이 문서의 내용 - peer 기반의 service 별 agent 협업 기반 service 운영과 동일 또는 유사 사례를 검색해서 요약해줘.
결론: 완전히 동일한 공개 사례는 드묾. 가장 가까운 공개 사례는 Microsoft TRIANGLE이고, 설계 철학이 가장 유사한 글은 AWS의 cross-team agent-to-agent collaboration이다. 반면 공개된 상용/레퍼런스 구현은 대부분 supervisor 중심이고, 일부는 multi-agent라기보다 single agent + deep investigation 또는 패턴/프로토콜 설명에 가깝다.
가장 가까운 사례
•
Microsoft Research — TRIANGLE (ASE 2025, 2025년 11월 공개)
대규모 클라우드 서비스의 incident triage를 multi-agent로 자동화한 사례. 핵심은 팀별로 분산된 domain knowledge를 agent에 담고, multi-role agents + negotiation으로 인간 엔지니어 협업 방식을 모사한다는 점. 실환경에서 triage 정확도는 최대 97%, TTE(Time To Engage; incident 발생 후 적절한 팀이 실제로 붙기까지 걸리는 시간)는 최대 91% 개선되었다고 보고함.
본 문서와 가장 닮은 점은 단일 중앙 agent보다 팀/도메인별 knowledge를 가진 agent 협업을 전제로 한다는 점. 차이는 초점이 incident triage에 더 강하고, service 운영 전반까지 확장한 공개 문서는 아니라는 점. (출처: Microsoft Research publication, PDF)
•
AWS Executive in Residence Blog — cross-team agent-to-agent collaboration (2026년 1월 30일)
AWS는 다른 팀 코드에 직접 agent를 보내지 말고, 각 팀이 자기 domain context를 가진 coordinator agent를 운영하고 agent-to-agent로 요청하라고 설명한다. 핵심 메시지는 "다른 팀 문맥은 다른 팀 agent가 처리해야 한다"는 것.
본 문서와 가장 유사한 부분은 service ownership → agent ownership, 타 팀 agent가 자기 문맥 안에서 처리, 권한/품질 책임 유지라는 설계 철학. 차이는 runtime 운영보다 cross-team delivery/change workflow에 초점이 있다는 점. (출처: AWS Executive in Residence Blog)
유사 사례
•
Ciroos AI SRE Teammate (보도자료 2025년 6월 3일, 웹사이트 2026년 4월 19일 확인)
SRE/운영팀용 multi-agentic AI 제품. 공개 자료에서 cross-domain correlation, A2A + MCP, human-in-the-loop, alert 발생 시 여러 agent가 관련 domain telemetry를 분석하는 구조를 강조한다.
본 문서와 닮은 점은 운영 업무, cross-domain, A2A/MCP, 인간 승인 유지. 차이는 공개 자료상 service team ownership별 peer mesh보다는 제품형 SRE teammate에 가깝다는 점. (출처: Ciroos homepage, Ciroos press release)
•
AWS multi-agent SRE assistant (AWS AI Blog, 2025년 9월 26일)
Kubernetes, logs, metrics, runbooks를 담당하는 전문 agent들이 협업하는 SRE assistant 예시. MCP를 통해 infra API와 runbook에 연결되고 incident 대응을 지원한다.
본 문서와 닮은 점은 운영 문맥별 agent 분리, runbook/tool 결합, incident 대응. 차이는 명확히 supervisor-agent pattern이라는 점. (출처: AWS AI Blog)
•
AWS Telecom Network Operations Assistant (AWS for Industries, 2025년 9월 17일)
Maintenance/Alarm/KPI agent와 supervisor agent로 구성된 telecom network operations 사례. tribal knowledge, fragmented tools, MTTR 문제를 multi-agent로 다룬다.
본 문서와 닮은 점은 운영 domain별 agent 분리, 실시간 운영 데이터 기반 협업, 운영 조직 역할 반영. 차이는 service ownership별 peer보다 기능별 sub-agent + supervisor 구조라는 점. (출처: AWS for Industries)
•
Cisco Crosswork Multi-Agentic AI Framework / AgenticOps (Cisco 공개 자료, 2026년 1~2분기)
Cisco는 network operations를 위해 specialized agents가 협업하고, consensus-based decision making, built-in resiliency, policy/oversight를 갖춘 multi-agentic framework를 공개했다. AgenticOps 설명에서는 monitoring, diagnostics, remediation, learning agent가 한 workflow에서 협업하는 예시를 든다.
본 문서와 닮은 점은 운영 특화, 도메인별 역할 분리, cross-domain telemetry, 정책/승인/감사. 차이는 서비스 ownership보다는 NetOps/SecOps/Network domain 중심이라는 점. (출처: Cisco Crosswork Multi-Agentic AI Framework, Cisco AgenticOps)
•
AWS DevOps Agent (GA 발표 2026년 3월 31일)
AWS DevOps Agent는 detection, investigation, recovery, prevention까지 incident lifecycle 전반에서 동작하는 운영 agent로 소개된다. MCP를 통해 온프레미스 및 내부 도구에 붙고, learned skills와 custom skills를 통해 조직별 조사 절차를 흡수한다.
본 문서와 닮은 점은 운영 업무 자동화, 조직별 knowledge/skills 축적, MCP 기반 내부 도구 접근, multicloud/on-prem 확장. 차이는 공개 자료상 service별 peer agent 협업보다 하나의 운영 teammate/agent space에 가깝다는 점. (출처: AWS Cloud Operations Blog)
•
IBM Instana Intelligent Incident Investigation (GA 발표 2025년 12월 10일)
IBM Instana는 agentic AI로 incident를 자동 조사하고, dependency graph 전체를 따라가며 evidence chain을 구성하고, remediation plan과 script까지 제안한다. reasoning path를 노출해 human oversight를 유지하는 점도 강조한다.
본 문서와 닮은 점은 운영 incident 조사, cross-entity / dependency-aware investigation, 설명가능성, human oversight. 차이는 공개 자료상 multi-agent peer 협업보다는 단일 investigation agent 또는 단일 investigation workflow에 더 가깝다는 점. (출처: IBM announcement, IBM product page)
•
AWS Security Incident Response — AI Investigative Agent (문서 확인 시점 2026년 4월 19일)
AWS Security Incident Response의 investigative agent는 지원 케이스가 생성되면 AWS Security Incident Response 엔지니어와 병렬로 조사에 들어가고, CloudTrail, IAM, EC2, Cost Explorer 등을 자동 조회해 evidence를 수집한다.
본 문서와 닮은 점은 운영/보안 incident investigation, 인간 대응과 병렬 동작, 자동 evidence gathering, 감사 가능성. 차이는 service별 peer multi-agent 협업이 아니라 하나의 조사 agent가 인간 대응팀과 병렬로 도는 구조라는 점. (출처: AWS Security Incident Response User Guide)
패턴 / 프로토콜 근거 (사례 아님)
•
AWS Prescriptive Guidance — Multi-agent collaboration
이 문서는 실사례 소개가 아니라 multi-agent collaboration 패턴 설명이다. 여기서 AWS는 multi-agent collaboration을 distinct role / specialization을 가진 agents가 정보를 공유하고, 책임을 나누고, collectively reason하는 패턴으로 설명하고, workflow agent와 달리 centralized coordinator가 아니라 decentralized, distributed, or role-based peers라고 구분한다.
따라서 본 문서의 서비스별 agent 및 agent 간 협업, 각 agent 모두가 leader를 받치는 패턴 분류 근거로는 적합하다. 반면 service ownership → agent ownership, platform bootstrap + 서비스팀 지속 보강 같은 조직 운영 모델까지 직접 뒷받침하는 자료는 아니다. (출처: AWS Prescriptive Guidance — Multi-agent collaboration)
•
Google A2A / kagent A2A 예시
이 역시 동일 사례는 아니고 agent-to-agent interoperability와 runtime feasibility를 보여주는 근거다. Google은 A2A를 distinct agents 간 communication/collaboration을 위한 open standard로 설명하고, kagent는 모든 agent가 A2A endpoint를 구현해 다른 agent 또는 A2A client로부터 호출될 수 있다고 문서화한다.
따라서 본 문서에서 agent 간 협업 채널이 실제로 가능한가를 받치는 프로토콜/런타임 근거로는 유효하지만, service ownership 기반 운영 모델의 직접 사례는 아니다. (출처: Google Developers Blog — A2A, kagent docs — Exposing agents through A2A protocol)
시사점
•
공개 구현의 주류는 아직 supervisor 패턴: AWS SRE assistant, AWS Telecom 사례 모두 specialized sub-agent + supervisor 구조다. Cisco도 consensus/resiliency를 강조하지만 공개 예시는 여전히 역할 분할형 협업에 가깝다. (출처: AWS AI Blog, AWS for Industries, Cisco Crosswork Multi-Agentic AI Framework)
•
Peer 기반 ownership-preserving 구조는 더 frontier에 가깝다: 공개 자료 중 가장 가까운 것은 TRIANGLE과 AWS cross-team 글이며, 둘 다 팀별 domain knowledge와 타 팀 agent가 자기 영역을 처리한다는 점을 강조한다. AWS Prescriptive Guidance도 peer/distributed collaboration 패턴 자체는 인정하지만, 그것은 어디까지나 패턴 분류 근거이지 이 문서 수준의 조직 모델 사례는 아니다. (출처: Microsoft Research publication, AWS Executive in Residence Blog, AWS Prescriptive Guidance — Multi-agent collaboration)
•
즉 본 문서는 완전히 공상적인 제안은 아님: 이미 업계는 운영 특화 multi-agent, cross-domain correlation, A2A/MCP, 인간 승인 유지, 조직별 skill/knowledge 축적 쪽으로 이동 중이다. Ciroos, AWS DevOps Agent, Cisco, IBM Instana가 각각 다른 각도에서 이를 보여준다. (출처: Ciroos homepage, Ciroos press release, AWS Cloud Operations Blog, Cisco AgenticOps, IBM announcement)
•
다만 본 문서의 차별점은 조직 설계 축: 대부분 공개 사례는 기능별 agent 분할, supervisor 중심, single investigative agent, 또는 패턴/프로토콜 설명에 머문다. service ownership을 그대로 agent ownership으로 옮긴 peer 구조, platform bootstrap + service team 지속 보강까지 한 번에 전개한 공개 자료는 드물다. (출처: AWS Prescriptive Guidance — Multi-agent collaboration, Microsoft Research publication, AWS Executive in Residence Blog, AWS Security Incident Response User Guide, IBM product page)