내 LLM 위키에 검색을 붙여 보며 배운 것

나는 안드레 카파시(Andrej Karpathy)가 제안한 LLM Wiki 방식으로 개인 위키를 만들어 쓰고 있다. AI가 문서를 찾아서 답하는 방식을 공부하다가, 이 위키에 검색을 직접 붙여 보았다. 결론부터 말하면, 검색은 조금 좋아졌지만 답변 품질은 그대로였고, 적용한 지 하루 만에 방식을 바꿨다. 질문할 때마다 검색 결과를 자동으로 붙이던 것을, 필요할 때만 AI가 검색하도록 바꾼 것이다. 이번 글에서는 왜 시작했고, 어떻게 진행했고, 결과가 예상과 달랐을 때 무엇을 보고 결정했는지 정리하려고 한다.

1. 왜 시작했을까?

안드레 카파시는 2026년 4월에 LLM Wiki라는 방식을 공개했다. 질문할 때마다 AI가 원본 자료를 처음부터 다시 찾게 하는 대신, AI가 자료를 읽고 마크다운 위키로 정리해 두고 계속 관리하게 하는 방식이다. 위키에는 페이지 목록을 담은 목차 파일(index.md)과 변경 기록(log.md)을 두고, 새 자료를 넣거나(ingest) 오래된 내용을 점검하는(lint) 일도 AI가 맡는다.

나는 이 방식을 따라 Claude Code가 나에 대해 알아야 할 것들을 모아 둔 개인 위키를 만들었다. 내 경력과 기술 스택, 사이드 프로젝트 저장소가 어디에 있는지, 블로그는 어떤 규칙으로 쓰는지 같은 내용이다. Claude Code로 세션을 시작하면 위키의 목차가 자동으로 들어가고, Claude는 목차를 보고 필요한 페이지를 직접 열어서 읽는다.

그런데 이 방식은 목차에 적힌 페이지 제목과 한 줄 설명에 기대고 있다. 답이 페이지 본문 깊숙이 있으면 목차만 보고는 어느 페이지를 열어야 할지 알기 어렵다. 지금은 페이지가 14개뿐이라 괜찮지만, 위키가 커지면 이 부분이 문제가 될 것 같았다. 그래서 질문과 관련 있는 부분을 찾아 주는 검색을 붙여 보기로 했고, 생각해 본 방식은 네 가지였다.

이 중에서 B안을 먼저 해 보기로 했다. C안은 질문할 때마다 AI를 한 번 더 불러야 하니 느려지고 비용이 든다. D안은 위키를 고칠 때마다 요약을 다시 만들어야 한다. B안은 AI 없이 평범한 검색만으로 할 수 있으니, 가장 단순한 것부터 해 보고 부족하면 그때 C안이나 D안을 보기로 했다.

이 작업에는 개인적인 목적도 하나 있었다. 나는 LLM 배경지식이 거의 없는 백엔드 개발자인데, 이런 개선을 직접 해 보면서 무엇을 알아야 하는지 확인해 보고 싶었다.

2. LLM을 몰라도 이해할 수 있었을까?

나는 백엔드 개발자이고 LLM에 대한 배경지식은 거의 없다. 그래서 처음에는 용어부터 막혔다. 그런데 하나씩 풀어 보니 대부분 이미 알고 있는 개념이었다.

LLM은 서버에 기억을 남기지 않기 때문에, 내 위키 내용을 알려면 그 내용이 매번 요청 안에 들어가 있어야 한다. 위키 전체를 넣을 수는 없으니 필요한 부분만 찾아서 넣어야 하고, 결국 이건 검색 문제였다. 검색이 틀리면 AI가 아무리 좋아도 답이 틀린다.

3. 어떻게 진행했을까?

작업은 Claude Code에게 맡겼다. 다만 바로 만들게 하지 않고, 순서를 정해서 단계마다 검토를 거치게 했다.

3-1. 기준부터 정했다

