RAG는 검색 문제가 아니라 문서 라우터 문제다

많은 팀이 RAG를 벡터DB 검색으로 시작하지만 실제 실패는 검색 전에 터진다. 문서를 어떻게 파싱하고, 언제 Graph RAG나 Agentic RAG로 보낼지 정하는 라우터가 2026년 AI 지식베이스의 핵심이다.

RAG를 처음 만들 때 우리는 보통 이렇게 생각한다. “문서를 쪼개고, 임베딩하고, 벡터DB에서 검색하면 되겠지.” 그런데 실제 제품에서는 검색 전에 더 자주 무너진다. PDF가 제대로 안 읽히고, 표가 깨지고, 문서 간 관계를 놓치고, 단순 Q&A에 에이전트까지 붙여 비용을 태운다. 2026년의 RAG는 검색 엔진이 아니라 문서 라우터로 봐야 한다.

TL;DR

RAG 실패의 상당수는 “검색 알고리즘”보다 문서 파싱, 구조 선택, 비용 라우팅, 검증 루프에서 발생한다.
Standard RAG, Graph RAG, Agentic RAG는 난이도 순서가 아니라 데이터/과업에 맞는 선택지다.
MinerU와 MarkItDown 사례는 문서 종류에 따라 GPU/VLM 파서와 경량 CPU 변환기를 나누는 전략을 보여준다.
Herculaneum 두루마리 해독은 문서 AI가 OCR 하나가 아니라 복원·분할·검출·전사·검증·공개 재현성의 전체 파이프라인임을 보여준다.
Frandeer가 바로 만들 수 있는 유틸은 “RAG Architecture Picker”, “Document Parser Router”, “Knowledge Base Readiness Checklist”다.

1. 많은 RAG 프로젝트는 너무 늦게 질문한다

RAG 프로젝트에서 흔한 첫 질문은 이것이다.

어떤 벡터DB를 쓸까?

중요한 질문이긴 하다. 하지만 너무 늦은 질문이다.

그 전에 물어야 할 것이 있다.

이 문서는 어떤 방식으로 읽혀야 하는가?
이 질문은 단순 검색으로 충분한가, 관계 추론이 필요한가?
실패했을 때 무엇으로 검증할 것인가?

많은 팀이 문서를 전부 같은 파이프라인으로 밀어 넣는다.

PDF도 같은 방식
Excel도 같은 방식
PPT도 같은 방식
스캔 이미지도 같은 방식
표와 수식이 있는 논문도 같은 방식
회의록과 정책 문서도 같은 방식

그리고 결과가 안 좋으면 모델을 바꾼다.

하지만 문제는 모델이 아닐 수 있다. 문서가 잘못 읽혔거나, 관계가 사라졌거나, 애초에 Agentic RAG가 필요 없는 질문에 너무 비싼 루프를 붙였을 수 있다.

RAG는 “검색”이라기보다 먼저 라우팅이다.

2. Standard, Graph, Agentic RAG는 계급이 아니다

LinkedIn에서 공유된 3 RAG Architectures 글은 단순하지만 중요한 구분을 준다.

Standard RAG

user prompt → embeddings → vector storage → top-K chunks → LLM

빠르고 단순하다. FAQ, 매뉴얼 Q&A, 평평한 문서 검색에 좋다.

하지만 약점도 명확하다.

여러 문서에 흩어진 정보를 엮는 질문
사람/회사/제품/계약 조건처럼 관계가 중요한 데이터
“A가 B에 영향을 줬고, B가 C와 연결된다” 같은 다단 추론

이런 경우에는 top-K chunk만으로 부족하다.

Graph RAG

user prompt → entity extraction → knowledge graph → linked context → LLM

문서 안의 사람, 조직, 제품, 법률 조항, 논문 개념처럼 연결이 중요한 경우에 강하다.

예를 들어 이런 질문이다.

이 고객사의 보안 요구사항 중 우리 제품 로드맵과 충돌하는 것은 무엇인가?

단순 chunk 검색보다 관계를 따라가야 한다.

Agentic RAG

user prompt → reasoning agent → vector + graph + web + tools → self-evaluation → final answer

