Vector 검색은 의미적 유사성(semantic similarity)과 설정 속도 면에서 강점을 가집니다. 반면 GraphRAG는 카운팅, 부재 여부(absence), 다단계 질문(multi-hop questions), 대체(supersession), 그리고 권한 안전 검색(permission-safe retrieval) 측면에서 강점을 가집니다.
대부분의 프로덕션 시스템은 결국 이 두 가지를 모두 사용하게 됩니다. 진정한 결정은 최종 컨텍스트를 어떻게 조립할 것인가에 달려 있습니다.
실제 차이점은 무엇인가?
Vector 데이터베이스는 텍스트를 임베딩(embeddings) 형태로 저장하고, 사용자 질의의 임베딩과 가장 가까운 것을 검색합니다. 이는 _“이것과 유사한 것이 무엇인지”_에 답합니다.
GraphRAG는 개체(entities)를 노드(nodes)로, 그 관계를 탐색 가능한 엣지(edges)로 저장하며, 이 관계들을 따라가며 정보를 검색합니다. 이는 _“이것과 연결된 것은 무엇이며, 어떻게 연결되어 있는지”_에 답합니다.
이들은 본질적으로 다른 기능적 역량이며, 같은 아이디어를 경쟁하는 구현체가 아닙니다. 이것이 바로 올바른 질문이 거의 “어떤 것이 더 좋은가”가 아니라 항상 “이 특정 질문은 어떤 것을 필요로 하는가”이기 때문입니다.
Vector 검색만으로 충분할 때?
세 가지 조건이 모두 충족되어야 합니다:
- 질문이 조합(composition)이 아닌 조회(lookup)일 때. “X라고 명시하는 정책을 찾아주세요.” 단일 청크(chunk)에 답이 포함되어 있습니다.
- 권한 모델이 거칠게 표현 가능하거나, 사실상 개방적일 때. 단일 필터로 표현되거나 효과적으로 열려 있어야 합니다.
- 오래된 콘텐츠가 무해할 때. 소스 데이터의 어떤 것도 나중에 뒤집히거나 대체되지 않습니다.
이 세 가지 조건이 모두 충족될 때, Vector 검색은 적절한 도구이며 GraphRAG는 과도한 공학(overengineering)입니다. 접근 권한이 실제로 범위가 지정되고 정책이 실제로 변경되는 운영 데이터에 대한 내부 기업 검색의 경우, 이 세 가지 조건을 동시에 만족하는 경우는 거의 없습니다.
대신 탐색(traversal)이 필요할 때는?
답변을 얻기 위해 **검색(retrieval)보다는 조합(composition)**이 필요할 때입니다. 단일 문서에 답이 포함되어 있지 않아, 시스템이 여러 개체 간의 관계를 따라가며 이를 조립해야 할 때입니다.
Vector 검색으로는 구조적으로 처리할 수 없는 네 가지 질문 형태가 있습니다:
| Question shape | Example | Why embeddings fail |
|---|
| Aggregation | "Who should review this change?" | 이는 조회(lookup)가 아니라 기여 이력에 대한 집계(aggregation)입니다 |
| ... | | |
| 세 번째 행이 사람들을 놀라게 하는 부분입니다. 존재하지 않는 것을 임베딩할 수 없습니다. 누락된 데이터에 대한 쿼리는 의미론적 이웃(semantic neighbor)이 없으며, 이를 답변하는 유일한 방법은 구조를 순회(traverse)하며 격차(gap)를 관찰하는 것입니다. | | |
두 가지 방식을 모두 활용할 수 있을까요?
네, 그리고 대부분의 성숙한 시스템들이 그렇습니다.
일반적인 패턴은 **진입점 발견을 위한 벡터 검색(vector search)**과 **맥락 조립을 위한 그래프 순회(graph traversal)**입니다. 임베딩이 관련 시작 노드를 찾고, 그래프는 그 노드에서 바깥으로 이동하며 실제로 질문에 답하는 사실들을 수집합니다.
중요한 것은 모델에 전달되는 최종 맥락을 어떤 계층(layer)이 조립하느냐입니다. 만약 벡터 저장소(vector store)라면, 그래프가 부착된 벡터 RAG를 갖게 됩니다. 만약 그래프라면, 의미론적 진입점(semantic entry point)을 가진 GraphRAG를 갖게 되며—다단계 질문(multi-hop questions) 하에서의 동작 방식은 완전히 다릅니다.
실무에서 판단하는 방법
가장 어려운 실제 사용자 질문 10개를 가져가세요. 데모용 질문이 아니라, 누군가가 티켓을 열게 만든 질문이어야 합니다.
각 질문에 대해 다음을 물어보세요: 단일 출처 문서가 이 답변을 포함하고 있나요?
- 주로 예(Yes) → 벡터 검색(vector search)에 집중하고 절약된 예산을 검색 품질 향상에 사용하세요.
- 주로 아니오(No) → 순회(traversal)가 필요하며, 나중에 추가하는 것은 처음부터 구축하는 것보다 비용이 많이 듭니다.
- 혼합(Split) → 하이브리드(hybrid)를 구축하고, 최종 맥락 조립을 담당하는 계층이 무엇인지 명확히 하세요.
우리가 가장 자주 보는 실패 모드는 이 테스트를 오직 조회 질문(lookup questions)에 대해서만 실행하고, 벡터 RAG를 출시한 후, 검색 계층이 핵심 역할을 하는 6개월 후에 구성 질문(composition questions)을 발견하는 팀입니다.
저희는 고객에게 실제로 어떤 것이 필요한지 솔직하게 알려줍니다. 이 결정을 내리고 있다면, 저희 팀에 문의하세요.