11. 틀릴 수 있는 AI 답변, 화면에서는 어떻게 보여야 할까

지난 10편까지는 SQL 생성 과정에서 주로 발생하는 오답 유형을 분석했습니다.

BIRD와 Spider 벤치마크를 활용하고 다양한 모델을 테스트하면서 오답을 COLUMN_BINDING, VALUE_BINDING, DERIVED_METRIC 등의 유형으로 세분화했습니다. SQL 오답을 계속 들여다보면서, 확인하고 싶은 것이 달라졌습니다.

“그렇다면 생성된 SQL과 답변의 근거는 화면에서 어떻게 시각화되어야 하는가?”

그동안 정확도 중심의 테스트에 집중하느라 실제 사용자가 화면에서 무엇을 확인해야 하는지는 놓치고 있었습니다. 비즈니스 환경에서 쓰는 데이터 분석 AI라면 수치가 어디서 왔는지 명확히 보여야 합니다. 근거를 확인할 방법이 없다면 결과가 정답처럼 보이더라도 사용자는 결국 SQL을 다시 실행하여 검증할 수밖에 없습니다.

DataNexus에서는 단순히 답변 문장을 매끄럽게 작성하는 것을 넘어, 수치와 문장 옆에 SQL 쿼리, 출처, 권한 범위, 검증 상태, Fallback 여부를 함께 배치하기로 했습니다. 그래야 사용자가 회의 자료나 실무 의사결정에서 그 데이터를 믿고 쓸 수 있기 때문입니다.

주요 제품별 답변 근거 제시 방식 벤치마킹

2026년 5월 기준 공개된 국내외 주요 제품의 문서와 데모 화면을 분석해 보았습니다.

해외 제품:

• Databricks Genie
• Snowflake Cortex Analyst
• Strategy(MSTR) AUTO
• ThoughtSpot Spotter 3
• Vanna.ai

국내 제품:

• Qurify(SmartMind)
• MISO(GS Neotek & 52g)

분석의 기준은 “사용자가 이 답변을 업무에 활용하기 위해 어떤 정보를 확인해야 하는가"였습니다. 제품별로 표현 방식은 달랐으나, 답변 문장만 단독으로 제공하는 제품은 존재하지 않았습니다.

• Databricks Genie 는 Trusted assets 기능으로 검증된 SQL 쿼리나 함수가 쓰인 답변에 ‘Trusted’ 라벨을 붙입니다. 사용자는 Genie Space에서 자연어로 질의하고 Data 및 Instructions 탭에서 테이블, 컬럼, 가이드라인, SQL 쿼리 등의 컨텍스트를 확인합니다. Unity Catalog 권한도 적용되어 사용자가 볼 수 있는 데이터만 답변 생성에 씁니다.

• Snowflake Cortex Analyst 는 REST API 응답 구조에서 화면 설계의 직접적인 단서를 줍니다. API 응답의 content 유형은 text, suggestion, sql로 나뉘고 SQL content에는 verified_query_used 같은 필드가 들어 있어 추론 경로를 따라갈 수 있습니다. warnings와 response_metadata.question_category도 함께 반환하므로, SQL 생성이 어려운 모호한 질문에는 대안 질문(suggestion)을 제시할 수 있습니다.

• Strategy(MSTR) AUTO 는 Auto Dashboards 및 Strategy AI 관련 문서와 데모에서 derived metric, selector, auto narratives, auto answers 등의 기능이 확장되고 있음을 확인했습니다. 특히 데모의 Interpretation 영역에서 사용자의 질문을 어떤 Metric과 Dimension으로 해석했는지 풀어 설명하는 방식은 DataNexus Trace UI 설계에도 필요한 요소였습니다.

• ThoughtSpot Spotter 3 는 본 글의 주제인 ‘화면 내 답변 근거 제시’에 가장 잘 맞는 구조를 취하고 있습니다. Spotter 3 는 구조화된 데이터 웨어하우스(DW)뿐만 아니라 Slack, Salesforce, Jira, SharePoint 등 업무 도구에 분산된 정보까지 다룹니다. 흩어진 정보를 답변 맥락으로 묶고 사용자가 결과를 점검한 뒤 후속 분석으로 넘어가게 하는 흐름이 DataNexus 설계에 특히 도움이 됐습니다.

