DataNexus

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

DataNexus를 개발하면서 Claude Code와 Codex를 함께 사용하고 있습니다. Claude Code가 라우터 로직을 수정하는 동안 별도 터미널에서는 Codex로 빠진 테스트를 보완합니다. 처음에는 두 에이전트가 같은 작업 디렉토리를 사용했습니다. 같은 파일을 동시에 수정하면서 충돌이 생겼고, 한 에이전트가 의존성 버전을 바꾸면 다른 터미널에서 진행 중이던 빌드가 실패했습니다. 충돌할 때마다 git stash로 변경 사항을 임시 보관했지만 두 에이전트를 동시에 실행할 수는 없었습니다. 하나의 작업이 끝난 뒤 다음 에이전트를 실행했습니다. git worktree로 에이전트 작업 공간 분리 일반적인 브랜치 전환은 작업 디렉토리 하나에서 체크아웃할 브랜치만 바꿉니다. git worktree를 쓰면 같은 저장소의 브랜치마다 별도 디렉토리를 둘 수 있습니다. git clone을 여러 번 할 필요도 없습니다. 각 worktree는 커밋 기록과 Git 메타데이터를 공유하고, 작업 파일만 별도 디렉토리에 둡니다. 어느 worktree에서 커밋하든 기록은 같은 저장소에 쌓입니다. ...

지난 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문항에서는 정확도 80%를 기록했지만 BIRD 공개 벤치마크 50문항에서는 56%였습니다. 9번의 실험 끝에 ‘후보 여러 개 만들어서 고르기’ 가설을 세 방향에서 모두 폐기했습니다. 남은 과제는 스키마 이해와 방법론이었습니다.

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

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

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

RAG는 매번 처음부터 답을 찾습니다. Karpathy는 LLM이 위키를 직접 유지보수하며 지식이 쌓이는 구조를 제안했습니다. DataNexus의 온톨로지 카탈로그가 방치되지 않으려면 같은 원리가 필요합니다.

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

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 프로젝트를 하면서 이 문제가 안 나온 적이 없습니다. ...