Agentic Knowledge Base: 설계 없이 마크다운 폴더와 정리 에이전트로 시작하는 지식 베이스

에이전트가 읽고 찾는 지식 베이스는 분류 체계를 먼저 설계하지 않아도 됩니다. 평범한 마크다운 폴더를 정본으로 두고 캡처와 검색은 에이전트에게, 주기적인 정리는 janitor에게 맡기면 구조는 쌓이면서 드러납니다. 팀에서 쓰려면 삭제 금지 같은 쓰기 규칙, 판단이 필요한 항목을 사람이 보는 검토 큐, 답마다 출처 파일을 다는 원칙을 처음부터 정해야 합니다.

요약

Chris Lettieri는 Obsidian을 오래 써 온 사람으로, 2025년 2월부터 에이전트 기반 노트 도구를 만들어 왔습니다. 2026년 6월 28일 글에서 그는 약 16개월 동안 직접 운영한 agentic knowledge base(에이전트가 읽고 쓰며 검색하는 지식 베이스)의 시작법을 정리합니다. 첫 시스템에서 그는 taxonomy, 태그 체계, ontology, entity extraction, knowledge graph부터 설계했습니다. 지금은 그것을 실수로 봅니다. 지식의 모양을 모르는 채로 정한 구조는 추측일 뿐이기 때문입니다. 대신 세 가지로 시작하라고 권합니다. 진실 원천인 마크다운 폴더, 캡처와 검색을 맡는 에이전트, 주기적으로 노트를 정리하고 가벼운 map(길잡이 색인)을 관리하는 janitor(정리 담당 에이전트)입니다.

시작 구성은 셋뿐입니다. 폴더가 정본이고, 에이전트와 janitor는 그 위에서 일합니다.

글의 뒷부분은 이 단순한 구성이 어떻게 커 가는지를 다룹니다. 저자는 Karpathy의 LLM Wiki, Garry Tan의 gbrain, j-wang의 knowledge-agent 템플릿, 자신의 OpenAugi를 나란히 놓고 오늘의 agentic knowledge base에 공통된 8요소를 뽑습니다. 그리고 각 요소는 단순한 구성이 실제로 깨질 때만 더하라고 말합니다. 파일이 너무 거칠면 더 작은 단위를, 관계가 중요해지면 그래프를, 검색이 시끄러우면 라우팅과 hybrid retrieval을 더합니다. 마지막으로 저자는 사람을 루프에 남겨 두라고 합니다. 에이전트가 읽기와 종합을 다 하면 이해 없이 참고 시스템만 남는다고 봅니다. 아래에서는 이 흐름을 여섯 개념으로 풀고 한국 기업의 팀 하나가 6주 파일럿으로 옮길 때 정할 것을 덧붙였습니다.

2025년 2월 시작해 약 16개월 운영한 뒤 쓴 글입니다.

핵심 메커니즘

Emergent Structure: 구조는 설계하지 않고 쌓이면서 드러나게

무엇인가. 분류 체계를 미리 정하지 않고 캡처가 쌓인 뒤 반복되는 태그와 주제를 보고 구조를 정하는 방식입니다. 작동은 이렇습니다. 사람은 생각, 출처, 관찰을 분류 없이 넣습니다. 에이전트는 새 태그를 만들기 전에 기존 태그를 다시 씁니다. 같은 주제를 공유하는 노트가 늘면 그 주제가 map에 올라가고 시간이 지나면 큰 영역이 됩니다. 저자의 Obsidian vault는 이렇게 다섯 영역으로 자리 잡았습니다. 미리 짠 틀이 아니라 수년간의 캡처에서 나온 구조입니다.

언제 쓰나. 무엇을 모을지 아직 모르는 팀, 회의록과 메모처럼 형식이 제각각인 자료에 맞습니다. 이미 업무 정의가 굳어 있고 여러 시스템이 같은 용어를 써야 하는 곳(예: 부품 코드 체계)은 사정이 다릅니다. 그런 데이터 층의 쌓는 순서는 Taxonomy부터 Context Graph까지 노트에 정리돼 있습니다. 가상 예시로, 구매팀이 석 달 동안 협력사 메모를 분류 없이 모았더니 ‘납기 지연’, ‘단가 재협상’, ‘품질 클레임’ 세 주제가 반복돼 map의 첫 themes가 됩니다.

