LLM Wiki는 검색을 어떻게 하나, 그리고 임베딩은 쓸까

지난 글에서 카파시의 LLM Wiki를 훑었습니다. 그러고 나면 꼭 따라오는 질문 두 개가 있습니다.

“검색이 효율적이라는데 대체 어떻게 하는 거지?” “그럼 결국 임베딩(RAG) 쓰는 거 아냐?”

이 글은 그 둘만 깊게 팝니다. 먼저 검색이 일어나는 과정을 단계별로 따라가고, 그다음 임베딩이 어디에 쓰이고 어디엔 안 쓰이는지를 분명히 가르겠습니다.

1. 한 장으로 — 검색은 “지도 보고 페이지 펼치기”

LLM Wiki의 검색은 기존 위키처럼 키워드로 풀텍스트 색인을 뒤지는 게 아닙니다. 에이전트가 index.md라는 지도를 먼저 읽고, 필요한 페이지만 펼쳐서 종합합니다.

핵심은 마지막 줄입니다. 읽는 양이 위키 크기가 아니라 “관련 페이지 수”에 비례합니다. 위키가 23장이든 2300장이든, 한 질문에 펼치는 건 보통 서너 장입니다. 그래서 위키가 커져도 질의 비용이 폭증하지 않습니다.

2. 단계별로 따라가기

말로만 하면 추상적이니, 질문 하나를 끝까지 따라가 봅시다. AI 아키텍처를 정리한 작은 위키에 이렇게 묻습니다.

“긴 문맥 처리에는 Transformer attention하고 Mamba 중에 뭐가 유리해? 근거랑 같이.”

2-1. `index.md`를 먼저 읽는다 (지도 우선)

LLM은 위키 전체를 컨텍스트에 욱여넣지 않습니다. 모든 페이지의 제목과 한 줄 요약만 담긴 index.md 한 장만 읽습니다.

# Index  (총 23 페이지)
## concepts
- [[attention]] — Transformer 핵심 연산. 길이 N에 O(N²). 긴 문맥에서 비쌈.
- [[state-space-model]] — Mamba가 쓰는 SSM. O(N) 선형. 긴 문맥 유리, 회상엔 약함.
## entities
- [[mamba]] — 2023, Gu & Dao. 선택적 SSM 기반.
## comparisons
- (없음)

지도를 보고 LLM이 판단합니다. “이 질문엔 attention, state-space-model, mamba면 된다. 비교 페이지는 아직 없다.” 23장을 다 읽는 대신 볼 것만 고른 겁니다.

2-2. 고른 페이지만 펼친다

판단한 서너 장만 엽니다. 위키가 아무리 커도 이 단계의 비용은 거의 그대로입니다. 펼치는 장수가 위키 크기와 무관하니까요.

2-3. 링크를 타고 보강한다 (관계는 미리 컴파일됨)

state-space-model 페이지를 열면 본문에 [[attention]] 링크와 함께 이런 모순 표시가 이미 박혀 있습니다.

## 한계 (모순 플래그)
> Contradiction: mamba-2023.pdf는 "언어 모델링에서 attention과 대등"이라 주장.
> 그러나 jamba-2024.pdf는 "순수 SSM은 in-context 회상에 약하다"고 반박.
> → 그래서 Jamba는 SSM과 attention을 섞었다. 어느 쪽이 맞나: 과제에 따라 다름.

여기서 중요한 건, “SSM과 attention의 관계”를 지금 새로 계산하는 게 아니라, 자료를 넣을 때(Ingest) 이미 적어둔 메모를 그대로 줍는다는 점입니다. 관계와 모순이 검색 시점이 아니라 컴파일 시점에 정리돼 있습니다.

2-4. 종합하고 인용한다

읽은 서너 장으로 바로 답을 만듭니다. 비용/속도만 보면 Mamba가 유리하지만(O(N) 선형), 정확한 회상이 필요한 과제라면 순수 SSM이 약하다는 모순까지 함께 답하고, 근거를 위키 페이지와 그 페이지의 원본(sources:)까지 단계적으로 인용합니다.

2-5. 좋은 답을 페이지로 굳힌다 (캐싱)

이 종합이 쓸 만하니, LLM이 comparisons/attention-vs-ssm.md를 새로 만들고 index.md에 한 줄 추가합니다. 그러면 다음에 비슷한 질문이 올 때는 서너 장을 다시 종합할 필요 없이 이 한 장만 꺼내면 됩니다.

