옵시디언 LLM 위키, 자동으로 쌓은 노트 일부를 접었다

노트에서 뽑은 이름 12만 7천 개를 엮어놨는데, 그걸 실제로 가져다 쓴 문서는 두 건이었다.

옵시디언 LLM 위키를 돌린 지 꽤 됐다. 옵시디언(마크다운 노트 앱)에 쌓은 노트를 LLM(대형 언어 모델)이 읽어 엮는 위키다. 위키가 매일 밤 알아서 돌고 주간보고도 꼬박꼬박 오니까 나는 잘 굴러가는 줄 알았다. 근데 어느 날 문득 걸리더라. 이거 내가 마지막으로 열어본 게 언제지? 그 질문 하나로 시작해서 일부를 접고 일부는 멈춰 두되 최신 상태만 유지하고(얼리고) 일부는 남겼다. 이 글은 어떻게 만들었는지가 아니라 무엇을 기준으로 접었는지를 다룬다.

📑 목차

• 1. 118시간 들여 쌓은 위키를 관리만 하고 안 쓰는 것 같았다
• 2. 만든 개수는 쓰인다는 증거가 아니었다
• 3. 위키를 가리킨 문서 58건 중 실제 사용은 2건이었다
• 4. 세 층으로 가르니 쓰이는 층은 그래프 없이 돌고 있었다
• 5. 미해결 모순 5건 중 4건은 한 문장을 네 번 잘못 읽은 거였다
• 6. 처방만 늘리고 멈추는 기준은 없었다
• 7. 처분: 모순탐지는 접고 그래프는 얼리고 인사이트 노트는 남기고 활용거리 칸은 8주 판정에 걸었다

---

1. 118시간 들여 쌓은 위키를 관리만 하고 안 쓰는 것 같았다

LLM은 챗GPT나 클로드 같은 대형 언어 모델을 말한다. LLM 위키는 이 모델이 옵시디언(마크다운 노트 앱) (obsidian.md)에 쌓인 노트를 하나씩 읽고 거기 나오는 사람·회사·개념 이름을 뽑아서 서로 엮어두는 층이다. 이렇게 뽑힌 이름 하나하나를 엔티티(entity)라고 부르고 엔티티끼리 이어진 지도를 그래프라고 부른다. 그 위에 주제별 페이지와 주간보고가 얹혀 있었다. 엮는 방법은 개인 위키 후기에 적어놨다.

노트 16,098개를 처음 한 바퀴 도는 데 노트마다 26.5초씩 걸려서 전체로는 118시간이 들었다. 결과물은 157MB였고 엔티티는 12만 7천 개를 넘었다. 그 뒤로는 매일 밤 바뀐 노트만 다시 읽는 증분 작업이 돌았다.

공도 꽤 들였다. 빠진 노트를 다시 채워 넣는 작업만 해도 하루 사이에 50건씩 열 번 넘게 돌았는데, 한 번에 100분 넘게 걸린 판도 있었다ㅋ 고장 나면 고치고 빠지면 채우고.. 그러다 보니 정작 이걸 읽는 사람이 있는지는 아무도 안 물었더라.

그래서 클로드코드(클로드를 터미널에서 코딩 작업에 부리는 도구)한테 그대로 던졌다. "관리 비용만 들고 활용은 안 하는 것 같다." 감으로 접지도 말고 하던 대로 계속 돌리지도 말고 남길지 말지를 증거로 따져달라고 했다.

2. 만든 개수는 쓰인다는 증거가 아니었다

위키 얘기를 하면 나는 엔티티 12만 7천 개와 페이지 194건부터 떠올렸다. 근데 이건 다 만들어진 양이다. 돌리면 돌릴수록 늘기만 하고 그게 어디서 쓰였는지는 한 마디도 안 해준다.

점검 장치가 없었던 것도 아니다. 자동화가 살아 있는지 보는 점검을 따로 붙여뒀었다. 결과물이 제시간에 도착하는지와 내용이 말이 되는지도 따로 봤다(점검하는 자동화). 그건 기계가 제대로 도는지를 보는 거라 누가 읽었는지는 안 잡는다. 매일 밤 멀쩡히 돌고 매주 멀쩡히 도착하는 게 오히려 잘 쓰이고 있다는 착각을 키운 듯하다.

그래서 기준을 바꿨다. 남길지 말지는 만든 양이 아니라 쓰인 흔적으로 잰다. 다른 문서가 이 위키를 가져다 인용했느냐, 그게 흔적이다.

3. 위키를 가리킨 문서 58건 중 실제 사용은 2건이었다

클로드코드는 프로젝트 문서와 기록 문서 전체에서 위키 폴더를 가리키는 문서를 전부 찾았다. 여기 쓴 도구가 grep인데, 여러 파일 안에서 특정 글자가 들어간 곳을 한꺼번에 찾아주는 명령이다. 그다음 위키 자기 자신의 설계 문서와 일일 기록을 목록에서 뺐다.

grep -rl "위키폴더" 문서폴더 | grep -v "위키 자기 문서"

