자료가 모자라서가 아니라 쓸데없는 게 섞여 있어서였어요. 제 볼트를 실측해서 찾은 원인 셋과, 각각 어떻게 확인하고 어떻게 빼는지 정리했습니다.
Claude Code나 MCP로 자기 지식베이스를 물려서 쓰다 보면 어느 순간부터 답이 이상해집니다. 분명히 정리해둔 문서가 있는데 AI는 다른 걸 집어오고, 재차 물어도 마찬가지고요. 저는 그동안 이걸 검색 엔진 품질 문제로 여기고 리랭킹을 켜는 식으로 대응해왔어요.
그런데 실제로 재봤더니 엔진 문제가 아니었습니다. 검색 대상에 들어가면 안 되는 게 들어가 있어서였어요. 제 볼트에서 세 종류가 나왔고, 셋 다 빼는 데 30분이 안 걸렸습니다.
제가 쌓고 있는 것
대처법으로 넘어가기 전에 제 환경을 먼저 밝혀둘게요. 뭘 검색하는지 알아야 왜 그게 문제였는지도 보일 테니까요.
저는 옵시디언 볼트 하나를 LLM Wiki로 쓰고 있습니다. 사람이 읽으려고 쓰는 노트가 아니라 LLM이 쓰고 LLM이 읽는 지식베이스예요. 안드레이 카파시가 던진 아이디어인데, 요지는 이렇습니다. 세션은 매번 백지에서 시작하는데 프로젝트 맥락은 계속 쌓이니, 그 사이를 잇는 위키를 두자는 거죠.
일반 노트앱과 다른 점은 로그를 쌓지 않는다는 겁니다. 날짜별로 append하는 게 아니라 주제 단위 페이지를 두고 항상 최신 상태로 갱신해요. "지난번 그 건" 같은 표현도 금지고요. 페이지 하나만 읽어도 이해되게 자기완결적으로 씁니다. 나중에 검색으로 그 페이지 하나만 열릴 걸 전제하니까요.
지금 들어 있는 건 네 종류입니다. 번복 비용이 큰 결정 63개(배경·검토한 대안·결정·근거를 같이 적습니다), 같은 실수를 반복하지 않으려고 적어둔 레슨런 110개, 프로젝트별 현재 상태와 월별 타임라인 23개, 그리고 전체 지도 역할을 하는 INDEX.md와 작성 규칙을 적어둔 CONVENTIONS.md. 페이지끼리는 위키링크로 엮여 있고 그 링크가 1,388개예요.
쌓는 것도 읽는 것도 Claude Code가 합니다. 작업이 끝나면 /compound라는 커맨드로 그 세션에서 나온 결정과 배운 걸 위키에 증류하고, 반대로 새 작업을 시작할 때는 설계에 들어가기 전에 관련 페이지를 먼저 검색하게 해뒀어요. "예전에 비슷한 거 했던 것 같은데" 싶을 때 그 느낌이 맞을 확률이 높거든요.
문제는 이 검색입니다. qmd라는 로컬 도구로 색인해두고 쓰는데, BM25와 벡터를 섞고 마지막에 LLM 리랭킹까지 도는 구성이에요. 색인 패턴은 **/*.md 한 줄이었고요. 볼트 안 모든 마크다운을 똑같이 취급하라는 뜻인데, 이 한 줄이 문제의 출발점이었습니다. 파일 630개, 약 90만 토큰이 전부 같은 자격으로 경쟁하고 있었거든요.
첫째, 손 안 댄 자동 기록을 빼세요
세션 로그 자동 내보내기, 웹 클리핑, 회의록 자동 전사 — 이런 게 볼트에 쌓이고 있다면 지금 검색 대상에 포함돼 있는지 확인해보세요.
제 경우 자동 export 폴더에 432개가 있었습니다. 손질해서 정리한 노트가 196개였으니 덤프가 정리본의 두 배였어요. 토큰으로 치면 전체의 51%고요.
이게 왜 문제냐면, 덤프는 같은 내용을 더 장황하게 담고 있어서 키워드가 더 많이 걸립니다. "이 기능이 기록을 어디로 보내나"를 물었더니 1등도 2등도 그 덤프였어요. 제가 손으로 정리해둔 노트가 밀린 거죠. 정리를 잘해둘수록 짧아지고, 짧아질수록 검색에서 불리해지는 구조였습니다.
확인은 이렇게 합니다. 폴더별 파일 수와 마지막 갱신일을 같이 보세요.
find . -name '*.md' | wc -l
find . -name '*.md' -exec stat -f '%Sm %N' -t '%Y-%m-%d' {} + | sort -r | head여기서 제가 한 방 맞았는데, 그 432개는 6월 12일 이후 갱신이 0건이었어요. 그 무렵 도구를 갈아치우면서 자동 내보내기가 같이 멈춘 걸 두 달 가까이 모르고 있었습니다. 죽은 파일이 검색의 절반을 차지한 채로 계속 정답을 밀어내고 있었던 거예요.
뺄 때는 지우지 마시고 강등하세요. 저는 볼트 밖 아카이브 폴더로 옮기고 별도 컬렉션으로 등록한 다음 기본 검색에서만 제외했습니다. 나중에 저기서 건질 게 나오면 그때 명시적으로 뒤지면 되니까요.
qmd collection add "경로/Archive" --name wiki-archive
qmd collection exclude wiki-archive둘째, 목차와 규칙 문서 를 빼세요
이건 제가 예상 못 했던 건데, 효과는 첫 번째만큼 컸어요.
지식베이스를 좀 굴리다 보면 "어디에 뭐가 있는지" 적어둔 인덱스 문서가 생깁니다. 저는 INDEX.md에 페이지 195개를 한 줄씩 정리해뒀어요. 작성 규칙을 적어둔 문서도 따로 있었고요.
덤프를 치우고 다시 재봤더니 이 목차가 검색 1등(89%)으로 올라왔습니다. 아까는 덤프에 가려 안 보이던 게, 경쟁자가 줄어드니 튀어 오른 거예요. 목차에는 모든 주제의 키워드가 한 줄씩 다 들어 있으니 무슨 질문을 던져도 얼마간 걸리거든요. 21,370토큰짜리 키워드 사전이 색인에 앉아 있던 셈입니다.
목차는 검색으로 찾을 문서가 아니라 열어서 읽는 문서예요. AI가 "어디를 볼지" 정할 때 직접 읽게 두고, 검색 후보에서는 빼는 게 맞습니다.
도구가 파일 단위 제외를 지원하면 그걸 쓰시면 되고, 제가 쓰는 도구는 폴더 단위만 돼서 색인 범위를 노트 폴더로만 좁혔어요. 볼트 루트를 통째로 걸던 걸 하위 폴더 셋으로 나눈 겁니다.
qmd collection remove wiki
qmd collection add "볼트/decisions" --name wiki-decisions
qmd collection add "볼트/lessons" --name wiki-lessons
qmd collection add "볼트/projects" --name wiki-projects파일은 하나도 안 옮겼습니다. 색인 범위만 바꾼 거라 기존에 경로를 참조하던 스킬이나 자동화는 그대로 돌아가요.
여기까지 하니 검색 대상이 630개에서 197개로 줄었고, 세 질문 중 둘이 정답을 1등으로 올렸습니다. 손대기 전엔 하나였고요.
셋째, 무거운 검색을 기본값에서 빼세요
앞의 둘이 정확도 얘기였다면 이건 속도 얘기입니다. 그리고 제가 제일 크게 착각하고 있던 부분이에요.
검색 대상을 3분의 1로 줄였으니 당연히 빨라졌겠거니 했는데, 22~28초가 나왔습니다. 고치기 전이 7~24초였으니 오히려 늘었어요.
시간을 먹는 게 파일 개수가 아니었습니다. 제가 기본값으로 쓰던 검색이 LLM을 세 번 부르거든요. 질문을 여러 갈래로 확장하고, 가상의 답변을 만들어 벡터를 뽑고(HyDE), 마지막에 후보를 다시 읽어 순위를 고칩니다. 이 세 번은 색인이 아무리 작아져도 그대로 듭니 다.
그래서 LLM을 전혀 안 부르는 BM25 검색으로 같은 질문을 던져봤어요.
0.11초였습니다. 세 번 반복해도 편차가 몇 밀리초였고요. 200배쯤 차이인데 정확도가 나쁘지도 않았어요. 리랭킹이 끝까지 못 맞히던 질문 하나를 BM25가 맞혔습니다.
물론 만능은 아니에요. 제가 "어디로 보내지"라고 묻는데 노트엔 "전송 경로"라고 적혀 있으면 단어가 안 겹쳐서 BM25는 못 잡습니다. 그건 리랭킹만 풀었어요. 결국 넷 중 어느 조합도 세 질문을 다 맞히지는 못했습니다.
그래서 순서를 두는 쪽으로 갔어요. BM25를 먼저 걸고, 빈손이거나 질문 표현이 문서 표현과 안 겹칠 때만 무거운 쪽으로 올리는 겁니다. 스킬 문서에 이렇게 적어뒀습니다.
1단계 — qmd search "키워드" -n 10 (0.1초, LLM 0회)
2단계 — 1단계가 빈손일 때만
qmd query "질문" -n 5 (22~28초, LLM 3회)대부분의 조회가 0.1초에 끝나고, 어려운 질문에만 비용을 씁니다.
안 해도 됐던 것
이 실험은 "제2의 뇌를 만들려면 목록(index)부터 제대로 만들라"는 영어권 글에서 출발했어요. 딱 하나만 한다면 목록을 만들라고까지 하더라고요.
제 목록은 그 기준으로 확실히 잘못돼 있었습니다. 한 줄에 이름과 링크와 한 문장만 쓰라고 했는데, 저는 항목당 평균 196자에 71%가 120자를 넘겼어요. 그래서 첫 문장까지만 남기고 잘라봤더니 21,313토큰이 11,288토큰이 되더군요. 47% 감소.
그런데 적용은 안 했습니다. 목차를 색인에서 빼고 나니 급할 이유가 없어졌거든요. 검색을 방해하던 문제는 이미 해결됐고, 남은 건 사람이 읽기에 좀 길다는 것뿐인데 그건 천천히 해도 되는 일이에요.
노트 200개 규모에서는 목록을 다듬는 것보다 무엇을 검색 대상에 넣을지 정하는 게 먼저였습니다.
정리하면
지식베이스 검색이 빗나갈 때 엔진부터 의심하기 쉬운데, 먼저 색인에 뭐가 들어가 있는지 보시길 권해요. 손 안 댄 자동 기록, 목 차·규칙 같은 메타 문서, 이 둘만 빼도 꽤 달라집니다. 그리고 기본 검색을 가벼운 쪽으로 두고 무거운 건 실패했을 때만 부르면 체감 속도가 크게 바뀌고요.
제가 이번에 제일 뜨끔했던 건 두 달간 죽어 있던 자동화를 몰랐다는 점이에요. 쌓는 건 자동으로 만들어놓고 그게 살아 있는지 보는 장치는 안 만들었던 거죠. 게다가 손질해서 노트로 올리는 일은 여전히 수동이라, 이대로 두면 몇 달 뒤 창고가 또 불어나서 같은 상태로 돌아옵니다.
쌓는 자동화를 만들 때 거르는 자동화를 같이 안 만들면 언젠가 한 번은 이 청소를 하게 되나 봐요. 다음 숙제로 남겨뒀습니다.