구조는 미리 정하지 않고, 반복되는 주제가 map에 오르며 생깁니다.

Folder · Agent · Janitor: inbox에서 notes와 map으로

시작 구성은 폴더 하나와 규칙 파일 셋입니다. AGENTS.md는 에이전트가 어떻게 행동할지, JANITOR.md는 정기 정리를 어떻게 할지 적습니다. MAP.md는 어디를 볼지 알려 주는 색인이며 거의 빈 채로 시작합니다. 폴더는 정리 전 캡처를 담는 inbox/와 분류된 노트를 담는 notes/ 둘입니다.

흐름은 한 방향입니다. 새 자료는 날짜가 붙은 파일로 inbox에 들어갑니다. janitor는 일정에 따라, 또는 inbox가 차면 돌면서 노트마다 기존 태그를 달고 관련 노트를 링크합니다. 분명한 것은 notes/로 옮깁니다. 모호하거나 서로 어긋나는 항목은 inbox에 그대로 두고 inbox/_review.md에 적어 사람에게 넘깁니다. 노트 세 개 이상이 공유하는 주제는 map의 themes에 올립니다. janitor는 사람이 쓴 글을 지우거나 고쳐 쓰지 않습니다.

janitor는 분명한 것만 옮기고, 판단이 필요한 것은 사람에게 넘깁니다. 사람이 쓴 글은 지우지 않습니다.

Capture → Maintain → Retrieve: map 먼저, 마크다운이 정본

루프는 세 단계입니다. 사람이 캡처하고, janitor가 유지하고, 에이전트가 찾아 답합니다. 찾을 때 순서가 정해져 있습니다. map을 먼저 읽고 관련 노트만 연 뒤, 어떤 파일을 썼는지 밝히며 답합니다. map은 agentic retrieval(에이전트가 스스로 찾아 들어가는 검색)을 위한 싼 색인입니다. 에이전트가 폴더 전체를 열거나, 자기가 만든 요약을 원문인 것처럼 내놓으면 안 됩니다.

정본과 파생물을 가르는 선도 이 단계에서 나옵니다. 마크다운 파일이 정본입니다. 나중에 붙이는 검색 인덱스나 임베딩 저장소는 언제든 파일에서 다시 만들 수 있는 파생층입니다. 그래서 도구를 바꾸거나 인덱스가 망가져도 지식은 잃지 않습니다. 저자가 권하는 사용 리듬은 capture, janitor, review, ask의 반복입니다.

사용 리듬은 capture → janitor → review → ask의 반복입니다.

마크다운만 정본이고 나머지는 다시 만들 수 있습니다. 표의 정리는 원문 설명을 바탕으로 AX Review가 구성.

Eight Common Components: 오늘의 agentic knowledge base에 공통된 8요소

저자는 여러 시스템을 비교해 공통 요소 여덟 개를 뽑습니다. 에이전트가 읽기만 하고 덮어쓰지 않는 raw source file(원본 마크다운), 추론 단위인 knowledge unit(페이지, 블록, 개념 같은 조각), 유사도가 아니라 실제 링크로 이은 typed graph, 토큰을 쓰기 전에 어디를 볼지 알려 주는 routing index, 행동 규칙을 담은 config file, 키워드·벡터·그래프 검색을 함께 쓰는 hybrid retrieval, 중복 제거와 통합까지 맡게 된 maintenance loop, 그리고 보통 MCP나 CLI로 여는 agent interface입니다.

한 줄로 줄이면 이렇습니다. 마크다운을 진실로 두고 연결된 단위로 쪼갭니다. 싼 라우팅 색인을 두고, config가 다스리는 인터페이스로 검색을 연 뒤 꾸준히 유지합니다. 시작 구성도 이 여덟 칸에 이미 대응합니다. 다만 대부분의 칸이 가장 단순한 형태로 들어 있을 뿐입니다.

