지금까지 벡터 DB 기반 RAG를 배웠습니다. 이번에는 그래프의 관계 정보를 검색과 답변에 활용하는 GraphRAG를 살펴봅니다. 여러 대상을 연결해야 답이 나오는 질문에 유용하지만, 그래프를 만들었다고 업무 실행 권한이 생기지는 않습니다. 앞부분에서는 관계 검색을 배우고, 뒷부분의 가상 교육 문의 실습에서는 업무 대상과 허용 행동을 따로 정의해봅니다.
먼저 복습 — 벡터 RAG는 어떻게 작동했나
벡터 RAG는 '문서를 잘게 쪼개 숫자(벡터)로 바꿔 저장해두고, 질문과 가장 비슷한 조각을 꺼내 LLM에 함께 넣어주는' 방식이었습니다. 구축과 질의를 한 줄로 그리면 이렇습니다.
벡터 RAG 파이프라인 — 구축과 질의
- 문서 로드 (Load) 원본 데이터를 불러온다
- 청킹 (Split) 긴 문서를 작은 조각(청크)으로 자른다
- 임베딩 (Embed) 각 청크를 의미 벡터(숫자)로 변환
- 벡터 저장 (Store) 벡터 DB에 적재
- 질문 임베딩 사용자 질문도 같은 방식으로 벡터화
- 유사도 검색 (Top-K) 가장 가까운 청크 K개를 꺼낸다
- 증강 + 생성 질문 + 검색된 청크를 LLM에 함께 전달해 답변
강력하지만, 이 구조에는 두 가지 구조적 한계가 숨어 있습니다 — 청킹과 Top-K.
한계 1 — 청킹이 문맥을 끊는다
문서를 조각내는 과정에서 '이어져야 할 문맥'이 서로 다른 청크로 흩어질 수 있습니다. 은행 수수료 규정이 세 청크로 나뉜 상황을 봅시다.
- 청크 ① — VIP 고객은 수수료 면제 대상이다.
- 청크 ② — 단, 해외송금 수수료는 면제 대상이 아니다.
- 청크 ③ — 2025년 3월 이후 가입자가 이 정책의 적용 대상이다.
"2025년 4월 가입한 VIP의 해외송금 수수료는 면제되나요?"
벡터 RAG가 검색한 것 — 청크 ①만
- 질문과 가장 유사한 청크 ① 하나만 검색됨
- "VIP는 수수료 면제" → LLM은 "면제됩니다"라고 답변
- 정답에 꼭 필요한 청크 ②(해외송금 예외)를 놓침
잘못된 답변
실제 정답에 필요한 문맥 — ①+②를 함께
- VIP는 면제가 맞지만, 해외송금은 예외
- 따라서 VIP·4월 가입이어도 해외송금 수수료는 면제 아님
- 여러 조각의 조건을 '연결'해야 정답이 나온다
올바른 답변
청크 크기와 경계에 따라, 정답을 뒤집는 예외 조항이 다른 조각으로 밀려나 검색에서 누락될 수 있습니다.
한계 2 — Top-K가 연결고리를 놓친다
Top-K는 '가장 유사한 K개'만 가져옵니다. 그런데 정답에 필요한 문장이 항상 상위 K개 안에 든다는 보장은 없습니다. 세 문장으로 된 예시를 봅시다.
- 문서 ① — 김민수는 결제 시스템 리팩터링을 담당했다.
- 문서 ② — 이 결제 시스템 리팩터링은 장애율을 낮추기 위한 프로젝트였다.
- 문서 ③ — 이 장애율 개선 프로젝트는 보안 팀과 플랫폼 팀이 공동으로 진행했다.
"김민수와 보안 팀은 어떤 관계야?" (K=2)
벡터 RAG — 문서 ①·③만 검색
- 질문 단어와 가장 겹치는 ①(김민수)·③(보안 팀)이 검색됨
- 둘을 잇는 다리 문서 ②가 K 밖으로 밀려 누락
- LLM은 김민수와 보안 팀의 연결을 설명하지 못함
관계 단절
그래프 탐색 — ①→②→③ 경로를 따라감
- 김민수 →담당→ 결제 시스템 리팩터링
- 결제 시스템 리팩터링 →포함→ 장애율 개선 프로젝트
- 장애율 개선 프로젝트 →공동진행→ 보안 팀
관계로 연결됨
여러 홉(hop)을 건너야 답이 나오는 '관계형 질문'에서, 유사도 상위 K개 방식은 중간 연결고리를 놓치기 쉽습니다.
그래서 등장한 RAG 디자인 패턴들
이런 한계를 보완하려 여러 RAG 설계가 등장했습니다. GraphRAG는 그중 '관계'에 특화된 패턴입니다.
| 패턴 | 핵심 아이디어 | 잘 맞는 상황 |
|---|---|---|
| Naive RAG | 검색 후 그대로 LLM에 증강 | 단순 사실 조회 |
| Rerank RAG | 많이 검색한 뒤 재정렬로 정확도↑ | 검색 노이즈가 많을 때 |
| Hybrid RAG | 의미 검색 + 키워드(BM25) 검색 결합 | 고유명사·코드·숫자 검색 |
| Agentic RAG | 에이전트가 스스로 검색 전략을 결정 | 다단계·복합 질문 |
| GraphRAG | 지식 그래프에서 관계를 따라 검색 | 엔티티 간 관계·다중 홉 질문 |
GraphRAG — 관계로 검색한다
GraphRAG는 문서를 '지식 그래프(Knowledge Graph)'라는 개념 지도로 바꿔둡니다. 그리고 질문이 들어오면, 유사한 조각을 꺼내는 대신 지도 위 노드 사이의 관계(엣지)를 따라 여정을 떠나 답을 찾습니다.
GraphRAG 작동 방식
- 문서 → 지식 그래프 구축 엔티티(노드)와 관계(엣지)를 추출해 그래프로
- 질문 입력 예: "김민수와 보안 팀은 어떤 관계야?"
- 그래프 탐색 노드에서 출발해 관계를 따라 경로를 추적
- 관계 컨텍스트 확보 김민수→결제시스템→장애율개선→보안팀 경로를 수집
- 증강 + 생성 이 관계 정보를 LLM에 넣어 최종 답변 생성
"김민수는 결제 시스템 리팩터링을 담당했고, 그 프로젝트에서 보안 팀과 협업한 관계입니다" — 관계를 따라가야 나오는 답을 만들어냅니다.
사실은 이미 쓰고 있다 — 구글 지식 그래프
구글에서 '에펠탑'이나 '크리스토퍼 놀란'을 검색하면 오른쪽에 뜨는 정보 패널(높이·완공연도·건축가, 또는 국적·형제자매·수상작). 이것이 2012년부터 구글이 운영해온 지식 그래프입니다. '에펠탑'이라는 노드와 관계 맺은 이웃 노드들을 즉시 펼쳐 보여주는 것이죠. 방대한 데이터를 그래프로 구축해두면, 규모가 커져도 관계 탐색으로 빠르게 답을 찾을 수 있습니다.
벡터 RAG vs GraphRAG — 언제 무엇을
벡터 RAG
- 검색 단위: 의미가 비슷한 텍스트 조각
- 강점: 개념·주제 유사 검색, 구축이 간단
- 약점: 여러 조각을 잇는 관계형 질문에 취약
- 데이터가 커지면 검색 지연·품질 저하 우려
'비슷한 내용' 찾기
GraphRAG
- 검색 단위: 노드와 노드를 잇는 관계(엣지)
- 강점: 연결된 근거를 찾는 다중 홉 관계 질문
- 약점: 그래프 구축 비용·설계 노력이 든다
- 탐색 지연은 그래프 크기·질의·구현에 따라 달라짐
'어떻게 연결됐나' 찾기
같은 질문·데이터·평가 기준으로 검색 결과와 지연을 비교하세요. 그래프 방식이 모든 질문에서 더 빠르거나 정확하다고 가정하지 않습니다.
둘은 배타적이지 않습니다. 실무에서는 GraphRAG로 관계형 질문을, 벡터 RAG로 개념 유사 질문을 처리하도록 '상호 보완'하는 하이브리드 구성이 흔합니다. GraphRAG를 배웠다고 벡터 RAG를 버릴 필요는 없습니다.
GraphRAG가 항상 정답은 아닙니다. 지식 그래프를 만드는 비용(엔티티·관계 추출, 스키마 설계)이 들고, 단순한 의미 검색에는 오히려 벡터 RAG가 빠르고 저렴합니다. '관계를 따라가야 답이 나오는 질문이 많은가?'가 도입 판단의 기준입니다.
8분 실습 — 관계를 찾은 다음, 무엇을 해도 될까?
GraphRAG로 '이 문의는 어느 회사의 어느 일정과 연결됐나?'를 찾았다고 해봅시다. 그래도 '지금 일정을 확정해도 되나?'는 별도 질문입니다. 관계 검색은 판단에 필요한 정보를 모으고, 업무 모델은 대상·현재 상태·허용 행동·확인 담당자를 정의합니다. 답을 찾는 것과 실제 업무를 바꾸는 것을 구별해야 합니다.
관계 검색과 업무 온톨로지의 역할
GraphRAG — 연결된 근거 찾기
- 문서에서 대상과 관계를 찾아 검색한다
- 문의→회사→정책의 연결 근거를 모은다
- 검색 결과가 실행 권한을 주지는 않는다
어떤 정보를 함께 읽어야 하나?
업무 모델 — 허용 행동 정하기
- 회사·일정·요청을 고유 ID로 구별한다
- 행동마다 입력·현재 조건·담당자를 정한다
- 실행 시 검증과 처리 기록을 남긴다
누가 무엇을 어떤 조건에서 바꿀 수 있나?
여기서 업무 온톨로지는 업무 대상과 관계, 허용 행동을 함께 정의하는 모델을 뜻합니다. 특정 그래프 DB나 제품 설치가 필수라는 뜻은 아닙니다.
| 쉬운 말 | 가상 교육 문의에서의 예 | 확인할 질문 |
|---|---|---|
| 대상 종류 | 문의·회사·일정·담당자 | 무엇을 구별해서 다룰까? |
| 속성 | 일정의 상태·버전·정원 | 지금 어떤 값인가? 모르는 값은? |
| 관계 | 문의 Q-12가 회사 ORG-7의 일정 S-16을 요청 | 어떤 ID와 연결되는가? |
| 허용 행동 | 후보 제안·초안 작성·담당자 승인 후 확정 | 누가 어떤 조건에서 실행할까? |
같은 틀을 네 가지 업무에 써보기
| 업무 | 연결할 대상 | 제안과 실행의 경계 |
|---|---|---|
| 쇼핑몰 교환 문의 | 요청→주문→고객→교환 규정 | AI는 안내 초안. 주문 ID·미사용 여부 확인 전 교환 접수는 보류 |
| 기업 교육 일정 | 문의→회사→일정→담당자 | AI는 후보 제안. 담당자 승인 뒤에도 현재 일정 상태를 확인 |
| CSV 거래처 변경 | 파일→행 ID→거래처→확인 요청 | 연락처 변경을 확인 목록으로. 이름이 비슷해도 원본 자동 병합은 하지 않음 |
| B2B 납기 예외 | 요청→계약→예외 규칙→담당자 | 예외 적용을 제안. 영업 메모만 있고 계약 근거가 없으면 재확인 |
각 업무마다 대상을 전부 모델링할 필요는 없습니다. 이번에 해결할 요청 하나부터 시작하세요. 따로 상태·담당자·승인 행동을 관리해야 한다면 별도 대상으로 나누고, 조회용 설명은 속성으로 두면 됩니다.
준비 — 아래 가상 입력만 사용합니다
실제 고객 정보 대신 사용하는 교육 문의
{
"inquiryId": "Q-12",
"companyId": "ORG-7",
"scheduleId": "S-16",
"reviewerId": "U-4",
"sourceVersion": "v1",
"scheduleStatus": "검토중",
"capacityConfirmed": false,
"requestedAction": "교육 일정 후보 제안"
}정원은 아직 확인하지 않았습니다. 미확인 값을 '가능'으로 채우지 마세요. 이 실습에는 API 키·DB·Neo4j 설치가 필요하지 않습니다. 평소 쓰는 AI 채팅이나 클로드 코드에 아래 입력과 프롬프트를 붙여넣고, 결과표를 직접 확인하면 됩니다.
복사해서 따라 하기 — 교육 문의의 업무 모델 만들기
위 가상 입력 Q-12를 대상으로 업무 모델 초안을 만들어줘.
1. 문의, 회사, 일정, 담당자를 대상 종류로 구분하고 ID로 연결해줘.
2. 대상 / 필요한 속성 / 관계 / 허용 행동을 표로 정리해줘.
3. 각 행동에 입력, 실행 전 조건, 확인 담당자, 남길 기록을 적어줘.
4. AI가 할 수 있는 것은 일정 후보 제안과 안내 초안 작성까지다.
5. 정원 미확인 등 빠진 사실은 '확인 필요'로 표시해줘.
6. 이름은 같지만 ID가 다른 회사, 승인 후 일정 상태가 바뀐 경우를 반례로 넣어줘.
실제 예약·발송·파일 변경·외부 도구 호출은 하지 마.
코드 작성이나 패키지 설치 대신 모델 표와 반례 결과표만 보여줘.8분 따라 하기 — 입력→모델→반례→자기 업무
- 위 JSON과 프롬프트를 복사합니다. 회사 이름이나 실제 연락처는 추가하지 않습니다.
- 출력에서 Q-12→ORG-7→S-16과 담당자 U-4가 ID로 연결됐는지 확인합니다. 이름만으로 연결했다면 ID 기준으로 다시 작성하게 합니다.
- 정원 미확인이 '확인 필요'로 남고, 후보 제안과 일정 확정이 다른 행동으로 구별됐는지 확인합니다.
- 두 반례의 결과를 읽습니다. 회사 ID가 다르면 연결을 재확인하고, 원본 상태가 바뀌면 이전 제안으로 확정하지 않아야 합니다.
- 아래 기대 결과와 비교한 뒤, 자신의 반복 업무 하나를 대상·관계·허용 행동·확인 담당자 네 줄로 바꿔 적습니다.
| 검사 | 기대 결과 | 다르게 나왔다면 |
|---|---|---|
| 대상 연결 | Q-12→ORG-7→S-16, 확인 담당자 U-4 | 이름이 아니라 명시된 ID만 사용하도록 재요청 |
| 빠진 정원 | 확인 필요, 일정 확정 보류 | 추정값을 삭제하고 확인 질문을 남기도록 요청 |
| 다른 회사 ID | 자동 연결·병합하지 않음 | ORG-7과 다른 ID를 별도 대상으로 분리 |
| 승인 뒤 원본 변경 | 현재 상태·버전 재확인 후 이전 실행 차단 | 승인이 실행 완료가 아님을 명시하고 반례 다시 검사 |
완료 조건은 모델 표와 두 반례를 설명할 수 있는 것입니다. AI의 표가 맞았다고 실제 권한 검사·예약·발송이 구현된 것은 아닙니다. 운영 서비스는 서버에서 신원·권한·입력·현재 상태를 검증하고 실제 실행 결과를 기록해야 합니다.
더 읽기: Microsoft GraphRAG 공식 설명은 텍스트에서 지식 그래프와 요약 구조를 만들어 검색하는 접근을 다룹니다 — https://microsoft.github.io/graphrag/ . Palantir 공식 온톨로지 개요는 업무 대상·속성·관계에 행동과 보안을 함께 연결하는 운영 레이어를 설명합니다 — https://www.palantir.com/docs/foundry/ontology/overview/ . 위 네 업무와 실습 입력은 LeanX가 만든 합성 예시입니다.
개념을 잡았으니, 다음 레슨에서 지식 그래프의 3요소(노드·엣지·속성)를 뜯어보고 Neo4j와 랭체인으로 실제 그래프를 만들어 질문까지 던져보겠습니다.