WikiDocs page analysis · Chapter 8.2

8.2 정리와 감사 흐름 만들기

LLM위키를 오래 믿고 쓰기 위한 핵심은 자료를 넣고 질문하는 흐름 뒤에 형식, 근거, 최신성, 구조, 중복을 점검하는 lint 루틴을 붙이는 것이다. 이 페이지는 원문 8.2의 절차를 실무 감사 흐름, 템플릿, 체크리스트로 재구성한 HTML 대응 문서다.

Source path: data/runtime/write-agents/LLM wiki reference analyses/md/wikidocs/pages/08-02-cleanup-and-audit-flow.md
원문: WikiDocs 8.2 정리와 감사 흐름 만들기 · 확인일: 2026-06-06 KST

핵심 요약

감사는 운영 루프다

원문은 LLM위키 운영을 ingest -> query -> lint로 본다. 자료 투입과 질의가 반복될수록 출처 없는 주장, 오래된 판단, 중복 문서가 생기므로 점검 흐름을 별도 단계로 둬야 한다.

형식과 사실은 다르다

제목, 요약, 근거, 확인 필요, 관련 문서, 다음 질문을 갖춘 문서는 다시 질문하기 쉽다. 그러나 형식이 좋다고 사실성이 보장되지는 않으므로 근거 점검이 뒤따라야 한다.

삭제보다 후보 기록

고립, 중복, 충돌 문서는 즉시 삭제하지 않는다. 조건, 날짜, 근거, 독자를 비교하고 정리 후보 기록에 남겨 되돌릴 수 있는 감사 흐름을 만든다.

원문 구조와 실무 의미

원문 절핵심 내용실무 의미
기본 흐름ingest -> query -> lint 흐름을 제시한다.자료 입력, 질의, 점검을 분리해 위키를 검토 가능한 지식으로 유지한다.
형식 점검하기좋은 위키 문서의 기본 형식을 확인한다.제목, 한 문장 요약, 근거, 확인 필요, 관련 문서, 다음 질문을 표로 점검한다.
근거 점검하기핵심 주장마다 원천 경로, URL, 확인일, 확실성, 최신성을 본다.출처 없는 주장과 오래된 주장을 확정 지식으로 쓰지 않는다.
구조와 중복 점검하기고립 문서, 중복 후보, 충돌 후보를 찾는다.삭제보다 대표 문서, 링크 보강, 주제 분리, 보류 여부를 기록한다.
정리 후보 기록후보, 이유, 근거, 제안 처리, 확인 필요, 상태를 남긴다.감사 결과를 추적 가능하게 만들고 같은 논의를 반복하지 않게 한다.

감사 루프: ingest, query, lint

단계하는 일남기는 것생략했을 때의 위험
ingest원천 자료를 넣고 출처와 확인일을 남긴다.raw/, source note, log.md자료는 많지만 근거가 불명확해진다.
query위키를 기준으로 업무 질문을 던진다.답변, output 초안, 확인 필요답변이 대화창에만 남고 위키가 갱신되지 않는다.
lint형식, 근거, 최신성, 구조, 중복을 점검한다.감사표, 정리 후보, 수정 사항, 보류 이유그럴듯하지만 믿기 어려운 위키가 된다.

lint는 문서를 예쁘게 다듬는 일이 아니라 신뢰 경계를 회복하는 일이다. LLM이 만든 문장은 자연스러워 보여도 원천, 확인일, 적용 조건이 없으면 업무 산출물로 승격시키기 어렵다. 이 문제의식은 8.1 위키에도 점검이 필요한 이유와 직접 연결된다.

형식 점검

형식 점검은 문서가 다시 질문 가능한 상태인지 확인하는 첫 단계다. 좋은 형식은 문서 미관이 아니라 업무 질문의 재료로 쓰일 수 있는 최소 구조다.

