[AI] 벡터DB 다음에 그래프를 붙이면 끝? GraphRAG를 ‘좀 아는 사람’의 구현 가이드
벡터DB 다음에 그래프를 붙이면 끝?
GraphRAG를 ‘좀 아는 사람’의 구현 가이드
기본 원리부터 Microsoft GraphRAG·DRIFT·LightRAG·HippoRAG 2, 금융권 데이터와 가명처리까지
GraphRAG 경험이 없다고 해서 “문서에서 엔티티와 관계를 뽑아 그래프에 넣습니다”까지만 말하면 너무 아쉽다. 실무에서 중요한 질문은 그 다음부터다. 무슨 관계를 뽑을 것인가? 같은 고객·상품·조항을 어떻게 하나의 노드로 합칠 것인가? 질문에 따라 Local·Global·Multi-hop 검색을 어떻게 고를 것인가? 그리고 LLM이 잘못 만든 edge를 금융 서비스에 어디까지 믿을 것인가?
GraphRAG는 마법의 정확도 버튼이 아니다. 잘 맞는 데이터와 질문에는 강력하지만, 관계가 별로 중요하지 않은 FAQ에 사용하면 비싼 그래프 장식품이 된다. 이 글은 GraphRAG를 처음 보는 단계에서 시작해 설계 리뷰·PoC·면접에서 구현과 한계까지 이야기할 수 있는 수준으로 정리한다.
0. 어느 날, 보험 약관 창고에 두 명의 조사관이 들어왔다
첫 번째 조사관은 문장을 아주 빨리 찾는다. “암 진단”, “면책기간”, “2024년 가입”과 비슷한 문장이 적힌 서류를 순식간에 책상 위에 올린다. 이 조사관이 Vector RAG다. 수십만 장 중 관련 문서를 찾는 능력은 놀랍지만, 서류와 서류 사이의 관계까지 자동으로 이해하지는 않는다.
두 번째 조사관은 벽에 사건 관계도를 그린다. 상품 P1042에서 A특약으로 선을 긋고, A특약에서 약관 제7조로, 제7조에서 2024년 개정 공문으로 이어 붙인다. 문서를 찾는 것에서 멈추지 않고 누가, 무엇과, 어떤 이유로, 언제 연결되는지 기록한다. 이 조사관이 GraphRAG다.
약점: 서류 사이의 연결 누락
약점: 관계도를 만드는 비용
● P1042 청크
● 개정공문 청크 ● 지급기준 청크
↓ 적용 ↓ 규율
약관 v3.2 ← 개정 ← 공문
GraphRAG는 질문과 비슷한 문장만 찾는 대신, 문서 속 개체·사건·조항·관계와 원문 근거를 그래프로 연결하고 그 경로를 따라 답변에 필요한 문맥을 구성하는 RAG 계열이다.
노드와 엣지만 알면 절반은 시작했다
그래프에서 node는 사람·상품·특약·조항 같은 명사이고, edge는 포함한다·개정한다·참조한다 같은 관계다. edge에는 방향과 속성이 붙는다. “약관 A가 약관 B와 관련 있다”보다 “약관 A가 2024년 1월 1일부터 약관 B를 대체한다”가 훨씬 쓸모 있다.
개정 공문 ── 개정 ──▶ 제7조 ◀── 규율 ── A특약
모든 관계에는 source_id · evidence_span · valid_from/to · confidence가 따라간다.
※ 기술 및 규제 내용은 2026년 9월 기준 공개 자료를 바탕으로 정리했다. 개인정보·신용정보의 실제 처리는 사내 개인정보보호·법무·보안 부서와 개별 검토가 필요하다.
1. 왜 Vector RAG만으로는 부족할까
Vector RAG는 질문과 의미가 가까운 청크를 잘 찾는다. 하지만 가까움과 연결됨은 다르다.
필요한 연결: 상품 P1042 → A특약 → 약관 v3.2 → 개정 공문 → 지급심사 규칙 → 적용일
각 문서는 표현도 다르고 저장 위치도 다를 수 있다. 벡터 검색 한 번에 모든 조각이 Top-k에 들어오지 않으면 답이 끊긴다. GraphRAG는 중간 개체를 다리로 사용한다.
질문 → 비슷한 청크 Top-k → 답변
GraphRAG
질문 → 시작 엔티티 탐색 → 관계·이웃·원문 청크 확장 → 경로별 근거 조립 → 답변
| 질문 유형 | Vector RAG | GraphRAG |
|---|---|---|
| “해지환급금이란?” | 충분히 강함 | 과투자 가능성 |
| “A와 B의 차이” | 두 청크가 모두 검색돼야 함 | 공통 관계·속성 비교에 유리 |
| “이 규정이 영향을 주는 상품은?” | 누락 가능 | 역방향 edge 탐색에 유리 |
| “전체 민원의 주요 패턴은?” | 대표 청크 편향 | community 요약에 유리 |
2. ‘GraphRAG’라는 말은 두 가지다
첫째는 knowledge graph를 retrieval에 활용하는 일반적인 패턴이다. Neo4j, PostgreSQL, Neptune 등 어떤 저장소를 쓰든 그래프 관계로 문맥을 확장하면 넓은 의미의 GraphRAG다.
둘째는 Microsoft Research가 공개한 고유한 GraphRAG 파이프라인이다. 이 방식은 문서에서 엔티티와 관계를 추출하는 데서 끝나지 않고, Leiden community detection으로 그래프를 계층화하고 각 community report를 미리 생성한다. 그래서 “이 문서 전체의 주요 테마는?” 같은 global sensemaking 질문을 처리한다. 원 논문은 약 100만 토큰 규모의 private corpus에 대한 global query-focused summarization에서 Naive RAG보다 포괄성과 다양성이 좋아졌다고 보고했다.
Text Units
Relationships
Leiden
Hierarchical
Local·Global·DRIFT
3. Microsoft GraphRAG의 Indexing 파이프라인
GraphRAG 품질은 질의 프롬프트보다 indexing에서 더 많이 결정된다. 핵심 흐름은 다음과 같다.
원문
PDF·표·공문
TextUnit
문맥+메타데이터
추출
Entity·Relation
Resolution
중복 통합
Graph
근거 연결
Community
Leiden 군집
Report
계층 요약
- Document parsing & TextUnit
PDF·Word·HTML을 파싱하고 의미 단위로 나눈다. 페이지, 절, 표, 시행일, 문서 버전 같은 provenance를 잃으면 나중에 그래프가 맞아도 감사 가능한 답을 만들 수 없다. - Entity extraction
LLM 또는 NER 모델이 상품, 특약, 조직, 규정, 질병, 사건 등을 추출한다. - Relationship extraction
상품-포함-특약,조항-개정됨-공문,사고-적용됨-면책규칙처럼 방향·유형·근거를 가진 edge를 만든다. - Entity resolution
“무배당 건강보험 P1042”, “P1042”, “건강플랜 2024”가 같은 상품인지 통합한다. 실무 난이도의 절반이 여기 있다. - Community detection
Leiden 알고리즘 등으로 밀접한 하위 그래프를 계층적 community로 묶는다. - Community report
LLM이 각 community의 주요 엔티티, 관계, 사건, 위험과 근거를 요약한다. - Embedding & indexes
엔티티 설명, community report, 원문 TextUnit을 벡터·키워드·그래프 인덱스로 연결한다.
LLM이 관계를 잘 추출했는데도 “A특약”, “A 특약”, “무배당A특약”을 서로 다른 노드로 남긴다. 그래프가 커 보이지만 실제로는 중복 노드가 만든 가짜 밀도다. Entity resolution 없는 GraphRAG는 관계형 환각을 구조화해서 저장하는 시스템이 될 수 있다.
4. Query 방식: Local, Global, DRIFT
도서관에 비유하면 더 쉽다. Local Search는 특정 인물의 책장에서 관련 자료를 꺼내는 방식이고, Global Search는 각 층의 사서가 작성한 요약 보고서를 모으는 방식이다. DRIFT는 전체 안내도를 먼저 본 뒤, 단서가 생길 때마다 특정 책장으로 내려가는 탐정형 검색이다.
질문 → 상품 P1042 → 이웃 edge → 관련 원문
모든 community → 부분 답 → map-reduce 종합
큰 그림 → follow-up 질문 → local 반복
| 모드 | 동작 | 좋은 질문 | 비용 |
|---|---|---|---|
| Local Search | 질문과 가까운 엔티티에서 관계·community·원문을 확장 | 특정 상품·조항·사건 | 중간 |
| Global Search | community reports를 map-reduce로 종합 | 전체 테마·패턴·위험 | 높음 |
| DRIFT Search | community 정보로 시작해 follow-up 질문을 만들며 local 탐색 | 범위와 세부를 함께 요구 | 중~높음 |
| Basic Search | 일반 vector RAG에 가까운 검색 | 단순 사실·FAQ | 낮음 |
실무에서는 사용자가 모드를 고르게 하지 않는다. query classifier가 질문의 entity specificity, 예상 hop, aggregation 범위, 시간 제약을 보고 Basic/Local/Global/DRIFT를 라우팅하고, 답변 근거가 부족하면 한 단계 확장하는 방식이 좋다.
Microsoft는 공식 GitHub 저장소를 현재 “largely in maintenance mode”라고 안내하고 있다. 즉 연구 결과와 reference pipeline은 여전히 가치가 있지만, 신규 production 기능을 Microsoft 프로젝트가 계속 대신 구현해 줄 것이라고 기대하면 안 된다. 운영 환경에서는 공식 코드를 그대로 제품화하기보다 데이터 모델·검색 아이디어를 가져와 사내 ingestion, 권한, 증분 갱신, 관측성 계층을 별도로 설계하는 편이 현실적이다.
5. 최신 흐름: 더 싸고, 덜 손실되고, Agent가 스스로 탐색한다
① LazyGraphRAG — 처음부터 모든 요약을 만들지 않는다
Microsoft의 full GraphRAG는 community report를 미리 생성하기 때문에 indexing 비용이 크다. LazyGraphRAG는 query가 오기 전에 모든 것을 LLM으로 요약하지 않고, vector RAG 수준의 저비용 index와 query-time 작업을 결합한다. Microsoft는 indexing cost가 full GraphRAG의 약 0.1%이며 vector RAG와 같은 수준이라고 보고했다. 핵심은 비싼 이해 작업을 무조건 선불로 내지 않고 필요한 질문에서 지불하는 것이다.
② LightRAG — 그래프와 벡터의 dual-level retrieval
LightRAG는 저수준의 구체적 엔티티·관계와 고수준의 주제·개념을 함께 인덱싱한다. Microsoft GraphRAG보다 단순하고 incremental update를 고려하기 쉬워 PoC에 많이 사용된다. 다만 ‘light’라는 이름이 schema·entity resolution·검증까지 자동으로 해결해준다는 뜻은 아니다.
③ HippoRAG 2 — 그래프를 장기기억처럼 사용
ICML 2025의 「From RAG to Memory」는 passage node와 phrase/entity node를 함께 두고 Personalized PageRank를 활용한다. 한 번의 유사도 검색이 아니라 연상 기억처럼 관련 경로를 활성화한다. GraphRAG의 최신 경쟁점이 ‘요약 그래프’에서 비모수적 continual memory로 확장되고 있음을 보여준다.
④ E²GraphRAG — local/global 수동 선택을 줄인다
E²GraphRAG는 summary tree와 가벼운 entity graph, entity↔chunk 양방향 인덱스를 결합한다. 논문은 GraphRAG보다 indexing을 최대 10배 빠르게 하고, LightRAG 대비 retrieval에서 최대 100배 속도를 보고했다. 중요한 아이디어는 모델이 global인지 local인지 미리 맞히게 하기보다 adaptive retrieval로 필요한 구조를 선택하는 것이다.
⑤ GraphRAG의 XAI — 답변만 보지 말고 경로를 디버깅한다
XGraphRAG 같은 연구는 어떤 노드와 edge가 검색됐고, 어느 단계에서 근거가 누락됐는지 시각화한다. 운영 GraphRAG에는 최소한 query → seed entity → traversed edge → source chunk → answer claim trace가 있어야 한다. 그래프 경로가 있다고 자동으로 설명 가능한 것은 아니다. edge가 어느 원문에서 생성됐는지 되돌아갈 수 있어야 한다.
6. 구현: PoC에서 Production까지
Step 0. 질문에서 시작한다
문서를 먼저 몽땅 graph로 바꾸지 말고 실제 질문 100~300개를 분류한다.
- 단일 문서 fact lookup
- 두 개체 비교
- 2~4 hop 관계 추론
- 전체 corpus 집계·테마
- 특정 시점 기준의 관계
multi-hop·global 질문 비율이 작으면 GraphRAG가 아니라 hybrid search와 reranker를 먼저 개선하는 편이 낫다.
Step 1. 최소 ontology를 정의한다
Node types
- Product(product_code, name, effective_from, effective_to)
- Rider(rider_code, version)
- Clause(clause_id, article_no, effective_period)
- Regulation(regulation_id, authority, version)
- ClaimRule(rule_id, decision_type)
Edge types
- Product -[:INCLUDES]-> Rider
- Rider -[:GOVERNED_BY]-> Clause
- Clause -[:AMENDED_BY]-> Regulation
- ClaimRule -[:SUPPORTED_BY]-> Clause
- Node -[:MENTIONED_IN {page, span, confidence}]-> TextUnit노드 타입을 50개부터 시작하지 않는다. 질문을 답하는 데 필요한 5~10개 node type과 10~20개 relation type으로 출발한다. 모든 node와 edge에는 source_id, evidence_span, valid_from/to, extractor_version, confidence를 붙인다.
Step 2. 추출은 LLM 하나에게 전부 맡기지 않는다
규칙·마스터 테이블로 상품코드/날짜/조항번호 추출
+ NER/LLM으로 자유 텍스트 엔티티·관계 후보 생성
+ schema validator와 master-data lookup
+ 중요 edge는 사람 승인 또는 deterministic verification
Step 3. Graph와 원문을 함께 저장한다
그래프 DB가 반드시 필요한 것은 아니다.
| 선택 | 적합한 경우 | 주의점 |
|---|---|---|
| Neo4j | 깊은 traversal, Cypher, graph algorithm이 핵심 | 추가 운영·라이선스·보안 검토 |
| PostgreSQL + pgvector | 기존 DB 활용, temporal/ACL/filter가 중요 | 매우 깊은 graph algorithm은 불편 |
| Azure AI Search + Graph store | 검색은 AIS, 관계 확장만 graph로 분리 | 동기화와 ID 일관성 필요 |
| 파일/Parquet 기반 GraphRAG | 연구·배치 PoC, 빠른 검증 | 동시성·증분 갱신·권한이 약함 |
Step 4. Retrieval은 hybrid하게 구성한다
def retrieve(query, user_context):
mode = route_query(query) # basic/local/global/drift
filters = build_acl_temporal_filter(user_context)
seeds = hybrid_entity_search(query, filters) # BM25 + vector
paths = expand_graph(
seeds,
max_hops=3,
allowed_relations=relation_policy(query),
valid_at=user_context.as_of_date
)
chunks = fetch_source_chunks(paths, filters)
evidence = rerank_and_deduplicate(query, chunks, paths)
return pack_context_with_provenance(evidence)Cypher 예시
MATCH (p:Product {code: $product_code})-[:INCLUDES]->(r:Rider)
MATCH (r)-[:GOVERNED_BY]->(c:Clause)
WHERE c.valid_from <= date($enrollment_date)
AND (c.valid_to IS NULL OR c.valid_to > date($enrollment_date))
MATCH (c)-[:MENTIONED_IN]->(t:TextUnit)
WHERE t.access_level IN $allowed_levels
RETURN p, r, c, t
ORDER BY c.article_no여기서 핵심은 vector similarity가 아니라 가입일과 권한을 traversal 전에 강제한다는 점이다. LLM에게 “알아서 2024년 약관을 고르라”고 프롬프트로 부탁하지 않는다.
7. GraphRAG는 무엇을 트레이닝해야 하나
GraphRAG 도입에 LLM fine-tuning은 필수가 아니다. 대부분은 기존 LLM을 이용한 추출·요약·검색 파이프라인 구축이다. “학습”보다 먼저 필요한 것은 ontology, canonical dictionary, source-grounded edge와 평가셋이다.
| 영역 | 트레이닝 필요성 | 필요 데이터 |
|---|---|---|
| Entity/Relation Extraction | 초기에는 prompt, 규모·일관성 이슈 시 fine-tune | 문장 + entity span/type + relation + evidence |
| Entity Resolution | 규칙·dictionary 우선, 필요 시 pair classifier | 동일/상이 entity pair, hard negative |
| Embedding | 도메인 용어 recall이 낮을 때만 | query-positive-hard negative triplet |
| Reranker | 효과가 큰 편 | 질문-문서/경로 relevance label |
| Query Router | 규칙/LLM부터, 운영 로그 축적 후 분류기 | 질문 + best mode + 비용/정확도 결과 |
| Answer LLM | 대부분 불필요 | 말투보다 grounded response template이 먼저 |
금융권에서는 고객 원문으로 LLM 전체를 fine-tune하는 것보다, 비식별 도메인 문서로 extraction/reranking을 개선하고 개인별 정보는 query-time filter로 결합하는 편이 통제와 삭제 대응이 쉽다. 모델 가중치에 고객정보를 넣으면 특정 정보의 삭제·정정·추적이 훨씬 어려워진다.
8. 어떤 데이터가 필요한가
- 원천 문서: 약관, 상품설명서, 업무규정, 심사지침, 개정 공문, FAQ
- Master data: 상품·특약 코드, 정식명, 별칭, 유효기간, 상위/하위 구조
- 관계 gold set: 어떤 조항이 어떤 상품·규칙과 연결되는지 전문가 검수
- 질문 gold set: 단일·비교·multi-hop·global·temporal 질문과 정답 근거
- Negative data: 이름은 유사하지만 다른 상품, 폐기 문서, 적용일이 다른 약관
- 운영 feedback: 검색 누락, 잘못된 edge, 상담사 override와 정정 이력
특히 hard negative가 중요하다. “정답과 완전히 무관한 문서”보다 상품명은 같지만 시행일이 다른 약관, 비슷한 특약명이지만 다른 상품군이 실제 금융 검색을 어렵게 만든다.
9. 가명처리: 이름만 지우면 끝이 아니다
Graph는 관계를 연결하기 때문에 표 형태 데이터보다 재식별 위험이 커질 수 있다. 이름·주민번호를 지워도 지점, 희귀질환, 가입일, 고액 청구, 가족관계가 결합되면 개인을 유추할 수 있다. 개인정보보호위원회는 2026년 3월 개정 가명정보 처리 가이드라인을 공개하고 있다.
권장 가명처리 절차
- 목적·법적 근거 확정: 통계작성·과학적 연구·공익적 기록보존 등 가명정보 활용 목적에 해당하는지, 신용정보법상 처리 근거와 별도 동의가 필요한지 검토한다.
- Data inventory: 직접식별자, 준식별자, 민감정보, 개인신용정보, 고유식별정보를 분류한다.
- 최소화: 그래프 목적에 필요 없는 필드와 edge는 수집하지 않는다. 고객 개인 그래프 없이도 약관 지식그래프를 만들 수 있다면 고객정보를 넣지 않는다.
- 가명처리: 삭제, 토큰화, 범주화, 날짜 일반화, 총계처리 등을 조합한다. 연결키는 별도 보관하고 graph DB에는 직접식별자를 넣지 않는다.
- 재식별 위험 평가: singling out, linkability, inference 가능성을 공격자 관점에서 평가한다.
- 적정성 검토·승인: 목적, 데이터, 처리기법, 잔여위험, 접근자를 문서화하고 사내 절차에 따라 승인한다.
- 분리·접근통제: 추가정보를 분리 보관하고 권한, 접속기록, 반출·재결합 통제를 적용한다.
- 종료·파기: 목적 달성, 보유기간 종료, PoC 종료 시 원본·그래프·embedding·cache·backup까지 범위를 정해 파기한다.
① 가명정보도 개인정보다. 안전조치와 목적 제한이 사라지지 않는다.
② 해시 처리했다고 무조건 익명정보가 아니다. 좁은 후보군은 대입 공격이 가능하다.
③ embedding도 안전하다고 단정할 수 없다. 원문 유추, membership inference, 삭제 불일치를 별도로 검토해야 한다.
상품·특약·약관·규정
직접식별자 없음
본인·목적·권한·시점 검증
허용된 subgraph만 조회
가입일·상품코드·동의
query-time 최소 전달
10. 금융권 컴플라이언스에서 받아야 할 것
회사마다 결재 체계가 다르지만 GraphRAG PoC와 운영 전환에서는 대체로 다음 검토가 필요하다.
| 검토 | 핵심 질문 | 산출물 |
|---|---|---|
| 개인정보·신용정보 | 처리 근거, 목적, 최소화, 제3자/위탁, 국외이전 | Data map, 법적근거, 가명처리 계획·적정성 검토 |
| AI 거버넌스 | AI기본법·고영향 여부, 사람 감독, 이용자 고지 | AI impact assessment, system card, RACI |
| Model Risk | 추출·검색·생성 오류와 독립 검증 | Validation report, limitation, threshold 승인 |
| 정보보호 | 망구성, 계정·권한, 암호화, prompt injection, 반출 | 보안성 검토, threat model, 침투·레드팀 결과 |
| Cloud·위탁 | 서비스 지역, 학습 사용 여부, subprocessors, 로그 보존 | 계약/DPA, architecture, 데이터 흐름·삭제 확인 |
| 현업·준법·법무 | 답변 책임, 소비자 오인, 금지 업무와 escalation | 업무규칙, disclaimer, human review flow |
| 아키텍처·변경관리 | index/ontology/model 변경을 추적·복구 가능한가 | ADR, version manifest, rollback·DR 계획 |
외부 생성형 AI가 가명처리된 개인신용정보를 처리하는 구조라면 “가명했으니 클라우드 전송 가능”으로 끝내면 안 된다. 금융권 망분리 규제 특례·혁신금융서비스 범위, 서비스 제공자의 데이터 학습 사용 여부, 국외 처리·재위탁, 삭제 가능성, 로그와 장애 대응까지 함께 확인해야 한다. 2026년 금융분야 AI 가이드라인은 거버넌스·합법성·보조수단성·신뢰성·금융안정성·신의성실·보안성의 7대 원칙을 제시한다.
11. 금융권 권장 아키텍처
Ingestion Plane: Blob/SharePoint → parser → PII detector/tokenizer → entity/relation extraction → resolution → validation → graph + source chunks
Retrieval Plane: query classification → ACL/temporal filter → hybrid seed search → bounded graph traversal → reranking → evidence packing
Generation Plane: grounded generation → claim/citation verification → uncertainty → human escalation
Audit Plane: source/version · traversed path · policy decision · model/prompt · response · reviewer · feedback
고객별 정보와 공통 지식그래프는 가능하면 분리한다. 약관·상품·규정 graph는 공통 knowledge plane에 두고, 고객 가입정보는 권한 검사를 거친 query-time attribute로 전달해 유효한 subgraph만 조회한다. 고객을 그래프 노드로 대량 축적하면 접근권한, 삭제·정정, 목적 외 결합 위험이 급격히 커진다.
Blob·SharePoint
원문·버전
Function·Container
Parser·PII·Extraction
PostgreSQL
Temporal·ACL·pgvector
Graph Layer
Node·Edge·Path
AI Search
BM25·Vector·Rerank
Azure OpenAI
Route·Generate·Verify
12. 성능 평가는 답변 정확도만 보면 실패한다
| 레이어 | 지표 | 대표 실패 |
|---|---|---|
| Extraction | Entity/Relation precision·recall | 근거 없는 edge |
| Resolution | Merge/Split error rate | 다른 상품 병합 |
| Graph | Dangling edge, provenance coverage | 원문 없는 관계 |
| Retrieval | Path recall@k, evidence recall, hop accuracy | 정답 경로 중간 노드 누락 |
| Answer | Correctness, groundedness, citation support | 맞는 답·틀린 근거 |
| Operations | Index cost, p95 latency, freshness lag | 정확하지만 너무 느림 |
A/B 평가는 반드시 같은 corpus와 같은 answer model로 Hybrid RAG → Hybrid+Reranker → GraphRAG Local → DRIFT/Global을 비교한다. GraphRAG만 더 큰 모델과 더 많은 토큰을 쓰면 그래프의 효과인지 비용의 효과인지 알 수 없다.
13. GraphRAG의 한계
다른 노드로 분리
edge 생성
community 편입
오류 압축
반복 노출
- Indexing 비용: 엔티티·관계·community report 생성에 많은 LLM 호출이 필요하다.
- 오류의 영속화: 잘못 추출한 관계가 DB에 저장되어 여러 답변에 반복 사용된다.
- Entity resolution 병목: 표기 변형, 동명이인, 버전과 시점이 결합되면 급격히 어려워진다.
- 요약 손실: community summary는 큰 그림에 유리하지만 작은 예외 조항을 버릴 수 있다.
- 증분 갱신: 문서 하나가 바뀌면 edge, community, summary의 재계산 범위를 정해야 한다.
- Graph explosion: 모든 명사와 관계를 저장하면 dense하고 의미 없는 그래프가 된다.
- 권한 누출: 허용된 노드에서 비허용 노드로 traversal하며 민감한 관계를 유추할 수 있다.
- 평가 난이도: 최종 답변이 틀렸을 때 extraction, resolution, traversal, reranking, generation 중 어디가 원인인지 추적해야 한다.
14. 언제 써야 하고, 언제 쓰지 말아야 하나
- 관계·경로가 답의 핵심
- 2~4 hop 질문이 자주 발생
- 전체 corpus의 테마·패턴 질문
- 규정·상품·조항 간 상호참조
- 관계 경로를 감사 증거로 활용
- 대부분 단일 FAQ·fact lookup
- 문서가 작고 구조가 단순
- 업데이트가 매우 빈번
- 관계 gold data와 전문가가 없음
- hybrid/reranker도 아직 안 해봄
의사결정 기준
관계 기반 질문 비율이 높은가?
├─ 아니오 → Hybrid Search + Reranker
└─ 예
├─ 전체 corpus 요약이 핵심? → Global / LazyGraphRAG 검토
├─ 특정 entity multi-hop? → Local / HippoRAG 계열 검토
└─ 둘 다? → Router + DRIFT/Adaptive Retrieval
PoC에서 정확도·비용·지연 개선이 유의미한가?
├─ 아니오 → GraphRAG를 도입하지 않는 것도 성공
└─ 예 → ACL·temporal·provenance·incremental update 후 운영Metadata Filter
Hybrid Search
Reranker
Entity Expansion
Full GraphRAG
15. 6주 PoC 로드맵
- 1주차: 실제 질문 150개 분류, baseline hybrid RAG 측정
- 2주차: 한 상품군, node 5~8종, relation 10~15종 ontology 정의
- 3주차: 추출·resolution pipeline과 300개 edge gold set 구축
- 4주차: Local graph expansion + 원문 reranking 구현
- 5주차: temporal/ACL filter, citation trace, failure dashboard 구현
- 6주차: baseline 대비 정확도·p95·비용·운영복잡도 평가 후 Go/No-Go
첫 PoC에서 전체 보험상품을 넣지 않는다. 관계가 복잡하고 질문이 충분한 한 상품군을 고른다. 성공 기준도 “그래프 생성 완료”가 아니라 multi-hop evidence recall 개선, critical error 감소, 감당 가능한 indexing cost로 잡는다.
마치며
개인적으로 GraphRAG를 공부할수록 ingestion의 중요성이 더 크게 보인다. 검색 알고리즘이 똑똑해도 잘못 합쳐진 엔티티와 근거 없는 edge 위에서는 더 자신 있게 틀릴 뿐이다. 결국 GraphRAG의 경쟁력은 그래프 DB 제품보다 도메인 ontology, temporal metadata, entity resolution, 평가와 검증 체계에서 나온다. 금융권에서는 여기에 개인정보와 권한 경계까지 포함해야 비로소 ‘운영 가능한 GraphRAG’가 된다.
논문 및 공식 자료
- Edge et al. — From Local to Global: A Graph RAG Approach to Query-Focused Summarization
- Microsoft GraphRAG 공식 문서
- Microsoft GraphRAG GitHub
- Microsoft Research — LazyGraphRAG
- LightRAG 공식 구현
- Gutiérrez et al. — From RAG to Memory: HippoRAG 2
- Zhao et al. — E²GraphRAG
- Wang et al. — XGraphRAG
- 개인정보보호위원회 — 가명정보 처리 가이드라인(2026.3.)
- 생성형 AI 개발·활용을 위한 개인정보 처리 안내서
- 금융위원회 — 금융분야 인공지능 가이드라인