RAG를 붙이면 환각이 줄어든다고 했다. 분명히 줄긴 했다. 그런데 없어지지는 않았다.
LangGraph 기반 RAG 시스템을 직접 운영하면서 가장 자주 들은 피드백이 “왜 이 질문에는 제대로 답을 못 하지?”였다. 단순한 사실 조회는 잘 됐다. 그런데 조금만 복잡해지면 흔들렸다. 여러 개체의 관계를 엮어서 추론해야 하는 질문, 전체 데이터에서 패턴을 찾아야 하는 질문에서 벡터 검색 기반 RAG는 근본적인 한계를 드러냈다.
그 한계가 어디서 오는지를 이해하게 된 순간, GraphRAG라는 접근 방식이 왜 나왔는지가 자연스럽게 따라왔다.
벡터 RAG가 “왜”를 모르는 이유
벡터 기반 RAG의 작동 방식을 다시 짚어보면, 문서를 청크로 잘라서 임베딩 벡터로 변환하고, 질문도 같은 방식으로 벡터화한 다음, 유사도가 높은 청크를 뽑아서 LLM 프롬프트에 넣는 구조다. 여기서 핵심은 “얼마나 비슷한가”다. 의미적으로 가까운 텍스트를 찾는 데는 강하다.
문제는 이 방식이 “얼마나 연결돼 있는가”를 전혀 보지 못한다는 점이다. A 문서와 B 문서가 서로 다른 개체를 다루고 있더라도, 그 두 개체 사이의 관계가 답변의 핵심이라면 벡터 유사도만으로는 그 관계를 건져낼 수가 없다.
직접 겪은 상황을 얘기하면 이렇다. “이 프로젝트 담당자가 지난 분기에 진행한 다른 프로젝트와 예산이 겹치는 부분이 있나?”라는 질문에 RAG 시스템은 관련 문서를 가져오긴 했는데, 답이 엉뚱하게 나왔다. 문서를 찾는 건 됐는데 그 문서들 사이의 관계를 연결하지 못한 거였다.
청킹 전략을 아무리 정교하게 만들어도 이 문제는 남았다. 청크를 잘게 자르면 앞뒤 문맥이 끊기고, 크게 잡으면 검색 정확도가 떨어진다. 어느 쪽으로 가도 손해가 생기는 구조였다. 이게 벡터 RAG가 태생적으로 갖고 있는 한계다.
GraphRAG가 다르게 보는 것
GraphRAG는 2024년 마이크로소프트 리서치에서 오픈소스로 공개되면서 주목받기 시작했다. 핵심 아이디어는 문서에서 개체와 관계를 추출해서 지식 그래프로 만들고, 검색할 때 벡터 유사도와 그래프 탐색을 함께 쓰는 것이다.
사내 문서에 “김민준 팀장은 2024년 AI 인프라 프로젝트를 담당했고, 이 프로젝트는 클라우드 전환 예산과 연동됐다”는 내용이 있다고 하자. 벡터 RAG는 이 문장을 청크로 저장한다. GraphRAG는 여기서 “김민준 → 담당 → AI 인프라 프로젝트”, “AI 인프라 프로젝트 → 연동 → 클라우드 전환 예산”이라는 노드와 엣지로 구조화한다.
이렇게 하면 “김민준 팀장이 관련된 예산 항목은 뭔가”라는 질문이 들어왔을 때, 그래프를 따라가면서 관계를 추적할 수 있다. 직접 연결된 관계뿐 아니라 두세 단계 떨어진 간접 관계도 탐색할 수 있다. 이걸 multi-hop reasoning이라고 부르는데, 벡터 검색만으로는 구조적으로 하기 어려운 영역이다.
전역 검색도 달라진다. 지식 그래프에서 클러스터링으로 전체 데이터의 주요 주제나 패턴을 파악할 수 있어서, “이 조직의 AI 프로젝트 전반적인 흐름이 어떤가” 같은 질문에 요약적으로 답할 수 있다. 벡터 검색이 특정 문서를 집어내는 데 강하다면, GraphRAG의 전역 검색은 전체 그림을 보는 데 강하다.
환각이 실제로 얼마나 줄어드는가
수치로 얘기하면, 기존 LLM만 쓸 때 환각 발생률이 15~20% 수준이라면 벡터 RAG를 붙이면 약 3%로 줄어든다. 여기에 GraphRAG를 적용하면 1% 수준까지 더 내려간다는 결과가 있다. 이 차이가 어디서 나오냐면, 답변의 근거가 되는 정보가 벡터 유사도가 아니라 구조화된 관계로 연결돼 있기 때문이다. LLM이 근거 없이 지어내기 어렵게 만드는 구조적 설계 덕분이다.
다만 이 수치를 무조건 믿는 건 위험하다. GraphRAG는 복잡한 관계 추론이 필요한 질문에서 강하고, 단순 사실 조회에서는 벡터 RAG와 성능 차이가 크지 않다. 2025년에 두 방식을 직접 비교한 실험에서도 단일 hop 질문에서는 기존 RAG가 우세했고, multi-hop 추론과 전역 패턴 파악에서는 GraphRAG가 앞섰다. 결국 어떤 질문이 많은 도메인인지가 선택의 기준이 된다.
Graphwise가 이 영역에서 하는 일
Graphwise는 GraphRAG 아이디어를 엔터프라이즈 현장에 적용한 플랫폼이다. Semantic Web Company와 Ontotext가 합병해서 만든 회사인데, 두 곳 모두 2000년대 초부터 지식 그래프와 온톨로지를 연구해온 곳이라 기술 기반이 탄탄하다. BBC, Microsoft, AstraZeneca가 실제 고객이라는 점도 그냥 넘어가기 어렵다.
GraphRAG를 직접 구현하려면 지식 그래프 구축 파이프라인을 따로 만들고, GraphDB 같은 그래프 데이터베이스를 설치·운영하고, 벡터 검색과 그래프 탐색을 결합하는 검색 레이어를 설계해야 한다. 온톨로지 설계 자체가 도메인 전문 지식을 요구하고, 관계 추출 파이프라인의 품질이 전체 시스템 정확도를 결정한다. 이게 만만치 않다.
Graphwise는 이 복잡한 과정을 플랫폼으로 제공한다. 문서를 올리면 자동으로 개체와 관계를 추출해서 지식 그래프를 만들고, 이를 기반으로 GraphRAG 검색이 동작하게 해준다. 직접 구축하려면 한참 걸릴 인프라를 쓸 수 있는 상태로 가져다 준다는 게 핵심 가치다.
그럼 벡터 RAG는 이제 쓸모가 없나
그렇지 않다. GraphRAG가 벡터 RAG를 완전히 대체하는 방향으로 가지는 않는다. 실무에서는 두 가지를 같이 쓰는 하이브리드 구조가 현실적이다.
단순한 사실 조회나 키워드 기반 검색은 벡터 RAG가 빠르고 효율적이다. 인프라도 단순하고 운영 비용도 낮다. 반면 여러 개체의 관계를 추론해야 하거나 전체 데이터에서 패턴을 파악해야 하는 질문에서는 그래프 탐색이 필요하다.
Graphwise를 포함한 GraphRAG 플랫폼들도 벡터 검색을 버리는 게 아니라, 벡터 검색으로 후보를 좁히고 그래프 탐색으로 관계를 연결하는 구조를 택한다. 두 방식의 강점을 상황에 따라 나눠 쓰는 거다.
내가 운영하는 LangGraph 에이전트에서도 Qdrant로 벡터 검색을 하고 BM25로 키워드 검색을 보강하는 구조를 쓰는데, 여기에 그래프 레이어를 더하는 게 GraphRAG로 가는 방향이다. 인프라가 하나 더 늘어나는 부담은 있지만, 복잡한 관계 추론이 핵심인 도메인에서는 그 부담이 충분히 정당화된다.
검색 정확도의 다음 단계는 구조화다
RAG를 처음 도입하는 팀은 대부분 벡터 기반으로 시작한다. 구현이 빠르고 결과가 바로 보이기 때문이다. 그런데 실제로 쓰다 보면 “왜 이 질문에는 제대로 답을 못 하지”라는 순간이 반드시 온다.
그 순간이 오면 두 가지 선택지가 있다. 청킹 전략을 더 정교하게 다듬거나, 검색 방식 자체를 바꾸거나. 청킹을 아무리 고도화해도 해결이 안 되는 문제가 있는데, 바로 개체 간 관계 추론이다. 이 문제에 부딪혔을 때 GraphRAG로 가는 결정이 맞다.
지식 그래프를 백본에 두고 AI를 얹는 방식이 엔터프라이즈에서 주목받는 이유가 여기 있다. 문서에서 지식을 추출해서 관계로 연결해두면, 사람이 바뀌어도 그 사람이 갖고 있던 맥락과 관계 정보가 시스템 안에 남는다. 단순히 검색 정확도를 높이는 것을 넘어, 조직의 지식 자산을 구조화하는 방향이다. RAG가 외부 지식을 LLM에 주입하는 기술이라면, GraphRAG는 그 지식이 서로 어떻게 연결되는지를 함께 주입하는 기술이다. 이 차이가 복잡한 질문 앞에서 결정적으로 갈린다.