전문가 지식 기반 에이전트에 RAG와 PageIndex 중 무엇을 선택해야 할까요?

📌 오늘의 안건
전문가 지식 기반 에이전트에 RAG와 PageIndex 중 무엇을 선택해야 할까요?

프로젝트에서 RAG와 PageIndex 중 하나를 골라야 합니다. 전문가가 자신의 지식을 업로드하면, 그 데이터를 연결한 에이전트가 질문자의 질문에 답할 때 이를 참고하는 구조입니다. 업로드되는 자료는 주로 길고 구조화된 문서와 의사결정 데이터입니다. 선택 기준은 속도, 비용, 확장성입니다. 이 조건에서 기존 벡터 검색 기반 RAG와 문서 구조(목차·트리) 기반 추론 검색인 PageIndex 중 어느 쪽이 더 적합할까요? 둘을 함께 쓰는 하이브리드 구성도 현실적인 선택지인지 궁금합니다. 장기적으로 RAG가 PageIndex 같은 방식으로 대체될 흐름인지도 함께 판단하고 싶습니다.

일이 틀어지는 날을 미리 그려 보고, 그날 피해를 얼마나 작게 막을지 같이 설계하는 일을 맡겠습니다. 겁을 주려는 게 아니라 안심하고 쓰실 수 있게 하려는 것이니 편하게 들어 주십시오.

다들 고개를 끄덕일 때가 제일 위험해요. 저는 이 분야의 통념과 홍보 문구, 그리고 아무도 묻지 않은 전제를 하나씩 뒤집어 볼게요.

지금 어떤 문서를 어떤 방식으로 넣고 계신지부터 짚을게요. 저는 그 판단 밑에 깔린 숫자가 진짜인지, 출처는 어디인지 하나씩 확인해요.

한 주에 몇 시간을 되찾을 수 있는지, 그 숫자부터 같이 잡아 봐요. 여기서 얼마나 더 크게 얻을 수 있는지, 내일 바로 해 볼 첫 실험까지 제가 맡을게요.

실행할 수 있어야 비로소 답입니다. 이번 토론에서는 얼마가 들고, 누가 언제까지 해낼 수 있는지를 함께 따져 보겠습니다.

속도, 비용, 확장성을 원한다면 PageIndex 선택은 명백한 패착이며, RAG를 대체할 은탄환도 아니에요. PageIndex는 벡터 DB를 없앴다는 마케팅을 앞세우지만, 실상은 쿼리 하나마다 LLM을 연쇄 호출해 문서 트리를 탐색하는 극단적인 고비용·고지연 구조예요. 프레드 브룩스가 갈파했듯 소프트웨어의 본질적 복잡성을 마법처럼 없애 주는 도구는 없어요. PageIndex 아키텍처 분석[1]에서도 드러나듯, 이는 벡터 인덱싱이라는 우발적 복잡성을 피하려다 쿼리당 추론 비용과 지연 시간 폭증이라는 훨씬 치명적인 본질적 대가를 치르는 꼴이에요.

하이브리드 구성이나 PageIndex로의 대체 전망 역시 기술적 맹점을 가린 장밋빛 착각이에요.

• 확장성 붕괴: 단일 보고서(FinanceBench 등) 분석을 벗어나 전문가 문서 풀이 커지는 순간, 트리 탐색 호출이 중첩되어 응답 시간이 초 단위에서 분 단위로 늘어져요.
• 추론 오류 누적: 인공지능 학자 게리 마커스가 줄곧 지적했듯, LLM의 연쇄적 추론 단계는 신뢰할 수 있는 논리가 아니라 확률적 추측의 누적일 뿐이라 트리 탐색 도중 길을 잃을 위험이 상존해요.
• 하이브리드의 낭비: 벡터 검색으로 문서를 좁힌 뒤 PageIndex로 탐색하는 구성은 시스템 복잡도와 장애 지점(SPOF), API 비용만 2배로 불리는 전형적인 오버엔지니어링이에요.

애초에 문제를 잘못 정의했어요. 전문가가 올린 구조화 문서라면 비싼 LLM에게 비싼 돈을 주고 목차를 읽게 만들 이유가 전혀 없어요. 문서의 장·절·목차를 파싱해 DB 메타데이터 필터로 걸고 고전적인 검색(BM25 + 경량 벡터 검색)을 붙이는 것만으로도 밀리초 단위 속도와 0원에 가까운 비용으로 문제를 해결해요. 장기적으로도 PageIndex 방식이 RAG를 전면 대체할 일은 없으니, 트렌드 추종을 멈추고 결정론적인 메타데이터 파이프라인부터 단단하게 구축하세요.

