# 벡터DB 없는 RAG

> 구조적 주장은 전부 맞았고, 틀린 건 전부 구체 숫자였습니다 — 2차 정리물의 전형적 실패 지점입니다.

- 수치: 구조 6/6 · 숫자 1/5
- 사람이 보는 화면: https://aitryed.com/ko/teardowns/memory/rag-without-vectors/
- 반대 언어: https://aitryed.com/en/teardowns/memory/rag-without-vectors/index.md
- 출처(원문): https://www.threads.com/@gptaku_ai/post/DbpB3WZE6p6
- 이 사이트 안내(AI용): https://aitryed.com/ko/llms.txt

---

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

> **[도판]** 이 글의 진짜 산출물. “만능은 없다”는 결론은 흔한데, 없다는 걸 규모 축으로 잘라 경계선을 명시한 게 값어치다.
>
> 문서 규모를 축으로 네 구간을 나눈 결정선. 수백 페이지까지는 통째로 컨텍스트에 넣고, 수백에서 수천 페이지는 YAML 프론트매터와 파일 탐색만으로 충분하며, 수천에서 수만 건은 벡터DB와 리랭킹, 그 이상은 벡터와 그래프와 SQL 하이브리드가 필요하다. 내 문서 자산은 두 번째 구간에 있다.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

## 판정

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

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

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

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



## 무엇을 읽은 것인가

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

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

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

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

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

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

> **[도판]** 2차 정리물의 실패가 어디에 몰리는지가 이 그림이다. 흩어져 있지 않고 한 종류에 뭉쳐 있다.
>
> 인용된 주장 열 건을 1차 출처에 대조한 결과. 구조적 주장 여섯은 전부 확인됐고, 구체 숫자 다섯 건 중 확인된 것은 하나뿐이며 셋은 1차 출처를 못 찾았고 하나는 연도가 틀렸다.

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

**믿을 만한 숫자는 하나였다.** 청크마다 맥락 설명을 덧붙여 임베딩하면 상위 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%다.**

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

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

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

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

## 판정

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

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

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