가장 먼저 한 일은 무엇이 좋아진 것인지 기준을 정하는 것이었다. 내가 실제로 물어볼 법한 질문 56개를 만들고, 질문마다 위키의 어느 부분에 답이 있는지 정답을 표시했다. 예를 들면 ‘블로그에 연재한 시리즈가 뭐가 있었지?’, ‘개인 프로젝트 로컬 서버를 띄우려면 환경 설정을 뭐로 잡아야 해?’ 같은 질문이다. 위키와 상관없는 질문(정규식 짜 줘, 도커 healthcheck 설정법 등)도 6개 섞었다. 그리고 상위 3개 검색 결과 안에 정답이 들어오는 비율이 지금보다 15%p 이상 오르면 통과라는 기준을 정했다.

이 질문과 정답은 구현을 시작하기 전에 확정해서 커밋했다. 결과를 본 뒤에 기준을 바꾸면 어떤 결과든 성공처럼 보이게 만들 수 있기 때문이다. 백엔드에서 성능 개선을 하기 전에 목표 응답 시간을 먼저 정해 두는 것과 같다고 생각했다.

3-2. 설계와 구현을 따로 검토받았다

설계를 먼저 쓰게 하고, 검색 분야를 잘 아는 역할을 맡긴 별도의 AI에게 검토를 받게 했다. 설계는 두 번 반려되고 세 번째에 통과했다. 기억에 남는 지적이 있었다. 한국어는 조사가 붙어 단어 모양이 계속 바뀌기 때문에 단어를 두 글자씩 잘라서 검색하기로 했는데, 이렇게 하면 ‘자동차보험’과 ‘자동화’가 ‘자동’이라는 조각을 공유해서 서로 관련 있는 것처럼 잡힌다는 것이었다. 나 혼자 했다면 놓쳤을 문제였다.

구현이 끝난 뒤에는 코드를 짜지 않은 또 다른 AI가 리뷰를 했고, 두 번째 리뷰에서 더 이상 지적할 것이 없을 때까지 수정을 반복했다.

3-3. 실제 답변까지 확인했다

검색 결과가 정확해졌다고 해서 Claude의 답이 좋아졌다고 말할 수는 없다. 그래서 마지막에는 Claude에게 56개 질문에 직접 답하게 하고, 답변을 채점했다. 지금 방식, 검색 결과의 위치만 알려 주는 방식, 검색 결과의 본문까지 보여 주는 방식 세 가지를 각각 56번씩, 총 168번 실행했다. 채점은 어떤 방식의 답인지 모르는 상태의 AI가 정답과 대조해서 했다. 비용은 12.5달러 정도 들었다.

4. 결과는 어땠을까?

4-1. 안전장치가 오히려 정답을 걸러 냈다

검색은 관련 있는 문서가 하나도 없어도 점수가 가장 높은 3개를 돌려준다. 내 위키에는 나와 내 프로젝트에 관한 내용만 있는데, 위키와 상관없는 일반적인 개발 질문을 해도 질문에 들어 있는 단어와 조금이라도 겹치는 섹션 3개를 찾아서 붙인다는 뜻이다. 실제로 ‘git rebase 충돌 해결 방법’을 검색해 보니 아래 3개가 나왔다.

셋 다 rebase와는 상관이 없다. 질문의 단어 하나가 그 섹션 어딘가에 들어 있어서 점수가 조금 나왔을 뿐이다.

이걸 막으려고 설계에 기준선을 하나 넣었다. 질문의 핵심 단어가 두 개 이상 겹칠 때만 검색 결과를 붙이도록 한 것이다.

그런데 이 기준선이 문제였다. ‘블로그에 연재한 시리즈가 뭐가 있었지?’ 같은 짧은 질문은 핵심 단어가 하나뿐이라, 검색이 정답을 1등으로 찾고도 기준선에서 걸러졌다.

