AI가 관리하는 위키는 왜 쉽게 썩는가

전에 LLM Wiki: RAG 이후의 지식관리 방식이라는 글을 썼다. 그 글에서는 Andrej Karpathy가 제안한 LLM Wiki를 꽤 긍정적으로 봤다.¹ 핵심은 이랬다.

RAG가 질문할 때마다 원문을 다시 검색하는 방식이라면, LLM Wiki는 LLM이 원문을 읽고 요약하고 연결하고 갱신한 지속형 지식베이스를 유지하는 방식이다.

이 관점은 여전히 맞다고 생각한다. 특히 개인 연구, 블로그, 컨설팅 메모, 프로젝트 기록처럼 시간이 지나며 맥락이 쌓이는 작업에서는 꽤 강력하다. 질문하고 사라지는 대화창보다, 마크다운 파일로 남는 지식 구조가 훨씬 오래 간다.

그런데 바로 그 이유 때문에 위험하기도 하다.

LLM Wiki의 문제는 위키를 못 만든다는 데 있지 않다. 오히려 너무 쉽게 만든다는 데 있다. 페이지가 생기고, 링크가 붙고, 요약이 쌓이면 지식이 축적되는 것처럼 보인다. 하지만 출처, 갱신, 망각, 검증, 모순 관리가 없으면 그것은 지식베이스가 아니라 그럴듯한 디지털 쓰레기장이 된다.

그래서 이 글은 LLM Wiki에 대한 반대가 아니다. 오히려 제대로 쓰기 위한 경고에 가깝다.

AI가 관리하는 위키는 왜 쉽게 썩는가?
그리고 사람이 넣어야 할 방부제는 무엇인가?

위키는 자란다. 동시에 썩는다

LLM Wiki를 처음 만들면 꽤 인상적이다. PDF를 넣으면 요약 페이지가 생긴다. 회의록을 넣으면 쟁점이 정리된다. 비슷한 개념끼리 링크가 생기고, index.md가 업데이트되고, Obsidian graph view에는 점과 선이 늘어난다.

처음 며칠은 정말 “지식이 자라는” 느낌이 든다.

문제는 4주차부터다.

파일은 쌓인다. 일부 페이지는 낡는다. 같은 주제를 다루는 페이지가 두 개 생긴다. 어떤 용어는 한국어로, 어떤 용어는 영어로 남는다. 예전 문서의 수치가 새 문서와 충돌한다. index는 실제 파일 구조와 조금씩 어긋난다. LLM은 예전 요약을 다시 읽고, 그 요약을 바탕으로 또 다른 요약을 만든다.

겉으로는 위키가 커진다. 하지만 안에서는 다른 일이 벌어진다.

• 낡은 정보가 최신 정보처럼 남는다.
• 추측이 사실처럼 굳는다.
• 오류가 여러 페이지에 복제된다.
• 모순이 질문으로 남지 않고 매끄러운 문장으로 봉합된다.
• 링크가 너무 많아져서 어떤 연결도 중요하지 않게 된다.

이 상태가 되면 LLM Wiki는 “생각을 돕는 구조”가 아니라 “그럴듯한 문서 더미”가 된다. Medium의 한 실사용기는 LLM Wiki에 대한 반응이 두 진영으로 갈렸다고 정리한다. 한쪽은 brilliant라고 했고, 다른 한쪽은 “glorified markdown graveyard that can’t scale”이라고 불렀다.²

표현은 거칠지만 핵심은 맞다. 위키는 관리되지 않으면 지식의 정원이 아니라 마크다운 묘지가 된다.

첫 번째 부패: 추측이 사실처럼 굳는다

AI가 만든 위키에서 가장 위험한 것은 명백한 오류가 아니다. 명백한 오류는 오히려 찾기 쉽다. 더 위험한 것은 그럴듯한 추측이다.

