개요
Genie Space의 응답 품질은 데이터 구성과 메타데이터의 풍부함에 직접적으로 비례 합니다. 이 가이드에서는 테이블 관리, 메타데이터 커스터마이징, 프롬프트 매칭, Knowledge Store의 구조를 상세히 설명합니다.왜 데이터 구성이 가장 중요한가
Genie가 SQL을 생성하는 과정을 이해하면 데이터 구성의 중요성이 명확해집니다. 사용자가 “지난 달 매출 상위 5개 지역은?”이라고 질문하면, Genie는 내부적으로 다음 단계를 거칩니다:- 테이블 선택: Knowledge Store에서 “매출”과 “지역”이 포함된 테이블을 찾음
- 컬럼 매핑: “매출” →
revenue컬럼, “지역” →region컬럼으로 매핑 - 비즈니스 로직 적용: SQL Expression에 정의된 “매출” 계산식 참조
- SQL 생성: 위 정보를 조합하여
SELECT region, SUM(revenue) ... GROUP BY region ORDER BY ... LIMIT 5생성
revenue를 연결하지 못하며, SQL Expression이 없으면”순매출”인지 “총매출”인지 판단할 수 없습니다.
주의 핵심 원칙: Genie의 정확도 문제 중 80% 이상은 LLM의 한계가 아니라 Knowledge Store의 부족 에서 비롯됩니다. 인스트럭션을 아무리 잘 써도, 테이블 메타데이터가 빈약하면 정확도가 올라가지 않습니다.
지식 저장소(Knowledge Store)란?
지식 저장소는 Genie가 정확한 응답을 생성하기 위해 참조하는 모든 메타데이터와 비즈니스 로직의 총체 입니다. 아래 요소들이 Knowledge Store를 구성합니다:| 구성 요소 | 위치 | 설명 | 제한 |
|---|---|---|---|
| 테이블/뷰 | Configure > Data | Genie가 쿼리할 데이터 소스 | 최대 30개 |
| 컬럼 설명 | Configure > Data > 테이블 선택 | 각 컬럼의 비즈니스 의미 | 테이블당 무제한 |
| 동의어(Synonyms) | Configure > Data > 컬럼 선택 | 컬럼의 별칭 | 컬럼당 무제한 |
| 텍스트 인스트럭션 | Configure > Instructions | 자연어 비즈니스 규칙 | 최대 200개 |
| 예제 쿼리 | Configure > Instructions | 질문-SQL 쌍 | 최대 200개 |
| SQL Expressions | Configure > Data > Expressions | Measure, Filter, Dimension | 최대 200개 |
| 조인 관계 | Configure > Data > Joins | 테이블 간 연결 관계 | 무제한 |
| 프롬프트 매칭 | Configure > Data > 컬럼 선택 | 입력값-데이터값 자동 매핑 | 컬럼당 1개 설정 |
참고 Genie는 사용자 질문을 받으면 이 Knowledge Store를 종합적으로 참조하여 최적의 SQL을 생성합니다. Knowledge Store가 풍부할수록 응답 정확도가 높아집니다. 모든 구성 요소가 LLM 프롬프트의 일부로 사용된다 는 점을 기억하세요. 컬럼 설명에 “이 컬럼은 별로 중요하지 않다”고 쓰면 Genie가 그것을 그대로 참조합니다.
Knowledge Store 구성 우선순위
처음부터 모든 요소를 완벽하게 채울 필요는 없습니다. 정확도 향상에 대한 기여도 순서로 접근하세요:| 우선순위 | 구성 요소 | 정확도 기여도 | 이유 |
|---|---|---|---|
| 1순위 | 컬럼 설명 + 동의어 | 매우 높음 | Genie가 올바른 컬럼을 선택하는 데 핵심 |
| 2순위 | SQL Expression (Measure) | 높음 | 비즈니스 지표의 정확한 계산식 보장 |
| 3순위 | 예제 SQL 쿼리 | 높음 | 복잡한 질문에 대한 “정답 패턴” 제공 |
| 4순위 | 프롬프트 매칭 | 중간 | 한국어-영어 데이터 값 매핑 |
| 5순위 | 조인 관계 | 중간 | 다중 테이블 사용 시 필수 |
| 6순위 | 텍스트 인스트럭션 | 보조적 | 글로벌 컨텍스트 제공 |
테이블 추가/제거
테이블 추가 절차
- Configure > Data 메뉴로 이동합니다.
- Add 버튼을 클릭합니다.
- Unity Catalog 브라우저에서 Catalog > Schema > Table을 탐색합니다.
- 화면 설명: 3단계 트리 구조의 카탈로그 브라우저가 나타나며, 검색 기능도 제공됩니다.
- 추가할 테이블/뷰를 선택하고 Add 를 클릭합니다.
- Overview 탭에서 컬럼 정보를 확인합니다.
- Sample data 탭에서 실제 데이터를 미리 확인합니다.
테이블 제거 절차
- Configure > Data 에서 제거할 테이블을 찾습니다.
- 테이블 우측의 휴지통 아이콘 을 클릭합니다.
- 확인 다이얼로그에서 Remove 를 클릭합니다.
주의 테이블을 제거하면 해당 테이블에 설정한 컬럼 설명, 동의어, 프롬프트 매칭, SQL Expression이 모두 삭제 됩니다. 임시로 비활성화하려면 제거 대신 컬럼을 숨기는 것을 고려하세요.
테이블 선택 가이드
| 권장 사항 | 비권장 사항 | 이유 |
|---|---|---|
| 5개 이하로 시작 | 10개 이상 한꺼번에 추가 | 테이블이 많으면 잘못된 테이블 선택 확률 증가 |
| 뷰(View) 활용 | 원본 테이블 직접 사용 | 뷰로 필요한 컬럼만 노출하면 정확도 향상 |
| 비정규화된 넓은 테이블 | 과도하게 정규화된 테이블 | 조인 수가 적을수록 Genie 정확도 향상 |
| 명확한 컬럼명의 테이블 | 약어/코드로 된 컬럼명 | 의미가 명확할수록 정확한 SQL 생성 |
컬럼 숨기기(Hide Columns)
불필요한 컬럼을 숨기면 Genie가 혼란을 줄이고 더 정확한 SQL을 생성합니다.왜 컬럼 숨기기가 중요한가
Genie의 LLM은 모든 노출된 컬럼을 “사용 가능한 후보”로 간주합니다. 테이블에 50개 컬럼이 있고 그 중 10개만 비즈니스 질문에 관련이 있다면, Genie는 나머지 40개 중에서 잘못된 컬럼을 선택할 확률이 높아집니다. 신호 대 잡음 비율(Signal-to-Noise Ratio) 을 높이는 것이 핵심입니다.숨겨야 할 컬럼 유형
| 컬럼 유형 | 예시 | 숨기는 이유 |
|---|---|---|
| 내부 시스템 ID | _id, _etl_timestamp, _row_hash | 비즈니스 의미가 없음 |
| 기술적 메타데이터 | created_by, modified_at, partition_key | 사용자 질문과 무관 |
| 더 이상 사용하지 않는 컬럼 | old_status, legacy_code | 혼란 유발 |
| 민감 정보 | ssn, credit_card, password_hash | 보안 (단, UC 권한이 우선) |
| 중복 컬럼 | full_name과 first_name + last_name | 어떤 컬럼을 사용할지 혼동 |
숨기기 절차
- Configure > Data 에서 테이블을 선택합니다.
- 숨길 컬럼의 Visibility 토글을 끕니다.
- 화면 설명: 각 컬럼 행 우측에 눈 모양 아이콘이 있으며, 클릭하면 회색으로 변하면서 숨겨집니다.
- 숨긴 컬럼은 Genie가 SQL 생성 시 참조하지 않습니다.
팁 테이블의 컬럼이 20개 이상이면, 사용자 질문에 관련된 핵심 컬럼 10-15개만 남기고 나머지는 숨기세요. 이것만으로도 정확도가 크게 향상됩니다.
메타데이터 커스터마이징
컬럼 설명 (Description) — Genie 정확도의 핵심
Space 전용 테이블/컬럼 설명을 추가할 수 있습니다. Unity Catalog의 원본 설명을 덮어쓰지 않고, Space에만 적용되는 별도의 설명을 관리합니다.왜 컬럼 설명이 가장 중요한가
Genie는 사용자 질문의 키워드를 컬럼과 매칭할 때, 컬럼명 과 컬럼 설명 을 LLM 프롬프트의 일부로 사용합니다. 컬럼명이ord_sts이고 설명이 없다면, Genie는 이것이 “주문 상태”인지 “주문 통계”인지 알 수 없습니다. 반면 설명에 “주문 상태. 가능한 값: ‘pending’, ‘shipped’, ‘delivered’, ‘cancelled‘“라고 적으면, Genie는 다음을 할 수 있습니다:
- “배송 완료된 주문” →
WHERE ord_sts = 'delivered'정확 매핑 - “취소된 주문 제외” →
WHERE ord_sts != 'cancelled'정확 매핑 - “주문 상태별 분포” →
GROUP BY ord_sts정확 선택
주의 흔한 실수: AI 자동 생성 설명을 검증 없이 사용하지 마세요. AI가 “This column stores the order status”라고 생성한 설명은 Genie에게 실질적인 도움이 되지 않습니다. 가능한 값, 단위, 비즈니스 정의 가 포함되어야 합니다.좋은 컬럼 설명 작성 원칙:
| 원칙 | 좋은 예시 | 나쁜 예시 |
|---|---|---|
| 가능한 값 나열 | "주문 상태. 가능한 값: 'pending', 'shipped', 'delivered', 'cancelled'" | "주문 상태" |
| 비즈니스 의미 설명 | "순매출. 총매출에서 할인과 반품을 제외한 금액 (단위: 원)" | "매출" |
| 계산 방법 명시 | "고객 등급. 연간 구매액 기준 — Gold: 1000만원 이상, Silver: 500만원 이상, Bronze: 그 외" | "등급" |
| 데이터 형식 명시 | "주문일. YYYY-MM-DD 형식. 한국 시간(KST) 기준" | "날짜" |
동의어(Synonyms) — 사용자 언어와 데이터의 다리
컬럼에 동의어를 추가하면 사용자가 다양한 표현으로 질문해도 올바른 컬럼을 찾습니다.왜 동의어가 필요한가
한국 기업 환경에서는 같은 개념을 다양한 방식으로 부릅니다. 영업팀은 “매출”이라고 하고, 재무팀은 “수익”이라고 하며, 경영진은 “세일즈”라고 합니다. 데이터베이스 컬럼명은revenue입니다. 동의어를 등록하지 않으면 “수익”이나 “세일즈”로 질문했을 때 올바른 컬럼을 찾지 못합니다.
| 컬럼명 | 추가할 동의어 |
|---|---|
revenue | 매출, 수익, 매출액, sales, 세일즈 |
customer_count | 고객수, 고객 수, 회원수, 사용자수 |
order_date | 주문일, 주문 날짜, 구매일, 거래일 |
region | 지역, 권역, 리전, area, 영업구역 |
product_category | 제품군, 상품 카테고리, 카테고리, 품목 |
팁 동의어 수집 팁: 실제 비즈니스 사용자 5명에게 같은 데이터를 어떻게 부르는지 물어보세요. 놀랍게도 같은 팀 내에서도 서로 다른 용어를 사용합니다. 이 다양한 표현을 모두 동의어로 등록하는 것이 정확도 향상의 지름길입니다.설정 방법:
- Configure > Data에서 테이블을 선택합니다.
- 컬럼을 클릭하여 상세 패널을 엽니다.
- Synonyms 필드에 쉼표로 구분하여 입력합니다.
프롬프트 매칭(Prompt Matching) 상세
프롬프트 매칭은 사용자의 입력 언어를 실제 데이터 값과 자동으로 매칭하는 기능입니다.왜 필요한가?
| 사용자 입력 | 실제 데이터 값 | 프롬프트 매칭 없이 | 프롬프트 매칭 있으면 |
|---|---|---|---|
| ”서울" | "Seoul” | 매칭 실패 → 결과 없음 | ”서울” → “Seoul” 자동 변환 |
| ”삼성전자" | "Samsung Electronics” | 매칭 실패 | 자동 매칭 |
| ”2분기" | "Q2” | 매칭 실패 | 자동 매칭 |
설정 방법
- Configure > Data 에서 테이블을 선택합니다.
- 프롬프트 매칭이 필요한 컬럼을 클릭합니다.
- Prompt Matching 섹션에서 Enable 을 클릭합니다.
- 화면 설명: 프롬프트 매칭을 활성화하면 해당 컬럼의 고유 값 목록이 로드되며, Genie가 사용자 입력과 데이터 값을 자동 매핑합니다.
자동 값 매핑 vs 수동 매핑
| 방식 | 설명 | 사용 사례 |
|---|---|---|
| 자동 매핑 | 컬럼의 고유 값을 Genie가 자동으로 인덱싱 | 값이 명확한 컬럼 (국가, 제품명 등) |
| 수동 정규식 패턴 | 사용자가 정규식으로 매칭 규칙 정의 | 약어, 다국어, 복합 패턴 |
정규식 패턴 예시
| 패턴 | 설명 | 매칭 결과 |
|---|---|---|
서울|Seoul|SEL | 서울의 다양한 표현 매칭 | → “Seoul” |
Q[1-4]|[1-4]분기 | 분기 표현 매칭 | → “Q1”, “Q2” 등 |
삼성.*|Samsung.* | 삼성 관련 회사 매칭 | → “Samsung Electronics” |
주의 프롬프트 매칭은 카디널리티(고유 값 수)가 낮은 컬럼 에 적합합니다. 고유 값이 수만 개 이상인 컬럼(예: 주문번호)에는 사용하지 마세요. 인덱싱 시간이 길어지고 효과도 미미합니다.
조인 관계 정의
테이블 간 연결 관계를 명시적으로 정의합니다. Genie는 이 정보를 참고하여 정확한 JOIN 쿼리를 생성합니다.왜 조인 관계를 명시적으로 정의해야 하는가
Genie는 조인 관계가 정의되지 않으면 컬럼명의 유사성 을 기반으로 추론합니다.orders.customer_id와 customers.id처럼 명확한 경우에는 잘 작동하지만, 다음과 같은 경우 잘못된 조인을 생성할 수 있습니다:
- 여러 테이블에
id라는 이름의 컬럼이 있을 때 - 조인 키가
account_id와acct_id처럼 약간 다를 때 - 복합 키(2개 이상 컬럼)로 조인해야 할 때
- 조건부 조인(날짜 범위 등)이 필요할 때
설정 방법
간단한 경우— 컬럼 동등 구문 사용:
팁
조인 관계를 정의하지 않으면 Genie가 컬럼명을 기반으로 추론 합니다. 대부분 정확하지만, 컬럼명이 모호한 경우(예: 여러 테이블에 id 컬럼이 있는 경우) 명시적 정의가 필요합니다.
SQL 표현식 (SQL Expressions)
비즈니스 로직을 재사용 가능한 Measure, Filter, Dimension 으로 정의합니다. 텍스트 인스트럭션보다 SQL로 명확하게 정의하는 것이 더 정확한 결과를 얻을 수 있습니다.왜 SQL Expression이 텍스트 인스트럭션보다 우선인가
텍스트 인스트럭션에 “순매출은 총매출에서 할인과 반품을 빼세요”라고 쓰면, LLM이 이를 해석하여 SQL을 만들어야 합니다. 해석 과정에서SUM(amount) - SUM(discount) - SUM(refund)가 될 수도 있고, SUM(amount - discount - refund)가 될 수도 있습니다. 결과가 다릅니다.
SQL Expression으로 SUM(amount) - SUM(discount) - SUM(refund) AS net_revenue라고 정의하면, Genie는 해석할 필요 없이 그대로 SQL에 삽입 합니다. 따라서:
- 정확도: 비즈니스 로직이 100% 보장됨
- 일관성: 누가 어떻게 질문해도 같은 계산식 적용
- 검증 가능: SQL이 명시적이므로 검증이 쉬움
| 유형 | 용도 | 예시 |
|---|---|---|
| Measure | 지표/메트릭 정의 | SUM(order_total) AS total_revenue |
| Filter | 자주 사용하는 필터 | status = 'active' AND created_at > '2025-01-01' |
| Dimension | 분석 차원 정의 | CASE WHEN age < 30 THEN 'Young' ELSE 'Senior' END AS age_group |
SQL Expression 작성 예시
| 비즈니스 요구사항 | 유형 | SQL Expression |
|---|---|---|
| ”순매출” 지표 | Measure | SUM(amount) - SUM(discount) - SUM(refund) AS net_revenue |
| ”활성 고객” 필터 | Filter | last_purchase_date >= DATE_ADD(CURRENT_DATE(), -90) |
| ”매출 구간” 차원 | Dimension | CASE WHEN revenue < 1000000 THEN 'Small' WHEN revenue < 10000000 THEN 'Medium' ELSE 'Large' END AS revenue_tier |
| ”전년 동기 대비” 지표 | Measure | SUM(CASE WHEN YEAR(order_date) = YEAR(CURRENT_DATE()) THEN amount ELSE 0 END) - SUM(CASE WHEN YEAR(order_date) = YEAR(CURRENT_DATE()) - 1 THEN amount ELSE 0 END) AS yoy_diff |
참고 SQL 표현식은 최대 200개 까지 추가할 수 있습니다. 텍스트 인스트럭션으로 “순매출은 총매출에서 할인과 반품을 빼세요”라고 쓰는 것보다, SQL Expression으로 정확한 공식을 정의하는 것이 훨씬 안정적입니다.
실전 시나리오: 전자상거래 Space 구축 예시
한 전자상거래 기업이 Genie Space를 구축하는 과정을 예시로 설명합니다. 1단계 — 테이블 구성:orders, customers, products 3개 테이블을 추가하고, 필요 없는 _etl_timestamp, _partition_key 같은 기술 컬럼을 숨김 처리합니다.
2단계 — 컬럼 설명: 주요 컬럼에 비즈니스 설명을 추가합니다.
orders.status→ “주문 상태. 가능한 값: ‘pending’(결제 대기), ‘paid’(결제 완료), ‘shipped’(배송중), ‘delivered’(배송 완료), ‘cancelled’(취소), ‘refunded’(환불)”orders.amount→ “주문 금액 (부가세 포함, 단위: 원). 할인 적용 전 금액”customers.tier→ “고객 등급. Gold: 연간 구매 1,000만원 이상, Silver: 500만원 이상, Bronze: 그 외”
revenue → 매출, 수익, 세일즈 / customer_count → 고객수, 회원수
4단계 — SQL Expression:
- Measure:
SUM(amount) - SUM(discount) - SUM(refund_amount) AS 순매출 - Filter:
status NOT IN ('cancelled', 'refunded')(유효 주문) - Dimension:
CASE WHEN amount >= 100000 THEN '고가' WHEN amount >= 50000 THEN '중가' ELSE '저가' END AS 주문_구간
region 컬럼에 “서울” → “Seoul”, “부산” → “Busan” 매핑 활성화
이 5단계를 완료하면 벤치마크 정확도가 보통 50% → 80% 이상으로 향상됩니다.
Metric View 활용
Metric View는 지표(Metric), 차원(Dimension), 집계(Aggregation)를 Unity Catalog 수준에서 정의 하는 기능입니다. SQL Expression이 Space 내부에서만 적용되는 반면, Metric View는 카탈로그에 등록되므로 여러 Space에서 재사용할 수 있습니다.| 비교 항목 | SQL Expression | Metric View |
|---|---|---|
| 범위 | 해당 Space에만 적용 | Unity Catalog 전체에서 재사용 |
| 관리 | Space 관리자가 관리 | 데이터 엔지니어/분석가가 관리 |
| 일관성 | Space마다 다르게 정의 가능 | 조직 전체에서 동일한 정의 보장 |
| 적합한 경우 | Space 특화 로직 | 조직 표준 KPI (매출, 고객수 등) |
팁 조직의 핵심 KPI(매출, 이익, 고객수 등) 는 Metric View로 정의하고, Space별 특수한 지표만 SQL Expression으로 추가하는 것이 이상적입니다. 이렇게 하면 “A Space에서는 매출이 이렇게 계산되고, B Space에서는 다르게 계산된다”는 불일치를 방지할 수 있습니다.
흔한 데이터 구성 실수와 디버깅
| 증상 | 원인 | 디버깅 방법 |
|---|---|---|
| ”매출”을 질문하면 엉뚱한 컬럼을 선택 | 여러 테이블에 비슷한 이름의 컬럼 존재 | 불필요한 테이블/컬럼 제거, 동의어로 정확한 컬럼 지정 |
| 조인 결과가 뻥튀기(데이터 중복) | 1:N 관계에서 잘못된 조인 키 | 명시적 조인 관계 정의, 뷰로 사전 조인 |
| ”서울 매출”을 질문하면 결과 없음 | 데이터에는 “Seoul”로 저장 | 프롬프트 매칭 활성화 |
| 필터 조건이 누락되어 삭제 데이터 포함 | Genie가 is_deleted 조건을 모름 | Filter 타입 SQL Expression 추가 |
| 날짜 필터가 잘못 적용 | ”지난 달”의 SQL 해석이 부정확 | 인스트럭션에서 날짜 표현의 SQL 함수 정의 |
데이터 구성 베스트 프랙티스
| 항목 | 권장 사항 |
|---|---|
| 테이블 수 | 5개 이하로 시작, 필요 시 점진적 확장 |
| 컬럼 설명 | 가능한 값, 단위, 계산 방법 포함. 모든 주요 컬럼에 작성 |
| 동의어 | 한국어/영어 모두 등록. 부서별로 다른 용어도 포함 |
| 숨김 컬럼 | 비즈니스 의미 없는 컬럼은 모두 숨김. 20개+ 컬럼이면 핵심만 남기기 |
| 프롬프트 매칭 | 카디널리티가 낮은 카테고리 컬럼에 적용 |
| 조인 관계 | 모호한 경우 반드시 명시적 정의 |
| SQL Expression | 핵심 비즈니스 지표는 Measure로 정의 |
| 뷰 활용 | 복잡한 조인/변환은 뷰로 사전 처리 |
| Metric View | 조직 표준 KPI는 Metric View로 카탈로그 수준에서 정의 |