오래 믿고 쓰는 LLM위키 운영법

이 HTML은 로컬 Markdown 원본 md/wikidocs/chapters/08-long-term-operations.md의 대응 페이지다. 내부 Markdown 링크는 생성된 HTML 대응 경로로 변환했다.

원문과 확인 범위

• 장 원문: 8장. 오래 믿고 쓰는 LLM위키 운영법
• 원천 도서: LLM위키 완벽 가이드
• 하위 원문: 8.1 위키에도 점검이 필요한 이유, 8.2 정리와 감사 흐름 만들기, 8.3 주제가 늘어날 때 관리하기, 8.4 내 업무 루틴에 붙이기
• 참고 근거: Karpathy LLM Wiki Gist, nvk/llm-wiki, nvk/llm-wiki Releases, OpenAI Codex AGENTS.md, Claude Code memory, Obsidian Graph View, Obsidian Web Clipper, WiCER

읽는 순서

1. 핵심 요지
2. 원문 구조
3. 장 수준 합성
4. 8장 운영 절차
5. 예시와 체크리스트
6. 남길 산출물
7. 검증 질문
8. 관련 문서 연결
9. 누락 또는 주의사항

핵심 요지

8장은 LLM위키를 오래 믿고 쓰기 위한 운영 장이다. 앞 장들이 반복 업무 후보를 고르고, 원천과 위키를 나누고, 질문하고, 보고서와 실행 항목을 만드는 방법을 다뤘다면, 8장은 그 결과물이 시간이 지나도 신뢰 가능한 상태로 남는지를 묻는다. 자료가 추가되고 답변이 생성되고 산출물이 만들어지는 동안 위키는 계속 변한다. 이 변화가 관리되지 않으면 읽기 좋은 요약 묶음은 오히려 위험한 판단 근거가 된다.

8.1은 점검 필요성을 설명한다. LLM 요약은 문장이 매끄럽기 때문에 조건 누락, 추정의 단정화, 출처 누락, 오래된 주장 재사용이 잘 드러나지 않는다. 따라서 위키 문장은 원천 근거, 확인 날짜, 조건, 예외, 최신성 필요 여부를 기준으로 다시 보아야 한다.

8.2는 점검을 반복 가능한 감사 흐름으로 바꾼다. 감사는 거창한 보안 이벤트가 아니라 문서 형식, 근거, 최신성, 구조, 중복, 보류 상태를 주기적으로 확인하는 운영 습관이다. 문서마다 한 문장 요약, 근거, 확인된 내용, 확인 필요, 다시 물어볼 질문이 있는지 확인하고, 근거가 약한 강한 표현은 확인 필요로 낮춘다.

8.3은 위키가 커질 때의 경계 관리다. 업무 질문, 독자, 보안 등급, 산출물 형식이 달라지면 맥락이 섞인다. 반대로 너무 잘게 나누면 중복과 관리 누락이 생긴다. 그래서 핵심 질문, 독자, 출처와 보안 등급, 산출물 형식, 장기 재질문 가능성으로 기존 위키에 둘지, 주제 폴더로 둘지, 새 주제 위키로 나눌지 결정한다.

8.4는 운영을 매일과 매주 업무 루틴에 붙인다. 매일 모든 자료를 넣지 않고 다음에도 설명할 가능성이 있고 원천 자료를 남길 수 있으며 업무 판단이나 산출물에 다시 쓰일 자료만 보관 또는 정리한다. 주 1회는 새 지식을 더하기보다 출처, 오래됨, 모순, 확인 필요를 보는 시간을 둔다.

원문 구조

네 절은 순차적이다. 8.1이 없으면 왜 점검해야 하는지 모르고 위키 문장을 그대로 믿게 된다. 8.2가 없으면 점검 필요성을 알아도 실행 루틴이 없다. 8.3이 없으면 위키가 커질수록 질문 범위가 흐려지고, 8.4가 없으면 점검은 의욕이 있을 때만 하는 별도 프로젝트가 된다.

장 수준 합성

1. 오래된 LLM위키의 위험은 오류보다 매끄러운 단정이다

8.1의 핵심은 LLM 요약이 틀릴 수 있다는 일반론이 아니다. 요약이 짧아지는 과정에서 날짜, 조건, 예외, 반대 의견, 불확실성이 빠질 수 있다는 점이다. 회의 메모의 제한적 표현이 위키 요약에서 확정 실행처럼 바뀌면 오탈자처럼 눈에 띄지 않는다. 문장이 자연스러울수록 검토자는 근거를 덜 찾게 된다.