• Vanna.ai 는 학습 루프와 권한 처리 흐름을 중심에 둡니다. Vanna 2.0 문서 에 따르면 LLM에 SQL 실행 및 차트 생성 도구를 연결하고 Tool Memory로 성공한 ‘질문-SQL-결과’ 쌍을 다시 쓸 수 있는 형태로 저장합니다. 사용자 권한도 전체 파이프라인에 적용합니다. 진행 상태, SQL 코드, 데이터 표, 차트, 자연어 요약은 한 흐름 안에서 확인합니다.

국내 제품의 경우 공개된 소개 자료와 릴리스 노트를 기준으로 파악했습니다.

• Qurify 는 자연어로 데이터베이스와 소통하는 Text-to-SQL 제품입니다. 0.4.4 버전 기준으로 생성된 SQL을 화면에 보여주고 사용자가 직접 편집·실행·복사할 수 있게 합니다. 실행 결과를 인용해 후속 질문을 이어가는 방식도 DataNexus 설계에서 참고했습니다.

• MISO 는 하나의 NL2SQL 제품이라기보다 엔터프라이즈 AI 플랫폼과 워크플로우 앱 빌더의 성격이 강합니다. 공개된 정기 보고서 자동화 및 문서 검색 사례를 벤치마킹하여 DataNexus의 운영형 AI 화면을 구체화하는 데 반영했습니다.

앞선 벤치마킹 사례를 바탕으로 DataNexus 화면의 방향을 잡았습니다. 답변 문장을 다듬기 전에 사용자가 SQL, 출처, 검증 상태, 권한 범위, Fallback 여부를 먼저 확인할 수 있는 파이프라인이 필요했습니다.

이 과정에서 시맨틱 레이어(Semantic Layer)의 개념도 다시 봤습니다. 일반적인 시맨틱 레이어가 업무 용어와 지표 정의를 SQL에 매핑하는 중간 계층이라면, DataNexus의 Glossary, Ontology, Knowledge Graph는 컬럼·테이블 수준의 메타데이터를 넘어 비즈니스 규칙과 개념 사이의 관계까지 포함합니다. 이 관계 정보를 시스템 내부에서만 쓰면 사용자는 다시 문서를 찾아야 합니다. 답변 카드 안에서 바로 열어 볼 수 있는 인터페이스가 필요했습니다.

출처 확인을 위한 지식 그래프

DataNexus가 말하는 ‘답변의 근거’는 답변에 쓰인 개념에서 시작해 출처, 관련 테이블·컬럼까지 이어지는 연결망(Lineage)을 말합니다. 처음에는 지식 그래프를 별도 분석 화면으로 만들고 노드와 엣지를 따라가는 시각화도 생각했습니다. 하지만 실제 비즈니스 환경에서는 시각적 효과보다 ‘특정 요소를 클릭했을 때 어떤 정보를 확인할 수 있는가’가 더 중요합니다.

지식 그래프를 화면에 넣는다면 사용자가 아래 질문에 바로 답할 수 있어야 합니다.

• 이 답변은 어떤 비즈니스 개념을 기반으로 도출되었는가?
• 해당 개념은 어떤 물리 데이터(테이블/컬럼)와 연결되어 있는가?
• 이 관계의 정의 주체와 문서적 근거는 어디에 있는가?
• 지표 정의가 변경될 경우 어떤 답변들이 영향을 받는가?

전통적인 키워드 검색은 문서 안에 “순매출"이라는 단어가 있는지는 찾을 수 있지만 “순매출이 총매출, 반품, 할인, 에누리와 어떤 연산 관계로 묶여 있는가"까지 추론하기는 어렵습니다. 비즈니스 질의에서는 단어 매칭보다 개념 사이의 맥락 연결이 중요합니다. DataNexus는 이 연결을 화면에 담기 위해 온톨로지와 지식 그래프를 씁니다.

이 글에서 보는 온톨로지는 거창한 개념이 아니라 전사 표준 용어와 관계를 정리한 기준표 역할을 합니다.

• Concept: 고객 / 제품 / 주문 / 순매출
• Relationship: 고객이 주문을 생성한다 / 순매출은 총매출을 기반으로 계산됩니다
• Property: 주문일시, 결제수단, 주문상태
• Rule: 환불은 결제 완료 이후 상태에서만 발생합니다
• Metric: 평균 주문 금액, 전년 동기 대비 성장률

지식 그래프는 이 기준표를 실제 물리 데이터와 맵핑합니다. 개념은 노드가 되고 관계는 엣지가 되어 문서, 테이블, 컬럼, 계산식을 하나의 연결망으로 묶습니다.

