핵심 요약
매일 5분
모든 자료를 위키에 넣지 않는다. 오늘 생긴 회의록, 메모, 웹 문서, LLM 답변, 산출물 후보의 운명을 보관, 정리, 보류, 버림으로 정한다.
주간 30분
새 지식을 많이 더하는 시간이 아니라 신뢰를 회복하는 시간이다. 최근 실제로 쓴 wiki 문서 1-3개만 골라 출처, 오래됨, 모순, 확인 필요, 링크를 점검한다.
세 공간 유지
캘린더, 할 일 앱, 노트 앱, LLM 도구, 보고서 폴더를 붙이더라도 입력함, 위키, 산출물의 책임을 섞지 않는다. 원본은 raw, 파생 지식은 wiki, 제출·실행 문서는 output이다.
확장 중단 신호
매일 입력이 10분을 넘거나, 주간 점검을 건너뛰거나, 출처 없는 요약과 도구 설정 시간이 늘면 자동화를 더하기보다 입력 기준과 점검 범위를 줄인다.
8.4의 목표는 완벽한 지식 관리가 아니다. 다음 주의 내가 같은 배경 설명을 반복하지 않아도 되는 상태를 만드는 것이다. 그래서 이 절은 LLM위키 구축의 마지막 단계라기보다 운영 비용을 낮추는 기준선이다.
원문 구조와 실무 의미
| 원문 절 | 핵심 내용 | 실무 의미 |
|---|---|---|
| 도입부 | 위키는 만든 순간 완성되는 문서함이 아니며 업무 변화에 맞춰 갱신되어야 한다. | 목표를 자료 축적이 아니라 반복 설명 감소로 둔다. |
| 매일 넣을 자료 정하기 | 다시 쓸 가능성, 원천 보존 가능성, 업무 판단 재사용 가능성을 기준으로 한다. | 자료를 모두 저장하지 않고 후보의 다음 위치를 빠르게 정한다. |
| daily-inbox 흐름 | 오늘 넣을 후보, 오늘 정리할 문서, 확인 필요 항목을 나눈다. | daily-inbox.md는 영구 보관함이 아니라 분류 장치다. |
| 주간 점검 흐름 | ingest -> query -> lint를 작은 루프로 반복한다. | 도구 명령 여부와 무관하게 사람이 출처, 오래됨, 모순을 확인한다. |
| 확인 필요 자동 수집 | 확인 필요, 출처 없음, TODO 표시를 모은다. | 자동화는 후보를 모을 뿐 품질과 보안을 보장하지 않는다. |
| 개인 업무 시스템 확장 | 입력함, 위키, 산출물을 기준으로 업무 도구를 연결한다. | 도구별 동기화보다 자료 책임 경계가 먼저다. |
| 운영 규칙 만들기 | Codex의 AGENTS.md, Claude Code의 CLAUDE.md에 원칙을 둘 수 있다. | 규칙 파일은 반복 설명을 줄이는 문맥이며 결과 검토를 대체하지 않는다. |
| 확장 중단 신호 | 입력 과다, 점검 생략, 출처 없는 요약, 도구 설정 과다, output 단절을 본다. | 루틴이 커지면 자동화보다 범위 축소가 우선이다. |
매일·주간 루틴 설계
1. 매일 입력의 기준은 다시 쓸 업무 맥락이다
매일 생기는 자료를 모두 위키에 넣으면 raw/는 커지지만 질문에는 약해진다. 후보 자료가 다음에도 LLM에게 설명될 가능성이 있고, 원천 자료를 남길 수 있으며, 업무 판단이나 산출물에 다시 쓰일 가능성이 있을 때만 처리한다. 민감 정보, 권한 불명확 자료, 원문 없는 기억 조각은 바로 wiki 문서가 아니라 보류 또는 확인 필요로 둔다.
| 자료 후보 | 넣는 조건 | 먼저 둘 위치 | 바로 넣지 않는 경우 |
|---|---|---|---|
| 회의록 | 결정 사항, 담당자, 기한, 확인 필요가 있다. | raw/meetings/ | 공유 범위나 민감 안건이 불명확하다. |
| 반복 업무 규칙 | 다음 요청에도 같은 설명이 필요하다. | wiki/rules/ 또는 wiki/concepts/ | 개인 취향에 가깝고 재사용 가능성이 낮다. |
| 공식 문서 | 업무 판단의 근거로 쓰인다. | raw/references/ | 확인 날짜와 버전이 없다. |
| 고객 피드백 | 반복 패턴이나 우선순위 판단에 쓰인다. | raw/feedback/ | 개인정보, 계약 정보, 고객 원문이 그대로 있다. |
| 보고서 초안 | 다음 보고서 형식의 기준이 된다. | output/ | 근거가 연결되지 않은 일회성 문장이다. |
2. daily-inbox는 운명 결정표다
daily-inbox.md의 목적은 매일 완성된 wiki 문서를 만드는 것이 아니라 후보의 다음 위치를 정하는 것이다. 보관은 원천성을 살려 raw/에 두는 결정이고, 정리는 바로 질문과 산출물에 다시 쓸 수 있어 wiki/나 기존 문서 갱신으로 보내는 결정이다. 보류는 권한, 출처, 민감 정보, 최신성 확인이 남은 상태이며, 버림은 업무 지식으로 재사용 가능성이 낮다는 판단이다.
| 판단 | 의미 | 다음 위치 | 기록할 것 |
|---|---|---|---|
| 보관 | 원천성은 있지만 당장 정리할 필요는 낮다. | raw/ | 수집 이유와 확인일 |
| 정리 | 다음 질문이나 산출물에 바로 다시 쓸 가능성이 높다. | wiki/ 또는 기존 문서 | 근거 raw와 반영 위치 |
| 보류 | 가치가 있을 수 있지만 권한, 출처, 민감 정보, 최신성이 불명확하다. | inbox/ 또는 확인 필요 목록 | 보류 이유와 필요한 확인 |
| 버림 | 업무 지식으로 재사용 가능성이 낮다. | 저장하지 않음 | 반복 혼입되면 제외 기준 |
3. 주간 점검은 신뢰 회복 루프다
주 1회 점검은 ingest, query, lint를 30분 안에 작게 반복한다. 이번 주 새 자료를 확인하고, 많이 쓴 wiki 문서 1-3개를 읽고, 실제 업무 질문 하나를 던져 답변 품질을 본 뒤, 확인 필요와 다음 행동을 남긴다.
| 시간 | 작업 | 남길 것 | 실패 신호 |
|---|---|---|---|
| 5분 | 이번 주 daily-inbox와 새 raw 후보 확인 | 보관, 정리, 보류, 버림 결정 | inbox를 그대로 다음 주로 넘긴다. |
| 10분 | 많이 쓴 wiki 문서 1-3개 점검 | 출처 누락, 오래된 주장, 확인 필요 | 범위가 커서 아무 것도 고치지 못한다. |
| 5분 | 실제 업무 질문 하나 실행 | 근거가 약한 답변과 다음 자료 필요 | 위키 밖 일반론이 주 답변이 된다. |
| 5분 | 확인 필요, 출처 없음, TODO 수집 | 주간 점검 output 또는 log | 확인 필요가 문서 속에 숨어 있다. |
| 5분 | 다음 주 행동 1-3개 결정 | log.md 갱신 | 점검이 감상으로 끝난다. |
보안과 권한: 로컬 Markdown으로 저장하더라도 LLM 도구나 플러그인으로 처리하면 외부 모델 호출, 웹 접근, 플러그인 권한이 개입할 수 있다. 고객 정보, 개인정보, 계약 정보, 비공개 코드는 조직 기준을 먼저 확인해야 한다.
개인 업무 시스템 연결
8.4의 확장은 도구를 많이 붙이는 일이 아니라 어디에 붙일지를 정하는 일이다. 회의가 끝나면 원문 회의록은 raw, 회의에서 정한 반복 기준은 wiki, 회의 후 실행 계획은 output에 가깝다. 이 경계가 없으면 캘린더, 할 일 앱, 노트 앱, 보고서 폴더가 같은 내용을 조금씩 중복 보관하게 된다.
| 업무 도구 | 연결 방식 | 지켜야 할 경계 |
|---|---|---|
| 캘린더 | 회의 후 raw 회의록 후보와 결정 로그를 만든다. | 일정 자체를 wiki 지식으로 착각하지 않는다. |
| 할 일 앱 | output의 실행 항목을 업무 카드로 옮긴다. | 완료 상태와 결정 근거를 분리한다. |
| 노트 앱 | 빠른 메모를 daily-inbox 후보로 모은다. | 노트가 raw인지 wiki인지 표시한다. |
| LLM 도구 | raw를 wiki로 정리하고 output 초안을 만든다. | raw 수정 금지, 근거 표시, 확인 필요를 요구한다. |
| 보고서 폴더 | 제출본과 공유본을 output 역할로 둔다. | 보고서를 원천 자료나 기준 문서로 쓰지 않는다. |
운영 규칙 파일의 역할
Codex의 AGENTS.md나 Claude Code의 CLAUDE.md에는 raw 원본 보존, wiki 작성 시 출처와 확인 필요 표시, output 생성 시 근거와 후속 반영 위치, 주간 점검 항목을 둘 수 있다. 다만 이 파일은 반복 설명을 줄이는 문맥이다. 결과물이 실제로 출처, 최신성, 민감 정보 기준을 지켰는지는 별도로 확인해야 한다.
| 규칙 파일에 쓸 내용 | 결과물에서 확인할 증거 |
|---|---|
| raw는 임의로 수정하지 않는다. | raw 파일 변경이 없거나 변경 이력이 log에 있다. |
| wiki 문서에는 출처와 확인 필요를 남긴다. | 핵심 주장에 raw, URL, 확인일, 확인 필요가 있다. |
| output에는 목적과 근거와 후속 반영 위치를 둔다. | 문서 정보 블록과 관련 wiki/raw 링크가 있다. |
| 주간 점검은 출처, 최신성, 중복, 링크를 본다. | 점검 로그와 다음 행동이 남아 있다. |
| 민감 정보는 외부 호출 전 확인한다. | 보류 항목과 익명화 기준이 분리되어 있다. |
확장 중단 신호
| 신호 | 의미 | 줄이는 방법 |
|---|---|---|
| 매일 입력이 10분을 넘는다. | 입력 기준이 너무 넓다. | 자료 후보를 줄이고 버림 기준을 강화한다. |
| 주간 점검을 자주 건너뛴다. | 점검 범위가 크거나 보상이 약하다. | 문서 1개, 확인 필요 3개만 보는 루틴으로 줄인다. |
| 출처 없는 요약이 늘어난다. | 빠른 정리가 검증을 앞지른다. | 새 wiki 작성보다 기존 핵심 문서 출처 보강을 우선한다. |
| 도구 설정에 더 많은 시간을 쓴다. | 목적이 지식 운영에서 도구 관리로 바뀐다. | 수동 Markdown 기준선으로 돌아간다. |
| output이 wiki와 끊어진다. | 산출물이 다음 질문의 재료가 되지 않는다. | output 상단에 근거와 후속 반영 위치를 필수로 둔다. |
| inbox가 영구 보관함이 된다. | 분류 결정을 미룬다. | 보류 기한과 폐기 기준을 둔다. |
템플릿과 체크리스트
daily-inbox 판단표
| 날짜 | 후보 자료 | 자료 성격 | 다음에도 쓸 가능성 | 원천 보존 | 민감 정보 | 판단 | 다음 위치 | 확인 필요 |
|---|---|---|---|---|---|---|---|---|
| YYYY-MM-DD | 회의록 / 메모 / 웹 문서 / LLM 답변 / output | 높음 / 중간 / 낮음 | 예 / 아니오 | 있음 / 없음 / 확인 필요 | 보관 / 정리 / 보류 / 버림 | raw/..., wiki/..., output/... |
주간 30분 점검표
| 시간 | 작업 | 산출물 |
|---|---|---|
| 5분 | 이번 주 daily-inbox와 새 raw 후보 확인 | 보관, 정리, 보류, 버림 정리 |
| 10분 | 많이 쓴 wiki 문서 1-3개 점검 | 출처 누락, 오래된 주장, 확인 필요 목록 |
| 5분 | 실제 업무 질문 1개 실행 | 근거가 약한 답변과 다음 자료 필요 |
| 5분 | 확인 필요, 출처 없음, TODO 모으기 | output/weekly-review-YYYY-MM-DD.md |
| 5분 | 다음 주 행동 1-3개 결정 | log.md 갱신 |
실무 적용 절차
- 현재 LLM위키의 목적을 한 문장으로 다시 쓴다.
- 매일 자료 입력 시간을 5분으로 제한한다.
- 하루 동안 생긴 회의록, 메모, 웹 문서, LLM 답변, 보고서 초안, 실행 항목을 후보로 모은다.
- 각 후보에 다음에도 설명할 가능성, 원천 보존 가능성, 업무 판단 재사용 가능성을 표시한다.
- 민감 정보, 권한, 외부 호출 가능성이 불명확한 후보는 보류한다.
- 후보를 보관, 정리, 보류, 버림으로 나눈다.
- 보관은 raw에 넣고 출처, 확인일, 자료 성격을 남긴다.
- 정리는 기존 wiki 문서에 반영하거나 새 문서 후보로 둔다. 핵심 주장에는 근거를 붙인다.
- 보류는 필요한 확인, 담당자, 정책, 익명화 여부를 함께 적는다.
- 주 1회 30분 점검 시간을 캘린더에 둔다.
- 점검에서는 이번 주 새 raw, 많이 쓴 wiki 문서, 새 output, 확인 필요 항목을 본다.
- 실제 업무 질문 하나를 위키에 던져 답변의 근거와 확인 필요를 본다.
- output을 만든 경우 문서 상단에 목적, 생성 날짜, 근거 위키, 원천 자료, 확인 필요, 후속 반영 위치를 넣는다.
- 확장 중단 신호가 보이면 도구를 추가하지 말고 자료 투입 기준과 점검 범위를 줄인다.
체크리스트
- [ ] 오늘 생긴 자료 후보를 모두 위키에 넣으려 하지 않았다.
- [ ] 후보별로 다음에도 설명할 가능성과 원천 보존 가능성을 표시했다.
- [ ] 민감 정보와 권한이 불명확한 자료를 보류했다.
- [ ] daily-inbox가 영구 보관함처럼 커지지 않는다.
- [ ] 주간 점검 시간을 30분 안으로 제한했다.
- [ ] 많이 쓰인 wiki 문서 1-3개만 점검했다.
- [ ] 출처 없는 문장, 오래된 주장, 확인 필요, 깨진 링크를 찾았다.
- [ ] 자동 수집 결과를 최종 판단이 아니라 후보 목록으로 다뤘다.
- [ ] output에 목적, 생성 날짜, 근거 위키, 원천 자료, 확인 필요, 후속 반영 위치가 있다.
- [ ] 확장 중단 신호를 확인하고 필요하면 루틴을 줄였다.
LLM에게 던질 좋은 질문
- 오늘 생긴 자료 후보를 보관, 정리, 보류, 버림으로 나눠 주세요. 기준은 다음에도 설명할 가능성, 원천 보존 가능성, 업무 판단 재사용 가능성, 민감 정보 여부입니다.
- 이번 주 많이 쓴 wiki 문서 3개를 기준으로 주간 점검 목록을 만들어 주세요. 출처 없음, 오래된 주장, 확인 필요, 깨진 링크, 다음 행동을 표로 정리해 주세요.
- wiki 폴더에서 확인 필요, 출처 없음, TODO 표시가 있는 문장을 모아 주간 점검 output 초안으로 정리해 주세요.
- 이 output 문서가 위키와 연결되어 있는지 점검해 주세요. 목적, 생성 날짜, 근거 위키, 원천 자료, 확인 필요, 후속 반영 위치가 빠진 곳을 표시해 주세요.
- 현재 개인 업무 시스템에서 캘린더, 할 일 앱, 노트 앱, LLM 도구, 보고서 폴더가 raw, wiki, output, log 중 어디에 연결되는지 지도처럼 정리해 주세요.
관련 문서와 한계
관련 문서
- 8장. 오래 믿고 쓰는 LLM위키 운영법: 8.4를 8장 전체 운영 결론 안에 둔다.
- 8.1 위키에도 점검이 필요한 이유: 매끄러운 요약, 출처 누락, 오래된 주장 점검이 필요한 이유를 설명한다.
- 8.2 정리와 감사 흐름 만들기: 형식, 근거, 최신성, 중복, 링크 감사 흐름을 제공한다.
- 8.3 주제가 늘어날 때 관리하기: 주제가 늘어날 때 같은 위키에 둘지 새 주제로 나눌지 판단한다.
- 7.3 다음 행동으로 연결하기: output에서 실행 항목, 회의 준비, 후속 위키 반영으로 이어지는 구조를 제공한다.
- 7.1 산출물의 목적 정하기: output의 목적, 독자, 포함/제외 항목을 정한다.
- 6.3 답변을 다시 위키에 반영하기: 검증된 답변을 결정, 새 지식, 템플릿, index, log로 반영한다.
- 6.2 답변의 근거 확인하기: 답변을 문장별 근거와 확실성으로 검증한다.
- 5.1 자료를 넣기 전에 정할 기준: daily-inbox에서 보관과 보류를 가르는 기준을 제공한다.
- 5.2 자료 수집하기: raw 자료의 출처, 확인일, 자료 성격, 처리 이력을 남기는 방법을 제공한다.
- 5.3 위키 문서로 정리하기: 보관된 raw를 질문 가능한 wiki 문서로 정리한다.
- 2.1 지식이 쌓이는 세 층: raw, wiki, rules의 신뢰 경계를 설명한다.
- 2.2 좋은 폴더 구조 이해하기: index, log, output 역할을 구조적으로 설명한다.
- 2.3 좋은 위키 문서의 조건: 출처, 재사용성, 링크 기준을 제공한다.
한계와 확인 필요
- 이 문서는 2026-06-06 KST에 확인된 WikiDocs 원문 기반 분석을 HTML로 재구성했다. 원문 세부 표현과 최신 수정 여부는 WikiDocs 원문에서 다시 확인해야 한다.
- daily-inbox, 주간 점검, 확인 필요 자동 수집, 개인 업무 시스템 확장 예시는 학습용이다. 실제 업무에서는 고객 정보, 개인정보, 계약 조건, 내부 정책, 비공개 코드가 포함될 수 있으므로 저장 위치와 외부 LLM 호출 여부를 먼저 확인해야 한다.
AGENTS.md,CLAUDE.md, 템플릿, 자동 수집 스크립트는 작업 기준을 전달하거나 점검 후보를 찾는 도구일 뿐 품질과 보안을 자동 보장하지 않는다.ingest,query,lint,audit같은 표현은 구현체마다 다르게 제공될 수 있다. 이 페이지에서는 운영 단계 이름으로 재구성했다.- 루틴이 부담스러우면 더 많은 자동화를 붙이기보다 자료 투입 기준과 점검 범위를 줄이는 편이 안전하다.
이 절의 완료 기준
- 매일 넣을 자료와 버릴 자료를 구분하는 기준을 갖고 있다.
- daily-inbox 또는 동등한 입력 목록에서 보관, 정리, 보류, 버림 판단을 한다.
- raw 자료에는 출처, 확인일, 자료 성격이 남는다.
- wiki 문서에는 원천 근거와 확인 필요가 남는다.
- 주 1회 30분 안에 끝나는 점검 루틴이 있다.
- 확인 필요, 출처 없음, TODO, 오래된 날짜, 깨진 링크를 점검 후보로 모을 수 있다.
- output 문서에는 목적, 생성 날짜, 근거 위키, 원천 자료, 확인 필요, 후속 반영 위치가 있다.
- 확장 중단 신호를 정기적으로 확인하고 필요하면 루틴을 줄인다.
- 최종적으로 다음 업무에서 같은 배경 설명이 줄어드는지 확인한다.