따라서 좋은 문서의 기준은 짧고 자연스러운가에서 다시 고칠 수 있는가로 바뀐다. 출처, 날짜, 범위, 확인 필요가 있으면 문서는 조금 길어질 수 있지만 다음 점검자가 같은 판단을 다시 확인할 수 있다.

2. 신뢰도 라벨은 다음 행동을 만드는 표시다

3. 감사는 위키 루프의 일부다

8.2는 LLM위키 운영을 ingest -> query -> lint 흐름으로 본다. 여기서 lint는 특정 도구 명령으로 한정되지 않는다. 사람이 체크리스트로 문서 상태를 보는 것도 유효한 운영 lint다.

1. 형식 점검: 주요 문서에 한 문장 요약, 근거, 확인된 내용, 확인 필요, 다시 물어볼 질문이 있는지 본다.
2. 근거 점검: 중요한 주장에 원천 경로나 URL, 확인 날짜가 있고 원문보다 강하게 쓰이지 않았는지 본다.
3. 구조 점검: 새 문서가 index.md나 관련 문서에 연결되어 있는지, 비슷한 제목과 주장이 중복되어 있지 않은지 본다.

이 흐름에서 중요한 원칙은 바로 고치기보다 먼저 기록하는 것이다. 오래된 문서, 중복 후보, 근거 없는 주장을 삭제하면 흔적이 사라진다. 형식 보완 후보, 근거 보완 후보, 구조 보완 후보를 기록하면 다음 주 검토와 LLM 후속 작업의 프롬프트 재료가 된다.

4. 문서 형식은 LLM과 사람이 같은 기준으로 읽기 위한 계약이다

5. 강한 표현은 우선 감사 대상이다

가장, 반드시, 항상, 최고, 완전히 같은 표현은 자동 오류가 아니다. 다만 출처 없는 단정인지 확인하기 좋은 시작점이다. 원천이 강한 결정을 직접 말하면 근거와 함께 유지한다. 원천은 반복 발생만 말하는데 위키가 우선순위 1위라고 쓰면 확인 필요로 낮춘다. 최신 기능이나 명령을 단정하면 날짜 필요를 붙이고 공식 문서 재확인 대상으로 둔다.

6. 주제가 늘어날 때 먼저 물을 것은 같은 핵심 질문인가다

새 자료나 새 주제를 받을 때는 기존 위키의 핵심 질문과 같은지, 같은 독자와 업무 흐름에서 쓰이는지, 출처나 보안 등급이 같은지, 산출물 형식이 같은지, 3개월 뒤에도 독립적으로 다시 물어볼 가능성이 있는지를 확인한다.

7. 인벤토리는 파일 목록이 아니라 운영 현황판이다

주제 위키가 세 개를 넘으면 기억으로 관리하기 어렵다. 인벤토리는 단순 파일 목록이 아니라 각 주제가 살아 있는지, 점검이 필요한지, 다음 행동이 무엇인지 보여 주는 운영 문서다. 최소 항목은 주제 이름, 핵심 질문, 상태, 마지막 갱신일, 다음 행동, 대표 산출물이다.

8. 아카이브는 삭제가 아니라 맥락 축소다

아카이브는 쓸모없다는 판단이 아니다. 기본 질의와 유지보수 맥락에 항상 넣을 필요가 없는 주제를 분리하는 방법이다. 끝난 프로젝트, 오래된 리서치, 다른 위키에 흡수된 중복 주제, 접근 범위가 달라진 자료는 아카이브 후보가 될 수 있다. 아카이브 기록에는 주제, 날짜, 이유, 다시 볼 조건, 원천 보존 위치가 있어야 한다.

9. daily-inbox는 영구 보관함이 아니라 자료의 운명을 정하는 장치다

10. 주간 점검은 새 지식 추가 시간이 아니라 신뢰 회복 시간이다

주 1회 점검은 새 지식을 더하는 시간이 아니라 믿고 쓸 수 있는지 확인하는 시간이다. 30분 안에 이번 주 추가 자료, 많이 쓰인 위키 문서, 오래된 주장, 충돌, 다음 주 질문을 확인한다. 모든 문서를 고치려고 하면 지속되지 않으므로 한 번에 보완할 문서는 1-3개로 제한한다.

8장 운영 절차

