지능형 애플리케이션을 위한
지식그래프의 기초를 세우다

앞 장에서 우리는 RAG가 무엇인지, LLM과 함께 RAG 흐름을 구현하는 간단한 예제 몇 가지를 보았다. 이 장에서는 지식그래프가 무엇이고, 그래프가 어떻게 검색 증강 생성(RAG)을 더 효과적으로 만드는지를 본다. 지식그래프를 모델링하는 방법과 그 목적에 Neo4j를 쓰는 법을 탐구하고, Neo4j의 데이터 지속 접근을 활용한 데이터 모델링이 더 강력한 지식그래프 구축에 어떻게 기여하는지 살핀다. 관계형 데이터베이스 관리 시스템(Relational Database Management System, RDBMS)에서 Neo4j 지식그래프에 이르는 데이터 저장소의 지속 접근들을 견주며, 다양한 데이터 모델을 통해 데이터를 더 깊이 이해하게 될 것이다.

RAG 모델과 Neo4j의 강건한 그래프 데이터베이스 능력의 융합이, 구조화된 지식 베이스를 활용해 성능과 결과를 끌어올리는 지능형 애플리케이션의 창조를 어떻게 가능케 하는지, 그 흥미로운 여정을 시작한다.

Neo4j와의 RAG 통합을 위한 지식그래프 구축의 실무로 뛰어들기 전에, 필요한 도구와 환경부터 갖추어야 한다.

GraphRAG 흐름이 Neo4j와 어떻게 작동하는지 보기 전에, 한 걸음 물러나 지식그래프를 모델링하는 방법부터 이해하자. 간단한 데이터를 놓고 RDBMS와 그래프에서 각각 어떻게 모델링하는지, 그리고 데이터를 바라보는 방식에 따라 모델링이 어떻게 달라지는지를 볼 것이다.

그래프는 우리에게 다르게 생각하기를, 풀려는 문제에 따라 데이터를 다른 관점에서 보기를 강요한다. 문제처럼 보일지 모르지만, 실은 수많은 문을 여는 일이다. 오랫동안 우리는 RDBMS 저장 접근을 개체-관계(Entity-Relationship, ER) 다이어그램의 틀로 생각하도록 배워 왔다. 기술에 한계가 있고 저장 비용이 매우 비쌌던 시절, 이 접근은 데이터를 표현하고 지속시키기에 좋았다. 그러나 기술이 진화하고 하드웨어가 저렴해지면서 새로운 길이 열렸고, 데이터를 모델링하는 새로운 접근이 가능해졌다. 그래프는 이 이점을 취하기에 알맞은 자리에 서 있다.

데이터 모델링의 새 길을 생각하려면, ER 다이어그램으로 데이터를 표현하던 익숙한 방식 몇 가지를 탈학습(unlearn)해야 할지도 모른다. 말은 간단하지만 실제로는 조금 어려운 일이다. 이 학습과 탈학습의 과정은 신경가소성 연구의 프리즘 고글 실험과 닮았다.

좋은 그래프 데이터 모델을 만드는 데 도움이 될 다른 접근이 있는지, 실생활에서 우리가 데이터를 소비하는 방식을 들여다보자.

그래프 데이터베이스는 데이터의 쉽고 효율적인 소비를 돕는 데이터 모델을 만들게 해 준다. 그래프와 함께라면 사고의 과정을 바꾸고 몇 가지 다른 모델링 접근을 시도해야 할 수도 있다. 첫 접근이 완전히 옳지 않을 수 있지만, 우리에게 통하는 수용 가능한 모델에 이를 때까지 데이터 모델을 계속 조정하면 된다. RDBMS를 비롯한 다른 기술에서는 데이터 모델이 경직되어 있어, 제대로 잡지 못하면 파장이 크다. 바로 여기서 Neo4j가 빛난다. 선택적이고 유연한 스키마 접근 덕분에, 처음에는 최적이 아닐 수 있는 데이터 모델로 시작하더라도 백지에서 다시 시작할 필요 없이 점진적으로 조율할 수 있다.

이제 작고 단순한 데이터를 놓고 RDBMS와 그래프의 데이터 모델링을 견주어 보자. 모델링할 데이터는 이렇다. 한 사람(firstName, lastName)과, 그 사람이 살았던 다섯 곳의 렌탈(주소 1행, 도시, 주, 우편번호, 입주 시점, 퇴거 시점). 단순해 보여도 이 데이터가 RDBMS와 그래프에서 어떻게 표현되는지의 미묘한 결을 이해하기에는 충분하다. 이 데이터로 답하려는 질문은 셋이다.

