Agent Knowledge Foundation: 엔비디아가 회사 테이블에서 업무 개념 지도를 뽑아 에이전트에 주는 오픈소스

에이전트를 데이터베이스에 연결해도 회사의 말을 알아듣지는 못합니다. NVIDIA는 테이블에서 '고객', '주문', '요금제' 같은 업무 개념과 관계를 자동으로 뽑아 에이전트에 주는 오픈소스 부품을 내놓았습니다. 실제로 쓰려면 자동 초안을 현업이 인증하는 절차와, 그 결과를 골든 질문으로 시험하는 기준이 함께 있어야 합니다.

요약

The New Stack의 Frederic Lardinois는 NVIDIA가 GTC Berlin에서 발표한 Agent Knowledge Foundation(에이전트용 지식 기반 부품 묶음)을 전합니다. NVIDIA Agent Toolkit에 더해진 오픈소스 묶음으로 네 가지가 들어 있습니다. 검색을 맡는 Nemotron Retriever 모델, 테이블을 업무 개념으로 바꾸는 새 Auto-Ontology 라이브러리, 표 데이터로 예측하는 Kumo 모델, 그리고 CUDA-X 데이터 처리 라이브러리입니다. 출발점은 NVIDIA 에이전틱 AI 제품 담당 부사장 Adel El Hallak의 문제의식입니다. 에이전트를 Snowflake 같은 플랫폼에 붙여도 회사 전체의 맥락은 생기지 않고 탭이 여러 개인 스프레드시트 한 장에서도 헤맨다는 것입니다. 데이터는 원래 시스템에 그대로 두고 접근 규칙도 그대로 따르게 했다는 점이 설계의 전제입니다.

NVIDIA 개발자 페이지가 제시한 다섯 단계. 데이터는 원래 플랫폼에 두고 각 단계에 부품만 끼운다

기사가 내세운 숫자는 주로 검색 단계에서 나왔습니다. 오픈소스 OpenSearch 환경에서 Nemotron Retriever를 쓰자 검색 관련도가 65% 올랐고 추가 지연은 거의 없었습니다. SAP의 미세 조정 reranker는 약 3배 빨라졌고 ServiceNow는 지연을 약 25% 줄이면서 정렬 품질을 높였습니다. 더 큰 변화는 RAG(비슷한 문서 조각을 찾아 붙이는 방식)에서 온톨로지(업무 개념과 관계를 정의한 지도)로 무게를 옮긴 것입니다. El Hallak은 ‘RAG was awesome, but is it good enough?‘라고 묻습니다. 통신사에서 tier와 plan이 같은 뜻이라는 사실을 LLM은 자주 놓치니 표마다 다른 용어를 먼저 맞춰야 한다는 답입니다. 그렇게 맞춘 표 위에서 Kumo가 예측을 돌리고 데이터 보관과 권한 관리는 Palantir, Databricks, Snowflake 같은 파트너가 맡습니다. 아래에서는 이 구조를 부품별로 풀고 공개 저장소를 근거로 실제 파일럿 설계를 덧붙입니다.

검색 단계 파트너 수치(기사·NVIDIA 발표 기준)

핵심 메커니즘

Agent Knowledge Foundation: 데이터를 옮기지 않고 끼우는 부품 묶음

새 플랫폼이 아니라 기존 데이터 플랫폼, 벡터 DB, 에이전트 프레임워크 옆에 끼우는 부품 모음입니다. NVIDIA 개발자 페이지는 회사 데이터가 에이전트의 판단이 되기까지를 다섯 단계로 나눕니다. 문서와 표를 정리하고(Nemotron Parse, cuDF), 근거를 찾아 순서를 매기고(Nemotron Embed, Rerank, cuVS), 뜻을 맞추고(Auto-Ontology), 예측하고(Kumo, cuGraph, cuML), 계획으로 바꿉니다(cuOpt). 부품은 골라 쓸 수 있어서 시맨틱 레이어(업무 용어와 실제 열을 이어 둔 층)가 이미 있는 회사는 검색 모델만 가져가도 됩니다.

