여러분도 뭔가를 읽고 나서, "어? 이거 나중에 써먹어야지"라고 생각한 적이 있을 겁니다. 아티클, 뉴스레터, 팟캐스트, 어딘가에 적어둔 메모 등 말이죠. 그런데 나중이 되면 어디 있는지 모르거나, 찾아도 맥락이 기억나지 않습니다. 그래서 이걸 해결하고자 개인 위키를 만드는 사람들이 있습니다. 개인 위키는 말 그대로 개인 지식의 디지털 저장소로, 내가 읽고 배운 것들을 한 곳에 쌓아두는 문서 공간입니다. 노션이나 옵시디언 같은 툴에 주제별 페이지를 만들고, 내 지식들을 한 곳에 정리해 두는 방식이죠.

저도 몇 번이나 개인 위키 제작을 시도해 봤는데요. 처음엔 꽤 공들여 세팅해서 그럴듯했습니다. 페이지 만들고, 태그를 붙이고, 데이터베이스도 구성했죠. 그런데 한두 달쯤 지났을까, 같은 자리에서 막히기 시작했습니다. 새 정보를 넣으려고 열면 이 내용이 어떤 태그에 붙어있는지부터 기억해 내야 했고, 정보 업데이트를 위해선 이전에 적어둔 것들과 어떤 부분이 겹치는지 확인해야 했습니다.

또 새로 추가할 때마다 기존 내용을 업데이트하고, 교차 참조도 달아야 했죠. 이 과정이 30분을 넘어가기 시작하면, 그냥 어느 순간부터 안 쓰게 되고 그렇게 제 위키는 조용히 멈춰졌습니다. 언제부턴가 열지도 않게 됐죠. 결국 작심삼일처럼 스스로의 의지가 부족한 거라고 생각했습니다. 그런데 안드레 카파시(Andrej Karpathy, OpenAI 창립 멤버)가 최근 공개한 LLM 위키 아이디어 문서를 읽으면서, 다른 생각이 들었습니다. 걸림돌은 게으름이 아니라, 정리를 계속 유지하는 데 들어가는 비용이 너무 컸던 겁니다.

부담이 쌓이면 위키는 멈춘다

안드레 카파시는 최근 "코드보다 개인 지식 저장소 구축에 더 많은 AI 토큰을 쓰고 있다"고 말하며, 자신이 실험 중인 LLM-Wiki를 공개했습니다.

그는 사람들이 위키를 포기하는 건 지식이 부족해서가 아니라, 유지 관리 비용이 가치보다 빠르게 증가하기 때문이라고 말했는데요. 보통 교차 참조 업데이트, 요약 최신화, 수십 페이지에 걸친 일관성 유지를 ‘북키핑(bookkeeping)’이라고 부릅니다. 우리가 읽고 생각하고 연결하는 것까진 즐거워하는데, 이미 적어둔 내용과 새 내용이 어디서 겹치는지 찾고, 기존 페이지를 하나하나 업데이트하는 건 다른 종류의 일이기 때문이죠. 그 지루한 일이 쌓이면, 결국 위키 관리를 포기하게 되고요.

그러나 인간과 달리 LLM은 지루함을 모릅니다. 교차 참조 업데이트를 잊지 않고, 새 소스 하나를 넣으면 관련된 15개 페이지를 한 번에 처리할 수 있습니다. 북키핑 비용이 거의 0에 가까워진다면, 위키를 유지할 수 있는 조건이 됩니다.

그런데 이 아이디어는 우리가 AI를 활용하는 일반적인 방식과 꽤 다릅니다. 보통 ChatGPT에 파일을 올리거나, NotebookLM을 쓸 때는 RAG(Retrieval-Augmented Generation) 방식을 사용합니다. 이건 질문할 때마다 원문에서 관련 내용을 다시 찾아 답하는 방식인데요. 예를 들어, 도서관 사서에 비유하면, 매번 서가에서 책을 꺼내 읽어주는 것과 비슷합니다. 찾아주긴 하지만 지식이 어딘가에 정리되어 쌓이지는 않습니다.

