AI가 기억하는 지식사전 만들기

AI 교육 · Read in English

AI와 일을 하다 보면 같은 설명을 몇 번이고 다시 하게 되는 순간이 옵니다. 지난주에 정해 둔 말투 기준, 한 번 실패한 뒤에 찾아낸 해결 방법, 이건 하지 않기로 한 이유 같은 것들이 그날의 대화창에는 남아 있지만 다음 날 새 대화를 열면 사라집니다. 메모장에 적어 두어도 폴더가 늘어날수록 어디에 무엇을 적었는지 찾기가 어려워지고, 결국 같은 시행착오를 한 번 더 겪게 됩니다.

이 글은 그 문제를 줄이기 위해 DMS.Labs의 리도가 쓰고 있는 개인 지식사전 「리도의 세계수」를 어떻게 만들었는지 정리한 실무 가이드입니다. 고객사의 구축 결과를 보고하는 글이 아니라, 공개된 아이디어 문서와 직접 운영 중인 저장고를 바탕으로 만드는 순서를 적은 글입니다. 글 끝에는 개인 내용을 모두 뺀 빈 서식을 내려받는 링크를 붙였으니, 읽으시면서 같은 구조를 바로 열어 보실 수 있습니다.

먼저 풀어야 할 문제: 배움이 흩어진다

리도는 하루에도 여러 건의 글, 상품, 영상 작업을 AI로 진행하는데, 그 과정에서 얻은 배움이 작업 기록과 기억 파일 여기저기에 나뉘어 있었습니다. 예전에도 같은 목적의 저장고를 한 번 만들었지만 몇 달 뒤에는 거의 쓰지 않게 되었습니다. 정리하는 일이 사람 몫이었기 때문에, 바쁜 날이 이어지면 가장 먼저 밀리는 일이 되었습니다.

사람이 지식을 정리하다 포기하는 이유는 대개 두 가지입니다. 새 자료가 들어올 때마다 기존 문서 여러 곳을 함께 고쳐야 하는데 그 일이 지루하고, 고치지 않으면 문서끼리 서로 어긋나기 시작합니다. 이 두 가지를 AI에게 맡기자는 생각이 이번 지식사전의 출발점이었습니다. 사람은 어떤 자료를 넣을지와 무엇이 옳은지를 판단하고, AI는 요약하고 연결하고 목록을 고치고 기록을 남깁니다.

왼쪽에는 손글씨 메모와 포스트잇이 흩어져 있고 오른쪽에는 빈 폴더 네 개와 노트가 정돈된 나무 책상을 위에서 본 모습.원본 전체 보기 ↗

LLM Wiki는 무엇이 다른가

이 방식의 바탕은 Andrej Karpathy가 2026년 4월에 공개한 아이디어 문서입니다. 제품이 아니라 아이디어 문서여서 세부 구현은 각자 AI와 함께 정하도록 되어 있습니다. 핵심은 AI가 자료를 넣는 시점에 미리 읽고 정리해서, 서로 연결된 마크다운 문서 모음(위키)에 반영하고 그 위키를 계속 고쳐 나간다는 점입니다.

흔히 쓰는 방식과 비교하면 차이가 분명해집니다. NotebookLM이나 파일 올리기처럼 질문할 때마다 자료에서 관련 부분을 찾아 답하는 방식을 RAG(검색 증강 생성)라고 부르는데, 이 방식은 질문할 때 정리가 일어나기 때문에 질문이 끝나면 정리된 내용이 남지 않습니다. LLM Wiki는 정리가 자료를 넣을 때 일어나므로 연결, 모순 표시, 종합이 문서에 쌓입니다. 그래서 같은 질문을 다시 해도 처음부터 다시 찾을 필요가 없습니다.

원문은 구조를 세 층으로 설명합니다. 원본 자료는 넣은 뒤 고치지 않고, 위키는 AI가 쓰고, 운영 규칙 문서가 AI에게 어떻게 일할지 알려 줍니다. 작업은 넣기, 질문하기, 점검하기 세 가지이고, 목록 문서와 작업 기록으로 위키를 둘러봅니다. 원문 작성자는 자료가 약 100개, 문서가 수백 개까지는 목록 문서만으로도 충분하다고 말합니다.

폴더는 네 칸이면 충분합니다

리도의 저장고는 폴더를 역할별로 나눕니다. 아직 정리하지 않은 것은 받은자료에, 넣은 뒤 건드리지 않을 원본은 원본에, AI가 계속 고쳐 나가는 지식은 위키에, 위키로 만든 강의안이나 글 기획은 결과물에 둡니다. 서식과 첨부 파일은 따로 두어 위의 네 곳이 어지러워지지 않게 합니다.

