최근 PageIndex가 "벡터 없이 RAG를 한다"는 메시지로 빠르게 주목받고 있습니다. 핵심은 단순합니다. 문서를 잘게 쪼개 유사도로 찾는 대신, 문서의 목차와 계층 구조를 트리로 만들고 LLM이 그 구조를 따라가며 답이 있을 법한 위치를 추론한다는 것입니다.12
왜 지금 중요할까요. 많은 팀이 RAG 문제를 자동으로 "검색 문제"로 취급해 왔기 때문입니다. 하지만 계약서, 10-K, 정책집, 기술 매뉴얼처럼 길고 구조가 강한 문서는 종종 검색보다 "탐독과 항해"에 가깝습니다. PageIndex가 던지는 질문은 벡터가 좋으냐 나쁘냐가 아니라, 당신의 문제를 정말 최근접 이웃 검색으로 풀어야 하느냐는 것입니다.
진짜 판단 기준: 사실을 찾는 일인가, 문서를 따라가는 일인가
확인된 사실부터 보죠. PageIndex는 PDF나 Markdown에서 목차형 트리를 만들고, 각 노드에 제목·요약·페이지 범위 같은 정보를 붙입니다. 질의가 들어오면 전체 텍스트를 바로 뒤지지 않고, 먼저 이 구조를 보고 어떤 섹션을 읽어야 할지 LLM이 고릅니다.23
이 방식이 강한 곳은 문서 구조 자체가 의미를 갖는 경우입니다. 예를 들어 재무보고서의 본문과 각주, 계약서의 조항과 예외, 매뉴얼의 증상-원인-조치 흐름처럼 답이 "어느 섹션에 있어야 하는가"와 강하게 연결된 문서입니다. 이런 환경에서는 벡터 검색의 "비슷한 문장"보다, "답이 나올 만한 장과 절"을 찾는 편이 더 인간적인 접근입니다.
반대로 사내 위키, 슬랙 로그, 짧은 FAQ 묶음처럼 구조보다 표현 다양성이 큰 데이터라면 이야기가 달라집니다. 이런 환경에서는 넓은 의미적 회수를 잘하는 벡터 검색이 여전히 유리할 수 있습니다. PageIndex는 문서를 잘 읽는 방식이지, 모든 지식 저장소를 잘 훑는 방식은 아닙니다.
PageIndex가 이기는 자리와, 오히려 복잡해지는 자리
PageIndex 측은 벡터 DB 불필요, 청킹 불필요, 추적 가능한 검색 경로를 장점으로 내세웁니다. GitHub와 공식 설명을 보면 실제로 페이지·섹션 단위의 참조성과 설명 가능성을 강하게 밀고 있습니다.23 FinanceBench에서 98.7% 정확도를 언급하는 자료도 있습니다.2 다만 이 수치는 특정 벤치마크와 특정 제품 구성의 결과이므로, 곧바로 모든 문서 QA에 일반화하긴 어렵습니다.
실무적으로 더 중요한 건 실패 방식입니다. 벡터 RAG는 틀려도 "왜 이 청크가 뽑혔는지"가 흐릴 때가 많습니다. PageIndex는 적어도 어떤 노드를 읽었는지는 드러납니다. 이건 고정밀 산업에서 꽤 큽니다. 법무, 금융, 규제 대응처럼 답보다 근거 경로가 더 중요한 팀에게는 특히 그렇습니다.
하지만 공짜는 아닙니다. 구조 생성과 노드 요약 자체가 LLM 호출에 의존하고, 질의 때도 트리 탐색 추론이 들어갑니다. 즉 임베딩 비용은 줄어도 추론 비용과 지연시간이 생깁니다.3 문서 구조가 부실하거나 질문이 모호하면, 잘못된 가지로 내려가는 문제도 생깁니다. "청킹 튜닝"이 사라지는 대신 "트리 품질과 탐색 정책"이 새 운영 포인트가 됩니다.
벤치마크보다 먼저 봐야 할 평가 항목
도입 전에는 정확도 하나만 보지 말고 다섯 가지를 확인하는 편이 낫습니다.
첫째, 답이 아니라 근거를 검증하세요. 페이지와 섹션 참조가 실제로 사람 검토에 도움이 되는지 봐야 합니다.
둘째, 실패가 잘 보이는지 보세요. 틀린 답보다 위험한 건 틀렸는지 알 수 없는 답입니다. PageIndex는 이 지점에서 강점이 있지만, 전제는 트리와 요약이 믿을 만해야 한다는 점입니다.
셋째, 긴 문서에서의 지연시간을 재세요. 특히 100페이지 이상 문서와 복수 섹션을 오가는 질문에서 체감 성능이 갈립니다.
넷째, 유지보수 비용을 비교하세요. 벡터 DB가 빠진다고 시스템이 무조건 단순해지는 건 아닙니다. 색인 생성, 요약 품질, 모델 비용 관리가 새 복잡성으로 들어옵니다.
다섯째, 처음부터 전면 교체를 가정하지 마세요. 실제로는 하이브리드가 가장 현실적입니다. PageIndex는 한 문서 안 깊은 탐색을 맡고, 벡터 검색은 여러 문서 중 후보를 넓게 찾는 역할을 맡는 식입니다. 공식 자료에서도 하이브리드 트리 서치 방향이 언급됩니다.4
PageIndex를 지금 당장 진지하게 봐야 할 사람은 분명합니다. 길고 구조적인 전문 문서를 다루고, "맞는 답"만큼 "왜 그 답인지"가 중요한 팀입니다. 반대로 대규모 비정형 코퍼스에서 빠른 의미 검색이 핵심이라면, 아직은 벡터 DB를 버릴 이유가 약합니다. 중요한 건 새 유행을 택하는 일이 아니라, 당신의 문서 작업이 검색에 가까운지, 독해에 가까운지 먼저 구분하는 일입니다.
참고
1RAG Without Vectors: How PageIndex Retrieves by Reasoning
3PageIndex: Next-Generation Vectorless, Reasoning-based RAG
4PageIndex -- 벡터 DB 없이 문서 구조와 LLM 추론으로 검색하는 reasoning-based RAG
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.