RAG 벡터DB 없이 완성하는 AI 자연어에서 SQL까지, 데이터와 대화하다

Databricks Genie(AI/BI Genie)로 Text-to-SQL을 “제품 기능”으로 끝내는 방법

왜 직접 구현(Text-to-SQL 파이프라인)이 힘들어지나

보통 DIY Text-to-SQL은 이런 구성으로 갑니다.

• 스키마 수집(테이블/컬럼/PK-FK/뷰/코멘트)
• 전처리(명칭 정규화, 용어 사전, PII 라벨링)
• 임베딩 + 벡터DB(RAG)
• 질문→관련 스키마/쿼리 후보 검색
• 프롬프트(“이 스키마를 참고해 SQL 만들어라”)
• LLM 생성 SQL 검증(실행/에러 수정/재시도)
• 권한/마스킹/행·열 보안 적용
• 성능/비용/품질 모니터링

여기서 “성능이 안 나오는” 대표 원인은

• 스키마 컨텍스트가 항상 불완전: 컬럼 의미/조인 규칙/비즈니스 정의가 빠짐
• 조인 추론이 어렵고 실수가 잦음
• 스키마 변경/신규 테이블 추가 시 운영비 폭증
• LLM 토큰 비용 + 재시도 비용이 누적
• 보안(권한/PII/감사로그) 내재화가 결국 가장 어렵습니다

Databricks Genie가 정확히 뭐냐

Microsoft Learn 기준으로 Genie는 자연어 질문을 SQL로 변환하고 결과(가능하면 시각화까지)로 답해주는 Azure Databricks 기능입니다. 특히 “주석(설명)이 달린 테이블/열 정보에서 관련 이름·설명을 선택해 자연어를 SQL로 바꾼다”고 명시돼 있어요.

300x250

핵심 포인트는 이겁니다.

• 분야 전문가(분석가)가 Genie Space를 큐레이션: 데이터셋 + 샘플 쿼리 + 텍스트 지침으로 “회사 용어/업무 정의”를 주입
• Genie는 공간에 넣은 데이터 자산 기반으로 workspace의 관련 ‘인기 쿼리’를 자동 제안하기도 합니다. (승인/거절 가능)
• 비즈니스 사용자는 채팅하듯 묻고, SQL/결과/차트를 얻습니다.

Genie Space(지니 공간) 구조를 “설계 관점”으로 이해하기

Genie가 잘 되는 공간은 결국 “지식 저장소(knowledge store)”를 잘 구성한 공간입니다.
Microsoft Learn의 API 예시에서 serialized_space 안에 무엇이 들어가는지가 굉장히 힌트가 됩니다.

공간 구성에 들어가는 대표 요소(실무적으로 중요)

• 데이터 소스: tables/views 목록(공간에 추가된 것만 사용)
• 샘플 질문(sample_questions)
• 텍스트 지침(text_instructions): 전역 규칙(반올림, 기간 기준 등)
• 예제 SQL(example_question_sqls): 복잡 질문은 “정답 SQL”을 예제로 주입
• 조인 규칙(join_specs): 조인 기준을 명시적으로 학습
• 표현식/측정치(measures)/필터(sql_snippets): 회사 표준 지표(매출, 활성고객 등) 정의

이게 왜 좋냐면, DIY에서 가장 힘든 “비즈니스 의미(semantic)”를 공간에 넣어 “제품 기능”으로 운영하게 만들어 주기 때문입니다.

기술 요구사항 / 한계(운영에 바로 영향)

Microsoft Learn에 명시된 Genie Space 요구사항/제한은 아래가 핵심입니다.

1. Unity Catalog 필수

• Genie Space 데이터는 Unity Catalog에 등록돼 있어야 함
• 공간당 최대 30개 테이블/뷰 추가 가능

2. SQL Warehouse 필요

• Pro 또는 Serverless SQL warehouse가 필요
• 공간 생성/구성 시 작성자는 해당 warehouse에 CAN USE 권한이 있어야 함
• 중요: “작성자의 compute credential이 공간에 embedded되어” 모든 사용자 쿼리 처리에 사용됨

3. 처리량/용량 제한

• UI 접근: 워크스페이스 전체 기준 분당 20개 질문 처리(모든 공간 합산)
• Genie API 무료 티어(공개 미리보기): 워크스페이스 전체 기준 best effort 분당 5개 질문
• 공간당 최대 10,000 conversations, 대화당 10,000 messages

4. 권한 요구(만들기/편집)

• Databricks SQL entitlement
• Warehouse CAN USE
• 데이터 SELECT 권한
• Space ACL (CAN EDIT 이상)

“무료”의 정확한 의미

사용자 체감은 “LLM 토큰 과금이 없다/덜하다”에 가깝습니다.
하지만 문서 기준으로 Genie는 SQL Warehouse를 통해 실제 쿼리를 실행합니다.

즉,

• 질문 자체를 토큰 단위로 외부 LLM API에 직접 과금시키는 DIY 형태와는 다름
• 대신 Databricks/Azure Databricks 사용 비용(특히 SQL warehouse compute)은 발생할 수 있음(환경/플랜에 따라)

