서론

이 기사는 BigQuery의 프로퍼티 그래프(Property Graph) 기능을 사용하여 지식 그래프(Knowledge Graph)를 구축하고, 여러 테이블을 가로지르는 분석을 LLM이 자율적으로 수행하도록 시도한 내용을 정리한 것입니다.

여러 테이블에 걸친 데이터 분석을 LLM에 맡기려고 하면, "어떤 테이블과 어떤 테이블이 어떻게 연결되어 있는지"를 모델에 전달해야 합니다. 보통은 스키마 정의를 시스템 프롬프트(System Prompt)에 나열하지만, 테이블 수가 늘어날수록 관계에 대한 기술이 방대해져 LLM이 이를 간과하거나 오해할 리스크가 높아집니다.

그래서 이번에는 BigQuery의 프로퍼티 그래프(GRAPH_TABLE + MATCH 구문)를 사용하여 고객·주문·상품·매장과 같은 엔티티(Entity)의 관계성을 노드(Node)와 에지(Edge)로 정의한 지식 그래프를 구축했습니다. 프로퍼티 그래프는 지식 그래프를 표현하는 하나의 수단이며, SQL의 확장으로서 작성할 수 있기 때문에 LLM이 MATCH 구문으로 그래프를 따라가며 자율적으로 분석하게 할 수 있습니다. 이 메커니즘이 어느 정도 기능하는지, 그래프 유/무 및 모델 차이에 따라 실제로 비교해 보았습니다.

결론

실험을 통해 얻은 지견을 먼저 정리해 둡니다.

프런티어 모델(Frontier Model)에 그래프를 주어도 성과는 변하지 않는다

이번 규모(테이블 6개·상품 약 206건)에서는 고성능 모델의 경우 그래프가 있어도 일반적인 JOIN으로 분석을 진행하는 경우가 많았으며, GRAPH_TABLE을 거의 사용하지 않는 케이스가 있었습니다. 그래프를 주어도 "건너뛰는" 움직임이 눈에 띕니다.

경제적인 로컬 모델에서도 효과 차이는 작으며, 오히려 구문 오류가 증가한다

컨텍스트(Context) 제약으로 인해 프로퍼티 그래프의 혜택을 받기 쉬워야 할 로컬 모델에서도, 그래프 유/무에 따른 분석 품질의 큰 차이는 나타나지 않았습니다. 그보다는 GRAPH_TABLE 구문의 엄격한 스코프(Scope) 규칙에 걸리는 쿼리 오류가 더 두드러지는 결과가 되었습니다.

그래프에 너무 끌려가서, 그래프 외의 조사를 하지 않게 된다

그래프 정보를 시스템 프롬프트로 제공하면, 모델은 그래프의 에지·노드 범위 내에서만 분석하려는 경향이 있습니다. 그래프에 정의되지 않은 관점의 분석은 자발적으로 수행되지 않습니다. 에이전트의 프롬프트 설계나 도구 구성을 고민할 여지가 있어 보입니다.

다른 접근 방식과의 비교가 필요하다

과거 쿼리 아카이브를 벡터 검색(Vector Search)으로 참조하게 하는 방식이 이번과 같은 규모에서는 더 안정적으로 동작할 가능성이 높아 보입니다. 이 방식에 대해서는 별도의 기사에서 자세히 소개하고 있습니다.

지식 그래프가 진가를 발휘하는 것은 테이블 수가 많고 관계성이 복잡한 대규모 데이터가 된 이후가 아닐까 하는 인상을 받았습니다.

왜 로컬 LLM을 사용했는가

이번에 사용한 데이터는 고객 92,000건·주문 195만 건·주문 명세 430만 건의 EC 데이터입니다. 컨텍스트 길이(Context Length)가 충분히 큰 모델을 사용하면 모든 테이블의 스키마 정의·컬럼 설명·샘플 데이터를 한꺼번에 시스템 프롬프트에 전달할 수 있습니다. 그 경우 LLM은 데이터 구조의 전체상을 "놓치지 않고" 파악한 상태에서 SQL을 작성할 수 있으므로, 프로퍼티 그래프로 관계성을 별도로 정의할 필요는 그리 많지 않습니다.

반면, 컨텍스트 길이가 제한적인 로컬 LLM에서는 전달할 수 있는 데이터 정의의 양에 제약이 있습니다. 테이블 수가 늘어남에 따라 "이 테이블과 저 테이블 사이에 이런 관계가 있었다"라는 정보가 누락되기 쉽습니다. 프로퍼티 그래프는 그 관계성을 컴팩트하게 구조화한 것이므로, 컨텍스트가 짧은 모델일수록 혜택을 받기 쉽다는 전제가 있습니다. 이 조건을 의도적으로 만들기 위해 OpenAI 호환 API로 구동하는 로컬 모델(qwen3.6-35b-a3b / 27b)을 사용했습니다.