위키 안에서는 한 번 더 나눕니다. 원본 하나당 요약 하나를 두는 자료요약에는 사실만 적고, 개념 폴더에서 해석과 연결을 합니다. 도구와 플랫폼은 따로 모으고, 직접 해 보고 얻은 지식은 실전 폴더에 방법, 실험, 교훈, 판단으로 나누어 둡니다. 사실과 해석을 같은 문서에 섞지 않으면 나중에 틀린 부분을 찾아 고치기가 훨씬 쉽습니다.

AI가 먼저 읽는 운영 규칙 한 장

지식사전에서 가장 중요한 파일은 위키 문서가 아니라 운영 규칙입니다. AI는 대화가 바뀌면 이전 약속을 기억하지 못하므로, 매번 작업 전에 이 문서를 먼저 읽도록 정해 둡니다. Claude Code나 Codex는 폴더 안의 안내 파일을 자동으로 읽는 도구라서, 그 안내 파일이 운영 규칙을 먼저 읽으라고 가리키게 해 두면 따로 부탁하지 않아도 규칙이 적용됩니다.

운영 규칙에는 다음 내용을 적었습니다. 이 저장고의 목적이 많이 모으기가 아니라 다음 작업에서 다시 꺼내 쓰기라는 점, 다시 쓸 수 있는 배움만 넣는다는 점, 새 문서를 만들기 전에 기존 문서를 먼저 고친다는 점, 틀린 내용은 조용히 덮지 않고 무엇이 왜 바뀌었는지 남긴다는 점입니다. 폴더별 역할과 문서 머리 정보 양식, 세 가지 작업의 순서도 여기에 들어갑니다. 규칙 문서가 짧고 구체적일수록 AI가 지키는 정도도 높아집니다. AI에게 일을 시키기 전에, 업무 설명서 한 장부터 씁니다에서 다룬 한 장짜리 업무 설명서와 같은 생각입니다.

모든 문서에 출처와 확인 상태를 붙입니다

LLM Wiki의 약점은 한 번 잘못 정리된 내용이 다른 문서와 이후 답변으로 퍼질 수 있다는 점입니다. 원문에는 이를 막는 방법이 따로 없어서, 리도는 모든 위키 문서의 맨 위에 머리 정보를 붙이도록 했습니다. 문서 제목, 종류, 확인 상태, 출처, 확인한 날, 다시 확인할 날, 분야 태그가 들어갑니다.

확인 상태는 다섯 가지입니다. 직접확인은 실제로 해 보거나 화면과 파일로 확인한 것, 출처확인은 공식 문서나 원문으로 확인한 것, 작성자주장은 글쓴이의 주장만 있고 따로 확인하지 않은 것, 미검증은 아직 확인하지 못한 것, 폐기는 틀렸거나 더는 맞지 않는 것입니다. 폐기한 문서도 지우지 않고 이유를 남깁니다. 요금이나 정책처럼 자주 바뀌는 내용에는 다시 확인할 날을 30일 뒤로, 도구 기능은 60일 뒤로 적어 두고, 원리나 판단은 비워 둡니다.

이 표시가 쓸모 있는 순간은 AI가 답할 때입니다. 운영 규칙은 답에 근거 문서를 붙이고, 확인 상태가 낮은 내용은 그렇다고 말하도록 정해 두었습니다. 예를 들어 어떤 도구의 기능을 묻는 질문에 작성자주장이라고 표시된 문서가 근거라면, AI는 그 사실을 함께 알려 줍니다. 사람이 읽을 때에도 어느 문장까지 믿어도 되는지 바로 보입니다.

세 가지 작업만 반복합니다

지식사전을 쓰는 방법은 세 가지 작업으로 줄어듭니다.

자료 넣기는 원본을 알맞은 폴더에 저장하는 것에서 시작합니다. AI가 원본을 읽고 자료요약을 만들고, 관련된 개념과 도구와 실전 문서를 찾아 먼저 고칩니다. 맞는 문서가 없을 때만 새 문서를 만듭니다. 그다음 목록과 기록을 고치고, 원본의 처리 상태를 완료로 바꿉니다. 한 번에 하나씩 끝내고 다음으로 넘어가는 것이 규칙입니다.

질문하기는 목록 문서를 먼저 읽고 관련 위키 문서를 읽은 뒤 답하는 순서입니다. 원본은 마지막에 확인합니다. 다시 쓸 가치가 있는 답은 종합 폴더에 저장해서 다음 질문의 재료로 삼습니다.

점검하기는 한 달에 한 번, 서로 어긋나는 내용과 다시 확인할 날이 지난 문서, 아무 문서와도 연결되지 않은 문서, 깨진 연결, 머리 정보가 빠진 문서, 목록과 실제 파일이 다른 곳을 찾는 일입니다. 보고서를 먼저 만들고 사람이 확인한 뒤에 고칩니다. 내려받는 서식에는 이 점검을 대신해 주는 짧은 스크립트(scripts/check.mjs)가 들어 있어서 Node.js가 설치된 컴퓨터에서 한 줄로 실행할 수 있습니다.

