RAG+지식그래프: LLM 에이전트 추론 아키텍처

RAG의 한계를 넘어서: 지식 그래프(KG)로 LLM 에이전트의 추론 능력을 극대화하는 아키텍처 설계 가이드

최근 LLM 기반 에이전트 시스템의 발전 속도는 경이롭습니다. 특히 검색 증강 생성(RAG)은 외부 문서를 참조하여 답변의 근거를 제시함으로써, LLM의 가장 큰 약점인 '환각(Hallucination)'을 획기적으로 줄였습니다. 하지만 현업의 복잡한 비즈니스 로직을 마주할 때, 우리는 종종 RAG만으로는 해결할 수 없는 벽에 부딪힙니다. 바로 **'관계 추론(Reasoning)'**의 영역입니다.

이 글은 단순한 '정보 검색'을 넘어, 세상의 지식을 구조화하고 복잡한 논리적 연결고리를 따라가며 추론하는, 진정한 의미의 '전문가 시스템'을 LLM 에이전트에 구현하는 심화 아키텍처를 다룹니다. 그 핵심 도구가 바로 **지식 그래프(Knowledge Graph, KG)**입니다.

RAG가 놓치는 것: 정보 검색과 관계 추론의 근본적 차이

RAG는 본질적으로 '문서 조각(Chunk)' 단위의 유사도 검색에 최적화되어 있습니다. 사용자가 "지난 분기 마케팅팀의 A 캠페인과 관련된 B 제품의 리스크는 무엇인가?"라고 질문했을 때, RAG는 이 질문과 관련된 문서들을 검색하여 답변을 조합합니다. 이는 마치 방대한 백과사전에서 키워드가 포함된 여러 페이지를 모아주는 것과 같습니다.

하지만 실제 비즈니스 문제는 이보다 훨씬 복잡합니다. "A 캠페인에 참여했던 팀원 중, B 프로젝트와 과거에 협업한 이력이 있고, 최근 리스크 보고서에 언급된 담당자는 누구인가?"와 같은 질문은 단순한 문서 검색만으로는 답을 찾을 수 없습니다. 이 질문은 **'팀원' $\rightarrow$ '캠페인 참여' $\rightarrow$ '프로젝트 연관성' $\rightarrow$ '리스크 보고서 언급'**이라는 다단계의 구조적 연결고리를 따라가야만 답이 나옵니다.

이러한 구조적 연결고리를 명시적으로 모델링하고 쿼리할 수 있게 해주는 것이 바로 지식 그래프입니다. KG는 지식을 **노드(Node, 개체)**와 **엣지(Edge, 관계)**로 구조화하여, 세상의 모든 정보를 '연결된 관계'의 형태로 저장합니다.

지식 그래프 기반 에이전트의 심장: 아키텍처 설계 원칙

KG를 활용하는 에이전트는 단순한 검색기를 넘어, **'계획-실행-검증'**의 사이클을 갖춘 추론 엔진으로 작동합니다. 이 과정은 다음과 같은 워크플로우로 설계됩니다.

[에이전트 추론 워크플로우 다이어그램 (텍스트 묘사)]

1. 사용자 질문 입력: (예: "최근 가장 리스크가 높은 담당자는?")
2. LLM 계획 수립 (Planning): LLM이 질문을 분석하여, 이 질문에 답하기 위해 필요한 논리적 단계와 필요한 데이터 구조를 추론합니다. (예: "담당자 $\rightarrow$ 프로젝트 $\rightarrow$ 리스크 점수 순서로 쿼리해야 한다.")
3. 쿼리 생성 (Query Generation): LLM은 추론된 계획을 기반으로, 그래프 데이터베이스가 이해할 수 있는 언어(Cypher)의 쿼리를 생성합니다.
4. DB 실행 (Execution): 생성된 Cypher 쿼리가 Neo4j와 같은 그래프 DB에 전달되어 실행됩니다. DB는 관계를 따라가며 정확한 구조화된 결과(JSON 또는 테이블 형태)를 반환합니다.
5. 결과 해석 및 답변 생성 (Interpretation): LLM은 DB가 반환한 구조화된 결과(Raw Data)를 받아, 이를 다시 자연어 문맥으로 해석하고, 사용자 친화적인 최종 답변을 생성합니다.

이 과정에서 가장 중요한 것은 2단계와 3단계의 'LLM $\rightarrow$ Cypher' 변환 능력입니다.

