신뢰성은 요약의 품질이 아니라 되돌아갈 수 있는 능력이다
LLM Wiki를 운영하다 보면 처음에는 요약 품질에 눈이 간다. 문장이 매끄러운가, 개념이 잘 정리됐는가, 링크가 충분한가를 본다. 그러나 시간이 지나면 더 중요한 기준이 드러난다.
이 문장이 어디서 왔는가?
AI가 만든 위키의 가치는 멋진 문장에 있지 않다. 의심스러운 문장을 만났을 때 원문으로 돌아갈 수 있는 구조에 있다. 원문을 확인할 수 없다면 그 문장은 지식이 아니라 추정이다. 추정은 쓸 수 있지만, 사실처럼 섞이면 위키 전체를 오염시킨다.
그래서 LLM Wiki에서 출처 관리는 부가 기능이 아니다. 위키의 뼈대다. raw/는 증거 보관소이고, wiki/는 해석과 요약의 레이어다. 이 둘을 섞지 않는 것이 신뢰성 관리의 출발점이다.
raw는 증거, wiki는 해석이다
raw/ 폴더에는 원문을 저장한다. 웹 문서, PDF, 회의록, 인터뷰 녹취, 논문, 책 발췌, 고객 피드백이 여기에 들어간다. 이 파일은 수정하지 않는다. 오탈자를 고치고 싶어도 고치지 않는다. 문서 형식을 바꾸거나 일부를 삭제하고 싶어도 원본은 그대로 둔다.
이 원칙이 중요한 이유는 단순하다. AI는 요약하면서 생략한다. 생략은 필요하지만, 생략된 맥락이 나중에 중요한 근거가 될 수 있다. 원문이 그대로 남아 있어야 나중에 "이 요약이 맞는가?"를 확인할 수 있다.
반대로 wiki/는 AI가 만들어도 되는 공간이다. 여기에는 개념 페이지, 인물 페이지, 비교 페이지, 의사결정 기록, 요약 페이지가 들어간다. 이 문서들은 계속 바뀐다. 새로운 자료가 들어오면 수정되고, 오래된 주장은 낮은 신뢰도로 표시되며, 모순이 발견되면 검토 대기 상태로 바뀐다.
LLM Wiki 구현체들도 원문은 불변 자료로 두고, 그 위에 요약·교차참조·신뢰도 점수를 가진 위키 문서를 쌓는 구조를 강조한다.1 이 구조는 단순하지만 강력하다. 위키가 틀려도 원문은 남아 있다. 위키가 과감하게 요약해도 검증 경로는 끊기지 않는다.
좋은 출처 표기는 다음 정보를 포함한다.
raw/상대 경로원문 URL
수집일
문서 작성일 또는 발행일
페이지 번호, 문단 번호, 타임스탬프
인용 또는 요약한 범위
원문 신뢰도에 대한 간단한 판단
예를 들면 다음과 같다.
sources:
- path: raw/articles/2026-05-10-rag-evaluation.md
url: https://example.com/rag-evaluation
collected: 2026-05-19
locator: "section 3, paragraphs 2-4"
note: "RAG 평가 지표 비교 근거"이 정도만 지켜도 위키의 성격이 달라진다. 단순 노트가 아니라 검증 가능한 지식 저장소가 된다.
문장은 주장 단위로 관리한다
AI가 만든 위키에서 가장 위험한 문장은 그럴듯한 문장이다. 문장이 자연스러울수록 독자는 검증하지 않고 받아들인다. 그래서 중요한 문장은 "문단"이 아니라 "주장" 단위로 봐야 한다.
한 문단 안에도 여러 종류의 문장이 섞인다.
사실: "이 기능은 2026년 5월에 출시되었다."
해석: "이 출시는 제품 방향이 자동화로 이동했음을 보여준다."
추정: "앞으로 팀 위키 자동화 수요가 늘어날 가능성이 높다."
의견: "이 방식은 소규모 팀에 가장 적합하다."
실행 제안: "따라서 주간 lint 루틴을 먼저 도입하자."
이 다섯 문장을 같은 무게로 저장하면 안 된다. 사실에는 출처가 필요하다. 해석에는 근거가 필요하다. 추정에는 불확실성 표시가 필요하다. 의견에는 작성자의 관점이 드러나야 한다. 실행 제안에는 적용 조건이 붙어야 한다.
위키 페이지에는 다음처럼 주장 유형을 드러내는 표기를 넣을 수 있다.
status: needs-review
claim_type: interpretation
confidence: medium
last_verified: 2026-05-19또는 본문에 직접 표시해도 된다.
- [fact] 제품 A는 2026년 4월에 가격 정책을 변경했다. 출처: raw/competitors/product-a-pricing.md
- [interpretation] 이 변경은 엔터프라이즈 고객 중심 전략으로 해석할 수 있다.
- [hypothesis] 3분기에는 팀 요금제가 추가될 가능성이 있다. 근거 부족, 검토 필요.이 방식은 번거로워 보이지만, 나중에 큰 차이를 만든다. 보고서, 블로그, 제안서, 투자 자료를 만들 때 어떤 문장을 그대로 써도 되는지 빠르게 판단할 수 있다. 출처 없는 문장은 초안에만 쓰고, 검증된 사실은 외부 문서에 재사용한다.
신뢰도 상태를 문서에 새긴다
LLM Wiki는 모든 문서를 같은 신뢰도로 다루면 안 된다. 방금 수집한 회의 메모와 세 번 검증된 제품 정책 문서는 다르다. 오래된 블로그 글과 공식 문서도 다르다. 한 명의 고객 인터뷰와 50건의 고객 피드백에서 반복된 패턴도 다르다.
따라서 frontmatter에 신뢰도 상태를 넣는다.
---
title: 고객 온보딩 병목
type: concept
status: verified
claim_type: mixed
confidence: high
sources:
- raw/meetings/2026-04-customer-interviews.md
- raw/support/2026-q2-tickets.md
last_verified: 2026-05-19
review_owner: minji
---상태값은 단순할수록 좋다.
verified: 출처가 있고 사람이 검토했다.needs-review: 출처는 있으나 해석이나 요약 검토가 필요하다.speculative: 아이디어, 가설, 초기 추정이다.stale: 오래되었거나 최신 자료와 충돌할 가능성이 있다.rejected: 근거 부족 또는 오류로 폐기되었다.
신뢰도는 숫자보다 상태로 시작하는 편이 좋다. 처음부터 0.82 같은 점수를 매기려 하면 운영이 복잡해진다. 다만 위키 규모가 커지면 신뢰도 점수, 최신성, 반복 확인 횟수, 반대 근거 여부를 함께 관리할 수 있다. LLM Wiki v2 계열의 논의에서도 지식은 시간이 지나며 낡고, 새로운 근거로 강화되거나 대체되어야 한다고 설명한다.2
중요한 것은 AI가 verified와 speculative를 섞어 단정하지 않게 만드는 것이다. speculative 상태의 문장을 답변에 사용할 때는 "가능성이 있다", "추정된다", "추가 검증이 필요하다"라고 말하게 해야 한다.
편집 이력은 신뢰의 일부다
위키피디아와 위키데이터가 신뢰를 쌓아온 방식은 완벽한 첫 문장이 아니다. 많은 사람이 고치고, 출처를 연결하고, 편집 이력을 남기고, 구조화된 항목을 관리해 온 과정이다. 위키데이터는 대규모 지식 그래프와 방대한 편집 이력을 바탕으로 AI 시스템이 활용할 수 있는 지식 기반으로 확장되고 있다.3
LLM Wiki도 같은 원칙을 가져올 수 있다. 완벽한 요약을 기대하지 말고, 검토 가능한 변경 기록을 남긴다.
log.md에는 최소한 다음을 기록한다.
## 2026-05-19
- ingest: raw/articles/rag-hallucination-review.md
- updated:
- wiki/concepts/rag-hallucination.md
- wiki/concepts/faithfulness.md
- new claims:
- RAG도 충분한 컨텍스트가 있어도 환각할 수 있음
- review:
- needs human check: LUMINA 성능 수치 해석Git을 함께 쓰면 더 좋다. 한 번의 ingest가 어떤 파일을 바꾸었는지 diff로 볼 수 있다. 잘못된 요약이 들어가면 되돌릴 수 있다. 팀 위키라면 pull request 방식으로 AI가 만든 변경을 사람이 검토한 뒤 병합할 수 있다.
이 구조에서는 AI가 편집자이고, 인간은 발행 책임자다. AI가 초안을 만들 수는 있지만, verified로 승격하는 권한은 사람에게 두는 편이 안전하다.
환각은 정기적으로 찾는다
AI 환각은 한 번의 실수로 끝나지 않는다. 위키에 저장되면 다음 답변의 근거가 된다. 잘못된 요약이 다시 요약되고, 약한 추정이 강한 결론처럼 바뀐다. 이것이 누적되면 위키는 점점 자신감 있는 오류 저장소가 된다.
그래서 정기적인 truth-seeking audit이 필요하다. 이름은 거창하지만, 하는 일은 단순하다.
출처 없는 주장 찾기
원문과 다른 요약 찾기
오래된 정보 찾기
서로 모순되는 페이지 찾기
근거가 약한 결론 찾기
추정이 사실처럼 쓰인 문장 찾기
처리 결과는 네 가지 중 하나로 정한다.
삭제한다.
수정한다.
needs-review로 보류한다.사람 검토를 요청한다.
특히 RAG나 LLM 기반 답변에서는 검색된 문서가 있어도 모델이 그 문서를 제대로 사용하지 못해 환각할 수 있다는 연구가 계속 나오고 있다.4 이는 LLM Wiki에도 그대로 적용된다. 출처가 있다는 사실만으로 충분하지 않다. 위키 문장이 실제로 그 출처에 의해 지지되는지 확인해야 한다.
감사용 프롬프트는 다음처럼 짧게 시작할 수 있다.
wiki/ 전체에서 다음을 찾아줘.
1. 출처가 없는 사실 주장
2. sources에는 파일이 있지만 본문 주장과 직접 연결되지 않는 문장
3. speculative인데 단정형으로 쓰인 문장
4. 6개월 이상 검증되지 않은 verified 문서
각 항목에 대해 삭제, 수정, 보류, 사람 검토 요청 중 하나를 제안해줘.이 루틴은 앞 장의 lint와 연결된다. lint가 링크와 구조의 건강검진이라면, truth-seeking audit은 사실성과 근거의 건강검진이다.
민감정보는 들어오기 전에 막는다
출처 관리에서 마지막으로 중요한 것은 보안이다. LLM Wiki는 자료를 많이 넣을수록 좋아 보이지만, 넣으면 안 되는 자료가 있다. 개인정보, API 키, 비밀번호, 고객 원문 데이터, 계약서, 사내 기밀, 미공개 재무 정보는 ingest 단계에서 걸러야 한다.
한 번 raw/나 logs/에 민감정보가 들어가면 제거가 어렵다. Git에 커밋되면 기록에도 남는다. 외부 LLM에 업로드했다면 통제 범위 밖으로 나갈 수 있다.
CLAUDE.md나 AGENTS.md에는 다음 규칙을 명시한다.
## 민감정보 규칙
- API 키, 토큰, 비밀번호가 포함된 파일은 ingest하지 않는다.
- 주민등록번호, 전화번호, 이메일, 주소는 익명화한다.
- 고객명은 Customer-A, Customer-B처럼 치환한다.
- 사내 기밀 문서는 외부 LLM에 업로드하지 않는다.
- 민감정보가 의심되면 작업을 중단하고 사람에게 확인을 요청한다.팀 위키에서는 공유 영역과 개인 영역도 나눠야 한다. 개인 메모가 곧바로 팀 위키에 들어가면 안 된다. 사람이 검토한 자료만 공유 위키에 반영한다. AI가 정리하더라도 공개 범위의 판단은 사람이 해야 한다.
신뢰성 관리의 최소 규칙
처음부터 복잡한 거버넌스를 만들 필요는 없다. 다음 여섯 가지만 지켜도 위키의 신뢰도는 크게 올라간다.
raw/는 수정하지 않는다.wiki/의 중요한 주장은 원문 경로를 남긴다.사실, 해석, 추정, 의견을 구분한다.
status와confidence를 frontmatter에 적는다.모든 ingest와 주요 수정은
log.md와 Git에 남긴다.민감정보는 ingest 전에 차단한다.
LLM Wiki는 AI가 알아서 맞는 말을 쌓아주는 마법 상자가 아니다. AI가 빠르게 읽고, 요약하고, 연결하게 하되, 그 결과를 검증 가능한 구조 안에 묶어두는 운영 방식이다.
좋은 위키는 틀리지 않는 위키가 아니다. 틀렸을 때 어디가 틀렸는지 찾을 수 있는 위키다. 그리고 그 오류를 고친 기록이 다음 지식의 일부가 되는 위키다.
참고
2LLM Wiki v2 — extending Karpathy's LLM Wiki pattern
3IBM의 Wikipedia·Wikidata 지식 기반 활용 사례
4LUMINA: Detecting Hallucinations in RAG System with Context-Knowledge Signals
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.