예를 들어 어떤 프로젝트 문서에서 “Redis를 캐시로 쓰는 것 같다”는 문장이 있었다고 하자. LLM이 이것을 읽고 프로젝트 X 아키텍처.md에 이렇게 정리한다.

프로젝트 X는 Redis를 캐시 계층으로 사용한다.

처음에는 작은 정리 오류다. 그런데 이 문장이 다음 질의에서 다시 검색된다. 다른 페이지에도 연결된다. 운영 이슈 분석에도 인용된다. 어느 순간 이 문장은 “출처가 약한 추측”이 아니라 “위키에 있는 사실”이 된다.

LLM Wiki v2 글은 이 문제를 “conjectures solidify into facts”, 즉 추측이 사실로 굳는 문제로 설명한다.³ 더 무서운 점은 이것이 자기강화한다는 것이다. 초기에 들어간 추측이 이후의 답변 근거가 되고, 이후 답변이 다시 위키에 남으면, 시스템은 자기 추측을 자기 근거로 삼기 시작한다.

이건 단순한 hallucination보다 더 귀찮다. hallucination은 한 번의 답변에서 끝날 수 있다. 하지만 위키에 기록된 hallucination은 다음 답변의 재료가 된다.

즉, LLM Wiki에서는 오류도 축적된다.

두 번째 부패: 오류가 링크를 타고 퍼진다

일반 문서에서 틀린 수치가 하나 있으면 그 문서 하나를 고치면 된다. 하지만 LLM Wiki에서는 이야기가 달라진다.

LLM은 한 문서의 내용을 여러 페이지에 나눠 반영한다. 개념 페이지, 기관 페이지, 비교표, 요약 페이지, 타임라인에 같은 정보가 다른 형태로 들어간다. 처음에는 장점이다. 지식이 연결되기 때문이다.

하지만 틀린 정보도 똑같이 연결된다.

AFFiNE의 LLM Wiki 소개글은 이 문제를 “hallucination contamination”으로 설명한다. 오래된 통계 하나가 여러 topic page와 entity page에 엮인 뒤, 나중에 새 자료가 들어와도 일부 페이지만 고쳐지고 나머지는 그대로 남을 수 있다는 것이다.⁴

더 위험한 경우도 있다. LLM이 오래된 수치와 새 수치를 보고 “둘 중 하나가 틀렸다”고 표시하는 대신, 그럴듯하게 둘을 화해시키는 설명을 만들어낼 수 있다. LLM은 데이터베이스 제약조건처럼 모순을 멈추지 않는다. 문장을 매끄럽게 이어 붙인다.

연구나 컨설팅에서는 이게 치명적이다. 모순은 지워야 할 노이즈가 아니라 새 질문의 출발점일 수 있다. 그런데 LLM은 모순을 질문으로 남기기보다, 종종 자연스러운 종합으로 덮는다.

좋은 글처럼 보이지만, 나쁜 지식관리다.

세 번째 부패: 위키가 망각하지 않는다

사람의 기억은 불완전하지만, 그래서 유용한 면도 있다. 중요하지 않은 것은 흐려진다. 반복해서 확인한 것은 남는다. 오래된 정보는 조심스럽게 다룬다.

반대로 나쁜 LLM Wiki는 모든 정보를 평평하게 저장한다.

• 어제 확인한 사실
• 6개월 전 회의에서 나온 임시 의견
• 한 번 언급된 추측
• 여러 출처가 반복 확인한 패턴
• 폐기된 결정
• 아직 검증되지 않은 가설

이것들이 같은 폴더 안에서 비슷한 무게로 존재한다. 파일로 남아 있다는 이유만으로 계속 검색되고, 계속 답변에 섞인다.

LLM Wiki v2가 제안하는 중요한 보완점이 바로 memory lifecycle이다.³ 지식에는 수명이 있다. 어떤 정보는 오래 가고, 어떤 정보는 빨리 썩는다. 어떤 주장은 새 출처가 나오면 약해져야 하고, 어떤 패턴은 여러 번 반복될수록 강해져야 한다.

