Knowledge-Graph

사용자가 자연어 질의를 입력한 뒤 최종 답변을 받을 때까지 각 컴포넌트가 어떤 순서로 동작하는지 정리한 글입니다. 이 글은 시리즈의 첫 글입니다. 각 구성 요소를 왜 그렇게 선택했는지, 실험 과정에서 무엇이 달라졌는지는 이어지는 글에서 다룹니다. 단일 NL2SQL의 한계와 라우팅 구조 NL2SQL을 실운영 환경에 처음 적용하면 같은 문제를 반복해서 만납니다. DDL만으로는 T_CUST_MST 같은 약어 테이블이 무슨 의미인지, “순매출"이 어떤 산식인지 LLM이 파악·추론하지 못합니다. 공개 벤치마크가 아무리 올라가도 실제 엔터프라이즈 환경에서는 정확도가 절반 이하라는 보고가 꾸준히 나옵니다. 같은 종류의 오답은 데이터셋을 바꿔도 사라지지 않습니다. ...

LLM이 생성한 답변을 그대로 신뢰하기 어려운 이유와 Agentic AI 환경에서 온톨로지 기반 검증 체계가 필요한 배경을 정리했습니다.

별도의 벡터 데이터베이스 없이 tree-sitter AST 파싱과 지식 그래프로 코드와 문서를 분석하는 오픈소스 도구 graphify를 소개합니다.

마이크로소프트가 제공하는 무료 온톨로지 학습 및 실습 플랫폼인 Ontology Playground를 소개하며, 대화형 그래프와 RDF 파일 변환 기능을 활용하는 방법을 다룹니다.

AI 에이전트의 품질을 결정하는 핵심은 조직의 맥락입니다. AI 노트테이커 티로(Tiro)가 회의록을 기반으로 개념과 관계를 자동으로 연결하여 프리 온톨로지를 구축하고 소수 정예 팀으로 AX를 실현하는 구체적인 방법을 소개합니다.

AI 도입 견적이 수억 원대로 부푸는 원인을 분석하고, 비IT 기업이 겪는 AX 2단계의 현실과 온톨로지 기반의 데이터 루프 구축 방식을 설명합니다.

LLM Graph Builder는 PDF, 영상 등 비정형 데이터를 LLM으로 분석해 Neo4j 지식 그래프로 변환하는 오픈소스입니다. 노드와 관계를 추출하고 다양한 LLM과 질의 모드를 지원하며 복잡한 데이터 속에서 필요한 정보를 대화하듯 찾아줍니다.

AI 에이전트가 로컬 파일을 검색할 때 발생하는 심각한 토큰 낭비와 지연 시간을 해결하고자, 벡터 DB 없이 결정론적 파일 지도와 LLM Wiki를 활용하는 오픈소스 Jikji의 효율적인 탐색 구조를 분석합니다.

LLM Wiki는 Andrej Karpathy의 위키 패턴을 구현한 데스크톱 앱입니다. RAG의 한계를 넘어 LLM이 문서를 분석, 점진적으로 지식 그래프 기반 위키를 구축하며 개인 지식 관리의 새로운 길을 제시합니다.

사전 지식 그래프를 구축하지 않고 질문 시점에 논리 구조를 동적으로 생성하는 LogicRAG의 작동 원리와 효율성을 다룹니다.

AI 개발 시 토큰 낭비와 에이전트 맥락 손실은 흔한 문제입니다. 이는 AI가 다루는 대상 관계가 불분명해서 생기는데, 그래프를 활용해 명시적으로 만들면 해결됩니다. codegraph와 ActiveGraph 두 프로젝트로 그 방법을 알아봅니다.

지난 10편까지는 SQL 생성 과정에서 주로 발생하는 오답 유형을 분석했습니다. BIRD와 Spider 벤치마크를 활용하고 다양한 모델을 테스트하면서 오답을 COLUMN_BINDING, VALUE_BINDING, DERIVED_METRIC 등의 유형으로 세분화했습니다. SQL 오답을 계속 들여다보면서, 확인하고 싶은 것이 달라졌습니다. “그렇다면 생성된 SQL과 답변의 근거는 화면에서 어떻게 시각화되어야 하는가?” 그동안 정확도 중심의 테스트에 집중하느라 실제 사용자가 화면에서 무엇을 확인해야 하는지는 놓치고 있었습니다. 비즈니스 환경에서 쓰는 데이터 분석 AI라면 수치가 어디서 왔는지 명확히 보여야 합니다. 근거를 확인할 방법이 없다면 결과가 정답처럼 보이더라도 사용자는 결국 SQL을 다시 실행하여 검증할 수밖에 없습니다. ...

