RAG 이후 지식 유지보수: 출처, 충돌, 갱신을 관리하는 법

RAG를 붙이면 많은 문서에서 관련 조각을 찾을 수 있다. 같은 질문을 한 달 뒤 던지면 시스템은 자료를 다시 검색하고 문맥을 다시 조합한다. 지난번에 사람이 해결한 출처 충돌과 용어 정의가 검색 결과에 그대로 남아 있지 않으면 같은 판단을 반복한다.

Andrej Karpathy가 제안한 LLM Wiki는 원문 위에 연결된 Markdown 지식층을 둔다. 에이전트가 새 자료를 읽고 기존 위키 페이지를 갱신하는 구상이다. 다음 질의는 정리된 페이지에서 시작하고, 근거가 필요할 때 원문으로 내려간다. 이 패턴을 내 OpenClaw 기록 방식과 비교하면서 검색 정확도와 별개인 유지보수 문제를 살폈다.

저장 파일이 늘면서 생긴 문제

내 환경에서는 URL을 보내면 에이전트가 자료를 읽고 요약 파일을 만든다. 세션이 끝나도 파일은 남는다. 초기에는 저장한 문서 수가 늘면 기억도 좋아질 것으로 생각했다.

이전 원고에 남긴 내 운영 상태는 반자동이었다. OpenClaw가 새 자료를 읽어 요약하고 Notion과 블로그에 저장했지만, 기존 Notion 페이지를 다시 읽어 새 정보와 통합하는 과정까지 자동으로 맡기지는 않았다. 관련 클립의 연결을 제안하면 내가 내용을 보고 다음 행동을 정했다. 새 페이지 생성과 기존 페이지 유지보수는 다른 작업이었다.

파일이 늘 때 확인할 위험도 나눠 봤다. 같은 개념에 다른 이름을 붙이거나 작년 결론을 올해 사실로 쓰는 경우, 원문 대신 출처 없는 요약을 다시 인용하는 경우다. 이 위험을 모두 내 시스템에서 측정·해결했다는 뜻은 아니다. 아래 폴더 구조와 상태, 검사는 반자동 기록을 확장하기 위한 설계안이다. 전부 구현된 기능이나 성능 개선 결과로 읽지 않았으면 한다.

저장소는 기억의 재료를 보관한다. 관리자가 중복을 합치고 오래된 결론을 표시해야 독자가 현재 판단을 찾을 수 있다. LLM Wiki에서 내가 주목한 작업도 새 요약 생성보다 기존 페이지 수정이었다.

원문, 위키, 규칙을 분리한다

지식 폴더를 다시 구성한다면 다음처럼 책임을 나눌 생각이다.

sources/   원문 사본, URL, 저자, 발행일, 수집 시각
wiki/      주제별 설명, 현재 판단, 관련 페이지 링크
rules/     페이지 스키마, 출처 우선순위, 갱신 절차
reviews/   변경 제안, 승인자, 검사 결과

sources 파일은 수집 당시 증거를 보존한다. 에이전트는 원문을 고쳐 쓰지 않는다. 웹페이지가 바뀌면 새 수집본을 만들고 이전 버전과 연결한다. 저작권 때문에 전문을 저장할 수 없는 자료는 URL과 인용 가능한 범위, 접근 날짜를 남긴다.

wiki 페이지는 사람이 검토한 편집 결과다. 새 증거가 들어오면 결론이 바뀔 수 있다. 문장마다 출처 ID를 붙이고, 한 출처가 문장 전체를 뒷받침하는지 확인한다. rules에는 정부 통계와 원 논문, 회사 블로그처럼 자료 유형이 다를 때 어떤 기준으로 비교할지 적는다.

페이지 스키마가 갱신 판단을 돕는다

자유로운 Markdown만 사용하면 에이전트가 페이지마다 다른 형식을 만들 수 있다. 최소 메타데이터를 고정하는 안은 다음과 같다. 날짜와 ID는 형식을 보여 주는 예시다.

---
title: Agent harness
aliases: [에이전트 하네스, harness engineering]
status: reviewed
reviewed_at: 2026-08-17
sources: [src-014, src-027]
conflicts: [conflict-006]
owner: ck
---

aliases는 같은 개념의 중복 페이지를 찾는 데 쓴다. reviewed_at은 오래된 페이지를 선별하고, conflicts는 해결하지 못한 증거 차이를 숨기지 않는다. owner는 새 자료가 결론을 바꿀 때 검토할 사람을 알려 준다.

