NVIDIA Auto Ontology: 오픈소스 의미론적 계층으로 신뢰할 수 있는 에이전트 분석 구현

NVIDIA Auto Ontology는 Apache-2.0 라이선스의 Python 프레임워크로, 엔터프라이즈 데이터 위에 의미론적 그래프 기반 온톨로지 계층을 구축하여 LLM 및 에이전트 워크플로가 추측 대신 출처를 갖춘 결정적이고 검증된 SQL 쿼리를 생성할 수 있게 합니다. NVIDIA는 이를 github.com/NVIDIA/auto-ontology에 오픈소스 저장소로 공개했으며, Hacker News에서 206포인트와 70개의 댓글을 기록했습니다.

이 저장소는 자체 동기를 속도보다 신뢰성에 두고 있습니다: "에이전트는 문서를 검색하고 데이터베이스를 쿼리할 수 있지만, 신뢰성이 에이전트 분석을 좌우합니다: 숫자가 틀리면 더 빠르게 답한 매출 지표는 아무 가치가 없습니다." Auto Ontology는 에이전트에게 데이터가 어디에 있는지, 무엇을 의미하는지, 사용할지 여부, 사용 방법, 출처, 유사한 항목을 알려주는 컨텍스트 계층으로 포지셔닝됩니다. NVIDIA는 이 도구가 고객이 이미 보유한 의미론적 모델을 대체하는 것이 아니라 보완한다고 밝힙니다.

온톨로지 계층이 해결하는 문제

핵심 주장은 에이전트가 데이터베이스 접근 권한뿐만 아니라 인증된 비즈니스 의미가 필요하다는 것입니다. Auto Ontology는 기존 엔터프라이즈 메타데이터에서 계층을 구축하고, 시스템 간 정의를 조정하며, MCP, CLI 및 HTTP API를 통해 모든 에이전트 하네스에 결과를 노출합니다.

저장소에는 다섯 가지 기능이 나열되어 있습니다:

  • Discover: 메타데이터에서 엔터프라이즈 온톨로지를 생성하고, 기존 온톨로지 및 의미론적 모델을 연결하며, AI 준비 지식 그래프를 구축합니다.
  • Ground: 에이전트에게 지표, 엔터티 및 관계에 대한 신뢰할 수 있는 비즈니스 의미를 제공하고, 시스템 간 불일치하는 정의를 조정합니다.
  • Validate: 생성된 쿼리를 인증된 정의 및 계보와 대조하여 확인하고, 모든 답변에 출처를 반환합니다.
  • Expose: MCP, CLI 및 API를 통해 모든 에이전트 하네스에 컨텍스트를 제공합니다.
  • Learn: 인증된 수정 사항과 사용 내역을 온톨로지에 반영하여 공유 컨텍스트가 모든 질문으로 개선되도록 합니다.

소프트웨어 구성 요소 및 기본 포트

Auto Ontology는 다중 서비스 스택으로 제공됩니다. 프론트엔드는 Next.js 16 애플리케이션(React 19, TypeScript, Tailwind CSS 4)으로 Better Auth와 Prisma를 사용하며, 웹 UI, 인증 및 API 게이트웨이를 포트 3000에서 제공합니다. 백엔드는 Python 3.12+의 FastAPI와 LangChain으로, 채팅 및 자연어-to-SQL, 카탈로그, 데이터소스 API를 포트 3001에서 처리합니다. 별도의 FastAPI 수집 워커는 포트 3002에서 테이블 형식 데이터를 수집하고 임베딩을 작성합니다. 포트 5432의 pgvector가 포함된 Postgres는 애플리케이션 메타데이터, 카탈로그 및 온톨로지, 벡터 저장소를 저장합니다. HashiCorp Vault는 선택 사항이며 구성 요소 표에 할당된 포트가 없습니다.

웹 UI는 채팅, 분석, 데이터 카탈로그, 분석 및 설정을 포함합니다. 배포는 Kubernetes용 Helm 차트 또는 로컬 스택용 Docker Compose를 통해 지원됩니다.

추론은 NVIDIA NIM 및 모델 트리플렛으로 구성됩니다