Nemotron Retriever: 조회 한 번보다 답이 나올 때까지를 줄이는 검색

임베딩 모델이 질문과 문서를 벡터로 바꿔 후보를 찾고 reranker가 후보를 다시 읽어 근거가 강한 순서로 세웁니다. El Hallak의 논리는 정확한 임베딩과 reranker가 조회 한 번의 지연을 조금 늘리더라도, 에이전트가 다시 찾는 횟수가 줄어 전체 지연은 낮아진다는 것입니다. 에이전트는 틀린 조각을 받으면 질문을 바꿔 또 찾습니다. 그래서 모델은 조회당 속도가 아니라 질문 하나에 검색이 몇 번 도는지로 비교합니다.

조회당 지연이 아니라 답이 나올 때까지 걸린 전체 시간으로 비교한다

Auto-Ontology: 테이블 메타데이터로 업무 개념 지도의 초안을 만드는 라이브러리

회사 테이블을 읽어 고객, 제품, 주문 같은 업무 개념과 그 관계를 만들고 에이전트가 REST API나 MCP 서버로 물을 수 있게 합니다. 공개 저장소(Apache 2.0)를 보면 이 개념을 Term이라 부르고 Term마다 실제 열(ColumnAttribute)과 계산식(SqlAttribute)을 붙입니다. 작동 순서는 다섯 단계입니다. 테이블마다 열 이름, 타입, 샘플 값을 읽고 종류가 적은 열은 고유값까지 봅니다. LLM이 열 설명을 쓰고 Term과 동의어를 뽑습니다. 결과를 임베딩해 Postgres의 pgvector에 넣습니다. 그 뒤 테이블 사이의 의미상 외래키(semantic FK)를 찾고 쿼리 이력에서 자주 쓰는 계산식을 SqlAttribute로 제안합니다. 개인정보로 보이는 열에는 PII 태그를 답니다. NVIDIA는 이것을 완성본이 아니라 전문가가 시험하고 고쳐 인증하는 출발점으로 설명하며 자체 시험에서 온톨로지 작성 시간이 90% 줄었다고 밝힙니다.

공개 저장소 코드 기준으로 재구성. 1~4는 자동, 5는 사람이 한다

작은 예시(가상). 통신사 데이터에 billing 테이블의 tier, CRM의 plan, 사용량 테이블의 plan_cd가 있다고 합시다. 에이전트는 셋을 다른 것으로 보고 ‘요금제별 이탈률’을 엉뚱하게 셉니다. Auto-Ontology가 셋을 Term ‘요금제’의 열로 묶고 현업이 그 정의를 인증하면, 에이전트는 어느 표를 쓰든 같은 개념으로 계산합니다.

가상 예시. 이름이 다른 세 열을 Term 하나로 묶어야 에이전트가 같은 것을 같게 센다

MCP 서버: 원본 스키마 대신 개념 층으로만 묻게 하는 통로

Auto-Ontology의 MCP 서버는 읽기만 합니다. 주력 도구 ask_question은 질문을 받아 답, 실행한 SQL, 결과 행을 함께 돌려주고 check_answerable은 시맨틱 층이 그 질문을 덮는지 먼저 판정합니다. search_terms, get_term, describe_table로 용어와 연결된 열을 볼 수 있지만 원본 스키마를 훑는 도구는 일부러 두지 않았습니다. 에이전트가 인증된 개념으로만 데이터에 닿게 하려는 설계입니다. MCP 서버는 자체 자격 증명이 없고 로그인한 사람의 권한으로만 움직입니다.

저장소 문서 기준. MCP 서버는 권한을 따로 갖지 않고 로그인한 사람의 권한으로만 움직인다