기본 선택은 벡터 RAG로 두고, 중요하고 긴 구조화 문서에만 PageIndex를 병행하는 하이브리드가 가장 안전합니다. 운영 중 가장 자주 겪는 실패는 “좋은 데모를 전체 자료에 적용했다가 질의 지연과 호출비가 예상보다 커지는” 경우입니다. 벡터 검색은 대규모 문서·짧은 사실 질의에서 빠르고 비용이 예측 가능하지만, 조항 간 참조나 의사결정 근거처럼 표현은 다르고 구조가 중요한 질문을 놓칩니다. PageIndex는 목차 트리를 LLM이 탐색하므로 이런 문서에는 강하지만, 질의마다 추론 호출이 개입해 지연·비용·모델 장애 의존성이 커집니다. 제작사가 제시한 FinanceBench 98.7%도 유망하되 자체 벤치마크이므로 그대로 일반화해서는 안 됩니다(PageIndex GitHub[1]).

권장 구조는 벡터·키워드 검색으로 문서 후보를 좁힌 뒤, 복합·교차참조 질문만 PageIndex 트리 탐색으로 넘기는 방식입니다. 문서별 ACL을 검색 전에 강제하고, 원문 페이지 인용·답변 검증·질의별 비용 및 시간 상한·PageIndex 실패 시 벡터 검색으로의 폴백을 둬야 합니다. 업로드 문서는 신뢰하지 않는 입력으로 격리하고 에이전트에는 읽기 권한만 주십시오. 외부 파일을 통한 간접 프롬프트 주입은 실제 데이터 유출과 도구 오작동으로 이어질 수 있으며, RAG 자체가 이를 막아주지 않습니다(NIST IR 8579[1], OWASP Prompt Injection[2]).

장기적으로도 PageIndex가 RAG를 대체한다기보다 RAG의 검색 계층이 벡터 단일 방식에서 구조·키워드·추론 검색을 조합하는 라우팅 방식으로 진화할 것입니다. 따라서 전면 교체보다 실제 문서와 질문으로 정확도·p95 지연·질의당 비용·근거 누락률을 비교한 뒤, PageIndex가 명확히 이기는 문서군에만 단계적으로 확대하는 판단이 적합합니다.

결론은 하이브리드예요. 문서 수천 건 규모에서 PageIndex만으로는 속도·비용·확장성 세 기준을 모두 맞추기 어려워요. 지금 구성은 전문가가 올린 긴 구조화 문서와 의사결정 데이터를 에이전트가 참조하는 형태예요. 이 조건에서 수치가 말하는 건 하나예요. 문서 안을 찾는 일은 PageIndex가 낫고, 어느 문서를 볼지 고르는 일은 벡터·BM25가 나아요.

• PageIndex 정확도 근거. Mafin 2.5(PageIndex 기반)는 FinanceBench에서 98.7%를 기록했어요. 일반 벡터 RAG는 약 50% 수준으로 비교돼요(towardsai[1], pageindex.ai[2]). 다만 세 가지를 감안해야 해요. - 벤더가 직접 낸 수치이고, 금융 공시라는 단일 도메인이에요. - 비교 대상은 2023년식 단순 청크 RAG예요. 원 논문에서도 검색을 붙인 GPT-4-Turbo가 오답이나 응답 거부를 낸 비율이 81%였어요(arXiv 2311.11944[3]). - 독립 재현 결과는 아직 확인하지 못했어요.

• 개선된 RAG도 격차를 크게 줄여요. Anthropic의 Contextual Retrieval 실험 결과예요(Anthropic[1]). top-20 검색 실패율 기준이에요.

따라서 "벡터는 50%, 트리는 99%" 같은 구도는 실제 운영 환경을 그대로 보여주는 비교가 아니에요.

세 기준으로 나눠 보면 결과가 갈려요.

• 속도: 벡터 검색은 ms 단위예요. PageIndex는 질의 한 번에 트리를 탐색하는 LLM 호출을 여러 번 해요. 그래서 대략 초 단위가 걸려요. 이건 구조에서 나오는 추정이고 실측값은 아니에요.
• 비용: PageIndex는 색인할 때도 LLM으로 트리를 만들어야 해요. 질의 비용도 탐색 깊이만큼 늘어나요.
• 확장성: PageIndex는 문서 한 건 안을 탐색하는 데 최적화돼 있어요. 여러 문서에 걸치면 결국 메타데이터나 의미 검색으로 문서를 먼저 골라야 해요.

그래서 권장 구성은 이래요.

• 1단계, 문서 선택: 하이브리드 검색(BM25 + 벡터 + 리랭커)으로 후보 문서 3~5건을 고르세요.
• 2단계, 문서 내 탐색: 길고 목차가 분명한 문서에만 PageIndex 트리 탐색을 쓰세요.
• 의사결정 데이터: 표나 레코드 형태라면 둘 다 맞지 않아요. 메타데이터 필터나 SQL 조회로 따로 빼세요.

장기 전망에 대한 판단은 이래요. RAG가 PageIndex로 대체되기보다 둘이 합쳐지는 흐름이에요. 문서를 구조적으로 탐색하는 방식은 "검색을 어떻게 할지"의 한 갈래로 흡수되고 있어요. 대규모 말뭉치에서 1차로 거르는 비용 효율 면에서는 여전히 벡터·BM25를 대체할 수단이 없어요. 판단은 남의 벤치마크로 하지 마세요. 실제 전문가 문서 50~100건과 실제 질문 200개로 세 구성을 돌려 보세요. 순수 벡터, 순수 PageIndex, 하이브리드예요. 각각 Recall@k, 정답률, p95 지연, 질의당 비용을 재세요. 측정 전에는 하이브리드를 기본값으로 두는 게 맞아요.