공통 8요소(원문). 오른쪽 열의 시작 구성 대응은 AX Review 정리.

Add Layers Only When It Breaks: 깨질 때만 층을 더한다

단순 구성에서 출발해, 그 구성이 실제로 만든 문제가 있을 때만 층을 더합니다. 저자가 든 신호는 셋입니다. 파일 하나가 추론 단위로 너무 거칠어지면 knowledge unit을, 노트 사이의 관계가 답의 품질을 좌우하면 typed graph를, 검색 결과가 시끄럽거나 에이전트에 들어가는 컨텍스트가 부풀면 routing과 hybrid retrieval을 더합니다. 어떤 층을 더해도 원칙은 같습니다. 에이전트에게 압축된 map과 탐색 도구를 주고 필요하면 원본 파일까지 파고들게 합니다.

저자 자신의 시스템도 이렇게 자랐습니다. 그는 이 모델을 Contextgraph라고 부르고 OpenAugi로 구현했습니다. janitor는 분할, 링크 갱신, 요약 갱신, 중복 제거, 인덱스 동기화를 하는 수집·유지 파이프라인이 됐습니다. 더 발전한 참고 사례로 든 gbrain은 매일 밤 노트를 통합하고 중복을 지우는 ‘dream cycle’을 돌립니다.

원문의 세 신호. 단순 구성이 실제로 만든 문제가 있을 때만 그 층을 더합니다.

Route by Default, Synthesize on Demand: 기본은 길 안내, 종합은 요청할 때만

인프라가 좋아진다고 사고가 좋아지지는 않습니다. 저자의 우려는 에이전트가 읽기와 종합을 모두 맡을 때 생깁니다. 사람에게는 이해 없이 참고 시스템만 남습니다. 그래서 지저분하고 미완성인 노트를 진실 원천으로 두고 시스템은 그쪽으로 길을 안내하고 연결을 드러내는 데 씁니다. 종합은 요청할 때만 만들고 결과물은 초안으로 다룹니다. 의미가 만들어지는 자리에는 사람이 검토합니다. 저자는 이를 “route by default, synthesize on demand”라는 문장으로 줄입니다.

가상 예시로, 팀장이 “지난 분기 협력사 이슈를 정리해 달라”고 하면 에이전트는 먼저 map에서 관련 노트 목록과 경로를 보여 줍니다. 요약은 팀장이 따로 요청할 때만 만들고 ‘초안’ 표시를 단 채 별도 폴더에 둡니다. 그 요약이 다음 질문의 근거로 인용되지는 않습니다.

기본은 길 안내이고, 종합은 요청할 때 초안으로 만들어 사람이 봅니다.

통념과 다른 주장

흔히 이렇게 봅니다지식 베이스를 만들려면 taxonomy와 태그 체계, ontology를 먼저 설계하고 그 틀에 맞춰 자료를 넣어야 한다.

저자는 이렇게 봅니다지식의 모양을 모를 때 정한 구조는 추측입니다. 평범한 폴더와 정리 루프로 시작하면 구조는 쌓이면서 드러나고 층은 실제로 필요해졌을 때 더하면 됩니다.

근거저자는 첫 시스템에서 taxonomy, ontology, entity extraction, knowledge graph부터 설계했다가 이를 실수로 꼽습니다. 그의 vault는 미리 설계하지 않았는데도 수년간의 캡처에서 다섯 영역으로 자리 잡았습니다.

구조를 먼저 정할지, 쌓인 뒤에 드러나게 할지의 차이입니다.

흔히 이렇게 봅니다에이전트가 자료를 다 읽고 위키처럼 종합해 두면 지식이 저절로 쌓인다.

저자는 이렇게 봅니다에이전트가 읽기와 종합을 다 하면 이해 없이 참고 시스템만 남습니다. 기본은 길 안내에 두고 종합은 요청할 때 초안으로 만들어 사람이 검토합니다.