Auto Ontology는 추론을 위해 NVIDIA NIM 엔드포인트를 사용합니다. 호스팅된 NVIDIA API 카탈로그(integrate.api.nvidia.com) 또는 자체 호스팅 NIM입니다. 저장소의 .env.example 기본값은 다음과 같습니다:

  • LLM: nvidia/nemotron-3-nano-30b-a3b
  • Embeddings: nvidia/nemotron-3-embed-1b
  • Reranking: nvidia/llama-nemotron-rerank-vl-1b-v2

각 모델 역할은 PREFIX_ENDPOINT URL, PREFIX_API_KEY 및 PREFIX_MODEL의 세 가지 환경 변수 트리플렛으로 구성됩니다. 역할은 DEFAULT_MODELS(다른 모든 것이 대체되는 공유 기본값), REASONING(주요 채팅 및 NL-to-SQL 모델), NON_REASONING(엔터티 추출에 사용되는 더 가벼운 모델), EMBED(텍스트 임베딩 모델, 수집과 쿼리 간에 일치해야 함) 및 RERANK(검색 흐름에서 사용되는 리랭커)입니다. 설정되지 않은 필드는 일치하는 DEFAULT_MODELS_ 필드로 대체되며, *_API_KEY는 이전 버전과의 호환성을 위해 레거시 NVIDIA_API_KEY 변수로도 대체됩니다.

배포 전제 조건

로컬 스택에는 Docker Compose v2가 포함된 Docker, build.nvidia.com에서 얻은 nvapi-... 형식의 NVIDIA API 키, 그리고 쿼리할 소스 데이터베이스의 연결 세부 정보가 필요합니다. 저장소에 명명된 지원 소스 시스템은 Databricks, Postgres, Snowflake 및 DuckDB입니다.

설치는 저장소를 클론하고 .env.example을 .env로 복사한 다음 Postgres 자격 증명, DEFAULT_MODELS_API_KEY 및 CONNECTION_STRINGS와 같은 값을 채우고 docker compose up -d --build를 실행하는 것입니다. 이 빌드는 백엔드(auto_ontology) 및 프론트엔드(auto-ontology-frontend) 이미지를 생성하고, Postgres 및 pgAdmin을 시작하고, 일회성 프론트엔드 마이그레이션 작업을 실행하여 데이터베이스 스키마를 동기화하고, 앱을 시작합니다. UI는 http://localhost:3000에서 제공되고, 백엔드 API는 포트 3001, pgAdmin은 포트 5050에서 제공됩니다.

저장소는 두 가지 구성 함정을 지적합니다. AUTH_SECRET 및 APP_URL이 필요하며, 없으면 모든 페이지가 Better Auth "기본 비밀" 오류로 실패합니다. POSTGRES_PORT는 호스트 측 포트 매핑만 변경합니다. 컨테이너는 항상 내부 네트워크 포트에서 Postgres에 도달하기 때문입니다. 또한 재시작 후 브라우저가 오래된 세션 쿠키를 보유하여 UI가 왼쪽 탐색 패널 없이 로드되는 문제 해결 사례를 문서화합니다. 이는 AUTH_SECRET이 변경되거나 데이터베이스가 재설정될 때 발생합니다. localhost:3000의 사이트 데이터를 지우거나 better-auth.session_token 쿠키를 삭제하면 해결됩니다.

자격 증명 저장은 Vault가 구성되지 않으면 기본적으로 일반 텍스트입니다

이것은 저장소에서 운영상 가장 중요한 보안 세부 사항입니다. UI를 통해 추가된 연결은 Vault가 구성되지 않는 한 자격 증명이 Postgres에 일반 텍스트로 저장됩니다. Vault가 없으면 비밀번호를 포함한 전체 연결 개체가 JSON 직렬화되어 카탈로그의 데이터베이스 행에 암호화되지 않은 채 저장됩니다. Vault가 있으면 자격 증명은 데이터베이스 이름을 키로 하여 Vault에 기록되고 카탈로그 행에는 자격 증명이 저장되지 않습니다. 데이터베이스 이름 자체가 조회 키이고 별도의 참조 필드가 없기 때문입니다.