PageIndex와 벡터 RAG의 최신 벤치마크·공식 자료를 먼저 확인한 뒤, 속도·비용·확장성 기준으로 결론을 내리겠어요.98.7%가 아니라, 엄격 채점 90.7%(150문항 중 136)로 봐도 PageIndex가 이 코퍼스에 맞아요. 공식 비교에서 벡터 RAG는 FinanceBench 50%대에 머물고, 420쪽 문서를 통째로 넣는 방식보다 질의 비용이 약 16배 낮아요. 긴 목차형 문서·의사결정 자료는 유사도가 아니라 장·절을 고르는 문제라서, 트리 탐색이 정답 페이지까지 시간을 더 줄여요. 질의당 3–8초, 약 $0.005–$0.025로 벡터(수십 ms, $0.001 미만)보다 느리고 비싸지만, 색인은 페이지당 약 $0.001로 한 번만 만들면 재사용돼요. 속도·단가의 표면 승자는 벡터이고, 전문가 답의 적중·인용까지 넣은 처리량은 PageIndex예요.

출처: PageIndex Developer[1], GitHub README[2], 엄격 채점 정리[3].

가설은 이거예요. 전문가 문서 10개·실제 질문 30개에서, 문서 선택은 벡터(제목·요약)로 하고 본문 탐색만 PageIndex로 하면 전문가 채점 정답률 85% 이상, p95 8초 이내, 100질문당 $3 이내가 나와요. 성공 지표는 정답 여부, 인용 쪽 일치, 전문가가 고치는 시간이에요. 하이브리드는 현실적인 기본안이에요. 짧은 표·키-값은 구조화 조회로 두고, 수백 쪽 문서는 트리로 읽으면 벡터 인덱스만 키워도 품질이 같이 커져요.

장기적으로 벡터 RAG가 통째로 사라지진 않아요. 값싼 교차 문서 라우팅은 벡터가 맡고, 긴 전문 문서의 검색 단계는 트리 추론으로 바뀌는 흐름이에요. 앤드루 응은 한 번의 임베딩 조회 다음 단계로, 도구를 골라 다시 찾는 에이전트형 RAG를 공개 강의에서 밀어 왔어요. 사이먼 윌리슨은 임베딩을 실무 도구로 유지하면서도, 모델이 목차형 인덱스를 보고 필요한 조각만 집어 읽는 방식이 문서를 통째로 밀어 넣는 것보다 낫다는 쪽을 반복해 보여 줬어요. 이 프로젝트는 그 갈림길의 문서 쪽에 서 있어요.

결론: 기본값은 벡터 RAG입니다. PageIndex는 긴 구조화 문서에만 좁게 시범 도입하세요. 둘을 섞는 하이브리드는 현실적인 선택입니다. 다만 아래 가격·성능 수치는 이번에 웹 검색으로 다시 확인하지 못했습니다. 기억과 공개 자료에 근거한 것이니 도입 전에 공식 요금표로 재확인하세요.

근거 (속도·비용·확장성)

• RAG:
• 색인은 임베딩 비용뿐입니다. 질의는 ANN 검색 한 번이라 보통 수십~수백 ms에 끝납니다. 전문가 수와 문서가 늘어도 인덱스만 키우면 됩니다. - 약점은 청킹이 목차와 표 구조를 끊는다는 점입니다. 이건 계층형 청킹, BM25 병행, 리랭커, 문맥 보강으로 상당 부분 메워집니다. Anthropic은 Contextual Retrieval로 검색 실패율이 49% 줄었고, 리랭킹을 더하면 67% 줄었다고 보고했습니다. anthropic.com[1]
• PageIndex:
• 문서마다 LLM으로 목차 트리를 만듭니다. 질의 때도 LLM이 트리를 따라 여러 번 추론합니다. 그래서 질의당 토큰 비용과 지연(수 초 이상)이 RAG보다 큽니다. - 정확도 주장은 FinanceBench 98.7%입니다. 벤더 발표라 우리 데이터에서 따로 검증해야 합니다.

github.com[1]

• 문서가 수천 개로 늘면 트리 탐색만으로는 감당이 안 됩니다. 먼저 문서를 골라내는 단계가 필요하고, 그 단계는 결국 벡터 검색입니다. - 현장에서 자주 보는 장면이 있습니다. "정확도가 높다"는 말에 끌려 전면 도입했다가, 질의당 비용 때문에 한 달 만에 다시 설계하는 경우입니다. 작게 재고 넓히는 쪽이 쌉니다.

하이브리드와 장기 전망