이는 RDBMS를 대체하려는 목적이 아닙니다. 트랜잭션 처리는 RDBMS가 맡고 지식 그래프는 그 데이터가 업무상 어떤 의미를 지니는지 설명합니다. DataNexus에서는 SQL로 계산한 값과 지식 그래프로 설명한 의미를 화면에서 나란히 제공하는 쪽을 가장 중요하게 봤습니다.

지식 그래프 안에서 제공되는 상세 출처

지식 그래프 인터페이스에서 개념 노드만 시각화해서는 부족합니다. 개념을 뒷받침하는 출처와 메타 정보도 함께 보여야 합니다.

사용자가 노드나 엣지를 클릭하면 그 관계의 도출 근거가 즉시 팝업되어야 합니다. 예를 들어 “순매출” 노드를 누르면 인접 노드뿐 아니라 데이터 카탈로그의 Glossary 항목, 원본 문서 문장, 맵핑된 DB 컬럼까지 단계별로 펼쳐져야 합니다. 그래야 사용자가 답변이 맞는지 끝까지 확인할 수 있습니다.

“순매출의 정의가 무엇인가?“라는 질문에 시스템이 짧게 이렇게 답하면 사용자는 다시 묻게 됩니다.

순매출은 총매출에서 반품, 할인, 에누리를 차감한 금액입니다.

이 설명이 정확하더라도 실무자는 다음 검증 단계를 요구합니다.

• 이 비즈니스 로직의 출처는 어디인가?
• 현재 전사 표준 기준이 맞는가?
• 물리적으로 어떤 컬럼들을 연산한 결과인가?

그래서 답변 카드에는 최소한 아래 같은 메타데이터가 함께 있어야 합니다.

 - source: Data Catalog Glossary
 - term: 순매출
 - source_id: urn:li:glossaryTerm:net_sales
 - related concepts: 총매출 / 반품 / 할인 / 에누리
 - linked columns: orders.amount, orders.refund_amount, orders.discount_amount
 - validation: PASS

사용자는 이 정보를 단서 삼아 지식 그래프 안에서 근거를 따라가며 직접 확인합니다.

아래 계보를 직접 눌러 각 노드의 근거를 확인해 보세요.

수치 중심 답변의 한계

글로벌 제품을 벤치마킹하면서 데이터 분석 결과 화면에는 신뢰성의 근거가 함께 나와야 한다는 판단이 더 분명해졌습니다.

사용자가 이렇게 물었다고 해보겠습니다.

2024년 총 주문 건수는?

시스템이 수치만 답하면,

2024년 총 주문 건수는 12,486건입니다.

겉으로는 답변이 끝난 것처럼 보이지만 실무자는 바로 이런 질문을 던집니다.

• 어떤 마트 테이블을 조회했는가?
• 기간 조건(2024년)의 물리적 기준 타임스탬프는 무엇인가?
• 취소 및 반품 주문 건수도 집계에 포함되었는가?
• 운영 환경 데이터인가, 스테이징 환경 데이터인가?

“12,486건"이라는 수치 하나만으로는 결과를 그대로 믿기 어렵습니다. 공식 보고서에 바로 인용하기도 부담스럽습니다. DataNexus에서는 자연어 답변 하단에 SQL 쿼리, 실행 프로세스(Trace), 검증 상태, 접근 권한 범위를 함께 두어 사용자가 판단할 기준을 제공합니다.

화면에서 SQL 제공 여부

NL2SQL UI를 기획할 때 일반 현업 사용자의 가독성을 위해 SQL을 완전히 숨기려는 경향이 있습니다. 화면 복잡도가 증가하고 AI의 자율성이 가려진다는 우려 때문입니다. 하지만 엔터프라이즈 환경에서는 투명성이 중요해서 SQL을 완전히 숨길 수는 없습니다.

DataNexus는 SQL을 내부 로그에만 남기지 않고 답변 안에서 접고 펼 수 있는 블록으로 구현했습니다.

• 1차 자연어 답변 레이어:

2024년 총 주문 건수는 12,486건입니다.

• 2차 확장형 SQL 레이어 (접기/펼치기 지원):

SELECT COUNT(*) AS order_count
FROM orders
WHERE order_date >= DATE '2024-01-01'
  AND order_date < DATE '2025-01-01';

