옵시디언을 깔기 전에,
검색 문장 세 개를 먼저 써라
카파시의 gist를 읽었고, 유튜브에서 옵시디언 vault에 에이전트를 물리는 영상을 봤고, 그래프뷰가 별자리처럼 펼쳐지는 화면에 감탄했을 것이다. 그리고 지금 옵시디언을 설치하고 있을 것이다. 멈춰라.
질문 하나에 답해보라 — 그 위키에 무엇을 검색할 것인가? 답이 없다면 당신이 만드는 것은 위키가 아니라 요약 무덤이다. 그래프뷰는 예쁘게 나올 것이다. 3주 뒤에 안 열어볼 것도 확실하다.
"쌓다 보면 구조가 창발한다"고 반박하고 싶은가? 제텔카스텐이 그랬듯이? 맞다 — 단, 창발은 링크를 걸 때마다 "이건 저것과 왜 연결되지?"라는 암묵적 질문을 던진 사람에게만 일어난다. 나는 그 질문을 명시화하라는 것뿐이다. 질문 없이 폴더에 파일만 쌓는 것은 창발이 아니라 적재다.
01카파시가 말한 것 vs 당신이 쫓는 것
카파시가 말한 것은 패턴이다. LLM은 지루해하지 않고, 크로스레퍼런스 갱신을 잊지 않고, 한 번에 15개 파일을 고칠 수 있다 — 그러니 인간이 포기하던 위키 유지보수를 에이전트에게 맡기자는 것.
당신이 쫓는 것은 도구다. 옵시디언, 그래프뷰, graphify. 도구는 패턴의 물질화 중 하나일 뿐이다.
02본질 세 문장
"어떤 질문을 던질 것인가"를 먼저 정의하고, 그 질문에 답이 나오도록 지식을 압축·구조화·연결하는 것. 질문이 없으면 오버엔지니어링이다.
표현층(어떤 형태로 압축) × 연결층(요약→원문을 어떻게 잇나) × 접근층(에이전트가 어떻게 읽나). 옵시디언 방식은 이 조합의 하나다: 요약 md × 심링크·정션 × 파일읽기. 그래프뷰는 부산물이다.
위키에는 요약만 저장한다. 검색된 요약에서 심링크·경로·URL로 원문까지 에이전트가 도달해야 완성이다. 예쁜 그래프에는 이 층이 자주 빠져 있다.
03같은 검색 계약, 여섯 가지 물질화
같은 검색 계약을 여섯 가지 방식으로 구현할 수 있다. RAG vs Wiki vs DB 논쟁은 가짜 논쟁이다. 대립이 아니라 같은 온톨로지의 다른 물질화다. 질문 형태가 조합을 정한다.
| 방식 | 조합 (표현×연결×접근) | 잘 답하는 질문 |
|---|---|---|
| Wiki MD | 요약 md × 심링크·정션 × 파일읽기 | 관계 탐색, 그래프뷰 |
| SQLite | 레코드 × 외래키 × SQL | 정확한 조인·필터·집계 |
| MCP 서버 | SQLite × MCP 툴콜 | 어떤 세션에서든 /wiki |
| RAG | 벡터 청크 × 메타데이터 × 유사도 | "비슷한 거 어디 있었지" |
| RSS/정적사이트 | 피드 × URL × HTTP | 구독, 외부 공유 |
| OKF 번들 | 요약 md × resource × 표준규약 | 타 조직·타 도구 호환 |
04구글도 같은 결론에 도달했다 — OKF
작년부터 다들 비슷한 걸 각자 따로 만들고 있었다. 누구는 옵시디언 vault에 md 파일을 쌓고, 누구는 레포에 AGENTS.md와 CLAUDE.md를 써놓고, 누구는 폴더에 index.md를 만들었다. 이름만 다르지 하는 짓은 똑같다 — 에이전트가 읽을 지식을 마크다운 파일로 정리해두기.
2026년 6월, 구글 클라우드가 "너희 다 같은 걸 하고 있다. 규칙을 통일하자"고 했다. 그것이 Open Knowledge Format(OKF) v0.1이고, 스펙의 전부는 어이없을 만큼 단순하다.
폴더에 마크다운 파일을 넣어라. 파일 맨 위에 type: 강의안 같은 딱지 한 줄을 붙여라. 파일끼리는 그냥 마크다운 링크로 연결해라. 끝이다.
콘센트 규격이라고 생각하면 된다. 220V 규격이 정해지니 어느 회사 드라이기든 어느 집에나 꽂힌다. OKF 규격대로 위키를 만들면 내 위키를 남의 에이전트가 읽고, 구글 클라우드가 읽고, 아직 나오지 않은 미래의 도구도 읽는다.
여기서 주목할 것: 구글이 표준화한 것은 파일 형식과 연결 방식이지 옵시디언이 아니다. 스펙 어디에도 옵시디언이라는 단어는 없다 — 콘센트 규격에 드라이기 상표가 안 들어가는 것과 같다. "LLM wiki = 옵시디언 + 그래프뷰"라고 믿는 것은 콘센트 규격을 배우라니까 드라이기 브랜드를 외우는 격이다.
05LLM 위키가 기존 KMS와 다른 것 두 가지
첫째, 조인을 사람이 짜지 않는다. RDBMS와 구조는 같지만, 복잡한 조인과 키 스키마를 LLM이 의미 기반으로 대신 걸어준다. 그래서 스키마가 느슨해도 검색이 된다. 단, LLM의 조인은 확률적이다 — "2025년 공공기관 강의 전부"처럼 빠짐없음이 중요한 질문에는 여전히 진짜 DB가 필요하다. 그래서 SQLite 레시피가 있다.
둘째, 유지보수를 사람이 하지 않는다. 인간의 위키가 죽는 이유는 검색이 아니라 갱신이다 — 크로스레퍼런스 하나 고치는 게 귀찮아서 방치되고, 방치된 위키는 신뢰를 잃고, 신뢰 잃은 위키는 안 열어본다. 카파시 논지의 진짜 핵심이 여기다. LLM은 지루해하지 않고, 갱신을 잊지 않고, 한 번에 15개 파일을 고친다. 검색 계약이 위키의 탄생 조건이라면, 에이전트 유지보수는 생존 조건이다.
단, 두 경우 모두 무엇을 축으로 삼을지는 사람이 정한다 — 그것이 온톨로지 설계이고, 도구가 대신 못 해주는 유일한 일이다.
정리하며트렌드는 도구를 판다. 본질은 질문을 판다.
기존의 프롬프트, 플러그인, 스킬, 에이전트, 워크플로우, 자동화 스크립트를 전부 "위키"라고 부르기 시작하면, 정작 위키가 필요한 이유 자체가 사라진다. 옵시디언을 깔기 전에, 검색 문장 세 개를 먼저 써라.
온톨로지에도 정답은 없다. 개념-개체-관계 트리플? 그것도 패턴 중 하나일 뿐이다. 자료와 질문에 따라 계층·패싯·이벤트·최소 구조가 더 맞을 수 있다. 단 두 가지만은 패턴과 무관하게 불변이다: 검색 계약이 먼저, 그리고 source_path 필수.
이 글에서 다룬 6가지 레시피, 5가지 온톨로지 패턴, 시작 템플릿은 오픈소스로 공개되어 있습니다. 클론해서
claude를 실행하면 에이전트가 검색 문장 세 개부터 물을 것입니다.github.com/cdsassj00/llm-wiki-anatomy · MIT License