Kumo: 맞춰진 표 위에서 돌리는 사전학습 예측 모델

Kumo는 관계형·표·시계열 데이터를 위한 파운데이션 모델입니다. 데이터팀은 지금까지 분류, 이탈 예측, 감성 분석처럼 업무마다 파이프라인을 따로 만들었는데, Kumo는 사전학습 모델 하나로 이 일을 대신하려 합니다. El Hallak은 온톨로지가 표를 조화시켜야 Kumo가 예측을 제대로 돌릴 수 있다고 설명합니다. 가중치는 Hugging Face에 공개됐고 블로그 기준으로 Kumo Tabular, Relational, Time Series, Forecast가 있습니다. 예측 결과는 cuOpt가 제약 조건과 합쳐 경로, 일정, 자원 배분 계획으로 바꿉니다.

예측 모델을 업무마다 따로 만들던 일을 사전학습 모델 하나로 바꾸는 구조

파트너 구조: 권한과 저장은 원래 플랫폼에 두는 분업

NVIDIA는 데이터 플랫폼과 경쟁하지 않겠다고 말합니다. ACL(접근 제어 목록)과 데이터 접근 관리는 파트너가 하고 NVIDIA는 모델과 라이브러리만 공급합니다. 이미 Databricks나 Snowflake에 맥락 층을 쌓은 회사는 그 층을 그대로 두고 NVIDIA 모델만 더하면 됩니다. Auto-Ontology도 자기 형식 외에 Apache Ossie 형식으로 모델을 내보내고 들여올 수 있습니다.

데이터를 옮기지 않고 부품만 끼우는 구조. 권한은 원래 플랫폼에 남는다

통념과 다른 주장

흔히 이렇게 봅니다에이전트를 데이터 플랫폼에 연결하고 RAG를 붙이면 회사 데이터를 이해한다고 봅니다.

기사 속 NVIDIA는 이렇게 봅니다연결만으로는 회사 맥락이 생기지 않습니다. 비슷한 조각을 찾는 방식은 표마다 다른 용어를 맞추지 못하니 개념과 관계를 먼저 세워야 합니다.

근거El Hallak은 탭이 많은 스프레드시트 한 장에서도 에이전트가 헤매고 통신사의 tier와 plan처럼 같은 것을 다르게 부르는 용어를 LLM이 자주 섞는다고 설명합니다.

기사 속 NVIDIA 쪽 주장 정리

흔히 이렇게 봅니다정확한 모델은 느리니 응답 속도가 중요하면 작은 검색 모델을 쓴다고 봅니다.

기사 속 NVIDIA는 이렇게 봅니다에이전트에서는 가장 정확한 임베딩과 reranker를 쓰는 편이 낫습니다. 조회 한 번은 조금 느려져도 조회 횟수가 줄어 전체 지연이 내려갑니다.

근거OpenSearch 시험에서 관련도가 65% 오르면서 검색 단계는 줄고 추가 지연은 거의 없었고 ServiceNow는 품질을 높이면서 지연을 약 25% 줄였습니다.

OpenSearch 시험에서 관련도가 오르고 추가 지연은 거의 없었다는 것이 근거

저자가 든 사례

검색 단계: OpenSearch, SAP, ServiceNow

상황: 에이전트 검색이 엉뚱한 조각을 가져와 여러 번 다시 찾습니다.
한 일: OpenSearch는 Nemotron Retriever 임베딩을 붙였고 SAP는 reranker를 미세 조정했고 ServiceNow는 reranking을 바꿨습니다.
결과: 관련도 65% 향상(OpenSearch), 약 3배 속도(SAP), 지연 약 25% 감소(ServiceNow). 모두 벤더 발표 수치입니다.
연결: Nemotron Retriever 메커니즘의 사례입니다.

OpenSearch, SAP, ServiceNow 사례(벤더 발표 수치)

