8.1 위키에도 점검이 필요한 이유

핵심 요약

원문 구조와 실무 의미

상세 분석

1. 감사의 출발점은 raw, wiki, output의 경계다

LLM위키는 회의록, 웹 문서, 정책, 메모 같은 raw 자료를 업무 질문에 맞게 wiki 문서로 정리하고, 다시 보고서나 실행 계획 같은 output으로 꺼내 쓰는 구조다. 이 구조는 생산성을 높이지만 원천과 파생 지식 사이에 신뢰 간격을 만든다.

2. 요약 왜곡은 조건 누락과 추정의 단정화에서 자주 생긴다

감사자는 문장을 더 짧게 만드는 사람이 아니라 더 정확한 범위로 제한하는 사람이다. 좋은 수정은 종종 문장을 조금 길게 만든다. 조건, 날짜, 적용 범위, 확인 필요가 다시 들어가기 때문이다.

3. 네 가지 라벨만으로도 점검을 시작할 수 있다

4. 출처 누락은 수정 가능성의 문제다

출처가 없는 문장은 틀렸을 때 무엇을 기준으로 고칠지 알기 어렵다. 삭제만이 답은 아니다. 중요한 문장은 필요한 원천을 찾아 보강하고, 근거가 부족한 문장은 단정문에서 낮춘다.

5. 오래된 주장은 확인일이 없을 때 위험해진다

실무 적용 절차

1. 최근 추가 문서나 많이 쓰는 핵심 wiki 문서 하나를 고른다.
2. 문서 상단의 원문 URL, raw 경로, 확인일, 자료 성격을 확인한다.
3. 문장을 사실, 조건, 추정, 비교, 결정, 실행 제안 단위로 나눈다.
4. 각 문장에 확인됨, 확인 필요, 날짜 필요, 범위 제한 중 필요한 표시를 붙인다.
5. 확인됨 문장은 실제 원천 자료와 대조한다.
6. 확인 필요 문장은 필요한 원천 자료와 다음 질문을 적는다.
7. 날짜 필요 문장은 확인일, 기준 문서, 재확인 시점을 붙인다.
8. 범위 제한 문장은 도구, 버전, 기간, 조직, 실험 조건을 문장 안에 넣는다.
9. 출처 없는 사실 주장은 보강하거나 단정 강도를 낮춘다.
10. 설치 명령, 최신 버전, 가격, 정책, 일정, 제품 기능, 보안 기준을 우선 점검한다.
11. LLM에게 후보 추출을 맡기되 실제 원천, 최신 공식 문서, 조직 승인 여부는 사람이 판단한다.
12. 점검 결과를 log.md에 남기고, 다음 점검에서 이어 볼 행동을 정한다.

15분 주간 점검 루틴

템플릿

문장 신뢰도 점검표

점검 로그 템플릿

## [YYYY-MM-DD] weekly-check

- 점검 범위:
- 출처 누락:
- 오래된 주장:
- 조건 누락 또는 과도한 단정:
- 충돌 후보:
- 확인 필요:
- 다음 행동:

LLM 점검 요청 프롬프트

다음 위키 문서를 점검해 주세요.

목표:
- 출처가 없는 사실 주장 찾기
- 오래되었을 가능성이 있는 주장 찾기
- 추정이 단정처럼 쓰인 문장 찾기
- 서로 충돌할 수 있는 문장 찾기

출력 형식:
| 문장 | 문제 유형 | 이유 | 수정 제안 | 확인할 원천 자료 |

규칙:
- 원천 자료나 공식 문서로 확인되지 않은 내용은 단정하지 마세요.
- 버전, 가격, 정책, 일정, 제품 기능은 확인 날짜가 필요하다고 표시하세요.
- 문장을 고칠 때는 의미를 넓히지 말고, 근거가 있는 범위로 좁히세요.
- 민감 정보나 고객 원문을 새 문서에 복사하지 마세요.

검증 체크리스트

• 위키 문서를 원본으로 취급하지 않았다.
• 핵심 문장을 raw 원천 자료와 대조했다.
• 원문에 있던 기간, 대상, 조건, 예외가 사라지지 않았는지 확인했다.
• 검토 중, 후보, 내부 테스트, 확인 필요 같은 표현이 확정문으로 바뀌지 않았다.
• 출처 없는 사실 주장을 찾고 보강하거나 확인 필요로 낮췄다.
• 최신 버전, 가격, 정책, 일정, 제품 기능, 설치 명령에 확인일을 붙였다.
• 산출물을 만들기 전 핵심 주장만 다시 검증했다.
• LLM 점검 결과를 최종 판단으로 취급하지 않았다.
• 조직 승인, 최신 공식 문서, 고객 공유 가능성, 보안 기준은 사람이 판단했다.

관련 문서

• 8장. 오래 믿고 쓰는 LLM위키 운영법: 8.1의 점검 필요성을 8장 전체 운영 원칙 안에 배치한다.
• 8.2 정리와 감사 흐름 만들기: 형식, 근거, 최신성, 중복, 링크 감사 흐름으로 바꾼다.
• 8.3 주제가 늘어날 때 관리하기: 문서와 주제가 많아질 때 분리와 통합 기준을 제공한다.
• 8.4 내 업무 루틴에 붙이기: daily-inbox와 주간 점검으로 감사 루틴을 일상 업무에 붙인다.
• 2.1 지식이 쌓이는 세 층: raw, wiki, rules의 신뢰 경계를 설명한다.
• 2.3 좋은 위키 문서의 조건: 출처, 재사용성, 링크가 없는 문서가 왜 위험한지 기준을 제공한다.
• 5.1 자료를 넣기 전에 정할 기준: 자료 투입 시점의 출처, 신뢰도, 최신성 기준을 정한다.
• 6.2 답변의 근거 확인하기: 답변 문장별 근거 라벨과 확실성 등급을 붙인다.
• 7.2 업무 보고서 만들기: 보고서 문장을 주장-근거 매트릭스로 검증한다.

한계와 확인 필요

• 원문이 제시한 예시는 학습용이다. 실제 고객 문의, 회의록, 자동 응답 기준에는 개인정보, 계약 정보, 고객명, 내부 정책, 비공개 코드가 포함될 수 있으므로 파생 문서나 output에 그대로 복사하지 않는다.
• AGENTS.md나 CLAUDE.md에 점검 프롬프트를 넣어도 결과가 자동으로 정확해지는 것은 아니다. 실제 원천 자료, 최신 공식 문서, 조직 승인 상태, 고객 공유 가능성은 사람이 확인해야 한다.
• 15분 점검 루틴은 완벽한 감사가 아니라 최소 운영 루틴이다. 법무, 보안, 고객 커뮤니케이션, 규제 준수처럼 고위험 결정에는 별도 공식 검토 절차가 필요하다.

완료 기준

1. 위키 문서는 원본이 아니라 LLM이 만든 파생 지식이라는 점을 설명할 수 있다.
2. 조건, 날짜, 예외, 불확실성이 빠졌는지 문장 단위로 점검할 수 있다.
3. 확인됨, 확인 필요, 날짜 필요, 범위 제한 라벨을 적용할 수 있다.
4. 출처 없는 사실 주장과 오래된 주장 후보를 찾을 수 있다.
5. 최신성이 필요한 문장에 확인 날짜, 기준 자료, 재확인 시점을 붙일 수 있다.
6. 자료 추가, 산출물 작성 전, 주간 점검의 세 시점에 검증을 나누어 넣을 수 있다.
7. LLM에게 감사 후보 추출을 맡기되 최종 판단은 사람이 해야 함을 설명할 수 있다.