본문도 정의, 현재 판단, 근거, 반례, 변경 기록으로 나눈다. 모든 페이지에 같은 소제목을 강요하지는 않지만 사실과 해석이 섞이지 않도록 구역을 둔다. 에이전트가 원문 없이 사실 문장을 추가하면 감사 단계가 실패하게 만든다.

새 소스가 들어올 때 만드는 diff

에이전트는 새 자료를 읽은 뒤 페이지 전체를 다시 쓰지 않는다. 먼저 변경 제안을 만든다.

새 출처: src-031
영향받는 페이지: wiki/agent-harness.md
기존 주장: 장시간 작업은 단일 세션에서 처리한다.
제안 변경: 세션별 인수인계와 진행 기록을 사용한다.
근거 위치: src-031, section 3
충돌: src-014의 실험 조건과 다름
확신 수준: 검토 필요

검토자는 제안된 출처와 기존 출처를 함께 읽는다. 연구 대상과 날짜, 방법이 다르면 한쪽을 지우지 않고 적용 범위를 분리한다. 새 자료가 기존 결론을 뒤집을 때는 페이지의 reviewed_at과 변경 기록을 갱신한다.

에이전트가 여러 페이지에 같은 문장을 복사하지 않게 한다. 중심 페이지 한 곳에서 결론을 관리하고 다른 페이지는 링크로 연결한다. 중복된 사실 문장이 줄어들면 수정할 위치도 줄어든다.

충돌을 데이터로 남긴다

자료가 모순될 때 에이전트가 그럴듯한 중간값을 만들면 근거가 사라진다. 충돌 파일에 양쪽 주장을 그대로 기록한다.

id: conflict-006
topic: coding-agent-productivity
source_a: src-014
source_b: src-031
reason: 측정 대상과 기간이 다름
status: open
next_action: 동일 조건의 후속 연구 확인

검토자는 resolved, scoped, open 중 하나를 선택한다. scoped는 두 주장이 서로 다른 조건에서 성립한다는 뜻이다. 증거가 부족하면 open을 유지하고 위키 본문에도 불확실성을 표시한다.

미해결 충돌 수는 품질 실패가 아니다. 독자가 어떤 판단을 보류해야 하는지 알려 주는 정보다. 문제는 충돌을 삭제하고 하나의 확정 문장처럼 제시하는 데 있다.

RAG와 위키가 맡는 구간

RAG는 새 질문과 관련된 원문을 넓게 찾는다. 위키는 반복해서 사용하는 정의와 검토 기록을 압축한다. 한 질의는 다음 경로를 지난다.

위키에서 용어와 현재 판단, 미해결 충돌을 읽는다.
질문이 최근 정보나 세부 근거를 요구하면 RAG로 원문을 찾는다.
답변의 각 주장에 원문 또는 위키 출처를 연결한다.
새 자료가 기존 판단을 바꾸면 변경 제안을 만든다.
승인 후 위키를 갱신하고 diff를 저장한다.

위키만 읽으면 최근 자료를 놓칠 수 있다. RAG 결과만 읽으면 지난 검토 기록을 반복한다. 질의 유형에 따라 두 경로를 함께 사용하고 답변에 어느 층을 사용했는지 표시한다.

오래된 페이지를 찾는 기준

시간이 지났다는 이유만으로 페이지를 폐기하지 않는다. 법률과 제품 기능, 가격처럼 자주 변하는 주제는 검토 주기를 짧게 둔다. 수학적 정의와 과거 사건 기록은 출처가 바뀌지 않는 한 긴 주기를 쓸 수 있다.

다음 신호가 있으면 재검토 목록에 넣는다.

출처 URL이 열리지 않거나 내용이 바뀌었다.
reviewed_at 이후 새 공식 자료가 나왔다.
연결된 페이지가 다른 정의를 사용한다.
답변 로그에서 같은 충돌이 반복된다.
소유자가 바뀌었거나 업무 맥락이 사라졌다.

삭제할 때도 Git 이력을 남긴다. 다른 페이지가 링크하고 있으면 새 위치로 연결하거나 폐기 이유를 적는다. 지식 시스템은 현재 결론과 판단이 바뀐 과정을 함께 보여 주는 기록이다.

사람이 승인할 항목

