NVIDIA, DGX SuperPOD AI 팩토리 운영 에이전트 설명: NemoClaw·OpenShell 기반 도메인 에이전트 6개, Kubernetes 검사에는 읽기 전용 자격 증명 사용; 정확도 수치 미공개, 이미지에는 NGC 초기 접근 초대 필요

2026년 11월 4일 NVIDIA는 개발자 블로그에 「How NVIDIA Uses AI Agents to Streamline AI Factory Operations」를 공개했습니다. 글쓴이는 Kavya G Y와 Rohan Adwankar입니다. 글은 AI Factory Operations Agent를 소개합니다. NVIDIA는 이것을 자사 내부 DGX SuperPOD 클러스터의 운영을 간소화하고 사이트 신뢰성 엔지니어(SRE)의 수작업을 줄이기 위해 만들었다고 말합니다. SRE는 컴퓨팅, 네트워크, 하드웨어, 스케줄러 대시보드를 하나씩 확인하는 대신 채팅 인터페이스에서 질문하고, 전문 하위 에이전트가 증거를 모아 서로 대조합니다. 하위 에이전트들은 모델 컨텍스트 프로토콜(MCP)로 통신합니다. 페이지에는 NVIDIA Nemotron 모델이 자동 생성한 요약도 있지만 이 기사에서는 쓰지 않았고, 글 본문과 GitHub 저장소를 근거로 삼았습니다.

구조는 NVIDIA의 NemoClaw 블루프린트를 중심으로 합니다. 사용자 쪽 에이전트 런타임이 SRE의 질문을 받아 도메인 에이전트로 보냅니다. 에이전트는 OpenClaw 플러그인과 MCP 서버를 통해 인프라에 연결하고, 각 MCP 서버는 승인된 소수의 운영 도구만 노출합니다. 프레임워크는 NVIDIA OpenShell 위에 만들어졌고 글에 따르면 완전히 온프레미스로 실행할 수 있으며, 추론은 로컬에서 제공되는 NVIDIA Nemotron 오픈 모델이 맡습니다. NVIDIA는 이 프레임워크가 내부 DGX H100, DGX B200, DGX GB300 운영 클러스터에서 돌아간다고 말합니다. 이는 NVIDIA 자체 배포에 대한 설명이며 다른 사용자에게 요구하는 하드웨어 조건은 아닙니다.

배포 형태는 Kubernetes 컨트롤 플레인 애플리케이션입니다. Helm이 웹 인터페이스, OpenClaw 게이트웨이, MCP 도구 서버, 추론 엔드포인트, OpenShell 런타임을 서비스로 설치합니다. 셸 명령을 실행할 때 OpenShell은 주 게이트웨이 파드에서 명령을 돌리는 대신 세션마다 별도의 Kubernetes 샌드박스를 만듭니다. Kubernetes 점검은 고정된 kubectl 바이너리와 등록된 읽기 전용 자격 증명을 쓰는 서버 쪽 run_kubectl 도구를 거치며, OpenShell은 kubectl도 Kubernetes 자격 증명도 받지 않습니다. 글은 에이전트 쪽에서 kubectl auth can-i를 실행한 결과를 보여 줍니다. 파드와 컨피그맵은 조회할 수 있지만 시크릿은 조회할 수 없고 파드를 만들거나 수정할 수도 없습니다. 하나의 구성에서 나온 것이지만 권한 경계를 잘 보여 주는 예입니다.

여섯 가지 도메인 에이전트가 나옵니다. 작업 복구 에이전트는 학습 작업 실패와 유효 처리량 저하를 감지하고 스케줄러, 애플리케이션, 하드웨어, 네트워크 계층에 걸쳐 근본 원인을 분석합니다. 하드웨어 에이전트는 PCIe, ECC, GPU, NVMe, 열 이상을 개별 부품까지 분류합니다. 관측 에이전트는 Prometheus, 텔레메트리, Grafana Loki 로그를 조회하고 필요에 따라 대시보드를 만듭니다. 리서치 에이전트는 NVIDIA Mission Control 매뉴얼과 DGX SuperPOD 참조 아키텍처 같은 미리 올려 둔 문서를 검색하며 팀이 자체 런북을 더할 수도 있습니다. Kubernetes 에이전트는 파드, 서비스, 배포, GPU 자원, 노드 상태를 읽기 전용으로 파악합니다. 클러스터 관리 에이전트는 진단 도구를 통해 NVIDIA Base Command Manager API와 연동해 조언하는 일을 합니다. 공통 MCP 도구에는 웹 검색, 코드 실행, Grafana 대시보드가 있고 팀이 자체 MCP 서버를 연결할 수도 있습니다.

