pgvector를 RAG에 붙이고 꽤 만족스럽게 쓰고 있었다. 이미 PostgreSQL을 쓰고 있었고, 확장 하나 설치하면 벡터 검색까지 되니까 인프라를 늘리지 않아도 됐다. 문서 수가 수십만 건 수준일 때는 HNSW 인덱스로 응답 속도도 충분했고, BM25 하이브리드 검색까지 붙이니까 검색 품질도 나쁘지 않았다.
그러다 어느 날 질문 하나가 들어왔다. “이 계약서에 등장하는 모든 법인이 서로 어떻게 연결돼 있고, 그중 계열사 관계인 곳은 어디인가.” pgvector는 이 질문에 제대로 답하지 못했다. 유사한 계약서 청크를 가져오긴 했는데, 법인들 사이의 관계를 연결하는 추론이 안 됐다. 이게 GraphDB를 진지하게 들여다보게 된 계기였다.
pgvector가 잘 하는 것과 못 하는 것
솔직하게 정리하면 pgvector는 “비슷한 걸 찾아오는” 일을 잘 한다. 사용자의 질문과 의미적으로 가까운 문서 청크를 빠르게 가져오는 건 pgvector가 강점이다. 설정도 간단하고, 기존 PostgreSQL SQL 문법 그대로 쓸 수 있고, 메타데이터 필터링도 WHERE 절 하나면 된다.
문제는 “연결된 것을 따라가는” 일이다. 관계 데이터베이스는 테이블과 외래 키로 데이터를 연결하는데, 이게 복잡한 다단계 관계를 표현하는 데는 구조적으로 한계가 있다. 예를 들어 “A 법인이 B 법인의 자회사이고, B 법인은 C 그룹 산하인데, C 그룹이 관련된 계약은?”처럼 세 단계를 건너야 하는 쿼리는 SQL JOIN이 복잡해지고, 성능도 급격히 떨어진다. 그 관계가 네 단계, 다섯 단계로 늘어나면 더 심해진다.
이게 그래프 데이터베이스가 존재하는 이유다.
GraphDB가 데이터를 보는 방식
GraphDB는 Graphwise가 개발한 RDF 기반 그래프 데이터베이스다. Ontotext가 20년 이상 개발해온 제품이고, Graphwise 합병 이후 GraphRAG 플랫폼의 핵심 엔진으로 통합됐다.
RDF는 데이터를 “주어-서술어-목적어” 형태의 트리플로 표현한다. “삼성전자 → 자회사 → 삼성SDI”, “삼성SDI → 계약 → A 프로젝트”처럼 모든 데이터가 노드와 엣지로 연결된 그래프 구조가 된다. 이 구조에서 “삼성전자와 관련된 모든 계약”을 찾으려면 SPARQL이라는 그래프 쿼리 언어로 그래프를 탐색하면 된다. 관계가 몇 단계인지는 중요하지 않다. 그래프를 따라가면 된다.
SQL과 SPARQL의 결정적인 차이는 여기서 나온다. SQL은 관계를 미리 정의된 스키마 안에 가두는 방식이고, SPARQL은 데이터에서 관계를 발견하는 방식이다. 관계가 얼마나 복잡해지든, 몇 단계를 건너든 그래프 탐색으로 처리할 수 있다.
실제로 두 개를 같이 쓰면 어떻게 되나
GraphDB와 pgvector를 동시에 쓰는 구조를 운영해보면, 역할이 자연스럽게 나뉜다.
pgvector는 의미 기반 검색의 진입점이다. 사용자의 질문과 가까운 문서 청크를 빠르게 1차로 좁혀오는 역할을 한다. 속도가 빠르고 임베딩 모델과 연결이 쉽다. 반면 GraphDB는 그 결과에서 관계 추론을 추가하는 역할이다. pgvector가 후보 문서를 가져오면, 그 문서들에 등장하는 개체가 서로 어떤 관계인지를 GraphDB에서 추가로 탐색해서 컨텍스트를 보강한다.
이 구조가 GraphRAG다. 벡터 검색이 광범위하게 후보를 좁히고, 그래프 탐색이 관계 기반으로 정밀하게 컨텍스트를 연결한다. Graphwise의 GraphDB 10.8이 이 두 가지를 하나의 파이프라인으로 묶는 Talk-to-Your-Graph 2.0 기능을 출시한 것도 이 흐름이다. LLM, 벡터 검색, SPARQL 쿼리를 하나의 인터페이스로 통합해서 비기술 사용자도 자연어로 그래프를 탐색할 수 있게 만들었다.
인프라 복잡도 – 솔직한 이야기
GraphDB를 추가하면 관리할 시스템이 하나 더 늘어난다. pgvector는 이미 있는 PostgreSQL 위에 올라가지만, GraphDB는 별도의 서비스를 띄워야 한다. AWS, Azure, GCP 모두 클라우드 배포를 지원하고 온프레미스도 되지만, 모니터링, 백업, 버전 업그레이드를 따로 관리해야 하는 건 피할 수 없다.
그리고 SPARQL을 배워야 한다. SQL에 익숙한 개발자라면 처음에 진입 장벽이 느껴진다. SPARQL의 패턴 매칭 방식은 SQL의 JOIN과 다른 사고 방식을 요구한다. RDF 트리플 구조를 이해하고, 온톨로지 개념에 익숙해지는 데 시간이 걸린다.
비용 이야기도 빠질 수 없다. GraphDB는 엔터프라이즈 라이선스 기반이라 오픈소스 pgvector와는 비용 구조 자체가 다르다. 무료 버전도 있지만 멀티 클러스터 배포나 고가용성 기능은 유료 라이선스에서 지원된다. 도입 전에 이 비용을 충분히 고려해야 한다.
GraphDB가 LLM 비용을 줄이는 원리
Graphwise가 강조하는 포인트 중 하나가 LLM 비용 절감이다. 처음엔 “그래프 DB를 쓰면 LLM 비용이 줄어든다”는 말이 직관적으로 와닿지 않았는데, 실제 구조를 이해하고 나서는 납득이 됐다.
일반 벡터 RAG는 검색 품질이 낮을 때 보완하는 방법이 더 많은 청크를 컨텍스트로 넣는 것이다. 관련 문서인지 불분명하니까 일단 많이 넣어서 LLM이 알아서 판단하게 한다. 그러면 프롬프트 토큰이 늘어나고, LLM 호출 비용이 올라간다.
GraphDB는 이 방향이 반대다. 지식 그래프에서 관계 기반으로 정확히 필요한 컨텍스트만 뽑아오기 때문에, 같은 질문에 더 적은 토큰으로 더 정확한 답을 낼 수 있다. 실제로 Graphwise의 내부 벤치마크에서 GraphDB 기반 GraphRAG가 순수 벡터 RAG 대비 LLM 호출 비용을 의미 있게 줄인다는 결과가 나왔고, 2026년 2월 공식 출시된 GraphRAG 플랫폼의 핵심 셀링 포인트 중 하나로 이 비용 효율성을 내세우고 있다.
어느 쪽을 써야 하는가
pgvector로 충분한 상황과 GraphDB가 필요한 상황을 구분하면 이렇다.
문서 수가 수십만 건 이하이고, 사용자 질문이 주로 단순 사실 조회거나 유사 문서 검색이라면 pgvector로 충분하다. 인프라를 단순하게 유지하면서 충분한 검색 품질을 얻을 수 있다.
반면 조직 내 데이터가 복잡하게 얽혀 있고, 여러 개체 사이의 관계를 추론해야 하는 질문이 많거나, 법률·금융·의료처럼 정확성과 설명 가능성이 중요한 도메인이라면 GraphDB가 맞다. “이 답변의 근거는 무엇인가”를 추적해야 하는 상황, 즉 감사나 규제 대응이 필요한 환경에서 그래프 기반 추론의 추적 가능성이 결정적으로 유리하다.
내가 지금 운영하는 구조는 두 가지를 역할 분리해서 같이 쓰는 방식이다. 빠른 의미 검색은 pgvector로, 관계 기반 컨텍스트 보강은 GraphDB로 나눠서 처리한다. 인프라 부담이 늘어나는 건 사실이지만, 복잡한 관계 추론이 필요한 쿼리에서 답변 품질 차이가 분명하게 나온다.
선택이 아니라 설계의 문제
GraphDB냐 pgvector냐를 “어느 게 더 좋냐”의 문제로 보면 답이 없다. 이건 도메인의 데이터 구조와 사용자 질문의 성격에 따라 달라지는 설계 결정이다.
관계가 복잡한 데이터를 AI로 다루려는 조직이라면, 벡터 유사도만으로 검색하는 구조를 언제까지 유지할 수 있는지 점검해볼 필요가 있다. 지식 그래프를 AI 백본에 두는 방향은 단순히 검색 품질을 높이는 것을 넘어, 조직이 가진 암묵적 관계 지식을 명시적인 구조로 변환하는 일이다. 그리고 그 구조화된 지식이 AI를 더 신뢰할 수 있게 만든다는 것이 Graphwise가 20년 동안 주장해온 핵심이고, 지금 GraphRAG라는 형태로 현실에서 검증되고 있다.