기본적으로 쿼리는 접어둡니다. 수치 검증이 필요한 순간에는 분석가나 DBA가 즉시 쿼리를 열어 같은 환경에서 재실행하고 오류 범위를 좁힐 수 있습니다.

SQL 조작이 낯선 사용자를 위해 질문이 시스템 내부에서 어떻게 해석되었는지 보여주는 ‘값 매핑(Interpretation) 요약’ 영역을 우선 배치합니다. 이 영역은 매핑 오류(VALUE_BINDING)를 확인하는 데 도움이 됩니다.

사용자는 SQL 전체를 읽지 않아도 의도가 맞게 반영됐는지 먼저 확인합니다. 잘못된 부분이 있으면 화면에서 조건을 바로 고쳐 재실행할 수 있습니다.

쿼리를 실행하기 전에 생길 수 있는 위험을 줄이려고 드라이런(Dry-run) 기반의 SQL Inspect 정보도 함께 보여줍니다.

SQL Inspect

 - EXPLAIN 요약: Index Scan
 - 예상 행 수: 124,503
 - 풀스캔 경고: 없음
 - 예상 비용: 낮음
 - 정책 검사: 통과

Runtime Trace와 처리 과정 시각화

Trace는 사용자의 질문이 시스템 내부의 어떤 파이프라인을 거쳐 처리되었는지 보여주는 실행 기록입니다. DataNexus의 답변 프로세스는 모델 호출 한 번으로 끝나지 않습니다. 온톨로지 검증, 카탈로그 매핑, 질문 유형 분류를 거쳐 알맞은 경로로 보냅니다.

시스템은 질문의 성격에 따라 처리 과정을 나눕니다.

• “순매출의 정의가 무엇인가?” → SQL을 실행하지 않고 카탈로그 용어집을 즉시 조회합니다.
• “2024년 총 주문 건수는?” → 데이터 웨어하우스(DW)에 SELECT 문을 수행합니다.

상세 Trace 레이어에는 감사와 디버깅을 위해 아래 같은 로그를 남깁니다.

• 데이터베이스 조회 경로 Trace 예시:

 - Runtime Trace
 - trace_id: dnq_20260523_001
 - route: NL2SQL
 - source: DW/DM
 - source_id: mart.orders
 - semantic_context: Data Catalog Glossary + Ontology
 - verified_query: none
 - sql_execution: success
 - validation:
   - schema_compliance: pass
   - policy_check: pass
   - source_binding: pass
 - permission_scope:
   - user: sales_analyst
   - rls_policy: sales_region_allowed
   - masked_columns: []
 - fallback: false
 - warnings: []

• 데이터 카탈로그 조회 경로 Trace 예시:

 - Runtime Trace
 - trace_id: dnq_20260523_002
 - route: Glossary
 - source: Data Catalog Glossary
 - source_id: urn:li:glossaryTerm:net_sales
 - sql_execution: not_applicable
 - validation:
   - source_binding: pass
   - policy_check: pass
 - permission_scope:
   - glossary_visibility: internal
 - fallback: false
 - warnings: []

여기서 sql_execution: not_applicable은 에러가 아니라 쿼리를 실행할 필요가 없는 메타 정보 조회 경로였다는 뜻입니다. 이 경우 validation.source_binding 항목으로 데이터의 무결성을 검증합니다. 일반 사용자 화면에는 복잡한 로그 대신 Source: DW/DM, Validation: PASS, Fallback: False 형태의 요약 지표만 보여줍니다.

실행 경로별 Route 분리

운영 안정성을 높이기 위해 런타임 실행 경로(route)를 더 잘게 나눠 정의했습니다. 시스템 검증을 통과한 ‘PASS’ 상태라도 사전 검증된 고정 쿼리를 재사용했는지, 모델이 실시간으로 생성한 Raw SQL을 실행했는지에 따라 신뢰도 수준이 다르기 때문입니다.

이 정도로 내부 경로를 기록하고 화면에 남겨두어야 사용자가 AI 답변의 처리 과정을 따라갈 수 있습니다. 시스템이 불확실하거나 예외 경로로 우회했을 때도 사용자가 그 상태를 보고 대응할 수 있습니다.

답변 전 모호성 해소

답변 결과에 근거를 제시하는 것도 필요하지만 질문 단계의 모호성을 먼저 줄여야 합니다. 현업 질문은 대개 추상적입니다. 그래서 바로 쿼리를 만들기 전에 온톨로지로 해석 후보를 먼저 보여주고 의도를 좁힙니다.