먼저 이 데이터가 RDBMS에서 어떻게 모델링되는지 본다. 다음 그림이 데이터 모델을 ER 다이어그램으로 나타낸 것이다.

이 데이터 모델에는 테이블이 셋이다. Person 테이블은 인물 상세를, Address 테이블은 주소 상세를 담는다. Person_Address 테이블은 렌탈 상세와 함께 두 테이블에 대한 참조를 담는다. Person이나 Address 개체의 데이터 중복을 피하려고 이 조인 테이블로 렌탈 상세를 표현하는 것이다. 이런 데이터 모델을 만들 때는 세부를 각별히 확신할 수 있어야 한다. 변경의 규모에 따라 모델을 고치는 일이 꽤 많은 시간을 잡아먹을 수 있고, 테이블 하나를 여러 테이블로 쪼개는 경우라면 데이터 마이그레이션이 만만치 않은 작업이 되기 때문이다. SQLite 데이터베이스는 이 튜토리얼로 만들 수 있다. 그 데이터베이스에 데이터를 적재하고, 앞서 정의한 질문들에 답하는 질의를 검증한다. 다음 SQL 스크립트가 테이블을 생성한다.

이제 RDBMS에서 데이터를 질의하는 방법을 본다.

이 질의는 end 컬럼 값이 null이라는 사실에 기대어 어느 것이 최신 주소인지 판별한다. 무엇이 마지막 주소인지 결정하는 논리가 SQL 질의 안에 들어 있는 것이다.

두 질의 모두 원하는 데이터에 이르기 위해 검색-정렬-필터(search-sort-filter) 패턴에 의존한다. 논리는 여전히 SQL 질의 안에 있다. 이제 같은 데이터를 그래프로 모델링하는 방법을 본다.

설명을 위해 이 데이터를 그래프로 모델링하는 가장 흔하고 단순한 방식을 쓴다.

이 모델은 우리가 정보를 영어로 표현하는 방식과 그대로 정렬된다. Person lives at Address. 이 문장에서 명사는 노드로, 동사는 관계로 표현된다. 이 데이터 모델 접근은 꽤 단순하고 RDBMS 데이터 모델의 ER 다이어그램과 거의 닮았다. 유일한 차이는 렌탈을 나타내던 조인 테이블이 관계로 모델링된다는 점이다. 이런 데이터 지속의 이점은 인덱스 조회 비용의 절감이다. RDBMS에서 데이터 검색의 가장 큰 비용은 조인 테이블의 인덱스 조회 비용이고, 데이터 크기가 커질수록 그 비용은 계속 불어난다. 이 접근으로 그 비용을 줄일 수 있다.

다음 Cypher 스크립트가 더 빠른 데이터 적재와 검색을 위한 인덱스를 설정한다. 일종의 스키마라고 생각해도 좋다.

이 스크립트는 Person과 Address 노드의 중복을 막는 고유 제약 둘을 만들고, 이름으로 인물을 빨리 찾기 위한 인덱스 하나를 더한다. 스키마가 갖춰지면 이 Cypher로 데이터를 적재한다.

이제 앞 절의 RDBMS 질의와 대응하는 Cypher 질의를 만든다.

앞서 본 SQL보다 훨씬 단순하다. 그러나 결과는 여전히 마지막 주소를 표시하는 방식, 곧 관계에 end 프로퍼티가 없다는 사실에 의존한다. 마지막 주소가 무엇인지 아는 논리는 SQL에서처럼 여전히 질의의 일부다. 다만 SQL에서 조인 테이블 위에서 쓰던 인덱스 검사(pa.person_id = p.id, pa.address_id = a.id)를 피할 수 있고, 이 인덱스를 피하는 것만으로도 성능이 좋아진다.

둘 다 SQL 질의와 마찬가지로 검색-정렬-필터 패턴에 기대어 원하는 데이터에 도달한다. 첫 번째·세 번째 주소를 판별하는 논리는 Cypher 질의의 일부다. 이제 더 섬세한 그래프 데이터 모델링 접근으로 들어간다.

이번에는 데이터를 다르게 바라보고 데이터 모델을 세운다. 이 모델은 우리가 데이터를 소비하는 방식의 영향을 받는다.

