세컨드 브레인을 만들고 나서 한 가지 의문이 생겼다. digest 스킬을 돌리면 wiki 페이지가 쌓여야 하는데, 막상 돌려도 결과가 별로 안 나왔다.
스킬이 잘못된 건가 싶어서 신호 구분 로직도 붙이고, pin 기능도 만들었다. 중요한 건 먼저 보게, 잡담은 걸러내게. 그런데 그것도 별로 달라지지 않았다. 쌓아둔 raw는 1861개인데 wiki는 제자리였다.
예상과 달랐던 것
나는 문제가 소화 품질에 있다고 생각했다. digest가 얼마나 잘 읽고 종합하느냐. 그래서 기준을 더 정교하게, 신호 감지를 더 똑똑하게.
아니었다. digest가 찾질 못하고 있었다.
raw 파일이 1861개인데, LLM도 그걸 다 읽지는 않는다. 현실적으로 파일명을 보고 열어볼지 말지를 판단한다. 그런데 파일명은 대부분 날짜+세션 id 조합이거나, 아니면 첫 문장 일부다. 2026-06-23__local-command-caveat Caveat The messages below wer__a48bda7b.md 같은 식이다. 거기서 “이 파일에 위키 소재가 있다”는 걸 알 수 없다.
pin 기능도, 고신호 구분 로직도, 벌크로 쌓인 파일들한테는 소급 적용이 안 됐다. 나중에 만든 기능이니까. 수백 개짜리 더미는 그냥 이름만 있는 파일들로 남아있었다.
digest가 멍청한 게 아니라, 탐색할 수 있는 정보가 파일명뿐이었다.
그래서 요약본을 만들기로 했다
LLM이 읽을 수 있는 인덱스여야 했다. 파일명이 아니라 내용을 압축한, LLM이 훑어보고 “이 파일 읽겠다”를 판단할 수 있는 그런 것.
핵심은 단순하게 정했다. 파일을 다 읽는다. 주제가 전환될 때마다 주제문을 적는다. 그걸 topics + summary로 뽑아서 캐시 파일에 모아둔다. 파일 하나당:
path: raw/...경로.md
topics: [키워드1, 키워드2, ...]
summary: 무슨 맥락에서 무슨 일이 있었는지 2~3줄.작업은 오래 걸렸다. 파일마다 실제로 다 읽어야 하니까. projects 폴더 제외하고 돌렸는데, 미처리 파일이 341개였다. 크기 편차가 커서(최대 810KB) 93개 배치로 쪼개 병렬로 처리했다. 최종적으로 635개 엔트리가 쌓였다.
그다음 digest를 돌렸더니
위키 페이지가 쏟아졌다. 한 번 돌렸는데 새로 생긴 게 17개, 갱신된 게 70개였다. 87개가 한 세션에 건드려진 거다.
digest 로직은 아무것도 안 바뀌었다. 전에 안 됐던 게 지금은 됐다. 차이는 하나였다. digest가 raw를 탐색하기 전에 캐시를 먼저 훑고, “이 다섯 개 읽겠다”로 후보를 좁힌 다음 그것만 실제로 읽는다. 이름이 아니라 내용으로 후보를 고를 수 있게 됐다.
내가 틀렸던 지점
위키가 안 쌓이는 이유를 소화 로직에서 찾고 있었다. 더 정교한 기준, 더 똑똑한 신호 감지. 근데 문제는 소화가 아니었다. 찾지를 못하고 있었던 거다.
LLM이 파일 더미를 탐색하는 방식이 파일명 기반이라는 걸, 그 한계를 직접 겪기 전까지 생각 못 했다. 새로 쌓이는 파일은 실시간으로 캐시되니까 괜찮은데, 이미 수백 개 쌓인 더미는 이름밖에 없는 채로 방치돼 있었다.
요약본은 나를 위한 것이기도 하지만, LLM이 읽을 수 있어야 하는 거다. 사람이 책 목차를 보고 어느 챕터를 펼칠지 결정하듯, LLM이 캐시를 훑고 어떤 raw 파일을 열지를 결정한다. 그 한 겹이 없으면, 파일이 아무리 많아도 찾을 수가 없다.
남는 것
2차 인덱스라는 이름을 붙였는데, 사실 별거 아니다. 파일을 다 읽고 주제 전환마다 주제문을 쓴 것. 그게 위키 생산성을 바꿨다.