AI 에이전트는 Kubernetes를 대체하지 않는다: 제어 역할을 안전하게 어떻게 나눌 것인가?

AI 에이전트와 Kubernetes 오퍼레이터를 제어 루프 안에서 동등한 대체재로 취급해서는 안 된다. 오퍼레이터는 실제 상태를 감시하고, 이를 원하는 상태와 비교한 다음, 시스템이 선언된 결과에 가까워질 때까지 반복 가능한 방식으로 정해진 규칙을 실행하도록 설계됐다. 반면 에이전트는 결과는 알려져 있지만 그 결과에 도달하는 과정에 조사와 정보 수집, 트레이드오프 조정이 필요한 경우 더 유용하다.

Cloud Native Computing Foundation (CNCF)이 후원한 이 글은 클라우드 네이티브 인프라에 에이전트를 도입하면 권한의 경계를 정하는 일이 단순한 convention이 아니라 설계의 문제가 된다고 말한다. 가장 안전한 방식은 에이전트가 사고와 컨텍스트, 제안을 담당하도록 두고, 실행 권한은 오퍼레이터와 정책 엔진, 결정론적 시스템이 계속 보유하도록 하는 것이다.

사고와 실행을 분리하는 운영 루프

이 모델은 모니터링, 진단, 제안, 승인, 조정, 검증의 6단계로 구성된 실용적인 순서를 제안한다. 에이전트는 초기 단계에서 리소스와 로그, 이벤트, 메트릭, 문서를 조사할 수 있지만, 자동으로 변경 사항을 적용하거나 리소스를 수정 또는 삭제할 권한을 얻지는 않는다. 민감하지 않은 읽기 작업은 자동으로 실행할 수 있지만, 영향이 큰 변경 사항은 명시적인 승인이나 정책 게이트를 거친다.

kagent 프로젝트는 이를 보여주는 사례다. CNCF Sandbox에 속한 오픈 소스 프로젝트인 kagent는 에이전트를 Kubernetes 리소스로 실행하고 Kubernetes, Helm, 모니터링 도구 및 사용자 지정 도구와 연결한다. 이를 통해 분석과 실행 사이의 장벽을 없애지 않고도 문제를 조사하거나 전문 에이전트를 조정할 수 있다.

왜 오퍼레이터를 언어 모델로 대체해서는 안 되는가?

Karpenter의 사례는 그 차이를 명확히 보여준다. Karpenter는 스케줄링 제약을 처리하고 NodePool 및 NodeClaim 리소스를 조정하는 오퍼레이터다. 사용되지 않는 노드나 Spot 리소스의 변동, 스케줄링을 기다리는 워크로드가 나타나면 운영 에이전트는 NodePool 및 EC2NodeClass 설정, 이벤트와 로그, Pod Disruption Budget, Prometheus 메트릭을 조사해 원인을 찾을 수 있다.

조사 결과 축출 비활성화 정책이 통합을 막고 있거나, 중단 예산이 축출을 방해하고 있거나, consolidateAfter 값이 변동하는 워크로드에서 피할 수 있는 변동을 일으키고 있음이 드러날 수 있다. 그러나 필요한 결과는 “NodePool을 개선하라”와 같은 일반적인 권고가 아니라, 근거와 트레이드오프, 영향을 받을 가능성이 있는 노드 수, 안정성을 모니터링할 기간을 설명하는 구체적인 설정 패치다.

승인이 끝나면 Karpenter는 자체적인 스케줄링 및 중단 로직에 따라 변경 사항을 실행한다. 그런 다음 에이전트는 결과를 모니터링하고, 워크로드의 대기 시간을 늘리거나 유해한 중단을 일으키지 않으면서 통합이 개선됐는지 확인한다. 승인 기준이 충족되지 않으면 동일한 경로를 통해 롤백을 제안할 수 있다.

또 다른 사례: Argo CD와 Helm 업그레이드

Argo CD가 관리하는 Helm 차트 업그레이드에서는 Git에서 버전을 변경하는 일은 비교적 쉽지만, 실행 중인 애플리케이션에 미칠 영향을 추정하는 일은 더 어렵다. 에이전트는 릴리스 노트와 현재 값, 생성된 매니페스트를 비교해, 예를 들어 readiness probe를 설정하는 데 사용되는 값의 이름이 새로 바뀌면서 조용히 기본값으로 되돌아갈 가능성을 발견할 수 있다.

이 결과는 영향을 받는 버전과 값을 업데이트하고, 운영 위험을 설명하며, 배포 전 검사를 지정하는 집중된 병합 요청으로 변환해야 한다. 검토와 병합이 끝나면 Argo CD가 애플리케이션 정책에 따라 매니페스트를 생성하고 동기화한다. 동기화 성공만으로 업그레이드의 안전성이 입증되는 것은 아니다. 지연 시간과 오류율, 가용성 지표를 점검해야 한다. 검사가 실패하면 에이전트는 변경 사항을 되돌리거나 복구 계획을 제안할 수 있지만, 데이터 또는 스키마 변경은 완전히 되돌릴 수 없을 수 있다는 점을 고려해야 한다.

자율성은 단계적으로 얻어진다

이 글은 먼저 읽기 및 조사만 수행하는 에이전트로 시작한 다음, 패치나 병합 요청을 생성하도록 허용하고, 이후 명확한 롤백 조건이 있는 저위험·제한된 범위의 변경을 실행하도록 허용할 것을 권고한다. 조치가 이해 가능하고 측정 가능할 때에만 해당 조치는 자율적으로 수행돼야 한다.

편집부의 견해: 여기서 진정한 변화는 kubectl이나 Helm을 호출할 수 있는 에이전트를 추가하는 것이 아니라, 확률적 추론이 무제한의 실행 권한으로 전환되지 않도록 제어 루프를 다시 설계하는 것이다. 이 모델의 실질적인 가치는 감사 가능한 위임, 제한된 범위, 모니터링, 영향 되돌리기 가능성에 달려 있다. 제안에서 자율성으로 전환하는 속도를 정하는 책임은 여전히 사람에게 있으며, 또한 이 글은 이러한 접근 방식이 오류의 위험을 없애거나 모든 경우에 롤백을 가능하게 한다는 점을 입증하지 않는다.