NVIDIA 공급망 조직: Palantir 위에서 쓰는 지식 기반

상황: NVIDIA 자체 공급망 조직이 사내 데이터로 판단하는 에이전트가 필요했습니다.
한 일: 이전부터 함께 일해 온 Palantir의 Foundry(블로그 기준 Ontology, AIP 포함) 위에서 Agent Knowledge Foundation을 씁니다.
결과: 전문 에이전트를 배치해 예측과 의사결정 최적화에 쓴다고 밝혔습니다. 효과 수치는 원문에서 밝히지 않았습니다.
연결: 파트너 구조의 사례입니다. 온톨로지와 권한은 Palantir에 두고 NVIDIA 부품을 얹었습니다.

NVIDIA 공급망 조직이 Palantir 플랫폼에서 쓰는 사례

Databricks와 Snowflake: 플랫폼의 맥락 층 위에 Kumo

상황: 두 플랫폼 모두 자기 맥락 층과 노트북 환경을 이미 갖고 있습니다.
한 일: Databricks는 Kumo 이상 탐지 모델을 6월에 내놓은 Genie Ontology와 짝지었고 Snowflake는 고객이 Snowflake Notebooks에서 Kumo 모델을 돌리게 했습니다.
결과: 데이터를 옮기지 않고 예측 기능을 더했습니다. 정확도 수치는 원문에서 밝히지 않았습니다.
연결: Kumo와 파트너 구조의 사례입니다.

두 플랫폼 모두 자기 맥락 층 위에 NVIDIA 모델을 얹는다

인수로 모은 팀과 SAP의 반대 전략

상황: 온톨로지와 표 데이터 예측은 LLM만으로 잘 풀리지 않는 영역입니다.
한 일: NVIDIA는 2월 온톨로지 자동 생성 스타트업 Illumex를 인수했고(Globes 보도 7,500만 달러), 6월 Kumo를 인수했습니다(The Information 보도 4억 달러 이상). SAP는 반대로 7월 TabPFN을 만든 Prior Labs 인수를 마쳤고(4년간 10억 유로 이상 투자 약속), SAP AI Core에서 TabPFN-3.5 Plus를 자체 RPT 모델과 함께 제공합니다.
결과: NVIDIA는 가중치를 Hugging Face에 공개해 어느 플랫폼에서나 쓰게 하고 SAP는 표 모델을 자기 스택 안에 둡니다.
연결: Auto-Ontology와 Kumo가 어디서 왔는지, 그리고 파트너 구조가 왜 NVIDIA의 선택인지를 보여 줍니다.

기사가 대비한 두 전략. 인수 금액은 각 매체 보도치

기술 디테일: 우리 데이터로 첫 온톨로지를 돌리려면

아래는 공개 저장소(github.com/NVIDIA/auto-ontology)의 문서와 코드를 근거로 AX Review가 새로 짠 파일럿 설계입니다. 저장소에 없는 숫자는 가상 예시입니다.

Auto-Ontology를 띄우려면 Docker Compose로 네 구성 요소를 올립니다. Next.js 프론트엔드(3000번 포트, 로그인과 API 게이트웨이), FastAPI 백엔드(3001, 채팅·NL→SQL·카탈로그), 수집 워커(3002, 테이블을 읽고 임베딩을 씀), Postgres와 pgvector(5432, 카탈로그·온톨로지·벡터)입니다. 모델은 NVIDIA NIM 엔드포인트를 쓰며 호스팅 API 카탈로그나 자체 설치 NIM 중에 고릅니다. 원본 DB는 README 기준 Databricks, Postgres, Snowflake, DuckDB이고 코드에는 ClickHouse, MySQL, Trino 커넥터도 있습니다. .env에는 AUTH_SECRET과 APP_URL을 반드시 넣어야 화면이 뜹니다.

저장소 기본값. 각 역할은 ENDPOINT·API_KEY·MODEL 세 변수로 바꾼다

