테이블 수십 개짜리 DB를, AI가 조인 없이 읽는 요약표 몇 장으로 묶습니다
Text-to-SQL이 실패하는 이유는 대부분 모델이 아니라 스키마입니다 — 길고, 얽혀 있고, 조인을 매번 스스로 추론해야 합니다. tablefold는 연결된 관계를 따라 테이블을 넓은 논리 모델로 접어 두고(접기), AI가 쓴 간단한 SQL을 실제 실행 가능한 SQL로 되돌려 줍니다(펼치기). 아래는 이 화면에 연결된 데이터베이스를 실제로 접은 결과입니다.
무엇이 달라졌나
AI에게 이 데이터베이스를 설명할 때 들어가는 내용입니다.
어떻게 묶였나
모델 하나는 넓은 표 한 장입니다. 표 하나에 필요한 내용이 이미 다 붙어 있어, AI가 표를 이어 붙이는 작업을 하지 않아도 됩니다. 카드를 누르면 안에 든 항목을 볼 수 있습니다.
0개 테이블은 어느 모델에도 묶이지 않았습니다
묶어 봐야 이득보다 설명 비용이 큰 테이블들입니다. 사라진 게 아니라, 그 테이블이 필요한 질문이 들어올 때만 따로 꺼내 씁니다.
왜 이렇게 묶였나
가운데가 기준이 되는 표이고, 주위 표들이 그 한 줄에 붙습니다. 실선은 그대로 붙은 것, 점선 Σ는 여러 줄을 미리 합계 낸 것입니다.
묶음의 네 가지 기준
어떤 테이블을 묶을지, 어디를 중심으로 할지는 아래 규칙으로 정해집니다.
- 관계(연결)가 있을 때만 묶습니다. 정의서에 외래 키가 없어도 기본 키 이름이 같은 컬럼을 찾아 후보로 삼고, 실제 데이터에서 엉뚱한 값의 비율이 1% 이하일 때만 연결로 인정합니다.
- "한 줄"의 기준(앵커)을 정합니다. 참조만 하는 표(매출·주문)는 거래 한 건이 한 줄, 참조당하는 표(조직·품목)는 항목 하나가 한 줄입니다. Text-to-SQL 에서는 둘 다 앵커로 두고 겹치는 것만 뺍니다.
- 여러 줄짜리 자식은 반드시 미리 합계 낸 뒤 붙입니다. 매출 두 건을 조직에 직접 붙이면 조직 행이 두 배가 되어 합계가 부풀어 오릅니다. N:1(한 줄씩 대응)은 그대로 붙입니다.
-
자식의 원본 값은 조건과 묶음 기준으로 씁니다.
WHERE로 걸면 합계 전에 조건이 적용되고,GROUP BY로 묶으면 그 값의 입도(예: 월별)로 다시 잘게 쪼개집니다.
작은 예시로 보기 — 매출·계획·조직 3개 테이블
D_ORG — 조직 (1줄 = 조직 1개)
| ORG_CD | ORG_NM |
|---|---|
| 100 | 서울본점 |
| 200 | 부산지점 |
F_SALES — 매출 (1줄 = 매출 1건)
| ORG_CD | YYYYMMDD | AMT |
|---|---|---|
| 100 | 2026-01-05 | 600 |
| 100 | 2026-01-20 | 400 |
| 200 | 2026-02-05 | 500 |
F_PLAN — 계획 (1줄 = 조직 × 월)
| ORG_CD | YYYYMM | PLAN_AMT |
|---|---|---|
| 100 | 202601 | 1200 |
| 200 | 202602 | 800 |
외래 키 선언이 없어도 F_SALES.ORG_CD → D_ORG 연결이 되살려집니다.
D_ORG 를 중심으로 접으면 매출과 계획이 미리 합쳐져 한 줄에 나란히 놓입니다:
-- AI가 쓰는 SQL (조인 없음) SELECT ORG_NM, SUM(f_sales_AMT_sum), SUM(f_plan_PLAN_AMT_sum) FROM D_ORG WHERE f_sales_YYYYMMDD LIKE '202601%' -- 조건: 합계 안으로 들어간다 GROUP BY ORG_NM -- 월별 추이: 묶음 기준으로 쓰면 월 입도로 재집계된다 SELECT SUBSTR(f_sales_YYYYMMDD, 1, 6) AS YM, SUM(f_sales_AMT_sum) FROM D_ORG GROUP BY SUBSTR(f_sales_YYYYMMDD, 1, 6)
기준 표 그대로 붙은 표 · 실선 미리 합계 낸 표 · 점선 Σ ◆ 연결 키
실제로 돌려보기
왼쪽은 AI가 넓은 표만 보고 쓴 간단한 SQL입니다. 오른쪽은 그걸 실제 데이터베이스가 이해하는 SQL로 바꾼 결과입니다. 사람이 조인을 직접 쓰지 않아도 됩니다.
AI가 쓴 SQL
조인 없음실제로 실행되는 SQL
바꿔보기를 누르면 여기에 결과가 나옵니다.
설정과 자세한 분석
개발자용
스키마 가져올 곳
연결된 데이터베이스의 카탈로그를 직접 읽습니다.
설정
바꾼 뒤 다시 묶기를 누르면 위 결과가 갱신됩니다.
위 세 값(최소 이득 · 테이블당 한도 · 목표 커버리지)은 지금 앵커 방식에서는 아무 일도 하지 않습니다. 어떤 표를 앵커로 삼을지가 구조에서 이미 정해져 있어, 고를 여지가 없기 때문입니다.
프롬프트 예산 ↔ 답할 수 있는 질문
설정을 하나 추천하는 대신 곡선을 봅니다. 더 줘도 답이 늘지 않는 지점(포화)이 있고, 그 위는 낭비입니다.
| 예산(자) | 실제 | 모델 | 항목 | 답변 | 주제 |
|---|
AI에게 전달되는 전체 텍스트
이 글이 그대로 프롬프트에 들어갑니다.
아직 결과가 없습니다.
되찾은 테이블 연결
외래 키가 선언돼 있지 않아도, 기본 키와 실제 데이터로 관계를 되살립니다.
| 어느 테이블의 | 어느 컬럼이 | 어디를 가리키는지 | 확신도 |
|---|---|---|---|
| 아직 결과가 없습니다. | |||
테이블별 분석
어떤 테이블이 모델의 중심이 될 만한지 점수로 나타낸 값입니다. 숫자가 클수록 사건 기록에 가깝고(매출·주문), 작을수록 이름표에 가깝습니다(조직·품목).
| 테이블 | 상태 | 중심 점수 | 컬럼 | 참조됨 | 참조함 |
|---|---|---|---|---|---|
| 아직 결과가 없습니다. | |||||