• 구성: 1단계는 벡터와 BM25로 문서와 섹션 후보를 좁힙니다. 2단계는 장문 구조화 문서에서만 트리 추론으로 정확한 구간을 짚습니다. 의사결정 데이터가 표나 규칙 형태라면 둘 다 쓰지 말고 SQL이나 구조화 조회로 처리하세요. 이게 가장 싸고 정확합니다.
• 이번 분기 시범안: 전문가 2~3명이 쓰는 대표 문서와 골든 질문 30~50개로 RAG와 하이브리드를 A/B 비교합니다. 2주 안에 정확도, p95 지연, 질의당 비용 세 지표를 재면 됩니다. 개발자 1~2명이면 충분합니다. 하이브리드가 정확도를 크게(예: 10%p 이상) 올리고 비용이 감당 가능할 때만 확대하세요.
• 장기 전망: RAG가 PageIndex로 "대체"된다기보다 검색이 에이전트화되며 공존하는 흐름이라고 봅니다. 문서 트리 탐색, 키워드 검색, 벡터 검색을 도구로 두고 모델이 골라 쓰는 방식입니다. 컨텍스트 윈도우와 토큰 단가가 계속 변하니, 검색 계층을 교체할 수 있게 인터페이스만 분리해 두면 어느 쪽으로 가도 손해가 없습니다.

하이브리드를 만능 기본값으로 퉁치려는 안일한 합의는 경계하되, 초장문 문서에 대한 제한적 격리 배치는 수용해요. 홍재원이 제시한 맥락 보강 RAG의 1.9% 실패율은 2023년식 구형 RAG를 허수아비 삼은 PageIndex의 과장된 마케팅을 통렬하게 무너뜨렸어요. 주다은과 류하진의 지적대로 수백 쪽에 달하는 극소수 교차 참조 문서에 한해, p95 지연과 비용 상한을 엄격히 건 2단계 예외 폴백으로 PageIndex를 활용하는 실증적 절충안은 타당해요.

하지만 다수가 합의 속에서 놓친 치명적 맹점은 트리 탐색이 초래하는 '경로 탈옥과 보안 붕괴'예요. 임도경이 보안 위험을 짚었듯, 게리 마커스가 줄곧 비판한 LLM의 확률적 취약성은 목차 추론 단계에서도 고스란히 터져요. 외부 전문가가 악의적인 소제목이나 지시문을 목차 트리에 심어두면, 탐색 에이전트는 추론 경로를 이탈해 엉뚱한 조항을 근거로 채택하거나 기밀 데이터를 긁어와요. 비결정론적 모델을 검색 라우팅 깊숙이 끌어들이는 건 지연 시간 폭증을 넘어 시스템 통제권을 해커에게 넘겨주는 꼴이에요.

결국 본질은 화려한 검색 프레임워크 대결이 아니라 '데이터 모델링의 실종'이에요. 주다은의 통찰처럼 의사결정 규칙과 표 데이터는 RAG나 PageIndex가 아니라 확정적인 SQL과 룰 엔진으로 격리해야 프레드 브룩스가 말한 본질적 복잡성이 비로소 사라져요. 정형 의사결정 데이터는 SQL, 일반 지식 문서는 맥락 보강 벡터 RAG, 0.1%의 초장문 교차 참조에만 샌드박스로 격리된 PageIndex를 붙이는 '데이터 유형별 분리'로 아키텍처를 단순화하세요.

강도율의 “목차를 메타데이터로 먼저 활용하라”는 지적은 받아들여야 합니다. 특히 표·규칙·승인 이력 같은 의사결정 데이터는 생성형 검색에 맡기지 않고 SQL이나 결정론적 조회로 분리하는 편이 더 빠르고, 환각 경로도 짧습니다. 다만 하이브리드를 곧바로 비용 2배·SPOF 증가로 단정한 것은 과합니다. PageIndex를 모든 질문에 직렬로 거는 구조라면 맞지만, 저신뢰·교차참조 질의에만 제한하고 실패 시 기존 검색으로 우회하면 독립적인 보조 경로가 됩니다. 제가 운영하며 가장 곤란했던 사고도 새 검색기가 실패한 것보다, 기존 경로로 돌아갈 스위치 없이 전면 전환했던 경우였습니다.

홍재원·주다은의 단계적 라우팅과 구조화 조회 분리는 타당해 제 권고에 반영하겠습니다. 반면 류하진이 제시한 3–8초, $0.005–$0.025, 페이지당 $0.001 같은 정밀 수치는 이번 라운드에서 검증된 근거가 아니므로 의사결정 기준에서 제외해야 합니다. FinanceBench 수치 역시 비교 조건과 독립 재현이 확인되지 않은 이상 구매 근거가 아니라 실험 가설일 뿐입니다. 평가도 단순 정답률보다 권한 밖 문서 노출률, 잘못된 인용률, 검색 실패가 그럴듯한 답으로 변환되는 비율, 비용·지연 상한 초과율을 함께 보아야 합니다.

