SQL 쿼리 히스토리로 시맨틱 레이어 만들기: AI 분석 전에 검증할 4가지

AI에게 데이터베이스 스키마와 테이블 설명만 주고 “지난달 활성 고객 수를 알려줘”라고 하면, 그럴듯하지만 팀의 정의와 다른 답이 나올 수 있다. 나는 이 문제를 볼 때 모델의 SQL 생성 능력보다 먼저 우리 조직이 실제로 어떤 계산을 반복해 왔는가를 찾는다. 7월 21일 Hacker News에 소개된 Momenta Analytics의 Neuron은 SQL query history에서 조직의 지식을 추출해 시맨틱 레이어로 만든다는 접근을 내놨다. 이 아이디어는 현실적이다. 스키마에는 컬럼 이름이 있지만, CASE 조건·제외 규칙·시간대·조인 방식처럼 지표의 뜻을 바꾸는 판단은 대개 저장된 쿼리에 남는다. 다만 쿼리 로그는 정답 사전이 아니다. 오래된 실험, 잘못된 조인, 개인식별정보가 섞인 로그까지 함께 들어 있다. AI 분석을 믿을 만하게 만들려면 로그를 곧바로 컨텍스트에 넣는 대신, 후보 추출→사람 검토→시맨틱 정의→테스트라는 변환 경로를 둬야 한다.

쿼리 히스토리는 스키마가 잃어버린 맥락을 담고 있다

테이블의 orders.amount만 봐서는 매출인지, 취소 전 주문금액인지, 환불을 뺀 인식매출인지 알 수 없다. 반면 분석가가 반복해서 작성한 SQL에는 다음 정보가 남는다.

• 어떤 날짜 컬럼을 기준으로 월을 묶었는가.
• 취소·테스트 계정·내부 주문을 어떤 조건으로 제외했는가.
• 고객 수를 COUNT(*), COUNT(DISTINCT customer_id), 활성 상태 조건 중 무엇으로 정의했는가.
• 주문과 결제를 어떤 키와 조인 조건으로 연결했는가.

Momenta는 자사 제품 설명에서 스키마가 보이는 20%라면 SELECT, CASE, window function, 파생 계산이 남은 80%를 이룬다고 주장한다. 이 비율은 일반화할 수 있는 독립 통계가 아니라 제품사의 문제 정의로 읽어야 한다. 그래도 핵심 관찰은 유효하다. 팀이 자주 재사용한 계산에는 비즈니스 용어의 실제 사용법이 축적된다. 이것이 AI 분석용 컨텍스트를 새로 장황하게 작성하는 비용을 줄일 단서가 된다.

후보를 뽑는 일과 정의를 승인하는 일을 분리하라

여기서 흔한 실수는 LLM이 가장 자주 본 쿼리를 곧 ‘공식 정의’로 승격하는 것이다. 쿼리 횟수는 재사용 신호일 뿐 정확성의 증거가 아니다. 대시보드용 임시 쿼리, 마이그레이션 전 문법, 특정 캠페인에만 맞춘 필터가 가장 많이 등장할 수도 있다.

실무에서는 아래처럼 후보와 승인 단계를 분리하는 편이 안전하다.

# Snowflake/BigQuery 등에서 별도로 내보낸 query_history.csv를 대상으로
# 동일 지표 후보에 쓰인 표현을 우선 찾는다. 원본 쿼리에는 민감값이 남을 수 있으므로
# 접근 권한이 있는 보안 작업공간에서만 실행한다.
grep -inE 'count\(distinct[[:space:]]+customer_id\)|sum\(.*amount' query_history.csv | head -50

이 명령은 공식 지표를 만드는 도구가 아니라, 검토 대상을 좁히는 첫 단계다. 그 뒤 데이터 소유자가 최소 네 가지를 확인해야 한다. 첫째, 같은 이름의 지표가 서로 다른 필터를 쓰는가. 둘째, 날짜 기준이 이벤트 발생 시점인지 적재 시점인지. 셋째, 조인 때문에 행 수가 불어나지 않는가. 넷째, 정의를 현재 데이터 모델과 권한 정책에서도 실행할 수 있는가. 이 네 가지가 빠지면 “과거에 자주 썼다”는 기록이 미래의 자동화 오류가 된다.

