NVIDIA Agent Toolkit: 회사 데이터와 권한 경계, 개선 루프를 한 묶음으로 낸 에이전트 오픈 스택

NVIDIA는 에이전트를 쓸 만하게 만드는 조건을 둘로 봅니다. 회사 데이터를 얼마나 아는가와 어떤 경계 안에서 움직이는가입니다. Agent Toolkit은 이 둘에 실행 기록으로 하네스를 고치는 루프까지 묶었습니다. 실제로 쓰려면 업무 하나를 정해 정책과 평가 세트를 먼저 만들고, 개발 세트와 보류 세트가 함께 오를 때만 수정을 받아들이는 규칙이 필요합니다.

요약

NVIDIA의 Erik Pounds는 10월 21일 GTC Berlin 발표에 맞춰 오픈소스 NVIDIA Agent Toolkit이 넓어졌다고 알립니다. 묶음은 다섯 갈래입니다. 회사 데이터를 에이전트가 쓰는 지식으로 바꾸는 새 Agent Knowledge Foundation(에이전트용 지식 기반), 검색용 Nemotron Retriever와 예측용 Kumo 같은 오픈 모델, 에이전트의 접근과 행동을 막는 OpenShell(보안 런타임), 전용 에이전트의 참조 설계인 NemoClaw 블루프린트, NeMo Relay와 NeMo Compass 같은 도구입니다. 저자는 에이전트가 실제 일을 하려면 모델, 하네스(harness, 도구·기억·작업 흐름을 묶은 실행 틀), 런타임, 데이터, 도구가 한 스택으로 맞물려야 한다고 봅니다.

원문이 밝힌 Agent Toolkit 구성. 이번 발표로 Data와 최적화 쪽이 늘었다

결과는 파트너 사례로 제시됩니다. NVIDIA 공급망 조직은 Palantir 위에서 이 지식 기반으로 전용 에이전트를 돌리고, Databricks와 Snowflake는 자기 플랫폼 안에서 Kumo 모델을 씁니다. 검색 쪽에서는 Amazon OpenSearch, SAP, ServiceNow가 관련도와 속도 개선을 밝혔습니다. 저자가 강조하는 효과는 데이터를 옮기거나 업무 흐름과 거버넌스를 다시 만들지 않고 붙일 수 있다는 점입니다. 아래에서는 다섯 층이 각각 어떻게 작동하는지, NVIDIA 기술 문서로 보강한 OpenShell과 최적화 루프의 작동 방식과 첫 파일럿을 돌리는 방법을 차례로 봅니다.

원문의 두 조건(아는 것, 경계)을 운영 순서로 다시 배열

핵심 메커니즘

Open agent stack: 다섯 층을 따로 고르되 함께 맞추는 구조

무엇인가. 에이전트 하나를 모델, 하네스, 런타임, 데이터, 도구라는 다섯 층으로 나눠 보는 틀입니다. 작동 방식은 이렇습니다. 사용자 요청이 들어오면 하네스가 계획을 세우고 도구를 고릅니다. 모델은 추론을 맡고, 데이터 층이 근거를 찾아 줍니다. 런타임은 이 모든 호출이 허용 범위 안에 있는지 확인하고, 도구 층은 실행 기록을 남겨 다음 개선의 재료로 씁니다. 언제 쓰나. 에이전트를 여러 업무로 늘릴 계획이 있고 층마다 다른 벤더를 쓰고 싶을 때 맞습니다. 단일 SaaS 에이전트 하나로 끝나는 업무라면 이 정도로 나눌 이유가 적습니다. 원문의 예는 Toolkit 구성 그 자체입니다. 작은 예시(가상): 구매 요청 에이전트에서 모델은 외부 상용 모델을 쓰더라도 런타임과 실행 기록은 사내 표준으로 고정해 두면, 모델을 바꿔도 통제와 측정 방식은 그대로 남습니다.

원문이 꼽은 다섯 층과 각 층의 역할. 강조 칸이 이번 발표의 중심

Agent Knowledge Foundation: 데이터를 옮기지 않고 업무 개념을 입히는 층