Vault는 VAULT_ADDR, VAULT_NAMESPACE, VAULT_ROLE_ID 및 VAULT_SECRET_ID의 네 가지가 모두 설정된 경우에만 활성화됩니다. VAULT_AUTH_MOUNT 및 VAULT_KV_MOUNT는 선택적 재정의입니다. 기본적으로 꺼져 있으며, 부분 구성은 경고와 함께 무시되고 일반 텍스트 저장으로 대체됩니다.

연결 정의의 두 번째 소스는 CONNECTION_STRINGS 환경 변수로, 배포 시 제공되는 쉼표로 구분된 목록입니다(예: Helm --set connectionStrings= 플래그). 이 경로는 명시적으로 폴백입니다: UI에서 추가된 연결이 없을 때만 사용됩니다.

에이전트 API, API 토큰 및 FastAPI 신뢰 경계

공용 클라이언트는 POST /api/chat/completions에서 인증된 Next.js 게이트웨이를 호출합니다. 응답은 step, result 또는 error 이벤트 다음에 [DONE]이 오는 SSE 스트림입니다. conversation_id 필드는 선택 사항입니다: 상태 없는 일회성 요청의 경우 생략하거나, 클라이언트 생성 UUID를 제공하여 대화를 생성하거나 계속하고 모든 턴에 동일한 UUID를 재사용합니다. 호출자는 다음 턴을 보내기 전에 [DONE]을 기다려야 합니다. 한 대화에 대한 중복 요청은 409 Conversation in progress를 반환하기 때문입니다.

대화형 요청의 경우 FastAPI는 최근 완료된 최대 5턴(12,000자 제한)을 로드하고 "8월은 어때?"와 같은 컨텍스트 입력을 기존 텍스트-to-SQL 그래프를 실행하기 전에 독립 질문으로 재작성합니다. 독립 질문은 변경 없이 통과합니다. 내부 에이전트 생각, 차트 페이로드, 오류 및 원시 SQL 결과 집합은 컨텍스트로 재사용되지 않습니다. 대화 기록은 인증된 Auto Ontology 사용자로 범위가 지정됩니다.

저장소는 FastAPI 주변에 명시적인 보안 경계를 그립니다. FastAPI 포트는 공개적으로 노출되어서는 안 되는 신뢰할 수 있는 내부 서비스 경계라고 명시합니다. FastAPI는 Next.js 게이트웨이가 전달하는 내부 x-auto-ontology-user-id 헤더를 독립적으로 검증하지 않기 때문입니다. conversation_id가 없는 직접 FastAPI 요청은 상태가 없습니다. conversation_id가 있는 직접 요청은 신뢰할 수 있는 ID 헤더가 필요합니다. API로 생성된 대화는 서명된 사용자에게 속한 경우 UI에서 /chat?focus=로 열 수 있습니다.

API 토큰은 브라우저 세션 쿠키를 보유할 수 없는 스크립트, 노트북 및 예약 작업을 위해 존재합니다. 사용자 메뉴의 API 토큰에서 생성되며, Auto Ontology는 SHA-256 해시만 저장하므로 토큰은 정확히 한 번만 표시되고 분실하면 새로 생성해야 합니다. 토큰은 모든 /api/... 호출에서 x-api-key 헤더로 전송되며 Authorization: Bearer 도 작동합니다.

네 가지 토큰 동작이 문서화되어 있습니다:

  • 토큰은 소유자로 작동하며 자체 권한이 없으므로 모든 호출은 브라우저에서와 정확히 동일하게 소유자의 역할에 대해 권한이 부여되며, 뷰어의 토큰은 관리자 작업을 수행할 수 없습니다.
  • 전체 API 표면이 토큰을 허용합니다. 인증이 모든 경로에 대해 한 곳(frontend/auth/resolve-user.ts)에서 해결되기 때문에 docs/openapi/auto-ontology-api.json에서 withPublic으로 표시되지 않은 모든 엔드포인트는 토큰으로 작동합니다.
  • 해지는 즉각적입니다: UI에서 토큰을 삭제하거나 소유 사용자를 삭제하거나 금지하면 다음 요청에서 401을 받습니다.
  • 토큰은 토큰을 관리할 수 없습니다. 토큰 생성 및 해지에는 서명된 세션이 필요하므로 유출된 토큰은 스스로 후속 토큰을 발급할 수 없습니다.