가장 유연하지만 비용과 디버깅 난이도가 오른다. 모든 RAG를 agentic하게 만들면 멋있어 보이지만, 운영에서는 낭비일 수 있다.

정리하면 이렇다.

고급 아키텍처가 좋은 아키텍처가 아니다. 문제와 데이터에 맞는 아키텍처가 좋은 아키텍처다.

3. 문서 파싱도 라우터가 필요하다

정민철 님의 MinerU + MarkItDown 하이브리드 파싱 전략은 RAG 앞단을 잘 보여준다.

기업 문서는 한 종류가 아니다.

복잡한 PDF
스캔본 이미지
수식이 있는 논문
다단 레이아웃 보고서
Excel
Word
PowerPoint
단순 텍스트 기획서

이걸 한 도구로 처리하면 둘 중 하나가 된다.

모든 문서에 비싼 VLM/GPU 파서를 써서 비용이 터진다.
모든 문서에 가벼운 변환기를 써서 복잡한 문서가 깨진다.

그래서 제안은 단순하다.

앞단에 document router를 둔다.

예시:

복잡한 표, 수식, 스캔, 다단 레이아웃 → MinerU
일반 Word/Excel/PPT/텍스트 문서 → MarkItDown
이미 깨끗한 Markdown/HTML → 경량 정규화만 수행
중요한 계약/정책 문서 → 사람이 검수하는 queue로 보냄

이건 작은 차이처럼 보이지만 제품에서는 크다.

RAG의 품질은 검색 순간에 결정되지 않는다. 문서가 처음 들어오는 순간부터 결정된다.

4. 두루마리 해독이 RAG 팀에게 주는 힌트

Herculaneum 두루마리 해독 사례는 얼핏 고대 문헌 연구 이야기처럼 보인다. 하지만 문서 AI 관점에서는 매우 실용적인 힌트를 준다.

닫힌 두루마리를 물리적으로 펼치지 않고 읽기 위해 연구팀은 여러 단계를 결합했다.

고해상도 X-ray 스캔
내부 표면 재구성
평탄화
머신러닝 잉크 검출
파피루스학자의 전사/검토
데이터와 코드 공개

이건 사실상 극한의 문서 파이프라인이다.

중요한 건 “ML 모델이 읽었다”가 아니다.

좋은 데이터 획득 → 구조 복원 → 신호 검출 → 전문가 검증 → 공개 재현성

이 전체가 있었기 때문에 2,000년 된 문서를 읽을 수 있었다.

우리의 사내 문서는 두루마리보다 쉽다. 하지만 원리는 같다.

원본이 무엇인지 보존해야 한다.
중간 변환 결과를 추적해야 한다.
파서가 놓친 표/그림/수식을 확인해야 한다.
답변이 어떤 chunk/문서/관계에서 나왔는지 추적해야 한다.
중요한 답은 사람이 검증할 수 있어야 한다.

RAG 제품을 만들 때 “검색 결과가 그럴듯하다”만으로는 부족하다. 사용자는 결국 이렇게 묻는다.

이 답이 어디서 나왔는데?

5. 문서 라우터는 이렇게 생겨야 한다

실무적으로 문서 라우터는 거창할 필요가 없다. 처음에는 규칙 기반으로 충분하다.

입력: 파일, URL, 폴더, 문서 묶음
출력: 처리 경로 + 검증 수준 + RAG 아키텍처 추천

예시 규칙:

조건	추천 경로
단순 텍스트/FAQ	Standard RAG
사람/조직/제품/계약 관계가 중요	Graph RAG
여러 도구 호출/최신 웹 확인/반복 추론 필요	Agentic RAG
스캔 PDF/수식/표/다단 레이아웃	VLM 기반 parser
Office 문서 대량 처리	경량 Markdown 변환기
법무/재무/보안 문서	human review queue 포함
출처 추적이 중요한 답변	citation/provenance 필수

여기서 핵심은 “한 번에 완벽한 AI 지식베이스”가 아니다.

먼저 분류하고, 위험한 문서는 검수하고, 단순한 문서는 싸게 처리하고, 관계가 중요한 문서만 graph로 올리는 것이다.

이게 제품의 비용과 품질을 동시에 잡는다.

6. Frandeer가 바로 만들 수 있는 작은 유틸

