LLM Wiki를 잘 쓰는 사람은 무엇을 저장하지 않을지 먼저 정한다

LLM Wiki를 처음 접하면 설치보다 먼저 막히는 지점이 있다. ingest하라는 말은 쉬운데 무엇을 넣어야 하는지는 모호하다. 읽어 둔 글을 전부 넣으면 두 번째 뇌가 될 것 같다가도, 출처가 불분명한 글과 오래된 문서가 섞이면 오히려 답의 수준이 낮아질 것 같다. 하나의 범용 Wiki를 키워야 하는지, 프로젝트마다 새로 만들어야 하는지도 애매하다.

이번 조사에서 도출되는 결론은 단순하다. LLM Wiki를 잘 쓰는 사람은 많이 저장하는 사람이 아니라, 어떤 자료를 어떤 질문을 위해 지식으로 승격할지 결정하는 편집자에 가깝다.

좋은 LLM Wiki는 모든 것을 기억하는 창고가 아니다. 반복해서 묻는 영역에서 검증된 원문을 요약하고 연결하되, 언제든 원문으로 되돌아갈 수 있게 만든 버전 관리형 파생 캐시다.

먼저, LLM Wiki는 제품 이름이 아니다

여기서 말하는 LLM Wiki는 2026년 4월 Andrej Karpathy가 공개한 아이디어 문서에서 출발한 패턴을 뜻한다. 같은 이름을 쓰는 프로그램과 플러그인이 여럿 있지만 하나의 표준 제품이나 확정된 사양은 아니다.

원문의 구조는 세 층으로 나뉜다.

사람이 고른 불변 원문
LLM이 원문을 요약·연결·갱신하는 Markdown Wiki
페이지 구조와 ingest·query·lint 절차를 정한 스키마

보통의 RAG는 질문이 들어올 때 원문 조각을 검색해 답을 합성한다. LLM Wiki는 그 앞에 한 단계를 더 둔다. 자료를 넣을 때 원문을 읽고, 개념 페이지와 출처 요약을 갱신하고, 기존 주장과의 충돌까지 기록한다. 나중에는 이 파생 Wiki를 검색한다.

그렇다고 LLM Wiki가 RAG의 반대이거나 대체재인 것은 아니다. 질문에 맞는 Wiki 페이지를 고르는 과정에도 검색이 필요하다. 더 정확한 설명은 ingest 시점의 지식 합성에 query 시점의 검색을 결합한 방식이다. RAG의 원래 연구가 외부 비모수 기억을 검색해 생성에 연결했다면, LLM Wiki는 검색 대상 사이에 사람이 읽고 고칠 수 있는 합성층을 추가한다.

아무거나 넣으면 Wiki의 수준이 낮아질까

조건부로 맞다. 다만 문제는 자료가 많다는 사실 자체가 아니다. 검증되지 않은 파생 주장이 출처·날짜·권한 정보 없이 사실처럼 승격되고, 다음 답변에서 다시 근거로 사용되는 순간 품질이 낮아진다.

여기서는 두 종류의 오염을 구분해야 한다.

저장 오염: 중복 문서, 오래된 결정, 출처 없는 AI 답변, 광고성 자료가 같은 신뢰도로 Wiki에 합쳐지는 문제
검색 오염: 질문과 비슷해 보이지만 답에 도움이 되지 않는 문서나 잘못된 버전이 실제 프롬프트에 들어오는 문제

연구에서도 단순한 “자료가 많을수록 좋다”는 결론은 지지되지 않는다. 전체 길이와 관련 정보의 위치를 고정해도 문서 수가 늘자 대부분의 평가 모델에서 성능이 하락했다는 다중 문서 연구가 있다. 또 다른 장문맥 연구에서는 관련 근거를 완벽히 찾은 조건에서도 입력 길이 자체가 늘면 성능이 떨어질 수 있었다. 다만 Qwen2처럼 문서 수 증가에 견고한 예외도 있어 결과는 모델과 과제에 따라 달랐다. 결국 품질을 결정하는 것은 저장량 하나가 아니라 원문 신뢰도, 합성의 충실도, 검색의 정밀도, 갱신 규칙의 조합이다.