NVIDIA는 운영 경험에서 다섯 가지 교훈을 제시합니다. 에이전트 경계를 분명히 할 것, 자동화 전에 정확한 조사로 신뢰를 쌓도록 읽기 전용으로 시작할 것, 계층을 가로질러 상관관계를 보아 고립된 도구가 놓치는 원인을 찾을 것, MCP 도구를 정밀하게 정의해 라우팅을 개선할 것, 도구 호출과 증거와 결론을 보여 줘서 SRE가 행동 전에 확인하게 할 것입니다. 글은 NVIDIA가 근본 원인 분석의 정확도를 측정하고 SRE의 동의 여부를 추적하며 프레임워크를 다듬고 있다고 말합니다. 그러나 정확도 수치도, 동의율도, 인시던트 건수도, 절약된 시간도 공개하지 않습니다. 데모 영상은 내부 시연을 위해 DGX 클러스터에 주입한 인시던트 사례로 설명됩니다.

제공 상태는 두 자료가 강조하는 바가 달라 주의해서 읽어야 합니다. 글은 이 오케스트레이션 프레임워크를 실험적 오픈 소스 소프트웨어라고 부르며 API, 구성, 배포 요구 사항이 릴리스 사이에 바뀔 수 있다고 하고 GitHub 저장소를 안내합니다. Apache 2.0 라이선스의 저장소도 실험적 릴리스라고 밝히면서, 초기 접근 단계에서는 공개된 Helm 차트와 컨테이너 이미지를 받으려면 비공개 NGC 레지스트리 초대가 필요하고 nvcr.io에 로그인하는 것만으로는 내려받을 수 없다고 덧붙입니다. 요구 사항으로는 Kubernetes, kubectl, Helm 3, 모델용 OpenAI 호환 엔드포인트 또는 차트가 관리하는 vLLM이 나오며 GPU는 그 vLLM을 배포할 때만 필요합니다. 별도로 글은 NVIDIA 고객이 계정 담당자를 통해 NVIDIA가 개발한 클러스터 운영 에이전트 접근을 요청할 수 있다고 말합니다. README에는 글이 언급하지 않은 워크플로, 예를 들어 Slurm 작업 분석과 VictoriaMetrics 쿼리도 나오고, 브라우저 UI, HTTP API, 명령줄 클라이언트, 코딩 에이전트용 MCP 브리지라는 네 가지 인터페이스도 있습니다.

멀티 테넌트 클러스터에 대해 글은 범위가 제한된 에이전트, 도구, 샌드박스, Kubernetes 권한을 설명합니다. 테넌트의 SRE는 자기 네임스페이스, 작업, 노드만 보고, 중앙 운영은 더 넓은 시야를 유지하며 OpenShell이 커널 수준 제한을 강제합니다. 에이전트의 추론이 학습용 GPU를 쓰지 않도록 운영 클러스터와 분리된 GPU 가속 전용 컨트롤 플레인을 권하고, 작은 배포에는 RTX PRO 워크스테이션이나 DGX Spark를 언급합니다.

우리의 판단입니다. 이는 한 공급업체가 자사 내부 도구를 설명하는 아키텍처와 교훈의 글입니다. 읽기 전용 자격 증명, 세션별 샌드박스, 좁은 MCP 도구라는 설계 선택은 구체적이고 재사용할 수 있지만, 들인 노력과 견줄 만한 측정 결과는 없습니다. 도입을 고려하는 팀은 컨테이너 이미지 접근 권한을 첫 관문으로 보고 먼저 비운영 클러스터에서 시험하는 것이 좋습니다.