LLM과 함께 raw·wiki·schema 3계층으로 지식 볼트 운영하기

노트 폴더를 열어 보면 파일이 5,000개가 넘는다. 전부 마크다운(글자만 있는 아주 단순한 글쓰기 파일) 형식이다. 이 파일들은 옵시디언이라는 노트 앱 안에서, '볼트'라고 부르는 하나의 큰 창고에 쌓여 있다. 처음엔 그냥 여기에 다 적었다. 캡처한 대화도, 기사에서 옮겨 적은 문장도, 회의 중 떠오른 생각도 전부 한곳에 몰아넣었다. 문제는 그다음이었다. 새로 대화를 시작할 때마다 AI 에이전트에게 "이 창고 전체를 처음부터 다시 읽어 줘"라고 시킬 수는 없었다. 파일이 몇 백 개일 때는 그럭저럭 버텼다. 몇 천 개를 넘기자 이 방식 자체가 무너졌다.

그래서 창고 위에 층을 하나 더 얹었다. 원자료(raw, 원본 그대로의 자료)는 그대로 창고에 둔다. 그 위에 AI가 계속 손봐 가며 관리하는 요약 지도를 따로 만든다. 이 글은 그 구조를 실제로 어떻게 쓰고 있는지 적은 기록이다.

원자료만 쌓아서는 안 되는 이유

메모하는 습관 자체는 나쁘지 않다. 문제는 규모다. 노트가 몇 십 개일 때는 폴더를 눈으로 훑어도 충분하다. 몇 백 개를 넘어가면 폴더 이름만으로는 안에 뭐가 들었는지 가늠이 안 된다. 몇 천 개를 넘기면 "전체를 훑는다"는 선택지 자체가 사라진다.

이 볼트에는 원자료만 5,000개가 넘는 마크다운 파일이 쌓여 있다. 새 대화를 시작할 때마다 에이전트가 이걸 처음부터 다 읽고 상황을 파악해야 한다면, 답 하나 받는 데도 한참 걸린다. 실제로 그랬다. 처음엔 관련 폴더를 통째로 열어 주고 "여기서 알아서 찾아봐"라고 시켰다. 그런데 매번 탐색을 처음부터 다시 시작하다 보니, 같은 질문을 해도 매번 답이 달라졌다. 어제 물어본 걸 오늘 또 처음부터 설명해야 했다.

필요한 건 매번 다시 찾지 않고 곧바로 쓸 수 있는, 압축된 지도였다. 전체를 다시 읽지 않아도 "어디에 뭐가 있는지"만 알려주는 요약 층. 그게 wiki 층을 따로 둔 이유다. 지금은 새 대화를 시작할 때 wiki/index.md 파일 하나만 읽어도 필요한 곳을 짚어서 더 깊이 파고들 수 있다. raw 전체를 처음부터 훑을 일은 거의 없다.

예전과 비교하면 차이가 뚜렷하다. 예전엔 질문 하나에 답하려고 관련 폴더 서너 개를 열어서 파일 이름을 하나하나 눈으로 훑었다. 지금은 인덱스에서 관련 페이지 하나만 짚으면, 거기서 필요한 raw 링크만 따라가면 된다. 걸리는 시간도 줄었지만, 더 크게 달라진 건 답의 일관성이다. 예전엔 질문이 조금만 달라져도 참고하는 raw 파일이 매번 바뀌었다. 지금은 지도를 하나만 보고 움직이니, 어제 물어본 것과 오늘 물어본 것이 같은 근거를 가리킨다.

raw·wiki·schema, 계층마다 다른 일을 한다

볼트는 세 층으로 나뉜다. 이름은 원자료(raw)·요약 지도(wiki)·규칙집(schema), 이렇게 세 개다. 각자 하는 일이 다르고 서로 겹치지 않는다.

