위키는 쌓기만 하면 무너진다
LLM Wiki를 처음 만들 때는 자료를 넣는 일이 가장 중요해 보인다. 웹 문서, 책, 회의록, 아이디어, 고객 피드백을 계속 ingest하면 위키가 빠르게 풍성해진다. 하지만 어느 순간부터 문제가 생긴다.
비슷한 페이지가 여러 개 생긴다. 예전에 맞았던 주장이 지금은 틀린 말이 된다. 어떤 페이지는 다른 문서와 연결되지 않은 채 혼자 남는다. 출처가 없는 문장은 사실처럼 보이지만 근거를 확인할 수 없다. 서로 다른 페이지가 같은 질문에 다른 답을 하기도 한다.
이때 필요한 것이 lint다. 프로그래밍에서 lint는 코드의 오류, 스타일 문제, 위험한 패턴을 찾아내는 점검 절차다. LLM Wiki에서도 같은 개념을 쓸 수 있다. 위키 lint는 지식의 오류, 중복, 모순, 방치를 찾아내는 건강검진이다.
중요한 점은 lint가 완벽한 정답 판정이 아니라는 것이다. AI가 모든 문제를 확정할 수는 없다. 대신 AI는 의심 지점을 빠르게 찾아준다. 사람은 그중 중요한 것을 검토하고 고친다. 즉, AI는 검사자이고 인간은 편집장이다.
Lint가 찾아야 할 네 가지 문제
위키 lint의 목표는 단순하다. 위키가 커질수록 생기는 구조적 부채를 줄이는 것이다. 처음에는 작은 문제였던 중복과 모순이 시간이 지나면 검색 품질, 글쓰기 품질, 의사결정 품질을 떨어뜨린다.
우선 오래된 주장을 찾아야 한다. 예를 들어 "현재 가장 널리 쓰이는 모델은 A다", "이 가격 정책은 2024년 기준이다", "우리 제품의 핵심 고객은 프리랜서다" 같은 문장은 시간이 지나면 다시 확인해야 한다. 날짜, 버전, 가격, 시장 상황, 조직 전략이 들어간 문장은 특히 오래되기 쉽다.
둘째, 상충되는 페이지를 찾아야 한다. 한 페이지에서는 "고객은 자동화를 원한다"고 쓰고, 다른 페이지에서는 "고객은 자동화보다 직접 제어를 원한다"고 썼다면 둘 중 하나가 틀렸거나, 맥락이 다르거나, 고객군이 다른 것이다. 모순을 발견했다면 바로 삭제하기보다 조건을 분리해야 한다.
셋째, 출처 없는 문장을 찾아야 한다. 모든 문장에 출처가 필요하지는 않다. 그러나 사실 주장, 수치, 인용, 고객 발언, 외부 자료에서 가져온 내용은 근거가 있어야 한다. 출처 없는 주장이 많아질수록 위키는 지식 자산이 아니라 그럴듯한 메모장이 된다.
넷째, 연결되지 않은 페이지를 찾아야 한다. 아무 페이지에서도 링크되지 않는 문서를 고아 페이지라고 부른다. 고아 페이지는 나쁜 페이지라는 뜻은 아니다. 하지만 찾기 어렵고 재사용되기 어렵다. 좋은 지식은 연결되어야 한다.
오래된 주장 찾기
오래된 주장은 보통 문장 안에 힌트를 갖고 있다. "현재", "최근", "요즘", "가장 많이", "시장 표준", "대표적인", "우리의 전략", "다음 분기" 같은 표현은 시간이 지나면 위험해진다. 날짜가 없는 현재형 주장도 조심해야 한다.
다음과 같은 프롬프트를 lint에 사용할 수 있다.
wiki/ 폴더의 문서를 점검하라. 날짜, 버전, 가격, 정책, 시장 상황, 제품 전략, 모델 성능, 고객 세그먼트처럼 시간이 지나면 바뀔 수 있는 주장을 찾아라. 각 항목에 대해 파일 경로, 문제 문장 요약, 왜 오래되었을 수 있는지, 확인이 필요한 원문 또는 후속 작업을 제안하라. 확실하지 않은 것은 "검토 필요"로 표시하고 임의로 수정하지 마라.
이 프롬프트의 핵심은 "수정하지 마라"이다. lint 단계에서는 문제를 발견하는 것이 먼저다. AI가 오래된 문장을 마음대로 최신 정보로 바꾸면 더 큰 문제가 생긴다. 원문 확인 없이 업데이트된 문장은 새로운 환각이 될 수 있다.
오래된 주장을 찾았다면 세 가지 중 하나로 처리한다.
여전히 맞는 내용이면 날짜를 붙인다. 예: "2026년 5월 기준".
틀린 내용이면 새 근거를 확인한 뒤 수정한다.
판단하기 어려우면 페이지 상단에 "검토 필요" 표시를 남긴다.
작은 표시 하나가 나중의 혼란을 줄인다. 위키에서 가장 위험한 문장은 틀린 문장이 아니라, 오래되었는지조차 알 수 없는 문장이다.
모순은 삭제보다 분해가 먼저다
모순을 발견하면 보통 하나를 지우고 싶어진다. 하지만 지우기 전에 먼저 물어야 한다. 정말 모순인가, 아니면 조건이 다른가?
예를 들어 고객 인터뷰 페이지 A에는 "고객은 자동 요약 기능을 원한다"고 되어 있고, 페이지 B에는 "고객은 AI 요약을 신뢰하지 않는다"고 되어 있을 수 있다. 겉으로는 모순처럼 보인다. 하지만 실제로는 "초안 생성은 원하지만 최종 판단은 직접 하고 싶다"는 더 정교한 통찰일 수 있다.
모순 탐지 프롬프트는 이렇게 쓸 수 있다.
wiki/ 폴더에서 서로 충돌하거나 긴장 관계에 있는 주장을 찾아라. 특히 고객 니즈, 제품 전략, 시장 해석, 기술 선택, 가격 정책, 사용자 페르소나에 관한 문장을 비교하라. 각 항목에 대해 충돌하는 파일 경로, 주장 A, 주장 B, 가능한 해석 3가지를 제시하라. 하나를 즉시 삭제하지 말고, 조건 분리·대표 페이지 병합·추가 검증 중 어떤 처리가 적절한지 제안하라.
모순을 다루는 좋은 방법은 "조건"을 붙이는 것이다.
어떤 고객군에게 맞는가?
어느 시점의 관찰인가?
어떤 상황에서는 맞고 어떤 상황에서는 틀린가?
정량 데이터인가, 인터뷰 인상인가?
내부 의견인가, 외부 근거가 있는 사실인가?
LLM Wiki에서 모순은 쓰레기가 아니다. 잘 다루면 지식이 깊어지는 지점이다. 모순을 발견했다는 것은 위키가 단순 저장소에서 사고의 도구로 바뀌고 있다는 뜻이다.
출처 없는 문장 정리하기
출처 없는 문장은 두 종류로 나눠야 한다. 하나는 개인의 생각이나 해석이다. 이 경우 출처가 없어도 된다. 대신 "의견", "가설", "해석"이라고 표시하면 된다. 다른 하나는 사실 주장이다. 이 경우에는 출처가 필요하다.
출처 lint 프롬프트는 다음처럼 쓴다.
wiki/ 문서에서 출처가 필요한데 출처가 없는 문장을 찾아라. 수치, 인용, 시장 규모, 제품 기능 비교, 고객 발언, 논문 내용, 외부 기사 내용, 법률·정책·가격 정보에 집중하라. 각 문장에 대해 파일 경로, 주장 요약, 필요한 출처 유형, 위험도를 낮음·중간·높음으로 분류하라. 개인 의견이나 내부 가설은 출처 누락으로 보지 말고 "의견 표시 필요"로 분류하라.
여기서 중요한 것은 모든 문장을 각주로 도배하지 않는 것이다. 위키는 논문이 아니다. 그러나 나중에 글, 보고서, 투자 자료, 제품 의사결정에 재사용될 수 있는 문장은 근거가 있어야 한다. 근거가 없는 문장은 재사용 비용을 높인다.
출처가 없는 문장을 발견하면 다음 중 하나로 처리한다.
원문 링크나 raw 파일 경로를 붙인다.
확실하지 않으면 "출처 필요" 표시를 남긴다.
개인 의견이면 "해석" 또는 "가설"로 바꾼다.
중요하지 않은 문장이면 삭제한다.
위키의 신뢰도는 문장의 양이 아니라 확인 가능한 주장 비율로 결정된다.
고아 페이지와 끊어진 링크 찾기
고아 페이지는 다른 페이지에서 참조되지 않는 페이지다. 예를 들어 wiki/concepts/사용자-활성화.md라는 좋은 문서가 있어도, 제품 전략 페이지나 고객 인터뷰 페이지에서 링크하지 않으면 다시 발견하기 어렵다.
LLM Wiki에서는 링크가 곧 지식의 길이다. 링크가 없으면 AI도 맥락을 놓치기 쉽다. 사람이 읽을 때도 마찬가지다.
고아 페이지를 찾는 프롬프트는 이렇게 쓸 수 있다.
wiki/ 폴더의 모든 Markdown 파일을 기준으로 내부 링크를 점검하라. 다른 문서에서 한 번도 링크되지 않은 페이지, 링크는 있지만 핵심 개념 페이지와 연결되지 않은 페이지, 존재하지 않는 파일로 연결된 깨진 링크를 찾아라. 각 항목에 대해 파일 경로, 현재 문제, 연결하면 좋을 후보 페이지 3개, 추천 링크 문장을 제안하라.
고아 페이지를 발견했다고 바로 삭제해서는 안 된다. 먼저 세 가지를 판단한다.
중요한데 연결만 안 된 페이지인가?
다른 페이지와 중복되는 페이지인가?
더 이상 필요 없는 임시 메모인가?
중요한 페이지라면 대표 페이지나 index에서 링크한다. 중복 페이지라면 병합한다. 필요 없는 메모라면 archive로 옮기거나 삭제 후보로 표시한다.
또 하나 봐야 할 것은 "링크가 없는 핵심 개념"이다. 어떤 단어가 여러 문서에서 반복되는데 개념 페이지가 없다면, 그것은 새 페이지 후보일 수 있다. 예를 들어 고객 인터뷰 문서마다 "초기 활성화", "신뢰 장벽", "반복 사용 이유"가 반복된다면 각각 개념 페이지로 만들 가치가 있다.
중복 페이지는 대표 페이지로 병합한다
LLM Wiki가 커지면 같은 주제가 다른 이름으로 여러 번 생긴다. "고객 온보딩", "신규 사용자 경험", "첫 사용 흐름"은 서로 다른 페이지처럼 보이지만 실제로는 같은 문제를 다룰 수 있다.
중복 페이지를 발견했을 때 가장 나쁜 방식은 아무 기준 없이 하나를 지우는 것이다. 그 안에만 있는 좋은 근거와 표현이 사라질 수 있다. 더 나은 방식은 대표 페이지를 정하고, 나머지는 병합한 뒤 redirect처럼 남기는 것이다.
Markdown 위키에서는 완전한 웹 redirect가 없어도 된다. 병합된 페이지 상단에 다음처럼 남기면 충분하다.
이 페이지의 내용은
wiki/concepts/고객-온보딩.md로 병합됨. 이후 업데이트는 대표 페이지에서 관리한다.
중복 병합 프롬프트는 다음과 같다.
wiki/ 폴더에서 제목, 핵심 개념, 본문 내용이 겹치는 페이지를 찾아라. 각 중복 후보 묶음에 대해 대표 페이지로 삼을 파일을 제안하고, 그 이유를 설명하라. 병합 시 보존해야 할 고유 내용, 삭제해도 되는 반복 내용, 병합 후 남길 redirect 문구를 작성하라. 실제 파일 수정 전 변경 계획만 제시하라.
대표 페이지를 고를 때는 세 기준을 쓰면 된다.
가장 최신이고 관리가 잘 된 페이지
출처와 링크가 많은 페이지
앞으로도 자주 참조될 이름을 가진 페이지
페이지 이름은 멋있을 필요가 없다. 찾기 쉬워야 한다. 팀 위키라면 더욱 그렇다. 사람들이 실제로 쓰는 말이 대표 페이지 이름이 되어야 한다.
Lint 결과는 outputs에 남긴다
Lint를 한 번 실행하고 끝내면 효과가 작다. 더 중요한 것은 점검 이력을 남기는 것이다. 어떤 문제가 반복되는지, 어떤 페이지가 계속 방치되는지, 어떤 주제가 자주 모순되는지 봐야 한다.
이를 위해 루트에 outputs/ 폴더를 만들고, lint 결과를 날짜별 파일로 저장한다.
outputs/lint-2026-05-19.mdoutputs/lint-2026-05-26.mdoutputs/lint-2026-06-02.md
파일에는 다음 항목을 남긴다.
점검 날짜
점검 범위
발견한 문제 요약
우선순위 높은 수정 항목
사람이 확인해야 할 항목
AI가 제안한 병합 또는 링크 추가
실제 반영한 변경 사항
다음 lint 때 다시 볼 항목
이 파일은 단순 보고서가 아니다. 위키 운영의 진료 기록이다. 나중에 위키가 왜 이렇게 바뀌었는지, 어떤 기준으로 페이지를 병합했는지, 어떤 주장을 보류했는지 추적할 수 있다.
주간 lint 프롬프트는 이렇게 시작하면 좋다.
오늘 날짜 기준으로 LLM Wiki 주간 lint를 수행하라. 점검 범위는 wiki/ 전체이며, 오래된 주장, 모순된 주장, 출처 없는 사실 주장, 고아 페이지, 깨진 링크, 중복 페이지를 찾는다. 결과는
outputs/lint-YYYY-MM-DD.md형식으로 작성할 수 있게 정리하라. 각 문제에는 우선순위, 관련 파일, 추천 조치, 사람이 검토해야 하는 이유를 포함하라. 실제 파일은 수정하지 말고 보고서 초안을 먼저 작성하라.
처음부터 모든 문제를 고치려고 하면 지친다. 주간 lint에서는 상위 3개만 고쳐도 충분하다. 중요한 것은 완벽한 정리가 아니라 지속적인 회복이다.
주간 건강검진 루틴
LLM Wiki 운영자는 매주 한 번 30분만 투자해도 충분하다. 루틴은 단순해야 오래 간다.
AI에게 주간 lint 보고서를 만들게 한다.
우선순위 높은 문제 3개를 고른다.
오래된 주장은 검토 표시를 붙이거나 최신 근거로 갱신한다.
중복 페이지는 하나만 병합한다.
고아 페이지 몇 개를 대표 페이지나 index에 연결한다.
반영한 내용을
log.md와outputs/lint-YYYY-MM-DD.md에 남긴다.
이 정도면 충분하다. 위키 관리는 대청소가 아니라 양치질에 가깝다. 매일 완벽하게 정리하지 않아도 된다. 하지만 너무 오래 방치하면 다시 쓰기 어려워진다.
좋은 LLM Wiki는 자료가 많은 위키가 아니다. 오래된 주장과 새 근거가 구분되고, 중요한 개념이 연결되어 있으며, 중복이 대표 페이지로 정리되고, 수정 이력이 남아 있는 위키다.
AI에게 질문만 하는 사람은 매번 새 답을 받는다. AI와 함께 위키를 관리하는 사람은 이전 답을 점검하고, 더 나은 지식으로 갱신한다. 축적은 ingest로 시작되지만, 신뢰는 lint에서 만들어진다.
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.