핵심 기술 구현: LLM과 Cypher를 연결하는 패턴

LLM에게 '쿼리 생성기' 역할을 부여하는 것이 이 아키텍처의 핵심입니다. 우리는 LLM이 추론한 의도를 가장 정확한 코드로 변환하도록 유도해야 합니다.

1. 복잡한 관계를 쿼리하는 Cypher 예시

다음은 "특정 부서에 속하며, A 프로젝트에 참여했고, 그 프로젝트와 연결된 모든 리스크를 가진 담당자"를 찾는 복잡한 경로 탐색 쿼리입니다.

MATCH (d:Department {name: '마케팅'})<-[:WORKS_FOR]-(p:Person)-[:WORKS_ON]->(proj:Project {name: '신제품 런칭'})
MATCH (p)-[:HAS_ROLE]->(r:Role)
WHERE r.level = '시니어'
RETURN p.name, r.level, proj.name

이 쿼리는 단순한 검색을 넘어, '어떤 관계를 거쳐서' 원하는 대상을 찾아내는 복잡한 추론을 가능하게 합니다.

2. 프롬프트 엔지니어링을 통한 구조화된 출력 유도

LLM에게 "너는 그래프 데이터베이스 쿼리 전문가다. 다음 요구사항을 만족하는 Cypher 쿼리만 출력해라. 다른 설명은 절대 붙이지 마라."와 같은 **역할 부여(Role-playing)**와 **출력 형식 강제(Output Constraint)**를 통해, LLM이 원하는 구조화된 쿼리만 생성하도록 유도하는 것이 가장 중요합니다.

결론적으로, RAG(Retrieval-Augmented Generation)가 '문서'를 검색한다면, 이 방식은 **'관계(Relationship)'**를 검색합니다. 이 구조적 검색 능력이 바로 기업의 복잡한 지식 그래프(Knowledge Graph)를 활용하는 핵심 열쇠입니다.

언제 KG인가

query → vector retrieve
      → entity link → graph traverse
      → evidence pack → LLM

그래프 질의가 틀린 답을 낼 때: 원인과 검증

LLM이 자연어를 Cypher로 바꾸는 구조에서는, 답이 틀렸을 때 원인이 질의 생성·그래프 데이터·답변 생성 중 어디인지 나눠 봐야 합니다.

원인

• 스키마에 없는 관계 이름이나 방향을 LLM이 만들어 내 빈 결과가 나옴
• 엔터티 이름 표기 불일치(예: "삼성전자" vs "Samsung Electronics")로 노드를 찾지 못함
• 질의 결과는 맞는데 LLM이 결과를 요약하면서 사실을 덧붙임

검증 방법

1. 생성된 Cypher를 로그로 남기고, 실패 사례는 직접 실행해 결과를 확인합니다.
2. 실행 전에 EXPLAIN으로 문법과 스키마 일치를 확인합니다.

// 스키마에 실제로 존재하는 관계 타입 확인
CALL db.relationshipTypes() YIELD relationshipType RETURN relationshipType;
// 생성된 질의를 실행하지 않고 계획만 확인
EXPLAIN MATCH (c:Company {name: $name})-[:SUPPLIES]->(p:Product) RETURN p.name;

해결

• 프롬프트에 스키마(노드 라벨, 관계 타입, 방향, 속성)를 명시하고, 생성된 질의에서 쓰인 관계 타입이 db.relationshipTypes() 결과에 있는지 코드로 검사합니다.
• 엔터티 연결 단계(이름 정규화, 별칭 테이블, 전문 검색 인덱스)를 질의 생성 앞에 둡니다.
• 쓰기 질의(CREATE, MERGE, DELETE)는 읽기 전용 사용자로 실행해 원천 차단합니다.

재발 방지

• 질문·기대 Cypher·기대 결과를 묶은 테스트 세트를 만들어, 프롬프트·모델 변경 시 질의 정확도를 다시 측정합니다.

참고 자료

• Neo4j LLM graph
• LangChain KG QA

검증 환경·편집자 주

• GSC 보호. 2026-09 보강. KG 구축 비용이 RAG보다 큼.

자주 묻는 질문 (FAQ)

Q. 처음부터 KG를 만들어야 하나요?
아니요. RAG 실패 패턴(관계 질의)이 보일 때 부분 도입하세요.