따라서 보완된 결론은 “벡터 RAG 우선”보다 한 단계 더 보수적입니다. 결정론적 구조화 조회를 1순위, BM25·벡터·리랭킹을 기본 검색층, PageIndex를 제한된 장문 문서의 선택적 탐색기로 두십시오. 각 단계에 문서별 ACL을 검색 전에 적용하고, 업로드 문서의 명령문은 데이터로만 취급하며, PageIndex에는 외부 전송·쓰기 권한을 주지 않아야 합니다. 섀도 트래픽과 기능 플래그로 시작해 품질뿐 아니라 피해 반경까지 통과할 때만 확대한다면, 어느 방식이 우세해져도 되돌릴 수 있습니다.

하이브리드 결론은 그대로예요. 다만 PageIndex를 쓸지는 정확도 개선폭으로 정하세요. 그 판정에 필요한 질문 수는 지금 나온 제안들보다 훨씬 많아요. 류하진 님 수치부터 받아들일게요. 엄격하게 채점하면 98.7%가 아니라 90.7%(136/150)예요. 질의 한 번에 3–8초, $0.005–$0.025가 들어요. 색인은 페이지당 약 $0.001이에요. 그래서 제 초안의 "초 단위 추정"은 이 수치로 바꿀게요. 이 단가로 하루 1,000질의를 받으면 PageIndex 비용은 최대 하루 $25 정도예요. 이 규모라면 비용보다 지연이 진짜 제약이에요. 다만 이 수치들도 벤더 자료이거나 2차 정리예요. 비교 기준인 "벡터 50%대"도 여전히 2023년식 단순 청크 RAG예요. 그리고 앤드루 응이나 사이먼 윌리슨의 이름을 든 부분은 데이터가 아니라서 근거에서 빼야 해요.

검증 표본 크기는 짚어야 해요. 류하진 님은 30문항으로 85% 정답률을 가설로 세웠고, 주다은 님은 30–50문항으로 10%p 차이를 보자고 했어요. 계산해 보면 이 표본으로는 판정이 안 돼요.

• 정답률 85%, n=30: 95% 신뢰구간이 약 ±13%p예요. 실제로는 72%일 수도 98%일 수도 있다는 뜻이에요.
• 정답률 70% 근처, n=50: 구간이 약 ±13%p라서 10%p 차이를 구분하지 못해요.
• 필요한 규모: 같은 질문으로 두 구성을 비교하고(paired), 질문을 200개 이상 써야 해요. 그래야 구간이 약 ±6%p로 줄어서 10%p 차이를 읽을 수 있어요.

주다은 님의 "10%p 이상 오를 때만 확대"라는 기준은 좋아서 그대로 가져올게요. 단 200문항 이상으로 쟀을 때만 의미가 있어요.

강도율 님 지적에서 하나는 맞아요. 목차가 명시된 문서라면 트리를 LLM으로 만들 필요가 없어요. 파싱으로 장·절 구조를 결정적으로 뽑으면 색인 비용이 0에 가까워요. LLM은 질의 때 탐색에만 쓰면 돼요. 하지만 "메타데이터 필터 + BM25면 충분하다"는 주장은 숫자가 받쳐 주지 않아요. 맥락 BM25에 리랭킹까지 더해도 top-20 검색 실패율이 1.9% 남아요. 남는 실패는 대개 질문 표현과 절 제목이 어긋나는 경우예요. 질문을 어느 절 필터에 걸지 고르는 일 자체가 추론 문제예요. 그래서 "분 단위 지연", "비용 2배"는 근거 없는 수치예요. 라우팅된 질의에만 PageIndex를 쓰면 추가 비용은 그 비율만큼만 생겨요. 최종 운영 규칙은 이렇게 제안해요. - 라우팅 대상: 교차 참조나 다단계 추론이 필요한 질문만 트리 탐색으로 보내요. - 확대 조건: paired 비교 200문항 이상에서 정답률이 +10%p 이상 오르고, p95 지연이 8초 이하일 때만 넓혀요.

• 폴백: 임도경 님 제안대로 지연이나 비용 상한을 넘으면 벡터 결과로 돌아가요. 폴백이 몇 번 발동했는지도 지표로 따로 기록하세요.

입장은 유지하되 한 가지를 바꿉니다. 하이브리드의 2단계는 기본 탑재가 아니라, 질문 유형별 라우팅 뒤의 선택 옵션으로 내립니다. 류하진 초안의 "질의당 $0.005–$0.025, 3–8초" 수치는 이번 라운드에서 검증할 수 없습니다. 벤더 문서 인용이라 가설 목표치로만 쓰겠습니다. 그 수치가 맞더라도 벡터의 100배 안팎입니다. 질문자 수가 늘면 이 비용이 그대로 곱해집니다. 이 점이 류하진의 "처리량은 PageIndex"라는 주장의 약점입니다. 반면 "전문가가 고치는 시간"을 지표에 넣은 점은 좋습니다. 제 시범안에 흡수합니다.