실무 문서의 핵심인 표와 차트를 정교하게 분석하는 기술을 살펴봅니다. 이중 그래프 구조로 데이터 간 맥락을 연결해 검색 정확도를 높였습니다.

9편에서 multi-candidate 실험 세 건이 모두 유의미한 결과를 내지 못했지만 Schema Binding Plan으로 넘어가기 전에 확인하고 싶은 것이 하나 더 있었습니다. 모델 성능이 병목의 원인일 수 있다는 가설을 검증했습니다. Gemini flash-lite 대신 Pro 모델을 쓰면 현재 56% 수준인 정확도를 개선할 수 있을 것이라 예상했습니다. 이 과정에서 오답 유형 분류와 Spider 실험도 함께 진행했습니다. Pro 모델로 바꿨더니 오히려 정확도가 떨어졌다 모델만 교체하고 동일한 BIRD 50문항을 실행했습니다(프롬프트, 컨텍스트, 파이프라인은 그대로). 지표는 EX(Execution Accuracy)로, 생성된 SQL을 실제로 실행했을 때 정답과 같은 결과가 나오는지 확인하는 방식입니다. ...

라우팅 설계를 붙인 뒤 30문항 벤치마크에서 NL2SQL EX(Execution Accuracy)를 66.67%에서 80%까지 올렸습니다. 4사이클 동안 무엇을 고쳤고 어떤 한계에 부딪혔는지 정리합니다.

용어 정의를 마친 뒤, 질문이 들어왔을 때 그래프를 탈지 SQL을 작성할지 벡터 검색을 실행할지 정하는 라우터 설계 과정을 정리합니다.

Conway 유출이 나온 지 얼마 지나지 않아 Anthropic이 Claude Managed Agents를 정식 발표했습니다. 에이전트 인프라가 플랫폼에 흡수되는 흐름 속에서 DataNexus의 온톨로지가 왜 안전한지 정리합니다.

상품 마스터 DB의 데이터가 어떤 파이프라인을 거쳐 HTML 의 JSON-LD가 되는지 정리합니다. 3단계 파이프라인 구조와 SSR 기반 자동 배포 아키텍처를 다룹니다.

korean-law-mcp가 법제처 API를 64개 tool로 정리해 파이프 역할을 하고, DataNexus 온톨로지 레이어가 법령 간 위임 관계를 그래프로 잡아주면 AI가 추론 대신 탐색으로 법령을 해석할 수 있습니다.

구글 상위 10위 페이지 중 AI가 인용하는 비율은 9%에 불과합니다. SEO 순위가 AI 인용을 보장하지 않는 시대에 GEO의 3대 원칙과 학술 근거를 정리합니다.

DataNexus 온톨로지를 외부와 연결하기 위해 SKOS를 선택한 이유를 정리합니다. LPG와 RDF, 두 그래프 모델을 잇는 호환 레이어 설계를 설명합니다.

DataHub의 Business Glossary를 온톨로지 저장소로 쓰려 했습니다. 가능한 것과 어려운 것, 그리고 우회한 방법을 정리합니다.

DataNexus의 기술 스택을 DataHub + Vanna + ApeRAG + DozerDB로 결정한 과정을 정리합니다. 후보군에서 탈락한 것들과 그 이유도 함께 설명합니다.

“VIP 기준이 뭐죠?” 유통사 BI Agent 프로젝트에서 있었던 일입니다. 현업 담당자가 테스트 중에 Agent에게 물었습니다. “지난달 VIP 고객 매출 알려줘.” 시스템이 숫자를 뱉어냈는데, 담당자 표정이 좋지 않았습니다. “이거 뭔가 이상한데요. VIP 기준이 우리 팀이랑 다른 것 같아요.” 마케팅의 VIP와 CRM의 VIP가 달랐습니다. 매출도 마찬가지입니다. 순매출이냐 총매출이냐에 따라 수억 단위로 차이가 납니다. 처음 겪는 문제가 아니었습니다. DW를 클라우드로 옮기는 프로젝트에서도 봤고, 차세대 정보계를 여러 벤더와 1년 넘게 만들 때도 똑같았습니다. 벤더마다 “매출”, “원가"의 기준이 달라서 데이터 정합성 잡느라 몇 주씩 지연됐습니다. 용어 하나 안 맞으면 전체 일정이 밀립니다. DW/BI 프로젝트를 하면서 이 문제가 안 나온 적이 없습니다. ...