무엇인가. 회사 데이터를 에이전트가 찾고, 뜻을 이해하고, 예측에 쓰게 하는 부품 묶음입니다. 작동 방식은 세 단계입니다. 먼저 CUDA-X 라이브러리(cuDF, cuGraph, cuML, cuOpt, cuVS)가 GPU로 데이터를 다룹니다. 다음으로 새 Auto-Ontology 라이브러리가 원시 테이블을 고객, 제품, 주문 같은 업무 개념으로 바꾸고 그 관계를 잇습니다. 마지막으로 Nemotron Retriever가 근거를 찾고, Kumo Structured 모델(Kumo Tabular, Kumo Relational, Kumo Time Series, Kumo Forecast)이 표 데이터로 예측합니다. 언제 쓰나. ERP와 CRM처럼 같은 대상을 다른 이름으로 들고 있는 시스템이 여럿일 때 효과가 큽니다. 이미 시맨틱 레이어가 잘 정비돼 있다면 Retriever나 Kumo만 골라 붙일 수 있습니다. Auto-Ontology의 세부 작동과 인증 절차는 AX Review의 Agent Knowledge Foundation 노트에 따로 정리했습니다.

데이터를 옮기지 않고 원래 플랫폼 위에서 돈다

OpenShell: 에이전트가 할 수 있는 일을 런타임에서 정하는 경계

무엇인가. 에이전트가 무엇에 접근하고 무엇을 할 수 있는지를 실행 시점에 집행하는 오픈소스 보안 런타임입니다. 원문은 한 줄로만 소개하므로 같은 날 나온 NVIDIA 보도자료와 기술 블로그로 작동 방식을 보강합니다. OpenShell은 에이전트의 파일 시스템, 프로세스, 네트워크 접근을 정책으로 묶습니다. 모델 추론과 MCP(Model Context Protocol, 에이전트가 외부 도구에 붙는 표준) 연결에 쓰는 자격 증명은 샌드박스 밖에 둡니다. 그래서 기억이나 검색 결과가 엉뚱한 행동을 부추겨도 정책을 넘지 못합니다. 하드웨어까지 쓰는 참조 구조에서는 BlueField-4 DPU의 Sentry가 에이전트 행동을 따로 감시하다가 경계를 벗어나면 밀리초 단위로 격리합니다. 언제 쓰나. 에이전트가 메일 발송, 파일 수정, 외부 API 호출처럼 되돌리기 어려운 행동을 할 때입니다. 읽기만 하는 질의응답 봇이라면 기존 데이터 권한만으로 충분할 수 있습니다. 작은 예시(가상): 영업 지원 에이전트에 사내 CRM과 메일만 허용하고 GitHub과 개인 클라우드로 나가는 길은 막아 두면, 프롬프트 주입으로 고객 목록을 밖으로 보내려는 시도는 런타임에서 걸립니다.

NVIDIA 보도자료와 기술 블로그를 바탕으로 정리

NemoClaw blueprints: 고른 하네스 위에 나머지 층을 조립하는 설계도

무엇인가. 모델, 하네스, 런타임, 최적화 도구를 한 번에 맞춰 둔 참조 설계 모음입니다. NVIDIA 기술 블로그는 NemoClaw가 새 하네스도 런타임도 아니라고 설명합니다. 개발자가 Hermes Agent, OpenClaw, LangChain Deep Agents 가운데 하나를 고르거나 자체 하네스를 가져오면, 블루프린트가 Nemotron 모델, OpenShell 정책, NeMo 최적화 도구를 그 위에 얹습니다. 기존 에이전트를 다시 짜지 않아도 됩니다. 언제 쓰나. 오픈 모델과 자체 인프라로 전용 에이전트를 만들려는데 조합을 처음부터 맞출 여력이 없을 때입니다. 원문의 예는 새로 나온 에이전트 최적화용 블루프린트입니다. 보강 자료에 따르면 LangChain은 모델을 다시 학습하지 않고 프롬프트, 도구, 미들웨어만 조정해 Nemotron 3 Ultra를 최상위권에 가깝게 끌어올렸고, 실행 1회 비용은 주요 상용 모델보다 약 10배 낮았다고 밝혔습니다.

블루프린트는 새 하네스가 아니라 이미 고른 하네스 위의 조립 설계

