LLM Wiki Reference Analyses

Core thesis

RAG보다 위키가 필요한 순간

RAG는 질문 시점의 검색과 답변 생성에 강하다. 그러나 반복 업무에서는 답변마다 생기는 구조, 비교, 결정, 예외, 근거 라벨이 다음 작업의 출발점으로 남아야 한다. 이 컬렉션은 그 지점을 LLM위키의 출발점으로 본다.

위키가 필요한 조건은 원천 확인일, 결정 이력, 예외 조건, 산출물 재사용, 주기적 감사가 필요할 때다.

Architecture

원천과 해석의 분리

반복되는 구조는 raw/, wiki/, rules, index, log, output, lint, review다. 원천은 불변 근거이고, 위키는 LLM이 생성하고 사람이 검증하는 재사용 지식이다. 규칙 파일은 모델이 매번 다른 방식으로 문서를 만들지 않도록 하는 운영 계약이다.

Operating loop

질문, 검증, 반영, 감사

좋은 질문은 검색어가 아니라 업무 요청이다. 답변은 문장 단위로 원천 근거, 위키 근거, 제한적 확인, 추정, 출처 없음, 최신성 확인 필요로 나눠야 한다. 검증된 내용만 결정 로그, 주제 문서, 반복 질문 템플릿으로 반영한다.

읽는 목적별 경로

1. 처음 만드는 사람

1.1 지식이 남지 않는 이유에서 반복 설명이 왜 사라지는지 확인한다.
1.2 LLM위키 정의와 1.3 결과물에서 최소 산출물을 잡는다.
2.1 세 층과 2.2 폴더 구조로 원천, 위키, 규칙의 책임을 분리한다.
4.1 업무 주제, 4.2 초기화, 4.3 첫 질문으로 첫 실험을 만든다.

2. 도구 선택이 막힌 사람

3장 방식 선택으로 수동 Markdown, 에이전트, CLI, 데스크톱 앱의 기준선을 본다.
3.1 시작 방식과 3.2 도구 선택에서 입력 포맷, 자동화, 검증, 보안 조건을 비교한다.
WikiDocs 3.1 비교 분석으로 Node.js CLI, Python CLI, 데스크톱 앱의 실행 흐름과 최소 검증 산출물을 확인한다.

3. 자료가 쌓였지만 믿기 어려운 사람

5.1 인입 기준에서 포함, 제외, 민감 정보, 최신성 기준을 먼저 정한다.
5.2 자료 수집으로 원천 카드에 제목, 출처, 확인일, 수집 이유를 남긴다.
5.3 위키 문서화에서 다음 질문 기준으로 문서를 나눈다.
6.2 근거 확인과 8.2 감사 흐름으로 출처, 최신성, 중복, 링크를 점검한다.

4. 보고서와 실행 항목이 필요한 사람

6.1 좋은 질문에서 자료 범위, 목적, 판단 기준, 출력 형식을 명시한다.
7.1 산출물 목적으로 독자와 결정을 한 줄로 정한다.
7.2 업무 보고서에서 주장-근거 매트릭스를 만들고, 7.3 다음 행동에서 담당자, 기한, 완료 기준, 근거를 붙인다.

5. UX/UI 조직과 Obsidian 기반 업무 시스템

Obsidian UX/UI 리포트는 LLM위키를 디자인 업무의 로컬 지식 시스템으로 확장한다. 공개 레퍼런스, 내부 리서치, 디자인 시스템, 사용성 평가 기준, 스킬 문서를 Markdown으로 축적하면 에이전트는 단순 답변 도구가 아니라 반복 가능한 실무 실행자로 바뀐다. 단, 자동 자막 기반 분석이므로 도구명과 수치성 주장은 별도 검증 대상으로 남겨야 한다.

컬렉션이 합의하는 LLM위키 방법론

1단계: 후보를 좁힌다

말투나 출력 형식만 반복된다면 프롬프트 템플릿으로 충분할 수 있다. LLM위키 후보는 출처, 확인일, 결정 이력, 예외 조건, 최신성, 보안 조건이 필요한 반복 업무다. 첫 주제는 다음 주 실제 산출물에 쓸 수 있고 자료 3-5개로 시작 가능한 질문이어야 한다.

