컬렉션 홈
전체 트리
WikiDocs 통합 루트
현재 서빙 인덱스
LLM위키 완벽 가이드 서빙 인덱스
이 페이지는 WikiDocs 원문을 바탕으로 보강된 LLM위키 Markdown 코퍼스를 탐색하고, HTML 서빙본의 링크 구조와 커버리지를 검수하기 위한 안내서다. 본문 방법론은 통합 루트와 장/절 문서가 담당하고, 이 문서는 어디에서 무엇을 확인해야 하는지 빠르게 연결한다.
Source path: data/runtime/write-agents/LLM wiki reference analyses/md/wikidocs/serving-index.md
서빙 인덱스의 역할
이 파일은 책 전체를 다시 요약하는 본문이 아니다. 전체 방법론은 index.html , 장 개요 8개, 세부 절 25개가 맡는다. 이 서빙 인덱스는 서빙 계층이나 사용자가 다음 네 가지를 빠르게 판단하도록 돕는다.
현재 코퍼스가 WikiDocs 원문 목차를 어디까지 덮는가.
어떤 업무 상황에서 어떤 HTML 문서를 먼저 열어야 하는가.
장 개요와 세부 페이지가 어떤 근거와 산출물 역할을 갖는가.
Markdown 링크 구조가 HTML 변환이나 외부 서빙에서도 같은 계층으로 유지되는가.
HTML 서빙본에서도 논리 계층은 index -> chapters -> pages 순서를 유지한다.
커버리지 대시보드
범주 개수 포함 파일 역할 상태
원문 도서 루트 1 WikiDocs book/19830 책의 목적, 대상 독자, 전체 목차, 장별 설명 확인 확인됨
통합 루트 1 index.html 원문 루트와 전체 장/절 분석을 합성한 방법론 안내 갱신 대상 포함
서빙 인덱스 1 serving-index.html 트리, 커버리지, 사용 경로, 검수 기준 안내 현재 문서
장 개요 8 chapters/*.html각 장의 하위 절 관계와 장 수준 판단 기준 로컬 본문 있음
세부 절 25 pages/*.html원문 절별 실습, 체크리스트, 검증 질문 로컬 본문 있음
서빙 관점에서 본문 분석 문서는 34개다. 통합 루트 1개, 장 개요 8개, 세부 절 25개가 실제 학습과 운영 방법론을 담당한다. 이 서빙 인덱스는 그 34개 본문 문서를 찾고, 사용 순서와 커버리지 한계를 설명한다.
빠른 라우팅 표
사용자가 묻는 것 먼저 열 문서 보조 문서 이유
전체 방법론을 한 번에 보고 싶다 index.html 1장 , 8장 루트는 전체 흐름과 판단 기준을 합성한다.
왜 LLM 대화만으로 지식이 남지 않는지 설명하고 싶다 1장 1.1 , 1.2 반복 맥락 손실과 LLM위키 개념을 다룬다.
폴더 구조와 규칙 파일을 정해야 한다 2장 2.1 , 2.2 , 2.3 raw/wiki/rules, index/log, 좋은 문서 조건을 연결한다.
어떤 도구로 시작할지 모르겠다 3장 3.1 , 3.2 , 3.3 방식 비교, 도구 최소 조건, 미니 위키 실습을 제공한다.
첫 주제를 너무 크게 잡고 있다 4장 4.1 , 4.3 큰 주제를 작은 업무 질문과 첫 질문으로 줄인다.
자료를 넣기 전에 기준이 필요하다 5장 5.1 , 5.2 수집 기준 카드와 원천 카드가 중심이다.
LLM 답변을 믿어도 되는지 검증하고 싶다 6장 6.1 , 6.2 , 6.3 질문 경계, 근거 라벨, 검증 후 반영을 다룬다.
보고서나 실행 계획을 만들어야 한다 7장 7.1 , 7.2 , 7.3 산출물 목적, 주장-근거 매트릭스, 실행 항목화를 제공한다.
위키가 오래되어 신뢰가 떨어질까 걱정된다 8장 8.1 , 8.2 , 8.3 , 8.4 출처, 최신성, 중복, 주제 확장, daily-inbox 루틴을 관리한다.
원문 목차 기반 로컬 트리
루트
1장. LLM위키가 필요한 이유
2장. LLM위키의 기본 구조
장 개요 : 원천, 해석, 규칙, 산출물, 탐색, 로그를 분리한다.
2.1 지식이 쌓이는 세 층 : raw/wiki/rules 역할표와 원천 메타데이터 규칙.
2.2 좋은 폴더 구조 이해하기 : 핵심 질문 중심 폴더, index/log 책임.
2.3 좋은 위키 문서의 조건 : 출처 블록, 요약, 확인된 내용, 확인 필요, 관련 문서.
3장. 내게 맞는 LLM위키 방식 고르기
4장. 첫 번째 주제 위키 만들기
5장. 자료를 넣고 다시 쓰기 좋은 지식으로 바꾸기
6장. 위키에 질문하고 답을 검증하기
장 개요 : 위키를 검증 가능한 질의응답 루프로 전환한다.
6.1 좋은 질문 만들기 : 자료 범위, 업무 목적, 판단 기준, 출력 형식, 검증 조건을 가진 질문.
6.2 답변의 근거 확인하기 : 원천 근거, 위키 근거, 제한적 확인, 추정, 출처 없음, 최신성 확인 필요 라벨.
6.3 답변을 다시 위키에 반영하기 : 결정 로그, 새 지식 반영, 반복 질문 템플릿, index/log 갱신.
7장. 위키에서 업무 산출물 만들기
8장. 오래 믿고 쓰는 LLM위키 운영법
장 개요 : 오래된 주장, 출처 누락, 중복, 주제 확장을 관리한다.
8.1 위키에도 점검이 필요한 이유 : 신뢰도 라벨, 출처 누락과 오래된 주장 목록.
8.2 정리와 감사 흐름 만들기 : 문서 형식 점검표와 감사 로그.
8.3 주제가 늘어날 때 관리하기 : 주제 분리 기준, 주제 인벤토리, 아카이브 기준.
8.4 내 업무 루틴에 붙이기 : daily-inbox, 오늘 넣을 후보, 오늘 정리할 문서, 확인 필요, 주간 점검 기록.
서빙용 검수 절차
WikiDocs 원문 루트 의 목차가 8장과 25개 하위 절로 구성되는지 확인한다.
이 인덱스의 장/절 트리가 원문 목차와 같은 순서인지 확인한다.
각 장 링크가 chapters/NN-*.html로 이어지는지 확인한다.
각 하위 절 링크가 pages/NN-NN-*.html로 이어지는지 확인한다.
index.html 이 방법론 통합을 담당하고, 이 파일은 탐색과 커버리지 안내에 머무르는지 확인한다.
장 개요는 하위 절 관계를 합성해야 하고, 세부 페이지는 절별 실습과 체크리스트를 담당해야 한다.
원문 URL과 확인일이 각 본문 문서 상단에 유지되는지 확인한다.
HTML 서빙본은 Markdown 계층과 동일한 대응 경로를 가져야 한다.
서빙 계층에서 유지할 링크 원칙
루트 문서끼리는 상대 링크를 사용한다. 예: index.html , serving-index.html .
장 개요는 chapters/ 하위 링크를 사용한다.
세부 절은 pages/ 하위 링크를 사용한다.
장 문서 안에서 세부 절로 갈 때는 ../pages/... 상대 경로를 유지한다.
세부 절 문서에서 장으로 갈 때는 ../chapters/... 상대 경로를 유지한다.
외부 원문은 WikiDocs URL을 유지한다.
HTML 변환 시에도 논리 계층은 root -> chapters -> pages를 유지한다.
코퍼스 품질 체크리스트
원문 도서 루트 링크가 유지된다.
통합 루트와 서빙 인덱스의 역할이 분리된다.
장 개요 8개가 모두 연결된다.
세부 절 25개가 모두 연결된다.
각 장 개요가 하위 절의 순서와 관계를 설명한다.
세부 절 문서가 원문 실습을 절차, 판단 기준, 체크리스트로 재구성한다.
원문 문장을 장문 복제하지 않고 근거 위치를 링크로 남긴다.
수집 기준, 근거 라벨, 주장-근거 매트릭스, 감사 루틴처럼 실무 산출물로 이어지는 항목을 찾을 수 있다.
확인 필요 또는 적용 시 주의가 원문 근거와 분리되어 있다.
최신성이 필요한 도구, 정책, 보안, 외부 전송 관련 판단은 현재 공식 문서 확인 대상으로 남긴다.
누락 또는 주의사항
이 문서는 서빙/탐색용 인덱스다. 장별 세부 설명을 중복해서 담지 않고, 링크 트리와 사용 경로를 중심으로 구성했다.
현재 근거는 WikiDocs 도서 루트 확인과 로컬 Markdown 장/절 분석본이다. 원문이 2026-06-06 KST 이후 수정되면 원문 최종 편집일시와 로컬 분석 문서의 확인일을 다시 갱신해야 한다.
4장, 5장, 7장, 8장 장 개요의 일부 로컬 분석은 1장, 2장, 3장, 6장보다 상대적으로 짧다. 세부 절 25개 링크가 이를 보완하지만, 장 개요 자체도 이후 배치에서 더 풍부하게 보강할 필요가 있다.
HTML 산출물, Cloudflare 서빙, 애플리케이션 런타임 변경은 이 문서의 원천 Markdown 작업 범위가 아니었다. 현재 파일은 그 Markdown을 HTML 대응본으로 변환한 것이다.
민감 정보, 비공개 업무 자료, 고객 개인정보를 실제 LLM위키에 넣을 때는 원문 예시만으로 판단하지 말고 조직의 보안 정책과 외부 전송 가능성을 별도로 확인해야 한다.