Agent optimization loop: 실패 기록을 시험 문제로 바꿔 하네스를 고치는 순환

무엇인가. 원문이 에이전트를 시간이 갈수록 더 잘 일하게 만든다고 소개한 블루프린트의 실제 흐름입니다. 기술 블로그 기준으로 다섯 단계입니다. NeMo Relay가 도구 호출과 LLM 호출의 실행 범위와 이벤트를 trace(실행 기록)로 남깁니다. NeMo Compass는 수천 건의 trace를 읽고 이상 행동, 도구 사용 패턴, 의도와 어긋난 행동을 찾아 근거 trace ID가 붙은 backlog(고칠 목록)로 정리합니다. NeMo Eval Author는 그 결과를 받아 verifier(합격 판정기)가 있는 평가 과제를 만듭니다. 코딩 에이전트가 하네스 한 곳을 고치면 개발 세트와 보류 세트(held-out, 수정하는 쪽에 보여 주지 않은 과제)로 전후를 잽니다. 둘 다 오를 때만 받아들입니다. 언제 쓰나. 이미 돌고 있는 에이전트에서 실패가 반복되는데 원인이 모델인지 프롬프트인지 도구 정의인지 모를 때입니다. 작은 예시(가상): 견적 에이전트가 할인율 승인 없이 견적을 보내는 실패가 반복되면, 그 규칙을 verifier로 만들고 하네스에 초안까지만 만든다는 규칙을 넣은 뒤 두 세트로 다시 잽니다.

NemoClaw for agent optimization 블루프린트가 묶은 흐름

통념과 다른 주장

흔히 이렇게 봅니다에이전트 품질은 결국 모델이 정한다고 봅니다. 더 큰 모델로 바꾸면 답이 좋아진다는 생각입니다.

저자는 이렇게 봅니다저자는 첫 문장에서 에이전트가 쓸모 있는 정도는 아는 것만큼이라고 말합니다(only as useful as what they know). 믿을 만한 정도는 경계가 정합니다. 그래서 모델 하나가 아니라 하네스, 런타임, 데이터, 도구를 함께 맞춘 스택이 필요하다고 봅니다.

근거원문의 사례 대부분은 모델 교체가 아니라 검색 단계와 데이터 층에서 나왔습니다. OpenSearch, SAP, ServiceNow의 개선이 모두 그렇습니다.

흔히 이렇게 봅니다회사 데이터를 에이전트에 쓰려면 데이터를 한 저장소로 모으고 권한 체계를 새로 짜야 한다고 봅니다.

저자는 이렇게 봅니다Knowledge Foundation은 데이터를 옮기지 않고, 기존 업무 흐름을 다시 만들지 않고, 거버넌스 통제도 바꾸지 않은 채 붙일 수 있다고 말합니다.

근거Palantir, Databricks, Snowflake 사례 모두 고객 데이터가 원래 플랫폼에 머문 채 그 안에서 NVIDIA 모델을 씁니다.

원문 주장은 발표 내용 기준. 근거는 아래 사례

저자가 든 사례

NVIDIA 공급망 조직: Palantir 위에서 돌리는 전용 에이전트

항목	내용
상황	NVIDIA 공급망 조직이 자사 고유 데이터로 판단 근거를 만들어야 함
한 일	Palantir Foundry, Ontology, AIP 위에서 Agent Knowledge Foundation을 써 전용 에이전트를 배치
결과	실행 가능한 인텔리전스 생성, 결과 예측, 의사결정 최적화. 효과 수치는 원문에서 밝히지 않음
연결	Knowledge Foundation이 기존 온톨로지 플랫폼 안에서 도는 예

효과 수치는 원문에서 밝히지 않음

Databricks와 Snowflake: 데이터 플랫폼 안에서 쓰는 Kumo

항목	내용
상황	데이터 플랫폼 고객이 플랫폼 안에서 예측 기능을 원함
한 일	Databricks는 Kumo Anomaly를 Genie Ontology와 짝지어 맥락을 아는 에이전트를 만들고, Snowflake는 Snowflake Notebook에서 Kumo Engine과 Kumo Relational을 쓰게 함
결과	예측 기능 확대. 정확도 수치는 원문에서 밝히지 않음
연결	데이터를 옮기지 않는다는 주장의 근거