점검 항목통과 기준실패 신호후속 처리
제목업무 질문이나 판단 초점이 드러난다.notes.md, summary.md처럼 용도가 흐리다.질문 기준으로 제목과 파일명을 고친다.
한 문장 요약핵심 결론과 용도가 보인다.본문을 읽기 전 목적을 알 수 없다.요약을 추가하되 과한 단정은 피한다.
근거원천 경로, URL, 확인일, 자료 성격이 있다.원천으로 돌아갈 수 없다.근거 블록을 추가하거나 확인 필요로 낮춘다.
확인 필요미정, 추정, 최신성 확인 필요가 분리되어 있다.모르는 내용이 확정 문장처럼 쓰인다.확인 필요 섹션과 다음 질문을 만든다.
관련 문서상위 개념, 원천, 예외 기준, output으로 연결된다.문서가 고립되어 있다.index 또는 관련 문서 링크를 보강한다.
다음 질문문서를 읽힌 뒤 던질 질문이 있다.읽고 끝나는 메모가 된다.비교, 보고서, 실행 계획, 감사 질문을 추가한다.

근거와 최신성 점검

근거 점검은 문서 전체를 좋다, 나쁘다로 평가하지 않는다. 핵심 주장마다 원천 위치와 확실성을 따져 확정, 제한, 추정, 확인 필요로 나눈다. 자세한 문장별 검증 기준은 6.2 답변의 근거 확인하기와 연결된다.

문장 상태처리 기준문서 표현
원천 근거 있음raw, URL, 회의록 날짜, 공식 문서에서 직접 확인된다.원천 자료 기준으로 확인됨
제한적 확인근거는 있으나 기간, 표본, 상황이 제한적이다.현재 자료 기준, 회의록 기준, 샘플 기준
wiki 근거만 있음정리 문서에는 있으나 원천 연결이 약하다.위키 정리 기준, 원천 확인 필요
추정효과, 가능성, 우선순위 같은 해석이다.후보, 가설, 검토 대상
출처 없음근거 위치가 없다.확인 필요 또는 삭제 후보
최신성 확인 필요도구 기능, 정책, 가격, 보안, 릴리스, 담당자가 바뀔 수 있다.확인일 기준, 현재 공식 자료 재확인 필요
운영 원칙: 오래된 주장은 무조건 삭제하지 말고 작성일, 마지막 검토일, 다음 검토 필요일, 재확인 원천을 붙인다. 실행 명령, 플러그인 기능, 가격, 정책, 보안 권한, API 동작, 성능 효과는 현재 기준 재확인이 필요하다.

구조와 중복 점검

구조 점검은 문서 관계를 회복하는 일이다. 좋은 내용도 index.md, 관련 문서, output, log에서 발견되지 않으면 실무 질문의 출발점이 되기 어렵다.

점검 대상확인 질문처리 방향
index.md새 문서와 최근 output이 안내되는가?질문별 출발점과 확인 필요를 보강한다.
관련 문서 링크상위 개념, 근거, 예외, output으로 이어지는가?장식 링크보다 역할 있는 링크를 남긴다.
log.md자료 추가, 문서 생성, 점검, 정리 후보가 기록되는가?누락된 처리 이력을 보강한다.
고립 문서어느 질문에서도 시작점으로 쓰이지 않는가?연결, 통합, 보류, 아카이브 후보로 분류한다.
중복 문서같은 기준이 여러 문서에 반복되는가?대표 문서와 링크로 정리한다.
충돌 후보같은 사실을 다르게 말하는가?조건, 날짜, 근거 차이를 표시한다.

중복은 항상 삭제 대상이 아니다. 같은 기준이 반복되면 대표 기준 문서가 필요하다는 신호일 수 있고, 비슷한 문장이 실제로는 날짜, 독자, 정책 버전이 달라 모두 남아야 할 수도 있다. 관련 기준은 5.3 위키 문서로 정리하기8.3 주제가 늘어날 때 관리하기로 이어진다.

