클로드 코드로 대용량 문서 RAG 만들기, 벡터DB 없이도 되는 이유

대용량 문서를 클로드 코드에 읽혀 위키나 지식베이스를 만들려는 시도가 늘고 있다. docling 같은 도구로 PDF·PPTX·스캔본을 마크다운으로 바꾼 뒤, 클로드 코드가 읽고 정리·저작까지 하게 만드는 워크플로우다. 문제는 "이 문서량에 맞는 만능 RAG 레시피가 있느냐"는 것인데, 결론부터 말하면 없다. 파서도, 청킹 전략도, 벡터DB를 쓸지 말지도 문서의 성격과 규모에 따라 달라진다. 클로드 코드 사용자 커뮤니티 '클코단'에서 나온 실전 토론과 최신 조사를 엮어 이 판단 기준을 정리한다.

파서는 문서마다 다르다 — docling과 paddle의 역할 분담

가장 먼저 부딪히는 문제는 파싱이다. IBM이 만든 오픈소스 도구 docling은 PDF, DOCX, PPTX, XLSX, 이미지, HTML, AsciiDoc, 마크다운을 입력받아 마크다운이나 JSON으로 변환한다. LF AI & Data Foundation 산하로 이관돼 MIT 라이선스로 매주 릴리스가 나올 만큼 활발히 개발되고 있고, 파이썬 API 몇 줄이면 노트북에서도 돌아갈 만큼 가볍다. 반면 PaddleOCR 계열의 PP-StructureV3는 레이아웃 분석·표 인식·수식 인식을 하나의 파이프라인으로 묶은 구조로, 손글씨 인식 정확도가 약 73%로 Tesseract(45%)나 EasyOCR(62%)보다 확연히 높고 GPU에서 분당 120페이지 처리량을 낸다. 다국어·CJK와 복잡한 표에 강하지만 GPU 자원이 필요하다.

이 둘은 경쟁 관계라기보다 역할이 다르다. docling 자체는 PaddleOCR을 직접 지원하지 않고, 내부 OCR 엔진인 RapidOCR이 사실상 PaddleOCR을 onnxruntime으로 구동하는 형태다. 실제 벤치마크에서도 "가장 강한 엔진은 문서마다 매번 바뀐다"는 결론이 반복됐다. 클코단에서도 "가성비는 docling, 퀄리티는 paddle"이라는 정리가 나왔는데, 문서 난이도에 따라 도구를 바꿔야 한다는 벤치마크 결과와 맞아떨어진다. born-digital 문서, 즉 워드·파워포인트에서 바로 뽑은 PDF는 텍스트 레이어가 이미 있어 OCR 자체가 필요 없다는 구분도 고려해야 한다. 확대해도 또렷한 텍스트, 스캔본보다 훨씬 작은 파일 용량이 판별 기준이다. "모든 문서 형태를 커버하는 만능 파서는 없다"는 결론은 이 구조적 차이에서 나온다.

문서 전체 대신 디스크립션만 임베딩한다

파싱이 끝나면 청킹과 임베딩 문제가 남는다. 2026년 기준 업계에서 가장 널리 쓰이는 방식은 계층형(hierarchical) 청킹으로, 작은 단위는 검색 정밀도를, 큰 단위는 맥락 이해를 담당하게 나눠 트레이드오프를 완화한다. docling도 HybridChunker를 제공하는데, 문서 구조를 보존하는 계층형 청킹을 1차로 수행한 뒤 임베딩 모델의 토크나이저 기준으로 너무 큰 청크는 쪼개고 너무 작은 청크는 합치는 2단계 방식을 쓴다. 청크 크기는 512토큰이 실용적인 기본값으로 자리잡았고, 2026년 1월 한 체계적 분석에서는 청크 간 오버랩이 검색 성능에 별 도움이 되지 않고 인덱싱 비용만 늘린다는 결과도 나왔다.

클코단에서 공유된 실전 팁, 즉 "문서 전체를 임베딩하는 대신 디스크립션만 임베딩하고 파일 경로 등 메타데이터를 붙여 클로드 코드에 던진다"는 방식은 앤스로픽이 2024년 발표한 contextual retrieval와 원리가 통한다. 이 기법은 청크마다 "이 문단이 어느 문서, 어느 맥락에 속하는지"를 요약한 50~100토큰짜리 설명을 덧붙인 뒤 임베딩하는데, 상위 20개 청크 기준 검색 실패율을 5.7%에서 3.7%로 35% 낮췄다는 결과가 보고됐다. 원문 전체를 벡터화하는 대신 압축한 설명을 벡터화하고, 실제 처리는 원문 경로를 클로드 코드에 넘겨 맡기는 방식은 임베딩 비용과 검색 정밀도를 동시에 잡는 절충안인 셈이다.

벡터DB 하나로는 안 된다

