1. 대화는 쌓이지 않습니다

석 달 전, 경쟁 서비스의 요금제를 AI와 함께 뜯어본 적이 있습니다. 화면 캡처를 몇 장 붙이고 우리 요금제와 뭐가 다른지 한참을 주고받았습니다. 그날 나온 정리는 꽤 쓸 만했습니다. "이 회사는 무료 구간을 넓게 열어 두고 팀 단위 결제에서 돈을 버는 구조"라는 문장 하나를 얻으려고 40분을 썼으니까요.

그리고 오늘, 팀장이 묻습니다. "그때 그 경쟁사 요금제 정리한 거 어디 있죠?"

대화 목록을 뒤집니다. 제목은 '무제 대화'거나 '요금제 비교 도와줘' 같은 것들이라 어느 게 그날인지 알 수 없습니다. 검색창에 '요금제'를 넣으면 열 개가 나오는데 전부 비슷비슷합니다. 결국 새 창을 열고 처음부터 다시 시작합니다. 우리 서비스가 뭘 하는 곳인지, 경쟁사가 어디인지, 어떤 형식으로 정리해 달라고 했는지를 또 설명하면서요.

1.1 문제는 답이 아니라 답이 놓인 자리입니다

이 경험이 낯설지 않다면 문제의 정체를 정확히 볼 필요가 있습니다. AI가 답을 못해서 생긴 일이 아닙니다. 그날의 답은 훌륭했습니다. 문제는 그 답이 놓인 자리입니다.

대화 기록은 시간순으로 쌓입니다. 8월 3일에 한 이야기 다음에 8월 5일에 한 이야기가 옵니다. 반면 우리가 나중에 찾고 싶은 것은 주제순입니다. "경쟁사 요금제"에 대해 지금까지 알아낸 것 전부, "우리 온보딩 이탈률"에 대해 논의된 것 전부를 한자리에서 보고 싶습니다. 시간순으로 쌓인 것을 주제순으로 꺼내려니 매번 실패합니다.

파일을 올려 두고 물어보는 방식도 사정은 비슷합니다. PDF 열 개를 올려 두면 AI가 질문할 때마다 그 열 개를 다시 뒤져 답을 만듭니다. 답은 나오지만 어제 한 고생이 오늘 도움이 되지 않습니다. 매번 처음부터입니다.

한 바퀴 돌 때마다 결과물은 나오지만 다음 바퀴가 더 쉬워지지는 않습니다. 지식이 쌓이는 것이 아니라 같은 자리를 계속 도는 것입니다.

1.2 카파시가 공개한 패턴

2026년 4월, 안드레이 카파시(Andrej Karpathy)가 자신이 LLM으로 개인 지식 창고를 만드는 방식을 짧은 문서 하나로 공개했습니다. 이름은 'LLM Wiki'입니다. 며칠 만에 널리 퍼졌고, 이 책은 그 패턴을 한국어 실습으로 옮긴 것입니다.

핵심 문장은 이렇습니다.

내가 모은 자료는 소스 코드이고, 위키는 그것을 컴파일한 결과물이다.

프로그램을 실행할 때 소스 코드를 매번 다시 해석하지 않고 한 번 빌드해 둔 결과물을 실행하듯, 질문할 때마다 원본 더미를 다시 뒤지지 말고 한 번 정리해 둔 문서를 읽자는 것입니다. 자료가 새로 들어오면 그때 다시 빌드합니다.

그리고 이 컴파일을 사람이 하지 않습니다. 새 자료를 폴더에 넣고 "정리해 줘"라고 말하면, AI가 자료를 읽고, 관련된 기존 문서들을 찾아 갱신하고, 없으면 새로 만들고, 문서끼리 링크를 걸고, 목차와 작업 기록까지 손봅니다. 자료 한 건이 문서 열 장을 건드리기도 합니다.

카파시가 덧붙인 비유가 이 방식의 성격을 잘 보여줍니다.

Obsidian이 편집기이고, LLM이 프로그래머이고, 위키가 코드베이스다.

