Building Self-Correcting Memory in OpenWiki

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

OpenWiki는 위키의 각 주장(claim)을 버전이 지정된 코드 증거와 연결하고, 증거 변경 시 신뢰를 보류한 뒤 재검증·정정함으로써 전체 위키를 다시 생성하지 않고 기억을 자기 교정하며, 2,000개 주장 평가에서 지원됨 비율을 92.9%에서 97.8%로 높였다.

📌 핵심 요약

• OpenWiki는 코드가 변하면서 과거에 정확했던 위키 지식이 낡아지는 기억 드리프트와 기억 오염 문제를 해결하기 위해, 망각을 단순 삭제가 아니라 더 이상 안전하게 신뢰할 수 없는 주장을 식별하는 능력으로 정의했다.
• 에이전트가 페이지를 작성할 때 주요 사실적 주장과 이를 뒷받침하는 코드 위치를 함께 기록하고, 런타임은 증거의 버전을 저장해 개별 주장과 근거 사이에 지속적인 연결을 만든다.
• 모든 위키 업데이트가 시작될 때 모델 호출 없는 결정론적 검사가 전체 claim 집합의 저장된 증거 버전과 현재 소스를 비교하며, 재검증되지 않은 stale claim은 해결될 때까지 유지된다.
• claim은 개별 믿음의 신뢰성을 관리하고 OKF v0.2는 페이지 수준의 출처·생성 주체·검증 이력을 외부 도구가 확인할 수 있게 하며, verified는 페이지의 전체 claim 집합이 조정·재검증·저장된 뒤에만 추가된다.
• 각각 2,000개 주장을 평가한 결과 claims runtime은 지원됨을 92.9%에서 97.8%로 높이고 stale을 3.5%에서 0.5%, hallucinated를 0.7%에서 0%로 낮췄으며, OpenWiki 0.4.0은 다음 업데이트부터 claim 생성과 OKF v0.2 마이그레이션을 자동으로 시작한다.

🧩 주요 포인트

1. 주장과 버전 증거의 결속 → 코드 변경을 막연한 문서 노후화가 아니라 재검토가 필요한 개별 지식 단위로 추적할 수 있다.
2. 오래됨 상태의 지속 → 증거가 바뀐 claim은 틀렸다고 단정되지 않지만 실제 재검증 전까지 신뢰가 복구되지 않아 불확실성이 조용히 사라지지 않는다.
3. 결정론적 탐지와 증분 교정의 분리 → 전체 claim 검사는 모델 없이 수행하고 에이전트는 읽은 페이지의 stale claim만 해결하므로 교정 비용이 위키 전체 규모보다 코드 변경량에 좌우된다.

🧠 상세 정리

1. 장기 기억에서 망각이 필요한 이유

OpenWiki가 제기하는 핵심 문제는 장기 기억이 정보를 저장하고 다시 찾는 능력만으로는 충분하지 않다는 점이다. 진실의 원천인 코드가 계속 바뀌면 한때 정확했던 API 동작이나 기능 설명도 시간이 지나면서 더 이상 맞지 않을 수 있지만, 일반적인 기억 시스템은 그 변화를 안정적으로 알아차릴 방법이 없다. 이런 상태가 누적되면 위키와 실제 코드 사이에 기억 드리프트가 생기고, 잘못된 지식이 계속 참처럼 사용되는 기억 오염으로 이어질 수 있다. 특히 OpenWiki처럼 진실의 원천이 진화하는 코드 저장소인 경우 문서의 정확성은 작성 당시의 품질뿐 아니라 이후 변경을 감지하는 능력에도 달려 있다. 이에 OpenWiki는 무엇을 믿는지만 저장하지 않고 그 믿음을 뒷받침한 증거까지 보존해, 증거가 바뀌었을 때 관련 지식을 다시 살펴볼 수 있도록 설계했다.

2. 사실적 주장과 코드 증거의 영속적 연결

첫 단계는 에이전트가 위키 페이지를 작성할 때 페이지에 포함된 주요 사실적 주장과 이를 뒷받침하는 코드 증거를 함께 식별하는 것이다. 예를 들어 위키가 실패한 작업은 기본적으로 세 번 재시도된다고 설명하면, OpenWiki는 해당 문장을 claim으로 저장하고 이를 지원하는 repo://src/scheduler.ts#L393-L404 같은 코드 위치를 evidence로 연결한다. 런타임은 여기에 증거의 버전도 기록하므로 나중에 같은 근거가 유지되는지 다시 판정할 수 있다. 이 구조에서 위키는 더 이상 하나의 비정형 텍스트 묶음으로만 취급되지 않고, 각각의 주장이 어떤 코드에 의존하는지 추적할 수 있는 지식 집합이 된다. 결과적으로 문서 전체를 막연하게 의심하는 대신 변경된 증거에 연결된 개별 claim을 재검토 대상으로 지정할 수 있다.