1. 위키에서 이번 주 실제로 사용한 문서 1-3개를 고른다.
2. 각 문서가 한 문장 요약, 근거, 확인된 내용, 확인 필요, 다시 물어볼 질문을 갖췄는지 본다.
3. 중요한 문장마다 원천 자료, URL, 확인 날짜, 자료 성격이 있는지 확인한다.
4. 원문을 다시 열 수 없으면 깨진 근거로 표시하고 산출물 단정문에 쓰지 않는다.
5. 문장이 원문보다 강하면 표현을 낮춘다. 특히 강한 표현은 우선 확인한다.
6. 버전, 가격, 정책, 일정, 도구 기능, 보안 설정처럼 변할 수 있는 문장에는 날짜 필요를 붙인다.
7. 중복 문서나 연결되지 않은 문서를 찾고, 자동 검색 결과만으로 병합하지 말고 비교표를 만든다.
8. 문제를 바로 삭제하지 않고 형식 보완 후보, 근거 보완 후보, 구조 보완 후보로 기록한다.
9. 새 자료가 들어오면 기존 위키의 핵심 질문과 같은지 먼저 묻는다.
10. 핵심 질문, 독자, 보안 등급, 산출물 형식, 갱신 주기가 다르면 새 주제 위키 또는 분리 공간을 검토한다.
11. 주제가 세 개 이상이면 인벤토리를 만들고 상태, 마지막 갱신, 다음 행동, 대표 산출물을 남긴다.
12. 끝난 프로젝트나 기본 맥락에 항상 넣을 필요가 없는 주제는 아카이브 후보로 둔다.
13. 아카이브할 때는 날짜, 이유, 다시 볼 조건을 기록하고 원천 자료를 삭제하지 않는다.
14. 매일 업무 끝 5분 동안 daily-inbox에서 자료 후보를 보관, 정리, 보류, 버림으로 나눈다.
15. 주 1회 30분 안에 출처, 오래됨, 모순, 확인 필요 표시를 점검한다.
16. LLM 도구와 연결할 때는 AGENTS.md 또는 CLAUDE.md에 운영 규칙을 두되 결과 검토를 생략하지 않는다.
17. 루틴이 무거워지면 자료 입력 기준과 점검 범위를 줄인다. 목적은 위키 관리 자체가 아니라 다음 업무에서 반복 설명을 줄이는 것이다.

예시와 체크리스트

문서 감사 체크리스트

주제 분리 판단표

daily-inbox 템플릿

# daily-inbox.md

## 오늘 넣을 후보

| 시간 | 자료 | 출처 | 판단 | 이유 | 다음 행동 |
| --- | --- | --- | --- | --- | --- |
|  |  |  | 보관/정리/보류/버림 |  |  |

## 오늘 정리할 문서

- 

## 확인 필요

- 

## log.md에 남길 항목

- 

주간 감사 로그 템플릿

# 주간 LLM위키 점검

## 확인 날짜

YYYY-MM-DD

## 이번 주 추가 자료

| raw 자료 | 출처 | 확인 날짜 | 상태 | 보완 필요 |
| --- | --- | --- | --- | --- |

## 문서 형식 보완 후보

| 문서 | 빠진 항목 | 조치 |
| --- | --- | --- |

## 근거 보완 후보

| 문장 | 현재 상태 | 조치 |
| --- | --- | --- |

## 구조 보완 후보

| 문서 | 문제 | 조치 |
| --- | --- | --- |

## 다음 주 질문

- 

주제 인벤토리 템플릿

# LLM위키 인벤토리

| 주제 | 핵심 질문 | 상태 | 마지막 갱신 | 다음 행동 | 대표 산출물 |
| --- | --- | --- | --- | --- | --- |
|  |  | 운영 중/점검 필요/아카이브 후보 |  |  |  |

## 아카이브 기록

| 주제 | 아카이브 날짜 | 이유 | 다시 볼 조건 | 원천 보존 위치 |
| --- | --- | --- | --- | --- |

확장 중단 신호

8장에서 남길 산출물

검증 질문

