벡터DB 없는 RAG

구조는 채택했고 숫자는 인용을 금지했습니다. 이 글이 편 주장 열 개를 1차 출처에 하나씩 대조했더니, 구조적 주장 여섯은 전부 맞았고 못 믿을 것은 구체 숫자 네 건에 몰려 있었습니다(거기에 연도 오기 하나). 2차 정리물의 실패가 어디서 나는지가 정확히 보입니다. 그리고 이 글이 그은 경계선을 제 환경에 대봤더니 — 제가 이미 그 자리에 서 있었고, 다만 전제가 4.6%만 채워져 있었습니다.

무엇을 읽은 것인가

커뮤니티 실전 토론에 작성자의 조사를 덧붙인 2차 정리물이다. 형식이 특이한데 — 본문은 두 줄뿐이고 내용 전부가 이미지 열 장에 텍스트로 들어 있다. 텍스트 크롤링으로는 아무것도 안 잡히고, 이미지를 내려받아 판독해야만 내용에 닿는다.

그리고 1차 출처를 링크하지 않고 문장으로 요약해 붙였다. 그래서 수치를 쓰려면 검증이 선행돼야 한다 — 이 페이지의 절반이 그 얘기다.

내용을 관통하는 축이 셋이고, 축마다 “문서의 성격”이 결정변수라는 게 이 글의 논지다.

축	결정변수	갈림
파싱	born-digital인가	워드·PPT에서 바로 뽑은 PDF면 텍스트 레이어가 이미 있어 OCR 자체가 불필요
청킹·임베딩	무엇을 벡터화하나	⚠원문 전체가 아니라 “이 조각이 어느 문서·어느 맥락인가”라는 50~100토큰 요약과 파일 경로를 벡터화. 실제 원문 처리는 경로를 받은 LLM이
검색	질문의 종류	무엇이 비슷한가 = 벡터 / 어떻게 연결되는가 = 그래프 / 어떤 조건에 맞는가 = SQL

두 번째 축이 이 글에서 제일 값나가는 전환이다. 문서를 통째로 임베딩하는 게 아니라 설명만 임베딩하고 원문은 경로로 넘긴다.

검증 — 구조는 견디고 숫자는 못 견딘다

구조적 주장 여섯은 전부 맞았다. 파서 두 종이 경쟁이 아니라 역할 분담이라는 것, 검색 아키텍처가 세 종류로 수렴한다는 것, 규모 경계선, 그리고 지식 위키 패턴이 실재하며 그 패턴이 그은 경계선까지 정확히 일치한다는 것.

믿을 만한 숫자는 하나였다. 청크마다 맥락 설명을 덧붙여 임베딩하면 상위 20개 기준 검색 실패율이 5.7%에서 3.7%로 떨어진다는 것 — 발표문과 정확히 일치했다. 오히려 신뢰 가점을 줄 대목이 있다: 같은 발표문에 검색 방식을 병행하면 2.9%, 리랭킹까지 더하면 1.9%라는 더 좋은 숫자가 있는데 원문은 보수적으로 단독 수치만 인용했다.

나머지 넷은 못 쓴다.

• OCR 정확도 세 건 — 1차 출처를 못 찾았다. 이 계열의 표준 벤치마크는 지표 체계가 “정확도 %“가 아니라 오류율이라, 서로 다른 벤치의 숫자를 섞었을 가능성이 크다
• 청크 크기와 “오버랩은 무용하다” — 출처가 없다. 특히 뒤쪽은 통념과 정반대되는 주장이라 출처 없이 채택하면 위험하다
• 리랭커 지연 — 출처를 못 찾았고, 그 지연은 보통 배치 단위로 보고되지 조각 단위로 잘 쓰지 않는다
• 비용 절감 수치 — 값 자체는 정확한데 발표 연도가 한 해 틀렸다

패턴에 이름을 붙일 만하다. 구조는 2차 정리를 견디고, 구체 숫자는 못 견딘다. 옮겨 적는 사람이 구조는 통째로 옮기지만 숫자는 기억이나 다른 자료에서 끌어오기 때문이다. 그래서 구조는 채택하고 숫자는 인용을 금한다 — 이 글을 쓰는 올바른 방법이다.

그리고 제 환경을 재봤습니다

이 글이 그은 경계선에 제 것을 대봤다. 놀랍게도 제가 이미 그 칸에 서 있었고, 심지어 그 패턴을 독립적으로 재발명해 굴리고 있었다.

제 자산	실측	판정
위키 볼트	마크다운 1,021개 · 15MB	규모가 정확히 스위트스팟
메모리 서랍	156개 + 마스터 인덱스 한 장(항목당 한 줄 + 여는 조건)	✅ 이미 라이브 — 지식 위키 패턴 그 자체
전문 검색 색인	벡터 없이 키워드 색인	✅ 이미 라이브 — 원문의 grep보다 한 단계 위
파이프라인의 대조 단계	색인을 조회해 참조를 뽑아 넘김	✅ 프로덕션 — 벡터DB 없는 검색이 이미 업무 런에서 돈다
다루는 기획 문서	전부 born-digital	파서 논의 자체가 해당 없음

메모리 서랍이 특히 그렇다. 항목당 한 줄 포인터 + “언제 이 문서를 여는가” 한 줄 — 그게 정확히 이 글이 말하는 마스터 인덱스의 라우팅 힌트다. 제가 필요해서 만든 건데, 왜 그게 되는지의 이론적 근거를 이 글이 제공한다.

그런데 전제가 4.6%만 채워져 있었다

이 조사의 최대 발견은 남의 아키텍처가 아니라 제 숫자였다.

볼트 마크다운 1,021개 중 프론트매터가 있는 건 47개. 4.6%다.

이 패턴이 통하는 이유가 프론트매터가 검색의 의미적 고리 역할을 하기 때문이다. 그리고 원문의 진단은 “검색 실패의 상당수는 답변 생성이 아니라 관련 문서를 못 찾는 검색 단계에서 발생한다”이고, 그 처방이 “경로·태그·요약을 명시하라”다.

제 볼트는 그 처방이 가장 잘 듣는 규모에 서 있는데 처방을 47개 파일에만 적용한 상태였다. 지금은 구조화된 위키가 아니라 마크다운 더미 + 사람 기억에 가깝다.

즉 여기서 검색이 안 될 때 원인은 “도구가 없어서”가 아니라 “메타데이터가 비어서”일 가능성이 높다. 벡터DB를 얹는 것보다 프론트매터를 채우는 쪽이 훨씬 싸고 효과가 크다.

⚠ 다만 이건 아직 가설이다. 저는 “검색이 실제로 실패하고 있는가”를 재지 않았다. 순서를 지켜야 한다 — 채우기 전에 실패 사례를 몇 건 표본으로 잡아 원인이 메타데이터 부재인지 먼저 확인한다. 안 그러면 4.6%에서 100%까지 가는 작업량은 다 지불하고, 효과는 끝내 추정치로만 말하게 된다.

판정

도구 도입 0. 벡터DB도 그래프도 리랭커도 지금 규모에서는 전부 과잉이고, 원문 스스로 그은 경계선에 아직 도달하지 않았다.

가져온 것은 원칙 둘. 하나는 “문서 전체가 아니라 요약과 메타데이터만 색인하고 실제 처리는 원문 경로를 넘겨 맡긴다” — 제 쪽 세 곳이 이미 이걸 따로따로 재발명한 상태라 규약이 서로 다른데, 이름이 생겼으니 통일할 수 있다. 다른 하나는 이 페이지의 제목이다.

구조는 채택하고 숫자는 인용을 금한다.