보안 문제도 있다. PoisonedRAG 연구는 외부 지식 저장소가 공격 표면이 될 수 있음을 보였다. 이 결과를 개인 Wiki의 일상적인 오류율로 일반화할 수는 없지만, 큰 저장소라면 악성 문서 몇 개쯤은 자연스럽게 희석될 것이라는 가정은 위험하다. 웹페이지와 메일, 채팅에 들어 있는 명령문은 지식 후보일 뿐 에이전트가 따라야 할 지시가 아니다.

따라서 원문 저장소는 비교적 넓게 가져가도 된다. 대신 Wiki로의 승격은 좁아야 한다. 원문은 증거이고 Wiki는 그 증거를 편집한 결과다. Wiki 페이지가 다른 Wiki 페이지의 유일한 근거가 되는 순환을 피하고, 중요한 주장은 항상 원문까지 추적되어야 한다.

공개 사례에서 얻을 수 있는 운영 원칙

LLM Wiki는 등장한 지 오래되지 않았다. 장기간 사용자 집단을 비교한 연구는 아직 찾기 어렵고, 구체적인 성공담 대부분은 제작자나 커뮤니티의 자기 보고다. 그러므로 “누가 잘 쓴다”를 직업이나 유명인으로 정의하기보다 반복해서 관찰되는 행동으로 정의하는 편이 안전하다.

반복할 질문을 먼저 정한다

좋은 사용자는 “내가 가진 파일을 모두 넣겠다”보다 “앞으로 어떤 결정을 반복할 것인가”에서 시작한다. 프로젝트의 설계 결정과 변경 이유를 다시 찾아야 하는가, 논문 여러 편의 주장을 계속 비교해야 하는가, 회의 전에 사람과 과거 합의 사항을 확인해야 하는가를 먼저 정한다.

Wiki는 소비하는 흐름이 있을 때 가치가 생긴다. 공개된 사용자 토론에서는 프로젝트 계획과 설계 결정의 이력을 추적하거나, 업무 메일·일정·회의 기록으로 아침 브리핑을 만들거나, 매 세션을 Wiki 검색으로 시작한다는 사례가 나온다. 반대로 만들어 놓고 검색하는 습관이 없으면 Wiki는 존재하지만 실무에서는 없는 것과 같았다는 보고도 있다.

다른 커뮤니티 토론에는 LLM이 만든 오류 때문에 저장소 전체를 신뢰하기 어려워졌다는 경험과, 자동 ingest가 거의 다시 읽지 않는 파일만 늘렸다는 비판이 있다. 기존의 읽기·기록 습관을 확장하는 방식이라면 유용했다는 의견, 직접 요약하고 연결하는 과정 자체가 학습이므로 자동화가 그 가치를 없앨 수 있다는 반론도 함께 나온다. 이 사례들은 모두 익명의 자기선택형 자기보고다. 무엇이 효과적인지 비교한 사용자 연구가 아니라, 실험할 때 확인할 가설을 제공하는 정도로 읽어야 한다.

초반에는 자료를 하나씩 넣고 diff를 본다

Karpathy는 자신이 한 번에 한 자료를 ingest하면서 요약과 변경된 페이지를 읽고, 무엇을 강조할지 알려 주는 방식을 선호한다고 썼다. 이 방법이 영원히 가장 효율적이라는 뜻은 아니다. 스키마가 아직 안정되지 않은 초반에 어떤 종류의 오류가 생기는지 배우기 좋다는 뜻에 가깝다.

첫 자료 열 개에서 만들어진 페이지를 거의 읽지 않는다면, 백 개를 한꺼번에 넣을 이유도 없다. 자동화를 늘리는 시점은 사람이 검토할 기준이 생긴 뒤다.

