본문 바로가기

GITHUB 추천

PageIndex 벡터리스 RAG GitHub – 벡터DB 없이 정확도 98.7% 오픈소스 설치·사용법 완전 가이드

 

벡터DB 없이 RAG 정확도 98.7% – PageIndex 오픈소스 완전 가이드

벡터 임베딩·청킹 없이 문서 구조를 살려 검색하는 새로운 RAG, 설치부터 MCP 연동까지

PageIndex – 벡터DB 없이 추론 기반 RAG를 구현하는 오픈소스
 

PageIndex란? 벡터DB 없이 RAG 정확도 98.7%를 달성한 오픈소스

 

PageIndex는 벡터 임베딩과 청킹 없이 문서의 계층적 목차(ToC) 트리를 자동 생성하고, LLM이 트리 탐색으로 관련 섹션을 찾아가는 오픈소스 RAG 라이브러리입니다. FinanceBench 벤치마크에서 98.7% 정확도를 기록했습니다.

GitHub 스타 29.3k+, MIT 라이선스로 공개된 `VectifyAI/PageIndex`는 2026년 5월 GitHub Trending AI 레포 목록에도 올랐습니다. 기존 벡터 RAG와는 접근 자체가 다릅니다.

실무 관점에서 눈에 띄는 건 벡터DB 인프라 자체가 빠진다는 점입니다. ChromaDB나 Pinecone 같은 벡터 스토어를 띄우지 않아도 되고, 임베딩 모델 선택·튜닝 과정도 없습니다. 문서의 자연스러운 구조를 그대로 살린 채 LLM이 직접 탐색하는 방식이라, RAG 파이프라인을 처음 구성하는 팀이라면 진입 장벽이 상당히 낮아집니다.

PyTorchKR 커뮤니티에서도 PageIndex 관련 토론 스레드가 열린 바 있어, 한국 개발자들 사이에서도 관심이 확인됩니다. 아래에서는 PageIndex 벡터리스 RAG GitHub 레포의 설치부터 MCP 서버 연동, 실무 도입 판단까지 순서대로 짚어 봅니다.

 
PDF 문서에서 계층적 목차(ToC) 트리 노드가 자동 생성되고, 쿼리가 들어오면 LLM이 루트에서 리프까지 각 노드의 관련성을 판단하며 내려가는 과정을 좌에서 우 흐름으로 보여주는 다이어그램
 

벡터 유사도 검색만으로는 왜 부족할까?

 

벡터 유사도 검색은 텍스트가 '비슷한' 청크를 반환할 뿐, 질문에 '관련 있는' 정보를 정확히 찾아주지 못합니다. PageIndex는 이 문제를 '검색(search)'이 아닌 '탐색(navigation)'으로 재정의합니다.

VentureBeat가 2026년 1월 심층 보도한 바에 따르면, PageIndex 팀은 게임 AI의 트리 탐색(tree search) 기법에서 영감을 받았습니다. 체스나 바둑에서 AI가 수를 탐색하듯, 쿼리가 들어오면 LLM이 문서의 목차 트리를 따라 내려가면서 각 노드의 관련성을 판단합니다.

기존 벡터 RAG의 근본적 한계는 고정 크기 청킹에 있습니다. 500토큰 단위로 문서를 자르는 순간 표와 각주의 맥락이 끊기고, 교차 참조 관계도 사라집니다. SEC 제출 문서나 감사 보고서처럼 교차 참조가 많은 문서일수록 이 손실이 치명적이죠.

> 핵심 철학: similarity ≠ relevance — 유사도가 높다고 관련성이 높은 것은 아닙니다.

 

오픈소스 공개부터 GitHub Trending까지의 흐름

 

2026년 2월 Mafin 2.5와 함께 오픈소스로 공개된 PageIndex는 3개월 만에 29.3k+ 스타를 달성하고, 5월 GitHub Trending AI 레포에 선정됐습니다.

