엔비디아, 기존 에이전트 프레임워크와 OpenShell 권한 통제를 결합한 NemoClaw 청사진 설명

엔비디아는 2026년 10월 30일 개발자가 고른 에이전트 프레임워크에 Nemotron 모델, NeMo 최적화 및 관측 도구, 접근 권한을 통제하는 OpenShell 실행 환경을 결합하는 NemoClaw 공개 청사진을 설명했다. 현재 지원 대상으로 OpenClaw, Hermes Agent, LangChain Deep Agents를 들며 청사진이 프레임워크를 대체하거나 스스로 보안 실행 환경이 되는 것은 아니라고 구분했다. 이 사이트의 11월 2일 기사는 이번 기술 설명을 다루는 것이며 지난 3월의 NemoClaw 최초 출시를 새 소식으로 되풀이하지 않는다.

구조를 이해하려면 세 층을 분리해야 한다. 모델은 문장과 결정을 생성하고, 에이전트 프레임워크는 도구, 기술, 기억, 작업 순서를 정의하며, 실행 환경은 파일과 네트워크, 자격 증명에 닿을 수 있는 범위를 제한한다. NemoClaw 청사진은 이러한 요소와 측정 및 최적화 부품을 조립한다. 엔비디아는 NemoClaw가 경쟁 프레임워크도 별도 런타임도 아니라고 명시한다. 이미 세 프레임워크 중 하나에서 작업 흐름을 만든 팀이라면 모든 에이전트 로직을 다시 작성하지 않고 모델과 통제 요소를 실험할 수 있다. 다만 각 확장 기능과 버전이 그대로 호환된다는 보장은 없으므로 의존성과 권한 구성을 실제로 시험해야 한다.

원문에서 OpenClaw는 파일과 앱에 접근하고 코드를 작성하며 여러 세션에 걸친 문맥을 유지한다. Hermes Agent는 사용자의 수정과 반복된 절차를 재사용 가능한 기술로 남기는 데 초점을 맞춘다. LangChain Deep Agents는 계획, 파일 기반 문맥, 기억 및 복잡한 작업의 분담을 제공한다. 세 제품 모두 에이전트가 어떻게 일하는지를 규정하지만 도구를 호출할 수 있다는 사실만으로 운영 환경의 안전한 권한 경계가 생기지는 않는다. 청사진을 선택하기 전에 쓰는 도구와 저장 상태를 목록화하고 OpenShell에서 필요한 파일, 통신 대상, 자격 증명만 명시해야 한다. 개발 환경의 넓은 권한을 그대로 옮겨서는 안 된다.

청사진에는 공개 Nemotron 모델과 NeMo 도구도 들어간다. 엔비디아는 NeMo Relay가 실행 과정을 관측하고 개선하도록 돕고 라우팅이 처리량, 비용과 안정성에 기여할 수 있다고 설명한다. 관측이 가능하다는 것과 잘못된 행동을 자동으로 차단한다는 것은 다른 문제다. 모델과 프레임워크를 조정해도 실행 시점의 접근 제한을 생략할 수 없다. 최소 권한과 감사 가능한 기록을 먼저 설정한 뒤 실제 작업에서 성공률, 지연, 비용과 거부율을 측정하는 순서가 합리적이다. 검색한 웹페이지, 저장소 문서와 에이전트의 기억은 신뢰할 수 없는 입력이며 내용에 따라 네트워크 권한이나 비밀 접근을 늘려서는 안 된다.

엔비디아는 LangChain이 Nemotron 3 Ultra에 맞춰 Deep Agents의 프롬프트, 도구, 미들웨어를 조정하면서 모델을 다시 학습하지 않은 사례를 든다. 회사는 선도적인 폐쇄형 모델에 가까운 성능을 실행당 약 10분의 1 비용으로 얻었다고 주장한다. 이는 공급사와 협력사의 특정 모델·프레임워크 구성 비교이지 모든 작업, 장비, 과금 방식에서 열 배 절감된다는 독립적인 증명이 아니다. 이 글에는 작업별 분모와 외부 재현 결과가 충분히 공개되지 않았으므로 구매자는 동일한 작업과 평가 기준으로 자기 환경에서 성공한 실행당 비용을 계산해야 한다. 성능 주장은 단독 모델 가중치가 아니라 프레임워크와 모델의 조합에 관한 것이다.

시험을 시작할 때에는 공식 빠른 시작 문서와 예시를 격리 환경에서 실행하고 프레임워크·모델 버전, 도구 목록, OpenShell 정책, 원격 측정 설정을 기록한다. 정상 작업뿐 아니라 차단되어야 하는 파일, 네트워크, 자격 증명 요청도 시험해야 한다. 특히 검색 자료에 숨어 있는 권한 확대 지시를 넣고 거부되는지 살펴야 한다. 청사진 적용 전후는 같은 업무와 성공 기준으로 비교하고 작업이 완료됐다는 이유만으로 격리가 입증됐다고 보지 않는다. 운영 단계에는 로그 보존, 경보, 사람의 승인과 되돌리기를 책임질 담당자가 필요하다. 원문이 클라우드, 데이터센터, DGX Spark, RTX 장비를 열거하더라도 각 환경의 성능과 보안 구성이 같다는 뜻은 아니다.

청사진 자체는 규정 준수 인증도 아니다. 기본 권한, 예외 승인, 로그 속 민감정보, 외부 확장 기능, 업데이트 뒤의 정책 변화를 별도로 점검해야 한다. 성공 사례만 시험하고 차단 경로를 빼면 접근 제한이 실제로 작동하는지 알 수 없다. 현재 지원 목록에 없는 프레임워크까지 검증됐다고 해석해서도 안 된다.

이번 글의 핵심은 기존 에이전트 프레임워크, 조정된 모델, 관측 도구, 별도 실행 권한 통제를 하나의 구조로 제시했다는 점이다. 청사진은 재현 가능한 실험의 출발점이며 안정성과 비용 이익, 보안 경계는 사용자의 작업, 권한, 장비에서 확인해야 한다.