• 위키 문장을 위키에 적혀 있다는 이유만으로 믿고 있지 않은가?
• 문서마다 한 문장 요약, 근거, 확인된 내용, 확인 필요, 다시 물어볼 질문이 있는가?
• 핵심 주장마다 원천 자료, URL, 확인 날짜, 자료 성격 중 하나 이상이 있는가?
• 원문에는 조건부였던 내용이 위키에서 확정처럼 쓰이지 않았는가?
• 최신성이 필요한 버전, 명령어, 가격, 정책, 일정, 보안 설정에 확인 날짜가 있는가?
• 강한 표현이 실제 근거를 갖는가, 아니면 확인 필요로 낮춰야 하는가?
• 연결되지 않은 문서나 비슷한 중복 문서를 찾아 기록했는가?
• 중복 후보를 바로 삭제하지 않고 비교와 보류 이유를 남겼는가?
• 새 자료가 기존 위키의 핵심 질문과 같은지 먼저 확인했는가?
• 독자, 보안 등급, 산출물 형식, 갱신 주기가 다른 자료를 같은 위키에 억지로 넣고 있지 않은가?
• 주제 수가 늘었을 때 인벤토리로 상태와 다음 행동을 관리하는가?
• 아카이브할 때 날짜, 이유, 다시 볼 조건을 기록했는가?
• daily-inbox가 영구 보관함으로 변하지 않고 보관, 정리, 보류, 버림을 결정하는가?
• 주간 점검이 모든 문서를 고치려는 과한 작업이 아니라 실제 사용 문서 1-3개 점검으로 유지되는가?
• AGENTS.md나 CLAUDE.md 같은 규칙 파일을 결과 보증 장치로 과신하지 않는가?
• 위키 운영이 업무를 줄이고 있는가, 아니면 도구 설정과 문서 관리 자체가 더 큰 일이 되었는가?

관련 문서 연결

• 통합 루트: 책 전체를 raw, wiki, question, evidence, output, audit 흐름으로 통합한 안내 문서다.
• 7장. 위키에서 업무 산출물 만들기: 8장에서 감사할 보고서 주장, 실행 항목, output 근거 연결을 만든다.
• 7.2 업무 보고서 만들기: 주장-근거 매트릭스를 만들고, 8장에서 그 근거와 최신성을 다시 점검한다.
• 7.3 다음 행동으로 연결하기: 실행 항목의 담당자, 기한, 완료 기준, 근거를 확인한다.
• 8.1 위키에도 점검이 필요한 이유: 요약 왜곡, 출처 누락, 오래된 주장, 신뢰도 표시를 다룬다.
• 8.2 정리와 감사 흐름 만들기: 형식, 근거, 구조 점검과 정리 후보 기록을 만든다.
• 8.3 주제가 늘어날 때 관리하기: 주제 분리 기준, 인벤토리, 아카이브를 관리한다.
• 8.4 내 업무 루틴에 붙이기: daily-inbox, 주간 점검, 개인 운영 규칙을 업무 리듬에 붙인다.
• 2.3 좋은 위키 문서의 조건: 8.2의 형식 점검이 요구하는 출처 블록과 확인 필요 구조의 기반이다.
• 5.1 자료를 넣기 전에 정할 기준: 8.4의 daily-inbox와 민감 정보 보류 기준으로 이어진다.
• 6.2 답변의 근거 확인하기: 8.1의 신뢰도 라벨과 8.2의 근거 점검을 문장 단위 검증으로 확장한다.
• 6.3 답변을 다시 위키에 반영하기: 검증된 답변만 위키와 log에 반영하는 기준을 제공한다.

누락 또는 주의사항

• 원문에는 Mermaid 도해, Bash/Zsh 명령, Python 예제, daily-inbox와 inventory 예시가 나온다. 이 장 개요 페이지는 명령을 장문 복제하지 않고 운영 목적과 성공 기준을 절차, 판단표, 템플릿으로 요약했다.
• nvk/llm-wiki의 /wiki, inventory, archive, lint 관련 설명은 원문 확인일 기준 구현체 예시다. 실제 도입 전에는 현재 README, Releases, 설치된 도움말, 조직 보안 기준을 다시 확인해야 한다.
• AGENTS.md와 CLAUDE.md는 LLM이 운영 규칙을 참고하도록 돕는 파일이지 결과 품질이나 보안을 강제하는 장치가 아니다. raw 보존, 출처 표시, 확인 필요, log 갱신은 결과물에서 다시 검토해야 한다.
• Obsidian, Codex, Claude Code, 플러그인, 외부 LLM 호출, 웹 수집을 업무 시스템에 연결할 때는 저장 위치, 외부 전송, 접근 권한, 개인정보 처리 기준을 별도로 확인해야 한다.
• WiCER는 원문에서 제한된 근거로 언급된 프리프린트다. 검증 없는 지식 컴파일의 위험을 설명하는 참고로만 사용하고, 확정된 운영 규칙처럼 단정하지 않는다.
• 아카이브는 삭제가 아니다. 원천 자료와 아카이브 기록 없이 문서를 제거하면 이후 검증과 회고가 어려워진다.