AI on Your Lakehouse: Context Comes in Shapes, Not Queries — Zach Blumenfeld, Neo4j

---

출처 URL: https://www.youtube.com/watch?v=kRkcNOsRyYg 채널: aiDotEngineer 업로드일: 2026-07-23 길이: 7150초 (약 119분) 요약: 데이터 레이크하우스에서 AI 에이전트가 구조화된 데이터 웨어하우스와 비정형 문서 레이크를 동시에 이해하도록 돕는 그래프 기반 맥락 모델을 소개한다. 맥락은 단일 쿼리가 아니라 '연결된 시맨틱 레이어', '목차', '테마' 세 가지 형태(Shape)로 제공되어야 하며, Neo4j Carta와 Neo4j CLI를 활용한 에이전트 코딩 실습을 통해 구현 방법을 보여준다.

1. 핵심 주장

1. 데이터 레이크하우스의 진정한 난제는 "데이터 접근"이 아니라 "에이전트에게 적절한 맥락을 주는 것"이다. 텍스트→SQL, 벡터 검색 등으로 접근성은 높아졌지만, 수백~수천 개의 테이블과 수백만 개의 문서가 섞인 환경에서 에이전트가 필요한 데이터를 제대로 조각내어 보는 일은 여전히 어렵다.

2. 맥락은 "쿼리"가 아니라 "형태(Shape)"로 제공되어야 한다. Neo4j가 제안하는 해결책은 데이터 종류에 구애받지 않는 그래프 모델로, 구조화된 데이터와 비정형 문서를 모두 그래프로 표현해 에이전트가 질문에 맞는 형태로 맥락을 탐색하게 한다.

3. 세 가지 핵심 맥락 형태가 있다: (1) 연결된 시맨틱 레이어(Connected Semantic Layer): 데이터 웨어하우스의 스키마·테이블·열·외래키를 그래프로 표현; (2) 목차(Table of Contents): 문서 라이브러리의 계층 구조와 상호 링크를 그래프로 표현; (3) 테마(Themes): 문서 간 연결 구조를 그래프 데이터 과학(Community Detection)으로 군집화해 숨겨진 패턴을 발견.

4. 데이터를 그래프에 복사(ETL)하지 않고 메타데이터·구조만 그래프로 올리는 "시맨틱 레이어" 접근이 핵심이다. 실제 데이터는 BigQuery, 클라우드 스토리지 등 원래 위치에 두고, 그래프는 에이전트가 올바른 쿼리와 탐색 경로를 찾도록 돕는 지능형 레이어로 동작한다.

5. 에이전트 코딩(Agentic Coding) 환경에서 Neo4j CLI, MCP 서버, Cypher 스킬을 결합하면 복잡한 그래프 쿼리를 직접 작성하지 않고도 자연어 질문을 구조화된 데이터와 문서로 연결할 수 있다.

2. 세부 근거

2.1 데이터 레이크하우스의 양면성

• 데이터 웨어하우스 측: 정형 데이터, 테이블, 스키마, 외래키로 구성된 세계.
• 데이터 레이크 측: 매뉴얼, 안전 게시판(TSB), 리콜 공지, 수리 이력 등 비정형 문서의 세계.
• 전통적 접근: 텍스트→SQL로 웨어하우스를 질의하고, 벡터 검색으로 문서를 검색. 하지만 테이블 수가 많아지거나 문서 저장소가 커지면 정보 누락, 잘못된 조인, 맥락 손실이 발생한다.
• 특히 어려운 질문 유형: 부정/부족 증명("우리가 문서화하지 않은 DTC 코드는 무엇인가?"), 패턴 발견("어떤 리콜이 특정 차량 그룹에 집중되는가?"), 대규모 스키마 탐색("수백 개의 유사 테이블을 어떻게 올바르게 조인해야 하는가?")은 단순 검색으로 해결하기 어렵다.

2.2 Neo4j의 그래프 데이터 모델