검색을 쌓을수록 다음 검색이 더 싸지는 게 이 구조의 핵심입니다. 이른바 compounding입니다.

3. 기존 위키 검색과 무엇이 다른가

같은 질문을 세 방식이 어떻게 처리하는지 한 장으로 비교하면 차이가 또렷합니다.

기존 위키 검색은 단어 매칭으로 페이지를 찾아주고 끝입니다. 비교와 모순 정리는 사람이 직접 머릿속에서 합쳐야 하고, 다음에 또 물으면 처음부터 다시입니다. LLM Wiki는 항해해서 답하고, 그 답을 다시 위키에 쌓습니다. “찾기”와 “종합”이 한 동작으로 묶이고 결과가 휘발되지 않는다는 점이 가장 큰 차이입니다.

4. 그래서 임베딩은 쓰나

이제 두 번째 질문입니다. 한 줄로 답하면, 핵심 동작에는 안 쓰고, 규모가 커지면 선택적 보조로 얹을 수 있습니다. 사실 LLM Wiki는 어떤 의미에서 임베딩 검색(RAG)에 대한 반작용으로 나온 설계라, 기본 작동에 임베딩을 끼우지 않는 게 포인트입니다.

핵심에 임베딩이 없는 이유. 기본 검색이 벡터 유사도가 아니라 에이전트의 항해이기 때문입니다. “관련 페이지를 찾는 힘”이 코사인 유사도가 아니라, LLM이 미리 정리해 둔 구조(요약, 링크, 분류)를 읽고 판단하는 추론에서 나옵니다. 그래서 임베딩 인덱스를 안 만들어도 돌아갑니다.

그럼 임베딩은 어디서 들어오나. 위키가 수백, 수천 장으로 커지면 index.md 한 장으로 후보를 좁히기 버거워집니다. 이때만 후보 페이지를 빠르게 추리는 가속기로 검색 인덱스를 얹습니다. 카파시가 언급한 qmd 같은 도구가 BM25와 벡터(임베딩) 하이브리드 검색을 제공합니다. 즉 임베딩은 “답을 만드는 엔진”이 아니라 “이 질문에 볼 만한 페이지 30장을 1초에 추리는” 라우터 보조이고, 실제 종합은 그 페이지들을 읽어서 합니다.

RAG의 임베딩과 결정적으로 다른 점. 임베딩을 쓰더라도 검색 대상이 다릅니다. RAG는 raw 원본 청크에 임베딩 검색을 걸지만, LLM Wiki는 이미 정리된 페이지에 겁니다. RAG는 임베딩이 빠지면 검색 자체가 안 되는 반면, LLM Wiki는 임베딩이 0이어도 작동하고, 쓰더라도 raw 조각이 아니라 정제된 페이지 위에서 좁히기만 합니다.

Ingest(쓰기)에는 임베딩이 없다. 자료를 넣어 페이지를 만들고 고치는 일은 임베딩이 아니라 LLM의 읽기와 편집입니다. 임베딩은 어디까지나 “읽을 때 후보 찾기”에만 선택적으로 등장합니다.

5. 정리

검색의 본질은 “구조를 항해하는 에이전트” 입니다. 지도(index)를 보고 관련 페이지만 펼쳐 종합합니다.
효율은 세 가지에서 나옵니다. 지도 우선이라 읽는 양이 위키 크기와 무관하고, 관계와 모순이 미리 컴파일돼 있어 재계산이 없고, 답을 페이지로 쌓아 다음 검색이 더 싸집니다.
임베딩은 본체가 아니라 옵션입니다. 역할도 “지식 검색의 엔진”이 아니라 “큰 위키에서 후보를 빠르게 추리는 보조”에 한정되고, 쓰더라도 raw가 아니라 정제된 페이지 위에서 출발합니다.

마무리 — 언제 임베딩을 더하면 좋은가

작은 위키(수십~백 장 안쪽)라면 index.md 지도와 링크만으로 충분합니다. 임베딩 인덱스를 굳이 만들 필요가 없습니다. 페이지가 수백 장을 넘어 지도만으로 후보 고르기가 흔들리기 시작하면, 그때 qmd 같은 BM25와 벡터 하이브리드를 얹어 “볼 후보를 좁히는 단계”에만 임베딩을 더하면 됩니다. 답을 만드는 일은 여전히 정제된 페이지를 읽는 에이전트의 몫입니다.

LLM Wiki는 검색을 어떻게 하나, 그리고 임베딩은 쓸까

1. 한 장으로 — 검색은 “지도 보고 페이지 펼치기”