시기 주요 이벤트
2026년 1월 VentureBeat, '게임 AI 영감 트리 탐색 RAG 프레임워크'로 심층 보도
2026년 2월 Mafin 2.5 + PageIndex 오픈소스 공개, FinanceBench 98.7% 달성
2026년 3월 Analytics Vidhya에서 벡터 RAG 대비 구조적 차이 비교 분석 게재
2026년 4월 Medium에서 직접 테스트 기반 비교 기사 등장
2026년 5월 GitHub Trending AI 레포 선정, 29.3k+ 스타 · 2.5k 포크 도달

3개월 만에 이 정도 성장세를 보인 것은 벡터 RAG에 대한 실무 불만이 꽤 쌓여 있었다는 방증이기도 합니다.

 

설치와 첫 실행 — 어떤 환경이 필요한가?

 

`pip install -U pageindex`로 설치하고, `CHATGPT_API_KEY` 환경변수에 OpenAI API 키를 설정한 뒤, 마크다운 또는 PDF 문서를 지정해 실행하면 트리 인덱스가 자동 생성됩니다.

필수 요건:

  • Python 3.8 이상
  • OpenAI API 키 (환경변수 `CHATGPT_API_KEY`에 설정)

설치:
```
pip install -U pageindex
```

첫 실행 — 마크다운 문서:
```
python3 run_pageindex.py --md_path /path/to/document.md
```

PDF 문서:
```
python3 run_pageindex.py --pdf_path /path/to/document.pdf
```

브라우저에서 바로 테스트하고 싶다면, 공식 레포의 `cookbook/pageindex_RAG_simple.ipynb` Colab 노트북을 열면 됩니다. API 키만 넣으면 별도 환경 구성 없이 동작을 확인할 수 있습니다.

실제로 확인할 부분은 OpenAI API 비용입니다. PageIndex는 인덱싱과 검색 양쪽에서 LLM 호출이 발생합니다. 셀프호스트 환경에서는 표준 PDF 파서를 사용하기 때문에, 복잡한 레이아웃의 PDF라면 클라우드 서비스(`pageindex.ai`)의 강화된 OCR 파이프라인이 더 정확할 수 있습니다.

에이전트 RAG를 테스트하고 싶다면 OpenAI Agents SDK 연동 예제도 제공됩니다:
```
pip3 install openai-agents
python3 examples/agentic_vectorless_rag_demo.py
```

 
 
 

MCP 서버로 Claude Desktop·Cursor에 연동하려면?

 

`pageindex-mcp` npm 패키지를 설치하거나 `.mcpb` 번들 파일로 원클릭 설치할 수 있습니다. Node.js 18.0.0 이상이 필요하고, Claude Desktop의 Extensions 설정이나 `claude_desktop_config.json` 수동 편집으로 연동됩니다.

PageIndex는 MCP(Model Context Protocol) 서버도 제공합니다. Claude Desktop, Claude Code, Cursor 같은 에이전트 환경에서 문서 업로드와 검색을 바로 호출할 수 있다는 뜻입니다.

설치:
```
npm install -g pageindex-mcp
```

또는 공식 레포에서 `.mcpb` 번들 파일을 다운로드하면 한 번의 클릭으로 Claude Desktop에 추가됩니다. 인증 방식은 API Key(간단)와 OAuth(PageIndex Chat 계정 연동) 두 가지를 지원합니다.

한국 사용자 입장에서는, Claude Code나 Cursor에서 사내 기술 문서를 PageIndex로 인덱싱해 두고 에이전트가 코드 작성 중 필요한 스펙을 직접 검색하게 만드는 워크플로우가 실용적입니다. Claude Agent SDK 연동 예제도 공식 Cookbook에 있으니, 프로토타입 단계에서 참고하기 좋습니다.

 

벡터 RAG(LangChain+ChromaDB)와 구조적으로 다른 지점

 

벡터 RAG는 문서를 고정 크기 청크로 나누고 임베딩 유사도로 검색합니다. PageIndex는 문서의 계층적 목차 구조를 보존하고 LLM이 트리 탐색으로 관련 섹션을 추론합니다. 검색 경로가 페이지·섹션 단위로 추적되어 설명 가능성이 높습니다.