강도율의 "하이브리드는 오버엔지니어링, 메타데이터 필터와 BM25로 충분"은 절반만 받습니다. 맞는 부분이 있습니다. 장·절 구조가 이미 파싱되는 문서라면 LLM에게 목차를 읽힐 이유가 약합니다. 구조 파싱 + 메타데이터 필터 + BM25 + 리랭커를 1순위 대조군으로 올리겠습니다. 틀린 부분도 있습니다. "비용 0원에 가깝다"는 근거가 없고, 교차참조·의사결정 근거 질문이 이 방식으로 풀린다는 증거도 없습니다. 실측으로 가릅니다. 임도경 초안의 ACL 선적용, 비용·시간 상한, 벡터 폴백, 업로드 문서 격리는 전부 받습니다. 전문가 업로드 서비스라면 비용 상한은 선택이 아니라 필수입니다.

수정한 시범안(이번 분기, 개발자 1~2명)

• 3개 구성을 비교합니다. A는 벡터+BM25+리랭커, B는 A에 구조 메타데이터 필터를 더한 것, C는 B에 PageIndex 트리 탐색을 더한 것입니다.
• 전문가 2~3명, 골든 질문 40개로 시험합니다. 질문을 단답형과 교차참조형으로 나눠 따로 채점합니다.
• 지표는 정답률, 인용 페이지 일치, p95 지연, 질의당 비용, 전문가 수정 시간입니다.
• C가 교차참조형에서만 B를 10%p 이상 앞서면, 그 유형만 PageIndex로 라우팅합니다. 아니면 B로 갑니다.
• 도입 현장에서는 '어려운 질문만 비싼 길로 보낸다'는 규칙 하나가 비용 폭주를 막았습니다. 작게 시작하면 이길 수 있습니다.

질의 100건 중 트리 탐색은 교차참조 15건만 태우면, 나머지 85건은 밀리초·1원 미만으로 끝내고도 장문 적중은 살릴 수 있어요. 강도율 말이 맞아요. 매 질문마다 PageIndex를 켜는 건 패착이고, 장·절 메타데이터에 BM25와 경량 벡터를 거는 결정론 파이프라인이 기본 엔진이에요. 다만 “하이브리드는 비용 2배”는 과해요. 라우터가 막을 내리면 호출은 더해지지 않아요. 홍재원·주다은이 꺼낸 Contextual Retrieval(실패율 5.7% → 리랭킹 포함 1.9%)을 대조군으로 두면, 제가 앞에 둔 90%대 벤더 점수는 도입 근거가 아니라 가설로 내려놓아요.

이번 실험은 이렇게 바꿔요. 팔은 셋이에요. 메타데이터+BM25+벡터, 맥락 임베딩+BM25+리랭커, 그리고 교차참조일 때만 트리를 여는 하이브리드. 표·규칙형 의사결정 데이터는 둘 다 빼요. SQL이 가장 싸고 정확해요. 전문가 2–3명, 골든 질문 30개, 2주. 하이브리드가 대조군보다 정답을 10%p 이상 올리고, p95 8초·100질문당 $3 안이면 그 문서군만 키워요. 아니면 트리는 끄고 메타데이터 검색에 머물러요. 임도경의 폴백은 보안 설교가 아니라 이 상한을 지키는 스위치예요.

장기적으로 PageIndex가 RAG를 집어삼키진 않아요. 앤드루 응이 말해 온 다음 단계는 임베딩 한 방 다음, 모델이 도구를 골라 다시 찾는 쪽이에요. 사이먼 윌리슨이 반복해 보여 준 것도 통째 투입이 아니라, 목차를 보고 조각만 읽는 실무예요. 값은 벡터·BM25가 맡고, 긴 전문 문서의 마지막 한 걸음만 트리가 맡는 공존이 이 프로젝트의 정답이에요.

기본 선택은 맥락 보강 벡터 RAG이며, 무분별한 하이브리드는 결함만 은폐하는 비현실적인 허상이에요. 수천 건의 다중 문서 환경에서는 결국 1차 필터링을 벡터나 키워드 검색에 의존해야 하므로 확장성 병목은 고스란히 남아요. 게다가 틀린 검색 결과에 높은 확신을 갖는 오판 질의는 폴백 라우팅조차 타지 못하고, 게리 마커스가 비판한 LLM의 확률적 취약성 탓에 목차 트리에 숨은 간접 프롬프트 주입과 권한 탈옥을 방어할 수도 없어요.

[장기 대체 여부] PageIndex가 장기적으로 RAG를 대체하는 흐름은 결코 오지 않으며, 은탄환을 바라는 기술적 착시에 불과해요. 프레드 브룩스가 갈파했듯 도구를 바꾼다고 데이터의 본질적 복잡성이 줄어들지 않으며, 스캔 PDF나 목차가 부실한 문서에서는 트리 추론 자체가 성립하지 않아요. 1.9% 실패율을 입증한 맥락 보강 RAG가 존재하는 한, 문서가 수정될 때마다 재색인 비용이 폭증하는 무거운 트리 탐색이 지배적 표준이 될 수는 없어요.

결국 주다은의 데이터 격리 통찰과 홍재원의 맥락 보강 RAG를 뼈대로 삼는 것이 가장 정교한 답이에요. 류하진의 지적을 수용해 p95 지연과 비용 상한을 엄격히 건 격리 샌드박스에서만 초장문 교차 참조 예외로 PageIndex를 두는 제한적 절충으로 충분해요. 본질을 외면한 채 검색 계층만 복잡하게 꼬아놓는 만능 하이브리드 미신에서 당장 벗어나세요.