얼핏 보면 RDBMS의 ER 다이어그램에 더 가까워 보인다. Person, Address, 그리고 Rental 노드가 있다. 그러나 닮음은 거기까지다. Person은 FIRST 또는 LATEST 관계로 Rental 노드에 연결된다. Rental은 다른 Rental 노드로 향하는 NEXT 관계를 가질 수 있고, Address에도 연결된다. 모델이 조금 복잡해 보일 수 있지만, 데이터를 적재해 연결된 모습을 보면 이치가 통한다.

인덱스 설정은 앞의 모델과 같다. Rental 노드에는 어떤 인덱스나 제약도 더하지 않았다. 다음 Cypher가 데이터를 적재한다.

그래프에 저장된 데이터가 이전과 사뭇 다르다. Person은 첫 번째와 마지막 렌탈에만 연결되고, 첫 렌탈부터 마지막 렌탈까지는 NEXT 관계로 이어진다. 이제 세 질의를 다시 던져 보자.

이 질의는 앞의 그래프 질의나 SQL 질의와 확연히 다르다. 이전 그래프 모델에서 Cypher 질의는 마지막 주소를 판별하는 방식이 SQL과 비슷했다. 그런데 여기서는 질의가 영어 문장(Person's latest address)을 닮았다. 질의가 더 단순하고 대부분의 사람에게 이해하기 쉬워 보이지만, 이렇게 데이터를 표현할 가치가 있을까. 이 시나리오에서는 데이터를 정교하게 표현하기 위해 저장 공간을 더 쓴다. 처음 그래프 모델과 이 모델의 질의를 프로파일링해 이점이 있는지 확인하자.

순회하는 관계만 다를 뿐 질의 1과 정확히 같은 모습이다. 더는 검색-정렬-필터 패턴을 쓰지 않는다. 이것이 이 데이터 모델의 가장 큰 이점이다. 그래프 자체를 데이터 검색의 구조로 쓰기 쉬워지고, 어떤 데이터를 보고 있는지 판별하는 논리가 프로퍼티 비교의 형태로 질의에 새겨지지 않는다.

첫 렌탈로 순회한 뒤 다음 렌탈을 건너뛰어 세 번째 렌탈에 이르는 방식으로 쓰였다. 우리가 평소 데이터를 바라보는 방식 그대로이고, 데이터를 검색하는 질의를 이렇게 표현하는 것이 자연스럽게 느껴진다. 역시 검색-정렬-필터 패턴에 기대지 않는다. 세 질의의 프로파일을 비교하면 이렇다.

질의 1에서 처음 그래프 모델은 18번의 db 접근(hits)과 312바이트의 메모리를 썼고, 새 모델은 12번의 접근과 312바이트를 썼다. 데이터가 커지면 이전 모델의 db 접근은 인물이 가진 관계 수에 선형으로 늘어나지만, 새 모델에서는 상대적으로 일정하게 유지된다. 질의 2에서는 차이가 더 벌어진다. 처음 모델의 실행 계획은 더 크고 복잡해 19번의 접근과 1,020바이트를 썼지만, 새 모델은 질의 1과 거의 같은 계획으로 12번의 접근과 312바이트에 그쳤다. 정렬이 더 많은 메모리를 쓰게 만들고 더 많은 CPU 사이클을 소모하게 한다는 사실이 드러난다. 질의 3의 프로파일은 조금 더 복잡하지만 결과는 같은 방향이다. 처음 모델이 19번 접근과 1,028바이트, 새 모델이 16번 접근과 336바이트다.

질의와 데이터 모델의 분석에서 확인했듯, 데이터 모델을 정의하는 방식을 새로운 눈으로 바라보는 것만으로도 같은 연산의 성능과 비용에 커다란 영향을 줄 수 있다.

이 모델의 또 다른 이점이 있다. 렌탈이 주소의 관점에서 어떻게 돌아가는지 추적하고 싶다면, 같은 주소의 렌탈들 사이에 NEXT_RENTAL 같은 관계 하나만 더하면 된다. 같은 데이터에 대한 다른 관점이 열리는 것이다. RDBMS나 다른 데이터 지속 계층에서 이런 표현을 시도하기는 어렵다. 조인 인덱스 비용을 피하는 관계의 지속과 선택적 스키마라는 유연성을 지닌 Neo4j가 지식그래프 구축에 더 알맞은 이유가 여기에 있다.

좋은 그래프 데이터 모델은 RAG 흐름의 리트리버를 더 유능하게 만든다. 여기서 탐구했듯, 관련 데이터의 검색이 더 빠르고 쉬워지기 때문이다. 다음은 지식그래프를 RAG 흐름의 일부로 쓰는 방법이다.

앞 장에서 우리는 RAG 흐름의 심장인 리트리버를 보았다. 리트리버는 데이터 저장소를 활용해 관련 정보를 검색하고, 그것을 LLM에 제공해 질문에 대한 최선의 응답을 얻는다. 리트리버는 필요에 따라 다양한 데이터 저장소와 일할 수 있는데, 저장소의 능력이 검색된 정보가 얼마나 유용하고 빠르고 효과적인지를 크게 좌우한다. 바로 여기서 그래프가 큰 역할을 한다. GraphRAG는 그렇게 태어났다.

Neo4j 그래프 데이터베이스는 데이터를 노드와 관계로 이루어진 속성 그래프(property graph)로 지속시키는 데 탁월하다. 직관적인 방식으로 데이터를 저장하고 검색하기 쉬워지므로, RAG 리트리버의 데이터 저장소 노릇을 하기에 알맞다. 이 접근은 더 정확하고, 맥락을 알고, 신뢰할 수 있는 AI 기반 애플리케이션을 가능케 한다. 이제 RAG와 지식그래프의 힘을 결합해 LLM 응답을 개선하는 GraphRAG 흐름을 만든다.

앞 장에서 우리는 RAG 모델이 있는 채팅 애플리케이션의 정보 흐름을 논했다. 이제 그 워크플로가 어떻게 증강되어 채팅 애플리케이션의 응답을 개선하는지 본다. 그림 3.11은 GraphRAG의 워크플로다. 사용자의 프롬프트가 LLM API를 거쳐 처리되고, Neo4j에서 관련 정보가 검색되고, 프롬프트와 결합된 뒤 LLM API로 보내진다.

LLM API는 프롬프트와 Neo4j 지식그래프의 관련 정보를 둘 다 사용해 응답을 생성하고, 사용자에게 정확하고 맥락이 풍부해진 결과를 제공한다. Neo4j와 RAG 모델의 능력을 결합함으로써, GraphRAG는 더 많은 도메인 맥락으로 적합성을 끌어올린다. 이 GraphRAG 흐름을 보여줄 간단한 그래프를 만들어 보자.

이 예제에서는 시연을 위해 제한된 데이터로 그래프를 만들며, 영화와 그 줄거리에 집중한다. 제공된 코드 예제를 따라가며 Neo4j 데이터베이스를 설정하고, 노드와 관계를 정의하고, Cypher로 기본 질의를 수행하는 법을 배운다. 준비는 이렇다. 먼저 Neo4j 데이터베이스에 접근할 수 있어야 한다. Neo4j Desktop(로컬)이나 Neo4j AuraDB(클라우드) 어느 쪽이든 좋다. 데이터베이스 인스턴스를 시작하고 접속 자격증명(URI, 사용자명, 비밀번호)을 기록해 둔다. 필요한 Python 라이브러리는 Neo4j Python 드라이버와 pandas다: pip install neo4j pandas

먼저 간단한 그래프를 만든다. 이 그래프로 Neo4j가 GraphRAG 흐름의 어디에, 어떻게 자리 잡는지 보여줄 것이다.

전체 코드는 ch3/imdb_kg.py에 있다. 기본 그래프가 완성되었으니, 이제 이 그래프를 GraphRAG 흐름에 쓴다.

RAG 모델을 Neo4j와 통합하려면 모델이 그래프 데이터베이스를 질의하도록 설정해야 한다. 통상 RAG 모델과 Neo4j 사이의 통신을 매개하는 API나 미들웨어 계층을 두는 방식이다. 통합 워크플로의 예를 보자.

이 장의 전체 코드는 ch3/neo4j_rag.py에 있다.

기본 지식그래프를 만들고 질의하는 법, RAG 모델을 Neo4j와 통합하는 법을 이해했으니, 이제 지능적이고 맥락을 아는 애플리케이션을 만드는 데 필요한 기초 역량이 갖춰졌다. 다음으로 지식그래프를 강화하는 몇 가지 접근을 본다. 여기서는 개념만 소개하고, 지능형 애플리케이션 구축을 위한 상세한 탐구는 이후 장들에서 이어간다.

앞 절에서 만든 것은 단순한 그래프다. 지식그래프를 더 효과적으로 만드는 몇 가지 접근이 있고, 이후 장들에서 이 접근들로 우리의 지식그래프를 강화하게 된다.