클라우드 인프라(예: VM/컨테이너 노드, 네트워크, 스토리지, DB, 오케스트레이션/컨트롤 플레인 등) 각 컴포넌트에 AI Agent를 설치하고, 에이전트들이 상호 통신하도록 만들어 인프라 상태를 “완전 이해(complete understanding)” 하는 수준의 관측·이해를 달성한 뒤 장애/이상 상황에 대해 원인 분석(RCA: Root Cause Analysis) 까지 수행하는 아키텍처를 구상 중입니다.
다만 실제로 설계를 구체화하려고 보니 다음이 기술적으로 가장 큰 난점으로 느껴집니다.
“완전한 이해”를 어디까지로 정의해야 현실적/검증 가능할지
그 정의에 맞춰 각 Agent의 권한(Privilege), 데이터 접근 범위, 책임 경계(Ownership/Accountability) 를 어떻게 나누는 게 적절한지
컴포넌트 간 상호 통신을 허용했을 때 생기는 보안/거버넌스 이슈(과도한 권한, 데이터 유출, 상호 의존성 증가 등)를 어떻게 통제할지
커뮤니티에서 비슷한 접근을 해보셨거나, SRE/보안/플랫폼 관점에서 현실적인 설계 기준(가드레일)을 제안해주실 수 있는지 궁금합니다.
시도한 것
현재는 개념 설계 단계로, 코드/구현 로그는 없고 아래처럼 요구사항을 정리해보는 수준입니다.
목표: 컴포넌트별 Agent가 로컬(해당 컴포넌트) 신호를 관측하고, 필요한 경우 다른 Agent와 정보를 교환해 이상 탐지 + 원인 추정까지 수행
고민 중인 설계 축:
관측 데이터 범위: 메트릭/로그/트레이스/이벤트/설정 변경 이력/배포 이력/토폴로지(의존성 그래프) 등 중 어디까지 필수로 봐야 “이해”라고 할지
권한 모델: 최소 권한 원칙을 유지하면서도 RCA에 필요한 데이터 접근을 어떻게 제공할지(예: 읽기 전용/시간 제한 토큰/승인 기반 접근 등)
책임 분리: 각 Agent가 “자기 컴포넌트”만 최종 책임지는지, 아니면 교차 컴포넌트 추론(상위 관제 Agent/Coordinator)을 두는지
통신 모델: Agent 간 P2P vs 중앙 브로커/버스 기반 vs 계층형(로컬→도메인→글로벌) 중 어떤 형태가 운영/보안/확장성 측면에서 맞는지
검증 가능성: “완전 이해”가 달성됐는지 측정할 지표(정확도/재현율/MTTR/원인 적중률/설명 가능성 등) 정의
기대하는 결과
“완전한 이해”를 현실적으로 정의하는 방식(예: 운영 관점에서 충분한 이해의 수준, SLA/SLO와 연결된 정의, 관측 가능성의 범위 등)
그 정의에 맞춘 Agent 권한·데이터 접근·책임 경계의 추천 패턴(조직/보안/운영 관점의 가드레일 포함)
(가능하다면) 비슷한 접근에서 흔히 겪는 실패 지점과 이를 피하기 위한 설계 원칙/레퍼런스 아키텍처 방향
추가로, “완전 이해”를 목표로 할 때 어떤 범위는 과감히 제외하는 게 낫다(예: 민감 데이터, 특정 계층의 추론, 자동 조치 범위 제한 등) 같은 실무적인 조언도 환영합니다.
민재 님이 구상하시는 "인프라 상태 완전 이해"는 SRE의 정점에 해당하는 도전입니다. 이를 위해 A2A(Agent-to-Agent) 프로토콜과 K8s 네이티브 리소스를 어떻게 조합해야 하는지, 실무적인 가이드라인을 PART 1, 2로 나누어 제안합니다.
PART 1. 일반 설계 원칙
1. "완전한 이해"의 현실적 정의
설계에서 '완전(Complete)'은 지향점으로 두고, 실제 구현 기준은 ‘충분(Sufficient)하고 설명 가능한(Explainable)’ 수준으로 정의하십시오.
현실적 정의: “특정 이상 징후가 상위 서비스의 SLI에 영향을 주는 인과관계를 의존성 그래프(Topology) 위에서 추적할 수 있는 수준”
관측 데이터 우선순위: Config Drift + 토폴로지 → 메트릭(Prometheus) → 시스템 이벤트 → 로그(On-demand) 순으로 보십시오. 대다수의 인프라 장애는 선언한 의도(Spec)와 실제 상태(Status)의 불일치에서 시작됩니다.
제외 범위: 데이터 페이로드 내부(개인정보, DB 데이터 등)는 처음부터 추론 대상에서 제외하십시오. 메타데이터와 설정 변경 이력만으로도 RCA는 충분히 가능합니다.
2. 통신 모델: P2P vs 계층형 vs 혼합
"어느 쪽이 무조건 맞다"는 단정은 위험합니다. 시스템 규모와 거버넌스 요구사항에 따라 선택해야 합니다.
패턴
장점
단점
적합한 상황
P2P (Mesh)
단일 장애점 없음, 수평 확장 유리
디버깅 및 거버넌스 복잡
에이전트 수가 적고 도메인 경계가 명확할 때
계층형 (Hierarchical)
추적/감사 용이, 권한 경계 명확
상위 노드가 병목이 될 가능성
도메인이 복잡하고 거버넌스가 중요할 때
혼합 (Hybrid)
서브시스템별 최적화 가능
설계 복잡도 증가
가장 권장되는 프로덕션 패턴
권장 전략: 처음에는 **Orchestrator-Worker(중앙집중형)**로 시작하십시오. 구현이 단순하고 추적이 쉽습니다. 이후 특정 도메인에서 에이전트 간 직접 협업이 필요하다는 병목이 확인될 때, 해당 부분만 점진적으로 동적 위임(Mesh) 구조를 도입하는 것이 현실적입니다.
PART 2. Kagent를 활용할 경우: 실무적 구체화
Kagent는 AI를 새로운 시스템에 맞추는 것이 아니라, 쿠버네티스가 이미 일하는 방식(RBAC, CRD, 이벤트) 안에 태우는 것입니다.
1. Kagent의 핵심: A2A 프로토콜 기반 동적 위임
Kagent는 고정된 계층형 구조가 아닙니다. A2A(Agent-to-Agent) 프로토콜을 통해 에이전트 간 작업을 동적으로 위임합니다.
에이전트가 멀티스텝 작업을 계획하고 실행하면서, 필요에 따라 다른 전문 에이전트를 호출합니다.
이는 중앙집중식의 단순함과 분산형의 유연함을 동시에 가져가는 방식입니다.
2. "완전 이해"의 도구: OwnerReference 체인 추적
Kagent에서 상태 추적은 쿠버네티스의 OwnerReference 메타데이터를 따라갑니다.
"Pod가 죽었다"는 증상에서 멈추지 않고, 이를 소유한 ReplicaSet → Deployment → ConfigMap 변경 이력까지 거슬러 올라가 '원인의 흔적’을 찾아냅니다.
3. 권한 모델의 핵심: Custom Resource (CR) 기반 격리
에이전트 간의 모든 소통과 분석 결과는 **Custom Resource(CR)**라는 구조화된 오브젝트로 관리됩니다.
PrometheusRule (Prometheus): 이상 탐지 규칙을 CR로 정의하여 에이전트의 분석을 트리거합니다.
Workflow / WorkflowTemplate (Argo Workflows): RCA 분석 절차 자체를 파이프라인 코드로 정의합니다.
Analysis / AnalysisDefinition (Keptn): SLO 기반 품질 분석을 CR로 정의하여 자동 RCA의 기준점으로 삼습니다.
AnalysisReport (사용자 정의): 에이전트가 분석 결과를 기록하는 ‘게시판’ 역할을 합니다. 에이전트는 이 CR을 watch하며 추론을 이어갑니다.
4. 보안 및 설명 가능성 (Explainability)
권한 격리: 에이전트에게 cluster-admin 대신 view 롤 기반 ServiceAccount를 부여하고, 분석 결과(CR)에 대한 쓰기 권한만 추가하십시오.
근거 제시: RCA 결과에 반드시 **“근거가 된 K8s 이벤트 번호”**와 **“변경된 YAML의 diff 라인”**을 출처(evidence)로 포함하도록 설계 단계에서 강제하십시오.
정리: 흔히 겪는 실패 지점을 피하는 법
최소 권한에서 시작: 처음부터 높은 권한을 주지 말고, view 권한에서 시작해 필요한 범위만 세부적으로 추가하십시오.
단순한 통신에서 시작: 처음부터 과도한 Mesh 구조를 설계하면 에이전트 간 '핸드오프 루프(A→B→A…)'에 빠질 수 있습니다. 중앙의 통제 아래 단계적으로 분산화하십시오.
분석과 조치의 분리: AI가 원인을 찾았다고 해서 즉시 인프라를 수정하게(Auto-remediation) 하지 마십시오. 조치는 반드시 인간의 승인을 거치는 파이프라인(GitOps 등)을 통해 실행되어야 합니다.
결국 이 아키텍처의 본질은 **“인간의 인지 부하를 줄여주는 안전망”**입니다. 시스템을 억지로 AI에 맞추지 말고, AI를 기존 쿠버네티스 설계 원칙 안에 태울 때 가장 안정적인 RCA 아키텍처가 완성됩니다.