[초안] LLM이 유지보수할 수 있는 두 번째 뇌

#이 글이 다루는 것

LLM과 함께 운영하는 개인 지식 베이스(PKM)의 구조 설계. 자율 위키가 아니라 review-gate 위키. 무엇을 어떻게 나눴고, 왜 그렇게 나눴는지를 매뉴얼 형태로 정리한다.

이 글은 "잘 정리하는 법"보다 LLM과 사람이 같이 유지보수할 수 있는 시스템을 어떻게 설계했는지를 정리한 기록이다.

#출발점: 두 가지 문제

PKM 시스템에 LLM을 본격적으로 끼워 넣으니 두 가지 문제가 분명해졌다.

1) 분기는 자연스럽지만 병합은 안 된다

LLM과 일하면 대화가 빠르게 갈라진다. 질문 하나가 답을 부르고, 그 답이 또 다른 질문을 만들고, 어느 순간 한 주제로 서로 다른 세션 다섯 개가 떠 있다. 분기 자체는 효율적이다. 문제는 그 결과가 거의 모이지 않는다는 점이다. 며칠 뒤 같은 문제로 돌아오면 "내가 어디까지 확인했더라?"부터 다시 시작한다.

2) 폴더 의미가 흐릿하면 LLM이 매번 다른 답을 낸다

이전 구조는 PARA와 Zettelkasten이 섞여 있었다. Project? Resource? Note? Area? 폴더 이름의 의미가 겹쳤고, 그 결과 LLM에게 "이 노트 어디에 둘까?"를 물어볼 때마다 답이 달라졌다. 한 번은 Resource, 한 번은 Note, 한 번은 Project. 일관된 자동화가 불가능했다.

이 두 가지를 같이 풀어야 했다. 분기된 결과를 한곳으로 수렴시키는 동시에, 그 한곳의 구조가 LLM에게도 명확해야 한다. 그래서 폴더 구조 자체를 LLM이 읽을 수 있는 매뉴얼처럼 다시 짰다.

#3개 층 + 1개 보조

1Raw-Sources/  → 불변 원본 (수집한 자료, 아카이브)
2Wiki/         → 구조화된 지식 (journal, life, maps 포함)
3Schema/       → 규칙·스킬·설정 (LLM 매뉴얼)
4Entities/     → people / institutions / companies / tools / places
5Blog/         → 출판물 (output 분리)

1Raw-Sources/  → 불변 원본 (수집한 자료, 아카이브)
2Wiki/         → 구조화된 지식 (journal, life, maps 포함)
3Schema/       → 규칙·스킬·설정 (LLM 매뉴얼)
4Entities/     → people / institutions / companies / tools / places
5Blog/         → 출판물 (output 분리)

여기서 핵심은 각 층마다 수정 권한과 수정 방식이 다르다는 점이다. 같은 "노트"라도 어느 층에 속하느냐에 따라 LLM이 손댈 수 있는 정도가 달라진다.

이 분리가 가능해지자 LLM에게 줄 수 있는 자율성의 단위가 폴더가 됐다. "이 폴더 안에서는 마음대로", "저 폴더는 diff만 제안"이라고 정확히 말할 수 있게 된다.

#왜 출판물(Blog/)을 별도로 뺐나

Wiki 안에 두지 않고 Blog/를 따로 둔 이유는 두 가지다.

• 출판은 다른 lifecycle을 가진다: Wiki 노트는 끊임없이 갱신되는 살아있는 글이지만, 출판물은 한 번 공개되면 수정 빈도가 줄어든다. 두 흐름이 섞이면 어느 쪽도 잘 운영되지 않는다.
• 공개/비공개 경계가 명확해진다: "이건 공개해도 되는 글인가?"를 물어볼 필요 없이 폴더 자체가 답이다.

#결정적 적응: review-gate

원본 LLM 위키 패턴은 "LLM이 위키를 완전히 소유한다"에 가깝다. 새 자료가 들어오면 LLM이 알아서 기존 페이지를 갱신하고, 모순을 정리하고, 인덱스를 다시 짠다. 매력적이다. 하지만 그 모델은 한 가지를 가정한다. 잘못된 정보가 들어가도 비용이 작다는 가정.

내 볼트에는 그 가정이 성립하지 않는 영역이 있었다. 환각 한 번이 실제 비용으로 돌아오는 도메인. 사실 관계가 자주 갱신되고, 잘못된 숫자나 용어 하나가 의사결정에 직접 영향을 주는 영역. 이런 곳에서 자율 편집은 위험했다.

그래서 자율과 안전을 trade-off가 아니라 도메인별 정책의 문제로 다시 정의했다.

세 가지 원칙이 깔려 있다.

1. 도메인 위험도 = 정책의 입력값: 모든 페이지를 똑같이 다루지 않는다. 위험이 큰 곳은 보수적으로, 작은 곳은 자유롭게.
2. 사람 관련은 append-only: 과거 대화 기록을 LLM이 수정하면 기억이 왜곡된다. 새 만남은 새로운 섹션을 추가할 뿐, 이전 섹션은 건드리지 않는다.
3. review-gate는 검열이 아니라 협업 인터페이스: LLM이 작업을 멈추는 게 아니라, 작업의 결과를 diff로 제시하고 사람이 한 번 본다. 시간 비용은 작고, 안전 이득은 크다.

#Schema/는 LLM의 운영 매뉴얼이다

Schema/ 안에는 두 종류가 들어간다.

• rules: 상시 로드되는 헌법. 출력 톤, 검증 프로토콜, 도메인별 주의사항, 작성 스타일, 금지 사항. 매 세션 첫 응답부터 LLM이 따라야 할 규칙들.
• skills: 워크플로우. /daily, /research-doc, /write, /polish 같은 슬래시 명령. 각 스킬은 입력 → 단계 → 출력을 정의한 작은 매뉴얼이다.