근거저자는 이 시작 구성에서도 에이전트가 생성한 요약을 원문처럼 내놓지 말고 쓴 파일을 인용하게 합니다. 또 LLM Wiki만으로는 지식이 복리로 쌓이지 않는다는 주장을 별도 글로 펴냈습니다.

종합을 기본값으로 둘지, 요청할 때만 만들지의 차이입니다.

저자가 든 사례

저자의 Obsidian vault: 설계하지 않은 다섯 영역

상황: 첫 시스템에서 무엇이 필요한지 알기 전에 taxonomy, 태그, ontology, semantic clustering, entity extraction, knowledge graph를 먼저 설계했습니다.
한 일: 사전 구조를 내려놓고 캡처를 이어 가며 구조가 자리 잡게 뒀습니다.
결과: vault는 research, OpenAugi, content, personal growth, personal systems 다섯 영역으로 정리됐고 Tiago Forte의 PARA에 느슨하게 기댑니다. 걸린 기간은 ‘수년’으로만 밝혔습니다.
연결: Emergent Structure의 사례입니다.

저자의 vault(원문). 다섯 영역은 미리 설계한 것이 아닙니다.

네 시스템 비교: 공통 8요소

상황: 저자는 Karpathy의 LLM Wiki(2026년 4월)가 이 아이디어를 주류로 가져왔다고 보고 그 뒤의 시스템들이 서로 닮았다고 관찰합니다.
한 일: Karpathy의 LLM Wiki, Garry Tan의 gbrain, j-wang의 knowledge-agent 템플릿, 저자의 OpenAugi를 나란히 놓고 구성 요소를 비교했습니다.
결과: 여덟 요소가 공통으로 보였습니다. 원본 마크다운, 추론 단위, 링크 그래프, 라우팅 색인, config, hybrid retrieval, 유지 루프, MCP나 CLI 인터페이스입니다. 시스템별 성능 수치는 원문에서 밝히지 않았습니다.
연결: Eight Common Components의 근거입니다.

네 시스템 비교(원문). 성능 수치는 원문에 없습니다.

OpenAugi와 gbrain: janitor가 파이프라인이 되기까지

상황: 시작 구성의 janitor는 태그, 링크, 노트 이동, map 갱신만 맡습니다.
한 일: 저자는 Contextgraph 모델을 OpenAugi로 구현하며 janitor를 수집·유지 파이프라인으로 키웠습니다. gbrain은 매일 밤 통합과 중복 제거를 하는 dream cycle을 둡니다.
결과: janitor가 분할, 링크 갱신, 요약 갱신, 중복 제거, 인덱스 동기화를 맡습니다. 처리량이나 비용 수치는 원문에서 밝히지 않았습니다.
연결: Add Layers Only When It Breaks의 사례입니다.

janitor의 성장(원문). 처리량·비용 수치는 원문에 없습니다.

기술 디테일: 팀 공유 지식 베이스를 실제로 돌리려면

아래는 원문의 시작 구성을 한국 기업의 팀 하나가 함께 쓰는 지식 베이스로 옮길 때 필요한 설계로, AX Review가 새로 작성했습니다. 규칙 문구, 필드 이름, 숫자는 모두 가상 예시입니다.

세 구성을 팀 폴더로 옮기려면 개인 vault의 구조에 두 가지를 더합니다. 원본 자료를 읽기 전용으로 두는 sources/와, 요청받아 만든 종합을 정본과 섞지 않는 drafts/입니다. 노트 frontmatter에는 작성자와 민감도를 넣습니다. 팀에서는 ‘누가 쓴 문장인가’와 ‘누가 봐도 되는가’가 개인 vault보다 중요하기 때문입니다. 저장소는 변경 이력이 남는 git 저장소를 권합니다. janitor의 모든 변경이 diff로 남아야 삭제와 재작성을 기계로 잡을 수 있습니다.

