벡터DB 없는 RAG

「AI에게 내 자료를 찾아 읽히려면 꼭 특별한 검색 시스템이 필요한 건 아니다」는 글을 검증한 기록입니다. 주장 열 개를 원본 자료에 하나씩 대 봤더니, 틀린 것이 전부 한 종류에 몰려 있었습니다.

먼저 — AI에게 내 자료를 읽히는 게 왜 어려운가요

AI는 제 컴퓨터 안의 문서를 모릅니다. 그래서 질문할 때 관련 자료를 같이 붙여서 보내야 합니다.

문제는 어떤 자료를 붙일지 고르는 일입니다. 문서가 천 개면 천 개를 다 붙일 수 없습니다. 질문과 관련 있는 몇 개만 골라야 합니다.

이 「고르는 일」을 하는 방식으로 요즘 유행하는 게 있습니다. 문서를 전부 숫자 덩어리로 바꿔서 저장해 두고, 질문도 숫자로 바꿔서 가까운 걸 찾는 방식입니다. 전용 저장소가 따로 필요합니다.

이 글의 주장은 이겁니다 — 「대부분의 경우 그렇게까지 안 해도 된다.」

이 글의 값어치는 결론이 아니라 「경계선」이었습니다

「만능 해법은 없다」는 말은 흔합니다. 그런데 이 글은 어디서 갈리는지를 실제로 그어 놨습니다.

무엇으로 가르나	어떻게 갈리나
문서가 원래 디지털인가	워드나 발표 자료에서 바로 만든 PDF면 글자가 이미 들어 있습니다. 사진에서 글자를 읽어내는 과정 자체가 불필요합니다
질문의 종류가 뭔가	「비슷한 거 찾아줘」는 숫자 방식 / 「이게 뭐랑 연결돼 있지」는 관계도 방식 / 「조건에 맞는 거」는 그냥 표 조회
무엇을 숫자로 바꿀 것인가	원문 전체가 아니라 「이 조각이 어느 문서의 어느 맥락인지」를 짧게 적은 것

마지막 줄이 이 글에서 제일 좋았습니다. 원문을 통째로 숫자로 바꾸는 대신, 「이건 A 문서의 결론 부분」 같은 짧은 설명과 파일 위치만 저장합니다. 그러면 찾을 때는 그 설명으로 찾고, 실제 내용은 파일을 열어서 AI가 직접 읽습니다.

주장 열 개를 원본에 대 봤더니 — 틀린 게 한 종류에 몰려 있었습니다

이 글은 여기저기서 모아 정리한 글입니다. 그래서 원본을 하나씩 찾아 대조했습니다.

주장의 종류	검증 결과
구조에 대한 주장 6건	6건 전부 맞음
구체적인 숫자 4건	4건 다 못 믿음
연도 표기	1건 오기

깔끔하게 갈렸습니다. 「이럴 때는 이게 낫다」는 구조 이야기는 전부 견뎠고, 「몇 퍼센트」 같은 숫자는 전부 무너졌습니다.

이게 남의 정리 글을 읽을 때 알아 둘 만한 패턴입니다. 정리하는 사람은 구조는 이해하고 옮기는데, 숫자는 출처를 안 따라가고 옮깁니다. 그래서 구조는 살아남고 숫자가 죽습니다.

덧붙여 — 이 글은 내용이 전부 이미지 안에 있었습니다

읽는 과정에서 특이한 걸 하나 겪었습니다. 본문에 글이 두 줄뿐이고, 내용 전부가 이미지 열 장 안에 글자로 들어 있었습니다.

그래서 기계로 본문을 긁으면 아무것도 안 잡힙니다. 이미지를 하나씩 내려받아서 읽어야 내용에 닿습니다.

제 것을 대 봤더니 — 이미 그 자리에 서 있었습니다

이 글이 그은 경계선에 제 것을 대 봤습니다. 뜻밖이었습니다.

제가 갖고 있는 것	이 글의 분류로는
위키 문서 1,021개 (15MB)	딱 「특별한 시스템이 필요 없는 규모」
기억 서랍 156개 + 한 장짜리 목차	이 글이 권한 방식 그 자체
숫자 없이 낱말로 찾는 검색	이미 돌고 있음
제 작업 파이프라인의 대조 단계	이미 실제 업무에서 돌고 있음
다루는 기획 문서	전부 원래 디지털 — 사진 읽기 논의가 해당 없음

즉 남의 글을 읽고 배운 게 아니라, 제가 따로 도착해 있던 자리를 남이 설명해 준 것이었습니다.

그런데 진짜 발견은 제 숫자 하나였습니다

이 조사의 최대 성과는 남의 구조가 아니라 제 쪽 빈칸이었습니다.

제가 만들어 둔 방식이 제대로 돌려면 전제가 하나 있는데, 그 전제가 얼마나 채워져 있는지를 재 본 적이 없었습니다. 재 보니 4.6%였습니다.

구조는 맞게 만들어 놨는데, 그 구조가 힘을 쓰려면 채워야 할 것이 95% 비어 있었던 것입니다.

이런 건 구조를 보면 안 보이고 숫자를 재야 보입니다. 그리고 남의 글을 자로 대 보기 전에는 잴 생각조차 안 했습니다.

판정

도구 도입 0건. 숫자 방식 저장소도, 관계도도, 순위 재조정 장치도 지금 제 규모에서는 전부 과잉입니다.

그리고 더 정확히 말하면 — 원문이 스스로 그어 놓은 경계선에 제가 아직 도달하지 않았습니다. 도착하지도 않은 지점의 장비를 미리 살 이유가 없습니다.

여기부터는 자세한 기록입니다

구조는 채택했고 숫자는 인용을 금지했습니다. 이 글이 편 주장 열 개를 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도 그래프도 리랭커도 지금 규모에서는 전부 과잉이고, 원문 스스로 그은 경계선에 아직 도달하지 않았다.

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

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