인증을 위해 SSO가 지원되며, 리디렉션 URI는 ID 공급자에서 APP_URL/api/auth/sso/callback으로 구성됩니다.

MCP 서버 및 코딩 에이전트 스킬

Cursor 및 Claude Desktop과 같은 에이전트 하네스는 mcp/ 디렉토리 및 docs/mcp.md에 문서화된 Auto Ontology의 MCP 서버를 통해 데이터를 쿼리할 수 있습니다. 코딩 에이전트는 AGENTS.md에서 시작하도록 안내되며, skills/ 디렉토리에는 nvidia-ontology-setup, nvidia-ontology-management 및 nvidia-ontology-query의 세 가지 스킬이 포함되어 있습니다. 프로젝트 유지 관리자는 계속 CLAUDE.md를 사용합니다.

벤치마크는 참조되지만 저장소에 게시되지는 않습니다

저장소는 개발자를 github.com/NVIDIA/ontology-sql-eval의 별도 온톨로지 SQL 평가 저장소로 안내하여 BIRD와 같은 텍스트-to-SQL 벤치마크를 실행합니다. Auto Ontology 자체 README는 정확도, 지연 시간 또는 비용 수치를 게시하지 않으므로 프로젝트의 성능 주장은 저장소에서 인용하는 대신 해당 평가 하네스로 재현해야 합니다.

라이선스, 기여 및 외부 종속성

Auto Ontology는 SPDX 식별자 Apache-2.0으로 Apache License, Version 2.0에 따라 라이선스가 부여됩니다. NVIDIA 작성 소스 파일에는 "SPDX-FileCopyrightText: Copyright (c) 2024-2026, NVIDIA CORPORATION & AFFILIATES. All rights reserved." 및 "SPDX-License-Identifier: Apache-2.0" 헤더가 포함됩니다. 타사 오픈소스 구성 요소는 THIRD_PARTY_NOTICES.md에 업스트림 라이선스 및 프로젝트 URL과 함께 열거되며, 컨테이너 이미지에 의해 추가된 구성 요소는 CONTAINER_THIRD_PARTY_NOTICES.md에 별도로 나열됩니다.

오픈소스 라이선스에도 불구하고 프로젝트는 현재 외부 기여를 받지 않습니다: "Auto Ontology 유지 관리 팀 외부에서 제출된 이슈, 풀 리퀘스트 및 패치는 검토되거나 병합되지 않습니다." 보안 관련 보고서는 SECURITY.md를 통해 전달되며, 유지 관리자 워크플로는 CONTRIBUTING.md에 있습니다.

저장소에는 소프트웨어가 배포되지 않고 별도 약관이 적용되는 외부 자료를 검색하고 상호 작용한다는 고지도 포함되어 있습니다. 나열된 런타임 외부 자료는 채팅, 수집 및 의미론적 컴파일 중 LLM, 임베딩 및 리랭킹을 위한 build.nvidia.com 및 integrate.api.nvidia.com의 NVIDIA 호스팅 모델 API, 사용자가 *_ENDPOINT 및 *_MODEL 변수를 통해 구성하는 기타 OpenAI 호환 모델 엔드포인트, KUMO_RFM_API_KEY가 설정된 경우에만 사용되는 KumoRFM 예측 쿼리 서비스(Kumo 약관 적용), 그리고 수집, 프로파일링 및 쿼리 실행 중 사용자 자신의 소스 데이터베이스입니다.

Hacker News 토론의 반응

반응은 엔터프라이즈 온톨로지 작업을 AI의 실제 병목으로 보는 사람들과 또 다른 LLM 기반 계층을 추가하는 것이 에이전트 불안정성을 해결한다는 것에 회의적인 사람들로 나뉘었습니다.

가장 날카로운 기술적 반대는 grey-area에서 나왔으며, 아키텍처가 불확실성을 제거하기보다 추가한다고 주장했습니다:

불안정한 에이전트를 더 많은 불안정한 에이전트로 고치는 것. LLM이 분석 중인 데이터보다 자체 가중치에 더 많은 가중치를 두는 경향에 대해 우리가 뭔가 할 수 없다는 것이 유감입니다. 결국 그들이 세계에 대해 학습한 데이터, 지침 및 분석 중인 데이터를 명확히 구분하지 않는다는 사실로 귀결됩니다. 그들에게 눈앞의 5가지 사실만 고려하도록 요청할 수 있지만, 그들은 그렇게 하지 않을 것이고 할 수도 없습니다.