[질문] 2024년 순매출 알려줘

DataNexus가 질의 조건을 확인합니다.

 ○ 순매출_v1: 총매출 - 반품 - 할인 - 에누리
 ○ 순매출_KR: 국내 회계 기준, 세금 처리 포함
 ○ 순매출_global: IFRS 기준

[이 기준으로 실행] [직접 선택]

사용자가 선택한 세부 로직 기준은 세션과 대화 컨텍스트 안에서 계속 유지됩니다. 시스템은 내부적으로 아래 상태 구조를 씁니다.

{
  "carry_forward": {
    "accepted_metric": "urn:li:glossaryTerm:net_sales",
    "accepted_period": "2024",
    "accepted_filters": ["region = KR"],
    "rejected_interpretations": ["gross_sales_only"],
    "scope": "current_thread_only"
  }
}

scope: current_thread_only 설정으로 사용자가 대화를 이어가는 동안 컨텍스트(지표 기준, 필터 조건 등)를 고정합니다. 사용자는 흐름이 끊기지 않은 상태로 후속 질문을 이어갈 수 있습니다. 화면은 컨텍스트가 유지되거나 새로 갱신되는 상태를 표시해 사용자가 헷갈리지 않게 합니다.

답변 근거로서의 권한 범위

데이터의 출처가 정확하더라도 사용자의 보안 권한을 넘어선 정보가 답변에 들어가면 안 됩니다. 같은 자연어 질문이라도 소속 부서나 직급에 따라 볼 수 있는 데이터 범위가 달라집니다. Trace 내부에는 권한 스코프(permission_scope) 정보를 함께 매핑합니다.

permission_scope:
  - user: sales_analyst
  - allowed_domains: [Sales]
  - row_level_filter: region IN ('KR-Seoul', 'KR-Gyeonggi')
  - masked_columns: [customer_phone, customer_email]

행 단위 권한 필터(RLS)와 마스킹 정책이 어떻게 적용됐는지는 일반 UI에 자세히 보여주지 않습니다. 대신 데이터 보안 감사관이 나중에 Inspect 레이어에서 확인할 수 있도록 백엔드에 기록합니다.

Fallback 상태 투명화

시스템 에러나 데이터 단절 상태가 정상 답변처럼 숨는 상황은 위험합니다. 예를 들어 데이터베이스 커넥션이 실패했는데도 캐시된 과거 수치가 경고 없이 나오면 잘못된 의사결정으로 이어질 수 있습니다.

DataNexus는 데이터베이스 통신 장애나 쿼리 실패가 발생하면 이를 감추지 않고 Fallback이 작동했다는 것을 화면에 표시합니다.

 - Runtime Trace
 - source: fallback demo response
 - sql_execution: failed
 - validation: FALLBACK
 - fallback: true
 - warnings:
   - DB connection failed. Demo response was used.

운영 환경에서는 이를 FALLBACK · demo_response와 FALLBACK · sql_execution_failed로 나눕니다. 사용자는 현재 상태가 단순 데모 모드인지, 실제 인프라 장애인지 구분해야 합니다. 권한 차단이나 데이터 부재로 답변할 수 없는 경우는 단순 Fallback이 아니라 ABSTAIN(답변 보류) 상태로 분리했습니다.

출처 표시와 업무 활용성

비즈니스 질의에서 가장 중요한 기준점은 데이터 카탈로그입니다. “순매출"과 같은 핵심 KPI는 회사의 비즈니스 도메인과 회계 기준에 따라 포함하거나 빼는 항목이 달라집니다.

일반적인 DDL(데이터 정의어) 스키마는 amount, discount_amount 같은 기술적 컬럼 구조만 정의합니다. 비즈니스 컨텍스트까지 담지는 못합니다. 실제 비즈니스 규칙과 결합된 용어 정의는 공식 데이터 카탈로그에서 실시간으로 가져와야 합니다.

 - source: Data Catalog Glossary
 - term: 순매출
 - source_id: urn:li:glossaryTerm:net_sales
 - owner: Sales Data Domain

데이터 도메인 소유자(owner)와 용어집 ID를 함께 표시하면 사용자는 추측 대신 전사 표준을 기준으로 결과를 확인할 수 있습니다.

답변 안에서의 다중 탭 구조

