에이전트가 '매출'을 엉뚱하게 계산하는 이유: Knowledge Catalog와 비즈니스 맥락

"지난달 매출 알려줘"라는 질문의 함정

자연어로 데이터를 묻는 에이전트를 만들면 거의 반드시 이 질문에서 걸립니다.

"지난달 매출 알려줘."

사람에게는 쉬운 질문입니다. 그런데 데이터 웨어하우스 안에는 매출처럼 생긴 컬럼이 여러 개 있습니다. orders.amount, payments.paid_amount, finance.revenue_daily.net_revenue. 환불을 뺄지, 부가세를 포함할지, 주문일 기준인지 결제일 기준인지도 테이블마다 다릅니다.

LLM은 이 중 하나를 그럴듯하게 고릅니다. 쿼리는 문법적으로 완벽하게 돌아갑니다. 숫자만 틀립니다.

이게 가장 위험한 실패입니다. 에러가 나면 누군가 고치지만, 틀린 숫자는 그대로 보고서에 올라가니까요.

처음 떠올리는 해결책과 그 한계

가장 먼저 시도하게 되는 건 프롬프트에 규칙을 적어 넣는 겁니다. "매출은 finance.revenue_daily.net_revenue를 쓸 것. 환불 차감 후 금액임."

처음 몇 개는 잘 됩니다. 문제는 규칙이 늘어날 때입니다.

활성 사용자, 이탈률, 재구매율처럼 정의가 필요한 지표는 금방 수십 개가 됩니다. 시스템 프롬프트가 사내 용어 사전이 되어버립니다. 정의가 바뀌면 프롬프트를 고친 사람만 압니다. 대시보드는 예전 정의로 계산하고, 에이전트는 새 정의로 계산하는 상황이 생깁니다.

결국 의미를 프롬프트가 아니라 데이터 쪽에 두어야 한다는 결론에 이릅니다. Next '26의 Knowledge Catalog 발표가 정확히 이 지점을 겨냥했습니다.

Knowledge Catalog가 하겠다는 일

Knowledge Catalog는 Dataplex Universal Catalog가 진화한 제품입니다. 구글은 이를 "범용 컨텍스트 엔진"이라고 불렀습니다.

하는 일을 풀어 쓰면 이렇습니다. 흩어진 테이블과 문서를 모아 연결합니다. 그 위에 비즈니스 의미를 계속 덧붙입니다. 에이전트는 이 연결 그래프를 보고 "매출"이 어느 테이블의 어느 계산인지 찾아갑니다.

눈여겨본 부분은 의미를 어디서 가져오느냐였습니다.

• 쿼리 로그에서 추론: 사람들이 실제로 어떤 컬럼을 어떻게 조인하고 집계하는지 보고 비즈니스 로직을 짐작합니다.
• LookML Agent: 전략 문서, 스프레드시트, 보고서를 읽고 시맨틱 정의를 만들어 줍니다.
• 외부 시스템 연합: Salesforce Data360, SAP, ServiceNow, Workday, Palantir의 데이터를 복사 없이(zero-copy) 카탈로그에 연결합니다.

여기에 몇 가지가 함께 발표됐습니다. SQL 엔진 안에 비즈니스 로직을 심는 BigQuery measures, SLA와 거버넌스 조건을 묶어 배포하는 Data Products, Looker·BigQuery·Spark를 가로지르는 컬럼 단위 리니지입니다.

쿼리 로그에서 배운다는 말이 불편했던 이유

쿼리 로그 기반 추론은 데이터 스튜어드가 손으로 메타데이터를 채우지 않아도 된다는 점에서 매력적입니다. 그런데 읽자마자 걸리는 게 있었습니다.

우리 조직의 쿼리 로그는 정답지가 아닙니다.

신입이 연습 삼아 짠 쿼리, 급하게 만든 일회성 분석, 정의가 바뀌기 전의 옛날 쿼리가 다 섞여 있습니다. 많이 실행된 패턴이 곧 올바른 패턴은 아닙니다. 매일 아침 돌아가는 오래된 리포트가 옛 정의로 매출을 계산하고 있다면, 카탈로그는 그 정의를 가장 확신 있게 배울 겁니다.

그래서 자동 추론에 기대기 전에, 사람이 확정한 정의를 먼저 데이터에 박아두는 것이 순서라고 생각했습니다. 카탈로그는 그걸 출발점으로 삼고, 나머지 빈칸을 추론으로 채우게 하는 겁니다.

지금 당장 할 수 있는 준비

BigQuery measures의 정확한 문법과 출시 상태는 아직 문서에서 확인하는 중입니다. 다만 기존 기능만으로도 미리 해둘 수 있는 일이 있습니다.

첫째는 정의가 확정된 지표를 뷰 하나로 고정하는 것입니다. 에이전트든 사람이든 이 뷰만 보게 만듭니다.

CREATE OR REPLACE VIEW `my_project.semantic.revenue_monthly` AS
SELECT
  DATE_TRUNC(paid_date, MONTH) AS month,
  SUM(paid_amount - refund_amount) AS net_revenue  -- 환불 차감, VAT 제외
FROM `my_project.finance.payments`
WHERE status = 'SETTLED'
GROUP BY month;

둘째는 테이블과 컬럼 설명을 꼼꼼하게 채우는 것입니다. 지루한 일이지만 효과가 가장 확실합니다. 카탈로그와 에이전트가 읽는 1차 재료가 바로 이 설명이기 때문입니다.

ALTER VIEW `my_project.semantic.revenue_monthly`
SET OPTIONS (
  description = '공식 월 매출. 결제 완료(SETTLED) 기준, 환불 차감, VAT 제외. 재무팀 확정 정의(2026-09).'
);

ALTER TABLE `my_project.finance.payments`
ALTER COLUMN paid_amount
SET OPTIONS (description = '결제 금액(VAT 포함). 매출 계산에 직접 쓰지 말 것 → semantic.revenue_monthly 사용');

두 번째 컬럼 설명처럼 "이걸 쓰지 말라"는 안내를 남기는 게 의외로 중요합니다. LLM은 이름이 그럴듯한 컬럼에 끌리기 때문입니다.

정의를 바꾸는 일은 여전히 사람의 몫

Data Products 발표에서 마음에 들었던 건 승인 워크플로가 함께 나왔다는 점입니다. 데이터 품질 규칙을 재사용 가능하게 만들고, 정의를 바꿀 때 구조화된 승인을 거치게 합니다.

결국 에이전트가 똑똑해질수록 정의의 주인이 누구인지가 더 중요해집니다. 카탈로그는 의미를 찾아주고 연결해 줍니다. 하지만 "우리 회사에서 매출이란 무엇인가"를 결정하는 회의까지 대신해 주지는 않습니다.

text-to-SQL 에이전트를 준비하고 있다면, 모델이나 프롬프트를 고르기 전에 핵심 지표 열 개의 정의부터 뷰와 설명으로 박아두길 권합니다. 카탈로그가 무엇이든 그 위에서 훨씬 덜 틀립니다.