계층	역할	주로 손대는 주체	예시
raw	원자료를 담아 두는 창고, 원문 그대로 보존	나(사람)	대화 캡처, 자막 전문, 회의 메모
wiki	raw를 압축해 다시 쓴 지도, raw로 되돌아가는 링크	LLM 에이전트	개념 노트, 영역 허브, 인덱스
schema	태그·프론트매터 규칙, 노트 양식(청사진)	사람이 정하고 에이전트가 참조	태그 택소노미(분류표), 노트 양식

raw: 원문 그대로 보존하는 창고

raw 폴더는 말 그대로 창고다. 여기엔 손을 많이 대지 않는다. 사람이 쓴 메모나 어딘가에서 가져온 원문을 거의 그대로 옮겨 둔다. 학술 논문처럼 인용 형식을 갖출 필요도 없다. 목표는 깔끔하게 다듬는 게 아니라 있는 그대로 보관하는 것이다. 나중에 다시 열어 봤을 때 "그때 이걸 왜 저장해 뒀지"만 알 수 있으면 그걸로 충분하다.

wiki: LLM이 압축해 다시 쓰는 지도

wiki는 창고가 아니라 지도다. 여기는 내가 아니라 에이전트가 주로 손을 댄다. raw 더미를 훑고 개념·영역·프로젝트·슬립박스 단위로 압축해 다시 쓴다. 중요한 건 이 층이 raw를 통째로 베낀 사본이 아니라는 점이다. 원문을 그대로 복사해 붙이면 wiki도 곧 raw만큼 부풀어서, 처음에 겪었던 문제가 그대로 되풀이된다. 그래서 wiki 노트는 짧게 요약만 쓰고, 자세한 내용이 필요하면 raw로 돌아가는 링크만 남겨 둔다.

슬립박스(zettelkasten, 독일어로 "메모 상자"라는 뜻) 개념도 여기서 한몫한다. 큰 주제 하나를 통짜 문서로 쓰지 않는다. 대신 생각 하나, 주장 하나 단위로 짧게 쪼갠 노트를 만들어 서로 링크로 잇는다. 나중에 관련 주제가 새로 들어오면 기존 노트에 문장 한두 줄만 보태거나 링크 하나만 추가하면 되는 경우가 많다. 문서를 통째로 다시 쓰는 일이 그만큼 줄어든다.

schema: 에이전트가 지키는 계약

schema는 규칙집이자 설계도다. 건물을 지을 때 청사진이 있어야 다들 같은 기준으로 짓는 것과 비슷하다. 에이전트에게 이 규칙집 없이 맡겨 보면 아무 데나 마음대로 적어 버리는 경향이 있었다. 어떤 노트는 태그가 세 개, 어떤 노트는 하나도 없이 끝났다. 그래서 최소한의 약속을 이 층에 박아 두고 에이전트가 늘 그걸 참조하게 만들었다.

새 자료를 들이고 태그·허브로 정리하는 법

새 자료가 들어올 때 실제로 밟는 7단계

새 자료가 들어올 때마다 "이걸 어떻게 정리하지"부터 매번 고민하지 않는다. 순서를 아예 고정해 두고 그대로 따라간다.

1. 관련 raw 폴더나 허브를 찾는다. 없으면 새로 만든다.
2. 소스를 원문 그대로 raw 마크다운에 옮긴다. 링크만 남기지 않는다.
3. 자료가 크면 폴더 목차 노트(인덱스)와 여러 개의 하위 노트로 쪼갠다.
4. wiki/index.md를 열어 이번 자료가 어떤 페이지에 영향을 주는지 확인한다.
5. 영향받는 wiki 페이지를 새로 만들거나 고치고, raw로 돌아가는 링크를 남긴다.
6. wiki/index.md를 갱신한다.
7. wiki/log.md에 이번 작업을 덧붙인다(append-only, 기존 기록은 지우거나 고치지 않고 뒤에 새 줄만 더하는 방식이다).

