AI 시대, 데이터도 설명이 필요합니다

요즘은 데이터를 직접 조회하는 대신 자연어로 AI에게 질문하는 일이 점점 자연스러워지고 있습니다.

“지난달 매출 알려줘.”
“활성 고객 수가 얼마나 돼?”
“지난해보다 매출이 얼마나 늘었어?”

그런데 실제 업무에서 사용해보면 이야기가 조금 달라집니다. 간단한 질문에는 꽤 잘 답하는데, 정작 업무에서 필요한 질문을 하면 엉뚱한 답이 나오기도 합니다. 더 어려운 점은 그 답이 틀렸는지조차 알아채기 어려울 때가 있다는 것입니다.

왜 그럴까요? 상당수의 경우 문제는 AI가 아니라, AI가 데이터를 이해하는 데 필요한 정보가 충분히 제공되지 않았다는 데 있습니다.

같은 질문도 데이터가 얼마나 잘 설명되어 있느냐에 따라 결과가 달라집니다.

1. AI가 데이터를 잘 이해하려면

흔히 이렇게 생각합니다. “데이터가 많으면 AI도 잘 작동하겠지.” 하지만 꼭 그렇지는 않습니다.

AI가 데이터를 잘 활용하려면 데이터의 양만큼이나 중요한 것이 있습니다. 그 데이터가 무엇을 의미하는지, 어떤 규칙으로 만들어졌는지, 어떻게 사용해야 하는지가 명확해야 합니다.

사람은 모르면 물어볼 수 있습니다. 새로 합류한 팀원도 시간이 지나면 자연스럽게 익히고, 모르는 것이 있으면 담당자에게 물어볼 수도 있습니다.

“여기서 매출은 취소 건을 제외한 금액이죠?”

AI는 그렇지 않습니다. 컬럼 이름, 테이블 설명, 코드값의 의미, 비즈니스 규칙 — 이런 것들이 명확하게 적혀 있지 않으면 AI는 추측할 수밖에 없습니다. 그리고 그 추측이 틀리면 에러도 없이 그냥 틀린 숫자가 나옵니다.

그래서 AI 시대에는 데이터 자체뿐만 아니라 데이터를 설명하는 정보도 중요해집니다.

2. 사람이 보면 쉬운데 AI에게는 어려운 것

몇 가지 예를 살펴보겠습니다.

ord_amt ❓ 의미 불명확

CREATE TABLE orders (
  order_id BIGINT,
  ord_amt  DECIMAL(18,2),
  status   INT
);

“주문 금액이겠구나”라고 짐작할 수 있지만, AI는 알 수 없는 것이 많습니다.

세금 포함? 할인 전/후? 취소 주문 포함? 통화 단위?

flg_actv_ind ❓ 값 불명확

“활성 여부 플래그”라고 추측할 수 있지만, 값이 무엇인지는 알 수 없습니다.

Y / N 1 / 0 TRUE / FALSE 내부 코드?

status = 1 ❓ 코드 의미 불명확

1이 무엇을 의미하는지 AI는 알 수 없습니다. 사람도 처음엔 모릅니다. 차이는 사람에게는 물어볼 사람이 있다는 것입니다.

활성 상태? 승인 완료? 결제 완료?

이런 컬럼이 수백 개의 테이블에 퍼져 있다면, AI가 모든 걸 정확하게 추론하길 기대하기는 어렵습니다.

3. 그래서 ‘데이터를 설명하는 것’이 중요하다

AI가 데이터를 제대로 활용하게 하려면, 그동안 사람만 알고 있던 맥락을 데이터와 함께 남겨둬야 합니다. 이런 정보를 메타데이터라고 합니다.

읽기 쉬운 이름으로 짓기

❌ 전

flg_actv_ind
dt_lst_purch
ord_amt

✓ 후

is_active
last_purchased_at
net_revenue_usd

컬럼 설명 달기

SQL · BigQuery 컬럼에 설명 추가하기