LLM-Wiki는 다릅니다. 내가 읽은 것들을 직접 요약·정리해 주는 비서에 가깝습니다. LLM이 원문을 읽고 마크다운 위키를 직접 쓰고, 새 소스가 들어올 때마다 기존 위키를 업데이트하면서 지식이 쌓입니다. 카파시의 표현을 빌려 표현하자면 "복리 축적형 결과물"인 셈이죠.

내가 소스를 넣으면 LLM이 위키를 쌓는다

구조는 다음과 같은 세 레이어로 이루어집니다.

첫 번째는 원문 소스입니다. 내가 모은 아티클, 논문, 이미지, 데이터 파일이죠. LLM이 읽기만 하고 수정하지 않는 레이어로, 진실의 원천이 됩니다.
두 번째는 위키입니다. LLM이 직접 생성하고 관리하는 마크다운 파일 모음입니다. 요약, 개념 정리, 비교/분석이 여기 쌓이고, 옵시디언 같은 도구로 열어두면 LLM이 편집하는 내용을 실시간으로 볼 수 있습니다. 카파시는 옵시디언은 IDE, LLM은 프로그래머, 위키는 코드베이스라고 비유했습니다.
세 번째는 스키마(schema)입니다. LLM에게 위키의 구조와 컨벤션, 워크플로를 알려주는 설정 문서인데, 이 파일이 있어야 LLM이 일반 챗봇이 아닌 체계적인 위키 관리자로 동작합니다. 처음엔 짧아도 되고, 사용자와 LLM이 쓰면서 함께 다듬어가는 문서이기도 합니다.

그리고 실제 작업은 인제스트(Ingest), 쿼리(Query), 린트(Lint) 세 가지로 나뉩니다. 먼저 소스를 새로 추가할 때 LLM이 읽고 위키를 업데이트하는 인제스트, 위키를 대상으로 질문하면 관련 페이지를 찾아 답을 만들어주는 쿼리, 주기적으로 페이지 간 모순이나 고립된 페이지를 점검하는 게 린트입니다. 쿼리에서 잘 만들어진 답변은 위키에 새 페이지로 저장되기도 합니다. 탐색 자체가 쌓이는 거죠.

제가 이 구조에서 가장 마음에 든 건 데이터 소유권입니다. "쓸수록 알아서 좋아진다"는 AI 개인화 방식의 경우, 내 데이터가 어디에 어떻게 저장되는지 보이지 않습니다. 반면, LLM-Wiki는 로컬 파일로 존재해서 AI가 무엇을 알고 모르는지 사람이 직접 확인하고 수정할 수 있는데요. Claude든 다른 모델이든 원하는 걸 연결할 수 있고, 특정 업체에 묶이지도 않습니다.

AI가 정리까지 해주면, 생각은 누가 하지?

여기까지 글을 쓰다 보니, 문득 이런 생각이 들었습니다. AI가 정리까지 해주면, 내가 해야 할 생각도 AI에게 넘기는 건 아닐까요? 처음 안드레 카파시의 LLM 위키가 Hacker News에 공유됐을 때, 댓글에서 비슷한 경험을 털어놓은 사람이 있었습니다. 그는 번아웃으로 집중력이 떨어졌을 때 많은 작업을 에이전트에 위임했는데, 새로운 형태의 기술 부채가 생겼고, "뇌의 일부가 비어 있는 느낌"이 든다고 말했습니다.

그는 왜 그런 느낌을 받았을까요? 직접 정리하는 과정에는 LLM이 대신할 수 없는 게 있습니다. 이 개념이 저 개념과 어떻게 닿는지 깨닫는 순간, 예전에 읽은 내용이 지금 읽는 것과 어떻게 연결되는지 느끼는 순간, 저는 그 순간들이 학습의 본체에 가깝다고 생각하는데요. 이렇게 스스로 사고하는 과정이 빠지면, 위키는 쌓여도 내 머릿속은 비어가는 역설이 생길 수 있습니다.