두 번째 단계에서 크게 실패한 적이 있다. 처음엔 링크만 남겨 뒀다. 나중에 다시 열어 보면 링크가 끊겨 있거나, 살아 있어도 그때 왜 저장해 뒀는지 맥락이 다 날아가 있었다. 지금은 ChatGPT 대화든 유튜브 자막이든 PDF든 본문 자체를 그대로 옮겨 적는다. 손이 더 가지만, 검색했을 때 진짜 남아서 쓸모 있는 건 결국 그 본문뿐이었다.

세 번째 단계도 그냥 넘길 일이 아니었다. 하위 문서가 200개 넘는 자료를 통째로 파일 하나에 밀어 넣은 적이 있는데, 그 파일은 열자마자 스크롤만 하다 끝났다. 지금은 큰 자료가 들어오면 무조건 목차 노트 하나와 하위 노트 여럿으로 나눈다.

네 번째와 다섯 번째 단계는 손이 제일 많이 가는 구간이다. wiki/index.md를 열어 "이번 raw 변경이 건드리는 wiki 페이지가 있는가"부터 확인한다. 있으면 그 페이지를 열어 새 내용을 반영하고, 없으면 새 페이지를 만들되 처음부터 raw 링크를 함께 넣어 둔다. 이 순서를 건너뛰고 raw만 쌓아 두면 어떻게 될까. 나중에 wiki를 몰아서 정리하려 할 때, 무엇이 이미 반영됐고 무엇이 빠졌는지 구분이 안 된다. 그래서 자료 하나를 들일 때마다 wiki 갱신까지 같은 자리에서 끝낸다.

raw는 커밋하지 않고 wiki부터 커밋하는 이유

raw는 커밋(git이라는 버전 관리 도구에 "이 상태로 저장해 둬"라고 기록을 남기는 것) 대상에서 뺀다. 원자료는 계속 흔들리는, 아직 정리되지 않은 작업 중 상태이기 때문이다. 쓰다 만 메모, 다듬기 전 초안이 raw 안에 그대로 있다. 이걸 대화할 때마다 커밋하면 커밋 기록이 온통 잡음으로 뒤덮인다. 그래서 raw 변경은 내가 명시로 요청하지 않는 한 커밋도 푸시(원격 저장소로 올려 보내는 것)도 하지 않는다.

반면 wiki는 다르다. 대화 중 raw에 쌓인 변경을 먼저 wiki로 압축해서 옮겨 적은 다음에만 커밋한다. 이 순서를 wiki-먼저 커밋 방식이라고 부른다. 이 순서를 지키면 "아직 정리 안 된 원자료"와 "믿고 써도 되는 압축된 지식"이 한 커밋 안에서 섞이지 않는다.

경계를 나누고 나서 달라진 게 하나 있다. 커밋 기록만 봐도 이번 대화에서 뭐가 진짜 결론이 났는지 바로 보인다. raw 쪽은 기록을 뒤질 필요도 없다. 어차피 다음에 또 바뀔 걸 알고 있으니까.

태그로 나중에도 쉽게 다시 찾기

모든 노트에는 이름표(태그)가 최소 두 개 붙는다. 첫 번째는 층 이름표(layer, raw·wiki·schema 중 하나 — 이 노트가 어느 층에 속하는지)다. 두 번째는 종류 이름표(type, index·source·concept 등 — 이 노트가 어떤 종류인지)다. 주제가 있으면 domain(분야)과 subject(세부 주제) 이름표를 더 붙인다. 이름표가 없던 시절엔 그래프 뷰(노트 사이 연결을 그림으로 보여주는 화면)로 일일이 뒤져야 했다. 이 네 종류의 이름표를 붙이고 나서는 필터 하나만 걸어도 원하는 층만 골라 볼 수 있다.

domain·subject 이름표는 특히 나중에 빛을 본다. 같은 wiki 층에 속해도 domain이 다르면 서로 무관한 페이지일 확률이 높다. 검색창에 키워드 하나만 치면 층과 주제가 뒤섞인 결과가 잔뜩 쏟아진다. 여기에 domain·subject 필터를 더하면 정말 필요한 페이지 몇 개로 줄어든다. 이름표 네 종류를 다 채우는 게 처음엔 번거로워 보였다. 노트 수가 몇 천 개를 넘긴 지금은, 이 이름표가 없었다면 검색이 거의 불가능했을 거라고 본다.