3. 증거 버전 비교를 통한 오래됨 탐지

OpenWiki는 claim이 처음 작성될 때 저장한 증거 버전과 현재 소스의 버전을 비교해 지식의 신선도를 판단한다. 두 버전이 다르면 해당 claim은 stale로 표시되지만, 이것이 곧 그 문장이 틀렸다는 뜻은 아니다. 많은 코드 변경은 연결된 주장을 실제로 무효화하지 않을 수 있으므로 stale은 거짓 판정이 아니라 기존 신뢰를 유지하기 전에 확인이 필요하다는 신호다. 별도의 상태 플래그를 영속적으로 저장할 필요도 없으며, 저장된 증거 버전만 있으면 매 업데이트에서 현재 버전과 다시 비교할 수 있다. 증거가 재검증되지 않는 한 버전 차이가 계속 남기 때문에, claim에 대한 불확실성도 임의로 해소되거나 조용히 누락되지 않고 지속된다.

4. stale claim의 재검증과 자기 교정

오래된 지식을 탐지한 뒤에는 현재의 코드 증거를 조사해 claim이 여전히 참인지 거짓인지 판단한다. 주장이 계속 참이라면 문장은 유지하고 저장된 증거 버전을 최신 상태로 갱신하며, 더 이상 참이 아니라면 위키 본문과 이를 지지하는 증거를 함께 수정한다. 중요한 제약은 실제 검증이 끝나기 전까지 stale 상태가 그대로 유지된다는 점으로, 단순히 업데이트가 실행됐다는 이유만으로 신뢰가 자동 복구되지 않는다. 소스 변경이 기존 claim을 불확실하게 만들고 후속 업데이트가 이를 재확인하거나 정정하는 과정이 반복되면서 자기 교정 피드백 루프가 형성된다. 이는 매번 위키를 처음부터 다시 생성하는 방식과 달리 기존 지식을 보존하면서 변경의 영향을 받은 주장만 지속적으로 교정하는 접근이다.

5. claim과 OKF v0.2의 역할 분담

claim은 각 페이지가 무엇을 믿고 있는지와 그 믿음을 뒷받침하는 버전 증거를 OpenWiki 내부에서 세밀하게 관리한다. OKF v0.2는 이 정보를 페이지 수준의 이식 가능하고 검사 가능한 신뢰 정보로 표현해 OpenWiki 외부의 도구도 Markdown 묶음의 출처와 검증 이력을 이해할 수 있게 한다. OpenWiki는 claim의 evidence를 페이지의 OKF sources 메타데이터에 반영하고, 페이지 본문을 마지막으로 변경한 생성 주체를 기록하며, 전체 claim 집합이 조정·재검증·저장된 뒤에만 verified를 추가한다. 루트 인덱스는 okf_version을 0.2로 선언해 해당 Markdown 묶음이 OKF 소비 도구에서 인식될 수 있도록 한다. 정밀한 claim과 증거 버전은 OpenWiki의 sidecar에 유지되고, 휴대 가능한 Markdown에는 OKF front matter를 통해 문서 단위의 표준화된 신뢰 요약이 노출된다.

6. 실제 업데이트에서의 실행 방식

staleness 탐지는 에이전트가 다른 작업을 시작하기 전인 모든 위키 업데이트의 첫 단계에서 실행된다. 런타임은 전체 claim 집합을 순회하며 저장된 증거 버전과 현재 소스를 비교하고, 이 검사는 모델을 호출하지 않는 결정론적 연산이어서 claim이 수천 개로 늘어나도 빠르게 수행되도록 구성된다. 에이전트가 전체 claim 집합을 직접 훑는 것은 아니며, 업데이트 중 특정 페이지를 읽을 때 그 페이지에 속한 stale claim이 본문과 함께 제시된다. 에이전트는 기존 작업의 일부로 해당 claim을 재검증해 증거를 갱신하거나, claim과 위키 문장을 함께 정정한다. 해결되지 않은 claim은 삭제되지 않고 다음 업데이트를 위해 계속 표시되므로, 실질적인 업데이트 비용은 위키가 보유한 전체 claim 수보다 코드가 얼마나 바뀌었는지에 비례한다.

7. 망각 능력을 측정한 평가 설계