보안 설정은 첫날 정합니다. 화면에서 추가한 DB 접속 정보는 Vault를 켜지 않으면 Postgres에 평문으로 저장됩니다. VAULT_ADDR, VAULT_NAMESPACE, VAULT_ROLE_ID, VAULT_SECRET_ID 네 변수를 모두 넣어야 Vault가 켜지고 하나라도 빠지면 경고만 남기고 평문으로 돌아갑니다. 원본 DB에는 읽기 전용 계정을 따로 만들어 연결합니다. FastAPI 포트(3001)는 사용자 식별 헤더를 따로 검증하지 않으니 외부에 열지 않고 Next.js 게이트웨이만 엽니다. 스크립트용 API 토큰은 만든 사람의 권한으로만 움직이고 지우는 즉시 막힙니다.

모델은 역할별로 나눠 비용을 잡습니다. Term 추출처럼 호출이 많은 일은 NON_REASONING에 가벼운 모델을, NL→SQL은 REASONING에 기본 Nemotron 모델을 둡니다. EMBED 모델은 수집할 때와 질문할 때 같아야 하므로 바꾸면 임베딩을 다시 만들어야 합니다. 코드 주석에는 FK 해석 단계만 한 DB에서 300초를 넘긴 기록이 있습니다. 첫 실행은 한 도메인의 테이블 20~40개로 범위를 좁혀 시간과 토큰을 잽니다(가상 예시 범위).

골든 질문으로 시험합니다. 현업이 실제로 묻는 질문 50개와 정답 SQL을 먼저 만듭니다. 질문마다 check_answerable로 시맨틱 층이 덮는지 보고 덮는다면 ask_question으로 SQL과 결과 행을 받아 정답 SQL의 결과와 값을 비교합니다. 덮지 못한다고 판정한 질문은 지어낸 답보다 낫다고 보고 따로 셉니다. 저장소는 BIRD 같은 text-to-SQL 벤치마크용 평가 저장소(ontology-sql-eval)를 따로 안내합니다. 결과는 아래처럼 질문마다 한 줄로 남깁니다.

{
  "q_id": "scm-017",
  "question": "지난달 납기 지연 공급사 상위 10곳",
  "answerable": true,
  "terms_used": ["공급사", "납기", "구매 오더"],
  "sql_match": false,
  "row_diff": "지연 기준을 입고일로 계산, 정답은 확약 납기일",
  "fix": "Term '납기 지연'의 SqlAttribute 정의 수정 후 재인증",
  "checked_at": "2026-11-03"
}

가상 예시 설계. 덮지 못한다는 판정도 맞는 답으로 센다

자동 초안과 사람 확인의 경계를 정합니다. 저장소의 모델링 지침은 열 이름이 같다고 조인이 맞는 것은 아니라고 강조합니다. 관계마다 방향, 1:1·1:N·N:M 다중도, 키가 비거나 중복될 때의 동작, 조인 범위를 적고 시험합니다. 측정값은 행 단위, 단위, 분자·분모, 0으로 나눌 때의 동작을 적습니다. 1:N 조인 뒤에 상위 수준 합계를 다시 더하면 값이 부풀고 비율의 평균과 합계의 비율은 다릅니다. Term 이름과 설명에는 name_certified, description_certified 표시가 있으니 현업이 확인한 것만 인증으로 바꿉니다. 저장소 스스로 인증 기능이 원자적 승인·배포 시스템은 아니라고 밝히므로, 모델을 들여오기 전에 범위를 백업하고 다시 내보내 비교합니다.

저장소의 모델링 지침이 강조한 확인 항목을 정리

Kumo는 그 다음에 붙입니다. 저장소는 KUMO_RFM_API_KEY가 있을 때만 KumoRFM 예측 서비스를 부르므로, 골든 질문 시험을 통과한 도메인에서만 켭니다.

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