"LLM이 GRAPH_TABLE 구문을 능숙하게 사용할 수 있는가?"라는 의문도 출발점 중 하나였으며, 그래프 유/무 및 모델 차이에 따라 분석 품질에 얼마나 차이가 나는지를 측정했습니다.

환경과 전제

데이터는 Cymbal Pets라는 반려동물 용품 EC의 데모 데이터입니다. 고객 92,000건, 주문 195만 건, 주문 명세 430만 건이라는 적당한 사이즈로, 그래프 분석 검증에 적합합니다.

데이터와 그래프 준비

사용한 데이터

Google Codelabs가 제공하는 반려동물 용품 EC 데모 데이터인 "Cymbal Pets"를 사용했습니다.

지식 그래프 (Knowledge Graph)가 표현하는 것

이 데이터를 BigQuery의 프로퍼티 그래프 (Property Graph) 기능으로 모델링하면, '누가·무엇을·어디서 샀는가'라는 구매 행동의 관계성을 그래프 구조로 표현할 수 있습니다.

Customer ──[Placed]──> Orders ──[Has]──> Products
| |
[Visited] [BoughtTogether]
...

그래프화함으로써, '이 고객이 구매한 상품과 함께 자주 구매되는, 아직 미구매 상태인 상품을 찾는다'와 같은 **다단계 관계 트래버설 (Multi-hop Relationship Traversal)**을 JOIN을 쌓는 대신 MATCH 구문 한 줄로 표현할 수 있습니다.

데이터 구축 및 그래프 정의에 대한 자세한 절차는 다음 Codelabs를 참조하십시오.

LLM 자율 분석 에이전트 구현

에이전트 아키텍처

에이전트는 매우 심플한 구성입니다. LLM에 run_bigquery_query 도구를 하나 전달하여, 자연어 질문에 대해 자율적으로 SQL을 생성·실행·해석하게 합니다.

사용자의 질문
→ LLM: GRAPH_TABLE 쿼리 생성
→ 도구: BigQuery API로 실행
...

에이전트 코드

# experiments/04_llm_agent.py (발췌)
import json
from openai import OpenAI
...

GRAPH_TABLE 구문의 함정

실험을 통해 가장 중요하다고 느낀 지견을 먼저 말씀드립니다. LLM이 반복적으로 범하는 에러의 원인은 '노드 변수의 스코프 규칙 (Scope Rule)'이었습니다.

규칙: 노드 변수는 RETURN 절 내부에서만 사용할 수 있음