즉 좋은 위키에는 축적만 필요한 것이 아니다. 망각도 필요하다.

망각이 없는 지식베이스는 똑똑해지는 것이 아니라 무거워진다. 결국 오래된 문장, 임시 판단, 폐기된 맥락이 새 판단을 방해한다.

네 번째 부패: 링크가 너무 많아진다

LLM은 링크를 잘 만든다. 그런데 너무 잘 만드는 것도 문제다.

모든 명사에 링크가 붙으면 아무 링크도 중요하지 않다. 모든 개념이 노드가 되면 그래프는 지도가 아니라 털뭉치가 된다. graph view는 멋있지만, 실제 탐색에는 도움이 안 된다.

좋은 링크는 “나중에 다시 생각할 가치가 있는 연결”이어야 한다. 단순히 단어가 등장했다는 이유만으로 링크를 만들면 안 된다.

이건 내 Digital Garden 운영에서도 계속 신경 쓰는 부분이다. 위키링크는 많을수록 좋은 게 아니라, 다시 읽을 때 사고의 경로를 열어주는 만큼만 있어야 한다. 좋은 정원은 모든 씨앗을 다 심은 곳이 아니라, 자랄 만한 것만 남긴 곳이다.

LLM에게 링크 생성을 맡길수록 사람의 선택 기준이 더 중요해진다.

다섯 번째 부패: 유지보수 비용이 사라지는 게 아니라 숨어든다

LLM Wiki를 “자동 지식관리”라고 부르면 매력적이다. 하지만 엄밀히 말하면 자동이 아니다. 자동화된 초안 생성과 자동화된 유지보수 보조에 가깝다.

AFFiNE 글은 데모와 production의 간극을 이렇게 설명한다. 주말에 몇 개 문서를 넣고 질문하면 멋진 답이 나온다. 문제는 4주차다. 파일 hygiene이 조용히 나빠지고, naming convention이 drift하고, index가 실제 구조와 어긋나고, 중복 페이지가 생긴다.⁴

이걸 막으려면 lint가 필요하다.

• 고립된 페이지가 있는가?
• 중복 개념이 있는가?
• 출처 없는 주장이 있는가?
• 오래된 주장이 최신 글에 끼어들었는가?
• 같은 개념이 다른 이름으로 흩어졌는가?
• 깨진 위키링크가 있는가?
• 서로 모순되는 주장이 있는가?

그런데 lint도 공짜가 아니다. 규칙을 만들어야 하고, 실행해야 하고, 결과를 사람이 봐야 한다. LLM Wiki는 유지보수 비용을 없애지 않는다. 유지보수 비용의 형태를 바꾼다.

그래서 중요한 질문은 “AI가 다 관리해줄까?”가 아니다.

사람의 유지보수 시간을 어디에 써야 가장 효과적인가?

이 질문으로 바꿔야 한다.

사람이 넣어야 할 방부제 1: 원문은 절대 훼손하지 않는다

첫 번째 방부제는 raw source 보존이다.

LLM이 만든 요약은 언제든 틀릴 수 있다. 하지만 원문이 남아 있으면 돌아갈 수 있다. PDF, 기사, 회의록, 인터뷰 원문, 데이터 파일, 캡처, 링크, 날짜가 남아 있으면 위키가 썩었는지 확인할 수 있다.

규칙은 단순하다.

LLM은 원문을 읽을 수는 있지만, 원문을 고치면 안 된다.

위키 페이지는 가공물이다. 원문은 source of truth다. 이 둘이 섞이면 끝이다. LLM이 요약한 문장이 어느 순간 원문처럼 취급되기 시작하면 위키는 빠르게 오염된다.

그래서 모든 중요한 주장에는 최소한 다음 정보가 붙어야 한다.

항목	의미
출처	어떤 원문에서 왔는가
날짜	언제 확인된 정보인가
상태	사실, 추론, 가설, 의견 중 무엇인가
범위	어느 조직/문서/상황에만 적용되는가
갱신 필요성	언제 다시 확인해야 하는가

