왜 검색만으로는 기억을 생성할 수 없는지—그리고 소스 계층(source layers), 에이전트 규칙(agent rules), 결정론적 검사(deterministic checks)가 어떻게 지식 베이스를 시간이 지나도 유용하게 유지하는지에 대하여

나의 AI 지식 베이스는 검색창이 아닌 디렉토리 트리에서 시작합니다:

10-inbox      거칠고 검증되지 않은 캡처
20-sources    조용히 재작성될 수 없는 증거
30-knowledge  새로운 증거에 따라 변할 수 있는 합성(synthesis)
...

이 폴더들의 목적은 깔끔함이 아닙니다. 각 폴더는 서로 다른 변경 계약(change contract)을 정의합니다.

캡처된 대화는 불완전할 수 있습니다. 소스 기록(source record)은 실제로 발견된 것을 보존해야 합니다. 합성(synthesis) 페이지는 더 나은 증거가 이를 뒤집을 수 있기 때문에 편집 가능한 상태로 유지되어야 합니다. 프로젝트 결정에는 날짜와 소유자가 필요합니다. 로그(log)는 단순히 나중에 결과가 불편해졌다는 이유로 재작성되어서는 안 됩니다.

이러한 구분이 모델의 선택, 임베딩 데이터베이스(embedding database), 또는 노트 테이킹 앱의 선택보다 더 중요하다는 것이 밝혀졌습니다.

검색은 지식을 검색할 수 있지만, 유지하지는 못합니다.

대부분의 AI 문서 도구는 검색 증강 생성 (RAG, Retrieval-Augmented Generation) 패턴을 따릅니다: 파일을 업로드하고, 쿼리 시점에 관련 청크(chunks)를 검색하며, 모델에게 답변을 구성하도록 요청합니다.

이것은 유용합니다. 하지만 이를 장기 기억으로 오해하기 쉽습니다.

만약 질문 하나에 5개의 문서가 필요하다면, 검색 시스템은 질문이 던져질 때마다 매번 5개의 파편을 찾아 결합할 수 있습니다. 답변은 훌륭할 수 있지만, 그 합성(synthesis) 결과는 대개 채팅 기록 속으로 사라져 버립니다. 오늘 발견된 모순은 다음 달에 다시 발견해야 할 수도 있습니다. 수정된 해석이 다음 답변에 반영되지 않을 수도 있습니다.

2026년 4월, Andrej Karpathy는 그의 LLM Wiki 제안에서 다른 패턴을 설명했습니다: 원본 소스와 사용자 사이에 지속적이고 상호 연결된 Markdown 위키를 두는 것입니다. 새로운 소스가 도착하면, 에이전트(agent)는 단순히 인덱싱하는 것 이상의 일을 수행합니다. 에이전트는 주제 페이지를 업데이트하고, 상호 참조(cross-references)를 추가하며, 모순을 기록하고, 기존의 합성(synthesis) 내용을 수정합니다.

Karpathy의 문서는 설계 제안서(design proposal)이지, 위키(wiki)가 모든 규모에서 RAG를 능가한다는 것을 증명하는 벤치마크가 아닙니다. 저는 이 두 가지를 상호 보완적인 것으로 취급합니다.

• 유지 관리되는 위키(wiki)는 이미 개발된 결론, 관계, 그리고 해결되지 않은 이견(disagreements)을 저장합니다.

• 검색(Retrieval)은 컬렉션이 성장함에 따라 에이전트(agent)가 적절한 소스와 페이지를 찾을 수 있도록 돕습니다.

• 결론을 감사(audit)하거나 재구축해야 할 때 가공되지 않은 증거(raw evidence)를 계속 사용할 수 있습니다.

검색은 탐색 계층(navigation layer)입니다. 검색이 조용히 진실 계층(truth layer)이 되어서는 안 됩니다.

내구성이 있는 AI 지식 베이스에는 세 가지 역할이 필요합니다