• Neo4j는 속성 그래프(Property Graph) 데이터 모델을 사용한다: 노드(사람·장소·사물), 관계(동사/연관성), 속성(문자열·숫자·날짜·벡터 등) 세 요소로 모든 데이터를 모델링.
• 데이터를 추가하면 마치 미리 조인된 테이블 모음처럼 상호 연결되므로, 노드 사이 이동이 매우 쉽다.
• Neo4j Carta는 Neo4j의 연구실 프로젝트로, 메타데이터 그래프를 자동 생성하고 MCP 서버를 제공해 에이전트가 데이터 웨어하우스의 메타데이터를 읽고 그래프로 탐색할 수 있게 한다.
• 가상 그래프(Virtual Graph) 기능을 통해 SQL 데이터를 그래프 관점으로 조회할 수도 있지만, 본 워크숍에서는 데이터를 이동시키지 않는 메타데이터 시맨틱 레이어에 집중한다.

2.3 첫 번째 형태: 연결된 시맨틱 레이어

• BigQuery에 저장된 6개의 테이블과 5개의 참조(외래키) 조인 경로를 그래프로 변환.
• 그래프 중앙에는 데이터베이스 노드, 주변에 스키마·테이블·열 노드가 연결.
• 에이전트가 자연어 질문("IC 2042 부품을 장착한 차량은?")을 받으면, 시맨틱 레이어 그래프를 읽어 필요한 SELECT, JOIN, WHERE절을 생성한 뒤 BigQuery에 실행.
• 중요한 점: 데이터를 그래프로 복사하지 않는다. 그래프는 메타데이터 의미 계층으로, 실제 행 데이터는 SQL 쿼리로 원천 데이터베이스에서 가져온다.
• 데이터를 그래프에 직접 넣는 것이 유리한 경우: 공급망 최단 경로, 재귀 조인, 그래프 임베딩, 클러스터링 등 그래프 알고리즘이 필요한 경우. 그러나 운영 데이터를 옮기는 것은 보안, 동기화, 규모의 문제로 현실적으로 어려울 수 있다.

2.4 두 번째 형태: 목차(Outline/Table of Contents)

• 비정형 문서(매뉴얼, TSB, 리콜)는 단순 문서 집합이 아니라 계층적 포함(Containment) 트리와 상호 링크(Cross-link)로 구성된 지식 네트워크다.
• 폴더→문서→섹션→하위 섹션으로 이어지는 포함 트리(Containment Tree)를 그래프 노드로 표현하고, "다음 섹션", "관련 매뉴얼" 등의 링크도 관계로 표현.
• 모든 노드는 계층적 URI를 ID로 사용한다. 예: library/bulletins/TSB-001#section-3. 이 URI 구조 덕분에 에이전트는 특정 서브트리만 탐색하거나, 특정 문서를 기점으로 연결된 모든 정보를 가져올 수 있다.
• 결정론적 로딩(Deterministic Loading): 폴더/문서/섹션/링크의 구조를 해석하여 그래프로 변환. LLM 기반 엔티티 추출 없이도 문서의 내재된 구조를 활용하므로 빠르고 재현 가능하다.
• 검색 보완: Lucene 전체 텍스트 검색 인덱스를 문서/섹션 노드에 추가해, 벡터 검색 없이도 어휘 기반 검색을 수행. 계층적 URI로 검색 범위를 제한할 수 있어 "리콜 공지만 검색" 같은 스코핑이 가능.
• 의미 확장(Semantic Expansion): 검색어 "엔진 떨림"을 "실화/불안정한 공회전"까지 확장해 전체 텍스트 인덱스에서 관련 용어를 찾도록 에이전트에 지시.

2.5 세 번째 형태: 테마(Themes)와 커뮤니티 탐지