이 다섯 가지가 없으면, 지식이 아니라 문장이다.

사람이 넣어야 할 방부제 2: 사실과 추론을 분리한다

LLM Wiki가 썩는 가장 빠른 길은 사실, 추론, 가설, 의견을 같은 문체로 쓰는 것이다.

나쁜 예:

A대학은 지역산업 연계를 핵심 성장전략으로 삼고 있다.

좋은 예:

2026년 RISE 계획서에서 A대학은 지역 바이오산업 연계 사업을 핵심 과제로 제시했다. 따라서 현재 공개자료 기준으로는 지역산업 연계를 성장전략의 한 축으로 해석할 수 있다.

두 문장의 차이는 크다. 첫 문장은 단정이다. 둘째 문장은 출처, 시점, 해석 범위를 남긴다.

LLM Wiki v2에서 말하는 epistemic layer가 바로 이런 것이다.³ 위키 안의 문장은 모두 같은 지위가 아니다.

• fact: 출처로 직접 확인되는 사실
• verified inference: 여러 근거로 지지되는 해석
• hypothesis: 아직 검증이 필요한 가설
• speculation: 가능성 수준의 추정
• opinion: 작성자의 판단

이 상태값이 없으면, 위키는 시간이 지날수록 단정문으로 가득 찬다. 그리고 단정문은 검색될 때마다 더 강해진다.

사람이 해야 할 일은 모든 문장을 직접 쓰는 것이 아니다. 중요한 문장의 지위를 정해주는 것이다.

사람이 넣어야 할 방부제 3: 모순을 지우지 말고 보존한다

LLM은 모순을 싫어한다. 사람도 대체로 그렇다. 그래서 LLM에게 “정리해줘”라고 하면 서로 다른 주장을 하나의 매끄러운 문단으로 합쳐버리기 쉽다.

하지만 지식관리에서 모순은 쓰레기가 아니다. 좋은 모순은 연구 과제다.

예를 들어 두 자료가 이렇게 말한다고 하자.

• 자료 A: “학령인구 감소로 지방대학은 통폐합 압력을 받을 것이다.”
• 자료 B: “RISE 이후 지방대학은 지역산업 거점으로 역할이 강화될 것이다.”

나쁜 LLM Wiki는 이것을 이렇게 합친다.

지방대학은 학령인구 감소 속에서도 지역산업 거점으로 전환하며 생존전략을 모색하고 있다.

문장은 자연스럽지만, 긴장이 사라졌다. 진짜 질문은 이것이다.

• 어떤 지방대학은 통폐합 압력을 받고, 어떤 지방대학은 거점이 되는가?
• 차이를 만드는 조건은 무엇인가?
• 지역산업, 재정지원, 거버넌스, 교육과정 중 무엇이 결정적인가?

모순을 없애면 질문도 사라진다.

그래서 좋은 LLM Wiki에는 conflicts.md 또는 open-questions.md 같은 공간이 필요하다. 서로 충돌하는 주장을 지우지 말고, 그대로 보존해야 한다. 사람은 그 모순을 보고 다음 읽을거리와 다음 글감을 정한다.

이게 방부제다. 모순은 부패가 아니라 발효가 될 수 있다.

사람이 넣어야 할 방부제 4: 주기적으로 잊게 만든다

위키가 지식베이스가 되려면 잘 기억해야 한다. 그런데 더 좋은 위키가 되려면 잘 잊어야 한다.

여기서 잊는다는 말은 삭제한다는 뜻이 아니다. 검색과 판단에서 가중치를 낮춘다는 뜻이다.

예를 들어 다음처럼 상태를 나눌 수 있다.

상태	처리 방식
active	현재 자주 쓰는 지식. 답변과 글감에 적극 사용
watch	아직 중요하지만 추가 확인 필요
stale	오래되어 최신성 확인 전까지 조심해서 사용
superseded	새 자료가 대체한 정보. 역사 기록으로만 보존
archive	검색 가능하지만 기본 답변에는 넣지 않음

