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번의 실험 끝에 ‘후보 여러 개 만들어서 고르기’ 가설을 세 방향에서 모두 폐기했습니다. 남은 과제는 스키마 이해와 방법론이었습니다.

코드보다 모델링이 먼저라는 게시글의 참고자료 7개를 읽고 남은 것을 정리한 글입니다. 도구가 세 번 바뀌어도 살아남은 원칙, 실무에서 쓰이는 이력 관리 구현 네 가지, 가장 늦게 드러나는 조직 부채를 다룹니다.

수퍼-서브 타입은 논리 모델에서 비즈니스 분류를 명확하게 만듭니다. 물리 모델로 넘어갈 때 세 가지 선택지가 생기며, DW에서는 그 선택이 차원 설계 전체를 바꿉니다.

같은 까마귀발인데 왜 해석이 다를까요. 점선 하나도 툴마다 다른 뜻을 가집니다. 프로젝트에서 모델을 공통 언어로 쓰려면 사용하는 도구의 표기법부터 맞춰야 합니다.

ERD가 같아 보여도 설계 철학은 완전히 다릅니다. OLTP는 트랜잭션 정합성을, DW는 분석 접근 경로를 우선합니다. 그 차이가 Unknown 레코드와 시점 데이터 같은 낯선 설계를 만듭니다.

Synapse, BigQuery, Redshift로 오면서 DW 모델링 관점이 어떻게 달라졌는지 정리합니다. Kimball, Data Vault, One Big Table의 실무 판단 기준도 함께 다룹니다.

차원 데이터가 바뀌면 과거를 덮어쓸지 이력을 남길지 선택해야 합니다. SCD Type 1, 2, 3의 차이를 SQL로 직접 구현하고, dbt snapshot으로 프로덕션 패턴을 만듭니다.

Bronze에 쌓아둔 원본 데이터를 정제하고 표준화합니다. 타입을 맞추고 컬럼명을 통일하며 중복을 제거합니다. dbt로 이 과정을 SQL 모델로 정의합니다.

Bronze에 데이터를 넣는 방법은 두 가지입니다. 전체를 덮어쓰거나 바뀐 것만 가져오는 방식입니다. 어떤 방식을 고르느냐에 따라 파이프라인 복잡도가 완전히 달라집니다.

Bronze, Silver, Gold. 데이터를 레이어별로 나눠 적재하면 무엇이 달라지는지 DuckDB와 dbt로 직접 구성해 봅니다.

GEO가 소비자 AI를 위한 최적화라면 AEO는 코딩 에이전트를 위한 최적화입니다. 문서 길이 제약, llms.txt, skill.md, AGENTS.md까지 필요한 파일을 정리합니다.

On-Site GEO를 완벽하게 적용해도 AI 인용의 절반은 외부 채널에서 결정됩니다. 플랫폼별 Off-Site 전략과 robots.txt 진단법을 다룹니다.

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

ChatGPT는 Wikipedia를, Perplexity는 Reddit을, Gemini는 공식 사이트를 선호합니다. 하나의 전략으로 모든 AI 플랫폼에 대응하기는 어렵습니다.

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

AI가 코드 대부분을 작성하는 상황을 가정하고, 개발자에게 남는 설계·검증·운영 책임과 제품 담당자의 역할 변화를 짚습니다.

Qwen3.5 기반의 오픈소스 경량 의사결정 모델 Kev를 소개합니다. 폐쇄형 API 서비스인 Jev의 구조를 재현하여 로컬 환경에서 무료로 다중 질문을 단 한 번의 연산으로 처리합니다.

새로운 직장이나 승진 후 자신을 증명하려다 고립과 번아웃에 빠지는 시니어 엔지니어의 악순환을 살펴보고 작은 작업과 신뢰로 회복하는 방법을 정리했습니다.

기업 문서에서 표와 그래픽 요소를 정밀하게 추출하고 파싱하여 RAG 및 LLM 파이프라인의 검색 정확도를 극대화하는 실행 전략을 다룹니다.

대기업의 화려한 이력과 자본을 갖춘 팀이 초기 스타트업에서 실패하는 원인을 짚어보고, 성공적인 안착을 위해 빠르게 교정해야 할 3가지 업무 습관과 고객 소통 방식을 다룹니다.

모호한 프롬프트 대신 AI 코딩 에이전트의 판단 과정을 23개의 작고 독립적인 스킬로 분해하여 운용하는 프로젝트 구조를 소개합니다.

macOS 내장 명령어 caffeinate와 메뉴바 앱 Amphetamine의 옵션, 작동 방식, 클램쉘 모드 제약 우회 방법을 비교 정리했습니다.

dbt Labs가 단일 YAML 파일로 데이터 조회, 차트 시각화, 레이아웃 배치를 정의하는 오픈소스 대시보드 언어 dbt Charts를 공개했습니다. AI 에이전트의 코드 파편화를 줄이고 Git CI에서 데이터 모델과 차트 검증을 함께 처리합니다.

Claude Code, Cursor, Codex, Antigravity의 사용량 제한과 작업 상태를 화면 가장자리 위젯으로 보여주는 Codenotch를 소개합니다.

반복 입력, 누적 컨텍스트, 호출 수를 분리해 측정하고 온톨로지 검색과 Solution Cache로 AI 에이전트의 운영 비용을 줄이는 방법을 정리했습니다.