team-kb/
  AGENTS.md          에이전트 행동 규칙 (팀 합의본)
  JANITOR.md         정리 작업 규칙
  MAP.md             janitor가 관리하는 길잡이
  sources/           회의록 원본, 고객 메일 사본, 기사 (읽기 전용)
  inbox/             정리 전 캡처: 2026-11-03-0912-kjh.md
    _review.md       사람이 판단할 항목
  notes/             정리된 노트 (노트 하나에 주제 하나)
  drafts/            요청받아 만든 종합 (초안, 인용 금지)

---
created: 2026-11-03
author: kjh                 # 사번 또는 이니셜
source: sources/2026-11-03-협력사-주간회의.md
tags: [협력사, 납기]
status: inbox               # inbox | note
sensitivity: internal       # public | internal | restricted
---

팀용 폴더(가상 예시). 원문 구성에 sources/와 drafts/를 더했습니다.

AGENTS·JANITOR·MAP을 팀 규칙으로 바꾸려면 세 파일을 ‘누가 읽고 누가 고치나’로 나눕니다. 아래는 구매팀을 가정해 새로 쓴 규칙의 요지입니다. AGENTS.md에는 다섯 줄을 둡니다. 정본은 이 폴더의 마크다운이며 에이전트는 파일을 지우거나 사람이 쓴 문장을 고치지 않는다. 캡처 요청이면 inbox에 날짜와 작성자를 붙인 파일을 만들고 분류하지 않는다. 질문이면 MAP.md를 먼저 읽고 노트를 최대 8개까지만 열며 답의 사실 문장마다 근거 파일 경로를 단다. 근거가 없으면 ‘노트에 없음’이라고 답한다. 종합은 요청받을 때만 drafts/에 ‘초안’ 표시와 함께 쓰고 restricted 노트는 열지 않고 제목만 알린다.

JANITOR.md에는 실행 조건과 금지 사항을 적습니다. 실행은 평일 18시 하루 한 번, 또는 inbox가 30건을 넘을 때입니다. 노트마다 MAP의 ‘사용 중 태그’에서 태그를 고르고 새 태그는 제안만 해서 _review로 보냅니다. 관련 노트 링크는 5개까지 답니다. 같은 뜻의 태그(‘수요 예측’과 ‘수요예측’)와 깨진 링크는 고칠 목록을 만듭니다. 주제를 공유하는 노트가 3개 이상이면 MAP의 themes에 올립니다. 모호함, 서로 어긋나는 내용, 민감정보 의심은 inbox에 남기고 사유를 _review.md에 적습니다. MAP.md는 themes, 사용 중 태그(건수 포함), 반복되는 열린 질문 세 절로 두고 사람은 직접 고치지 않습니다. 1,500단어를 넘으면 theme별 하위 map으로 나눕니다.

규칙 파일별 독자와 관리자(가상 예시).

janitor를 반복 가능하게 돌리려면 노트 하나에 호출 하나로 나누고 모델에게는 변경 자체가 아니라 변경 제안을 JSON으로만 받습니다. 파일은 검사 코드가 고칩니다. temperature는 0으로 둡니다. 출력은 스키마로 검증해 어긋나면 한 번 다시 묻고 그래도 어긋나면 _review로 보냅니다. 편차는 같은 inbox 50건을 두 번 돌려 태그 제안의 일치율로 잽니다. 80% 아래면 새 태그를 막고 기존 태그 목록에서만 고르게 규칙을 좁힙니다.

{
  "file": "inbox/2026-11-03-0912-kjh.md",
  "tags": ["협력사", "납기"],
  "new_tag_proposals": [],
  "links": ["notes/협력사-납기-지연-패턴.md"],
  "action": "move_to_notes",
  "review_reason": null,
  "map_updates": [{ "theme": "협력사 납기 지연", "note_count": 4 }]
}

action은 move_to_notes와 keep_in_inbox 둘뿐이고 review_reason은 ambiguous, conflict, sensitive, new_tag 가운데 하나이거나 null입니다. 검사 코드는 적용 전에 두 가지를 확인합니다. 첫째, diff에 사람이 쓴 본문의 삭제나 수정 줄이 있으면 적용하지 않습니다. janitor는 frontmatter와 링크 줄만 더할 수 있습니다. 둘째, 주민등록번호, 계좌번호, 개인 전화번호 패턴이 보이면 sensitive로 바꿔 격리합니다.

