AI가 내 노트를 읽고, 내 노트를 써요

01쌓이는 위키 vs 매번 찾는 RAG

저는 AI를 써서 리서치를 많이 해요. 논문 읽고, 레포 파고, 트렌드 정리하고. 그런데 문제가 있었어요 — 같은 주제를 두 번째 물으면 처음부터 다시 시작이에요. 지난번에 발견한 게 어딘가에 기록되지 않으면 없어지는 거죠.

RAG(Retrieval-Augmented Generation)가 그 문제를 부분적으로 해결해요. 원본 문서를 벡터로 저장해 두고, 질문이 들어오면 관련 조각을 찾아서 함께 넣어주는 방식이에요. 그런데 여기에 한계가 있어요 — 매번 원본을 다시 찾아요. 지난번 질문에서 발견한 연결고리, 패턴, 인사이트 — 이것들은 다음 질문으로 이어지지 않아요.

카파시는 이걸 이렇게 표현했어요.

"a persistent, compounding artifact where knowledge accumulates through incremental synthesis rather than re-derivation on every query"

매번 다시 유도가 아니라, 점점 쌓이는 합성이에요. 이 차이가 시간이 지날수록 커져요.

02카파시가 조용히 올린 gist 하나

2024년 말, 카파시가 GitHub gist에 짧은 문서를 올렸어요. 공식 발표도 없이, 블로그 포스트도 없이. 그런데 내용을 보면 그냥 메모가 아니에요 — LLM을 지식 관리 시스템의 핵심 작성자로 쓰는 방법에 대한 완결된 아키텍처예요.

핵심 아이디어는 이거예요. 노트 앱(Obsidian 등)을 LLM과 연결하되, LLM이 노트를 읽기만 하는 게 아니라 직접 쓰게 하는 거예요. 제약은 하나 — "Schema"라는 설계도를 사람이 만들고, 그 안에서 LLM이 자율적으로 위키를 운영해요. 통제권은 LLM에게, 규칙은 사람이 — 카파시 특유의 패턴이 여기서도 나와요.

033계층 — Sources · Wiki · Schema

구조는 단순해요. 세 개 계층이에요.

여기서 핵심을 한 번 더 짚으면 — Wiki는 LLM의 소유예요. 사람이 Wiki 페이지를 직접 편집하면 안 돼요. 사람의 역할은 Schema를 잘 정의하는 것, 그리고 Sources를 가져오는 것. LLM이 그걸 읽고 페이지를 써요. 역할 분리가 명확해요.

043가지 오퍼레이션 — Ingest · Query · Lint

이 시스템엔 세 가지 동작이 있어요.

세 오퍼레이션을 합치면 — ingest로 지식이 들어오고, query로 쓰면서 더 깊어지고, lint로 깨끗하게 유지돼요. 시스템이 스스로 건강해지는 루프예요.

05왜 100k 토큰 이하에서 더 잘 작동하나

카파시가 gist에서 언급한 포인트 중 가장 실용적인 거예요 — 위키가 100k 토큰(약 200페이지) 이하일 때는, RAG보다 이 방식이 우월해요.

이유가 있어요. RAG는 "관련 조각을 찾는다"는 전제 위에서 작동해요. 그런데 조각을 잘 찾으려면 임베딩 품질, 청킹 전략, 검색 임계값 같은 걸 계속 튜닝해야 해요. 그리고 여전히 빠지는 게 생겨요 — 조각끼리의 연결이 보이지 않거든요.

Wiki 방식은 달라요. 전체 위키를 컨텍스트에 넣으면 — 전체 코퍼스에 대한 글로벌 추론이 가능해요. "이 개념과 저 개념의 연결"을 찾는 데 RAG보다 훨씬 강해요. 벡터 인프라도 없고, 검색 임계값 튜닝도 없고, 100% 리트리벌 신뢰성이에요.

06실제로 구축해보니 — kairosai llm-wiki 7주 기록

이론을 읽고 직접 만들어 봤어요. kairosai 하네스 안에 llm-wiki/라는 이름으로요. 카파시 gist를 기반으로 하되, 운영하면서 확장한 구조예요. 아래 숫자는 실제 운영 로그에서 나온 수치예요.

처음엔 평범하게 시작했어요. Sources 5개를 투입하니 wiki 페이지 13개가 자동으로 만들어졌어요. 그때까지는 "빠른 메모장" 정도였죠. 진짜 변화는 7주 뒤 자동화 파이프라인이 붙고 나서였어요 — 4,832개 프롬프트를 분석해서 8개 도메인을 스스로 발견했어요. 내가 어떤 주제로 일하는지를 시스템이 직접 분류한 거예요.

그 이후로 모든 대화가 달라졌어요. 매 프롬프트가 시작될 때 llm_wiki_route.py가 0.10초 안에 도메인을 감지하고, 관련 atom을 자동으로 컨텍스트에 주입해요. 질문하지 않아도 관련 지식이 먼저 들어와 있어요.

07함정 — 언제 무너지나

좋은 것만 얘기하면 안 되죠. 직접 써보면서 발견한 함정이 있어요.

08kairosai llm-wiki 구조를 보면

카파시 원안의 3계층(Sources·Wiki·Schema)에 하나를 더 얹었어요 — Ontology(온톨로지)예요. 재사용 가능한 방법론 원자들을 별도로 모아두는 레이어예요. Wiki 페이지가 "이번 주제에 대한 합성"이라면, Ontology는 "어떤 주제에든 꺼내 쓸 수 있는 패턴"이에요.

가장 좋았던 건 llm_wiki_route.py예요. 대화가 시작될 때마다 UserSubmit 훅이 프롬프트를 읽고 도메인을 분류해요 — 0.10초 안에. 관련 atom이 있으면 컨텍스트에 자동으로 밀어 넣어요. "이 파일 읽어줘"라고 하지 않아도 관련 지식이 이미 들어와 있어요.

이게 바로 카파시가 말한 "점점 쌓이는 합성"의 실체예요. Sources를 ingest할수록 Wiki가 깊어지고, Wiki가 깊어질수록 라우터가 더 정확한 atom을 주입하고, 그 다음 대화의 품질이 올라가요. 루프가 닫히는 순간이에요.

---

카파시의 gist는 짧아요. 그런데 읽다 보면 그가 소프트웨어를 다루는 방식의 핵심이 여기서도 똑같이 등장해요 — 통제권은 위로, 제약은 좁게. LLM에 위키 작성을 맡기되, Schema라는 좁은 규칙 안에서. 지식 관리에서도 같은 패턴이에요.

직접 만들어서 운영하면서 배운 건 — Schema 먼저, 그 다음 Sources. 라우터가 붙고 나서야 "아, 이게 쌓이는 거구나"가 체감됐어요. 그 전까지는 그냥 조금 빠른 메모장이었어요.

매번 찾는 것과 쌓이는 것의 차이 — 7주가 지나고 나서야 보였어요.