OpenWiki 팀은 코드 저장소를 일련의 git 커밋 순서로 재생하고 미리 정한 checkpoint에서 위키를 업데이트하는 평가를 구성했다. 커밋에는 새로운 기능, 기존 동작의 변경, 버그 수정, 변경의 되돌리기가 포함돼 진실의 원천이 여러 방식으로 달라지는 상황을 재현했다. 각 업데이트 후 위키의 사실적 claim은 현재 코드가 뒷받침하는 Supported, 과거에는 정확했지만 현재는 성립하지 않는 Stale, 저장소 역사상 한 번도 참이 아니었던 Hallucinated, 코드만으로 확인하거나 반박할 수 없는 Unverified로 분류됐다. 동일한 커밋과 업데이트 순서를 OpenWiki claims runtime을 적용한 경우와 적용하지 않은 기준선에 각각 실행했다. 두 조건은 각각 2,000개의 claim을 대상으로 평가돼, 기존 지식의 오래됨을 탐지하고 다시 교정하는 능력을 직접 비교할 수 있었다.

8. 평가 결과와 관찰된 회복 과정

2,000개 claim 기준으로 Supported 비율은 기준선의 92.9%에서 claims runtime 적용 후 97.8%로 상승했고, Stale은 3.5%에서 0.5%로 감소했다. Hallucinated는 0.7%에서 0%로 줄었으며 Unverified도 2.9%에서 1.7%로 낮아졌다. 전체 업데이트를 합산한 관찰에서는 stale claim 수가 기준선의 80개에서 9개로, hallucinated claim 수는 15개에서 0개로 감소했다. 개별 실행에서는 첫 checkpoint인 T1에서 코드 변경으로 claim의 17%가 stale이 되고 Supported가 77%까지 내려갔지만, 다음 T2에서 Stale은 0%가 되고 Supported는 98%로 회복됐다. 같은 사례에서 Hallucinated는 두 checkpoint 모두 1% 미만이었고 Unverified는 5%에서 2%로 줄어, 탐지된 불확실성이 후속 업데이트에서 실제로 교정되는 흐름을 보여줬다.

9. 자기 교정 기억의 의미와 OpenWiki 0.4.0

이 설계에서 망각은 오래된 기억을 무조건 삭제하는 행위가 아니라, 근거가 달라진 믿음을 더 이상 검증 없이 신뢰하지 않는 능력을 뜻한다. claims runtime은 위키 지식과 소스 증거를 지속적으로 연결하고, 증거 변경의 영향을 받은 claim을 stale로 만든 뒤 향후 업데이트에서 재검증하거나 정정할 수 있게 한다. 따라서 OpenWiki는 전체 위키를 매번 재구축하지 않고도 자신이 표현하는 코드의 현재 상태에 맞춰 점진적으로 진화할 수 있다. OpenWiki 0.4.0으로 업그레이드한 기존 사용자는 다음 위키 업데이트부터 자동으로 claim을 생성하고 OKF v0.2로 마이그레이션하게 된다. 새 설치는 npm install -g openwiki@latest로 패키지를 설치한 뒤 openwiki --init을 실행할 수 있으며, 공식 문서와 코드 저장소도 함께 제공된다.

🧾 핵심 주장 / 시사점

• OpenWiki의 망각은 정보를 지우는 기능이 아니라 증거가 변한 claim의 신뢰를 재검증 전까지 보류하는 메커니즘이다.
• claim 수준의 정밀한 evidence version과 OKF v0.2의 문서 수준 신뢰 요약을 분리함으로써 내부 교정 가능성과 외부 이식성을 함께 제공한다.
• 모델 없는 전체 staleness 탐지와 변경된 페이지 중심의 에이전트 교정을 결합해, claim이 수천 개로 늘어나도 주요 작업 비용을 코드 변경량에 맞춘다.

✅ 액션 아이템

• 에이전트가 페이지 작성 시 claim을 기록하고 코드 위치를 뒷받침하는 버전 증거와 지속적으로 연결해 기억 드리프트를 추적한다.
• 모든 위키 업데이트가 시작될 때 결정론적 검사를 돌려 claim 전체의 저장 증거와 현재 소스를 비교하고 stale claim은 재검증될 때까지 보류한다.
• OKF v0.2에서 verified는 페이지별 출처·생성 주체·검증 이력 공개가 확보된 뒤에만 전체 claim 집합 조정·재검증·저장이 완료되면 추가한다.

❓ 열린 질문

• stale claim이 생겼을 때 재검증되지 않은 상태를 몇 번의 업데이트 주기까지 유지해야 신뢰가 안정적으로 회복되는가?
• OpenWiki 0.4.0에서 claim 생성과 자동 마이그레이션을 시작하면 2,000개 claim 평가의 지원됨이 92.9%에서 97.8%로 오른 효과가 재현될까?
• claims runtime에서 hallucinated가 0.7%에서 0%로 낮아진 뒤에도 기억 오염과 불확실성을 어느 기준으로 계속 관리할 것인가?