모델은 제안만 하고 파일은 검사 코드가 고칩니다(가상 예시).

map 먼저 찾고 출처를 달게 하려면 검색을 세 걸음으로 고정합니다. MAP.md를 읽고 후보 노트 경로를 고른 뒤 그 노트들만 열고 사실 문장마다 [notes/…md] 형식의 경로를 답니다. 응답 뒤 검사 코드가 인용 경로가 실제로 있고 이번 호출에서 연 파일인지 확인합니다. 아니면 그 문장을 지우거나 다시 묻습니다. 검색 도구는 처음에는 파일 읽기와 키워드 검색만 MCP 서버나 CLI로 엽니다. 벡터 인덱스는 층 추가 신호가 나온 뒤에 붙이고 마크다운에서 언제든 다시 만들 수 있게 빌드 스크립트로 둡니다. 에이전트 권한은 sources/ 읽기 전용, inbox/·notes/·drafts/·MAP.md 쓰기이며 삭제 도구는 주지 않습니다. 쓰기를 실행 직전에 거르는 설계는 Context Layer 노트와 같은 발상입니다.

검색은 세 걸음으로 고정하고 마지막에 인용을 기계로 확인합니다(가상 예시).

층을 더할 때를 숫자로 정하려면 원문의 세 신호마다 측정값과 기준선을 둡니다. 팀이 실제로 자주 묻는 골든 질문 20개를 정해 두고 2주마다 같은 질문으로 잽니다. 예를 들어 typed graph는 ‘누가 담당인가’, ‘어느 협력사인가’ 같은 관계 질문에서 20개 중 5개 이상 틀릴 때 더합니다. 기준선은 업무에 맞춰 조정하고 넘는 신호가 하나면 그 층 하나만 더합니다.

층 추가 기준(가상 예시). 원문의 세 신호에 측정값을 붙였습니다.

실패하는 경우와 대응. 새 태그가 매주 늘어 같은 뜻의 태그가 쌓이면, 새 태그는 제안만 받고 KB 오너가 주 1회 승인합니다. drafts/의 요약이 다음 답의 근거로 인용되면, 인용 검사에서 drafts/ 경로를 막습니다. MAP이 커져 에이전트가 map만 읽어도 컨텍스트가 무거워지면 theme별 하위 map으로 나눕니다. 민감정보가 inbox로 들어오면 sensitivity 필드와 패턴 검사로 격리합니다. restricted 노트는 별도 폴더에 두어 에이전트 권한 밖으로 뺍니다. janitor가 사람 문장을 고친 diff가 나오면 적용을 거부하고 그 규칙을 JANITOR.md에 금지로 다시 적습니다.

실패 유형과 대응(가상 예시). 오른쪽 칸이 대응입니다.

현업 실행 디테일: 누가, 언제, 무엇을

역할	담당	6주 동안 하는 일
스폰서	대상 팀의 팀장	대상 범위와 민감정보 기준 승인, 6주차 판정
KB 오너	팀원 1명	규칙 세 파일 관리, 새 태그 주 1회 승인, 주간 점검
_review 검토 담당	팀원 2명, 1주 단위 순번	매일 10분 검토 큐 처리, 처리 결과 기록
기여자	팀원 전원	분류 없이 캡처, map을 통해 질문
엔지니어	AX 조직 1명	janitor 일정, MCP·CLI 연결, diff·민감정보 검사 코드
정보보호	보안 담당 1명	권한 점검, restricted 기준, 외부 모델 사용 승인

시작 전 준비물: 팀 공유 git 저장소와 권한, 최근 3개월 회의록·보고서 50~100건(마크다운으로 변환), 팀원이 실제로 자주 다시 찾는 골든 질문 20개와 모범 답의 근거 문서, 민감정보 분류 기준(public, internal, restricted), 사내 승인을 받은 에이전트 도구와 모델.