지식 그래프나 계보(Lineage)가 좋은 검증 수단이라 해도 사용자가 매번 복잡한 네트워크 맵부터 볼 필요는 없습니다. 대다수 사용자는 요약 수치를 먼저 확인한 뒤 세부 근거를 역추적하는 흐름을 선호합니다.

DataNexus는 답변 카드 하나 안에서 요약, SQL, 카탈로그, 그래프 뷰를 탭으로 전환하도록 레이아웃을 묶었습니다.

• [기본 화면] 요약 뷰

2024년 총 주문 건수는 12,486건입니다.

• [전환 탭 1] SQL 뷰

SELECT COUNT(*) AS order_count
FROM orders
WHERE order_date >= DATE '2024-01-01'
  AND order_date < DATE '2025-01-01';

• [전환 탭 2] 그래프 뷰

주문(Order)
 ├─ has property: 주문일자(order_date)
 ├─ has property: 주문상태(order_status)
 └─ counted as: 주문 건수(Order Count)

• [전환 탭 3] 카탈로그 뷰

 - Glossary Term: 주문 건수
 - Definition: 기준 기간 내 생성된 주문 레코드 수
 - Owner: Sales Data Domain

모든 정보가 한번에 보여지지 않도록 평소에는 슬림하게 요약 정보만 보여줍니다. 수치 검증이나 도메인 규칙 확인이 필요할 때 사용자가 하위 레이어를 차례로 열어 보는 방식입니다.

대화형 편집의 승인 워크플로우

사용자가 대화창에서 지식 베이스 수정을 요청하는 경우(예: “해당 노드 유형을 전략 고객으로 변경해줘”), 시스템은 수정 내용을 바로 반영하지 않고 검토용 초안으로 따로 저장합니다.

엔터프라이즈 환경에서는 AI와의 대화 결과를 지식 베이스에 바로 반영하면 위험합니다. 메타데이터가 한 번 바뀌면 하위 SQL 생성 파이프라인과 대시보드 리포트까지 줄줄이 영향을 받기 때문입니다.

DataNexus는 대화형 편집 요청에는 스테이징 및 승인 절차를 둡니다.

사용자 수정 요청
  → 변경 후보(Draft) 생성
  → 영향 범위 분석
  → 데이터 오너 검토 및 정책 체크
  → 최종 승인 후 Glossary / Ontology 마스터에 반영
  → 관련 지식 그래프 인덱스 재동기화

승인 절차와 변경 이력을 남기면 지식 베이스에 잘못된 수정이 섞이는 일을 줄이고 데이터 자산의 무결성을 유지할 수 있습니다.

정확도와 런타임 검증의 분리

사전 검증 단계에서는 주로 모델이 생성한 SQL과 정답 SQL의 일치 여부를 판단하는 EX(Execution Accuracy) 지표를 측정합니다. 하지만 실시간 운영 환경(Runtime)에는 미리 정해진 ‘정답(Gold Answer)‘이 없어서 사전 검증 지표를 그대로 쓸 수 없습니다.

운영계의 PASS 라벨은 단순히 SQL 문법 오류가 없다는 뜻의 EX 통과가 아닙니다. 정책과 출처 검증 파이프라인을 통과했는지 보는 런타임 검증 기준을 따릅니다.

 PASS
   - SQL 실행 엔진 오류가 없고 데이터 카탈로그 매핑이 끝남
   - 스키마 정책 검사 통과
   - 데이터 보안 정책과 행 단위 권한(RLS) 필터 통과
   - 공식 용어집(Glossary) 또는 검증 쿼리 자산과 맞음
   - 중요한 경고(Warning) 없음

 REVIEW
   - SQL은 실행됐지만 Binding 신뢰도가 낮음
   - 승인된 검증 쿼리 자산을 쓰지 않고 새 쿼리를 생성함
   - 메타데이터나 출처 연결이 약함
   - 질문이 모호해 쿼리 라우터가 안전 우회 경로를 선택함
   - 데이터 오너나 분석가 검토가 필요함

 FALLBACK
   - SQL 문법 오류 또는 커넥션 타임아웃으로 실행 실패
   - DB 직접 조회가 막혀 내부 캐시를 확인함
   - suggestion only 상태 또는 데모 응답으로 우회함
   - 실제 운영 데이터 소스에서 나온 결과가 아님