특히 “공간의 compute credential이 embed”되는 구조이므로, 비용/권한/남용 방지를 운영정책으로 잡아야 합니다.

성능을 끌어올리는 실전 설계(베스트 프랙티스 핵심)

Microsoft Learn의 권장사항 중 실무에서 바로 먹히는 포인트만 압축하면

1. 지침은 “적고 명확하게”

• 지침이 많아지면 장문 대화에서 우선순위가 흐려져 품질 저하 가능

2. 복잡한 질문은 “예제 SQL”이 답

• Genie는 검증된 SQL 예시로 학습/매칭하며 정확도를 끌어올림

3. 표준 지표는 SQL expressions로 정의

• revenue, active_customers 같은 자주 쓰는 개념은 재사용 가능한 정의로 박아두기

4. Prompt matching(값/철자 보정) 적극 활용

• 사용자의 표현을 실제 컬럼/값에 매칭해 정확도를 높이는 기능을 제공

5. 테이블은 “작게, 목적별로”

• 공간당 30개 제한도 있고, 많아질수록 혼란이 커집니다.
  👉 부서/업무 단위로 여러 공간으로 쪼개는 게 보통 더 잘 됩니다.

Genie 도입 시 반드시 잡아야 할 가이드

권한/접근통제(가장 중요)

• Unity Catalog에서 최소권한(Least Privilege)으로 SELECT 부여
• Space ACL(CAN USE/CAN EDIT/CAN MANAGE) 정책을 명확히 분리
• Embedded compute credential 구조 이해
  • 공간 작성자의 warehouse 권한이 공간에 embed됨
  • 따라서 작성자는 “쿼리 실행 통로”를 제공하는 셈 → 작성자 계정/권한 통제가 중요

데이터 노출/프롬프트 인젝션 대비

• Genie에 넣는 지침/예제 SQL에 민감정보(토큰, 내부 URL, 개인식별정보, 운영자 계정정보) 절대 금지
• 사용자가 “권한 없는 데이터”를 물으면 빈 응답이 나오는 동작이 문서에 있습니다. (오탐 방지 포인트)
• 민감 컬럼은 마스킹/뷰 계층/행/열 보안 정책으로 통제(Genie 이전 계층에서 강제)

감사/추적(감사 대응)

• “누가 어떤 질문을 했고 어떤 결과가 나갔는지”는 보안감사에서 핵심 쟁점이 됩니다.
• Genie는 대화/공간 데이터를 API로도 가져올 수 있고(관리/분석 목적), 대화 메시지 조회/목록 조회 엔드포인트도 제공합니다.
  👉 내부적으로는 SIEM 연계(감사로그 수집)까지 염두에 두시는 게 좋습니다.

비용/남용 방지

• 워크스페이스 전체 처리량 제한(UI 분당 20, API 분당 5 best effort)을 고려해 Rate limit / 사용자 가이드 필요
• 질문 템플릿/샘플 질문을 제공해 “큰 테이블 풀스캔 유도 질문”을 줄이기
• Warehouse 비용은 운영정책(업무시간/쿼터/모니터링)으로 통제

Genie API로 “사내 챗봇/에이전트”에 붙이는 방법(구체 예시)

Microsoft Learn에 Genie API 통합 방법이 꽤 구체적으로 나옵니다.

인증 방식

• 브라우저 기반 사용자: OAuth(U2M)
• 서버/백엔드: 서비스 주체(OAuth M2M) 권장

기본 호출 흐름(최소 구현)

1. (선택) 공간 생성

POST /api/2.0/genie/spaces
Authorization: Bearer <token>
...

2. 대화 시작(첫 질문)

POST /api/2.0/genie/spaces/{space_id}/start-conversation
Authorization: <token>
{
  "content": "<your question>"
}

3. 생성된 SQL/상태 조회(폴링)

• conversation_id, message_id로 조회

4. 쿼리 결과 가져오기

GET /api/2.0/genie/spaces/{space_id}/conversations/{conversation_id}/messages/{message_id}/query-result/{attachment_id}
Authorization: Bearer <token>

추가 운영 팁

• 1~5초 폴링, 보통 10분 내 타임아웃 권장
• API 결과는 최대 5,000행 제한

“이렇게 도입하면 실패 확률이 낮습니다” (추천 운영 모델)

1. 파일럿(1개 부서, 1개 업무)

• 테이블 5~10개 수준으로 시작
• “자주 묻는 질문 Top 20” + “정답 SQL 예제”를 먼저 넣기

2. 지식 저장소 강화

• 표준 지표(measure)/표현식/조인 규칙을 점진적으로 확장
• 지침은 짧고 강하게 유지

3. 보안/권한 표준화

• UC 권한 템플릿, 공간 ACL 템플릿, 작성자(embedded credential) 정책 확정

4. 운영/감사 체계

• 질문/사용량/비용/오답 패턴 모니터링
• API 기반 수집 또는 감사로그 연계(가능하면 SIEM)

Databricks Genie는 “Text-to-SQL 구현”이 아니라, ‘잘 큐레이션된 Genie Space를 운영’하는 문제로 바꿔줍니다.
그래서 성공의 관건은 데이터/용어/정답 SQL/권한/비용을 공간 운영 체계로 잡는 것입니다.