엔비디아 오토 온톨로지(NVIDIA Auto Ontology): AI 에이전트의 데이터 추측을 멈추는 시맨틱 레이어와 주의할 점 4가지
엔비디아가 공개한 오토 온톨로지는 AI 에이전트가 기업 데이터에 대해 잘못된 SQL을 추측해서 작성하지 않도록 비즈니스 의미 기반의 지도(온톨로지)를 구축해 주는 오픈소스 프로젝트입니다. 모호한 질문에 대해 무작정 거짓 답변을 지어내기보다 정확한 단계와 함께 모른다고 답할 줄 아는 정교한 구조를 갖추고 있습니다. 하지만 중복 컬럼명 데이터 누락 버그, 외부 API 전송에 따른 개인정보 이슈 등 도입 전 반드시 짚고 넘어가야 할 치명적인 한계점들이 존재합니다.
1. 깃허브 트렌딩 2위에 오른 엔비디아 오토 온톨로지
기업 데이터베이스에 질문을 던졌을 때, AI 에이전트가 단 몇 초 만에 SQL 쿼리와 함께 명확한 숫자를 보여준다면 무척 편리할 것입니다. 하지만 그 과정에서 도출된 숫자가 완전히 틀린 값이라면 빠른 속도는 아무런 의미가 없습니다.
"빠른 숫자는 틀렸다면 아무런 가치가 없습니다."
엔비디아의 오토 온톨로지(Auto-Ontology)는 바로 이 지점을 파고들며 깃허브(GitHub) 트렌딩 순위 2위에 올랐습니다. 아파치 2.0 라이선스로 공개된 이 프로젝트는 단 하루 만에 약 2,000개의 스타를 모으며 누적 8,700개 이상의 스타를 기록할 정도로 뜨거운 관심을 받았습니다.
기업 환경에서 "매출이 얼마인가요?"라는 질문을 던지면, 기존 AI는 매출이 '청구 기준'인지 '출고 기준'인지, 수많은 고객 테이블 중 어떤 것을 참조해야 할지 제멋대로 추측하곤 했습니다. 엔비디아 오토 온톨로지는 바로 이러한 맹목적인 추측을 명확한 데이터 시맨틱 지도로 대체하고자 합니다.
2. AI 에이전트를 위한 온톨로지 구조
오토 온톨로지가 구축하는 '지도'는 데이터가 실제로 무엇을 의미하는지 규명하며, 크게 세 가지 요소로 구성됩니다 🗺️.
- 용어(Terms): 고객이나 청구서 항목처럼 실제 테이블의 컬럼과 연결된 비즈니스 개념 및 동의어 집합입니다.
- SQL 속성(SQL Attributes): 마진율처럼 사전 검토를 거쳐 표준화된 공식으로, 어떤 질문에서도 매번 동일한 방식으로 계산되도록 보장합니다.
- 관계(Relationships): 여러 테이블이 서로 어떻게 연결(Join)되는지 정의합니다.
이 모든 온톨로지 정보는 PostgreSQL과 PG Vector에 임베딩 벡터 형태로 저장되어, AI 에이전트가 사용자의 자연어 질문을 바탕으로 빠르게 검색하고 참조할 수 있도록 지원합니다.
3. Text-to-SQL 에이전트의 3단계 작동 방식
오토 온톨로지는 단순히 질의를 SQL로 바꾸는 데 그치지 않고 체계적인 3단계를 거칩니다.
- 생성(Generation): 데이터베이스 스키마를 읽어 컬럼을 분석하고 샘플 데이터를 추출합니다. 이후 LLM이 엔티티를 명명하고 연결 관계를 추론합니다. (엔비디아 샘플 데이터 기준 31개의 용어가 자동 생성되었습니다.)
- 인증(Certification): 데이터 담당자가 실제 비즈니스 질문으로 테스트하고, 설명을 수정한 뒤 올바른 정의를 공식 승인합니다.
- 답변(Answering): 사용자가 질문하면 에이전트가 엔티티를 추출하고, 벡터 검색으로 일치하는 용어를 찾은 뒤 SQL을 작성합니다. 이후 필터링 조건이 실제 DB 값과 맞는지 검증하고, 오류가 발생하면 스스로 쿼리를 수정한 뒤 실행 단계별 과정과 함께 최종 답변을 반환합니다.
특히 인상적인 기능은 답변할 수 없을 때 이를 솔직하게 인정하는 답변 가능 여부 확인(check_answerable) 로직입니다.
"답변할 수 없다고 말하는 에이전트가 거짓으로 숫자를 지어내는 에이전트보다 훨씬 낫습니다."
예를 들어 광고 데이터가 전혀 없는 샘플 DB에 "광고비 대비 매출액(ROAS)을 알려줘"라고 묻는다면, 커버리지 점수(0.5)를 측정해 광고비에 해당하는 용어가 없음을 감지합니다. 그리고 무리하게 숫자를 지어내는 대신 "계산할 수 없다"고 안내하며 대체 지표로 매출 조회를 제안합니다.
4. 지원 환경 및 사용 방법
오토 온톨로지는 기업의 다양한 데이터 환경을 폭넓게 지원합니다.
- 지원 데이터베이스: PostgreSQL, MySQL, Snowflake, Databricks, ClickHouse, DuckDB 등 10개 주요 데이터 엔진 지원
- 에이전트 연동 방식: 읽기 전용 도구를 갖춘 MCP(Model Context Protocol) 서버, 코딩 에이전트를 위한 3가지 에이전트 스킬, 표준 REST API
직접 실행해보려면 Docker Compose와 uv 패키지 매니저, 그리고 엔비디아 API 키(build.nvidia.com)가 필요합니다. 저장소를 복제한 뒤 .env 환경 변수를 설정하고, 마이크로소프트의 샘플 DB(Wide World Importers)를 로드하여 Docker를 띄우면 로컬 웹 환경(localhost:3000)에서 바로 테스트해 볼 수 있습니다.
5. 도입 전 반드시 알아야 할 4가지 주의점
오토 온톨로지는 콘셉트가 훌륭하지만, 실무에 바로 투입하기에는 치명적인 함정들이 존재합니다 ⚠️.
① 408번 이슈: 에러 없이 데이터가 덮어씌워지는 치명적 버그
쿼리 결과에서 서로 다른 두 컬럼의 이름이 동일할 경우(예: 고객 ID와 주문 ID가 둘 다 id로 조회될 때), PostgreSQL, MySQL, SQLite 커넥터가 행 데이터를 컬럼명을 키로 하는 딕셔너리로 변환하면서 한쪽 값이 다른 쪽 값을 덮어써 버리는 버그가 있습니다.
실제 이슈 제보에서는 고객 정보(Ada)가 완전히 증발하고 주문 ID만 남았음에도 불구하고 에러 필드에는 None으로 표시되어 재시도조차 발동하지 않았습니다. 동일한 구조를 15줄의 파이썬 코드로 재현한 결과, 중복 컬럼명을 명시적인 별칭(Alias, 예: customer_id, order_id)으로 지정해 주어야만 데이터 누락을 방지할 수 있었습니다.
② 데이터 외부 유출 및 개인정보(PII) 노출 위험
기본 설정 상태에서는 질의 생성을 위해 엔비디아 호스팅 API를 사용합니다. 이 과정에서 컬럼의 실제 샘플 데이터가 프롬프트에 포함되어 전송됩니다. 아직 개인정보(PII) 태그를 감지해 필터링하는 파이프라인이 완성되지 않아(PR #419), 고객의 실제 이름이나 이메일이 외부 모델로 전달될 수 있습니다. 또한 예측 기능인 Kumo RFM을 켜면 연결된 테이블이 외부 Kumo 서비스로 업로드되므로 사전에 철저한 데이터 보안 검토가 필요합니다. 사내 보안 규정이 엄격하다면 자체 호스팅 NIM이나 사내 통제 하의 엔드포인트를 사용해야 합니다.
③ 백엔드 포트 보안 취약점
README에서는 포트 4001과 4002를 반드시 프라이빗 네트워크에 격리할 것을 권장하고 있습니다. 백엔드가 프론트엔드에서 전달하는 사용자 헤더를 그대로 신뢰하며, 수집(Ingest), 삭제, 초기화 등의 민감한 엔드포인트에 자체 인증 체계가 마련되어 있지 않기 때문입니다.
④ 미성숙한 초기 프로젝트와 외부 기여 제한
현재 이 프로젝트는 외부 개발자의 코드 기여(외부 PR)를 받지 않는 폐쇄적인 구조로 운영되고 있습니다. 또한 문서 내에서도 한쪽 섹션에서는 Neumatron 3 임베딩 모델을, 다른 쪽에서는 Neumatron 3.5를 언급하는 등 문서 완성도 면에서도 아직 초기 단계의 혼란을 보여줍니다.
마치며
엔비디아 오토 온톨로지는 LLM이 데이터베이스를 안전하게 질의하기 위해 반드시 거쳐야 할 '데이터 시맨틱 레이어'라는 정확한 문제를 해결하려 하고 있습니다. 투명한 SQL 생성 과정과 모를 때 솔직히 시인하는 설계는 돋보이지만, 아직 프로젝트 초기의 불안정성을 내포하고 있습니다.
따라서 실무에 도입할 때는 쿼리에 반드시 컬럼 별칭(Alias)을 부여하고, 외부 호스팅 대신 사내 모델 엔드포인트를 연결하며, 백엔드 포트 보안을 철저히 격리한 상태에서 신중하게 검증해 보는 접근이 필요합니다.