무엇을 넣고, 무엇을 넣지 않을지 정합니다

지식사전이 쓸모없는 기록 더미가 되는 가장 흔한 경로는 모든 것을 다 넣는 것입니다. 리도는 매일의 게시 완료 기록이나 단순 진행 보고, 일회성 상태는 넣지 않기로 했습니다. 넣는 것은 끝난 실험의 결과, 실패와 해결 방법, 사람이 명확히 고르거나 거절한 이유, 반복해서 쓸 제작 방법입니다.

반대로 어떤 경우에도 넣지 않는 것도 정해 두었습니다. 비밀번호와 인증 코드, 접속 열쇠, 개인정보, 다른 사람의 대화 원문, 유료 글의 전문입니다. 유료 글은 링크와 짧은 인용, 내 요약과 적용 아이디어만 남깁니다. 이 목록은 AI가 자료를 정리하다가 실수로 민감한 내용을 위키에 옮기는 일을 막는 안전선이기도 합니다.

예시로 위키에 실제로 들어 있는 교훈 가운데 일반화할 수 있는 것을 하나 옮겨 보겠습니다. 저장했다는 표시와 실제로 성공했다는 것은 다릅니다. 자동화가 완료 메시지를 남겼더라도 결과가 실제 화면에서 확인되기 전까지는 성공으로 적지 않는다는 판단입니다. 이렇게 한 줄로 줄일 수 있는 판단이 쌓이면 다음 작업에서 AI에게 같은 주의를 다시 설명할 필요가 줄어듭니다.

한 곳에서만 고치고, 다른 AI는 받은자료에만 씁니다

여러 AI를 함께 쓰면 같은 저장고를 동시에 고치는 사고가 생기기 쉽습니다. 리도는 위키와 원본을 고치는 AI를 하나로 정했습니다. Claude Code, Codex, ChatGPT, NotebookLM 같은 다른 도구는 읽기만 하고, 새로 알게 된 것이나 제안은 받은자료 폴더에 날짜와 출처 AI 이름이 붙은 파일로만 남깁니다. 정리 담당 AI가 주간 정리 때 그 파일을 읽어 와서 위키에 넣을지 판단합니다.

컴퓨터가 두 대인 경우도 같은 원칙입니다. 한 대에서만 위키를 고치고, 다른 컴퓨터에는 읽기 전용 사본만 둡니다. 동기화 프로그램으로 양쪽 수정을 합치지 않습니다. 목록과 기록이 두 군데에서 동시에 바뀌면 어느 쪽이 맞는지 가려내기 어렵기 때문입니다.

변경 기록을 남겨서 되돌릴 수 있게 합니다

AI가 문서를 잘못 고쳐도 원래대로 돌릴 수 있어야 안심하고 맡길 수 있습니다. 리도는 저장고를 git으로 관리해서 자료 넣기와 정리와 점검 수정이 끝날 때마다 변경 기록을 남기고, 그 기록을 다른 드라이브의 백업 저장소에도 보냅니다. 기본 드라이브가 고장 나도 백업 저장소에서 복원할 수 있습니다. git이 낯설다면 폴더를 압축해 날짜를 붙여 보관하는 것으로 시작하셔도 됩니다. 중요한 것은 AI가 고치기 전의 상태가 어딘가에 남아 있다는 점입니다.

나무 책상 위 열린 노트북 옆에 끈으로 연결된 빈 카드 묶음이 코르크판에 놓여 있는 모습.원본 전체 보기 ↗

NotebookLM은 보조로 붙입니다

NotebookLM은 자료를 넣고 그 자료를 근거로 질문하거나 오디오 해설을 만들어 주는 Google의 학습 도구입니다. Karpathy도 이 도구를 질문할 때마다 자료를 찾는 RAG 방식의 예로 듭니다. 그래서 리도는 NotebookLM을 중심 저장고가 아니라 보조 도구로 둡니다. 특정 주제에 해당하는 위키 문서만 골라 넣고, 그 범위 안에서 질문하거나 해설 음성을 만들 때 씁니다.

연결은 위키 문서를 구글 문서로 자동 동기화하고 그 구글 문서를 NotebookLM의 자료로 지정하는 방식으로 시험했습니다. 문서 7개를 연결해 동작하는 것까지 확인했고, 오래 운영했을 때 동기화가 안정적인지는 아직 확인하지 못했습니다. 다만 위키 원본은 여전히 한 곳에서만 고치므로, NotebookLM 쪽에서 무엇을 하든 원본이 바뀌지는 않습니다.