역할	담당	4주 동안 하는 일
스폰서	대상 도메인 임원(예: SCM 총괄)	도메인과 골든 질문 승인, 판정 회의 주재
도메인 전문가	현업 2명(구매·물류 등)	핵심 Term 정의, 인증, 골든 질문 작성
데이터 엔지니어	1명	설치, 읽기 전용 접속, 컴파일, 시험 자동화
데이터 거버넌스	데이터 스튜어드 1명	기존 용어 사전·시맨틱 모델과 대조
보안	1명	Vault, 포트 노출, 토큰·권한 점검, PII 태그 확인
AX 추진	PM 1명	일정, 정답률 집계, 판정 보고서

시작 전 준비물: 대상 도메인의 테이블 목록과 담당자, 기존 데이터 사전이나 BI 지표 정의서, 최근 3개월 쿼리 이력(SqlAttribute 제안에 쓰임), 현업이 자주 묻는 질문 50개와 정답 SQL, 읽기 전용 DB 계정, NVIDIA API 키 또는 자체 NIM 엔드포인트.

주차	할 일	산출물
1주	도메인과 테이블 20~40개 확정, 설치, 보안 설정, 골든 질문 50개 작성	범위 정의서, 골든 질문 세트
2주	의미 컴파일 실행, Term·관계·SqlAttribute 초안 검토 목록 작성	Term 초안 목록, 소요 시간·토큰 기록
3주	핵심 Term 인증, 조인·측정값 계약 확인, 골든 질문 1차 시험	인증 Term 목록, 정답률 표
4주	오답 원인별 수정, 2차 시험, 판정 회의	판정 보고서, 다음 도메인 제안

가상 예시 일정. 한 도메인, 테이블 20~40개 기준

도메인 전문가에게 물을 것.

같은 대상을 시스템마다 다르게 부르는 말은 무엇입니까? (예: 거래처·공급사·벤더)
같은 이름인데 부서마다 세는 범위가 다른 지표는 무엇입니까? (예: 활성 고객, 납기 준수율)
이 지표는 무엇을 무엇으로 나눕니까? 기간은 주문일, 출하일, 입고일 중 어느 것입니까?
두 테이블을 잇는 열 가운데 실제로는 다르게 맞춰야 하는 것이 있습니까?
에이전트가 답하면 안 되는 질문이나 볼 수 없어야 하는 열은 무엇입니까?

진행 판정 기준(예시). 핵심 Term의 80% 이상이 인증되고 골든 질문 가운데 답할 수 있다고 판정된 질문의 정답률이 85% 이상이며 답할 수 없는 질문을 지어내 답한 경우가 0건이면 다음 도메인으로 넓힙니다. 정답률이 70%에 못 미치면 오답을 Term 정의, 조인, 측정값 계산 중 어디서 틀렸는지 나눠 해당 항목을 고친 뒤 3주차부터 다시 돕니다. 기준은 시험 전에 정합니다.

AX 적용 제언. 제조·유통 고객사에서 에이전트가 막히는 지점은 대개 모델보다 용어입니다. ERP, MES, PLM, CRM이 같은 품목·거래처·고객을 서로 다른 코드와 이름으로 들고 있기 때문입니다. 그래서 첫 과제는 에이전트를 만드는 일보다 한 도메인의 개념 지도를 인증하는 일로 잡는 편이 맞습니다. 이미 Databricks, Snowflake, Palantir에 시맨틱 층이 있으면 그것을 기준으로 두고 Auto-Ontology는 빈칸을 채우는 초안 도구로 씁니다. 순서는 SCM이나 영업처럼 질문이 많고 지표 정의 다툼이 잦은 도메인 하나, 자동 초안, 현업 인증, MCP 연결과 골든 질문 시험, 다음 도메인과 Kumo 예측 순입니다. 자동 생성은 며칠이면 끝나지만 인증은 사람이 하므로 일정에는 현업 전문가의 시간을 먼저 잡습니다.

