GraphRAG를 “검색 품질을 조금 더 좋게 만드는 기법”으로 보면 도입 판단이 흐려진다. 더 실용적인 기준은 “영향 범위 질문이 자주 발생하는가”다. 단일 사실을 찾는 질문은 벡터 RAG만으로도 충분할 수 있지만, “이 모듈을 바꾸면 어디가 깨지는가”, “이 외부 API 장애가 어떤 서비스로 전파되는가” 같은 질문은 의미적 유사도보다 관계 경로가 중요하다.
그래서 도입 우선순위도 명확해진다. 작은 프로젝트나 단발성 질문에는 오버스펙일 수 있다. 반대로 수백 개 파일, 여러 서비스, 긴 멀티턴 작업, 팀 단위 Claude Code 운영에서는 관계 그래프가 비용 절감보다 사고 안정성에 먼저 기여한다. RAG로 시작점을 찾고, 그래프로 1~2 hop 관계를 따라가는 방식이 현실적인 절충점이다.
근거
원문은 RAG가 의미적으로 가까운 문서 조각을 찾는 데 강하지만, 문서 간 관계와 다중 hop 추론에는 약하다고 설명한다. 반면 온톨로지는 관계를 따라 검색하기 때문에 엔티티 비교, 영향 범위, 횡단 질문에 강하다.
RAG는 의미의 가까움으로 찾고, 온톨로지는 관계를 따라간다. 두 방식은 경쟁보다 조합이 현실적이다.
연결된 생각
- 20260629-ontology-as-relation-index-for-coding-agents — GraphRAG를 가능하게 하는 관계 인덱스.
- 20260609-codegraph-local-knowledge-graph — 코드베이스 영향 범위 질문을 위해 로컬 그래프를 구축하는 접근.
- 20260605-orchestrator-lightness-key-to-cost-quality — 필요한 지식만 lazy load해야 비용과 품질이 동시에 좋아진다는 원리와 연결된다.