RAG와 그래프RAG: 개발자가 “근거 있는 답변”을 만들기 위한 두 가지 접근

LLM(대규모 언어 모델)은 똑똑하지만, 모르는 건 모른다기보다 그럴듯하게 만들어내는 쪽으로 흘러가기 쉽습니다. 개발 현장에서는 이게 치명적이죠. 문서와 코드, 정책, 장애 리포트처럼 “정답이 있는 지식”을 기반으로 답해야 하니까요. 이때 많이 쓰는 방식이 RAG(Retrieval-Augmented Generation)이고, 최근엔 관계를 더 잘 다루기 위해 그래프RAG(Graph RAG)가 주목받고 있습니다.

RAG란 무엇인가

RAG는 한마디로 외부 지식(문서)을 검색해 근거를 붙인 뒤 답변을 생성하는 패턴입니다.

동작 흐름(개발 관점)

1. 문서를 조각(chunk)으로 나눔
2. 각 조각을 임베딩 벡터로 만들어 저장(벡터 DB 등)
3. 사용자의 질문을 임베딩 후, 유사한 조각을 검색
4. 검색된 조각을 프롬프트에 넣고 LLM이 답변 생성

RAG가 특히 잘하는 것

• 사내 위키/정책/매뉴얼 기반 Q&A
• 릴리즈 노트나 장애 보고서에서 근거를 끌어와 요약
• 최신 문서를 반영한 답변(모델 재학습 없이)

RAG의 한계(실무에서 자주 부딪힘)

• 문서 간 관계(원인-결과, 의존성, 사용자-권한 구조)를 깊게 추론하기 어렵다
• “A는 B의 하위이고, B는 C와 연결되고…” 같은 다중 홉 질의에서 검색이 빗나갈 수 있다
• 관련 조각이 흩어져 있으면, 한두 개 chunk만으로는 맥락이 부족해진다

그래프RAG란 무엇인가

그래프RAG는 RAG의 “검색”을 그래프 기반 탐색으로 강화하는 접근입니다. 문서에서 엔터티(서비스, 테이블, API, 담당자 등)와 관계(호출, 소유, 의존, 포함 등)를 뽑아 지식 그래프를 만들고, 질문에 따라 그래프를 타고 필요한 근거를 모읍니다.

언제 그래프RAG가 빛나는가

• 마이크로서비스 의존성: “장애가 났을 때 어디부터 영향이 퍼지나?”
• 데이터 계보(Lineage): “이 대시보드의 수치가 어떤 ETL과 테이블을 거치나?”
• 권한/역할 관계: “이 기능을 누가 승인해야 하고 어떤 정책을 따라야 하나?”
• 이슈 원인 분석: “최근 배포와 연관된 변경 파일/모듈이 뭐였지?”

RAG vs 그래프RAG, 감으로 잡는 비교

• RAG: 가까운 문서 조각을 잘 찾는 데 강함
• 그래프RAG: 관계가 많은 지식을 길게 연결해 추론하는 데 강함

간단한 사례로 이해하기

상황: 결제 실패 장애 문의

• 질문: “어제부터 결제 실패가 늘었는데, 원인이 뭘 가능성이 커?” RAG는 “결제 실패”, “에러 코드”, “어제” 같은 키워드와 가까운 장애 리포트 조각을 찾아 요약하는 데는 좋습니다. 하지만 원인이 결제 API → 인증 서비스 → 외부 PG로 이어지는 연쇄 의존 문제라면, 관련 정보가 여러 문서/리포트/런북에 흩어져 있을 수 있어요.

그래프RAG는 “결제 API가 의존하는 서비스”, “최근 변경된 노드”, “실패율이 증가한 경로”처럼 관계 기반으로 후보를 좁히고 필요한 근거를 모아 답변을 구성하기가 수월합니다.

개발자가 바로 적용할 수 있는 구현 아이디어

RAG 최소 구현(파이썬 예시)

아래는 “문서 조각 검색 → 상위 k개를 컨텍스트로 사용”하는 형태의 뼈대입니다. (임베딩/LLM 호출부는 사용하는 SDK에 맞게 교체하면 됩니다.)

from dataclasses import dataclass
from typing import List, Tuple
import numpy as np

@dataclass
class Chunk:
    id: str
    text: str
    vec: np.ndarray

def cosine(a: np.ndarray, b: np.ndarray) -> float:
    return float(a @ b) / (np.linalg.norm(a) * np.linalg.norm(b) + 1e-9)

def retrieve(chunks: List[Chunk], query_vec: np.ndarray, k: int = 4) -> List[Tuple[float, Chunk]]:
    scored = [(cosine(c.vec, query_vec), c) for c in chunks]
    scored.sort(key=lambda x: x[0], reverse=True)
    return scored[:k]

def build_context(topk: List[Tuple[float, Chunk]]) -> str:
    return "\n\n".join([f"[{c.id}]\n{c.text}" for _, c in topk])

# query_vec = embed("질문 텍스트")
# topk = retrieve(chunks, query_vec, k=4)

그래프RAG는 “그래프를 어떻게 만들지”가 핵심

그래프RAG에서 난이도가 생기는 지점은 모델 호출이 아니라 그래프 구성입니다.

• 노드 예: 서비스, API, DB 테이블, 배치 잡, 담당 팀, 정책 문서
• 엣지 예: 호출한다, 저장한다, 소유한다, 생성한다, 영향을 준다 처음부터 완벽한 지식 그래프를 만들기보다, 가장 자주 물어보는 질문 20개를 기준으로 노드/관계를 최소로 정의해 시작하면 성공 확률이 올라갑니다.

어떤 걸 선택해야 할까

RAG부터 추천하는 경우

• 문서가 잘 정리되어 있고 “찾아서 요약” 성격이 강할 때
• 빠르게 MVP를 만들어 내부에 배포하고 싶을 때
• 질의가 단발성이고 관계 추론 요구가 낮을 때

그래프RAG를 고려할 시점

• “왜/어떻게” 질문이 많고, 답이 여러 시스템에 걸쳐 있을 때
• 운영/장애/데이터 계보처럼 연결 구조 자체가 지식인 도메인일 때
• 단순 유사도 검색으로는 항상 한두 단계에서 막힐 때

마무리: 개발 조직에선 “정답”보다 “근거”가 자산이다

RAG는 지식을 가져오는 능력을, 그래프RAG는 지식을 연결하는 능력을 강화합니다. 개발 현장에서는 둘 중 하나만 고집하기보다, 먼저 RAG로 빠르게 가치(검색+답변)를 만들고, 반복 질문에서 관계 추론의 필요가 드러날 때 그래프를 얹는 전략이 현실적입니다. 결국 목표는 하나입니다. 팀이 신뢰할 수 있는 근거 기반 답변을 꾸준히 생산하는 것.