본문 검색(B안)만 붙이면 6%p 좋아졌지만, 기준선까지 넣으면 오히려 12%p 나빠졌다. 처음 정한 통과 기준(15%p)에는 둘 다 못 미쳤다.

4-2. 답변 품질은 그대로였다

실제 답변을 채점한 결과는 더 예상 밖이었다.

세 방식 모두 95점 안팎이었다. 내 위키는 아직 14페이지밖에 되지 않아서, 목차만 줘도 Claude가 알아서 맞는 페이지를 열고 거의 다 맞혔던 것이다. 검색을 아무리 잘해도 더 좋아질 여지가 없었다. 나중에 카파시의 글을 다시 읽어 보니, 작은 규모에서는 목차 파일로 충분하고 위키가 커지면 제대로 된 검색이 필요해진다고 적혀 있었다. 내 위키가 딱 그 앞 단계에 있었던 셈이다. 내가 걱정했던 부분, 즉 상관없는 위키 내용이 붙으면 답이 산만해질 거라는 걱정도 실제로는 한 건도 나타나지 않았다.

5. 적용하고 나서 어떻게 됐을까?

5-1. 일단 적용했다

처음 정한 기준으로 보면 이 변경은 실패다. 그래도 나는 본문 검색(B안)을 기준선 없이, 질문할 때마다 검색 결과의 본문을 자동으로 붙이는 방식으로 적용했다. 이유는 세 가지였다.

1. 위키는 계속 커진다. 지금은 목차만으로 충분하지만, 페이지가 늘어날수록 목차만 보고 맞는 페이지를 고르기는 어려워진다.
2. 손해가 없었다. 상관없는 내용이 붙어도 답이 나빠지지 않았고, 지어낸 답은 오히려 0건이었다.
3. 조금이지만 효율이 좋아졌다. 답이 이미 눈앞에 있으니 파일을 여는 횟수가 14% 정도 줄었다.

5-2. 직접 써 보니 테스트에서 안 보이던 것이 보였다

적용한 직후, Claude에게 이 기능에 대해 몇 가지를 물어봤다. ‘이 기능이 내가 여는 모든 프로젝트에 적용돼?’, ‘질문할 때마다 위키 파일을 전부 다시 읽는 거야?’ 같은 질문이었다. 그런데 이 질문들에도 4-1에서 본 것처럼 상관없는 위키 섹션이 3개씩 함께 붙어서 Claude에게 전달됐다. 질문 5개에 섹션 15개가 붙었는데, 질문과 관련 있는 것은 하나도 없었다. ‘프로젝트’, ‘파일’ 같은 흔한 단어가 위키 곳곳에 있었기 때문이다. 그중에는 가족이나 재무처럼 개인적인 내용도 섞여 있었다.

4장의 테스트에서는 이게 문제로 보이지 않았다. 질문 하나를 던지고 답 하나를 받는 상황에서 답이 맞았는지만 쟀기 때문이다. 하지만 한 대화 안에서 질문을 이어 가 보니, 테스트에서 재지 않은 문제가 두 가지 보였다.

1. 상관없는 내용이 대화에 계속 쌓인다. Claude 같은 AI는 이전 대화를 따로 기억하지 않는다. 그래서 대화를 이어 갈 때마다 처음부터 지금까지의 대화 전체를 다시 읽는다. 질문에 붙은 위키 섹션도 대화의 일부로 남기 때문에, 질문을 이어 갈수록 상관없는 글이 쌓이고 AI는 매번 그것까지 다시 읽게 된다. 이메일 스레드에 답장할 때마다 상관없는 첨부 파일이 하나씩 늘어나는 것과 비슷하다. 질문 한 번에 붙는 양은 1,300자 정도지만, 한 대화에서 50번 질문하면 6만 자가 넘는다.
2. 어떤 작업을 하든 개인적인 내용이 끼어든다. 이 기능은 내 컴퓨터에서 여는 모든 Claude Code 대화에 적용된다. 블로그 글을 고치든 사이드 프로젝트 코드를 짜든, 질문의 단어가 조금만 겹치면 가족이나 재무 이야기가 대화에 들어온다. 대화 기록을 다른 사람에게 보여 줄 일이 생기면 곤란할 수 있다.