2단계: 구조를 먼저 계약한다

raw/는 읽기 전용 원천, wiki/는 재사용 가능한 해석, output/은 보고서와 실행 계획, index.md는 탐색 지도, log.md는 처리 기록이다. AGENTS.md나 동등한 rules 파일에는 목적, 폴더 책임, 출처 처리, 링크 규칙, 불확실성 표시, 검토 절차가 들어가야 한다.

3단계: 자료 인입보다 기준을 먼저 둔다

자료를 많이 넣는 것은 성공 기준이 아니다. 포함 범위, 제외 범위, 민감 정보, 신뢰도, 최신성, 이 자료가 답할 질문을 먼저 적어야 한다. 그래야 LLM이 원천, 요약, 추정, 결정 문장을 섞지 않는다.

4단계: 질문을 업무 요청으로 만든다

좋은 질문은 자료 범위, 시간 범위, 목적, 판단 기준, 출력 형식, 검증 조건을 포함한다. 이렇게 해야 답변이 일반론으로 흐르지 않고, 근거 라벨과 산출물 작성으로 이어진다.

5단계: 답변을 문장 단위로 검증한다

답변은 원천 근거, 위키 근거, 제한적 확인, 추정, 출처 없음, 최신성 확인 필요로 나눈다. 보고서 단정문에는 출처 없음과 추정을 섞지 않는다. 최신성이 중요한 도구, 정책, 가격, 버전 정보는 재확인 날짜가 필요하다.

6단계: 검증된 내용만 다시 위키에 반영한다

좋은 답변 전체를 붙여 넣지 않는다. 결정은 결정 로그로, 새 지식은 주제 문서로, 반복 질문은 템플릿으로, 확인하지 못한 내용은 확인 필요 항목으로 보낸다. 반영 후 index와 log를 갱신하는 것이 루프의 종료 조건이다.

7단계: 산출물과 감사 루틴을 붙인다

요약, 보고서, 실행 계획은 목적과 독자가 다르다. 보고서는 주장-근거 매트릭스가 필요하고 실행 항목에는 담당자, 기한, 완료 기준, 근거가 필요하다. 장기 운영에서는 형식, 근거, 최신성, 중복, 충돌, 링크, daily-inbox를 주기적으로 감사한다.

상위 분석과 외부 레퍼런스

LLM Wiki 통합 분석본
GeekNews, WikiDocs, YouTube 튜토리얼을 실행 가능한 운영 모델로 통합 GeekNews LLM-Wiki 분석
RAG와 LLM위키 차이, 커뮤니티 논쟁, Markdown 지식 저장소 관점 WikiDocs 3.1 시작 방식 비교
Node.js CLI, Python CLI, 데스크톱 앱의 선택 기준과 검증 체크 Karpathy LLM Wiki 튜토리얼 분석
Obsidian vault, raw/wiki/rules, 첫 ingest, lint workflow Obsidian UX/UI 리포트
디자인 조직의 로컬 지식, 스킬 문서, 에이전트 업무 운영 모델 LLM위키 완벽 가이드 루트
8개 장과 25개 하위 절을 연결한 책 전체 방법론

WikiDocs 책 구조: 8장 운영 로드맵

1장. LLM위키가 필요한 이유

반복 설명이 왜 지식으로 남지 않는지 진단하고 첫 후보를 고른다.

1.1 · 1.2 · 1.3

2장. LLM위키의 기본 구조

raw, wiki, rules의 신뢰 경계와 질문 중심 폴더 구조를 만든다.

2.1 · 2.2 · 2.3

3장. 내게 맞는 방식 고르기

수동, 에이전트, CLI, 데스크톱 도구를 환경과 검증 조건으로 고른다.

3.1 · 3.2 · 3.3

4장. 첫 번째 주제 위키 만들기

검증 가능한 업무 질문으로 첫 주제를 줄이고 초기 구조와 첫 질문을 만든다.

4.1 · 4.2 · 4.3

5장. 자료를 지식으로 바꾸기