항목 벡터 RAG (LangChain+ChromaDB) PageIndex
인덱싱 방식 고정 크기 청킹 + 임베딩 벡터 계층적 목차(ToC) 트리 자동 생성
검색 방식 코사인 유사도 기반 LLM 트리 탐색(추론 기반)
인프라 벡터DB 필요 (ChromaDB, Pinecone 등) 벡터DB 불필요
설명 가능성 유사도 점수만 반환 페이지·섹션 경로 추적 가능
FinanceBench 정확도 60~80% 수준 98.7% (Mafin 2.5 기준)
쿼리당 비용 임베딩 비용 (상대적으로 저렴) LLM 추론 비용 (상대적으로 높음)
적합한 문서 범용 — 짧은 문서도 처리 가능 구조화된 장문 문서에 강점 (금융·법률·기술)

실무에서 가장 체감되는 차이는 설명 가능성입니다. 벡터 RAG에서 '이 청크가 왜 반환됐는지'를 추적하기는 어렵지만, PageIndex는 '어떤 페이지의 어떤 섹션에서 답을 찾았는지'가 검색 경로에 남습니다. 감사·컴플라이언스 환경에서 이 차이는 단순한 기능이 아니라 필수 요건이 됩니다.

반면, 비용 구조는 정반대입니다. 벡터 RAG는 인덱싱 때 임베딩 비용만 들고, 검색은 벡터 연산만으로 끝납니다. PageIndex는 매 쿼리마다 LLM 추론이 필요하므로, 쿼리가 잦은 서비스에서는 비용이 빠르게 올라갑니다.

 
 
 

도입 시뮬레이션: 어떤 팀이 써야 하고, 언제 건너뛰어야 하는가?

 

금융·법률 문서 분석, 기술 문서 QA, 감사·컴플라이언스처럼 구조화된 장문 문서를 다루는 팀이 가장 큰 효과를 봅니다. 반면, 비구조적 짧은 문서를 대량 처리하거나 오프라인 환경이 필수인 경우에는 적합하지 않습니다.

추천 분야:

  • 금융·법률 문서 분석 — SEC 제출물(10-K, 10-Q), 계약서, 규정 문서처럼 교차 참조·계층 구조가 복잡한 환경. FinanceBench 벤치마크가 바로 이 도메인입니다.
  • 기술 문서 QA — 매뉴얼, API 문서, 사양서 기반의 사내 챗봇. 문서 구조가 명확할수록 PageIndex의 트리 탐색이 잘 동작합니다.
  • 감사·컴플라이언스 — 검색 경로의 추적 가능성(traceability)이 규제 요건인 환경.
  • 에이전트 워크플로우 — MCP 서버를 통한 Claude Code·Cursor 연동으로 코드 작성 중 기술 스펙 자동 검색.

함께 쓰면 좋은 도구:

  • OpenAI Agents SDK — 공식 예제(`agentic_vectorless_rag_demo.py`)에서 직접 통합 데모 제공
  • Claude Desktop / Claude Code — pageindex-mcp 서버로 MCP 연동
  • Cursor IDE — MCP 호환 에이전트로 문서 검색 통합
  • AWS Bedrock — Vectorless RAG with AWS Bedrock 가이드가 공개되어 AWS 인프라와 통합 가능

여기서 중요한 건, PageIndex 벡터리스 RAG가 만능 도구는 아니라는 점입니다. 아래 조건에 해당하면 굳이 전환할 이유가 없습니다.

건너뛰어야 하는 경우:

  • 비구조적이고 짧은 문서 대량 처리 — 트리 구조의 이점이 작고, 벡터 검색이 더 빠르고 저렴합니다
  • 오프라인·에어갭 환경 — 현재 로컬 LLM을 지원하지 않아 OpenAI API 접속이 필수입니다
  • 초대량 실시간 쿼리 — 매 쿼리마다 LLM 추론이 필요해 처리량·비용 면에서 벡터 검색 대비 불리합니다
  • 이미 벡터 RAG로 90%+ 정확도를 달성한 경우 — 전환 비용 대비 개선폭이 작을 수 있습니다
  • 다국어·다도메인 혼합 코퍼스 — FinanceBench 외 시나리오에서의 정확도가 아직 독립적으로 검증되지 않았습니다
 