클코단 토론에서 나온 또 하나의 핵심은 "RAG는 벡터DB만의 문제가 아니라 SQL·그래프DB를 병행해야 품질이 올라간다"는 지적이었다. 이는 실제 RAG 아키텍처 논의와 일치한다. 벡터 검색은 표현이 달라도 같은 주제의 문서를 찾아내는 데 강하지만, 두 문서가 왜 연결되는지는 설명하지 못한다. 반대로 그래프 데이터베이스는 엔터티 간 관계를 타고 다니며 다중 홉 추론을 할 수 있지만 의미적 유사도 판단에는 약하다. 그래서 하이브리드RAG는 비정형·반정형 데이터는 벡터DB에, 관계 중심의 정형 데이터는 그래프DB에 나눠 맡기는 구조를 취한다. 마이크로소프트의 GraphRAG가 대표적인데, 원문에서 지식 그래프를 뽑고 커뮤니티 단위로 계층화해 요약을 생성한 뒤 검색에 활용하는 방식으로, 여러 문서를 넘나드는 복합 질의에서 단순 벡터 검색보다 낫다는 평가를 받는다. 2025년 나온 LazyGraphRAG는 인덱싱 비용을 기존 대비 0.1% 수준으로 낮췄다. 여기에 SQL을 더하는 이유도 명확하다. 날짜·작성자·카테고리 같은 정형 필터는 벡터 유사도보다 관계형 쿼리가 정확하고 빠르다. 결국 좋은 RAG는 "무엇이 비슷한가"는 벡터DB, "어떻게 연결되는가"는 그래프DB, "어떤 조건에 맞는가"는 SQL로 나눠 맡기는 구조로 수렴한다.

top-k 잘림과 리랭킹의 딜레마

클코단에서 고질적 어려움으로 꼽힌 top-k 잘림과 리랭킹 기준의 자의성도 근거가 있다. k가 작으면 정답이 들어있는 구간이 통째로 잘려나가고, k가 크면 잡음이 늘어 리랭커 성능이 오히려 떨어진다는 게 최근 연구의 공통 지적이다. 업계 절충안은 top-50~100개를 넉넉히 가져온 뒤 리랭커로 재정렬해 최종 top-5~10개만 생성 단계에 넘기는 2단계 구조다. Cohere Rerank 4.0 같은 상용 리랭커는 청크당 80~150ms 지연을 더하는 대신 정밀도를 끌어올린다. 다만 "어디서 잘라야 정답인가"는 문서 분포와 질의 유형마다 달라 고정된 공식으로 못 박기는 어렵다는 게 공통된 진단이다.

벡터DB 없이 가는 길도 있다

클코단에서 소개된 사례 중 눈에 띄는 것은 마크다운 상단에 YAML 메타데이터를 넣고 grep으로 검색하는, 벡터DB를 아예 쓰지 않는 구성이었다. 이 방식은 2025년 후반 앤드리 카패시가 제안해 화제가 된 'LLM 위키' 패턴과 사실상 같은 철학을 공유한다. 임베딩도 벡터DB도 없이 구조화된 마크다운 파일들을 그대로 LLM 컨텍스트에 읽혀서 처리하는 방식으로, 검색은 세션 시작 시 로드하는 요약 캐시, 페이지당 한 줄인 마스터 인덱스, 거기서 지목된 서너 개 페이지를 읽는 순서로 이뤄지고 grep은 보조 수단으로 쓰인다. 실제로 이 패턴을 클로드 코드 플러그인으로 구현한 오픈소스 프로젝트도 나와 있다.

이 방식이 통하는 이유는 마크다운 프런트매터가 검색의 '의미적 고리' 역할을 하기 때문이다. RAG 실패의 상당수가 답변 생성이 아니라 관련 문서를 찾지 못하는 검색 단계에서 발생한다는 점을 감안하면, 파일 경로·태그·요약을 YAML로 명시해두고 grep이나 파일 시스템 탐색만으로 찾아내는 방식이 수백~수천 페이지 규모에서는 벡터DB보다 오히려 예측 가능하고 유지보수가 쉬울 수 있다는 뜻이다. 다만 문서 규모가 수만 건을 넘어가거나 응답 속도가 중요해지는 시점부터는 다시 벡터 검색이 필요해진다는 게 이 패턴을 조사한 여러 글의 공통된 경계선이었다.

정리

결국 클코단이 던진 질문, "docling으로 변환한 문서를 클로드 코드가 처리하는 데 참고할 만능 레퍼런스가 있느냐"의 답은 "그런 단일 정답은 없고, 규모와 문서 성격에 따라 조합을 짜야 한다"는 쪽으로 수렴한다. 문서가 born-digital이면 파서 자체가 필요 없고, 스캔본 위주면 docling과 paddle 중 정확도와 비용을 저울질해야 한다. 컬렉션이 수백~수천 페이지 규모라면 벡터DB 없이 YAML 프런트매터와 grep만으로도 충분할 수 있고, 그 이상으로 커지면 벡터·SQL·그래프DB를 섞은 하이브리드 구조와 리랭킹 단계가 필요해진다. 어느 쪽이든 "문서 전체가 아니라 요약과 메타데이터를 임베딩하고 실제 처리는 클로드 코드에 맡긴다"는 원칙은 규모와 무관하게 유효한 절충안이다.