주차	할 일	산출물
1주	폴더와 규칙 세 파일 작성, 표본 문서 inbox 투입, 골든 질문 확정	팀 저장소, 규칙 v1, 골든 질문 20개
2주	janitor 매일 실행, _review 검토 시작, 태그 목록 정리	태그 목록 v1, 검토 처리 기록
3주	팀원 전원 하루 1건 이상 캡처, map을 통한 질문	질문 로그, MAP 첫 themes
4주	골든 질문 1차 측정(출처 인용률, 정답 수)	측정표, 실패 질문 목록
5주	규칙 수정, 층 추가 신호 점검	규칙 v2, 층 추가 여부 메모
6주	2차 측정, 판정 회의	판정 보고서(확대, 수정, 중단)

팀 단위 6주 파일럿 일정(예시).

_review 검토 큐 운영. 검토 담당은 매일 정해진 시간에 10분 동안 큐를 비웁니다. 항목마다 결과를 넷 중 하나로 적습니다. 노트로 이동 승인, 새 태그 승인 또는 기존 태그로 대체, 보류(사유 기록), 민감정보 격리입니다. 판단이 갈리는 항목은 작성자에게 묻고 그래도 정해지지 않으면 KB 오너에게 넘깁니다. 처리 시간은 _review.md에 올라온 시각부터 결과를 적은 시각까지로 잽니다.

권한 규칙. 파일 삭제는 KB 오너만 하고 에이전트에게는 삭제 권한이 없습니다. restricted 노트는 별도 폴더에 두고 에이전트와 외부 모델의 접근을 막습니다. 고객 이름, 계약 단가, 개인 연락처가 들어간 자료는 inbox에 넣기 전에 정보보호 담당이 정한 규칙으로 가립니다.

성공 지표(가상 예시). 6주 파일럿에서 볼 숫자는 넷입니다. 출처 인용률은 답의 사실 문장 가운데 근거 파일 경로가 달린 비율입니다. 골든 질문 정답률은 20개 중 모범 답과 같은 근거를 찾은 비율입니다. 검토 큐 처리율은 2영업일 안에 결과가 적힌 항목의 비율입니다. 캡처 참여율은 주에 1건 이상 캡처한 팀원의 비율입니다.

6주차 목표값(가상 예시). 각 지표는 따로 계산한 비율입니다.

담당자 인터뷰 질문(1주차). 일주일에 가장 자주 다시 찾는 정보는 무엇이고 지금은 메일, 메신저, 드라이브 중 어디에 있습니까? 지워지면 안 되는 문서와 사람만 판단해야 하는 항목은 무엇입니까? 외부 모델에 보내면 안 되는 정보는 무엇입니까? 같은 뜻을 팀원마다 다르게 부르는 말이 있습니까?

진행 판정 기준(예시). 6주차에 출처 인용률 95% 이상, 골든 질문 16개 이상 정답, 검토 큐 처리율 90% 이상, 에이전트의 삭제나 사람 문장 수정 0건이면 옆 팀으로 넓힙니다. 인용률이 80% 아래이거나 수정 사고가 1건이라도 있으면 규칙과 권한부터 고치고 2주 연장합니다. 캡처 참여율이 50% 아래면 도구보다 습관의 문제로 보고 캡처 경로(메신저 봇, 메일 전달 주소)를 더 쉽게 만든 뒤 다시 잽니다.

판정 기준(예시). 숫자는 팀 규모와 자료의 민감도에 맞춰 조정합니다.