• 문서들이 서로 링크로 연결되면 자연스럽게 클러스터가 형성된다. 이를 그래프 데이터 과학(GDS)의 커뮤니티 탐지 알고리즘(Leiden)으로 군집화.
• Leiden은 Louvain의 후속 알고리즘으로, 더 효율적으로 커뮤니티를 식별한다. Neo4j GDS는 메모리 내 프로젝션에 고성능 알고리즘을 실행해 수억 개 노드 규모에서도 클러스터링 가능.
• 실행 결과: 문서들이 브레이크(Brake), BCM, 코일/점화 등 차량 부품별 주제로 자연스럽게 묶인다. 군집 레이블은 LLM 태깅 없이 데이터에 이미 있는 파일명/링크명에서 추출.
• 전도도(Conductance) 지표: 클러스터 내부 연결성과 외부 연결성을 비교해 군집의 긴박함/느슨함을 측정. 이를 통해 의미 있는 테마만 필터링.
• 테마는 "우리가 문서화하지 못한 영역이 어디인가?", "새로 들어온 데이터는 어떤 주제에 속해야 하는가?" 같은 부동산 수준의 질문에 답하는 데 유용.
• 시간 데이터와 결합하면 시계열로 테마 변화를 추적할 수 있어, 사기 탐지, 리콜 패턴 변화, 수리 트렌드 분석에 활용 가능.

2.6 에이전트 코딩과 Neo4j CLI

• Neo4j CLI는 명령줄에서 그래프 스키마를 읽고 Cypher 쿼리를 실행할 수 있는 도구. Claude Code 등 에이전트 코딩 환경에서 MCP 서버로 연결하면 에이전트가 직접 그래프를 추론하고 쿼리를 구성.
• Neo4j Cypher 스킬: 최신 Cypher 2025 기능과 GDS 스킬을 포함해 에이전트가 시대에 뒤떨어진 문법을 사용하지 않도록 한다.
• 워크숍에서는 Claude에게 "어떤 차량에 IC 2042 부품이 장착되었는가?", "문서화되지 않은 DTC 코드는 무엇인가?", "공지/리콜의 주제와 수리 이력은 어떻게 연관되는가?" 같은 질문을 시키고, 에이전트가 스스로 SQL 쿼리, 전체 텍스트 검색, 그래프 탐색, 커뮤니티 탐지를 조합하여 답을 찾도록 한다.

3. 사례

3.1 시나리오: 가상의 자동차 정비 체인 AutoFix

• 전국적인 자동차 정비 체인(Pep Boys 유형)을 가정.
• 데이터: 차량, DTC 코드, 수리 절차, 부품, 작업 지시 내역, 매뉴얼, 안전 게시판(TSB), 리콜 공지.
• 목표: 현장 기술자(Danny)를 돕는 보조 인력(Sam 같은 AI 엔지니어)을 만들어 재방문률(수리 실패로 인한 고객 재방문)을 최소화.
• 데이터 인프라: 문서는 클라우드 스토리지, 정형 데이터는 BigQuery. Snowflake, Databricks 등으로 확장 가능한 패턴.

3.2 개별 질문: "IC 2042 부품을 장착한 차량은?"

• 에이전트는 먼저 연결된 시맨틱 레이어 그래프를 읽어, IC 2042 부품이 어떤 테이블과 조인되는지 파악.
• 필요한 SELECT, JOIN, WHERE절을 생성해 BigQuery에서 실행.
• 결과: 해당 부품이 장착된 차량 목록과 대수를 반환.
• 이 과정에서 에이전트는 스키마를 직접 학습할 필요 없이, 메타데이터 그래프가 안내하는 경로를 따른다.

3.3 부정/부족 증명: "창고 데이터에서 활용되지 않는 문서는?"

• 질문: "작업 지시 내역(창고 데이터)과 문서(매뉴얼/TSB/리콜) 사이에 불일치가 있는가? 문서화되지 않은 DTC 코드는?"
• 이는 벡터 검색이나 유사도 검색으로는 답하기 어려운 질문이다. 부정(존재하지 않음)을 증명해야 하기 때문.
• 에이전트는 다음 경로를 따른다:
  1. 작업 지시 내역에서 발생한 DTC 코드들을 수집.
  2. 문서 저장소에서 동일한 DTC 코드가 등장하는지 Lucene 전체 텍스트 검색 + URI 기반 스코핑으로 확인.
  3. 문서화되지 않은 코드를 식별.