가장 단순하면서도 유용한 아키텍처는 세 가지 계층을 가집니다:

가공되지 않은 소스 (raw sources) -> 유지 관리되는 지식 (maintained knowledge) -> 에이전트 스키마 (agent schema)

각 계층은 서로 다른 질문에 답합니다.

1. 소스가 실제로 무엇을 말했는가?

소스 계층은 출처(provenance)를 저장합니다: 정확한 URL 또는 파일, 저자, 가능한 경우 발행일, 액세스 날짜, 그리고 모든 캡처 제한 사항입니다. 또한 충실한 발췌문이나 소스 노트(source note)를 포함할 수도 있습니다.

이 계층의 역할은 우아해지는 것이 아닙니다. 이 계층의 역할은 나중에 검증(verification)을 가능하게 만드는 것입니다.

2. 현재 증거가 무엇을 뒷받침한다고 생각하는가?

지식 계층(knowledge layer)은 개념 페이지(concept pages), 비교, 요약, 그리고 진화하는 결론들을 포함합니다. 이 페이지들은 변경될 것으로 예상됩니다. 만약 새로운 증거가 오래된 주장을 약화시킨다면, 합성(synthesis) 내용이 이를 말해줘야 합니다.

이곳이 축적된 지식이 거주하는 곳입니다. 이곳은 가공되지 않은 증거가 아니며, 결코 그런 것처럼 가장해서는 안 됩니다.

3. 에이전트가 시스템을 어떻게 변경할 수 있는가?

스키마(schema) 또는 리포지토리 프로토콜(repository protocol)은 에이전트에게 파일 이름을 지정하는 방법, 중복 확인 방법, 주장을 인용하는 방법, 인덱스(index)를 업데이트하는 방법, 그리고 자신의 작업을 검증하는 방법을 알려줍니다. 저의 설정에서 이러한 규칙들은 AGENTS.md와 각 페이지에서 사용되는 프론트매터(frontmatter) 스키마에 존재합니다.

이 계층이 없다면, 모든 새로운 에이전트 세션은 규칙을 다시 추측해야 합니다. 그 결과는 예측 가능합니다: 중복된 페이지, 표류하는 이름, 누락된 링크, 그리고 취약한 출처(provenance)를 가진 자신만만한 요약들입니다.

내가 3계층 모델을 확장한 이유

3계층 모델은 문서가 어떻게 유지 관리되는 지식으로 변하는지를 설명합니다. 저의 저장소(repository)는 실행(execution) 또한 지원해야 합니다: 프로젝트, 연구 질문, 글쓰기, 그리고 투자 결정 등이 그것입니다.

이러한 객체들은 동일한 방식으로 노화되지 않습니다.

초기 초안에서는 다음과 같은 일반적인 구조를 사용했습니다:

raw/
wiki/
daily/
...

실제 자료가 들어오기 전까지는 단순해 보였습니다.

검증되지 않은 채팅 기록을 wiki에 넣어야 할까요, 아니면 memory에 넣어야 할까요? 연구 결론과 프로젝트 결정이 동일한 상태(status) 필드를 사용해야 할까요? 만약 나중에 출처가 부정확한 것으로 판명된다면, 원본 기록을 수정해도 될까요?

모호한 이름의 폴더를 더 추가하는 것으로는 이러한 질문들을 해결할 수 없었습니다. 변이 규칙(mutation rules)을 정의하는 것이 해결책이었습니다.

그 결과 이 글의 서두에 언급된 번호가 매겨진 디렉토리 구조가 탄생했습니다. 중요한 움직임은 _조용히 변경되어서는 안 되는 증거(evidence)_를 _수정 가능성이 유지되어야 하는 결론(conclusions)_으로부터 분리하는 것이었습니다.

두 규칙 모두 필요합니다. 불변의 결론은 교조(dogma)가 됩니다. 가변적인 증거는 감사 추적(audit trail)을 파괴합니다.