Frandeer 운영자의 전략은 거대한 SaaS를 한 번에 만드는 게 아니다. 글로벌 웹 유틸을 작게 많이 내고, SEO/트래픽/광고/소액결제 신호를 본 뒤, 살아남는 것을 AI 서비스로 키우는 것이다.

이 주제에서 바로 가능한 유틸은 세 가지다.

1) RAG Architecture Picker

사용자가 데이터와 질문 유형을 체크하면 Standard/Graph/Agentic RAG 중 무엇이 맞는지 추천한다.

입력:

문서 수
문서 형식
관계 추론 필요 여부
최신 웹 검색 필요 여부
답변 검증 중요도
비용/지연시간 민감도

출력:

추천 아키텍처
피해야 할 선택
최소 구현 스택
검증 체크리스트

2) Document Parser Router Calculator

파일 유형별로 어떤 파서 경로가 맞는지 알려준다.

입력:

PDF/Office/Image/Markdown/HTML
표/수식/스캔 여부
처리량
GPU 사용 가능 여부
정확도 vs 비용 우선순위

출력:

MarkItDown 경로
VLM/MinerU 경로
OCR 경로
human review 필요 여부
예상 리스크

3) Knowledge Base Readiness Checklist

기업이나 개인이 “우리 자료를 AI가 읽게 만들 준비가 됐는가”를 점검한다.

체크 항목:

원본 보존 여부
문서별 owner
업데이트 주기
접근 권한
민감정보 포함 여부
citation 필요도
실패 시 사람이 확인할 프로세스

이런 유틸은 개발자에게도 유용하고, 일반인에게도 설명 가능하다.

“AI 지식베이스를 만들기 전에 이 체크리스트부터 돌려보세요.”

이 문장은 SEO와 제품 모두에 좋다.

7. 반론: 그냥 좋은 모델 쓰면 해결되는 것 아닌가?

일부는 이렇게 말할 수 있다.

요즘 모델 컨텍스트도 길고 멀티모달도 되는데, 그냥 좋은 모델에 문서 넣으면 되지 않나?

작은 개인 작업에서는 맞을 때가 있다.

하지만 제품이 되면 문제가 달라진다.

문서가 계속 늘어난다.
비용이 누적된다.
권한이 생긴다.
답변 오류의 책임이 생긴다.
업데이트와 삭제가 필요하다.
출처 추적이 필요하다.
같은 질문에 일관된 답이 필요하다.

이 순간부터 “좋은 모델 하나”는 부족하다.

모델은 점점 좋아지겠지만, 데이터와 업무는 항상 지저분하다. 그래서 라우터와 검증 루프는 사라지지 않는다.

결론: RAG의 다음 경쟁력은 retrieval 전에 있다

RAG를 검색 기술로만 보면 중요한 절반을 놓친다.

진짜 경쟁력은 retrieval 전에 있다.

어떤 문서를 어떻게 읽을지
어떤 질문을 어떤 아키텍처로 보낼지
어디서 비용을 아낄지
어떤 답을 사람에게 검수시킬지
어떤 출처를 남길지
실패했을 때 어떻게 다시 처리할지

이걸 설계하는 팀이 더 안정적인 AI 지식베이스를 만든다.

Frandeer가 잡을 기회도 여기에 있다. 거대한 엔터프라이즈 RAG 플랫폼을 바로 만들 필요는 없다.

먼저 사람들이 스스로 물어보게 만들면 된다.

내 문서는 Standard RAG로 충분한가?
Graph RAG가 필요한가?
Agentic RAG는 과한가?
이 PDF는 어떤 파서로 보내야 하나?
이 답은 어떻게 검증할 것인가?

이 질문에 답해주는 작은 유틸부터 시작하면 된다.

Sources

3 RAG Architectures — public discussion summary reviewed by the Frandeer editorial workflow.
MinerU와 MarkItDown을 결합한 엔터프라이즈 하이브리드 파싱 전략 — public discussion summary reviewed by the Frandeer editorial workflow.
Herculaneum 두루마리 전체를 처음으로 해독 — public discussion summary reviewed by the Frandeer editorial workflow.
Image: Frandeer generated concept image.