수집 기준, 원천 카드, 주제 문서로 자료를 다시 쓰기 좋은 지식으로 바꾼다.

5.1 · 5.2 · 5.3

6장. 질문하고 검증하기

질문을 업무 요청으로 만들고 답변 문장을 근거 라벨로 검증한다.

6.1 · 6.2 · 6.3

7장. 업무 산출물 만들기

위키 지식을 보고서, 회의 자료, 실행 항목으로 변환한다.

7.1 · 7.2 · 7.3

8장. 오래 믿고 쓰는 운영법

감사, 정리, 주제 분리, daily-inbox, 주간 루틴으로 신뢰를 유지한다.

8.1 · 8.2 · 8.3 · 8.4

실무 의사결정 표

질문	위키로 갈 조건	먼저 볼 문서
프롬프트 템플릿이면 충분한가?	출처, 확인일, 예외, 결정 이력, 보안 기준이 필요하면 위키 후보다.	1.1, 1.2
어떤 도구로 시작할까?	입력 문서 형식, 사용자 숙련도, 자동화 필요성, 민감정보 이동 경로, 검증 산출물 2개 이상을 기준으로 고른다.	3.2, 도구 비교
자료를 넣어도 되는가?	포함/제외 범위, 확인일, 신뢰도, 민감정보 처리, 사용 질문이 적혀 있어야 한다.	5.1, 5.2
답변을 보고서에 써도 되는가?	핵심 문장마다 근거 위치가 있고 추정과 확인 필요가 단정문에서 분리되어야 한다.	6.2, 7.2
주제를 분리해야 하는가?	핵심 질문, 독자, 민감도, 산출물 형식, 갱신 주기가 달라지면 새 주제 후보다.	8.3

전체 페이지 커버리지

아래 링크는 Markdown 상대 경로를 HTML 출력 경로로 바꾼 안정 링크다. 원천 Markdown 링크를 직접 노출하지 않는다. 전체 파일 관계와 커버리지 확인은 tree.html에서 본다.

LLM Wiki 통합 분석본 WikiDocs 3.1 시작 방식 비교 분석 UX/UI 디자이너 Obsidian 리포트 GeekNews LLM-Wiki 분석 Karpathy LLM Wiki 튜토리얼 분석 WikiDocs 루트 통합 분석 WikiDocs 서빙 인덱스 1장. LLM위키가 필요한 이유 2장. LLM위키의 기본 구조 3장. 방식 고르기 4장. 첫 주제 위키 5장. 자료를 지식으로 6장. 질문과 검증 7장. 업무 산출물 8장. 장기 운영 1.1 지식이 남지 않는 이유 1.2 LLM위키란 무엇인가 1.3 만들 결과물 2.1 지식이 쌓이는 세 층 2.2 좋은 폴더 구조 2.3 좋은 위키 문서 3.1 시작 방식 비교 3.2 도구 선택 기준 3.3 실습 환경 4.1 업무 주제 정하기 4.2 위키 초기화 4.3 첫 질문 5.1 인입 기준 5.2 자료 수집 5.3 위키 문서 정리 6.1 좋은 질문 6.2 답변 근거 확인 6.3 답변 반영 7.1 산출물 목적 7.2 업무 보고서 7.3 다음 행동 8.1 감사가 필요한 이유 8.2 정리와 감사 흐름 8.3 주제 확장 관리 8.4 업무 루틴에 붙이기

검증과 주의

이 홈페이지는 로컬 Markdown 분석본을 근거로 합성했으며, 외부 원문이 바뀌었는지는 별도로 재확인해야 한다.
도구 설치 명령, 패키지 버전, API 조건, 데스크톱 앱 기능은 시간에 따라 바뀔 수 있으므로 실행 전 공식 저장소와 현재 버전을 확인해야 한다.
Obsidian UX/UI 리포트는 자동 생성 자막 기반 분석이다. 수치성 주장과 제품별 우위 평가는 운영 판단 전에 별도 검증이 필요하다.
이 페이지는 선언된 html/index.html 산출물만 작성한다. 개별 페이지와 트리 페이지는 같은 상대 링크 규칙으로 생성될 것을 전제로 링크한다.