2.3 좋은 위키 문서의 조건

핵심 요약

2.3의 기준은 이후 3장의 도구 선택, 5장의 자료 정리, 6장의 질문과 검증, 7장의 산출물 작성, 8장의 장기 감사 루틴으로 넘어가기 전 문서 품질 게이트로 작동한다.

원문 구조와 실무 의미

상세 분석

1. 원천으로 돌아갈 수 있어야 한다

LLM위키가 자료를 많이 모아도 어떤 문장이 어디에서 왔는지 찾을 수 없다면 업무 지식이 아니라 검색 가능한 메모 더미가 된다. 특히 LLM이 만든 자연스러운 요약은 원천보다 읽기 쉬워서 더 위험하다. 결정, 추정, 사람의 판단, LLM 표현이 섞이면 나중에 보고서나 실행 항목에서 근거 없는 단정으로 승격될 수 있다.

2. 질문 재료로 구조화되어야 한다

좋은 문서는 한 번 읽고 끝나는 글이 아니라 나중에 LLM에게 다시 읽힐 입력이다. 적용 조건이 없으면 모든 상황에 맞는 답처럼 일반화되고, 판단 기준이 없으면 우선순위 비교가 감에 가까워지며, 한계가 없으면 산출물에서 위험한 단정이 생긴다.

3. 제목과 파일명은 질문 선택을 돕는다

summary.md, notes.md, report-draft.md 같은 이름은 시간이 지나면 어떤 질문에 써야 하는지 드러나지 않는다. 좋은 제목은 대상 업무, 판단 초점, 재사용 질문을 보여 준다. 예를 들어 meeting-action-item-automation은 회의록 실행 항목 자동화라는 범위를, customer-inquiry-labeling-risks는 고객 문의 라벨링 위험 검토라는 초점을 드러낸다.

4. 링크는 다음 확인을 안내해야 한다

링크 없는 위키는 파일 묶음에 가깝다. 그러나 링크가 많다고 좋은 것도 아니다. 관련 없는 링크가 많으면 탐색 비용이 커지고 LLM이 질문과 무관한 문서를 함께 읽어 답변 범위를 흐릴 수 있다.

5. 세 조건은 함께 통과해야 한다

출처만 있으면 자료 목록에 머물 수 있고, 질문 구조만 있으면 근거 없는 판단 문서가 될 수 있으며, 링크만 많으면 탐색 장식이 될 수 있다. 좋은 문서는 출처, 재사용성, 링크, 한계, 최신성을 함께 갖춘다.

실무 적용 절차

1. 문서가 답하려는 업무 질문을 한 문장으로 쓴다.
2. 제목과 파일명이 그 질문을 드러내는지 확인한다.
3. raw 경로, 원문 URL, 회의 날짜, 파일 버전, 확인일, 자료 성격을 근거 섹션에 둔다.
4. 원천 자료가 없는 문장은 확정 지식이 아니라 아이디어, 추정, 확인 필요로 낮춘다.
5. 한 문장 요약으로 업무 범위, 입력, 출력 또는 판단 목적을 고정한다.
6. 원천에서 확인되는 사실, 결정, 반복 패턴만 확인된 내용으로 적고 해석은 분리한다.
7. 어떤 자료, 독자, 기간, 보안 조건, 사람 검토 조건에서 쓸 수 있는지 적용 조건을 쓴다.
8. 반복 빈도, 검토 시간, 오류 위험, 민감 정보, 산출물 영향, 최신성 같은 판단 기준을 표로 만든다.
9. 자동화 금지 조건, 사람 검토 필요, 원천 부족, 품질 저하 조건을 한계로 둔다.
10. 효과 측정, 정확도 목표, 보안 기준, 담당자 승인, 최신 문서 확인을 확인 필요로 분리한다.
11. 비교표, 실험 계획, 보고서, 실행 항목, 위험 점검으로 이어지는 질문을 2개 이상 남긴다.
12. 상위 개념, 비슷한 후보, 원천 자료, 위험 기준, 산출물, 감사 로그 중 필요한 링크만 붙인다.
13. 이 문서를 LLM에게 읽혔을 때 보고서, 실험 계획, 비교표 중 하나를 만들 수 있는지 시험한다.
14. 시험 답변에서 출처 없는 단정이 나오면 조건, 한계, 확인 필요를 보강한다.
15. 문서 생성 또는 갱신 사실을 log.md에 남길 수 있게 변경 이유를 정리한다.