이런 상태값이 없으면 2024년 회의 메모와 2026년 공식자료가 같은 목소리로 답변에 들어온다. LLM은 문체를 맞출 수는 있지만, 시간의 무게를 자동으로 이해하지 못한다.

사람은 위키의 기억을 편집해야 한다.

• 자주 쓰는 개념은 더 선명하게 만든다.
• 오래된 주장은 stale로 내린다.
• 새 자료가 대체한 정보는 superseded로 표시한다.
• 한 번 쓰고 끝난 자료는 archive로 보낸다.

좋은 위키는 모든 것을 보관하는 창고가 아니다. 지금 판단에 필요한 것이 앞에 오도록 정리된 작업대다.

사람이 넣어야 할 방부제 5: 링크에 세금을 매긴다

링크는 공짜처럼 보이지만 사실 비용이 있다. 링크가 많아질수록 독자의 주의가 분산되고, 그래프가 복잡해지고, LLM이 관련 없는 페이지를 끌어올 가능성도 커진다.

그래서 링크에는 세금을 매겨야 한다.

내가 쓰는 기준으로는 이렇다.

• 한 글에 핵심 위키링크는 5~12개 정도면 충분하다.
• 단순 명사에는 링크를 걸지 않는다.
• 나중에 독립 노트로 자랄 개념만 링크한다.
• 같은 개념의 다른 이름은 하나로 합친다.
• missing node는 실패가 아니라 작성 후보로 본다.
• 하지만 영원히 안 쓸 missing node는 정리한다.

LLM에게 “관련 개념을 모두 링크해줘”라고 하면 안 된다. 대신 이렇게 말해야 한다.

이 글을 다시 읽을 때 사고를 이어가게 만드는 핵심 개념만 링크해줘.

링크는 검색엔진용 장식이 아니라 사고의 경로다. 경로가 너무 많으면 길을 잃는다.

사람이 넣어야 할 방부제 6: 정기 검진을 자동화한다

사람이 모든 페이지를 매번 읽을 수는 없다. 그래서 정기 검진은 자동화해야 한다. 다만 자동화의 목적은 “AI가 알아서 고치게 하기”가 아니라 “사람이 봐야 할 이상 신호를 줄이는 것”이다.

LLM Wiki의 건강검진 항목은 대략 이렇게 잡을 수 있다.

검사	질문
broken link check	깨진 내부링크나 외부링크가 있는가
orphan note check	아무 글에서도 연결되지 않는 노트가 있는가
duplicate concept check	같은 개념이 여러 이름으로 흩어졌는가
stale claim check	오래된 날짜의 주장이 최신 글에서 쓰이고 있는가
source coverage check	중요한 주장에 출처가 붙어 있는가
conflict check	서로 충돌하는 주장이 있는가
link density check	한 글에 링크가 과도하게 많지 않은가

이 검진은 cron으로 돌릴 수 있다. 하지만 결과를 바로 반영하면 안 된다. AI가 제안하고 사람이 승인하는 구조가 좋다.

• AI: “이 두 페이지는 중복 개념일 가능성이 있습니다.”
• 사람: “합친다 / 유지한다 / 하나는 archive로 보낸다.”

이 정도의 human-in-the-loop가 없으면 LLM Wiki는 자동으로 건강해지는 것이 아니라 자동으로 자신감만 커진다.

사람이 넣어야 할 방부제 7: 편집장의 역할을 포기하지 않는다

결국 마지막 방부제는 사람이다.

이 말은 “사람이 다 해야 한다”는 뜻이 아니다. 오히려 반대다. LLM에게 많이 맡겨야 한다. 요약, 초안, 링크 후보, 중복 탐지, 출처 후보 정리, stale claim 후보 탐지는 LLM이 잘한다.

하지만 다음 결정은 사람이 해야 한다.

