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