• 실제로 두 가지 문서화되지 않은 DTC 코드가 발견되었다. 이는 현장에서 문제가 발생하고 있지만 매뉴얼/TSB에는 언급되지 않는 영역.

3.4 패턴 발견: "리콜/공지의 주제와 수리 이력의 연관성은?"

• 테마 형태를 사용:
  1. 문서 그래프(매뉴얼, TSB, 리콘)에서 Leiden 커뮤니티 탐지를 실행해 주제(테마)를 추출.
  2. 추출된 테마를 작업 지시 내역(정형 데이터)의 수리 유형과 연결.
  3. 각 테마별 영향을 받은 차량 대수와 비율을 집계.
• 결과: 브레이크, BCM, 점화/코일 등 자연스러운 주제 그룹이 형성되고, 각 주제가 실제 수리 이력과 어떻게 겹치는지 확인 가능.
• 활용: 보증 범위 결정, 재고 관리, 교육 자료 우선순위, 숨겨진 결함 패턴 발견.

3.5 문서 탐색: "목차를 따라 매뉴얼에서 ABS 관련 진단 정보를 찾아라"

• 에이전트는 단순 키워드 검색이 아니라, 라이브러리→게시판→문서→섹션→하위 섹션→링크의 계층 구조를 탐색.
• 예: manuals/ABS/diagnostic/platform-codes 같은 URI를 따라가며, 관련 진단 문제 해결 절차를 추적.
• 문서 간 상호 링크(예: "관련 매뉴얼: 코일 식별")를 통해 그래프를 따라 이동.
• 이는 단순 벡터 검색보다 맥락 손실이 적고, "어떤 문서가 어떤 상위 개념에 속하는가"를 에이전트가 이해할 수 있게 한다.

4. 시사점·실천

4.1 맥락을 "형태"로 설계하라

• AI 시스템을 설계할 때 데이터 접근 도구(텍스트→SQL, 벡터 검색)만 나열하지 말고, 에이전트가 질문 유형에 따라 사용할 수 있는 맥락 형태(Shape)를 정의하라.
• 구조화 데이터 → 시맨틱 레이어/연결 그래프; 비정형 문서 → 목차/포함 트리; 전체 데이터셋 → 테마/커뮤니티 탐지. 세 가지 형태를 조합하면 개별 질문, 탐색, 패턴 발견 모두를 커버할 수 있다.

4.2 데이터를 옮기지 않고 그래프를 사용하라

• 데이터를 모두 그래프 데이터베이스로 ETL하는 것은 보안, 동기화, 규모, 거버넌스 측면에서 현실적 제약이 크다.
• 메타데이터, 스키마, 문서 구조, 링크 관계만 그래프로 구축하고, 실제 데이터 쿼리는 원천 시스템(BigQuery, Snowflake, Databricks, 클라우드 스토리지)에 위임하는 방식부터 시작하라.
• 그래프 알고리즘이 필수적인 경우(최단 경로, 커뮤니티 탐지, 임베딩)에만 선택적으로 데이터를 그래프에 적재.

4.3 결정론적 로딩과 LLM 추출의 균형

• 문서가 이미 잘 구조화된 경우(폴더/제목/섹션/링크), LLM 기반 엔티티 추출 없이 결정론적 파싱만으로 그래프를 구축할 수 있다. 이는 비용, 속도, 재현성 측면에서 유리.
• 하지만 생명과학, 분자/약물 데이터처럼 매우 구체적인 온톨로지가 필요한 경우, LLM 추출이나 전문 모델을 활용해 추가 노드와 관계를 만들어야 한다.
• 복잡도가 높은 도메인에서는 결정론적 구조 + LLM 기반 엔티티 추출을 하이브리드로 결합하라.

