GraphRAG·지식그래프 구축 가이드 2026 — 온톨로지로 벡터 RAG 한계 넘기

GraphRAG는 문서를 벡터 유사도로만 찾는 대신, 도메인 온톨로지와 지식그래프로 엔티티와 관계를 구조화해 두고 그 그래프를 함께 탐색하는 검색 아키텍처입니다. 벡터 RAG를 프로덕션에 올려본 팀이 마주치는 두 가지 벽 — 관계를 못 따라가서 엉뚱한 문단을 근거로 끌어오는 문제, 그리고 답변의 출처를 추적할 수 없는 문제 — 를 구조로 푸는 접근입니다. 이 글은 온톨로지와 지식그래프가 정확히 무엇을 하는지, 어떤 순서로 구축하는지, 그리고 6개월 뒤에 방치되지 않게 하려면 무엇이 필요한지를 정리했습니다.

벡터 RAG는 어디서 막히는가

일반적인 RAG는 문서를 잘게 쪼개 임베딩하고, 질문과 가장 비슷한 조각을 찾아 LLM에 넘깁니다. 대부분의 단순 질의에는 이 방식으로 충분합니다.

막히는 지점은 세 가지입니다.

첫째, 관계를 모릅니다. "A 계열사가 납품한 부품이 들어간 모델 중 리콜된 것"처럼 여러 단계를 건너야 하는 질문에서, 벡터 검색은 각 단어와 비슷한 문단을 가져올 뿐 A와 부품과 리콜을 잇지 못합니다. 유사도는 의미가 비슷한 것을 찾지, 사실이 연결된 것을 찾지 않습니다.

둘째, 같은 개체가 흩어져 있습니다. 문서마다 "㈜나무숲", "나무숲", "TreeSoop"으로 적혀 있으면 벡터 검색은 이를 별개로 취급합니다. 한 회사에 대한 정보가 조각나서 어느 쪽도 완전한 답을 못 만듭니다.

셋째, 근거를 못 짚습니다. 답이 나와도 "이 문단이 비슷해서 가져왔다" 이상을 설명하기 어렵습니다. 규제 산업에서는 이 지점이 도입 자체를 막습니다.

온톨로지와 지식그래프는 각각 무엇인가

두 용어가 섞여 쓰이는데 층이 다릅니다.

온톨로지는 설계도입니다. 이 도메인에 어떤 종류의 개체가 있고(고객·계약·부품·규정), 그들 사이에 어떤 관계가 성립하며(고객—체결→계약), 각 개체가 어떤 속성을 갖는지를 정의한 스키마입니다. W3C OWL 같은 표준이 이 층을 다룹니다.

지식그래프는 그 설계도를 채운 실제 데이터입니다. 문서와 DB에서 개체와 관계를 뽑아 노드와 엣지로 쌓은 것입니다.

설계도 없이 그래프부터 만들면 개체 종류가 제멋대로 늘어나 나중에 정리가 안 됩니다. 순서가 중요한 이유입니다.

GraphRAG는 벡터 RAG와 무엇이 다른가

모든 RAG를 GraphRAG로 바꿀 필요는 없습니다. 사내 위키 검색처럼 단순 질의가 대부분이면 벡터로 충분하고, 온톨로지 설계 공수만 늘어납니다. 관계를 따라가야 답이 나오거나 근거 추적이 요구되는 도메인에서 값을 합니다.

오픈소스 구현으로는 Microsoft GraphRAG가 널리 쓰이고, 그래프DB 관점의 정리는 Neo4j의 GraphRAG 문서가 참고할 만합니다.

지식그래프는 어떤 순서로 구축하는가

나무숲이 프로젝트를 진행하는 순서는 네 단계입니다.

1단계 — 온톨로지 워크숍 (약 1주)

도메인 전문가와 함께 핵심 엔티티·관계·용어 체계를 정의하고 스키마 초안을 확정합니다. 이 단계를 건너뛰고 싶은 유혹이 크지만, 여기서 정리되지 않은 개념은 이후 전 단계에서 반복해서 발목을 잡습니다.

2단계 — 지식그래프 구축과 엔티티 해소

문서와 DB에서 엔티티·관계를 추출해 그래프로 쌓습니다. 이때 핵심이 엔티티 해소(entity resolution) — 문서 전반에 흩어진 같은 개체를 하나로 통합하는 작업입니다. 이게 안 되면 그래프가 커져도 답은 여전히 조각납니다.

3단계 — GraphRAG 통합

벡터 검색과 그래프 순회를 결합한 하이브리드 파이프라인을 LLM·에이전트와 연결하고, 답변마다 그래프 경로로 근거가 추적되는지 검증합니다.

4단계 — 거버넌스 이관

anti-drift 모니터링과 스키마 변경 반영 자동화, 운영 대시보드를 함께 넘깁니다. 이 단계가 왜 필요한지는 아래에서 따로 다룹니다.

프로덕션에서 무너지는 세 가지 패턴

파일럿은 되는데 운영이 안 된다