5-3. 필요할 때만 찾게 바꿨다

그래서 하루 만에 방식을 바꿨다. 질문할 때마다 자동으로 붙이는 대신, 세션을 시작할 때 ‘나와 내 프로젝트에 관한 질문이면 이 검색 명령을 실행해서 확인하라’는 안내만 넣었다. Claude는 원래도 목차를 보고 필요한 페이지를 직접 열어 봤기 때문에, 검색도 같은 판단으로 필요할 때만 쓰게 된다. 백엔드로 치면 연관 데이터를 매번 조인해서 가져오던 것(eager loading)을, 필요할 때만 조회하도록(lazy loading) 바꾼 것과 같다.

만들어 둔 검색 방식과 평가용 질문은 그대로 남겨 두었다. Claude가 검색해야 할 때 잊지 않고 검색하는지는 아직 재 보지 않았다. 위키가 30~40페이지 정도로 커지면 같은 질문으로 다시 측정해 볼 생각이다.

6. 무엇을 배웠을까?

첫째, AI를 더 쓰기 전에 가장 단순한 방법부터 해 보길 잘했다. AI 없이 평범한 검색만 붙였는데도 답변 품질은 이미 95점 안팎이었다. 지금 내 위키에서는 검색을 아무리 똑똑하게 만들어도 더 좋아질 여지가 없었다는 뜻이다. 처음부터 AI로 페이지 요약을 미리 만들어 두는 방식(D안)부터 했다면, 위키를 고칠 때마다 요약을 다시 만드는 비용만 들고 얻는 것은 없었을 것이다. 백엔드에서 느린 API를 고칠 때 서버부터 늘리지 않고 먼저 어디가 느린지 재 보는 것과 같다고 생각한다.

둘째, 검색 정확도만 보고 판단하면 안 된다. 검색 정확도만 봤다면 나는 ‘6%p 좋아졌으니 성공’이라고 하거나 ‘기준 미달이니 실패’라고 했을 것이다. 실제 답변까지 확인하고 나서야 지금은 둘 사이에 차이가 없다는 것을 알 수 있었다.

셋째, 기준을 먼저 정해 두니 실패도 쓸모가 있었다. 기준이 없었다면 50%라는 숫자를 보고 설정값을 이리저리 바꿔 가며 숫자를 올리려고 했을 것이다. 기준이 있었기 때문에 왜 떨어졌는지를 먼저 들여다볼 수 있었다.

넷째, 테스트로 재지 않은 비용은 직접 써 봐야 보인다. 168번이나 답변을 채점했지만, 그 테스트는 질문 하나에 답 하나를 받는 상황만 쟀다. 한 대화에서 질문을 이어 가며 상관없는 내용이 쌓이는 상황이나, 다른 작업 중에 개인적인 내용이 끼어드는 상황은 테스트에 없었다. 숫자가 괜찮다고 끝내지 않고 실제로 써 보면서 확인하는 단계가 필요하다고 생각한다.

정리

내 개인 위키에 본문을 소제목 단위로 찾는 검색을 붙여 보았다. 검색은 조금 좋아졌지만, 위키가 아직 작아서 답변 품질에는 차이가 없었다. 위키가 커질수록 효과가 커질 것으로 보고 적용했지만, 하루 써 보니 질문마다 상관없는 내용이 붙는 문제가 있어서 필요할 때만 검색하도록 바꿨다. LLM을 잘 모르는 백엔드 개발자로서도, 기준을 먼저 정하고 측정해서 판단하는 방식은 그대로 통했다. 그리고 측정만으로는 부족하고, 실제로 써 보는 것까지가 검증이라는 것도 알게 되었다. 다음에는 이번에 막혔던 용어들을 제대로 공부해 보려고 한다.