한계와 비용 — 과대평가를 경계하며

 

98.7% 정확도는 FinanceBench(금융 문서 QA) 한정 벤치마크 결과입니다. 모든 도메인에서 벡터 RAG를 대체할 수 있다고 단정할 수 없으며, 매 쿼리마다 LLM 호출 비용이 발생합니다.

여기서 조심할 점은 벤치마크 범위입니다. FinanceBench는 실제 SEC 제출 문서를 사용하는 금융 문서 QA 표준 테스트로, 정확한 수치 답변을 요구합니다. 이 환경에서 탁월한 성적을 보인 것은 사실이지만, 비정형·다도메인·모호한 쿼리 시나리오에서는 아직 독립적으로 검증되지 않았습니다.

비용 측면도 따져 봐야 합니다. sjramblings.io의 분석에 따르면, 100페이지 PDF 기준 인덱싱과 검색을 합치면 약 $0.50~$5.00의 OpenAI API 비용이 발생할 수 있습니다. 벡터 RAG가 임베딩 비용만 들고 검색 시에는 벡터 연산만으로 끝나는 것과 대비됩니다.

현재 로컬 LLM(Ollama 등)을 직접 지원하지 않는 점도 제약입니다. 반드시 OpenAI API 키가 있어야 하며, 에어갭·오프라인 환경에서는 사용이 불가합니다. 또한 대량 문서를 처리할 때 FAISS 폴백으로 전환되는 구조라는 분석도 있어, 이 경우 PageIndex의 핵심인 구조적 추론 장점이 줄어들 수 있습니다.

PageIndex 벡터리스 RAG GitHub 레포를 도입하기 전에, 자신의 문서 유형·쿼리 빈도·비용 허용 범위를 먼저 따져 보는 게 좋습니다.

 

자주 묻는 질문

 

Q. PageIndex를 사용하려면 OpenAI API 키가 반드시 필요한가?
A. 셀프호스트 로컬 실행 시에는 CHATGPT_API_KEY 환경변수에 OpenAI API 키를 설정해야 합니다. 현재 Ollama 등 로컬 LLM은 지원하지 않습니다. 클라우드 서비스(pageindex.ai)를 이용하면 별도의 OpenAI 키 없이 PageIndex 자체 API 키로 사용할 수 있습니다.

Q. 98.7% 정확도는 모든 문서 유형에서 동일하게 나오는가?
A. 아닙니다. 98.7%는 FinanceBench(SEC 제출 금융 문서 QA) 한정 벤치마크 결과입니다. 계층 구조가 명확한 금융·법률 문서에서 강점이 크지만, 비구조적 문서나 다도메인 혼합 코퍼스에서의 정확도는 아직 독립적으로 검증되지 않았습니다.

Q. 셀프호스트와 클라우드 서비스 중 어떤 것을 선택해야 하는가?
A. 빠른 테스트나 소규모 프로젝트에는 셀프호스트(pip install)가 간편합니다. 복잡한 레이아웃의 PDF를 다루거나 OCR 품질이 중요한 경우에는 클라우드 서비스(pageindex.ai)의 강화된 파이프라인이 더 정확합니다. 클라우드 서비스는 ChatGPT 스타일 채팅 UI, REST API, MCP를 모두 지원합니다.

Q. 기존 LangChain+ChromaDB RAG에서 PageIndex로 전환할 가치가 있는가?
A. 구조화된 장문 문서에서 정확도 문제를 겪고 있거나 검색 결과의 출처 추적이 필수 요건인 환경이라면 전환을 시도할 가치가 있습니다. 이미 벡터 RAG로 90% 이상 정확도를 달성했고 설명 가능성이 필수 요건이 아니라면, 전환 비용 대비 실익이 크지 않을 수 있습니다.

참조 링크

 
PageIndex – 벡터DB 없이 추론 기반 RAG를 구현하는 오픈소스 이 글은 실제 사례를 바탕으로 작성되었습니다