실무 적용 절차

  1. 이번 감사 범위를 최근 1주일 문서, 특정 주제, 최근 output처럼 작게 정한다.
  2. index.md를 열어 핵심 질문, 먼저 읽을 문서, 최근 산출물, 확인 필요가 맞는지 본다.
  3. log.md에서 자료 투입, 문서 생성, output 생성, 검증, 보류 이유가 기록됐는지 확인한다.
  4. wiki/ 문서 목록을 만들고 제목, 요약, 근거, 확인 필요, 관련 문서, 다음 질문을 점검한다.
  5. 형식이 부족한 문서는 사실을 임의로 보강하지 말고 부족 항목과 필요한 원천을 표시한다.
  6. 보고서나 실행 계획에 쓰일 핵심 주장부터 근거 점검을 한다.
  7. 각 주장에 raw 경로, URL, 확인일, 자료 성격이 있는지 확인한다.
  8. 근거가 약한 주장은 확인 필요, 제한적 확인, 추정, 삭제 후보 중 하나로 낮춘다.
  9. 도구 명령, 정책, 가격, 보안 권한, API 동작, 성능 효과, 담당자, 일정처럼 최신성이 필요한 주장을 표시한다.
  10. 관련 문서 링크가 근거, 예외, 다음 행동, 상위 개념 중 어떤 역할을 하는지 확인한다.
  11. 연결되지 않은 문서, 중복 문장, 충돌 후보를 찾고 정리 후보 기록표에 남긴다.
  12. 깨진 링크, 누락된 확인일, index 링크 추가처럼 되돌리기 쉬운 수정부터 처리한다.
  13. 병합, 삭제, 아카이브는 별도 검토로 남기고 필요하면 주제 분리 기준을 적용한다.
  14. 감사 결과를 log.md에 남기고 확인 필요를 자료 수집, 답변 검증, output 수정, 다음 행동으로 연결한다.

실무 템플릿

문서 형식 점검표

문서제목요약근거확인 필요관련 문서다음 질문처리
wiki/...예/아니오예/아니오예/아니오예/아니오예/아니오예/아니오유지/보강/확인 필요

근거 점검 라벨표

문장 또는 주장근거 위치근거 상태최신성 상태처리
raw/..., URL, wiki/...확인됨/제한적 확인/wiki 근거만 있음/추정/출처 없음안정/최신성 확인 필요/오래됨유지/낮춤/자료 수집/삭제 후보

정리 후보 기록 템플릿

항목작성 내용
후보 문서wiki/... 또는 output/...
문제 유형고립, 중복, 충돌, 오래됨, 근거 부족, 링크 누락
발견 이유어떤 점검에서 발견됐는가
근거관련 raw, wiki, log, output
제안 처리유지, 링크 보강, 대표 문서 통합, 주제 분리, 아카이브, 삭제 검토
확인 필요삭제 전 확인할 조건, 담당자, 최신성, 보안
상태후보, 검토 중, 처리 완료, 보류

감사 요청 프롬프트

다음 wiki 문서 묶음을 점검해 주세요.

기준:
- 제목, 한 문장 요약, 근거, 확인 필요, 관련 문서, 다음 질문이 있는가
- 핵심 주장에 raw 경로, URL, 확인일, 자료 성격이 있는가
- 효과, 비용, 일정, 정책, 보안, 도구 기능은 최신성 확인 필요 여부를 표시했는가
- 연결되지 않은 문서, 중복 후보, 충돌 후보가 있는가

주의:
- 원천 근거가 없는 내용을 새로 만들어 넣지 마세요.
- 문서를 즉시 삭제하거나 병합하지 마세요.
- 후보, 이유, 근거, 제안 처리, 확인 필요를 표로 제안하세요.

검증 체크리스트

형식

  • 문서 제목이 업무 질문이나 판단 초점을 드러낸다.
  • 한 문장 요약이 있다.
  • 근거 블록에 원천 자료, URL, 확인일, 자료 성격이 있다.
  • 확인 필요가 별도 섹션으로 남아 있다.
  • 관련 문서 링크가 상위 개념, 원천, 예외, output 중 하나의 역할을 가진다.
  • 다시 물어볼 질문 또는 다음 행동이 있다.

근거

  • 핵심 주장마다 raw 경로, URL, 회의록 날짜, 공식 문서 중 하나가 있다.
  • wiki 정리문에만 있는 내용을 원천 확인 없이 확정하지 않았다.
  • 출처 없는 문장을 확인 필요나 삭제 후보로 낮췄다.
  • 효과, 비용, 일정, 정책, 보안, 도구 기능 관련 문장에 최신성 확인 필요 여부를 표시했다.
  • 추정과 확인된 내용을 분리했다.