이 두 가지가 합쳐지면 LLM이 "이 볼트에서 일하는 법"을 갖게 된다. 새로운 세션이 시작돼도 AGENTS.md가 진입점 역할을 하면서 첫 응답부터 컨텍스트를 들고 시작한다. 컨텍스트가 코드처럼 버전 관리된다는 게 핵심이다.

이 구조가 주는 보너스는 자기 수정 능력이다. LLM이 같은 실수를 두 번 하면, 그 실수를 막는 규칙을 Schema/rules/ 안에 추가한다. 그러면 다음 세션부터 그 실수가 줄어든다. 매뉴얼이 살아있다.

#한 장짜리 흐름

flowchart LR
  A["Raw-Sources/"] -->|"/research-doc, /summarize"| B["Wiki/"]
  B -->|review-gate| C["Entities/"]
  B -->|"/daily, /retro, /session-log"| D["Wiki/journal/"]
  B -->|"/write, /polish"| E["Blog/"]
  F["Schema/"] -.->|every session| A
  F -.-> B
  F -.-> C

읽는 법은 단순하다.

• 수평 흐름: Raw-Sources에서 시작한 자료가 Wiki로 들어가서 구조화되고, 거기서 Entities로 빠지거나, 운영 로그(journal)로 정리되거나, Blog로 출판된다.
• 수직 흐름: Schema는 모든 작업에 점선으로 연결된다. 매 세션마다 LLM이 읽고 따른다. 직접 변형하지는 않는다.

이 그림이 작동하려면 한 가지 조건이 필요하다. 각 화살표가 슬래시 명령으로 자동화되어야 한다. 수동으로 옮기는 단계가 끼면 며칠 안에 무너진다. 그래서 /research-doc, /summarize, /daily, /retro, /session-log, /write, /polish 같은 스킬이 화살표마다 붙는다.

#의도적으로 안 한 것

작게 시작하기 위해 일부러 뺀 것이 있다. 나중에 필요하면 추가하면 된다.

• TLDR 백필: 모든 노트에 TLDR을 다는 작업. 구조가 안정되기 전엔 형식보다 흐름이 먼저다. 아직 폴더가 움직이고 있는데 메타데이터를 일괄 추가하면 두 번 일하게 된다.
• 자동 양방향 링크 일괄 추가: 80개가 넘는 파일을 건드릴 가치가 없다고 판단했다. Obsidian Backlinks 패널이면 충분하다. 새로 작성되는 노트만 양방향 링크를 보장하면 된다.
• 모든 도메인 자동화: 저위험만 자율, 나머지는 review-gate 유지. 자동화율을 무리하게 끌어올리면 오류 비용이 폭발한다.
• 고도화된 시각화: Graph view, Canvas, 카드 UI 같은 것들. 보기엔 좋지만 구조 설계 단계에서는 산만하다. 콘텐츠와 흐름이 먼저다.

이 넷은 모두 "할 수 있지만 지금은 안 한다"의 영역이다. 안 하기로 결정한 것이 한 일만큼 시스템을 정의한다.

#운영하면서 생긴 작은 규칙들

설계 직후엔 안 보였지만, 몇 주 운영해보니 자연스럽게 굳어진 것이 있다.

• 새 노트는 default로 Wiki에 들어간다: Raw-Sources는 외부 자료만, Schema는 사람만. 모호하면 Wiki다.
• journal은 절대 Blog로 직접 옮기지 않는다: 일상 기록과 출판 글의 lifecycle이 달라서, 옮기는 순간 양쪽이 꼬인다. 출판할 글은 처음부터 Blog/에서 시작한다.
• Entities 페이지는 제목이 ID다: 같은 사람이 여러 이름으로 등장하면 alias로 처리한다. ID가 흐려지면 LLM이 헷갈린다.
• Schema/rules/는 새로 추가할 때만 의미가 있다: 수정이 잦아지면 이미 그 규칙은 신뢰할 수 없다는 뜻이다.
• 세션이 끝나면 /session-log로 결과를 journal에 병합한다: 분기된 LLM 대화가 흩어지지 않게 하루 단위로 한곳에 모으는 마지막 단계. 이 한 줄이 빠지면 "분기는 자연스럽지만 병합은 안 된다"가 다시 살아난다.

#정리

LLM 시대의 PKM은 "내가 잘 정리하는 시스템"이 아니라 LLM과 사람이 같이 유지보수할 수 있는 시스템이다. 그러려면 두 가지가 필요했다.

1. 폴더 구조의 의미가 명확할 것 – 각 층의 책임이 다르고, 그 차이가 LLM에게도 보여야 한다.
2. LLM에게 자율을 줄 영역과 차단할 영역을 도메인별로 분리할 것 – 위험도가 다른 콘텐츠에 같은 정책을 적용하는 순간 시스템 전체의 신뢰가 떨어진다.

이 두 가지가 갖춰지면 자동화는 따라온다. 화려한 도구가 필요한 게 아니라, 물어보면 일관된 답이 나오는 구조가 필요하다. 결국 PKM의 본질은 같은 일을 두 번 생각하지 않는 데 있고, LLM과 함께라면 그 가능성이 처음으로 손에 잡힌다.

#관련 글

• 대화는 분기해도 지식은 병합되어야 한다 - 이 글의 사상적 출발점
• [초안] 내가 글 쓰기 환경을 구축한 방법 - 출판 파이프라인 (Blog/ 분리의 또 다른 이유)
• Karpathy, "LLM Wiki" gist - "원본 LLM 위키 패턴"의 출처