좋은 도구일수록 한계를 먼저 알아야 한다
LLM Wiki는 매력적인 아이디어다. 자료를 넣으면 AI가 읽고, 요약하고, 연결하고, 모순을 찾고, 다시 위키에 반영한다. 지식이 채팅창에 흩어지지 않고 파일로 남는다. 이 책에서 계속 말한 것처럼, 질문만 반복하는 사람과 지식을 축적하는 사람의 차이는 시간이 지날수록 커진다.
하지만 이 방식은 만능이 아니다. Andrej Karpathy가 공개한 LLM Wiki도 완성된 제품이 아니라 "아이디어 파일"에 가깝다. 핵심은 raw/, wiki/, schema라는 단순한 구조와 ingest, query, lint라는 운영 패턴이다.1 나머지 세부 구현은 사용자의 목적과 규모에 맞게 설계해야 한다.
따라서 LLM Wiki를 제대로 쓰려면 두 가지 태도가 필요하다.
첫째, 작은 규모에서는 과감하게 단순하게 시작한다. Markdown, Obsidian, Git, Claude Code나 Codex만으로도 충분히 쓸 수 있다.
둘째, 규모가 커지면 더 이상 "그냥 AI에게 정리시킨다"로 버티지 않는다. 검색, 권한, 검수, 감사 로그, 출처 추적을 시스템으로 만들어야 한다.
LLM Wiki는 지식 운영체제의 출발점이지, 운영 자체를 대신해주는 마법이 아니다.
위키가 커지면 다시 검색 문제가 돌아온다
처음에는 index.md 하나면 충분하다. 페이지가 30개, 50개, 100개 정도일 때는 AI가 인덱스를 읽고 관련 문서를 찾아가며 답할 수 있다. 이 규모에서는 복잡한 벡터 데이터베이스보다 Markdown 위키가 더 빠르고 투명할 때도 많다.
문제는 위키가 커질 때 시작된다.
페이지가 수백 개를 넘으면 index.md 자체가 길어진다. 개념 페이지가 많아지면 비슷한 이름의 문서가 늘어난다. "고객 인터뷰"라는 페이지와 "고객 피드백", "사용자 불만", "온보딩 문제"가 서로 겹치기 시작한다. AI는 어떤 페이지를 먼저 읽어야 할지 헷갈릴 수 있다.
컨텍스트 한계도 현실적인 문제다. 컨텍스트 창이 커졌다고 해서 모든 문서를 한 번에 넣으면 좋은 답이 나오는 것은 아니다. 긴 문맥에서는 중요한 정보가 중간에 묻힐 수 있고, 관련 없는 페이지가 섞이면 답변의 초점이 흐려진다. 위키가 커질수록 중요한 것은 "많이 넣기"가 아니라 "정확히 고르기"다.
이때 필요한 것이 계층 구조다.
주제별
index.md를 나눈다.오래된 프로젝트는
archive/로 이동한다.핵심 페이지에는 "이 페이지를 먼저 읽어라"는 역할을 부여한다.
페이지가 너무 길어지면 하위 개념으로 분리한다.
단순 키워드 검색, BM25, 벡터 검색, 하이브리드 검색을 추가한다.
결국 큰 규모에서는 RAG가 다시 등장한다. 다만 이번에는 원문 청크만 검색하는 RAG가 아니라, 원문과 위키 지식층을 함께 검색하는 구조다. 작은 규모에서는 Markdown 위키가 중심이고, 큰 규모에서는 검색 인프라가 보조 엔진이 된다.
중요한 판단 기준은 문서 수가 아니라 "탐색 실패가 얼마나 자주 발생하는가"다. AI가 중복 페이지를 자주 만들거나, 이미 있는 내용을 못 찾거나, 엉뚱한 문서를 근거로 답하기 시작하면 검색 계층을 추가할 때다.
잘못된 요약도 복리로 쌓인다
지식이 복리로 쌓인다는 말에는 반대편도 있다. 오류도 복리로 쌓일 수 있다.
LLM Wiki의 가장 큰 위험은 잘못된 요약이 위키 안에서 사실처럼 굳어지는 것이다. RAG는 질문할 때마다 원문을 다시 찾는다. 물론 RAG도 틀릴 수 있지만, 적어도 원문을 다시 볼 기회가 있다. 반면 LLM Wiki는 ingest 시점에 AI가 해석한 내용을 위키에 저장한다. 이 해석이 틀리면 이후 답변은 틀린 위키 페이지를 기반으로 다시 만들어진다.
오염은 여러 방식으로 생긴다.
원문에 없는 주장을 AI가 그럴듯하게 추가한다.
"가능성"을 "사실"처럼 적는다.
오래된 자료와 최신 자료의 차이를 표시하지 않는다.
서로 다른 맥락의 개념을 하나로 병합한다.
반론이나 예외를 요약 과정에서 삭제한다.
출처가 약한 주장을 반복 업데이트하면서 강한 주장처럼 만든다.
이런 오류는 한 번에 폭발하지 않는다. 조용히 쌓인다. 그래서 더 위험하다. 겉으로 보기에는 위키가 정돈되어 있고, 링크도 많고, 문장도 자연스럽다. 하지만 그 안의 핵심 주장 몇 개가 틀리면 전체 지식 베이스가 오염된다.
해결책은 단순하다. 위키를 진실의 원천으로 보지 말아야 한다.
진실의 원천은 언제나 raw/다. 위키는 해석이다. 원문은 증거다. 이 구분이 무너지면 LLM Wiki는 편리한 지식 시스템이 아니라 그럴듯한 오류 증폭기가 된다.
실무에서는 다음 규칙을 넣어야 한다.
모든 핵심 주장에는 출처를 붙인다.
확실한 사실, 추정, 의견을 구분한다.
신뢰도 낮은 페이지에는
confidence: low를 표시한다.충돌이 있는 페이지에는
contested: true를 표시한다.중요한 페이지는 AI가 바로 덮어쓰지 않고 초안으로 만든다.
ingest 후 Git diff를 확인한다.
주간 lint에서 "출처 없는 주장"을 우선 제거한다.
좋은 LLM Wiki는 많은 페이지를 가진 위키가 아니다. 되돌아갈 수 있고, 검증할 수 있고, 틀렸을 때 고칠 수 있는 위키다.
팀 위키에는 거버넌스가 필요하다
개인 위키에서는 실수가 나도 피해가 제한적이다. 잘못된 독서 요약, 중복된 개념 페이지, 어색한 링크 정도는 나중에 고치면 된다. 그러나 팀 위키는 다르다. 한 번 잘못된 정보가 팀의 공통 지식이 되면 제품 결정, 고객 대응, 채용, 보안, 법무 판단에 영향을 줄 수 있다.
팀 위키에서 반드시 필요한 것은 네 가지다.
첫째, 리뷰다. AI가 작성한 문서는 곧바로 공식 문서가 되면 안 된다. 초안, 리뷰 중, 승인됨 같은 상태가 있어야 한다. 특히 정책, 가격, 계약, 보안, 고객 약속과 관련된 페이지는 담당자가 승인해야 한다.
둘째, 권한이다. 모든 사람이 모든 원문을 볼 수 있으면 안 된다. 고객 개인정보, 급여 정보, 투자 자료, 법률 문서, 보안 사고 기록은 접근 범위가 다르다. AI 에이전트도 사람과 마찬가지로 최소 권한 원칙을 따라야 한다. OWASP는 LLM 애플리케이션에서 민감정보가 출력으로 노출될 수 있음을 주요 위험으로 다루며, 데이터 삭제·스크러빙, 입력 검증, 외부 데이터 소스 접근 제한, 최소 권한 원칙을 권장한다.2
셋째, 감사 로그다. 누가 어떤 자료를 넣었는지, AI가 어떤 페이지를 바꿨는지, 누가 승인했는지 남아야 한다. log.md는 개인 위키에서는 활동 기록이지만, 팀 위키에서는 책임 추적 장치다. Git commit, PR 리뷰, 승인자, 변경 사유가 함께 남아야 한다.
넷째, 롤백이다. AI가 잘못 병합하거나, 대량 업데이트로 페이지를 오염시키거나, 민감 정보를 잘못 요약할 수 있다. 이때 되돌릴 수 있어야 한다. Git은 선택이 아니라 기본 장치다.
팀 LLM Wiki는 "AI가 알아서 정리하는 위키"가 아니다. 더 정확히 말하면 "AI가 초안을 만들고, 사람이 승인하며, 시스템이 추적하는 위키"다. 이 차이를 무시하면 자동화는 생산성이 아니라 위험이 된다.
자동화와 인간 판단의 경계
LLM Wiki에서 AI에게 맡기기 좋은 일은 분명하다.
긴 문서를 1차 요약하기
관련 페이지 후보 찾기
중복 개념 탐지하기
깨진 링크 찾기
오래된 주장 표시하기
회의록에서 결정 사항 추출하기
질문 답변을 문서 초안으로 바꾸기
반대로 사람이 끝까지 맡아야 할 일도 있다.
무엇을 중요한 자료로 볼지 결정하기
어떤 주장을 공식 입장으로 채택할지 판단하기
충돌하는 증거 중 무엇을 더 신뢰할지 결정하기
팀의 전략과 가치에 맞는 방향을 정하기
삭제해야 할 민감 정보를 판별하기
최종 책임이 따르는 문서를 승인하기
AI는 정리를 잘한다. 그러나 책임을 지지는 않는다. 이 문장을 운영 원칙으로 삼아야 한다.
좋은 운영 구조는 AI를 믿지 않는 구조가 아니다. AI가 잘할 수 있는 일을 충분히 맡기되, 잘못했을 때 발견하고 멈추고 되돌릴 수 있는 구조다.
미래: 개인 AI와 지식 운영체제
LLM Wiki의 미래는 단순한 노트 정리 도구에 머물지 않을 가능성이 크다. 이미 방향은 보인다.
첫 번째 방향은 개인 AI다. 지금의 AI는 대화 상대에 가깝다. 하지만 개인 위키와 연결되면 나의 목표, 프로젝트, 반복 고민, 취향, 결정 이력을 장기적으로 참조하는 작업 파트너가 된다. 여기서 agent memory와 LLM Wiki가 만난다. Agent memory는 특정 사용자와의 상호작용, 선호, 시간 흐름을 기억하는 데 강하고, LLM Wiki는 특정 주제나 도메인의 지식을 축적하는 데 강하다.3 미래의 개인 AI는 둘을 함께 쓸 가능성이 높다.
두 번째 방향은 자동 지식 그래프다. 지금은 Markdown 링크가 중심이지만, 앞으로는 AI가 개념, 인물, 프로젝트, 주장, 근거, 반론 사이의 관계를 더 구조적으로 추출할 것이다. 단순히 "관련 있음"이 아니라 "A는 B의 원인이다", "C는 D를 반박한다", "E는 F의 최신 버전이다" 같은 관계가 관리될 수 있다.
세 번째 방향은 팀 운영체제다. 회의록, Slack, 이슈, 고객 인터뷰, 제품 문서가 자동으로 흡수되고, 팀의 의사결정 기록과 온보딩 문서가 계속 업데이트되는 구조다. VentureBeat는 Karpathy식 접근을 기업 내부의 흩어진 자료를 컴파일하는 새로운 제품 범주로 해석하면서, 개인 연구 위키에서 기업 운영 위키로 확장될 때 권한, 품질 게이트, 다중 에이전트 검증이 중요해진다고 설명한다.4
네 번째 방향은 지식 상품 플랫폼이다. 개인이나 팀이 만든 LLM Wiki는 단순한 내부 노트가 아니라 재사용 가능한 지식 상품이 될 수 있다. 예를 들어 "스타트업 투자 검토 위키", "영어 논문 읽기 위키", "AI 리서치 타임라인 위키", "특정 산업 경쟁사 분석 위키"는 템플릿, 원문 목록, 개념 페이지, 질문 프롬프트와 함께 판매될 수 있다.
이때 중요한 것은 원문 저작권과 출처 관리다. 원문을 그대로 재판매하는 것이 아니라, 출처를 존중하면서 사용자가 직접 검증 가능한 구조를 제공해야 한다. 미래의 지식 상품은 PDF 한 권이 아니라, AI가 읽고 업데이트하고 질의할 수 있는 살아 있는 지식 패키지가 될 수 있다.
현실적인 확장 기준
LLM Wiki를 오래 쓰려면 다음 기준을 기억하면 된다.
처음에는 단순하게 시작한다. raw/, wiki/, index.md, log.md, CLAUDE.md면 충분하다.
자료가 늘면 주제별로 나눈다. 하나의 거대한 위키보다 여러 개의 작은 주제 위키가 낫다.
탐색 실패가 늘면 검색을 붙인다. Markdown 위키와 RAG는 적이 아니라 서로 보완하는 계층이다.
중요도가 높아지면 리뷰를 넣는다. 개인 메모는 자동 저장해도 되지만, 팀의 공식 지식은 승인 절차가 필요하다.
민감도가 높아지면 권한을 나눈다. AI에게도 최소 권한만 준다.
오래 쓰려면 lint를 습관화한다. 위키는 작성보다 유지가 어렵다. 주간 lint, 월간 synthesis, 분기별 archive가 필요하다.
LLM Wiki의 핵심은 AI가 모든 것을 알아서 하게 만드는 것이 아니다. 인간이 지식의 방향을 정하고, AI가 반복 유지보수를 맡고, 시스템이 그 과정을 검증 가능하게 만드는 것이다.
미래의 지식 운영체제는 아마 하나의 앱으로 완성되지 않을 것이다. Markdown 파일, 로컬 검색, 에이전트 메모리, RAG, 지식 그래프, 권한 시스템, 감사 로그가 서로 연결된 형태가 될 가능성이 높다.
우리가 지금 만드는 LLM Wiki는 그 미래의 작은 버전이다. 작지만 충분히 실용적이고, 단순하지만 확장 가능하다. 그리고 무엇보다 중요한 점이 있다. 오늘 만든 한 페이지가 내일의 질문을 더 똑똑하게 만든다.
그것이 LLM Wiki의 가능성이자, 우리가 조심스럽게 다뤄야 할 힘이다.
참고
1Andrej Karpathy의 llm-wiki Gist
2OWASP LLM06: Sensitive Information Disclosure
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.