AI가 읽는 개인 위키 만들기 — 3개월 운영 기록

세컨드 브레인은 왜 쌓이기만 하고 안 쓰일까?

정리 도구의 문제가 아니라 독자가 바뀌었는데 구조가 그대로여서다.

노트 앱을 바꾸고 태그 체계를 다시 짜도 활용률은 잘 오르지 않는다. 대부분의 노트는 “나중에 내가 다시 읽는다”를 전제로 쓰여 있다. 문제는 그 “다시 읽는” 일 자체가 생각보다 큰 노동이었다. 나는 노트를 점검하고 다시 배치하고 구조를 손보는 데 매번 적지 않은 시간을 썼다.

그 유지 노동을 LLM에 넘기자 시간이 크게 줄었다. 대신 저장소를 실제로 열어 읽고 판단하는 쪽이 나에서 모델로 바뀌었다. 사람은 맥락을 기억한 채 노트를 펼치지만 모델은 매번 아무것도 모르는 상태로 들어온다. 사람에게 충분했던 메모가 모델에게는 근거 없는 문장 더미로 보이는 이유다.

그래서 2026년 5월 8일부터 전제를 뒤집은 개인 위키를 운영한다. 주 독자를 LLM으로 놓고 사람이 읽기 좋은 서술 대신 모델이 판단하기 좋은 구조를 우선했다. Andrej Karpathy가 2026년 4월 공개한 LLM-Wiki 패턴이 출발점이었고 3개월 동안 규칙을 다섯 번 고쳐 쓰며 지금 형태에 도달했다.

LLM용 위키는 사람용 노트와 무엇이 다른가?

모든 페이지가 “이 페이지를 지금 읽어야 하는가”에 10초 안에 답하도록 설계된다.

이 위키의 페이지는 본문보다 먼저 오는 네 문장짜리 서문으로 시작한다. 이 페이지가 무엇인지, 왜 이 저장소에 존재하는지, 읽는 쪽이 반드시 가져가야 할 사실 하나를 적는다. 규칙은 하나 더 있다. 첫 문장이 가장 큰 비중을 지고 그 문장만 읽고 멈춰도 관련성이 전달되어야 한다. 모델은 실제로 첫 문장에서 읽기를 멈춘다.

사람이 쓰는 노트의 구조는 그 노트를 남기던 순간에 낼 수 있던 시간에 좌우된다. 급할 때 적은 메모는 규칙도 맥락도 없이 남고 여유가 있던 날의 노트만 제대로 정리된다. 저장소 전체로 보면 품질이 들쭉날쭉할 수밖에 없다. LLM용 위키는 이 편차를 규칙으로 없앤다. 네 문장 서문과 첫 문장 우선은 그날 시간이 없어도 지켜야 하는 최소 형식이다.

이 형식은 관련이 없는 페이지를 빨리 버리게 만드는 쪽으로 작동한다. 검색으로 후보 페이지 열 개가 걸렸을 때 아홉 개를 빠르게 탈락시키는 쪽이 열 개를 모두 정독시키는 쪽보다 답의 품질을 높인다.

원본은 왜 절대 수정하면 안 되나?

해석과 원본이 섞이는 순간 무엇이 근거였는지 되짚을 수 없다.

저장소는 두 층으로 나뉜다. 아래층은 클리핑한 원본이다. 기사, 논문, 영상 자막이 손대지 않은 상태로 들어간다. 위층은 그 원본에서 뽑아낸 개념과 엔티티 페이지다. 아래층은 불변이다. 한 번 들어온 뒤에는 오타 하나도 고치지 않는다.

강제 수단은 해시다. 원본 파일마다 본문의 sha256을 프론트매터에 박아 두고 점검 스크립트가 값이 어긋나면 실패를 낸다. 원본이 바뀌었으면 고칠 게 아니라 새로 받아와 다시 해석한다. 덕분에 위층의 어떤 주장이든 어느 원본의 어느 지점에서 나왔는지 항상 되짚는다.

모델에게 요약을 시키면 원본에 없던 문장이 섞여 들어오는 일이 생긴다. 원본을 불변으로 묶어 두면 그 혼입이 어느 단계에서 일어났는지 짚어낼 수 있다.

솔직히 이 원칙이 도입 과정에서 가장 헷갈렸다. 무언가 눈에 걸리면 바로 고쳐 두던 기존 노트 습관과 정면으로 어긋나기 때문이다. 원본을 손대는 바람에 git 동기화가 깨진 적도 몇 번 있다. 원본은 고치는 게 아니라 다시 받아 오는 것이라는 감각이 붙고 나서야 그 실수가 사라졌다.

모든 노트를 위키 페이지로 만들어야 하나?

아니다. 서로 다른 원본 두 건 이상에 등장하거나, 한 원본이 통째로 그것을 다룰 때만 승격한다.

문턱이 없으면 저장소는 한 번 쓰이고 마는 페이지로 뒤덮인다. 한 번 언급된 개념은 원본 층에 그대로 두고 두 번째 원본에서 다시 만났을 때 페이지를 만든다. 두 번 나왔다는 사실 자체가 그 개념이 내 관심사에서 실제로 반복된다는 증거다.