두 회사 모두 자기 플랫폼의 맥락 층 위에 Kumo를 얹음

검색 단계: OpenSearch, SAP, ServiceNow, Zoom

항목	내용
상황	에이전트의 답이 검색 결과의 질에 좌우됨
한 일	Nemotron Retriever의 임베딩과 reranker(검색 후보를 다시 정렬하는 모델)를 도입
결과	OpenSearch는 더 적은 검색 단계로 관련도를 높이고 지연은 거의 늘지 않음. SAP의 미세 조정 reranker는 약 3배 빨라짐. ServiceNow는 정렬 품질을 높이며 지연을 약 4분의 1 줄임. Zoom은 문서 이해와 맥락 검색에 적용
연결	모델 교체 없이 데이터 층에서 품질이 오른 예

각 회사 발표 기준. 원문은 OpenSearch의 관련도 개선 폭을 숫자로 밝히지 않음

원문은 이 밖에 AWS, ClickHouse, Cloudera, Cohesity, Dassault Systèmes, Dell, Elastic, Exa, IBM, NetApp, Oracle, Perplexity, Starburst, VAST Data도 Knowledge Foundation 위에서 만들고 있다고 밝힙니다.

기술 디테일: 첫 에이전트에 경계와 개선 루프를 붙이려면

최적화 루프를 돌리려면 trace를 판정 가능한 단위로 남겨야 합니다. 실행 1회를 JSONL 한 줄로 쌓고, 그 안에 도구 호출 목록과 결과를 순서대로 넣습니다. Compass 같은 분석기는 이 기록과 행동 규칙 파일을 대조해 위반을 찾습니다. 규칙 파일은 업무 오너가 문장으로 쓰고 엔지니어가 verifier로 옮깁니다. 아래 필드는 이 노트의 제안이며 NeMo의 공식 스키마가 아닙니다.

{
  "run_id": "q-2026-11-05-0142",
  "task": "견적 초안 작성",
  "harness_version": "quote-agent@1.3.0",
  "model": "nemotron-3-super",
  "tool_calls": [
    {"name": "crm.lookup", "args_ok": true, "ms": 410},
    {"name": "mail.send", "args_ok": true, "ms": 220, "human_approved": false}
  ],
  "verdict": "fail",
  "violated_rule": "R-03 승인 없는 발송 금지",
  "evidence_ids": ["doc-311", "doc-318"]
}

필드 이름은 이 노트의 제안. NeMo 공식 스키마가 아님

수정을 받아들일지는 두 세트로 정합니다. 기술 블로그의 Hermes 예시에서 에이전트는 메시지 초안을 써 달라는 요청에 초안을 만든 뒤 사용자 확인 없이 보내기까지 했습니다. 하네스의 시스템 지시에 초안 요청은 준비만 허락한다는 규칙을 넣자 개발 세트 통과가 3/6에서 6/6으로, 보류 세트가 4/6에서 6/6으로 올랐습니다. 도구 호출은 10회에서 6회, 28회에서 15회로 줄었습니다. 같은 루프를 Dassault Systèmes의 차 문 설계 에이전트에 하룻밤(약 12시간) 돌리자 형식이 틀린 도구 호출이 142건에서 0건이 됐습니다. 원인은 인자가 엉뚱한 필드에 들어가는데 도구가 빈 오류만 돌려주던 데 있었습니다. 실제로 돌릴 때는 과제마다 3회 이상 반복 실행해 편차를 보고, temperature는 평가할 때 0~0.2로 낮게 고정합니다. 보류 세트는 수정하는 코딩 에이전트에게 절대 보여 주지 않습니다.

NVIDIA 기술 블로그(11.4)의 Hermes 예시. 보류 세트까지 오른 뒤에야 수정을 받아들임

OpenShell 정책은 막는 목록이 아니라 허용 목록으로 시작합니다. 첫 정책은 네 줄이면 됩니다. 작업 폴더 밖 파일 접근 차단, 허용한 도메인 외 네트워크 차단, 자격 증명은 샌드박스 밖 보관, 보내기·삭제·결제처럼 되돌릴 수 없는 도구는 사람 승인 뒤에만 실행입니다. 정책 위반 시도는 trace에 같이 남겨 Compass의 입력으로 씁니다. 실패하는 흔한 경우는 허용 목록이 좁아 정상 업무가 막히는 것입니다. 첫 2주는 차단 대신 기록만 하는 모드로 돌려 실제 호출 목록을 모은 뒤 허용 목록을 확정합니다.