Markdown과 Git이 실용적인 기반인 이유

저는 Markdown 파일이 자동으로 수십 년 동안 살아남는다거나, Git이 저장소를 진실하게 만든다고 주장하는 것이 아닙니다.

저는 더 좁은 의미의 이유로 이들을 선택했습니다.

CommonMark 사양(specification)은 Markdown을 구조화된 문서를 위한 평문(plain-text) 형식으로 정의하며, 소스 코드가 읽기 가능한 상태로 유지된다는 점을 강조합니다. 사람은 전용 애플리케이션 없이도 이를 검사할 수 있습니다. Codex, Claude Code, Cursor, Gemini CLI, OpenCode, 또는 아직 존재하지 않는 미래의 도구들도 마찬가지입니다.

Pro Git은 버전 관리(version control)를 파일의 변경 사항을 시간에 따라 기록하여 이전 버전을 복구할 수 있도록 하는 것이라고 설명합니다. 실제로 Git은 이 지식 베이스에 검토 가능한 차이점(diffs), 이력(history), 브랜치(branches), 그리고 이식 가능한 클론(portable clones)을 제공합니다.

Markdown과 Git은 함께 제가 중요하게 생각하는 네 가지 속성을 제공합니다:

1. 검사 가능성 (Inspectability). 전용 제품 없이도 콘텐츠, 출처, 운영 규칙을 읽을 수 있습니다.

2. 비교 가능성 (Comparability). 에이전트가 결론을 변경하면, diff를 통해 무엇이 바뀌었는지 보여줍니다.

3. 이식성 (Portability). 에디터, 모델 또는 검색 시스템 (retrieval systems)을 변경하더라도 핵심 지식을 먼저 내보낼 (exporting) 필요가 없습니다.

4. 재구축 가능성 (Rebuildability). 검색 인덱스 (search indexes), 그래프 캐시 (graph caches), 시각적 인터페이스는 파일로부터 다시 생성할 수 있습니다.

한계도 있습니다. Git은 백업 정책이 아닙니다. Markdown은 주장을 검증하지 않습니다. 프라이빗 저장소 (Private repositories)에는 여전히 액세스 제어와 원격 복사본이 필요합니다. 민감한 자료에는 여전히 명시적인 가시성 모델 (visibility model)이 필요합니다. 도구는 거버넌스 (governance)를 가능하게 할 뿐, 거버넌스를 수행하지는 않습니다.

에이전트에게 모호한 프롬프트가 아닌 저장소 프로토콜을 부여하세요

“내 노트를 정리해줘”는 운영 모델이 아닙니다.

제 설정에서 에이전트는 실질적인 변경을 수행하기 전에 현재의 우선순위, 관련 인덱스, 디렉토리 규칙 및 스키마 (schema)를 읽어야 합니다. 또한 새로운 페이지를 만들기 전에 동일한 주제에 대한 기존 페이지가 있는지 검색해야 합니다.

최소한의 페이지는 다음과 같은 프론트매터 (frontmatter)를 사용합니다:

---
schema: v1
id: note-llm-compiled-knowledge
...

스키마는 Markdown을 데이터베이스로 만들려는 시도가 아닙니다. 이는 여러 에이전트가 정체성과 라이프사이클 (lifecycle)을 끊임없이 재협상하지 않고도 동일한 저장소에서 작업하는 데 필요한 최소한의 공유 어휘를 설정하는 것입니다.

또한 프로토콜은 다양한 종류의 진술을 구분합니다:

• 사실 (Fact): 출처에 의해 직접적으로 뒷받침됨.
• 추론 (Inference): 하나 이상의 사실로부터 도출된 결론.
• 가설 (Hypothesis): 여전히 증거가 필요한 주장.
• 의견 (Opinion): 명시적인 판단.
• 결정 (Decision): 문맥과 날짜를 포함하여 선택된 행동.