SQL 실행이 성공해서 값이 맞더라도(EX 통과), 그 값이 어떤 데이터와 어떤 기준에서 나왔는지가 화면에 안 보이면 실무 판단에는 쓰기 어렵습니다.

관련 논문(TrustSQL 등) 역시 Text-to-SQL의 신뢰성은 정답을 맞히는 능력뿐만 아니라 답할 수 없는 모호한 질의를 스스로 거르는 보류 능력에 있다고 봅니다. 실제 엔터프라이즈 사례(LinkedIn Text-to-SQL 등)에서도 도메인 지식과 스키마 컨텍스트를 지식 그래프로 묶어 여러 단계로 검증합니다.

DataNexus는 이를 점수 하나만으로 평가하지 않고 사용자가 다음에 무엇을 할지 판단할 만큼 충분한 UI 단서도 제공했는지 확인합니다. 이 검수 원칙을 ‘Taste Gate’라고 부릅니다.

최종 레이아웃

앞에서 정리한 원칙을 바탕으로 최종 답변 카드 레이아웃을 다시 설계했습니다. 상단에는 신뢰 상태 배지와 핵심 출처를 고정하고 중앙에는 핵심 요약 데이터와 차트를 자동 렌더링합니다. 심층 검증을 위한 SQL 및 Trace 정보는 하단 탭 영역에서 접고 펼 수 있게 제공합니다.

+---------------------------------------------------------------+
| [Status: PASS / REVIEW / FALLBACK / ABSTAIN] | [Source: Data Catalog] |
+---------------------------------------------------------------+
| "이번 분기 순매출은 1,200억 원입니다."                        |
| [Chart: Bar / Line 자동 렌더링]                                |
+---------------------------------------------------------------+
| ▶ Show Evidence: SQL & Trace                                  |
+---------------------------------------------------------------+
| [Tabs] 1. SQL  2. Data Lineage  3. Metric Logic  4. Graph      |
+---------------------------------------------------------------+
| [👍 / 👎]       [수정 요청하기]  [내보내기]                |
+---------------------------------------------------------------+

임원은 최상단의 상태 라벨과 요약 수치만으로 빠르게 판단할 수 있고 실무 데이터 분석가나 DBA는 하위 Inspect 레이어로 들어가 SQL, 데이터 계보, 지식 그래프를 레이어별로 확인할 수 있습니다.

하단의 피드백 영역은 수집된 사용자 수정 의견을 실시간 학습에 직접 주입하지 않고 거버넌스 검토 큐로 보냅니다. 일종의 안전장치 역할입니다.

근거 데이터도 단순 문서 링크만 제공하지 않고, DataHub URN과 물리 table.column FQN(Fully Qualified Name)을 따라가며 특정 수치와 문장 단위까지 좁혀 표시합니다.

다만 Trusted나 PASS 같은 신뢰성 라벨을 조건 없이 자주 쓰면 사용자가 라벨만 보고 믿어버릴 수 있습니다. 그래서 런타임 검증 기준을 만족하는 경우에만 라벨을 켜도록 제어합니다.

 - PASS: 실무 판단이나 보고서 인용에 바로 쓸 수 있음
 - REVIEW: 수치 검증을 위해 하위 하이라이트와 SQL 검토 필요
 - FALLBACK: 인프라 단절 등으로 대체 데이터나 데모 응답을 표시한 상태
 - ABSTAIN: 보안 권한 제한이나 데이터 소스 부재로 답변할 수 없는 상태

자연어 답변은 수치와 핵심 기준을 짧게 먼저 전달합니다. 화면의 복잡도를 낮추기 위해 SQL과 Trace는 기본적으로 접어둡니다. 그래도 사용자가 언제든 데이터 흐름을 따라갈 수 있게 동선은 남겨야 합니다.

운영자 대시보드에서는 단순 지표 수집만 하지 않습니다. 실시간 피드에서 사용자가 어떤 인용 출처(citation)를 클릭했는지, 어떤 세부 경로(route)에서 Fallback 정체 현상이 자주 발생하는지 추적하고 전체 AI 자동화 스코프를 계속 손봅니다.

BI Agent 시스템을 기획하면서 가장 크게 부딪힌 질문은 “사용자가 화면에 표시된 데이터를 의심 없이 믿고 활용할 수 있는가"였습니다. 답변 근거가 함께 제공되지 않으면 답변 문장을 아무리 매끄럽게 다듬어도 기업 환경에서는 신뢰받기 어렵습니다.