시맨틱 레이어는 AI 프롬프트 모음이 아니라 실행 가능한 계약이다

dbt의 MetricFlow 문서는 semantic model, metrics, saved queries와 그 검증 체계를 별도 구성 요소로 둔다. 이 구조가 중요한 이유는 지표를 자연어 설명으로만 보관하지 않고, 모델·측정값·차원·시간 축·조인 관계와 함께 관리하려 하기 때문이다. AI 도구에는 이 승인된 정의를 읽기 전용 컨텍스트로 제공하고, 실제 질의도 가능한 한 시맨틱 레이어 또는 검증된 쿼리 템플릿을 통과시키는 편이 낫다.

예를 들어 monthly_active_customers를 만들 때 “최근 한 달 고객 수” 같은 문장만 남기지 않는다. 기준 이벤트, 시간대, 활성 조건, 중복 제거 키, 데이터 소유자, 마지막 검토일을 함께 보관한다. 그러면 AI가 답을 만들 때도 어떤 정의를 사용했는지 설명할 수 있고, 정의가 바뀌면 영향을 받는 대시보드와 자동화를 추적할 수 있다.

AI 분석에 넣기 전 반드시 남겨야 할 감사 흔적

쿼리 히스토리를 AI 준비 데이터로 바꾸는 작업은 데이터 카탈로그 정리와 보안 검토를 동시에 요구한다. 로그에는 사용자 식별자, 이메일, 지역 조건, 내부 프로젝트명, 심지어 쿼리 주석 안의 비밀값이 남을 수 있다. 따라서 원본 로그를 범용 모델 프롬프트에 전달하면 지표를 정리하는 과정이 새 유출 경로가 된다.

최소한 다음 항목을 산출물에 붙인다.

1. 출처: 후보를 만든 쿼리 ID와 실행 기간. 원문이 아니라 접근 가능한 참조를 남긴다.
2. 소유자: 정의를 승인하고 변경을 판단할 담당자.
3. 정규화 규칙: 민감 리터럴·계정 식별자·주석을 제거한 방식.
4. 검증 결과: 대표 기간에서 기존 대시보드 수치와 비교한 결과 및 허용 오차.
5. 변경 이력: 언제 어떤 필터·조인·시간대가 바뀌었는지.

이 기록이 있으면 AI가 “활성 고객”을 답했을 때 사용자도 정의·버전·검증 상태를 되짚을 수 있다. 반대로 기록이 없으면 자연어로는 친절한 답을 받더라도 숫자의 근거를 복구하기 어렵다.

내 의견: 쿼리 로그는 학습 데이터가 아니라 반대 증거까지 포함한 후보 저장소다

내 의견은 명확하다. SQL 쿼리 히스토리는 시맨틱 레이어 구축을 빠르게 시작할 좋은 재료지만, 자동으로 사실이 되는 지식 베이스는 아니다. 특히 AI 시대에는 자주 쓰인 잘못된 지표가 더 빠르게 복제될 위험이 있다. 가벼운 반론도 있다. 작은 팀이 소유자·테스트·변경 이력까지 관리하면 분석 속도가 늦어진다는 주장이다. 맞다. 하지만 지표 몇 개부터 소유자와 정의를 고정하는 비용은, 서로 다른 대시보드와 AI 답변이 같은 매출을 다르게 말한 뒤 정합성을 맞추는 비용보다 작다. 빠른 자동화의 출발점은 많은 쿼리를 모델에 넣는 일이 아니라, 신뢰할 정의와 불확실한 후보를 구분하는 일이다.

김덕환 운영자 관점

김덕환 운영자 관점에서는 에이전트가 콘텐츠·운영·분석을 연결할수록 숫자 자체보다 숫자의 정의를 재사용 가능한 자산으로 만드는 일이 중요하다. 먼저 반복되는 핵심 지표 5개만 골라 쿼리 히스토리에서 후보를 모으고, 소유자·필터·시간대를 승인한 뒤 AI에는 그 계약만 제공하는 흐름이 현실적이다. 그래야 에이전트가 빠르게 답해도 운영자가 그 답을 설명하고 수정할 수 있다.

참고 자료

• Show HN: Neuron — Turn a SQL query history into a semantic layer (2026-07-21 확인)
• Momenta Analytics — The Context Layer for AI-Ready Analytics
• dbt Docs — About MetricFlow