위키를 가리키는 문서는 58건이 나왔다. 그중 56건이 위키가 자기 자신을 참조한 거였다. 56건은 설계 문서가 설계 문서를 부르거나 작업 기록이 작업을 적은 문서라서 나는 쓰임새로 칠 수 없었다. 실제로 쓰인 문서는 2건만 남았다. 하나는 엔티티마다 자동으로 만든 요약 페이지(엔티티 페이지)를 인용한 문서였고 다른 하나는 인사이트 노트(클로드코드와 나눈 문답에서 건질 만한 걸 적어둔 노트)의 입력으로 들어간 경우였다.

▲ 옵시디언 LLM 위키 참조 문서 58건 중 실제로 가져다 쓴 문서는 2건 (자체 제작 이미지)

새 설계를 쓰기 전에 거치는 점검 절차 안에 "위키를 먼저 찾아봐라"는 단계가 들어가 있었다. 코드상으로는 멀쩡히 구현돼 있었고. 근데 그 단계가 생긴 뒤에 쓴 설계 문서 12건 중 11건에 실제로 위키를 찾아본 기록이 없었다.

그래서 바깥에서 세야 했다. "위키 참조 단계가 있다"는 건 자기소개에 가깝다. 어느 문서에 흔적이 남았는지를 파일에서 직접 세면 그 소개가 맞는지 틀린지가 바로 드러나더라.

4. 세 층으로 가르니 쓰이는 층은 그래프 없이 돌고 있었다

위키를 한 덩어리로 놓고 "남길까 버릴까"를 물으면 답이 안 나온다. 그래서 층을 셋으로 쪼갰다.

맨 아래가 쌓는 층, 엔티티 그래프다. 그 위는 그래프에서 파생되는 층이다. 이 층에는 주제 페이지가 있고 모순탐지(노트끼리 말이 부딪히는 곳을 찾는 기능)와 주간보고도 들어 있다. 맨 위는 실제로 쓰는 층이다. 이 층에는 클로드코드와 나눈 문답에서 건질 만한 걸 따로 적어두는 인사이트 노트와 제안 대기열이 들어 있다.

인사이트 노트는 104건이 쌓여 있었고 다른 작업의 입력으로 실제로 쓰이고 있었다. 그런데 이 층은 그래프를 안 쓴다. 118시간을 부은 층은 거의 안 쓰이고 유일하게 쓰이는 층은 그 그래프 없이 혼자 돈다.

통째로 판정했으면 어떻게 됐을까. "위키 안 쓰네, 접자" 하는 순간 멀쩡히 일하던 인사이트 노트까지 같이 날아갔을 거다.. 층을 가른 게 이번 판단에서 제일 값졌던 것 같다.

▲ LLM 위키를 세 층으로 나눠 층마다 다르게 처분한 표 (자체 제작 이미지)

5. 미해결 모순 5건 중 4건은 한 문장을 네 번 잘못 읽은 거였다

주간보고에 "미해결 모순 5건"이 계속 떠 있었다. 액면 그대로 보면 다섯 개를 방치한 거고 탐지 기준을 손봐서 새 버전을 만들어야 할 것처럼 보인다.

근데 클로드코드가 부딪힌다는 원문 쌍을 하나씩 열어보니 5건 중 4건이 같은 문장에서 나왔다. "MCP는 새로운 SEO다." 이 문장은 AI 도구끼리 연결하는 규격(MCP)이 앞으로 검색최적화(SEO)만큼 중요해진다는 걸 빗댄 말이다. 그런데 모델이 이걸 사실 주장으로 읽고 다른 노트와 충돌한다고 네 번 잡았다.

이건 기준값을 조정한다고 풀리는 문제가 아니다. 모델이 비유와 주장을 못 가르는 거라 새 버전을 만들 근거가 없었다. 쓰는 곳이 0인 상태에서 쌓는 품질을 올리면, 올린 만큼 전부 버려진다. 이 문장이 맞으면 품질 개선 제안은 전부 의미가 없어진다. 그래서 개선은 미루고 남길지 말지부터 정했다.

6. 처방만 늘리고 멈추는 기준은 없었다

사실 이 문제는 전에도 짚었다. 예전에 위키를 한 번 자가진단했을 때 "쓰는 흐름이 없다"는 결론이 이미 나와 있었다. 진단은 정확했다. 근데 그때 처방이 참조 단계를 더 까는 쪽이었다. 앞에서 말한 "설계 전에 위키를 찾아봐라" 단계가 그 처방으로 생겼다. 진단이 맞았는데 처방이 빗나갔으면 처방을 한 번 더 할 게 아니라 진단으로 돌아갔어야 했다.

멈추는 기준도 없었다. 나는 위키 색인기(노트마다 엔티티 언급 횟수를 세어 두는 색인 스크립트)를 고치면서 독립 검증을 세 번째 라운드까지 돌렸다(검증 게이트 얘기). 그 검증으로 꼼꼼히 확인한 대상은 아무도 안 읽는 페이지의 언급 횟수였다ㅋㅋ