4.4 에이전트 코딩 환경 구축

• Neo4j CLI, MCP 서버, Cypher 스킬을 Claude Code/Cursor 등 에이전트 코딩 도구에 연결하면, 데이터 과학자나 엔지니어가 복잡한 Cypher를 직접 작성하지 않아도 된다.
• 스킬 파일에 "어떤 형태를 만들고, 어떤 쿼리 구조를 사용할지"를 사양으로 정의해 두면, 에이전트가 반복적으로 일관된 결과를 생성할 수 있다.
• 다만, 관계명/노드 레이블이 너무 많아지면 에이전트의 맥락 창과 쿼리 구성에 부담을 주므로, 적절한 추상화 수준을 유지하라.

4.5 검색은 보완 수단, 대체 수단이 아니다

• 그래프 탐색(목차)과 벡터/전체 텍스트 검색은 대립 관계가 아니라 보완 관계.
• 목차로 큰 그림을 잡고, Lucene/벡터 검색으로 구체적 내용을 찾고, 테마로 전체 패턴을 이해하는 워크플로우를 설계.
• 특히 부정 증명, 누락 발견, 패턴 집계 같은 질문은 벡터 검색 단독으로는 어려우므로, 그래프 구조를 활용해야 한다.

4.6 문서 품질과 거버넌스

• 문서명, 링크명, 제목, 섹션 구조가 정확할수록 에이전트의 탐색과 검색 품질이 높아진다.
• Obsidian-style 명명된 링크, 동의어, 문서 메타데이터(업데이트 날짜, 공식 여부)를 추가하면 그래프 기반 지식 관리의 정확도가 향상.
• 문서가 업데이트되면 함께 참조하는 다른 문서의 URI/링크도 업데이트해야 한다. 그래프 로딩은 결정론적이지만, 원본 데이터의 불일치는 그대로 반영된다.

4.7 운영적 고려사항

• Neo4j Carta는 현재 연구실 프로젝트(프리뷰)이며, 데이터 브릭스 커넥터, 메트릭 뷰 등이 향후 추가될 예정.
• 가상 그래프(Virtual Graph)와 푸시다운 Cypher를 통해 SQL 데이터를 그래프 관점으로 쿼리하는 기능도 발전 중.
• 시간이 지남에 따라 테마 ID가 변할 수 있으므로, 시계열 추적이 필요한 경우 스냅샷과 버전 관리 전략을 수립하라.
• 보안상 민감 데이터가 있는 경우, 데이터를 물리적으로 이동하지 않는 시맨틱 레이어 접근이 더 안전할 수 있다.

5. 핵심 용어 정리

• Lakehouse: 데이터 웨어하우스(정형)와 데이터 레이크(비정형)를 결합한 데이터 아키텍처.
• Semantic Layer: 비즈니스 용어와 메트릭 정의를 포함해, 데이터를 일관되고 합의된 방식으로 쿼리할 수 있게 하는 추상 계층.
• Ontology: 데이터를 해석하고 추론하는 데 도움이 되는 개념적 정의 집합.
• Neo4j Carta: Neo4j의 연구실 프로젝트로, 메타데이터 그래프를 생성하고 MCP 서버를 제공.
• Cypher: Neo4j의 그래프 쿼리 언어.
• GDS (Graph Data Science): Neo4j의 그래프 알고리즘 라이브러리.
• MCP Server: Model Context Protocol 서버로, 에이전트가 외부 도구와 데이터베이스에 접근할 수 있게 하는 인터페이스.
• Leiden: 그래프 커뮤니티 탐지 알고리즘.
• Lucene: 전체 텍스트 검색 인덱스 라이브러리.
• DTC (Diagnostic Trouble Code): 차량 자기진단 시스템의 오류 코드.
• VIN (Vehicle Identification Number): 차량 식별 번호.
• Conductance: 커뮤니티 내부/외부 연결성 비율로, 군집의 긴박함을 측정하는 지표.