원문과 파생 지식을 섞지 않는다

원 제안처럼 원문은 수정하지 않는 층에 보존한다. Wiki에는 출처 추적과 접근 제어를 위해 다음과 같은 운영 메타데이터를 남길 수 있다. 이는 보편 표준이 아니라 이 글의 권장안이며, OWASP의 RAG 보안 지침도 출처, 문서 해시, 권한 메타데이터와 격리를 권한다.

원문 경로 또는 URL
작성자와 작성·갱신 시점
적용되는 프로젝트와 권한
주장 상태와 신뢰 수준
대체한 문서와 대체된 문서
마지막 검토일

LLM이 만든 요약도 새로운 오류면이다. 합성된 문장은 편리하지만 원문보다 권위가 높지 않다. 중요한 판단에서는 Wiki가 답한 문장만 읽지 말고 연결된 원문을 확인해야 한다.

좋은 답은 제안 상태를 거쳐 지식으로 만든다

Karpathy는 유용한 답을 다시 Wiki에 저장해 탐색 결과를 누적하자고 제안한다. 다만 품질을 우선한다면 답을 즉시 확정 지식으로 넣기보다 제안 상태에 두고, 원문 연결과 재사용 가능성을 확인한 뒤 승격하는 안전장치를 추가할 수 있다. 근거가 부족하면 “모른다”를 남기고, 서로 충돌하는 원문은 모델이 임의로 승자를 고르지 않게 한다. 앞 문장은 원 제안의 사용법이고, 뒤의 검토 단계는 이 글이 덧붙이는 운영상 권고다.

Wiki가 커질수록 lint와 평가의 비중도 커진다

Wiki가 커질수록 추가뿐 아니라 유지보수의 비중도 커진다. 중복 페이지, 고립된 페이지, 깨진 링크, 구버전 주장, 미해결 충돌, 권한 변경을 주기적으로 찾는다. 검색기와 생성기를 나눠 진단해야 한다는 RAGChecker 연구의 관점도 도움이 된다. 필요한 원문을 찾지 못한 문제와, 원문을 찾았지만 잘못 요약한 문제는 해결 방법이 다르다.

내가 운영 중인 Wiki를 점검해보니

나도 Obsidian에서 Karpathy의 제안에 가까운 LLM Wiki를 운영하고 있다. 2026년 8월 12일 기준으로 원문을 보존하는 raw, LLM이 만든 개념·엔티티·질문·종합 페이지, 전체 색인, 작업 로그, 에이전트 운영 규칙을 분리해 두었다. 전체 규모는 Markdown 29개, 그중 파생 Wiki 페이지는 15개다.

구조만 보면 앞에서 정리한 원칙과 꽤 가깝다. 15개 파생 페이지에는 유형, 상태, 생성·갱신일, 출처, 태그가 있고 모두 색인에 연결되어 있다. 사람이 쓴 원문을 고치지 않는 규칙, 새 페이지보다 기존 페이지를 갱신하는 규칙, ingest·query·lint·maintenance를 로그에 남기는 규칙도 있다.

하지만 실제 기록은 다른 질문을 던졌다. 초기 설정 이후 여덟 번의 ingest가 있었지만 query, lint, maintenance 기록은 아직 없었다. 다만 이 점검이 확인한 것은 로그에 남은 이력뿐이며, 기록하지 않은 검색이나 점검이 있었을 가능성은 배제할 수 없다. 페이지 상태도 draft, active, reviewed, todo로 나뉘어 있으나 무엇을 통과하면 승격되는지 명시적인 기준은 없었다. 링크 점검에서는 아직 만들어지지 않은 개념을 가리키는 링크도 두 종류 발견됐다. 구조를 갖춘 것과 반복해서 잘 쓰는 것은 별개의 단계였다.

