Looker LookML Knowledge Catalog 인덱싱 GA, AI 에이전트 활용법

AS-IS, 에이전트가 원시 테이블에 직접 붙을 때

에이전트가 원시 데이터베이스 테이블에 바로 연결되면 테이블 설명이나 용어집이 있어도 수학적 관계를 그때그때 추론해야 해요. 원문은 이때 생기는 문제를 두 가지로 짚습니다.

• 지표 정의 흔들림: 순매출이나 고객 획득 비용 같은 핵심 KPI를 에이전트가 서로 다른 공식으로 만들어 냅니다. 예를 들어 order_status가 'Complete'일 때만 매출로 인식하는 회계 규칙이나, 연간 계약을 활성 서비스 일수로 안분하는 규칙이 빠질 수 있어요.
• 조인 팬아웃: 인보이스, 라인 아이템, 환불처럼 1:N, 0:N 관계가 얽힌 스키마에서 미리 모델링된 조인 관계와 대칭 집계 규칙이 없으면 행이 불어나 재무 합계가 부풀려집니다.

이번에 바뀐 것, LookML이 카탈로그의 1급 계층이 됐어요

이전 카탈로그 연동은 파일 수준 포인터와 기본 대시보드 목록 정도만 담았습니다. 이번 GA로 LookML의 결정적(deterministic) 시맨틱이 Knowledge Catalog 컨텍스트 그래프의 정식 계층이 됐어요. 에이전트가 그래프에서 지표를 찾으면 그 지표의 정확한 정의, 조인 경로, 원천 테이블까지의 리니지를 같은 곳에서 함께 얻습니다.

동기화는 기본값으로 켜져 있어서 사용자가 따로 할 일이 없고, 운영(production) LookML을 갱신하면 거의 실시간으로 카탈로그에 반영돼요. 카탈로그에 기본 인덱싱되므로 Gemini Enterprise에서 별도 에이전트 코드나 별도 카탈로그 저장소 없이 바로 쓸 수 있습니다. Gemini Enterprise는 읽기 전용 스킬과 하이브리드 검색으로 기술 스키마, 비즈니스 용어집, 인덱싱된 LookML 로직을 한 번에 찾은 뒤 연합 BigQuery 커넥터에 넘겨 SQL을 생성합니다. 커스텀 에이전트를 만드는 개발자는 LookupContext API로 같은 컨텍스트 번들을 가져올 수 있어요.

카탈로그에 올라가는 엔터티 수준은 다음과 같습니다.

• 모델(looker-model): 설명 메타데이터, 데이터베이스 연결 라우팅, include 계층, 데이터 검증 테스트(assert), 모델과 Explore, View, 대시보드를 잇는 부모-자식 EntryLink
• Explore(looker-explore): 조인 타입, sql_on, many_to_one 같은 관계 카디널리티, foreign_key, required_joins, sql_where를 Schema-Join 관계로 인덱싱. always_filter, access_filter 같은 필수 필터와 상속된 dimension, measure, 사전 정의된 스타터 쿼리도 포함
• View와 필드(looker-view): ${total_revenue} / NULLIF(${count}, 0) 같은 컬럼 단위 컴파일된 LookML SQL 표현식, 기본 키, dimension group 타임프레임, 필드 동의어, 파생 테이블 변환 로직(SQL 및 네이티브 파생 테이블, 파티션 키, 클러스터 키)
• 대시보드, Look, 타일: UI에서 만든 것과 LookML로 정의한 대시보드, 시각화 타일을 필터, 차트 타입, 소유자, 사용 통계와 함께 카탈로그화

BigQuery 테이블부터 개별 대시보드 타일까지 테이블과 컬럼 단위 리니지도 보여서, 데이터 엔지니어가 스키마 변경 영향을 장애 전에 점검할 수 있습니다.

에이전트 활용 패턴 3가지와 실행 흐름

원문은 "지난 회계 분기 제품 카테고리별 총매출과 적용되는 지역 프로모션 정책 한도는?"이라는 복합 질문으로 세 가지 아키텍처를 비교합니다. 패턴 3, 즉 Knowledge Catalog와 Looker 시맨틱 레이어를 함께 쓰는 구성에서는 에이전트가 두 단계로 움직여요.

• 컨텍스트와 거버넌스 탐색: 데이터에 손대기 전에 카탈로그를 검색해 thelook_ecommerce LookML 모델이 gold 인증인지 확인하고, 컬럼 단위 거버넌스 태그를 점검한 뒤, 질문을 정확한 LookML dimension과 measure에 매핑합니다.
• 결정적 시맨틱 실행: LLM이 SQL을 즉석에서 만들지 않고, 카탈로그에 인덱싱된 LookML의 수학적 정의에 SQL을 근거시켜 반복 가능한 수치를 돌려줍니다. 답과 함께 측정값과 필터가 미리 채워진 'Open in Looker Explore' 링크도 줘서, 한 번 클릭으로 행 단위 라인 아이템까지 쪼개 볼 수 있어요.

실무 적용 포인트

• 사내 핵심 KPI(순매출, 이탈, 획득 비용 등)가 LookML에 이미 정의돼 있는지 먼저 점검하세요. 정의가 없으면 에이전트에 줄 시맨틱도 없습니다.
• 지표 공식과 조인 관계는 LookML에서 한 번만 관리하세요. 같은 정의가 BI 리포트와 에이전트 답변에 동시에 적용됩니다.
• 운영 LookML 변경이 카탈로그에 거의 실시간으로 반영되므로, 정의를 고칠 때 배포 검증 절차를 함께 두는 편이 안전해요.
• 리니지 화면은 소스 테이블 스키마를 바꾸기 전 영향 받는 대시보드를 찾는 용도로 쓸 수 있습니다.
• 이 구성은 Looker Core on Google Cloud 기준입니다. 도입 범위는 해당 환경에서 먼저 확인하세요.

자주 묻는 질문

Knowledge Catalog와 LookML은 각각 무엇을 맡나요

Knowledge Catalog는 구조화 테이블과 비정형 문서 메타데이터를 묶은 컨텍스트 그래프로, 어떤 데이터가 있고 어떻게 거버넌스되며 어떻게 연결되는지를 알려줘요. LookML은 지표를 어떻게 계산하는지, 테이블을 어떻게 조인하는지를 정의합니다. 에이전트에는 둘 다 필요하고, 한쪽만으로는 부족하다는 것이 원문의 입장이에요.

AI 에이전트가 원시 테이블에 직접 붙으면 왜 숫자가 틀리나요

지표 공식을 에이전트가 추론하면서 같은 KPI에 서로 다른 정의가 생기고, 1:N 관계 조인에서 행이 불어나 합계가 부풀려질 수 있기 때문입니다. LookML은 조인 경로와 지표 SQL 공식을 미리 정의해 두므로 에이전트가 SQL 수식을 즉석에서 추측하지 않아도 돼요.

이 기능을 쓰려면 따로 설정해야 하나요

동기화는 기본값으로 항상 켜져 있고 사용자 조치가 필요 없습니다. Gemini Enterprise는 별도 에이전트 코드나 별도 카탈로그 저장소 없이 인덱싱된 메타데이터를 바로 쓸 수 있어요. 커스텀 에이전트는 LookupContext API로 같은 컨텍스트를 가져옵니다.

에이전트가 만든 답을 Looker에서 검증할 수 있나요

답과 함께 측정값과 필터가 미리 채워진 Open in Looker Explore 링크가 제공됩니다. 사용자는 이 링크로 데이터를 쪼개 보고 행 단위 라인 아이템까지 확인할 수 있어요.