raw를 전부 안 읽어도 답이 나오는 이유
세컨드브레인을 어느 정도 쌓으면 반드시 맞닥뜨리는 순간이 있다. 뭔가 찾아야 하는데, 어디서 시작해야 할지 막막한 것.
raw 폴더를 열면 노트가 수십 개다. LLM에게 “여기서 X에 대한 내용 찾아봐”라고 지시하면, 파일을 하나하나 열다가 토큰이 다 간다. 그 과정에서 정작 중요한 내용을 빠뜨리는 경우도 생긴다.
/query 스킬을 만들면서 이 문제를 제일 오래 붙잡았다. “raw 다 읽어봐”는 지시가 아니라 포기 선언이나 다름없었다. 파일이 쌓일수록 탐색 비용도 같이 쌓이는데, 이걸 해결하지 않으면 위키가 쌓일수록 오히려 느려지는 역설이 생긴다.
방향은 단순했다. 읽는 순서를 정하는 것. 그 순서의 기준은 “신뢰도”였다.
신뢰도 순서로 읽으면 대부분 raw까지 안 간다
신뢰도라고 표현했지만 실제로는 이런 뜻이다. “이미 누군가가 한 번 검증한 신호인가.”
wiki 정리 페이지는 LLM이 소화를 거친 결과물이다. pinned.md는 내가 직접 손으로 골라낸 항목들이다. project-logs는 실제 작업이 끝난 뒤 남긴 기록이다. 반면 raw-cache는 자동 생성된 월별 요약이라 노이즈가 섞인다. raw 파일 원본은 소화 전 상태다.
이 차이가 탐색 순서를 결정한다.
4단계 인덱스
1단계: wiki/ 정리 페이지
가장 먼저 본다. wiki/ 아래 파일들은 한 번은 소화 과정을 거친 정리본이다. 여기서 답이 나오면 raw를 열 이유가 없다.
frontmatter에 sources: 필드가 있으면 원본 파일 경로가 명시돼 있어서, 더 파고들 때도 무작정 탐색하지 않아도 된다. 이미 경로가 박혀 있으니까.
2단계: pinned.md
raw/inbox/pinned.md. 내가 직접 “이건 나중에 써야 한다”고 박아놓은 미소화 항목들이다.
소화가 끝난 건 아니지만 신호 밀도가 높다. 수동으로 고른 거라 노이즈가 적고, raw-cache보다 실시간성이 좋다. 체크 표시(✅)가 없는 항목이 아직 처리 안 된 것들이다.
3단계: project-logs
index/project-log/<프로젝트>.md. 각 프로젝트 docs/log.md에서 날짜·타입·한 줄 요약 헤더만 뽑아놓은 파일이다. /ingest-docs를 실행할 때마다 자동으로 갱신된다.
프로젝트 관련 질문에서 이 단계가 특히 효과적이다. “X 프로젝트에서 뭐 했더라”, “그 기능 언제 구현했지” 같은 건 wiki보다 여기서 빠르게 잡힌다. 날짜와 타입이 있어서 타임라인을 따라가기도 쉽다.
블로그 소재 발굴에서도 마찬가지다. 실제 작업 기록이라 story/lesson 밀도가 raw-cache 세션보다 높다. raw-cache는 대화 흐름 전체를 요약하지만, project-logs는 “실제로 결정하고 실행한 것”만 담겨 있다. 그 차이가 소재 품질로 이어진다.
4단계: raw-cache
index/chrono/YYYY-MM.md. /ingest-index가 raw 세션들을 월별로 요약한 파일이다.
광범위 탐색이 가능하지만 노이즈가 있다. 사용법은 topics나 summary 키워드로 grep해서 후보 path를 추린 뒤 해당 파일만 여는 것이다. 전부 읽는 게 아니라 후보를 좁히는 데 쓴다.
raw/projects 폴더는 raw-cache에 포함되지 않는다. 프로젝트 작업 기록은 project-logs에서 따로 관리하기 때문이다.
이 네 단계에서도 안 잡히면 raw/를 직접 탐색한다. 마지막 수단이다.
스킬마다 이 순서를 다르게 쓴다
인덱스 순서는 같아도 스킬마다 질문의 성격이 다르다. 그래서 각 스킬이 이 순서를 같은 방식으로 따르지는 않는다.
/query
wiki → pinned.md → project-logs → raw-cache → raw 직접 순서로 탐색한다.
“X 프로젝트 관련해서 뭐 했지” 같은 프로젝트 맥락 질문이 들어오면 project-logs부터 간다. raw-cache를 건너뛰는 경우도 많다. project-logs가 wiki와 비슷한 속도로 답을 내놓기 때문이다.
반면 특정 개념이나 학습 관련 질문이면 wiki를 먼저 충분히 탐색하고, 거기서 안 잡히면 raw-cache로 간다.
/blog-mine
소재 발굴이 목적이라 탐색 우선순위가 살짝 다르다.
- pinned.md 미소화 항목을 먼저 훑는다 (점수 +2 보너스)
- wiki에서
content_potential태그가 붙은 페이지 수집 - project-logs 스캔. 실제 작업 기록이라 story/lesson 밀도가 높다 (점수 +1)
- raw-cache 또는 최근 세션 폴백으로 나머지 수집
pinned.md가 wiki보다 앞으로 올라온 건 실시간성 때문이다. wiki에 정리되기 전의 신선한 소재가 pinned에 더 많다. project-logs가 raw-cache 앞에 오는 건 신호 밀도 차이다.
project-logs에서 나온 소재는 결과 목록에 (project-log) 태그가 붙는다. 소재 출처를 구분해두면 나중에 글 쓸 때 어디서 찾아야 할지 바로 알 수 있다.
/ingest-docs
프로젝트 docs/를 동기화할 때 project-logs 파일도 함께 생성하거나 갱신한다.
구체적으로는 raw/projects/<프로젝트>/docs/log.md의 ## [날짜] 타입 | 요약 헤더 줄을 추출해서 index/project-log/<프로젝트>.md에 적는다. 최근 30건과 전체 통계를 유지한다.
핵심은 이 작업이 자동이라는 점이다. 프로젝트에서 작업하고 docs/log.md에 기록하면, /ingest-docs를 한 번 실행하는 것만으로 그 기록이 위키 검색 범주에 들어온다. 별도로 위키에 옮겨 적을 필요가 없다.
실제 탐색은 이렇게 흘러간다
대부분의 질문은 wiki나 project-logs에서 막힌다. 한 번 정리해둔 게 있으면 raw를 열지 않는다. “X 프로젝트에서 뭐 했더라” 류 질문은 project-logs가 먼저 잡아낸다.
raw-cache는 주로 wiki와 project-logs 어디에도 없는 내용을 찾을 때 쓴다. 최근에 raw에 들어왔지만 아직 소화가 안 된 내용들이 여기에 있다.
raw/ 직접 탐색까지 가는 경우는 드물다. 위 네 단계를 순서대로 타면 대개 그 전에 답이 나오기 때문이다. 드물다는 말은 “없다”는 뜻이 아니다. raw에만 있는 내용은 분명히 있고, 그럴 때는 그냥 raw를 뒤진다. 다만 그게 첫 번째 선택지가 아닌 것이다.
인덱스가 4단계인 건 설계상 결정이 아니라 경험에서 왔다. 어떤 질문에 어떤 소스가 답을 내놓는지 패턴을 보다가 자연스럽게 생긴 순서다. 앞으로 위키가 더 쌓이면 이 순서가 더 중요해질 거라 생각한다.