HexDecOctBin은 온톨로지 프레임이 초대하는 상징적 AI 질문을 제기했습니다: LLM을 사용하여 데이터에 맞는 상징적 규칙을 필요한 만큼 작성하면서 규칙 집합을 검토 가능하고 유지 관리 가능하게 유지하는 것은 어떨까요? 이 질문은 Auto Ontology 설계의 긴장을 직접 지적합니다. 이 설계는 LLM(NIM을 통해)을 사용하여 질문에 직접 답하는 대신 상징적이고 검토 가능한 카탈로그를 생성하고 유지 관리합니다.

여러 댓글 작성자는 제품이 끝나는 지점과 주변 복잡성이 시작되는 지점에 대해 의문을 제기했습니다. podocarp는 이것이 엔터프라이즈의 API와 CLI를 수집하는 메모리 시스템과 스킬의 조합과 무엇이 다른지 물었습니다. bbor는 README가 엔터프라이즈 프로젝트 관리자를 위해 작성되었다고 생각하고 프로젝트가 어떤 철학 또는 학술 온톨로지 작업과 연결되어 있는지 물었으며, 구체적인 내용을 따라가기 어렵다고 말했습니다. dstu는 첫 문장의 "게이트"라는 단어에 본능적인 반응을 보였고, 만들 가치가 있는 도구는 작성자 자신의 평범한 언어로 설명할 가치가 있다고 주장했습니다.

채택 마찰이 실질적인 반대 의견으로 제기되었습니다. igleria는 관심을 보였지만 프로젝트에 NVIDIA API 키가 필요하다는 것을 알고 실망했습니다. 이는 저장소와 일치합니다. NVIDIA API 키는 필수 전제 조건으로 나열되고 기본 모델 엔드포인트는 build.nvidia.com을 가리킵니다.

수요 측면에서 monkeydust는 엔터프라이즈 AI의 실제 성공에 중요하기 때문에 온톨로지를 올바르게 구축하는 데 많은 비용을 지출했다고 설명하고 이것이 도움이 될 수 있는지 궁금하다고 말했습니다. 원래 게시자 campervans는 가치 제안을 단호하게 요약했습니다: "엔터프라이즈(기술) 부채의 게임 체인저."

별도의 회의론 스레드는 NVIDIA의 오픈소스 자세를 더 광범위하게 겨냥했습니다. einpoklum은 다음과 같이 썼습니다:

오픈소스? NVIDIA 사용자 공간 라이브러리인 libcuda, libcudart, libOpenCL, libnvtx와 nvidia-smi 및 CUDA와 OpenCL 프로파일러를 오픈소스화하는 것부터 시작하는 게 어떨까요?

이 비판은 Auto Ontology 자체의 라이선스(Apache-2.0)가 아니라 업스트림 드라이버 및 툴체인 구성 요소에 관한 것입니다.

Auto Ontology 채택 전 확인 사항

저장소에서 특정 배포에 대해 확인할 가치가 있는 세 가지가 있습니다. 첫째, UI에서 추가된 연결의 자격 증명 저장은 네 가지 Vault 변수가 모두 설정되지 않는 한 Postgres에서 일반 텍스트가 기본값이므로 프로덕션 데이터베이스 비밀번호를 처리하는 모든 배포에서 Vault 구성은 선택 사항이 아닙니다. 둘째, FastAPI 포트는 공개적으로 노출되어서는 안 됩니다. 해당 경계에서 ID 헤더가 검증되지 않고 신뢰되기 때문입니다. 셋째, 프로젝트는 자체 벤치마크 결과를 게시하지 않습니다. README는 독자를 BIRD와 같은 텍스트-to-SQL 벤치마크 실행을 위한 별도 ontology-sql-eval 저장소로 안내할 뿐입니다. 잠재적 채택자는 외부 기여가 현재 닫혀 있으므로 로드맵이 전적으로 NVIDIA 유지 관리 팀에 의해 통제된다는 점도 고려해야 합니다.

Sources