출처가 짧을 때 생기는 문제도 보였다. ‘나중에 조사할 것’에 가까운 짧은 원문 하나가 외부 자료를 더해 긴 개념 페이지와 종합 페이지로 확장되어 있었다. 원문의 의도가 불확실하다는 표시와 열린 질문을 남긴 점은 좋았다. 반면 종합 페이지의 일부 설명은 외부 원문이 아니라 한 단계 앞의 파생 개념 페이지를 통해서만 추적됐다. 파생 문서가 파생 문서의 근거가 되기 시작하면 편리함과 함께 손실도 누적된다.

이 작은 점검만으로 LLM Wiki가 효과적이거나 실패했다고 결론 내릴 수는 없다. 아직은 지식을 넣는 흐름을 만든 초기 상태에 가깝다. 다음 단계는 자료를 더 넣는 일이 아니라, 실제로 반복할 질문을 등록하고 query와 lint를 기록해 어떤 페이지가 재사용되는지 확인하는 일이다.

무엇을 ingest하고 무엇을 다른 곳에 둘까

다음 표는 보편 법칙이 아니라 시작점이다.

자료	권장 위치와 처리
반복해서 물을 공식 문서, 논문, 확정된 결정, 포스트모템	불변 원문으로 저장하고 검토 후 Wiki에 반영한다.
읽지 않은 링크, 출처 후보, 아이디어, 열린 질문	inbox나 후보 목록에 둔다. 아직 지식으로 승격하지 않는다.
현재 대화, 임시 작업 상태, 오늘의 할 일	세션 또는 작업 메모에 둔다. 자동으로 장기 지식이 되지 않게 한다.
사용자 선호, 에이전트 행동 규칙, 도구 사용법	에이전트 장기 기억(agent memory), `AGENTS.md`, skill 같은 운영 계층에 둔다.
대형 로그, 전체 코드 저장소, 자주 변하는 데이터	복사본보다 위치·버전·조회 방법을 담은 목록 파일(manifest)을 두고 원 시스템을 실시간 조회한다.
AI가 생성한 답변	원문 근거가 연결되고 사람이 검토하기 전에는 증거로 쓰지 않는다.
중복 문서나 새 버전이 나온 문서	해시로 중복을 찾고 이전 주장을 `대체됨(superseded)` 또는 재검토 상태로 바꾼다.
개인정보, 비밀, 권한이 다른 문서	기본적으로 제외한다. 필요하면 별도 공간과 검색 시점 권한 검사를 먼저 설계한다.

“나중에 볼지도 모른다”만으로는 ingest 이유가 약하다. 다음 네 질문에 대부분 답할 수 있을 때 Wiki 후보가 된다.

반복해서 묻거나 결정할 때 다시 필요한가?
원본·작성자·시점을 확인할 수 있는가?
기존 지식을 갱신하거나 반박하거나 연결하는가?
잘못 요약됐을 때 원문으로 되돌아갈 수 있는가?

범용 Wiki 하나와 프로젝트별 Wiki 사이

직접 비교한 실증 연구가 부족하므로 “프로젝트별 Wiki가 항상 낫다”고 말할 근거는 없다. 분리 기준은 프로젝트 이름보다 다음에 가깝다.

접근 권한이 다른가
갱신·보존 주기가 다른가
같은 용어가 서로 다른 의미로 쓰이는가
권위 있는 원천(source of truth)이 다른가
별도의 대표 질문과 평가 기준이 필요한가

권한 경계가 다르면 별도 저장소·인덱스 또는 테넌트 격리처럼 접근 제어가 구조적으로 강제되는 경계를 둔다. 한 인덱스를 공유한다면 문서별 접근 권한(ACL) 메타데이터를 ingest하고 질의 시점에 권한 정보가 없을 때 차단하는 방식으로 필터링해야 한다. OWASP의 RAG 보안 지침과 Azure의 문서별 접근 제어는 이 두 접근을 구체화한다. 권한은 같지만 주제만 다르면 하나의 저장소 안에서 이름공간(namespace)과 메타데이터로 기본 검색 범위를 제한할 수도 있다. LangGraph의 장기 기억도 계층형 namespace로 기억의 범위를 구분한다.