에이전트는 링크 확인과 메타데이터 갱신, 중복 후보 탐색을 맡을 수 있다. 사람은 출처 우선순위와 주장 범위, 미해결 충돌의 공개 방식을 결정한다. 법률이나 의료처럼 위험이 큰 지식은 해당 분야 전문가가 검토해야 한다.

자동 갱신을 붙인 뒤에도 나는 변경 규칙을 정하고 중요한 diff를 승인해야 한다. 주간 감사에서는 새 소스 수보다 출처 없는 문장, 열린 충돌, 검토 기한이 지난 페이지를 볼 계획이다. 지금의 관련 자료 추천을 이 절차와 같다고 평가하지 않는다.

수집·질의·점검을 작은 저장소에서 시험한다

Karpathy의 원문은 수집, 질의, 정기 점검을 구분한다. 내가 시작할 단위는 자료 몇 개와 주제 페이지 하나면 충분하다. 실제 고객 자료 대신 공개 문서나 내가 만든 가상 입력을 쓰고, 원본 수집 시각과 URL을 남긴다. 원문 한 개를 넣었을 때 어떤 주장과 링크를 추가할지 먼저 제안받는다. 사람이 diff를 읽고 승인하기 전까지 위키의 현재 결론을 바꾸지 않는다.

갱신 시험에는 서로 다른 날짜의 두 가상 자료를 쓸 수 있다. 첫 자료에는 '일주일마다 백업한다', 다음 자료에는 '매일 백업한다'고 적는다. 두 번째 자료를 넣은 뒤 에이전트가 주기를 바꾸는 것만 보면 부족하다. 변경 시점, 새 근거와 이전 근거의 연결이 남는지 확인하고, 과거 시점을 묻는 질문에는 옛 주기를 답하는지 시험한다. 이 예시는 위키 기능을 검사하기 위한 합성 사례이며 실제 서비스의 백업 주장을 담지 않는다.

시험 입력	기대하는 결과
같은 URL과 같은 본문 재수집	새 사실처럼 중복 추가하지 않음
다른 조건의 상반된 주장	어느 조건에서 다른지 표시하고 승인 대기
출처 파일이 없는 변경 제안	적용하지 않고 누락 근거를 보고
원문의 기존 내용 수정	새 버전을 만들고 이전 수집본 보존
승인 후 잘못된 편집 발견	해당 변경과 연결 페이지를 함께 복구

작은 질문 목록도 고정한다. 현재 결론, 원문 위치, 남은 충돌, 마지막으로 결론이 바뀐 이유를 각각 물어본다. 답이 자연스러운지보다 근거를 직접 열 수 있는지와 적용 시점을 정확히 구분했는지 확인한다. 수집이 성공해도 질의에서 오래된 답이 나오면 완료로 표시하지 않는다.

Notion에 연결할 때는 수정 권한을 따로 연다

현재 반자동 기록을 유지하면서도 읽기 전용 점검부터 붙일 수 있다. 관련 페이지 ID와 마지막 수정 시각을 읽어 변경 제안만 저장한다. 사용자가 검토하는 동안 누군가 원문 페이지를 고쳤다면 이전 내용을 덮어쓰지 않고 다시 읽어 diff를 만든다. 동시에 작업할 때 생기는 충돌을 최신 파일이 이기는 방식으로 해결하지 않는다.

기존 페이지의 전체 교체보다 변경할 문단과 연결 관계를 지정하는 편이 검토하기 쉽다. 실행 전에는 해당 페이지의 복구 사본과 링크를 남기고, 수정 후에는 API가 성공했다고 답했는지에 더해 실제 페이지를 다시 읽는다. 한 출처가 여러 페이지에 영향을 주면 대상 목록과 적용 상태를 기록해 중간 실패에서 남은 페이지만 처리한다. 토큰·검수 시간·원문 접근 비용도 함께 측정한다. LLM이 편집을 대신한다는 이유로 유지 비용을 0으로 계산하지 않는다.

LLM Wiki 패턴은 지식 유지보수를 파일 변경으로 다룰 수 있게 한다. Git diff에서 문장과 출처가 어떻게 바뀌었는지 읽고, 문제가 생기면 이전 버전으로 돌아갈 수 있다. 내가 원하는 기억은 답을 즉시 내놓는 저장소보다 근거와 수정 이력을 설명할 수 있는 저장소에 가깝다.