요약
엔비디아가 AI 에이전트가 사내 데이터의 뜻을 알고 SQL을 짜도록 돕는 auto-ontology를 공개했습니다.
엔비디아가 Apache 2.0 라이선스로 내놓은 오픈소스 프로젝트입니다. 에이전트가 빨리 답해도 숫자가 틀리면 쓸모없다고 보고, 데이터가 어디 있고 무슨 뜻인지 알려 주는 계층을 데이터베이스 위에 얹습니다.
왜 중요한가
- 문법이 맞는 SQL을 만들어도 엉뚱한 표나 정의를 고르면 답이 틀립니다. 이 프로젝트는 그 문제를 사람이 검증한 정의로 막으려 합니다.
- 데이터로 답할 수 없는 질문이면 지어내지 않고 답할 수 없다고 밝히도록 설계했습니다.
- 다만 README에는 정확도 수치가 없고, 평가는 별도 저장소로 넘겼습니다.
핵심 내용
- 스키마와 샘플 값을 읽어 LLM으로 업무 용어를 뽑고, 쿼리 기록에서 표 사이 관계와 계산식을 제안합니다.
- 이렇게 만든 온톨로지(업무 용어와 데이터의 관계를 정리한 체계)를 사람이 실제 질문으로 시험하고 고쳐서 '인증'합니다.
- 답할 때는 임베딩 검색(뜻이 가까운 항목을 찾는 방식)으로 후보 열을 고르고, SQL을 검증·수정해 추론 단계와 함께 돌려줍니다.
- PostgreSQL, Snowflake, Databricks, DuckDB 등 SQL 엔진 10종을 지원하고 MCP, CLI, REST API로 쓸 수 있습니다.
- 기본 모델은 NVIDIA NIM의 Nemotron 계열이지만 OpenAI 호환 엔드포인트도 쓸 수 있습니다.
HN 반응
- 첫 문장 'reliability gates agentic analytics'처럼 AI가 쓴 듯한 README 탓에 무슨 도구인지 모르겠다는 비판이 토론 대부분을 차지했습니다.
- 열 이름과 실제 뜻이 다르면 소용없다는 우려에, 결국 사람이 관리하는 데이터셋과 운영 규율이 먼저라는 경험담이 이어졌습니다.
쓸모가 꽤 있을 수도 있겠지만, Claude 때문에 제 버릇이 완전히 망가졌어요. 첫 문장에 나오는 'gates'를 보자마자 본능적으로 거부감이 들어서 더 읽지 못했습니다. 만들어서 공유할 만한 도구라면, 그게 무엇을 하려는 건지 직접 쓴 짧은 요약 정도는 붙일 가치가 있지 않나요?
Claude 특유의 'robolect(로봇 방언)'를 모르면 그 문장은 거의 이해 불가입니다. (방금 단어를 하나 지어냈는데, 언어 덕후 소양이 없어도 뜻이 통했으면 좋겠네요.)
Claudish robolect, 지금 바로 제 언어에 추가할게요. 고맙습니다.
들으라, Claude의 폼파터스(Pompatus)를 입에 올리는 자여…
Claudish는 아주 크로멀런트(cromulent)한 단어예요.
진지하게 말하자면, 이런 최신 기능들을 가리킬 때 특정 업체에 매인 용어 말고 다 같이 쓰는 용어를 쓰기 시작하면 좋겠어요. 이러다간 JVM이냐 .NET 실행 엔진이냐 같은 구분 싸움으로 흘러가서, 시장에서 벌어지는 일만 더 흐려질 뿐이에요.
Clodish(얼간이스러운 말).
"reliability gates agentic analytics"는 적어도 영어가 모국어가 아닌 사람 눈에는 꽤 헷갈리는 문장(garden path sentence)입니다.
영어에서 더 흔한 표현은 gated가 아니라 "held back"입니다.
그리고 엔비디아는 아마 "환각을 포함한 확률적 응답 때문에 신뢰할 수 있는 AI 분석이 불가능하다"라고 쓰고 싶지 않았겠죠.
지금 문장은 전달하는 정보가 거의 없습니다. 신뢰할 수 없는 이유는 여러 가지입니다. 하드웨어 문제입니까? 소프트웨어입니까? 사용자입니까? 의도적으로 필요해서 쓰는 난수 생성기 때문입니까? Claude는 독자도 자기와 똑같은 가중치가 활성화되어 있다고 전제합니다.
저는 이 맥락에서 "Gate"라는 단어를 써 본 적이 있어요.
요즘 사람들은 모든 데에서 'AI'를 보더라고요. 구분이 안 돼요.
이제는 사람이 뭐가 AI이고 뭐가 아닌지를 두고 환각을 일으키는 셈이죠.
gate를 동사로 쓰는 건 미국 영어에서는 극히 드뭅니다. 영국 영어에서는 좀 더 흔할지도 모르겠습니다. Claude를 정기적으로 접하지 않는 사람 중에 그걸 헛소리 말고 다른 무엇으로 받아들일 사람은 거의 없을 거라고 봅니다.
gate를 동사로 쓰는 건 전혀 문제없습니다. 제가 자란 미국 동네에서는 늘 보는 표현입니다. 이 문장의 문제는 단어 선택보다 더 깊은 곳에 있습니다. 정치인 화법과 비슷해서, Claude가 하려는 말을 기술적으로는 담고 있지만 정확한 맥락은 끝까지 짚지 않습니다. 그래서 백만 가지로 해석할 수 있고, 잘 읽어 주기만 하면 어느 해석이든 맞습니다. 결국 아무 말도 안 하는 겁니다.
저는 이게 RLVR과 합성 데이터의 결과라고 확신합니다. LLM은 사람 독자가 아니라 학습 과정에서 만나는 LLM 평가자를 통과하도록 최적화되고, 결국 궤변술을 익히게 됩니다.
ㅋㅋ
사람들이 'gate'라는 단어를 어떻게 쓰는지를 두고 "gatekeeping"을 하고 있네요.
그러니까 Claude 모양의 가독성 게이트가 있다고 주장하시는 거네요? /s
제가 Twitch 스트리머 몇 명을 걸러내는 작업을 하고 있었는데, 겉보기엔 멀쩡한 미국인 스트리머 중에 글을 못 읽거나 겨우 읽는 사람이 예상 밖으로 많아서 좀 놀랐어요.
그 일에 쓰던 게임은 줄거리를 채우는 장치로 흔한 메모장 방식을 쓰는데, 많은 사람이 자기 모국어인데도 더듬더듬 겨우 읽더라고요.
그래서 이건 전적으로 Claude 탓만은 아니라는 게 제 인상이에요.
최대한 보수적으로 말하자면 '난독증' 탓으로 돌리겠습니다.
그 뒤에 이런 문장이 이어집니다. "...a revenue metric answered faster is worth nothing if the number is wrong."(...매출 지표를 더 빨리 답해 줘도 숫자가 틀리면 아무 가치가 없다.) 사람이 이걸 썼다고 진지하게 주장하시는 겁니까?
기업 특유의 말투라서 헷갈려요. 이건 대기업이 낸 거잖아요. 마케팅 슬롭은 AI 이전에도 있었어요. 저는 구분이 안 돼요. 어쩌면 그게 요점일 수도 있겠네요. 사람도 배배 꼬인 문장을 써 왔으니, 문장이 어떻게 들리는지만 보고 단정할 수는 없어요.
저는 모국어 화자로서 이 문장을 "AI 모델 루프가 사용하는 모든 분석 기능을 켜고 끄는 것을 제어한다"라는 뜻으로 읽었습니다.
저도 모델이 자기 문서를 자기 언어로, 나중에 스스로 참고하려고 보관하게 둘 때가 있습니다. 하지만 그건 사람에게 배포할 용도가 아닙니다. 단어와 표현 선택이 이상하기 때문입니다(이른바 슬롭).
제 생각엔 조금 다른 것 같습니다. 신뢰성이 없으면 에이전트형 분석은 쓸모없다는 뜻입니다.
또는, 에이전트형 분석은 충분한 신뢰성이 있어야 가능하다는 뜻입니다.
아니면 정말로 짧고 알아듣기 어렵게 줄이면 이렇게 됩니다. Reliability gates agentic analytics.
README를 끝까지 다 읽었는데도 '검색 가능한 지식 베이스'라는 것 말고는 이게 뭘 하는 건지 도무지 모르겠습니다. 사용 사례라도 좀 보여 주면 안 됩니까?
README가 너무 형편없이 쓰여서 여기 많은 분이 이해를 못 한 것 같으니, 제가 설명을 시도해 볼게요.
"Auto Ontology"는 좀 안 좋은 이름이에요.
문제는 이렇습니다.
회사의 데이터가 여러 종류의 데이터베이스에 흩어져 있습니다. 의사결정을 하는 사람들은 그 데이터에 대해 질문하고 싶어 하고요.
예전 방식은 데이터 분석가에게 가서 "이러이러한 보고서 좀 뽑아 주세요"라고 말하는 거였고, 필요한 정보를 만들어 내려고 알맞은 쿼리와 일회성 스크립트를 짜 맞추는 건 분석가의 몫이었죠.
이런 시스템에서는 모든 데이터베이스 모델을 인트로스펙션(introspection)해서 중앙 메타데이터 카탈로그에 저장해 둔다는 발상입니다.
"5월에 가장 많이 팔린 품목은 뭐였나?" 같은 질문이 들어오면 메타데이터 카탈로그가 "Products는 FOO_DB에 있고" "Product_Sales는 BAR DB에 있다"고 알려 줍니다. 그러면 올바른 곳에서 올바른 데이터를 가져와서 필요한 계산은 메모리에서 처리하는 거죠.
이 시스템이 제공하는 건 다음에 대한 구현 코드입니다.
각 DB를 인트로스펙션
모델과 메타데이터 정보를 중앙의 가상 DB(VDB)로 통합
자연어 질의로부터 방언(dialect)에 맞는 SQL을 생성하고, 해당 테이블이 있는 DB로 보내기
자연어 질의에 데이터 소스가 여러 개 필요할 때 결과를 메모리에서 결합
권한 처리 등
이걸 제대로 하는 좋은 시스템은 외부 API 소스(OpenAPI, GraphQL, gRPC, 뭐든)와 문서 소스(에헴, 제가 이걸 만들고 있어요, 에헴)까지 통합합니다.
컬럼 이름이 실제로 저장된 데이터를 제대로 나타내지 않고(그러면 좋겠지만 저희 회사는 지금 그렇지 않거든요), 그 내용이 전부 우리 데이터 사이언티스트들만 아는 암묵지라면 어떻게 되나요? 걱정되는 건 윗분들이 이게 자기 질문에 답하고 있다고 믿어 버릴 텐데, 사실은 A. 답이 틀렸거나 B. 법적인 이유로 그들이 만들려는 프로젝트에서 쓸 수 없는 데이터일 수 있다는 걸 모를 거라는 점이에요.
저는 마케팅 분석 조직에서 이 문제를 다루고 있습니다.
autoontology 같은 건 사람이 거버넌스를 강제하는 '승인된(blessed)' 데이터셋에 도움이 될 겁니다. 그래도 그런 데이터셋을 만들고, 그걸 채택하도록 변화를 이끌려면 운영상의 엄밀함과 데이터 성숙도는 여전히 있어야 합니다.
이건 사실상 도구와 라벨링 계층입니다. 하지만 이 모든 문제의 뿌리에 늘 있던 지저분한 사람 문제를 마법처럼 해결해 주지는 않습니다.
제가 일하는 제품에는 원본 테이블 설명 위에 사용자가 제공한 정의, 메모, 주석을 대응시켜 주는 메타데이터 계층이 있습니다.
필수는 아니지만, 스키마 설계가 부실할 때 수동으로 덮어쓸 수 있게 해 줍니다.
그게 핵심 문제입니다. 저는 이걸 의미 격차(semantic gap)라고 부릅니다.
예를 들어 뒤에 데이터베이스가 있는 트랜잭션 애플리케이션이 있다고 해 봅시다. 사용자는 애플리케이션과 정보를 주고받습니다. 애플리케이션은 비교적 빈약한 데이터를 트랜잭션 데이터베이스에 저장합니다. 데이터베이스에는 트랜잭션에서 나온 데이터를 라우팅할 만큼의 메타데이터만 있고, 온전한 의미까지는 담겨 있지 않습니다.
타임스탬프 타입의 "updated_date" 컬럼이 있다고 합시다. 데이터를 들여다보지 않고서 이 컬럼이 애플리케이션이 행을 처음 저장할 때 채워지는지 어떻게 압니까? 사용자 눈에 보이는 그 타임스탬프의 시간대가 무엇인지는 어떻게 압니까?
실제 사례를 들자면, 앱과 API에서 환자의 키는 SI 단위이고 둘 다 단위를 명시합니다. 그런데 데이터 웨어하우스에서 환자의 키는 단위 표기 없이 미국 관용 단위입니다. 앱과 API는 기반이 되는 트랜잭션 데이터베이스가 미국 관용 단위로 저장하기 때문에 복잡한 변환을 거칩니다.
LLM 온톨로지가 약속하는 바는 애플리케이션 코드를 읽어서 특정 데이터베이스 컬럼의 맥락을 이해하는 것이라고 생각합니다. 링크된 소프트웨어는 그런 게 아닙니다.
여러 마이크로서비스가 얽힌 복잡한 실제 대규모 시스템에서 온톨로지를 찾아내는 건 꽤 어렵습니다. 제 생각에 가장 좋은 방법은 소스 코드 자체에서 데이터베이스 스키마 세부 사항과 테이블 간 조인 등을 파악하는 겁니다. 소스 코드에는 비즈니스 맥락도 담겨 있으니까요. 저는 이 방법이 꽤 잘 통했습니다. 하지만 그 밖에도 어려운 점이 많습니다. KPI는 쿼리가 고정되어 있다든가, 제품 간 교차 쿼리, 대용량 데이터 가져오기, 메모리에서 조인하기 위한 올바른 아키텍처 구성 같은 것들이요.
"README가 너무 형편없이 쓰여서 여기 많은 분이 이해를 못 한 것 같다"는 말씀에 공감합니다.
저도 README를 끝까지 읽어 보려 했는데 그냥 동기도 없는 슬롭이었습니다. 에이전트가 읽기엔 더 나을지도 모르겠네요. 밴 헤일런의 라이더(rider) 일화랑 비슷합니다. 작성자들이 좋은 README를 쓰는 데 신경 쓰지 않았다면, 방대한 나머지 코드베이스에는 얼마나 신경 썼을까요?
저는 결국 README를 LLM에 던졌고, 훨씬 간단하고 명확한 설명을 받았어요. 도움이 된 부분만 옮겨 올게요.
그리고 맨 끝에 있던 한 문단짜리 요약이에요.
저도 그렇게 README를 파싱하고 요약하는 건 직접 할 수 있었어요. 하지만 요점은 작성자가 제대로 된 README를 써 줄 만큼 신경 쓰지 않은 프로젝트에 제 소중한 시간을 쓸 필요가 없다는 겁니다. 게다가 시맨틱 웹/그래프 인덱서와 쿼리 도구는 새로운 게 아니에요. 온톨로지 구조를 분류하고 질의할 새로운 도구들이 생겼다는 점을 빼면요.
그걸 못 한다면, 이 프로젝트에 의지할 만큼 세부 사항에 신경 쓰지 않았다는 신호입니다. 게다가 지금은 제 한정된 시간을 쏟을 수 있는 멋진 소프트웨어가 그 어느 때보다 많아요.
공정하지 못한 판단일 수도 있고 훌륭한 프로젝트일 수도 있지만, 이제는 기준이 훨씬 높아졌습니다.
죄송해요, 맞습니다. 제 글에서 원래 하려던 말을 전혀 못 전했네요. 쓰다가 직장에서 무슨 일로 호출을 받는 바람에 중간에 말하려던 요점을 놓쳤어요.
슬롭을 덜어 내고 더 간결하고 이해하기 쉬운 글로 바꾸려고 LLM을 써야 했다는 사실 자체가 말이 안 돼요. 저라면 그런 README가 달린 걸 내놓았다간 창피했을 거예요.
저는 소스 코드를 직접 파고들고 나서야 이게 뭔지 알았습니다. 예를 들면 이런 파일이에요.
https://github.com/NVIDIA/auto-ontology/blob/main/auto_ontology/connectors/mysql.py