실무 템플릿

좋은 위키 문서 기본 골격

최소 출처 블록

검증 체크리스트

• 문서의 제목과 파일명이 업무 질문을 드러낸다.
• 원천 자료, URL, 확인 날짜 중 하나 이상이 근거 섹션에 남아 있다.
• 자료 성격이 내부 회의록, 공식 문서, 개인 메모, LLM 초안 등으로 구분되어 있다.
• raw 원천과 wiki 정리 문서가 구분되어 있다.
• LLM이 만든 요약을 원천 자료처럼 취급하지 않는다.
• 핵심 주장마다 근거 위치 또는 확인 필요 표시가 있다.
• 단정할 수 있는 내용과 확인 필요 항목이 분리되어 있다.
• 적용 조건과 판단 기준이 있어 비교 질문, 우선순위 질문, 실험 계획 질문에 다시 쓸 수 있다.
• 한계가 있어 자동화나 산출물로 과하게 승격되지 않는다.
• 다시 물어볼 질문이 2개 이상 있다.
• 관련 문서, 원천 자료, 위험 기준, 산출물 중 필요한 링크가 있다.
• 시간이 지나면 틀릴 수 있는 주장에 확인 날짜나 재확인 기준이 있다.
• 개인정보, 보안, 비용, 법률, 제품 기능, 최신 버전처럼 위험한 주장을 근거 없이 단정하지 않았다.
• 문서 생성 또는 갱신 사실이 log.md에 남을 수 있다.

좋은 질문과 검증 질문

흔한 실패와 수정 방향

관련 문서

• 2장. LLM위키의 기본 구조: 2.3의 문서 품질 기준을 장 전체 구조 안에 배치한다.
• 2.1 지식이 쌓이는 세 층: 좋은 문서가 raw, wiki, rules의 신뢰 경계를 지켜야 하는 이유를 제공한다.
• 2.2 좋은 폴더 구조 이해하기: 좋은 문서가 index.md, log.md, output/ 흐름 안에서 어떻게 배치되는지 설명한다.
• 1.1 LLM을 써도 지식이 남지 않는 이유: 반복 맥락을 좋은 위키 문서 후보로 바꾸는 문제의식을 제공한다.
• 1.3 이 책에서 만들 결과물: raw/, wiki/, output/, index.md, log.md, AGENTS.md 구조를 보여 준다.
• 3.1 시작 방식 비교하기: 문서 품질 기준을 수동 Markdown, 에이전트, CLI, 데스크톱 방식 선택에 적용한다.
• 5.1 자료를 넣기 전에 정할 기준: 출처 블록에 들어갈 자료 투입 기준, 포함/제외 범위, 민감 정보 기준을 정한다.
• 5.3 위키 문서로 정리하기: 흩어진 자료를 주제별 문서와 링크로 재구성한다.
• 6.1 좋은 질문 만들기: 좋은 문서의 적용 조건과 판단 기준을 업무 질문으로 바꾼다.
• 6.2 답변의 근거 확인하기: 문장별 근거 라벨과 확실성 등급으로 문서 기반 답변을 검증한다.
• 7.2 업무 보고서 만들기: 출처와 판단 기준을 주장-근거 매트릭스로 옮긴다.
• 8.1 위키에도 점검이 필요한 이유: 그럴듯한 요약이 조건과 출처를 잃는 위험을 점검한다.
• 8.2 정리와 감사 흐름 만들기: 출처, 최신성, 중복, 충돌, 링크를 주기적으로 감사한다.

한계와 완료 기준

1. 좋은 위키 문서의 세 조건을 출처, 재사용성, 링크로 설명할 수 있다.
2. raw 원천과 wiki 파생 문서를 구분하고, wiki가 원천을 대체하지 않는다고 설명할 수 있다.
3. 최소 출처 블록에 원천 자료, 확인 날짜, 자료 성격, 확인 필요, 관련 문서를 남길 수 있다.
4. 아이디어 메모를 한 문장 요약, 적용 조건, 판단 기준, 한계, 다시 물어볼 질문이 있는 문서로 바꿀 수 있다.
5. 제목과 파일명이 나중에 던질 질문을 돕는지 점검할 수 있다.
6. 링크를 상위 개념, 비슷한 후보, 원천 자료, 위험 기준, 산출물 역할로 구분할 수 있다.
7. 확인 필요와 최신성 기준을 삭제하지 않고 문서 품질의 일부로 유지할 수 있다.