더 위험한 모델 오류 중 하나는 명백한 날조가 아닙니다. 그것은 압축 오류 (compression error)입니다. 즉, 저자의 의견이 검증된 사실로 요약되거나, 잠정적인 가설이 세 번의 재작성 후에 불확실성 라벨을 잃어버리는 경우입니다.

진술 유형(Statement types)은 그러한 드리프트(drift)를 더 쉽게 알아차릴 수 있게 해줍니다.

설계를 바꾼 인용 실패 사례

제 소스 자료의 초기 초안에서는 Karpathy의 작업을 그의 일반적인 Gist 페이지 링크와 함께 인용했습니다.

기술적으로는 참조(reference)가 존재했습니다. 하지만 실질적으로는 감사(auditable)가 불가능했습니다. 독자는 어떤 Gist가 해당 주장을 뒷받침하는지, 그것이 언제 생성되었는지, 혹은 제가 그것을 정확하게 표현했는지 알 수 없었습니다.

저는 프로필 수준의 링크를 정확한 LLM Wiki Gist로 교체하였고, 저자, 생성 날짜, 액세스 날짜, 캡처 방법 및 한계점을 포함하는 별도의 소스 레코드(source record)를 생성했습니다.

실수는 작았지만, 교훈은 그렇지 않았습니다. 참조(references) 섹션은 증거의 출처(evidence provenance)와 동일한 것이 아닙니다. 검색 결과 스니펫(snippets), 홈페이지, 모델의 의역(paraphrases)은 단서일 뿐입니다. 그것들은 소스 자체를 대체할 수 없습니다.

의미론적 검토(Semantic review)와 결정론적 체크(deterministic checks)는 서로 다른 문제를 해결합니다

자연어 지침(Natural-language instructions)은 편집적 판단을 표현하는 데 유용합니다:

• 이 소스가 해당 주장을 뒷받침할 만큼 충분히 신뢰할 수 있는가?
• 요약 과정에서 의견 불일치(disagreement)가 삭제되었는가?
• 결론이 이제 시대에 뒤떨어진(stale) 정보인가?
• 추론(inference)이 사실로 제시되었는가?

자연어 지침은 일반적인 코드가 안정적으로 찾아낼 수 있는 기계적 오류를 잡아내는 데에는 비효율적인 방식입니다:

• 필수 필드 누락
• 중복된 ID
• 깨진 상대 경로 링크
• 잘못된 콘텐츠 유형(content type)으로 저장된 파일
• 인덱스에서 누락된 페이지

제 구현체는 이러한 구조적 체크를 수행하기 위해 오직 표준 라이브러리(standard library)로만 구축된 작은 Python 도구를 사용합니다. 저장소의 검증 명령은 유닛 테스트(unit tests)와 헬스 체크(health check)를 모두 실행합니다:

make verify

이것이 지식이 정확하다는 것을 증명하지는 않습니다. 이는 정의된 구조적 불변량(structural invariants) 세트가 유지되고 있음을 증명합니다. 의미론적 검토(Semantic review)와 결정론적 검증(deterministic validation)은 상호 보완적인 것이지, 서로 대체 가능한 것이 아닙니다.

이번 주말에 직접 구축해 볼 수 있는 최소한의 구현체

저의 전체 디렉토리 구조가 모두 필요하지는 않습니다. 다음과 같이 시작하세요:

sources/
knowledge/
projects/
...

그런 다음 다섯 가지 제약 사항을 추가하세요.

1. 권위 있는 저장소(authoritative store)를 선택하세요

Markdown 파일과 로컬 자산(local assets)을 기록의 원천(source of record)으로 취급하세요. 노트 앱, 벡터 데이터베이스(vector databases), 그래프 뷰(graph views)는 유용한 인터페이스가 될 수 있지만, 지식의 유일한 복사본이 되어서는 안 됩니다.

2. 출처(sources)와 합성(synthesis)을 분리하세요