가상 예시. OpenShell 문법이 아니라 정책을 정할 때의 항목 목록

검색, 행동, 비용을 따로 잽니다. 답이 틀렸을 때 원인이 검색인지 하네스인지 가려야 고칠 곳이 보입니다. 검색은 골든 질문 50개로 recall@10(정답 근거가 상위 10개 안에 드는 비율)을, 행동은 verifier 통과율과 규칙 위반 건수를, 비용은 실행 1회당 도구 호출 수와 토큰을, 지연은 p95 응답 시간을 봅니다. Retriever를 바꿀 때는 지연이 늘지 않는지 같이 확인합니다. OpenSearch 사례도 관련도와 지연을 함께 보고했습니다.

가상 예시. 숫자는 시작점으로 삼을 값이며 원문 수치가 아님

현업 실행 디테일: 누가, 언제, 무엇을

역할	담당	하는 일
업무 오너	해당 업무 팀장	에이전트가 지켜야 할 규칙 5~10개를 문장으로 씀, 합격 판정
AX 추진 PM	AX 추진 조직	범위·일정 관리, 주간 결과 보고
플랫폼 엔지니어	IT 아키텍처팀 1~2명	하네스·Relay·평가 환경 구성, 하네스 수정
보안 담당	CISO 조직 1명	OpenShell 허용 목록과 승인 대상 도구 확정
데이터 오너	시스템 담당자	검색 대상 데이터와 접근 권한 확인, 골든 질문 정답 검수

시작 전 준비물. 업무 하나(예: 견적 초안, 구매 요청 검토, 고객 문의 1차 답변), 그 업무의 과거 처리 사례 30~50건, 규칙 문서, 에이전트가 쓸 시스템 목록과 테스트 계정, GPU 또는 NVIDIA API 키입니다. 기술 블로그의 예제 환경은 Ubuntu 24.04, 8 vCPU, 32GB 메모리였습니다.

기간	할 일	산출물
1주	업무 선정, 규칙 문장화, 과거 사례로 골든 과제 만들기	규칙 파일, 골든 과제 30~50개(개발용 70%, 보류용 30%)
2주	하네스 구성, OpenShell 정책을 기록 모드로 운영	실제 호출 목록, 허용 목록 초안
3주	기준 성능 측정, trace 분석, verifier 작성	기준 점수표, 고칠 목록 상위 3개
4주	하네스 1곳 수정, 두 세트 재측정, 정책을 차단 모드로 전환	전후 비교표, 진행 여부 판정

가상 예시. 한 업무, 한 에이전트, 한 번의 개선 루프

업무 오너에게 물을 질문. 에이전트가 절대 혼자 하면 안 되는 행동은 무엇입니까? 사람이 처리할 때 가장 자주 틀리는 지점은 어디입니까? 같은 대상을 시스템마다 다르게 부르는 용어가 있습니까? 답에 반드시 근거로 붙어야 하는 문서는 무엇입니까? 결과가 몇 점이면 실제 업무에 넣겠습니까?

진행 판정 기준(예시). 보류 세트 통과율이 기준선보다 20%p 이상 오르고, 승인 없는 되돌릴 수 없는 행동이 0건이며, 실행 1회당 도구 호출이 늘지 않았으면 같은 업무를 실사용자 10명에게 넓힙니다. 개발 세트만 오르고 보류 세트가 그대로면 과적합으로 보고 수정을 버린 뒤 3주차부터 다시 돕니다. 기준은 측정 전에 정해 둡니다.

