[LLM Wiki 5] 큰 회의록 Wiki에서 필요한 문서를 찾는 법

회의록이 적을 때는 파일명을 보고 찾거나 Obsidian의 index를 훑어도 된다. 하지만 회의록이 많아지면 LLM이 모든 파일을 읽는 방식은 느리고 비싸고 부정확해진다. 큰 LLM Wiki에서는 검색과 색인 구조가 반드시 필요하다.

작은 Wiki와 큰 Wiki의 차이

작은 Wiki는 단순하다.

하지만 회의록이 수백 개, 수천 개가 되면 index.md 자체가 너무 커진다. LLM이 매번 긴 index를 읽는 것도 낭비다.

큰 Wiki에서는 구조가 달라진다.

LLM은 검색 엔진이 아니다. 검색은 검색 도구가 하고, LLM은 검색 결과를 읽고 판단해야 한다.

Frontmatter metadata가 핵심이다

회의록 카드 맨 위에는 frontmatter가 있어야 한다.

type: meeting
date: 2026-06-27
meeting_type: customer-call
participants: [Jay, Alice]
projects: [Enterprise Pricing]
topics: [Pricing, SSO]
source: raw/meetings/2026-06-27-acme-call.md
visibility: private
language: ko

이 정보가 있어야 정확한 필터링이 가능하다.

예를 들어 “6월 회의록 전체 요약”은 다음 조건으로 찾는다.

• type = meeting
• date >= 2026-06-01
• date < 2026-07-01

6월 회의록 전체 요약은 어떻게 동작하나

질문은 단순해 보인다.

• 6월 회의록 전체 요약해줘

하지만 시스템은 여러 단계를 거쳐야 한다. 위 도식처럼 질문을 기간과 문서 타입으로 해석하고, metadata로 6월 meeting만 좁힌 뒤, 관련 카드를 읽고 월간 요약을 만든다.

qmd의 역할

qmd는 markdown 문서, 회의록, 지식베이스를 로컬에서 검색하는 도구다. BM25 키워드 검색, vector 의미 검색, LLM reranking을 결합한다.

예를 들어 다음 질문을 보자.

• 6월 고객 미팅 중 가격 부담이 나온 회의 요약해줘

qmd를 쓰면 먼저 BM25와 vector search가 후보를 찾고, reranker가 질문에 더 맞는 순서로 재정렬한다. 그 결과를 LLM이 읽고 요약한다.

qmd와 SQL은 역할이 다르다

qmd를 쓰면 검색용 SQL을 직접 많이 만들 필요가 줄어든다. 하지만 qmd가 모든 DB 역할을 대체하는 것은 아니다. qmd는 똑똑한 검색 사서에 가깝고, SQLite나 Dataview는 정확한 장부에 가깝다. LLM은 검색 결과와 장부를 읽고 판단하는 편집자다.

처음부터 SQLite를 만들 필요는 없다. 하지만 상태 관리와 집계가 중요해지면 Dataview나 SQLite가 필요해진다.