현실적인 구조는 하나의 거대한 범용 Wiki도, 완전히 고립된 프로젝트 Wiki의 복제도 아니다.

공통 허브
├─ 여러 작업에서 재사용하는 검증된 개념과 출처
├─ 프로젝트 A: 결정, 문서, 용어, 평가 질문
├─ 프로젝트 B: 결정, 문서, 용어, 평가 질문
└─ 민감 영역: 별도 권한과 보존 정책

세션/작업 메모
└─ 현재 상태와 임시 기록 — 검토 없이 허브로 승격하지 않음

공통 영역에는 안정적이고 재사용되는 지식만 올린다. 프로젝트 공간은 해당 프로젝트의 용어와 결정, 빠르게 변하는 상태를 가진다. 둘을 연결하되 같은 내용을 복사해 여러 버전으로 만들지는 않는다.

기억 계층은 단계가 아니라 역할 구분이다

기억 계층이라는 말은 성숙도 사다리를 뜻하지 않는다. 에이전트 연구와 실제 시스템에서 계층은 대체로 정보의 역할, 수명, 접근 방법을 분리하는 설계에 가깝다.

CoALA는 작업·일화·의미·절차 기억을 구분하고, MemGPT는 제한된 활성 컨텍스트와 외부 저장소 사이의 계층적 이동을 다룬다. OpenAI의 사내 데이터 에이전트는 테이블 사용 정보, 인간 주석, 코드 기반 보강, 조직 지식, 기억, 실행 시점 문맥이라는 여섯 층을 사용한다. 숫자와 이름이 다른 이유는 하나의 표준 단계를 따르기보다 각 시스템이 풀어야 할 문제에 맞춰 경계를 정하기 때문이다.

내 Wiki를 이 관점으로 보면 다음처럼 해석할 수 있다.

원문과 파생 지식, 작업 기록, 운영 규칙, 현재 문맥을 역할별 기억 계층으로 분리한 구조

기억 역할	현재 Wiki에서 대응하는 위치	하는 일
원문·아티팩트 기억	`raw/`	사람이 넣은 문서와 첨부파일을 보존하고 최종 추적 지점을 제공한다.
의미 기억	`wiki/concepts/`, `entities/`, `syntheses/`, `questions/`	여러 원문에서 재사용할 개념과 답을 요약·연결한다.
일화 기억	`log.md`	어떤 ingest·query·점검이 언제 일어났는지 남긴다.
절차 기억	`AGENTS.md`	원문을 고치지 않는 법, 페이지를 작성·연결하고 점검하는 법을 정한다.
작업 기억	현재 대화와 모델 컨텍스트	지금 질문에 필요한 일부 정보만 불러와 추론한다.

이들은 위아래 우열이 있는 단계가 아니다. 작업 기억이 원문보다 ‘높은 기억’인 것도 아니고, 모든 정보를 의미 기억으로 승격해야 하는 것도 아니다. 중요한 것은 각 정보에 대해 다음 네 질문에 답할 수 있는가다.

무엇이 원본이며 권위를 가지는가?
무엇을 장기적인 파생 지식으로 남길 것인가?
누구와 어떤 프로젝트까지 공유할 것인가?
지금 이 질문을 위해 모델 문맥에 무엇을 넣을 것인가?

LLM Wiki는 주로 두 번째 질문을 다룬다. 현재 세션 상태나 에이전트 행동 규칙까지 모두 Wiki 본문에 넣는 순간 역할이 다시 뒤섞인다. 기억 계층의 가치는 층수가 아니라, 필요한 정보를 필요한 시점에 올바른 경계에서 꺼낼 수 있다는 데 있다.

무한 컨텍스트가 오면 필요 없어질까

“입력할 수 있다”와 “정확하게 찾아 쓰고, 계속 최신이며, 싸게 운영된다”는 서로 다른 조건이다.