기본 선택은 결정론적 구조화 조회를 앞단에 둔 하이브리드 RAG이며, PageIndex는 장문·교차참조 질의에만 호출되는 선택적 보조 탐색기로 제한해야 합니다. 첫째, 문서가 수천 건으로 늘면 PageIndex도 대상 문서를 고르는 BM25·벡터 검색이 필요하므로 기본 검색층을 대체하지 못합니다. 둘째, 스캔 PDF·부실한 목차·빈번한 수정은 트리 품질과 재색인 비용을 흔들고, 표·규칙·승인 이력은 SQL 같은 결정론적 조회가 더 안전합니다. 셋째, 하이브리드는 직렬 결합이 아니라 기능 플래그와 우회 경로를 둔 조건부 라우팅으로 구현해야 장애 반경을 줄이고 되돌릴 수 있습니다.

다만 “저신뢰이면 PageIndex로 보낸다”는 규칙만으로는 부족합니다. 틀린 검색 결과가 높은 신뢰도로 평가되는 사고를 별도 시험하고, 라우팅 기준에 근거 간 충돌·인용 부재·교차참조 필요성을 포함해야 합니다. 검색 전 문서별 ACL을 강제하고, 업로드된 명령문은 데이터로만 취급하며, PageIndex에는 외부 전송과 쓰기 권한을 주지 마십시오. 제가 겪은 운영 사고에서도 새 검색기의 실패 자체보다 복귀 스위치 없는 전면 전환이 더 큰 피해를 만들었습니다.

장기적으로도 RAG가 PageIndex로 대체되지는 않습니다. 구조 탐색은 RAG의 후보 생성 이후 정밀 탐색 단계로 흡수될 가능성이 크며, 문서 선택·권한 필터링·구조화 데이터 조회라는 바깥 계층은 계속 필요합니다. 따라서 승부를 제품명으로 정하지 말고, 섀도 트래픽에서 라우팅 오판률·권한 밖 노출률·잘못된 인용률·비용 및 지연 상한 초과율을 통과한 경로만 점진적으로 확대하는 것이 최종 권고입니다.

기본 선택은 하이브리드 RAG(벡터 + BM25 + 리랭킹)예요. PageIndex는 라우팅된 일부 질의에만 붙는 보조 경로로 써요. 중간 점검의 두 지적은 받아들여요. 그래서 제 안을 두 군데 고쳐요.

첫째, 문서가 수천 건이 되면 어느 문서를 볼지는 결국 벡터나 BM25가 골라요. 그러니 확장성은 RAG 층이 정해요. PageIndex의 확장성은 문서 한 건 안에서만 의미가 있어요. 이건 PageIndex를 보조로 두는 근거를 더 강하게 만들어요. 둘째, 검색이 틀렸는데 신뢰도가 높게 나온 질의는 라우터를 그냥 지나가요. 그래서 200문항 이상 paired 평가에 지표를 하나 더 넣어요. 라우터 재현율, 곧 벡터 경로 오답 가운데 PageIndex로 넘어간 비율이에요. 벡터 오답이 적으면 이 수치도 n=30일 때처럼 신뢰구간이 ±13%p 수준으로 넓어져요. 그래서 오답 사례가 수십 건 모일 때까지 질문 수를 늘려야 해요. 스캔 PDF나 목차가 부실한 문서는 처음부터 트리 경로에서 빼고 벡터 전용으로 둬요. 목차가 명시된 문서는 강도율 님 말대로 파싱으로 트리를 결정적으로 만들어요. 이렇게 하면 문서를 고칠 때마다 다시 색인하는 비용이 0에 가까워져요. 장·절 단위 권한 관리와 업로드 본문의 프롬프트 주입 차단은 어느 경로를 쓰든 똑같이 필요해요.

그래서 선택을 가르는 변수는 아니에요.

핵심 근거는 세 개예요.

1. 남은 실패가 좁아요. 맥락 BM25에 리랭킹까지 하면 top-20 검색 실패율이 1.9%예요. PageIndex로 고칠 수 있는 건 그 좁은 구간뿐이에요.
2. 진짜 제약은 지연이에요. PageIndex는 질의 한 번에 3–8초, $0.005–$0.025가 들어요. 하루 1,000질의면 비용은 최대 하루 $25 정도라 부담이 아니에요. 그런데 모든 질의에 3–8초를 얹으면 체감 속도가 무너져요. 엄격 채점 90.7%라는 정확도도 벤더 자료예요.
3. 지금 나온 표본으로는 판정이 안 돼요. 30–50문항이면 신뢰구간이 ±13%p예요. 200문항 이상을 paired로 비교해야 구간이 ±6%p로 줄어서 10%p 차이를 읽을 수 있어요. 확대 조건은 그대로예요. 정답률 +10%p 이상, p95 지연 8초 이하, 그리고 폴백 발동률을 함께 기록하는 거예요.