sources/ 디렉토리에 주장의 기원을 보존하세요. 수정 가능한 요약본과 개념 페이지는 knowledge/에 두세요. AI가 생성한 요약을 소스 계층(source layer)으로 승격시키지 마세요.

3. 에이전트의 수정 규칙을 작성하세요

AGENTS.md는 다음 질문에 답할 수 있어야 합니다:

• 에이전트가 편집하기 전에 반드시 읽어야 하는 것은 무엇인가?
• 파일 이름은 어떻게 지정하며, 중복 제거(deduplication)는 어떻게 수행하는가?
• 어떤 기록이 편집 가능하며, 어떤 기록이 추가 전용(append-only)인가?
• 사실(facts)은 어떻게 인용되며, 추론(inferences)은 어떻게 라벨링되는가?
• 작업이 완료되기 전에 어떤 검사(checks)를 통과해야 하는가?

4. 최소한의 스키마(schema)를 사용하세요

id, type, status, created, updated, tags로 시작하세요. 관찰된 검색(retrieval), 검토(review), 또는 협업(collaboration) 문제를 해결할 때만 필드를 추가하세요.

첫날부터 만들어진 거대한 온톨로지(ontology)는 대개 준비를 가장한 유지보수 비용에 불과합니다.

5. 기계적인 규칙을 테스트로 전환하세요

결정론적 코드(deterministic code)를 사용하여 필수 필드, 고유 ID, 링크, 파일 위치, 인덱스 범위(index coverage)를 확인하세요. 모델의 판단(model judgment)은 소스의 품질, 모순, 불확실성 및 합성(synthesis)을 위해서만 남겨두세요.

언제 벡터 검색(vector search)을 추가해야 할까요?

첫날부터 도입하지 마세요.

적당한 규모에서는 인덱스 파일과 전체 텍스트 검색(full-text search)만으로도 충분할 수 있습니다. 다음과 같이 반복되는 실패 사례를 명확히 지목할 수 있을 때 BM25, 임베딩(embeddings), 재순위화(reranking), 또는 그래프 데이터베이스(graph database)를 추가하세요:

• 이미 알고 있는 정보를 반복적으로 찾기 어려울 때
• 인덱스가 너무 커서 탐색하기 힘들 때
• 어휘 불일치(vocabulary mismatch)로 인해 키워드 검색이 실패할 때
• 거의 중복된 페이지들이 계속 나타날 때
• 관계 쿼리(relationship queries)가 작업의 핵심이 되었을 때

이것은 보편적인 규칙이 아니라 공학적인 임계점(engineering threshold)입니다. 코퍼스(corpus), 쿼리 패턴(query patterns), 그리고 협업자의 수가 증가함에 따라 검색 인프라(retrieval infrastructure)가 필요해질 수 있습니다. 이는 가능한 한 언제든 다시 구축할 수 있는 가속화 계층(acceleration layer)으로 유지되어야 합니다.

자주 묻는 질문 (Frequently asked questions)

내구성이 있는 AI 지식 베이스(durable AI knowledge base)란 무엇인가요?

이는 출처의 기원(source provenance)을 보존하고, 수정 가능한 합성(revisable synthesis)을 유지하며, 변경 사항을 기록하고, 인간과 에이전트(agents)에게 컬렉션을 업데이트하기 위한 명시적인 규칙을 제공하는 지식 시스템입니다. 그 가치는 단순히 현재의 쿼리에 답하는 것에서 오는 것이 아니라, 축적되고 감사 가능한(auditable) 작업에서 나옵니다.

Markdown 위키가 RAG를 대체할 수 있나요?

아니요. 관리되는 위키는 질문들 사이에서 지속되어야 하는 결론과 관계(relationships)를 저장합니다. RAG(Retrieval-Augmented Generation) 또는 다른 검색 방법들은 쿼리 시점에 관련 자료를 찾는 것을 도와줍니다. 많은 시스템이 이 두 가지를 모두 사용할 때 이점을 얻습니다.

지식 관리에 왜 Git을 사용하나요?