Lost in the Middle과 RULER는 명목상 긴 컨텍스트가 모든 위치와 관계를 안정적으로 활용한다는 뜻이 아님을 보여 주었다. 다만 이 결과는 주로 2024년 전후 모델을 평가했으므로 미래 모델에 그대로 적용해서는 안 된다. 반대쪽 근거도 있다. RAG와 장문맥을 비교한 연구에서는 자원이 충분할 때 장문맥 방식이 평균 성능에서 우세했고, RAG는 비용 면에서 이점이 있어 질의별 라우팅을 제안했다.

따라서 “컨텍스트가 커져도 Wiki는 반드시 남는다”는 결론도 성급하다. 모델이 모든 원문을 저렴하게 읽고, 필요한 근거를 완벽하게 선택하고, 세션을 넘어 영속적으로 유지하며, 최신성·권한·삭제·출처까지 관리한다면 손실이 있는 중간 합성층은 불필요하거나 오히려 방해가 될 수 있다.

하지만 컨텍스트 길이만 늘어나는 경우라면 이야기가 다르다. 용량은 다음 문제를 자동으로 해결하지 않는다.

세션과 모델을 넘는 지속성
최신 문서와 폐기된 문서의 구분
원문, 추론, 의견의 출처 관계
접근 권한과 삭제·보존 정책
변경 이력과 사람이 고칠 수 있는 표현
같은 자료를 매번 다시 읽는 비용과 지연

현재로서는 한 가지 방식에 모든 질문을 맡기기보다 라우팅하는 편이 합리적이다.

한 번만 묻고 원문 충실성이 중요한 질문: 원문 검색 또는 장문맥
여러 문서를 반복해서 비교하고 종합하는 질문: LLM Wiki
항상 변하는 운영 데이터: 원 시스템에 실시간 질의
엄격한 엔티티 관계나 전체 주제 구조: 필요할 때 지식 그래프
중요한 판단: 어느 방식이든 원문 확인

범용 Wiki보다 먼저 작은 실험을 만든다

처음부터 인생 전체를 ingest할 필요는 없다. 작은 실험의 시작값으로 다음 구성을 제안할 수 있다. 연구가 정한 최적 수치가 아니라 실패 비용을 낮추기 위한 실험 설계다.

실제로 반복 질문이 있는 주제 하나를 고른다.
신뢰할 수 있는 원문 10~20개와 대표 질문 약 10개를 준비한다.
초반 자료는 하나씩 ingest하고 페이지 변경과 인용을 검토한다.
각 주장에 출처, 날짜, 적용 범위, 상태를 남긴다.
같은 질문을 원문 검색·장문맥과 Wiki에 각각 물어본다.
정답뿐 아니라 인용 정확성, 근거 부족 시 거절, 최신 버전 사용, 비용, 검토 시간을 기록한다.
반복 사용에서 이득이 확인될 때만 자료와 자동화를 늘린다.

이 실험에서 중요한 지표는 페이지 수가 아니다. 같은 질문에 다시 답할 때 시간이 줄었는지, 답이 원문에 충실한지, 잘못된 주장을 찾아 고치기 쉬운지다. 한 번의 ingest 비용이 여러 번의 재사용으로 상각되지 않는다면 Wiki로 만들 이유가 약하다.

기억보다 편집이 먼저다

LLM Wiki의 매력은 모델이 나 대신 모든 것을 기억해 준다는 데 있지 않다. 사람이 미뤄 온 요약, 연결, 갱신, 기록 작업을 모델과 나눌 수 있다는 데 있다. 동시에 LLM이 작성한 Wiki는 원문이 아니라 해석된 결과이며, 잘못된 해석도 복리처럼 쌓일 수 있다.

잘 쓰는 사람은 그래서 무엇을 넣을지만 결정하지 않는다. 무엇을 넣지 않을지, 무엇을 아직 지식으로 인정하지 않을지, 언제 원문으로 돌아갈지까지 정한다.

LLM Wiki는 기억 장치이기 전에 편집 시스템이다.