AX 적용 제언. 고객사가 이 발표에서 바로 가져갈 것은 제품 묶음보다 순서입니다. 효과가 가장 빨리 보이는 곳은 이미 운영 중인 RAG의 검색 모델 교체입니다. 위험이 가장 큰 곳은 메일 발송이나 시스템 수정 같은 되돌릴 수 없는 행동입니다. 그래서 검색 개선으로 신뢰를 얻고, 행동 에이전트로 넘어갈 때 런타임 경계와 개선 루프를 함께 세우는 편이 맞습니다. 보안 조직이 정책을 쥐고, 업무 오너가 verifier의 기준을 쥐게 하면 에이전트가 늘어도 통제 방식은 그대로 유지됩니다. 데이터 개념 맞추기(Auto-Ontology)는 두 번째 도메인으로 넓힐 때 꺼내도 늦지 않습니다.

효과가 빨리 보이는 검색부터, 위험이 큰 행동 통제를 그다음에

원문 사례

항목	내용
글	NVIDIA Blog, Erik Pounds, 2026.10.21 (GTC Berlin 발표)
핵심 주장	에이전트는 아는 만큼 쓸모 있고 경계만큼 믿을 수 있다. 모델·하네스·런타임·데이터·도구를 합친 오픈 스택이 필요하다
Toolkit 구성	Agent Knowledge Foundation(CUDA-X 포함), Nemotron Retriever·Kumo 오픈 모델, OpenShell, NemoClaw 블루프린트, NeMo Relay·NeMo Compass
새 부품	Auto-Ontology, Kumo Structured(Tabular·Relational·Time Series·Forecast), 에이전트 최적화용 NemoClaw 블루프린트
도입 사례	NVIDIA 공급망 조직(Palantir Foundry·Ontology·AIP), Databricks(Kumo Anomaly + Genie Ontology), Snowflake(Kumo Engine·Relational)
검색 수치	OpenSearch 관련도 개선·지연 거의 없음, SAP reranker 약 3배 빨라짐, ServiceNow 지연 약 4분의 1 감소, Zoom 적용
그 밖의 파트너	AWS, ClickHouse, Cloudera, Cohesity, Dassault Systèmes, Dell, Elastic, Exa, IBM, NetApp, Oracle, Perplexity, Starburst, VAST Data
보강 자료	OpenShell 참조 구조 보도자료(10.21), NemoClaw 기술 블로그, 에이전트 최적화 기술 블로그(11.4)

핵심 개념

harness: 모델 바깥에서 도구, 기억, 작업 흐름, 서브 에이전트를 묶어 에이전트를 움직이는 실행 틀.
trace: 에이전트 실행 1회에서 일어난 모델 호출과 도구 호출을 순서대로 남긴 기록.
verifier: 실행 결과가 정해 둔 조건을 지켰는지 합격·불합격을 가르는 판정 코드.
held-out set: 수정하는 쪽에 보여 주지 않고 남겨 둔 평가 과제. 과적합 여부를 가린다.
Sentry: BlueField-4 DPU에서 도는 감시 기능. 에이전트 행동을 따로 지켜보다 경계를 넘으면 격리한다.
NeMo Eval Author: trace 분석 결과와 규칙 파일로 평가 과제와 verifier를 만드는 코딩 에이전트용 스킬 모음.
CUDA-X: 데이터프레임, 그래프, 머신러닝, 최적화, 벡터 검색을 GPU로 돌리는 NVIDIA 라이브러리 모음.

내 메모

TODO: 내 생각 추가

원문: Erik Pounds, 「NVIDIA Agent Toolkit Expands, Grounding Enterprise Agents in Company Data」(NVIDIA Blog, 2026.10.21). 요약, 핵심 메커니즘의 원문 예, 통념과 다른 주장, 저자가 든 사례, 원문 사례 표는 원문 내용을 AX Review가 다시 정리했습니다. OpenShell, NemoClaw, 최적화 루프의 작동 방식과 Hermes·Dassault Systèmes 수치는 NVIDIA 보도자료 「NVIDIA Launches OpenShell Reference Architecture for Safe AI Agents」(2026.10.21)와 NVIDIA 기술 블로그 「Build Specialized Agents on a Stack You Control with NVIDIA NemoClaw」, 「Use NVIDIA NeMo to Turn Agent Failures into Tests and Harness Fixes」(2026.11.4)로 보강했습니다. 기술·현업 디테일, 가상 예시, 인포그래픽과 표는 새로 작성했습니다. 전체 내용은 원문에서 볼 수 있습니다.