3D 지식그래프로 연결 상태를 봅니다

문서가 늘어나면 얼마나 잘 연결되어 있는지 눈으로 보고 싶어집니다. 옵시디언에는 그래프 화면이 있고, 리도는 위키의 연결을 3D 그래프로 만들어 「리도의 세계수」라는 이름을 붙였습니다. 2026년 10월 9일 기준으로 문서 74개와 연결 119개가 7개 묶음으로 나뉘어 있고, 묶음 이름은 검증 원칙, 영상 제작 원칙, 글쓰기 원칙, 판매·제휴 원칙, 작업 운영 원칙 같은 분야 원칙과 개념·도구·운영 결정, 자료 요약입니다. 그래프는 매주 일요일 정리 때 새로 만듭니다.

리도의 세계수 3D 지식그래프 화면. 문서 74개, 연결 119개, 묶음 7개와 묶음 이름이 표시되어 있다.원본 전체 보기 ↗

위 화면은 리도의 실제 저장고에서 만든 그래프이고, 위의 숫자는 리도가 직접 센 수치입니다. 같은 구조를 만든다고 해서 같은 숫자가 나오지는 않습니다. 그래프에서 어느 묶음에도 이어지지 않고 떨어져 있는 점은 정리가 덜 된 문서라는 신호가 됩니다.

한계도 미리 알아 두셔야 합니다

이 방식은 만능이 아닙니다. 첫째, AI가 잘못 정리하면 그 내용이 퍼질 수 있습니다. 출처와 확인 상태 표시, 변경 기록, 월 1회 점검은 이 위험을 줄이는 장치이지 없애는 장치가 아닙니다. 위키 문서를 AI가 쓴 것이므로 사람이 가끔 직접 읽어 보셔야 합니다.

둘째, 문서가 수백 개를 넘으면 목록 문서만으로 찾기 어려워질 수 있습니다. 원문도 그 규모까지만 목록으로 충분하다고 말하며, 넘어서면 검색 도구를 붙이는 방향을 생각해야 합니다. 리도의 저장고는 아직 문서 74개 규모라서 이 한계에 닿지 않았습니다.

셋째, 위 숫자와 운영 방식은 한 사람이 약 3주 동안 쓴 결과입니다. 팀 단위로 쓸 때의 효과나 몇 달 이상 유지했을 때의 결과는 확인하지 못했습니다. 리도의 위키에는 리도가 확인한 교훈 52개와 분야 원칙 5개가 들어 있고, 매주 일요일에 정리하는 흐름도 만들었지만, 이것이 모든 사람에게 같은 효과를 낸다고 말씀드리기는 어렵습니다.

빈 서식으로 시작해 보세요

개인 내용을 모두 뺀 빈 서식을 압축 파일로 만들었습니다. 폴더 구조, 운영 규칙, Claude Code와 Codex용 안내 파일, 문서 서식 세 가지, 점검 스크립트, 예시 문서 두 개가 들어 있습니다.

빈 지식사전 서식 내려받기 (reedo-world-tree-starter.zip)

순서는 간단합니다. 압축을 풀고 옵시디언에서 폴더를 보관소로 엽니다. 그 폴더에서 Claude Code나 Codex 같은 AI 도구를 실행하고, 링크 하나를 주면서 지식사전에 넣어 달라고 부탁합니다. 운영 규칙의 순서대로 원본 저장, 요약, 연결, 목록과 기록 수정이 진행됩니다. 처음 몇 건은 결과를 직접 열어 확인하시고, 마음에 들지 않는 부분은 운영 규칙을 고쳐 다음 작업에 반영하시면 됩니다.

팀에서 쓰시려는 경우에는 앞의 글들과 함께 읽으시면 좋습니다. 어떤 일을 AI에게 맡길지 정하는 기준은 AI 교육은 도구 설명보다 '이 일을 맡겨도 되나'에서 시작합니다에, 맡긴 일의 권한을 나누는 방법은 AI 자동화, 권한을 세 단계로 나눠 주기에 정리했습니다. 지식사전을 도입한 뒤 효과를 어떻게 재는지는 AI 도입 성과 측정에서 다뤘습니다.

이 글의 설명은 공개된 아이디어 문서와 DMS.Labs 리도의 개인 저장고 운영을 바탕으로 한 일반 가이드이며, 특정 고객사의 결과가 아닙니다. 도구의 기능과 요금은 바뀔 수 있으므로 적용 전에 최신 공식 문서를 확인해 주시기 바랍니다.

참고 자료

• Karpathy, A. LLM Wiki (아이디어 문서). GitHub Gist, 2026년 4월.
• Obsidian. Data storage · Pricing. 2026년 10월 9일 확인.