온톨로지를 만드는 일보다 인증하는 일에 현업 시간을 먼저 잡는다

원문 사례

항목	내용
기사	The New Stack, Frederic Lardinois, 2026.10.21 (GTC Berlin 발표)
발표 내용	NVIDIA Agent Toolkit에 Agent Knowledge Foundation 추가: Nemotron Retriever, Auto-Ontology, Kumo, CUDA-X 데이터 처리 라이브러리
화자	Adel El Hallak, NVIDIA 에이전틱 AI 제품 담당 부사장
검색 수치	OpenSearch 관련도 65% 향상(추가 지연 거의 없음), SAP reranker 약 3배 빨라짐, ServiceNow 지연 약 25% 감소
Auto-Ontology	회사 테이블로 지식 그래프를 만들어 고객·제품·주문 같은 업무 개념에 연결, REST API와 MCP 서버로 제공, NGC 카탈로그 등록
Kumo	관계형 데이터용 파운데이션 모델, Hugging Face에 가중치 공개, Kumo Tabular 9월 공개
파트너	NVIDIA 공급망 조직(Palantir Foundry), Databricks(Kumo 이상 탐지 + Genie Ontology), Snowflake(Notebooks에서 Kumo)
인수	Illumex 2월(Globes 보도 7,500만 달러), Kumo 6월(The Information 보도 4억 달러 이상)
대비 사례	SAP의 Prior Labs 인수(7월 완료, 4년간 10억 유로 이상 약속), SAP AI Core에서 TabPFN-3.5 Plus와 RPT 모델 제공
공식 자료 보강	개발자 페이지: 다섯 단계 흐름, 온톨로지 작성 시간 90% 감소(NVIDIA 자체 시험). NGC: Auto-Ontology 백엔드 1.1.0, Apache 2.0

핵심 개념

Term: Auto-Ontology에서 업무 개념 하나를 가리키는 단위. 이름, 설명, 동의어, 연결된 열과 계산식을 함께 가진다.
SqlAttribute: Term 아래에 정의한 계산식. 매출, 지연 일수처럼 열을 조합한 값을 SQL 식으로 고정해 둔 것.
semantic FK: 스키마에 외래키로 선언되지 않았어도 의미상 두 테이블을 잇는 관계 후보.
reranker: 검색이 찾은 후보를 질문과 함께 다시 읽어 근거가 강한 순서로 정렬하는 모델.
NIM: NVIDIA가 모델을 API 엔드포인트로 띄우는 추론 패키지. 호스팅형과 자체 설치형이 있다.
ACL: 누가 어떤 데이터에 접근할 수 있는지 정한 목록. 이 구조에서는 데이터 플랫폼이 관리한다.
Apache Ossie: Auto-Ontology가 내보내기·들여오기에서 지원하는 시맨틱 모델 교환 형식.

내 메모

TODO: 내 생각 추가

원문: Frederic Lardinois, 「Nvidia bets open models can give enterprise AI agents the context they’re missing」(The New Stack, 2026.10.21). 요약, 통념과 다른 주장, 저자가 든 사례, 원문 사례 표는 기사 내용을 AX Review가 다시 정리했습니다. Auto-Ontology의 작동 단계, 모델 설정, MCP 도구, 보안 설정은 NVIDIA 공식 자료(developer.nvidia.com의 Agent Knowledge Foundation 페이지, NVIDIA 블로그 2026.10.21 발표, NGC 카탈로그, GitHub NVIDIA/auto-ontology 저장소의 README·docs/mcp.md·skills 문서와 코드)로 보강했습니다. 기술·현업 실행 디테일, JSON 예시, 일정, 질문, 판정 기준, 인포그래픽은 원문에 없는 내용으로 새로 작성했으며 가상 예시가 섞여 있습니다. 전체 내용은 원문에서 볼 수 있습니다.