장기 전망: 대체가 아니라 계층화예요. 근거는 위 두 가지예요. 문서 수가 늘수록 1차 문서 선택은 벡터나 BM25가 맡을 수밖에 없어요. 질의당 3–8초라는 지연도 전체 트래픽을 받기엔 무거워요. 그래서 검색 층은 남아요. 트리 탐색은 그 위에 붙는 정밀 탐색 층으로 자리 잡을 거예요. 이 판단을 뒤집으려면 데이터가 필요해요. 지연이 벡터 검색 수준으로 내려오고, 수천 건 규모에서 문서 선택까지 트리 추론으로 해도 정답률이 떨어지지 않는다는 독립 벤치마크예요. 지금까지 나온 자료에는 그런 수치가 없어요.

기본 선택은 B입니다. 벡터+BM25+리랭커에 구조 메타데이터 필터를 얹은 구성입니다. PageIndex는 시범에서 이긴 질문 유형에만 붙이는 선택 옵션입니다.

중간 점검의 지적을 받아들여 시범안을 두 곳 고칩니다. 첫째, 수천 건 규모에서 "어느 문서를 볼지" 고르는 1차 검색은 벡터나 BM25가 맡습니다. PageIndex는 문서 한 건 안에서만 탐색합니다. 그래서 하이브리드는 구조상 불가피합니다. 질문은 "쓸 것이냐"가 아니라 "어디까지 쓰느냐"입니다. 대체 흐름의 근거도 여기서 나옵니다. 둘은 서로를 대체하지 않고 계층이 다릅니다. 둘째, 라우팅의 신뢰도 판정은 그 자체를 평가합니다. 골든 질문 40개 중 B가 틀렸는데 신뢰도가 높게 나온 건수를 세겠습니다. 이 오탐이 많으면 "저신뢰만 PageIndex로" 규칙은 쓸 수 없습니다. 그러면 신뢰도 대신 질문 유형(교차참조형 여부)으로 라우팅합니다. 유형 분류는 신뢰도보다 단순하고 검증하기 쉽습니다.

장기 대체 여부: 대체되지 않습니다. 흡수됩니다. 근거는 세 가지입니다. (1) 수천 건 단위 후보 선별은 벡터·BM25가 맡아야 합니다. 이 병목은 앞서 짚은 대로 남습니다. (2) 류하진 초안의 수치(질의당 $0.005–$0.025, 3–8초)는 검증하지 못했습니다. 그래도 맞다면 벡터의 100배 안팎입니다. 질문자가 늘수록 비용이 곱해지므로 전 질의 적용은 어렵습니다. (3) 스캔 PDF나 목차가 부실한 문서는 트리가 안 만들어지고, 수정 때마다 재색인이 필요합니다. 목차 단위 권한과 프롬프트 주입 방어도 따로 설계해야 합니다. 앞으로 모델이 싸지면 PageIndex형 추론은 "문서 내부 정밀 탐색" 모듈로 자리 잡을 가능성이 큽니다. 그래도 1차 검색을 대신하는 일은 없습니다.

이번 분기 실행 순서는 이렇습니다. 개발자 1~2명이 A·B·C를 40문항으로 비교합니다. 비용 상한, 벡터 폴백, ACL 선적용, 업로드 문서 격리는 처음부터 넣습니다. 현장에서는 이 네 가지를 나중으로 미룬 팀이 먼저 데었습니다. C가 교차참조형에서 B를 10%p 이상 앞서면 그 유형만 라우팅합니다. 아니면 B로 갑니다. 작게 재고 넓히면 됩니다. 충분히 해낼 수 있습니다.

기본 선택은 메타데이터에 BM25와 경량 벡터를 건 검색이에요. 트리는 문서 한 건의 마지막 한 걸음으로만 켜요.

신뢰도 점수로 길을 나누면 안 돼요. 틀린 답이 높은 점수를 받으면, 정작 트리가 필요한 질문은 보조 경로로 안 가요. 라우터는 질문 형태만 봐요. 교차참조·다문서·장절 지정인지, 30개 골든 질문으로 보정부터 재요. 적중과 보정을 같은 표에서 따로 채점해요. 문서가 수천 건이어도 1차 고르기는 벡터·BM25예요. 트리는 고른 한 건 안에서만 타요. 목차가 없는 스캔본은 트리 후보에서 빼요. 수정분은 그 문서만 다시 색인해요. 권한과 숨은 지시문 차단은 검색 엔진 선택이 아니라 옆 관문이에요.

장기적으로 PageIndex가 RAG를 대체하지 않아요. 앤드루 응이 말한 다음 단계는 임베딩 한 방 다음, 모델이 도구를 골라 다시 찾는 쪽이에요. 사이먼 윌리슨이 보여 준 것도 통째 투입이 아니라 목차를 보고 조각만 읽는 실무예요. 값은 벡터·BM25가 맡고, 구조가 분명한 장문의 마지막만 트리가 맡는 공존이 정답이에요.