한쪽 화면에 AI를 띄우고 다른 쪽 화면에 Obsidian을 띄웁니다. AI가 대화에 따라 문서를 고치면, 그 결과가 옆 화면에서 실시간으로 보입니다. 링크를 눌러 따라가고, 그래프를 열어 전체 모양을 보고, 방금 바뀐 페이지를 읽습니다. 이 책이 만들려는 작업 환경이 정확히 이 그림입니다.

• 카파시가 공개한 원문: llm-wiki.md

1.3 정리해 두자는 다짐은 왜 실패했나

"그러니까 중요한 건 노션에 옮겨 두면 되잖아요."

맞는 말이고 대부분 실패합니다. 실패하는 이유는 게을러서가 아니라 정리라는 일의 성격 때문입니다.

문서 하나를 지식 창고에 제대로 넣으려면 이런 일들을 해야 합니다.

• 이 내용이 들어갈 페이지가 이미 있는지 찾기
• 있으면 기존 내용과 충돌하지 않는지 읽어 보기
• 겹치는 문장은 지우고 새 정보만 합치기
• 관련된 다른 페이지에 링크 걸어 두기
• 목차에 새 항목 추가하기
• 출처가 무엇이었는지 적어 두기

읽고 판단하는 데 5분, 이 뒷정리에 25분이 듭니다. 재미있는 부분은 앞의 5분이고, 위키를 망가뜨리는 것은 뒤의 25분입니다. 그래서 첫 주에는 열심히 채우다가 셋째 주에는 "일단 나중에"라고 미루고 두 달 뒤에는 아무도 열지 않는 폴더가 됩니다.

한 가지 사실만 붙잡으면 이야기가 달라집니다. 지식 창고를 유지하기 어려운 이유는 읽기나 생각하기가 아니라 뒷정리이고, 그 뒷정리야말로 AI가 지치지 않고 하는 일입니다. 사람은 무엇이 중요한지 판단하고, AI는 그 판단을 문서로 옮기고 정리하고 이어 붙입니다.

1.4 이 책에서 만드는 것

거창한 시스템이 아닙니다. 내 컴퓨터 안의 폴더 하나와 그 안에 든 마크다운 문서들입니다. 서버를 빌리거나 프로그램을 개발하지 않습니다. 설치하는 것은 Claude Desktop과 Obsidian 둘뿐이고, 둘 다 클릭 몇 번이면 끝납니다.

달라지는 것은 쓰는 방식입니다.

1. 새 자료가 생기면 폴더에 넣고 "인제스트해 줘"라고 말합니다. AI가 읽고, 관련 문서를 갱신하고, 없으면 만들고, 목차와 기록까지 손봅니다.
2. 궁금한 것이 생기면 그 폴더 안에서 묻습니다. AI는 원본을 매번 다시 읽는 대신 이미 정리된 문서를 읽고 근거와 함께 답합니다.
3. 가끔 "이 위키 어디가 이상한지 봐 줘"라고 시킵니다. 서로 어긋나는 문장, 오래돼서 더는 맞지 않는 주장, 아무 데서도 연결되지 않은 문서를 찾아냅니다.

이 세 동작을 각각 인제스트, 질의, 린트라고 부릅니다. 책 전체가 사실상 이 셋을 손에 익히는 과정입니다.

화살표의 방향이 핵심입니다. 자료도, 질문도, 답변도 결국 위키로 모입니다. 한 번 정리한 것은 다음 질문에서 재료가 됩니다. 쓰면 쓸수록 위키가 두꺼워지고, 두꺼워질수록 답이 좋아집니다.

이 아이디어 자체는 오래됐습니다. 1945년 버니바 부시(Vannevar Bush)가 제안한 메멕스(Memex)는 개인이 읽은 모든 자료를 연결해 둔 기계였습니다. 80년 동안 실현되지 않은 이유는 아이디어가 나빠서가 아니라 그 연결을 사람이 손으로 유지할 수 없었기 때문입니다. 이제 그 유지 비용을 대신 낼 존재가 생겼습니다.

다음 절에서 준비물을 챙기고, 3장에서 곧바로 위키 하나를 만들어 봅니다.