AX 적용 제언. 이 구성이 맞는 곳은 형식이 제각각인 기록이 쌓이고 같은 질문이 반복되는 팀입니다. 구매팀의 협력사 이슈 기록, 영업팀의 고객 대응 이력과 제안서, R&D의 실험 노트, AX 조직의 자료 서가가 대표적입니다. 순서는 한 팀, 골든 질문 20개, 6주 측정, 옆 팀 확대가 무난합니다. 기존 지식관리 프로젝트와 다른 점은 출발점입니다. 분류 체계 설계 워크숍으로 시작하지 않고 캡처와 정리 루프를 먼저 돌려 반복되는 주제를 확인한 뒤에 공통 용어를 정합니다. 여러 팀이 같은 용어를 써야 하는 단계가 오면 다섯 데이터 층과, 자동으로 뽑은 개념 초안을 현업이 인증하는 Agent Knowledge Foundation 노트를 함께 보면 됩니다. 어느 단계에서든 종합은 요청 시 초안으로, 검토는 사람에게 남긴다는 원칙은 그대로 둡니다.

원문 사례

항목	내용
저자·발표처	Chris Lettieri, Bits of Chris(2026.06.28, 2026.10.13 수정), 전문 공개
경험	2025년 2월부터 에이전트 기반 노트 도구 제작, 약 16개월 운영
시작 구성	마크다운 폴더(정본), 에이전트(캡처·검색), janitor(정리·map 관리)
폴더	AGENTS.md, JANITOR.md, MAP.md, inbox/(_review.md 포함), notes/
노트 규칙	노트 하나에 아이디어 하나, wikilinks, 소문자 해시태그(기존 재사용), 사전 taxonomy 없음
map 규칙	themes는 노트 3개 이상이 공유할 때 추가, 사용 중 태그, 열린 질문
루프	capture → maintain → retrieve, 사용 리듬은 capture · janitor · review · ask
공통 8요소	raw source, knowledge unit, typed graph, routing index, config, hybrid retrieval, maintenance loop, agent interface
비교 대상	Karpathy LLM Wiki(2026.04), Garry Tan gbrain, j-wang knowledge-agent 템플릿, OpenAugi
층 추가 신호	파일이 거칠 때 knowledge unit, 관계가 중요할 때 typed graph, 검색이 시끄러울 때 routing과 hybrid retrieval
vault	다섯 영역(research, OpenAugi, content, personal growth, personal systems), PARA에 느슨하게 기반
원칙	기본은 길 안내, 종합은 요청 시 초안, 의미가 만들어지는 곳에 사람 검토

핵심 개념

LLM Wiki: Karpathy가 2026년 4월 제안한, LLM이 자료를 읽어 위키 형태의 지식 베이스를 만들고 유지하는 방식. 저자는 이 아이디어가 agentic knowledge base를 주류로 가져왔다고 본다.
wikilinks: [[노트 이름]] 형식으로 노트끼리 직접 잇는 링크. Obsidian 같은 도구가 쓴다. typed graph의 가장 단순한 형태.
PARA: Tiago Forte의 정리법. Projects, Areas, Resources, Archives 네 묶음으로 자료를 나눈다.
OpenAugi: 저자가 만든 에이전트 지식 도구. 저자의 Contextgraph 모델을 구현한다.
gbrain: Garry Tan의 지식 시스템. 매일 밤 통합과 중복 제거를 하는 dream cycle을 돌린다.
MCP: Model Context Protocol. 에이전트가 외부 도구와 데이터에 접속하는 표준 방식. 8요소의 agent interface로 흔히 쓰인다.
derived layer(파생층): 검색 인덱스나 임베딩 저장소처럼 정본 파일에서 언제든 다시 만들 수 있는 층.

내 메모

TODO: 내 생각 추가

원문: Chris Lettieri, “How to Build Your Agentic Knowledge Base (after 16 months of running my own)“(Bits of Chris, 2026.06.28). 요약, 핵심 메커니즘, 통념과 다른 주장, 사례, 원문 사례 표는 글의 내용을 AX Review가 다시 정리했습니다. 원문의 시작용 지시문은 옮기지 않았습니다. 기술·현업 디테일의 팀 폴더 구조, 팀 규칙, JSON 예시, 검사 규칙, 일정, 지표, 판정 기준, 인포그래픽은 새로 작성했으며 숫자는 가상 예시입니다. 시작용 지시문을 포함한 원문 전체는 Bits of Chris에서 볼 수 있습니다.