크기 제한도 같은 목적이다. 페이지는 200줄을 넘지 않는 것을 목표로 하고 300줄을 넘으면 분할한다. 페이지마다 다른 페이지로 향하는 링크를 두 개 이상 요구하는 규칙도 있다. 어디에도 연결되지 않은 페이지는 검색에 걸려도 맥락을 주지 못한다.

3개월 뒤 숫자는 이렇다. 원본 93건(기사 30, 자막 63)에서 승격된 위층 페이지가 97개. 개념 76개, 엔티티 20개, 질의 기록 1개. 승격 비율이 1대 1 근처라는 건 문턱이 느슨하다는 신호이기도 해서 다음 개정에서 손볼 지점으로 본다.

AI가 언제 내 노트를 읽어야 하는지는 어떻게 정하나?

읽을지 말지를 모델의 판단에 맡기지 않고 트리거 단어로 규칙화한다.

매번 저장소를 읽으면 느리고 비싸다. 한 번도 안 읽으면 개인 위키를 둔 의미가 없다. 그래서 네 단계로 나눴다.

1단계는 강제 조회다. 질문에 우리, 지난번, 결정, 전략 같은 단어나 저장소에 등록된 고유명사가 들어오면 무조건 읽는다. 개인 저장소에만 답이 있는 질문은 대부분 이 단어들을 달고 온다. 읽은 페이지는 답변에 인용해 근거를 드러낸다.

2단계는 가벼운 훑기, 3단계는 읽지 않을 영역의 명시다. 일반적인 코딩 문제, 바깥 뉴스, 단순 번역은 트리거에 걸려도 저장소를 열지 않는다. “우리는 React 쓸까?“는 우리에 걸리지만 개인 위키에 답이 없다. 3단계는 1단계의 오탐을 걷어내려고 존재한다. 4단계는 사용자가 직접 켜고 끄는 스위치다.

규칙을 이렇게 적어 두면 모델이 매번 다르게 판단하는 문제가 사라진다. 조회가 빗나가면 프롬프트가 아니라 규칙을 고친다. 이쪽이 더 중요하다.

사실이 바뀌면 이전 내용은 어떻게 하나?

지우지 않는다. 본문은 현재의 사실로 다시 쓴다. 이전 주장은 페이지 하단 이력 절로 내리고 변경 사실을 별도 로그에 한 줄 남긴다.

날짜가 새 쪽이 대체로 이긴다. 어느 쪽이 맞는지 판단이 서지 않으면 두 주장을 나란히 두고 다툼 표시를 단다. 조용히 덮어쓰는 것만 금지된다.

모델이 과거의 틀린 답을 반복하지 않게 하려고 만든 규칙인데 정작 쓸모는 다른 데서 나왔다. 내가 왜 그렇게 판단했는지 되짚을 때다. 결론만 남은 저장소는 시간이 지나면 믿기 어려워진다. 바뀐 흔적이 남아 있어야 지금의 결론을 신뢰할 근거가 생긴다.

3개월 굴려 보니 무엇이 남았나

효과가 분명했던 것은 네 문장 서문과 원본 불변 두 가지다. 서문은 조회 품질을 즉시 끌어올렸고 원본 불변은 답이 이상할 때 어디서 틀어졌는지 추적하게 해 줬다. 둘 다 도구가 아니라 규칙이라서 노트 앱을 바꿔도 그대로 따라온다.

반면 태그 체계는 계속 손이 갔다. 상위 분류 여덟 개를 고정하고 하위만 늘리는 방식으로 정리했지만 태그는 여전히 가장 자주 어긋나는 부분이다.

그래서 LLM-wiki가 제텔카스텐·PARA를 대체하나?

아니다. 지금은 오히려 PARA를 더 많이 쓴다.

내 세컨드 브레인은 LLM-wiki와 PARA를 결합한 Obsidian 저장소로 굴러간다. 예전에 PARA에 얹어 쓰던 제텔카스텐은 지금 LLM-wiki가 완전히 대체했다.

일상에서 손이 더 자주 가는 쪽은 PARA다. CTO 업무는 진행 중인 프로젝트와 연구의 상태를 관리하는 일이 대부분이라 그렇다. 동료가 쓴 콘텐츠나 리서치를 리뷰할 때도 PARA를 더 쓴다. LLM-wiki가 진짜 힘을 내는 곳은 따로 있다. 흩어진 원본에서 개념을 뽑아 반복해서 다시 꺼내 쓰는 리서치와 콘텐츠 생산이다.

그러니 LLM-wiki를 모든 노트의 대체재로 볼 필요는 없다. 상태를 관리하는 일에는 PARA가, 근거를 쌓아 다시 쓰는 일에는 LLM-wiki가 맞는다. 세컨드 브레인을 다시 짠다면 순서는 이렇게 잡겠다. 폴더 구조나 앱 선택은 뒤로 미루고 누가 이 노트를 읽을 것인가를 먼저 정한다. 그다음 그 독자가 판단하는 데 필요한 최소한의 형식을 규칙으로 적는다. 나머지는 거기서 따라 나온다.

이 저장소를 새벽마다 읽고 쓰는 쪽은 이제 사람이 아니다. 그 무인 자동화를 어떻게 짰는지는 개인 AI 자동화 기록에, 같은 전제를 AI 크롤러에게 적용해 이 사이트를 다시 지은 기록은 GEO 네이티브 사이트 구축기에 따로 적었다.