물론 카파시가 LLM에게 맡기자는 건, 사고의 과정이 아닙니다. 북키핑과 합성은 다르거든요. 교차 참조를 업데이트하고 모순을 표시하고 파일을 일관성 있게 유지하는 건 행정 작업이고, 여러 소스를 읽고 그것들이 무엇을 의미하는지 스스로 연결하는 건 사고 작업입니다. LLM에게 위임하는 건 전자죠. 무엇을 읽을지, 무엇을 물을지는 여전히 사람이 결정해야 합니다.

위키 관리 작업이 쌓이다 보면, 정작 읽고 연결하고 이해하는 데 쓸 시간과 에너지가 남지 않습니다. 따라서 LLM-Wiki는 그 관리를 LLM에 넘겨, 사람은 생각에만 집중할 수 있게 하는 시도에 가깝습니다.

물론 현실적인 위험도 있습니다. 위키가 커질수록 LLM이 전체를 일관성 있게 유지하기 어려워지고, 스키마가 잘 설계되지 않으면 어느 순간부터 LLM도 사람도 전체 구조를 파악하지 못하게 되거든요. 해커 뉴스 댓글에는 "일정 복잡도를 넘으면 에이전트가 위키를 유지하지 못한다"는 경고도 있었습니다.

결국 처음부터 모든 걸 담으려 하지 말고, 좁은 도메인부터 시작하는 것이 이 위험을 줄일 수 있는 현실적인 방법입니다.

1) 하나의 주제를 정합니다

만약 여러분이 AI와 지식 관리를 공부하고 있다면 그 주제만, 특정 기술 영역을 파고 있다면 그 영역만 팝니다. 처음부터 모든 지식을 담으려 하면 스키마 설계가 복잡해지고, 일관성을 유지하기 어려워집니다. 좁게 시작해서 구조를 익히는 게 먼저입니다.

2) 스키마 파일을 먼저 씁니다

LLM에게 "이 위키는 어떤 구조로 쓸 건지, 어떤 형식의 페이지를 만들 건지, 새 소스가 들어왔을 때 무엇을 업데이트해야 하는지"를 설명하는 파일입니다. 처음엔 짧아도 되고, 쓰면서 함께 다듬어가면 됩니다.

3) 아티클 하나를 넣어보세요

LLM에게 읽고 위키를 만들어달라고 하면서, 어떤 페이지들이 생기는지 보고 스키마를 다듬는 과정이 진짜 세팅입니다. 이 과정에서 꼭 옵시디언 같은 툴이 필요하진 않습니다. 마크다운 파일이 생기는 폴더 아무 데서나 시작할 수 있고, 위키가 수십 페이지를 넘어가면 그때 옵시디언 그래프 뷰가 연결 구조를 파악하는 데 유용합니다. 웹 기사를 마크다운으로 바꿔주는 브라우저 확장(Obsidian Web Clipper)을 쓰면, 소스를 빠르게 추가하는 루틴도 잡을 수 있습니다.

마치며: 유지 관리 비용이 낮아지면 지식은 복리로 쌓인다

카파시는 이 아이디어가 1945년 Vannevar Bush가 제안한 Memex에서 이어진다고 했습니다. Memex는 개인이 직접 큐레이션하고, 문서 간 연결이 문서 자체만큼 가치 있는 지식 저장소였습니다. 그런데 Bush가 끝내 풀지 못한 문제가 하나 있었습니다. 바로 “이걸 누가 유지 관리하느냐”에 대한 것이죠. 이제 80년이 지나, 그 자리에 LLM이 들어왔습니다.

카파시가 말한 “에이전트 활용 능력은 21세기의 핵심 스킬”은 단순히 에이전트를 쓰는 능력만을 뜻하지는 않는다고 생각합니다. 오히려 중요한 것은 무엇을 에이전트에게 맡기고, 무엇을 스스로 판단할지 가르는 능력입니다. 북키핑은 맡기더라도, 무엇을 읽고 무엇을 물을지는 내가 결정해야 합니다. 결국 그 판단의 질이 위키의 깊이로 이어질 거고요. 이 글을 쓰고 나니 오랜만에 노션 위키를 다시 열어봐야겠다는 생각이 드는데요. 여러분도 나만의 위키를 갖고 계신가요?

<참고>