재놓고 안 열어본 숫자도 있었다. 위키를 실제로 쓴 기록을 남기는 칸이 24건 있었는데 24건 모두 만족도가 비어 있었다. 매주 그래프를 다시 만드는 작업(재빌드)이 실패 코드를 내도 나는 그냥 넘어갔다. 신호는 계속 나오는데 읽는 사람이 없었다. 이 점에서 점검 신호도 위키 본체와 똑같은 처지였다.

7. 처분: 모순탐지는 접고 그래프는 얼리고 인사이트 노트는 남기고 활용거리 칸은 8주 판정에 걸었다

클로드코드는 유지(남김)·동결(얼림)·폐기(접음)·8주 판정(8주 동안 증거를 모은 뒤 결론을 내는 것)으로 나눈 네 갈래 계획을 올렸고 내가 정할 질문 여섯 개도 같이 올렸다. 나는 다섯 개를 승인하고 하나는 보류했다.

모순탐지 작업과 위키 결과물을 따로 분석하던 자동 작업(분석 에이전트) 하나를 접었다. 둘 다 쓰는 곳이 없었다.

그래프는 얼렸다. 정확도를 올리는 작업은 멈추고 매일 밤 도는 증분만 남겼는데, 이건 하루 2~4분이면 끝난다. 증분을 살려두면 그래프가 계속 최신으로 남는다. 그러면 나중에 쓸 일이 생겨도 118시간짜리 재빌드를 다시 돌릴 필요가 없다. 버리는 것보다 되돌리기 싼 선택이 있으니 그쪽부터 쓴 거다.

인사이트 노트는 그대로 남겼다. 실제로 쓰이고 있고 그래프에 기대지도 않으니까.

애매한 게 하나 있었다. 주간보고의 "활용거리" 칸이다. 이 칸은 읽히긴 하는데 실제 실행으로 이어진 흔적이 안 보였다. 이건 지금 결론 내지 않고 8주짜리 판정 기간을 걸었다. 그 안에 "채택"으로 치려면 커밋 해시(변경 기록마다 붙는 고유 번호)나 파일 경로 같은 증거를 남겨야 한다. 판정 스크립트는 채택했다고 적기만 한 줄을 채택으로 치지 않는다. 그런데 이 판정 스크립트에서도 한 번 구멍이 나왔다. "구현 없음"이라고 쓰고 뒤에 사유를 붙인 줄을 합격으로 세고 있었던 거다. 그래서 증거가 실제로 있을 때만 합격이 되게 판정 방식을 바꿨다.

내가 직접 뺀 것도 하나 있다. 이미 등록된 노트에서 엔티티가 얼마나 덜 뽑혔는지 규모를 재보자는 안이 있었는데 취소했다. 쓰는 곳이 없는 데이터의 정확도를 재는 건 5절에서 본 함정을 한 번 더 밟는 거라서.

집행하다가 계획에 없던 구멍도 하나 나왔다. 클로드코드가 모순탐지 예약 작업만 끄고 보니, 주간보고 스크립트가 모순 목록 파일을 따로 읽고 있었다. 탐지는 멈췄는데 알림은 남은 파일을 읽어서 "미해결 5건"을 영원히 다시 띄우게 되는 구조였던 거다. 만드는 쪽과 읽는 쪽을 한꺼번에 끄는 스위치 하나로 막았다. 뭔가를 접을 땐 그걸 만드는 쪽만이 아니라 읽는 쪽까지 찾아서 같이 꺼야 하더라.

이번 조치는 전부 되돌릴 수 있고 전체를 되돌리는 데 15분이면 된다. 여섯 번째 질문은 아직 보류로 남아 있다.

비슷하게 "뭘 아예 없앨까"를 따진 적이 또 있는데, 그건 스킬 80개를 7개로 줄인 얘기다. 거기서도 먼저 재보고 나서야 어디를 자를지 보였다.

3줄 요약

• 118시간 들여 쌓은 옵시디언 LLM 위키를 가리킨 문서 58건 중 56건은 자기참조였고 실제로 가져다 쓴 건 2건이었다
• 층으로 가르니 쓰이는 층(인사이트 노트)은 그래프 없이 돌고 있었고 모순 5건 중 4건은 비유 한 문장을 잘못 읽은 거였다
• 모순탐지는 접고 그래프는 얼리고 인사이트 노트는 남겼고 애매한 칸은 8주 동안 증거로만 채택을 세게 했다

그래프는 오늘 밤에도 몇 분 돌아서 최신으로 남아 있을 거다. 읽는 사람이 생길 때까지.

---

이 글은 정보 제공이 목적이고, 작성 시점 기준이다. 요금·기능·정책은 이후 바뀔 수 있으니 결제·설치 전 공식 페이지를 한 번 확인하는 게 좋다. 특정 제품 사용을 권유하거나 결과를 보장하지 않는다.

참고한 공식 자료

• 옵시디언 공식 사이트: obsidian.md