CREATE TABLE orders (
  net_revenue_usd FLOAT64
    OPTIONS(description=”취소·환불 제외 후 확정된 매출 금액 (USD, 세금 포함)”),

  is_cancelled BOOL
    OPTIONS(description=”TRUE = 취소된 주문. 매출 집계 시 반드시 제외.”),

  order_status STRING
    OPTIONS(description=”주문 상태. ‘confirmed’|’cancelled’|’refunded'”)
);

도구마다 방법이 조금씩 다릅니다. BigQuery는 OPTIONS(description=...), Snowflake는 COMMENT, dbt를 쓴다면 schema.yml에 description을 달 수 있습니다. 방법은 달라도 목적은 같습니다. AI가 읽을 수 있는 형태로 의미를 남겨두는 것입니다.

데이터 사전 만들기

지표명	정의	주의사항
net_revenue_usd	취소·환불 제외 후 확정 매출 (USD)	세금 포함, 쿠폰 할인 반영
is_active	최근 90일 내 구매 이력 있는 고객	탈퇴·삭제 고객 제외
order_status	주문 처리 상태	‘cancelled’, ‘refunded’는 집계 제외

4. 비즈니스 규칙을 데이터 모델에 담기

문서에 비즈니스 규칙을 적어두는 것만으로 끝낼 수도 있지만, 반복해서 사용하는 규칙이라면 데이터 모델에 직접 반영하는 방법도 있습니다.

예를 들어 매출 정의가 “결제 완료된 주문 중 취소와 환불을 제외한 금액”이라면, 이 규칙을 매번 쿼리에 작성하는 대신 View로 만들어두는 방식입니다.

❌ 매번 직접 작성

SELECT
  SUM(net_revenue_usd)
FROM orders
WHERE
  status NOT IN (2, 3);

— 개발자마다 조건이
— 달라질 수 있음

✓ View로 굳혀두기

CREATE VIEW valid_orders
AS SELECT *
FROM orders
WHERE
  status NOT IN (2, 3);

— 한 곳에서 관리,
— AI도 바로 활용 가능

이렇게 하면 AI가 매번 비즈니스 규칙을 추측해야 하는 부담도 줄어듭니다.

5. Text-to-SQL — 자연어로 데이터를 조회한다

이제 처음의 질문으로 돌아가 보겠습니다. “지난달 매출 얼마야?” — 이 질문에 AI가 데이터베이스를 조회해서 답할 수 있을까요? 가능합니다. 그 대표적인 방법이 바로 Text-to-SQL입니다.

Text-to-SQL 동작 흐름

입력

“지난달 매출 알려줘”

↓

1단계

질문의 의도와 조건 해석

↓

2단계

관련 테이블·컬럼 탐색

↓

3단계

SQL 생성 + 검증

↓

출력

결과 해석 및 답변

Text-to-SQL · 예시 “지난달 매출 알려줘” → AI 생성 SQL

SELECT
    SUM(net_revenue_usd) AS revenue
FROM valid_orders
WHERE
    DATE_TRUNC(order_date, MONTH)
    = DATE_TRUNC(
        DATE_SUB(CURRENT_DATE(), INTERVAL 1 MONTH),
        MONTH
      );

— net_revenue_usd = “확정 매출” 임을 설명으로 알고 있음
— valid_orders View = 취소·환불 제외 규칙이 반영됨
— order_date = 집계 기준 날짜임을 데이터 사전에 정의됨

⚠️ 문법적으로 올바른 SQL ≠ 비즈니스적으로 올바른 SQL
SQL이 실행돼도 결과가 틀릴 수 있습니다. 취소 주문이 포함됐거나, 잘못된 컬럼을 골랐거나. 에러 없이 틀린 숫자가 나오는 게 데이터 조회의 가장 골치 아픈 문제입니다.

6. Semantic Layer — 비즈니스 개념과 데이터를 연결하다

한 단계 더 나아가면 Semantic Layer라는 개념으로 연결됩니다. 단순히 컬럼 설명을 관리하는 것을 넘어, 회사가 사용하는 비즈니스 개념과 실제 데이터를 연결해 관리하는 계층입니다.

AI가 “지난달 매출 알려줘”라는 질문을 받았을 때, 단순히 테이블을 찾는 것이 아니라 “회사가 정의한 ‘매출’이라는 지표를 찾아서, 그 정의에 맞는 데이터를 조회한다”는 방향으로 접근할 수 있습니다.

마치며

결국 AI 시대의 데이터 준비는 완전히 새로운 일이 아닐지도 모릅니다.

오늘 새로 만드는 테이블 하나, 설명을 추가하는 컬럼 하나, 팀에서 합의한 데이터 정의 하나. 작은 것부터 시작해도 충분합니다.

AI에게 우리 데이터를 잘 이해시키는 가장 좋은 방법은, 먼저 사람이 이해할 수 있게 만드는 것입니다.