-- ❌ 흔한 에러: 외부 SELECT에서 노드 변수를 참조
SELECT c.loyalty_member, p.product_name -- c. p. 는 여기서 사용할 수 없음
FROM GRAPH_TABLE(
...

CTE에서도 동일한 규칙이 적용됨

-- ❌ 흔한 에러: CTE의 SELECT 리스트에 노드 변수를 작성
WITH base AS (
SELECT o.order_id, p.category -- o. p. 는 여기에서도 사용할 수 없음
...

로컬 LLM은 이 규칙을 프롬프트에 명시해도 반복적으로 위반했습니다. 반면 API 모델의 경우 거의 한 번에 통과하였으며, 구문 규칙 준수 능력에서 모델 간에 큰 차이가 있었습니다.

실험 결과

3가지 질문을 사용하여 비교 실험을 진행했습니다.

Q1: 함께 자주 구매되는 상품 조합 Top 5
Q2: 로열티 회원과 비회원의 구매 패턴 비교
Q3: Angelica Russell을 위한 추천 상품 (개인화 추천)

정답 데이터 (필자가 수동으로 분석)

LLM 에이전트의 결과를 평가하기 위한 정답 데이터로서, 제가 직접 쿼리를 작성하여 실행한 결과를 보여드립니다.

Q1: 함께 자주 구매되는 상품 Top 5

BoughtTogether 에지의 Jaccard 유사도를 내림차순으로 정렬하는 것만으로 1개의 쿼리, 에러 없이 완료되었습니다. K9 Guard Flea & Tick Shampoo를 기점으로, 동일 브랜드의 그루밍·건강 관리 상품이 강한 공기(Co-occurrence) 클러스터를 형성하고 있음을 알 수 있습니다.

Q2: 로열티 회원 vs 비회원의 구매 패턴 비교

카테고리 구성 및 결제 방법 모두 1포인트 미만의 차이만 나타나, 구매 행동의 '종류'는 회원과 비회원을 구분할 수 없다는 결과가 나왔습니다.

Q3: Angelica Russell을 위한 추천 상품

먼저 구매 이력을 확인하니, 개·고양이·새·소형 동물·수조 등 5종류 이상의 반려동물을 동시에 기르고 있음을 알 수 있었습니다.

개 : K9 Guard (노미 샴푸·칫솔·컨디셔너·발톱 그라인더·덴탈 츄)
고양이 : Ocean Bites (연어·참치·실내묘 사료), Hairball Remedy
새 : Happy Birds (욕조·사료), Chirpy Seed
...

BoughtTogether 에지의 점수 순서에 따른 추천 결과입니다.

1위인 K9 Guard Dog Ear Cleaner는 평가 4.8로 후보 중 최고점이며, K9 Guard 그루밍 세트를 다수 구매한 Angelica가 귀 관리 상품만 미구매했다는 '틈새 보완형 니즈 (Gap-filling needs)'에 부합합니다. 3위인 Flea Fighter Plus for Cats 또한, 강아지용 벼룩 샴푸는 가지고 있지만 고양이용은 미구매했다는 다두 사육자 특유의 구매 격차를 찌른 추천입니다.

실험 1: 그래프 있음 vs 그래프 없음 (qwen3.6-35b-a3b)

그래프가 있는 경우 (04 스크립트)는 GRAPH_TABLE + MATCH를 사용하고, 그래프가 없는 경우 (05 스크립트)는 일반적인 JOIN / CTE만으로 분석합니다.

Q3에서 그래프가 있는 쪽이 12단계를 모두 소모하며 실패했습니다. 원인은 모두 '노드 변수 스코프 위반 (Node variable scope violation)'의 반복이었습니다. 그래프가 없는 쪽은 co_related_products_for_angelica 테이블 (BoughtTogether 에지의 원 데이터)을 직접 JOIN함으로써 5단계 만에 완료했습니다.

그래프가 없는 쪽이 에러가 적고 전 문항을 완료할 수 있었다는 것이 솔직한 결과입니다.

실험 2: 모델 간 비교 (그래프 있음 · 35b-a3b vs 27b)

동일한 그래프 있음 스크립트를 사용하여 모델만 바꾸어 비교합니다.

에러 건수는 우연히도 동일했으나, 실패하는 문항이 역전되었습니다.

• 35b-a3b: Q2는 효율적으로 완료, Q3는 노드 변수 스코프 위반을 끝까지 반복하며 실패 -
• 27b: Q3는 초반에 에러를 내면서도 자기 수정(Self-correction)을 통해 완료, Q2는 '아직 더 분석할 수 있다'고 판단하여 멈추지 못하고 타임아웃 발생

27b의 수렴 판정(Convergence判定) 능력이 약하다는 점이 눈에 띄었습니다. '이제 충분한 통찰을 얻었다'라고 판단하는 능력에서 파라미터 사이즈의 차이가 나타났을 가능성이 있습니다.

요약

이번에는 BigQuery의 프로퍼티 그래프 (Property Graph) 기능을 사용하여 LLM 에이전트의 자율 분석을 시도하였고, 그래프 유무 및 모델 차이에 따라 비교했습니다.

얻은 주요 지견을 정리합니다.

• GRAPH_TABLE의 노드 변수 스코프 규칙은 LLM에게 습득 비용이 높으며, 로컬 LLM에서는 반복적으로 위반하는 사례가 있었다.
• 그래프가 없는 쪽 (JOIN/CTE)이 에러가 적고 전 문항을 완료할 수 있었다.
• 동일한 에러 건수라도 실패하는 문항은 모델에 따라 다르며, 수렴 판정 능력에서 차이가 나타났다.
• 구문 준수 (Syntax compliance) 능력이 높은 모델을 사용한다면 그래프가 있는 쪽의 우위성이 나타날 가능성이 있다.

BigQuery의 그래프 기능 자체는 기술적 서술성이 매우 높으며, 에지의 시맨틱스 (Semantics)가 SQL에 나타나는 점은 개발 경험(DX) 측면에서 매력적입니다. 꼭 모델을 바꾸어 추가 실험을 해보시기 바랍니다.

저의 X(구 Twitter)에서는 LLM뿐만 아니라 AI를 활용한 업무 개선 정보를 발신하고 있으니, 관심 있으신 분들은 꼭 팔로우 부탁드립니다.

Discussion