허브 노트로 자식 노트를 흩어지지 않게 묶는다

폴더마다 허브 노트를 하나씩 둔다. 허브 노트는 그 폴더의 목차라고 보면 된다. 이 폴더가 다루는 범위(Knowledge Scope)와 그 안의 하위 영역(Knowledge Areas)을 적고, 각 자식 노트를 한 줄 요약과 함께 링크한다. 큰 원자료는 절대 파일 하나에 다 밀어 넣지 않는다. 목차 노트 하나와 자식 노트 여럿으로 쪼개는 게 기본값이다.

새 노트를 만들 때마다 아래 다섯 가지를 체크한다.

• ☐ 새 노트에 layer 이름표(raw/wiki/schema 중 하나)를 붙였는가
• ☐ type 이름표(index/source/concept 등)를 붙였는가
• ☐ 주제가 있으면 domain·subject 이름표를 더했는가
• ☐ 폴더에 허브 노트(목차 노트)가 있고 자식 노트가 한 줄 요약과 함께 링크돼 있는가
• ☐ 큰 자료를 파일 하나에 몰아넣지 않고 목차 노트+자식 노트로 쪼갰는가

에이전트에게 맡기면 생기는 문제, 계약으로 잡은 법

에이전트에게 "알아서 정리해 둬"라고만 맡기면 태그도 프론트매터(노트 맨 위에 붙는, 이 노트의 정보를 요약한 카드 같은 부분)도 매번 형식이 달라졌다. 어떤 날은 태그가 세 개, 어떤 날은 하나도 없었다. 노트 제목을 짓는 규칙도 대화마다 조금씩 바뀌었다. 나중에 검색해 보면 비슷한 내용인데 제목 패턴이 달라 한 번에 걸리지 않는 경우가 있었다. 규칙집 없이는 일관성이 안 생긴다는 걸 그때 알게 됐다.

그래서 최소한의 약속을 schema 층에 박아 뒀다. 태그 택소노미(태그를 어떻게 나눌지 정한 분류표), 프론트매터의 최소 형태, 노트 양식까지. 코딩 에이전트는 이 약속을 AGENTS.md나 CLAUDE.md 같은 규칙 파일에서 읽는다. 그리고 raw 캡처부터 wiki 합성, 로그 기록까지 스스로 수행한다. 볼트 자체가 에이전트를 위한 운영 매뉴얼처럼 동작하는 셈이다.

wiki 문서가 너무 커지는 것도 따로 겪은 문제였다. 합성 페이지 하나가 길어지면 오히려 검색이 안 됐다. 원문 전체를 미러링하지 않고 링크백 위주로 짧게 쓴다는 압축 원칙을 계속 지켜야 한다는 걸 몸으로 체감했다. 지금도 wiki 문서가 길어졌다 싶으면 "쪼갤지, 링크백으로 줄일지"부터 판단한다.

관련 이야기는 LLM 활용 카테고리에도 몇 편 더 있다.

다음에 시도해볼 것

이 구조가 완성됐다는 뜻은 아니다. wiki/index.md 자체도 폴더 수가 늘면서 조금씩 길어지고 있다. 지금은 그 안에서 오래 안 열어 본 페이지를 솎아내는 기준을 못 정했다. 다음엔 log.md에 쌓인 append 기록을 거꾸로 훑어서, 한동안 갱신 안 된 wiki 페이지를 자동으로 표시해 주는 절차를 한번 만들어 보려 한다.

허브 노트 패턴도 아직 폴더마다 깊이가 다르다. 어떤 폴더는 허브 하나에 자식 노트 스무 개가 걸려 있고, 어떤 폴더는 아직 허브도 없다. 이번 정리가 끝나면 그 편차부터 손볼 생각이다.