구조와 운영

  • 새 문서가 index 또는 관련 문서에서 연결된다.
  • 최근 output이 근거 wiki와 raw로 돌아갈 수 있다.
  • 고립 문서와 중복 후보를 정리 후보로 기록했다.
  • 충돌 후보를 즉시 합치지 않고 조건, 날짜, 근거, 독자를 비교했다.
  • 감사 결과가 log, 관련 wiki, 다음 자료 수집, 다음 output 수정으로 이어진다.

좋은 질문과 사람 검증 질문

LLM에게 묻기

  • 이 문서 묶음을 형식 기준으로 점검해 주세요.
  • 핵심 주장에 근거 라벨을 붙여 주세요.
  • 최근 output이 raw와 wiki 근거로 돌아갈 수 있는지 확인해 주세요.
  • index와 log를 기준으로 고립 문서와 중복 후보를 찾아 주세요.

사람이 확인하기

  • 형식이 맞는 문장을 사실로 착각하지 않았는가?
  • 출처 없는 문장이 자연스럽다는 이유로 남아 있지 않은가?
  • 오래된 output이 현재 정책이나 담당자 기준처럼 쓰이지 않는가?
  • 중복 문서가 정말 같은 사실을 말하는가?

다음 연결

  • 감사 결과를 자료 수집으로 보낸다.
  • 답변 검증 기준을 문서 감사에 재사용한다.
  • 주제 범위 문제는 8.3으로 보낸다.
  • daily-inbox와 주간 점검은 8.4로 연결한다.

흔한 실패와 수정 방향

실패 사례위험수정 방향
감사 없이 계속 자료만 넣는다.출처 없는 주장과 중복이 쌓인다.ingest -> query -> lint를 운영 기준으로 둔다.
형식 점검을 사실 검증으로 착각한다.근거가 부족한 문장이 확정 지식처럼 남는다.형식 점검 뒤 근거 점검을 별도로 한다.
최신성 필요한 명령을 현재 사실로 쓴다.실행 실패와 보안 위험이 생길 수 있다.확인일, 기준 자료, 재확인 위치를 붙인다.
중복 문서를 즉시 삭제한다.조건이나 날짜가 다른 기록을 잃을 수 있다.정리 후보로 기록하고 조건과 근거를 비교한다.
log를 생략한다.왜 고쳤고 왜 보류했는지 추적할 수 없다.감사 범위, 수정, 보류, 다음 행동을 기록한다.

관련 문서

한계와 확인 필요

  • 이 분석은 2026-06-06 KST에 확인한 WikiDocs 원문과 로컬 Markdown 분석 파일을 기준으로 한다. 원문 세부 표현과 마지막 편집 여부는 원문 페이지에서 다시 확인해야 한다.
  • 원문이 언급한 구현체, 명령, 플러그인, 외부 참고 자료는 실제 사용 전 현재 README, 릴리스, 설치된 도움말, 공식 문서, 조직 보안 정책으로 재확인해야 한다.
  • 형식 점검과 근거 점검은 LLM에게 보조로 맡길 수 있지만 삭제, 병합, 아카이브, 주제 분리의 최종 판단은 사람이 해야 한다.
  • 고객명, 개인정보, 계약 조건, 내부 정책, 비공개 코드가 포함된 raw나 output은 감사 프롬프트에 그대로 복사하지 말고 접근 권한과 외부 LLM 호출 여부를 확인해야 한다.

완료 기준

  1. ingest -> query -> lint 흐름을 설명할 수 있다.
  2. 형식 점검, 근거 점검, 구조 점검의 차이를 구분했다.
  3. 문서별 제목, 요약, 근거, 확인 필요, 관련 문서, 다음 질문을 점검했다.
  4. 핵심 주장마다 근거 위치, 확실성, 최신성 상태를 표시했다.
  5. 출처 없는 주장과 오래된 주장을 확인 필요 또는 자료 수집 항목으로 낮췄다.
  6. 연결되지 않은 문서, 중복 후보, 충돌 후보를 정리 후보 기록에 남겼다.
  7. 삭제나 병합 전에 조건, 날짜, 근거, 독자, 주제 범위를 확인했다.
  8. 감사 결과를 log.md에 남길 수 있다.
  9. 확인 필요가 자료 수집, 답변 검증, output 수정, 주제 분리, daily-inbox 루틴으로 이어진다.