[LLM Wiki 11] qmd의 기술 구조와 사용 케이스

qmd는 LLM Wiki 전체를 대신하는 도구가 아니다. 더 정확히 말하면, qmd는 LLM Wiki 안에서 검색 엔진 레이어 역할을 한다. 회의록과 markdown 카드가 많아졌을 때 LLM이 모든 파일을 처음부터 끝까지 읽는 것은 비싸고 느리다. qmd는 그 전에 관련 문서 후보를 찾아 LLM에게 넘긴다.

LLM Wiki에서 qmd의 위치를 단순하게 보면 이렇다.

• markdown wiki는 사람이 읽는 지식 저장소다.
• qmd는 그 wiki 안에서 읽을 문서를 찾는 검색 계층이다.
• LLM은 qmd가 골라준 문서를 읽고 요약, 분석, 답변, wiki 갱신을 한다.

그래서 qmd를 쓴다고 SQL, Dataview, Graph RAG가 모두 필요 없어지는 것은 아니다. qmd는 “무엇을 읽을지 찾는 일”에 강하고, 상태 집계나 관계 추적은 다른 계층이 더 잘할 수 있다.

qmd가 필요한 순간

회의록이 20개 정도라면 사람이 파일명을 보고 찾을 수 있다. 하지만 회의록이 500개, 5,000개가 되면 이야기가 달라진다.

예를 들어 이런 질문을 생각해보자.

• 가격 부담이 나온 고객 미팅 찾아줘.
• 6월 가격정책 관련 결정 모아줘.
• SSO 때문에 막힌 고객콜 요약해줘.
• Jay가 언급된 제품 회의 중 액션이 열린 것만 찾아줘.

이 질문들은 단순 파일명 검색으로는 부족하다. “가격 부담”이라는 표현이 실제 회의록에는 “budget concern”, “too expensive”, “도입 비용이 높다”로 적혀 있을 수 있기 때문이다. qmd는 이런 표현 차이를 줄이기 위해 키워드 검색과 의미 검색을 함께 쓴다.

BM25, Vector Search, Reranker

qmd 검색을 이해하려면 세 가지 층을 나눠 보면 된다.

BM25는 전통적인 키워드 검색이다. 문서 안에 검색어가 얼마나 중요하게 등장하는지를 계산한다. 고객명, 제품명, 약어, 코드명, 날짜처럼 정확한 단어가 중요한 검색에 강하다.

Vector Search는 의미 검색이다. 문장이나 문서를 embedding이라는 숫자 벡터로 바꾼 뒤, 의미적으로 가까운 문서를 찾는다. “가격 부담”, “budget concern”, “too expensive”처럼 단어는 다르지만 뜻이 비슷한 표현을 연결하는 데 유리하다.

Reranker는 후보 재정렬 단계다. BM25와 vector search가 넓게 찾은 후보 중에서 질문에 더 맞는 문서를 위로 올린다. 검색 후보가 많을수록 reranker의 가치가 커진다.

중요한 점은 reranker가 최종 답변을 쓰는 모델이 아니라는 것이다. reranker는 후보를 다시 줄 세우고, 최종 답변은 main LLM이 쓴다.

qmd의 세 가지 검색 모드

qmd는 용도별로 검색 방식을 나눠 쓸 수 있다.

qmd search는 키워드 검색에 가깝다. “ACME”, “SSO”, “usage-based pricing”처럼 정확한 단어를 찾을 때 빠르고 강하다.

qmd vsearch는 의미 기반 검색이다. 사용자가 자연어로 넓게 물어보거나, 한국어와 영어 표현이 섞여 있을 때 유리하다.

qmd query는 고품질 질의에 가깝다. BM25, vector search, query expansion, reranking을 묶어 사용한다. 회의록 QA나 LLM Wiki 질의응답에는 보통 이 흐름이 가장 적합하다.

qmd와 SQL은 역할이 다르다

qmd를 쓰면 검색용 SQL을 많이 직접 만들 필요가 줄어든다. 하지만 qmd가 정확한 장부 역할까지 대체하지는 않는다.

예를 들어 “가격 부담이 나온 고객 미팅 찾아줘”는 qmd가 잘한다. 관련 표현이 다양하고, 의미 검색이 필요하기 때문이다.

반대로 “due date가 지난 open action을 owner별로 집계해줘”는 SQL이나 Dataview가 더 잘한다. 조건이 명확하고, 상태, 날짜, 담당자 필드를 정확히 필터링해야 하기 때문이다.

LLM은 둘의 결과를 읽고 판단한다. qmd가 관련 문서를 찾고, Dataview나 DB가 상태표를 만들고, LLM이 그 결과를 읽어 설명하는 구조가 가장 안정적이다.

qmd에서 모델을 바꾼다는 뜻

qmd가 LLM을 쓴다고 할 때, 하나의 모델만 의미하지 않는다. 역할에 따라 모델이 나뉜다.

Embedding model은 문서와 질문을 벡터로 바꾼다. 한국어 회의록이라면 이 모델이 매우 중요하다. 영어 중심 embedding을 쓰면 “예산 문제”와 “budget concern”을 잘 연결하지 못할 수 있다.

Reranker model은 검색 후보를 다시 정렬한다. 이 모델은 답변을 길게 쓰는 것보다, 질문과 후보 문서가 얼마나 관련 있는지를 잘 판단해야 한다.

Main LLM은 최종 답변을 만든다. 검색된 문서를 읽고 요약하거나, 월간 요약을 만들거나, wiki 카드를 갱신하는 역할이다.

모델을 바꿀 때 주의할 점도 있다. embedding model을 바꾸면 기존 문서를 다시 embedding해야 한다. 문서를 예전 모델의 벡터로 색인해두고 새 모델로 질문만 embedding하면 검색 품질이 흔들릴 수 있다.

회의록 LLM Wiki에서의 권장 구조

회의록 시스템에서 qmd는 다음 위치에 두는 것이 좋다.

• 원본 회의록과 wiki 카드는 markdown으로 보관한다.
• 각 카드에는 date, type, project, participant, source 같은 frontmatter를 둔다.
• qmd는 markdown 본문과 metadata를 색인한다.
• 날짜, 타입, 담당자처럼 정확한 조건은 metadata 필터로 좁힌다.
• 의미가 넓은 질문은 vector search와 reranker를 사용한다.
• 최종 LLM은 상위 후보만 읽고 답한다.

이 구조를 쓰면 “모든 회의록을 LLM에게 다 읽히는 방식”을 피할 수 있다. 검색은 검색 계층이 하고, 판단은 LLM이 한다.

qmd는 만능 저장소가 아니라 검색 레이어다. 이 구분을 지키면 qmd, Dataview, Graph RAG, Confluence 같은 도구를 서로 경쟁시키지 않고 역할별로 조합할 수 있다.