• 무엇을 중요한 개념으로 볼 것인가?
• 어떤 모순을 연구 질문으로 남길 것인가?
• 어떤 정보는 잊게 만들 것인가?
• 어떤 링크는 끊을 것인가?
• 어떤 추론을 공개 글로 승격할 것인가?
• 어떤 페이지는 디지털 쓰레기로 보고 버릴 것인가?

LLM은 위키의 관리인일 수 있다. 하지만 편집장은 사람이어야 한다.

Medium 실사용기에서도 결론은 비슷하다. AI가 제안하고 사람이 승인해야 한다. 유지보수가 0이 되는 것이 아니라, 유지보수의 부담이 크게 줄어드는 것으로 봐야 한다.²

나는 이 관점이 가장 현실적이라고 본다.

LLM Wiki를 썩지 않게 하는 운영 규칙

정리하면, LLM Wiki를 운영할 때 최소한 이런 규칙이 필요하다.

1. 원문은 immutable하게 보존한다.
2. LLM이 만든 wiki page와 raw source를 분리한다.
3. 중요한 주장에는 출처, 날짜, 상태, 범위를 붙인다.
4. fact / inference / hypothesis / opinion을 구분한다.
5. 모순은 지우지 말고 conflict note로 남긴다.
6. stale / superseded / archive 상태를 운영한다.
7. 링크는 선택적으로 건다.
8. 정기적으로 broken link, orphan note, duplicate concept를 점검한다.
9. AI의 수정은 제안으로 받고, 핵심 변경은 사람이 승인한다.
10. 위키의 목적을 “많은 노트”가 아니라 “다시 생각하기 좋은 구조”로 둔다.

이 규칙이 없으면 LLM Wiki는 빨리 커진다. 하지만 빨리 커지는 것과 좋아지는 것은 다르다.

결론: 방부제 없는 LLM Wiki는 지식이 아니라 부산물이다

LLM Wiki는 좋은 아이디어다. 나는 여전히 그렇게 생각한다. RAG처럼 매번 검색하고 답하는 방식에서 벗어나, 지식이 파일로 남고 연결되고 갱신되는 구조는 분명히 강력하다.

하지만 좋은 아이디어일수록 더 위험한 착각이 따라온다.

위키가 자동으로 만들어지면, 지식도 자동으로 축적될 것이다.

아니다. 자동으로 축적되는 것은 지식만이 아니다. 오류도 축적된다. 중복도 축적된다. 낡은 주장도 축적된다. 출처 없는 추론도 축적된다. 링크도 축적된다. 비용도 축적된다.

그래서 LLM Wiki의 핵심 질문은 “어떻게 더 많이 만들 것인가”가 아니다.

어떻게 덜 썩게 만들 것인가?

그 답은 결국 사람의 편집 행위에 있다. 원문을 보존하고, 사실과 추론을 나누고, 모순을 남기고, 오래된 정보를 낮추고, 링크를 선별하고, 정기적으로 검진하는 일.

이것이 AI가 관리하는 위키에 사람이 넣어야 할 방부제다.

LLM은 지식의 장부를 빠르게 정리할 수 있다. 하지만 장부가 현실을 제대로 가리키는지, 어떤 항목을 폐기하고 어떤 항목을 다음 질문으로 키울지는 사람이 결정해야 한다.

좋은 LLM Wiki는 사람 없는 위키가 아니다.

좋은 LLM Wiki는 사람이 편집장으로 남아 있는 위키다.

확인한 출처

• Andrej Karpathy, llm-wiki, GitHub Gist
• Rohit Goyal, LLM Wiki v2 — extending Karpathy's LLM Wiki pattern
• AFFiNE, What Is LLM Wiki? Karpathy's Idea That Turns Notes Into a Brain
• Tom Nguyen, I Built Karpathy’s LLM Wiki for My Day Job — Here’s What Actually Works
• StarMorph, How to Build Karpathy's LLM Wiki