데모용 문서 수십 건으로는 잘 돕니다. 운영 규모에서는 데이터 정합성, 권한, 갱신 주기가 한꺼번에 걸립니다. 내부에 그래프·온톨로지 경험이 없으면 이 구간에서 멈춥니다.

온톨로지 drift — 6개월 뒤 아무도 소유하지 않는다

가장 흔한 실패입니다. 초기 구축 후 조직이 바뀌고 새 개체 종류가 생기는데 스키마는 그대로 남습니다. 유지·개선 책임자가 지정돼 있지 않으면 지식그래프가 서서히 낡아 검색 품질이 무너집니다. 구축 계약과 별개로 누가 스키마를 소유하는지를 먼저 정해야 합니다.

그래프만 만들고 검색에 연결하지 않는다

그래프 구축 자체가 목적이 되어 버리는 경우입니다. 그래프는 검색·추론에 쓰일 때 값을 하지, 존재만으로는 아무것도 하지 않습니다. 어떤 질문에 답하려고 만드는지를 1단계에서 고정해야 합니다.

134~167 단어 자립형 답변: GraphRAG란 무엇인가?

GraphRAG(그래프 기반 검색 증강 생성)는 문서를 벡터 유사도로만 검색하는 기존 RAG와 달리, 도메인 온톨로지와 지식그래프로 엔티티와 관계를 구조화해 두고 그래프 순회와 벡터 검색을 함께 사용하는 아키텍처입니다. 온톨로지는 어떤 개체와 관계가 존재하는지를 정의한 스키마이고, 지식그래프는 그 정의를 문서·DB에서 추출한 실제 데이터로 채운 것입니다. 벡터 RAG는 의미가 비슷한 문단을 찾을 뿐 사실이 연결된 경로를 따라가지 못하므로, 여러 단계를 건너야 하는 질문에서 부정확한 근거를 제시합니다. GraphRAG는 관계를 따라 답에 도달하고 그 경로를 근거로 제시할 수 있어 규제 산업처럼 출처 추적이 요구되는 환경에 적합합니다. 구축은 온톨로지 워크숍, 엔티티 해소를 포함한 지식그래프 구축, 하이브리드 검색 통합, 거버넌스 이관의 네 단계로 진행하며, 단순 문답 위주라면 벡터 RAG로 충분합니다.

관련 서비스

나무숲은 AI-Native Team으로, 팀원 전원이 Claude Code Max 플랜을 기본 개발 환경으로 사용합니다. RAG 프로젝트를 여러 건 수행하며 벡터 검색의 한계를 실제로 겪은 위에 온톨로지 그라운딩을 얹는 방식으로 접근합니다. 진행 방식은 AI-Native 개발 방식에서 확인하실 수 있습니다.

• 지식그래프·GraphRAG 구축 — 온톨로지 설계부터 거버넌스 이관까지
• AI 챗봇 — RAG 기반 사내 문서 검색
• 벡터 RAG 자체의 도입 판단은 RAG 시스템 도입 전 꼭 알아야 할 3가지에 정리했습니다.

자주 묻는 질문

Q. 기존 벡터 RAG를 GraphRAG로 갈아엎어야 하나요?

아닙니다. 대부분은 병행합니다. 단순 질의는 벡터가 빠르고 저렴하므로, 관계를 따라가야 하는 질의 유형만 그래프 경로로 보내는 하이브리드가 현실적입니다.

Q. 온톨로지 설계에 얼마나 걸리나요?

도메인 복잡도에 따라 다르지만 핵심 엔티티·관계를 잡는 워크숍은 대개 1주 안에 초안이 나옵니다. 오래 걸리는 쪽은 설계가 아니라 그다음의 엔티티 해소입니다.

Q. 그래프DB를 꼭 도입해야 하나요?

규모에 따라 다릅니다. 노드가 수만 건 수준이면 기존 RDB에 관계 테이블로도 시작할 수 있고, 다단계 순회가 잦고 규모가 커지면 그래프DB가 유리해집니다. 먼저 질의 유형을 확정한 뒤 결정하세요.

Q. 문서가 정리돼 있지 않은데 시작할 수 있나요?

가능하지만 엔티티 해소 공수가 늘어납니다. 표기가 제각각인 개체를 통합하는 작업이 전체 일정에서 가장 큰 변수이므로, 견적 단계에서 이 범위를 명시적으로 다루는 편이 안전합니다.

Q. 환각이 완전히 사라지나요?

사라지지 않습니다. 줄어들고, 무엇보다 틀렸을 때 어디서 틀렸는지 추적할 수 있게 됩니다. 근거 경로가 남는다는 점이 규제 대응에서 실질적인 차이를 만듭니다.

Q. 구축 후 누가 유지하나요?

계약 단계에서 정해야 합니다. 스키마 변경 반영과 신규 엔티티 편입을 누가 어떤 주기로 하는지가 문서에 없으면 6개월 뒤 방치됩니다. 이관 범위에 운영 대시보드와 모니터링이 포함되는지 확인하세요.

---

*글쓴이: 남대현 | TreeSoop CEO, POSTECH 컴퓨터공학 AI/MR/HCI 석사*