LLM Wiki는 왜 무너지는가 - 4가지 붕괴 모드

LLM Wiki를 만든 사람들의 후기는 두 갈래로 나뉩니다. "실제로 업무가 달라졌다"는 쪽과 "일주일 만에 안 쓰게 됐다"는 쪽입니다. 차이가 왜 생기는지, 단순히 "꾸준함"의 문제로 볼 수 없습니다.

Your LLM Wiki Will Collapse는 이 붕괴를 4가지 구조적 결함으로 분석합니다. 의지나 습관이 아니라 아키텍처 문제라는 시각입니다. 각 모드가 무엇이고, 어떻게 대응할 수 있는지를 정리합니다.

왜 붕괴를 설계 문제로 봐야 하는가

"3일 만에 안 쓰는" 현상을 게으름으로 설명하면, 해결책은 "더 부지런히"가 됩니다. 그런데 그 처방은 작동하지 않습니다.

실제 패턴을 보면 다릅니다. 처음엔 열심히 씁니다. 그런데 위키가 커질수록 신뢰도가 떨어집니다. 내가 쓴 내용인데 맞는지 확신이 없어집니다. AI가 오래된 내용을 기반으로 잘못된 제안을 합니다. 결국 위키를 열지 않게 됩니다.

붕괴는 의지 부족이 아니라 피드백 루프가 없어서입니다.

붕괴 모드 1: 인식론적 필터 부재

위키에 정보를 넣을 때, "이게 사실인가?"를 검증하는 메커니즘이 없습니다.

Mehul Gupta가 지적했듯이, AI가 생성한 요약을 위키에 저장하면 그 요약의 오류도 함께 저장됩니다. 그리고 그 오류는 다음 AI 응답의 전제가 됩니다. 오류가 오류를 낳는 구조입니다.

더 교묘한 문제도 있습니다. HN 댓글에서 나온 표현인 "consensus smoothing"입니다. 위키가 커질수록, AI는 개인의 날카로운 관점보다 여러 출처의 평균적인 시각을 반영하게 됩니다. 독특하고 유용했던 개인 지식이 일반론으로 희석됩니다.

대응: 위키에 쓸 때 출처를 병기합니다. "이건 공식 문서에서 확인한 내용"과 "이건 내 경험에서 나온 추측"을 구분해서 표시합니다. 확인되지 않은 내용은 별도 폴더(/unverified)에 따로 둡니다.

붕괴 모드 2: 지식 생애주기 부재

위키는 쓰는 것만 있고 지우는 것이 없습니다.

페이지가 만들어지면 영구적으로 남습니다. 6개월 전에 쓴 AWS 인프라 구조가 리팩토링 후에도 그대로 있습니다. 작년에 쓴 팀 규칙이 팀원이 바뀐 뒤에도 남아있습니다. AI는 오래된 내용과 최신 내용을 구분하지 못합니다.

Tom Nguyen이 솔직하게 인정했습니다. "정확하지 않은 위키는 아무것도 없는 것보다 나쁠 수 있습니다." 구식 정보가 틀린 자신감을 만들기 때문입니다.

대응: 각 페이지에 last_reviewed: 날짜를 씁니다. 3개월 이상 검토되지 않은 페이지는 /stale 폴더로 이동합니다. 위키를 쓸 때는 만료 날짜를 함께 생각합니다. "이 정보는 인프라 재구성 전까지만 유효하다."

붕괴 모드 3: 엔트로피 역전 부재

시스템이 스스로 붕괴에 저항하는 힘이 없습니다.

내용이 쌓이면 중복이 생깁니다. 비슷한 주제가 다른 파일 두 군데에 있습니다. 모순되는 내용이 생깁니다. 한 파일에서는 "배포는 금요일 금지"라고 하고, 다른 파일에서는 아무 언급이 없습니다. 이런 문제들은 사람이 직접 찾아 정리하지 않으면 계속 쌓입니다.

그런데 그 정리 자체가 고된 작업입니다. 그리고 위키가 클수록 더 고됩니다. 결국 위키를 열지 않게 됩니다.

대응: 정기적으로 전체 위키를 AI에게 리뷰시킵니다. "이 위키에서 중복되거나 모순되는 내용을 찾아줘"라는 프롬프트로 시작합니다. 이 작업을 주간 또는 월간 루틴에 박아 넣습니다. Claude Code의 cron 기능이나 launchd를 쓰면 자동화할 수 있습니다.

붕괴 모드 4: 접지 검증 부재

가장 근본적인 문제입니다. LLM은 통계적 확률로 다음 토큰을 예측합니다. 위키의 내용이 현실과 맞는지를 스스로 검증하지 않습니다.

"배포 서버는 prod-01이다"라고 위키에 쓰여 있으면, AI는 그것이 지금도 사실인지 확인하지 않습니다. 서버 이름이 바뀌었어도, 위키에 있으니 그대로 씁니다.

이것은 LLM 자체의 한계이기도 합니다. 모델은 개념 간 통계적 관계는 잘 파악하지만, "이 개념이 현재 세계에서 사실인가"를 직접 검증하는 능력이 없습니다.

대응: 변동성이 높은 정보(서버 목록, 환경 변수, API 엔드포인트)는 위키에 넣지 않습니다. 위키는 변화 속도가 느린 것들, 즉 원칙, 설계 결정의 배경, 팀의 사고방식을 담는 공간입니다. 빠르게 변하는 것은 공식 문서나 실제 시스템을 직접 참조하게 합니다.

4가지를 한 줄로

이 네 가지를 의식하고 위키를 만들면, "3일 만에 안 쓰는" 패턴은 피할 수 있습니다. 전부 처음부터 완벽하게 할 필요는 없습니다. 지금 쓰고 있는 위키에서 가장 리스크가 큰 모드 하나만 골라서 시작하는 것으로 충분합니다.

참고: Your LLM Wiki Will Collapse (gist) / HN 토론 (2026-04-25) / Mehul Gupta — LLM Wiki is a Bad Idea