그래프 기반 RAG 아키텍처 패턴: 프로덕션에서 벡터 검색을 넘어
출처: VentureBeat
검색 보강 생성(RAG) 은 대형 언어 모델(LLM)을 사내 데이터에 연결하는 사실상의 표준이 되었습니다. 일반적인 아키텍처는 문서를 청크로 나누고, 이를 벡터 데이터베이스에 임베딩한 뒤, 코사인 유사도로 상위 k개의 결과를 검색하는 방식이며, 비구조적 의미 검색에 효과적입니다.
하지만 공급망, 금융 규제, 사기 탐지와 같이 데이터가 고도로 상호 연결된 기업 도메인에서는 벡터 전용 RAG가 자주 실패합니다. 유사성은 포착하지만 구조를 놓치기 때문입니다. “부품 X의 지연이 고객 Y의 3분기 납품에 어떤 영향을 미칠까?”와 같은 다중 홉 추론 질문에 벡터 스토어는 부품 X가 고객 Y의 납품에 포함된다는 사실을 “알고” 있지 않기 때문에 어려움을 겪습니다.
이 글에서는 그래프 강화 RAG 패턴을 살펴봅니다. Meta에서 고처리량 로깅 시스템을 구축한 경험과 Cognee에서 사내 데이터 인프라를 만든 경험을 바탕으로, 의미적 유연성을 제공하는 벡터 검색과 구조적 결정성을 제공하는 그래프 데이터베이스를 결합한 레퍼런스 아키텍처를 단계별로 안내합니다.
문제: 벡터 검색이 맥락을 잃을 때
벡터 데이터베이스는 의미를 포착하는 데 뛰어나지만 토폴로지를 버립니다. 문서를 청크로 나누고 임베딩하면, 계층·의존·소유와 같은 명시적 관계가 평탄화되거나 완전히 사라집니다.
예시: 공급망 위험 시나리오
(이 예시는 가상의 상황이지만, 기업 데이터 아키텍처에서 흔히 마주하는 구조적 문제를 정확히 보여줍니다.)
- 구조화된 데이터: 공급업체 A가 부품 X를 공장 Y에 제공한다는 내용이 SQL 데이터베이스에 정의돼 있음.
- 비구조화된 데이터: “태국 홍수로 인해 공급업체 A의 시설이 생산을 중단했다.”는 뉴스 기사.
“생산 위험”이라는 쿼리로 표준 벡터 검색을 하면 뉴스 기사가 검색됩니다. 하지만 해당 기사와 공장 Y의 생산량을 연결할 맥락이 부족합니다. LLM은 뉴스를 받지만 핵심 비즈니스 질문인 **“어떤 하위 공장이 위험에 처했는가?”**에 답할 수 없습니다.
실제 운영에서는 이것이 환각으로 나타납니다. LLM은 뉴스와 공장 사이의 연결 고리를 찾지 못해 관계를 추측하거나, 데이터가 존재함에도 “모르겠다”는 답변을 반환합니다.
패턴: 하이브리드 검색
이를 해결하기 위해 **“Flat RAG”**에서 “Graph RAG” 아키텍처로 전환합니다. 세 층으로 구성된 스택을 사용합니다.
-
수집(Ingestion) – “Meta” 교훈
Meta에서 Shops 로깅 인프라를 구축하면서 구조는 수집 단계에서 강제해야 한다는 교훈을 얻었습니다. 뒤늦게 지저분한 로그에서 구조를 복원하려 하면 신뢰할 수 있는 분석을 보장할 수 없습니다. RAG에서도 텍스트 청크에서 엔터티(노드)와 관계(엣지)를 추출해 수집 단계에서 그래프에 연결해야 합니다. LLM이나 명명된 엔터티 인식(NER) 모델을 활용해 청크에서 엔터티를 추출하고 기존 그래프 레코드와 연결할 수 있습니다. -
저장(Storage)
구조 그래프는 Neo4j와 같은 그래프 데이터베이스에 저장합니다. 벡터 임베딩은 특정 노드(예:RiskEvent노드)의 속성으로 저장합니다. -
검색(Retrieval)
하이브리드 쿼리를 실행합니다.- 벡터 스캔: 의미적 유사도로 그래프 내 진입점을 찾습니다.
- 그래프 탐색: 해당 진입점에서 관계를 따라가며 컨텍스트를 수집합니다.
레퍼런스 구현
Python, Neo4j, OpenAI를 이용해 간단한 공급망 위험 분석기를 구현해 보겠습니다.
-
그래프 모델링
비구조화된 “위험 이벤트”를 구조화된 “공급망” 엔터티와 연결하는 스키마가 필요합니다. -
수집: 구조와 의미 연결
여기서는 이미supplier → factory관계가 구축돼 있다고 가정합니다. 새로운 비구조화된 “위험 이벤트”를 수집하면서 그래프에 연결합니다. -
하이브리드 검색 쿼리
핵심 차별점입니다. 상위 k 청크만 반환하는 대신, Cypher를 사용해 벡터 검색으로 이벤트를 찾고, 그 뒤에 탐색을 통해 하위 영향을 찾아냅니다.
출력 예시
[
{
"issue": "Severe flooding...",
"impacted_supplier": "TechChip Inc",
"risk_to_factory": "Assembly Plant Alpha"
}
]LLM은 이 구조화된 페이로드를 받아 **“TechChip Inc의 홍수로 인해 Assembly Plant Alpha가 위험에 처했습니다.”**와 같이 정확한 답변을 생성합니다.
운영 교훈: 지연 시간과 일관성
노트북 수준 구현을 실제 서비스로 옮기려면 트레이드오프를 관리해야 합니다.
1. 지연 시간 비용
그래프 탐색은 단순 벡터 조회보다 비용이 많이 듭니다. Meta에서 제품 이미지 실험을 할 때 엄격한 지연 시간 예산을 관리했으며, 그 경험은 Graph RAG에도 그대로 적용됩니다. 모든 것을 실시간으로 계산할 여유가 없습니다.
| 방식 | 평균 조회 시간 |
|---|---|
| 벡터 전용 RAG | ~50‑100 ms |
| 그래프 강화 RAG | ~200‑500 ms (홉 깊이에 따라) |
완화 방안: 의미 캐싱을 활용합니다. 새로운 질문이 이전 질문과 코사인 유사도 > 0.85이면 캐시된 그래프 결과를 반환해 “그래프 비용”을 크게 줄일 수 있습니다.
2. “구식 엣지” 문제
벡터 DB에서는 데이터가 독립적이지만, 그래프에서는 데이터가 상호 의존적입니다. 공급업체 A가 공장 Y에 대한 공급을 중단했지만 엣지가 그래프에 남아 있으면 RAG 시스템은 존재하지 않는 관계를 환각하게 됩니다.
완화 방안: 그래프 관계에 TTL을 두거나, ERP 등 진실 소스로부터 CDC 파이프라인을 통해 실시간 동기화합니다.
인프라 결정 프레임워크
Graph RAG를 도입해야 할까? Cognee에서 사용하는 판단 기준은 다음과 같습니다.
벡터 전용 RAG를 선택할 경우
- 코퍼스가 평면 구조(예: 위키, Slack 대량 로그)일 때
- 질문이 광범위하고 단순할 때(예: “VPN을 어떻게 재설정하나요?”)
- 지연 시간 < 200 ms가 절대적인 요구사항일 때
그래프 강화 RAG를 선택할 경우
- 도메인이 규제 대상(금융, 의료 등)일 때
- 설명 가능성이 필요하고, 탐색 경로를 보여줘야 할 때
- 답변이 다중 홉 관계에 의존할 때(예: “간접 자회사가 어떤 영향을 받나요?”)
결론
그래프 강화 RAG는 벡터 검색을 대체하는 것이 아니라, 복잡한 도메인을 위한 필수적인 진화입니다. 인프라를 지식 그래프로 바라보면, LLM에게 환각할 수 없는 비즈니스 구조적 진실을 제공하게 됩니다.
Daulet Amirkhanov – UseBead 소프트웨어 엔지니어.