AI Agent Lab

LLM Wiki의 핵심은 벡터 DB가 아니라 지식 아키텍처다

Obsidian frontmatter를 출발점으로, Google AI Agent 자료들이 말하는 RAG, 메모리, 품질, 거버넌스 관점에서 LLM Wiki를 다시 설계합니다.

LLM Wiki의 핵심은 벡터 DB가 아닙니다.
에이전트가 믿고 행동할 수 있는 지식 아키텍처입니다.

Google의 AI Agent 자료들을 보면 공통된 방향이 있습니다.

에이전트는 단순히 답변을 생성하는 모델이 아닙니다.
외부 지식을 검색하고, 도구를 호출하고, 상태를 기억하고, 때로는 업무를 실행하는 소프트웨어 시스템입니다.

그래서 LLM Wiki도 단순한 문서 저장소가 되면 안 됩니다.

Obsidian으로 생각해보면 더 분명합니다.

Obsidian 볼트는 Markdown 파일이 든 폴더입니다.
사람이 읽을 수 있고, Git으로 버전 관리할 수 있고, 코드로 파싱할 수 있습니다.

하지만 진짜 중요한 건 파일 내용이 아니라 맨 위의 메타데이터입니다.

1
2
3
4
5
6
7
8
9
---
domain: payments
owner: jane.kim
updated: 2026-01-08
source: adr
trust: high
agent_usable: true
audit_required: true
---

이 몇 줄이 LLM Wiki의 정보 아키텍처입니다.

어느 도메인의 지식인가.
누가 책임지는가.
최신인가.
얼마나 신뢰할 수 있는가.
에이전트가 직접 사용해도 되는가.
사용했다면 감사 로그를 남겨야 하는가.

Google의 RAG Engine 문서는 RAG 과정을 데이터 수집, 변환, 임베딩, 인덱싱, 검색, 생성의 흐름으로 설명합니다.
여기서 중요한 점은 임베딩이 첫 단계가 아니라는 겁니다. 먼저 데이터가 수집되고, 정리되고, 검색 가능한 단위로 변환됩니다. 벡터 DB는 그 뒤에 옵니다.

Google의 AI agent core concepts도 비슷한 방향을 말합니다. 에이전트의 데이터 아키텍처는 하나가 아닙니다. 장기 지식 베이스, 작업 중인 대화 상태, 그리고 행동을 기록하는 트랜잭션 메모리가 분리되어야 합니다.

그러면 LLM Wiki의 frontmatter도 단순 태그가 아닙니다.
에이전트의 메모리와 행동을 통제하는 계약입니다.

예를 들어 이런 코드가 먼저 필요합니다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
import frontmatter
from pathlib import Path

def load_vault(vault: str):
    for md in Path(vault).rglob("*.md"):
        note = frontmatter.load(md)
        meta = note.metadata

        if meta.get("agent_usable") is False:
            continue

        yield {
            "text": note.content,
            "path": str(md),
            "domain": meta.get("domain"),
            "owner": meta.get("owner"),
            "updated": meta.get("updated"),
            "trust": meta.get("trust", "unknown"),
            "audit_required": meta.get("audit_required", False),
        }

보세요.
아직 벡터 DB는 등장하지 않았습니다.

먼저 해야 할 일은 “무엇을 임베딩할지”가 아니라 “무엇을 에이전트가 믿고 써도 되는지”를 정하는 겁니다.

Google의 Agent Quality 백서는 “agent quality is an architectural pillar”라고 말합니다. 품질은 마지막 테스트 단계가 아니라 아키텍처의 일부라는 뜻입니다.

LLM Wiki도 마찬가지입니다.

나중에 검색이 잘 되는지 확인하는 문제가 아닙니다.
처음부터 지식의 출처, 신뢰도, 권한, 사용 가능성, 감사 가능성을 설계해야 합니다.

특히 개발 조직에서는 이 차이가 큽니다.

코딩 에이전트가 코드를 수정하기 전에 관련 ADR을 읽는가.
API를 바꾸기 전에 계약 문서를 확인하는가.
장애 대응 코드를 만들기 전에 과거 incident를 찾아보는가.
보안 정책 문서는 직접 인용해도 되는가, 아니면 사람 검토가 필요한가.

이 질문에 답하지 못하면 LLM Wiki는 그냥 “문서를 많이 넣은 검색창”이 됩니다.

반대로 이 질문에 답할 수 있으면 LLM Wiki는 에이전트가 매 작업마다 호출하는 지식 API가 됩니다.

그래서 저는 LLM Wiki를 만들 때 이렇게 시작하는 게 맞다고 봅니다.

  1. Obsidian 같은 Markdown 기반 지식 저장소를 만든다.
  2. 모든 노트에 domain, owner, updated, trust, agent_usable을 붙인다.
  3. 문서를 heading 단위로 쪼갠다.
  4. path와 metadata를 유지한 채 검색 색인에 넣는다.
  5. 그다음에야 벡터 DB나 RAG 엔진을 붙인다.

벡터 DB는 중요합니다.
하지만 마지막 10%에 가깝습니다.

앞의 90%는 정보 아키텍처입니다.

LLM Wiki의 질문은 “어떤 임베딩 모델을 쓸까?”가 아닙니다.

먼저 물어야 할 질문은 이것입니다.

에이전트가 이 지식을 믿고 행동해도 되는가?

참고 자료

지식 링크

연결된 글

이 글을 언급한 글

언급: LLM Wiki GEB로 만든 아이디어 생성기: 형식, 의미, 루프를 프롬프트로 바꾸는 법 괴델, 에셔, 바흐에서 얻은 형식 체계, 의미, 재귀, 자기참조, 이상한 루프의 통찰을 블로그·앱·수업·학원 운영 자동화에 쓰는 메타프롬프트로 정리합니다. 언급: an LLM Wiki starts with knowledge architecture, not a vector database Reading the Video: Ponytail Is Not a Code-Saving Trick. It Is an Agent Decision Ladder. A bilingual video note on Ponytail, the 'lazy senior developer' skill for AI coding agents, read together with its GitHub repo and benchmark writeup. 언급: LLM Wiki의 핵심은 벡터 DB가 아니라 지식 아키텍처 영상으로 읽기: Ponytail은 코드 절약 스킬이 아니라 에이전트 판단 사다리다 개발동생의 Ponytail 실험 영상을 GitHub repo와 벤치마크 원문까지 함께 읽으며, '게으른 시니어 개발자'가 어떻게 에이전트 하네스가 되는지 정리합니다. 언급: LLM Wiki의 핵심은 벡터 DB가 아니라 지식 아키텍처다 영상으로 읽기: Matt Pocock의 에이전틱 엔지니어링 워크플로우 — 모델이 아니라 하니스가 실력이다 David Ondrej × Matt Pocock 대담을 7개 구간 클립으로 끊어, '전략적 프로그래밍 → 에이전트 스킬 → 하니스 → 루프 vs 큐 → 개발자의 미래'로 읽고 내 생각을 붙인 영상 노트. 언급: An LLM Wiki starts with knowledge architecture, not a vector database Translation Is Not Automation. It Is Another LLM Wiki. A practical architecture for expanding a Korean blog into English through dynamic translation, editorial memory, and a dedicated Translation LLM Wiki. 언급: LLM Wiki의 핵심은 벡터 DB가 아니라 지식 아키텍처다 영어 번역은 자동 번역이 아니라 또 하나의 LLM Wiki다 한국어 블로그를 영어로 확장하기 위한 큰 설계. 자동 번역이 아니라 동적 번역, 번역 LLM Wiki, 리뷰 가능한 지식 운영체제로 접근합니다. 언급: LLM Wiki의 핵심은 벡터 DB가 아니라 지식 아키텍처다 책노트: The Edge of Objectivity 5회차 - 에너지와 장은 보이지 않는 것을 객관화한다 Carnot, Joule, Mayer, Helmholtz, Clausius, Faraday, Maxwell, Hertz, Mach, Einstein을 지나며 객관성이 물체의 운동에서 에너지, 확률, 장, 상대성의 추상적 구조로 이동하는 마지막 회차. 언급: LLM Wiki의 핵심은 벡터 DB가 아니라 지식 아키텍처다 책노트: The Edge of Objectivity 3회차 - 자연법은 윤리가 아니고, 화학은 언어가 된다 Newton의 과학이 계몽주의의 사회철학으로 번역될 때 생기는 is/ought 혼동과, Lavoisier가 화학을 저울·명명법·균형식의 언어로 다시 설계한 장면을 AI 시대의 스키마 설계와 연결한다. 언급: LLM Wiki의 핵심은 벡터 DB가 아니라 지식 아키텍처다 책노트: The Edge of Objectivity 1회차 - Galileo의 삼각형과 객관성의 인터페이스 The Edge of Objectivity 서문과 1장을 읽고, 근대 과학의 객관성을 마음가짐이 아니라 측정·수학화·검증 인터페이스의 탄생으로 읽어본 첫 번째 독서록. 언급: LLM Wiki의 핵심은 벡터 DB가 아니라 지식 아키텍처다 Preposition Globe: 전치사를 하나의 세계로 가르치는 LLM Wiki 실험 프롬프트 문서에서 출발한 영어 전치사 학습 도구 Preposition Globe를 배포하며, LLM Wiki가 어떻게 실행 가능한 학습 인터페이스로 확장되는지 기록합니다. 언급: LLM Wiki의 핵심은 벡터 DB가 아니라 지식 아키텍처다 책노트: 몰입 Flow 3회차 - 몸과 생각은 몰입의 훈련장이 된다 Flow 5~6장을 읽고 몸, 감각, 기억, 언어, 사고가 어떻게 몰입의 재료가 되는지 학습 루틴과 지식 작업 관점으로 정리한 세 번째 독서록. 언급: LLM Wiki의 핵심은 벡터 DB가 아니라 지식 아키텍처다 책노트: 몰입 Flow 2회차 - 즐거움은 쉬움이 아니라 설계된 도전에서 온다 Flow 3~4장을 읽고 쾌락과 즐거움의 차이, 몰입의 8요소, 도전-능력 균형을 개발자와 제품 설계 관점으로 정리한 두 번째 독서록. 언급: LLM Wiki의 핵심은 벡터 DB가 아니라 지식 아키텍처다 책노트: 몰입 Flow 1회차 - 행복은 의식의 질서에서 시작된다 Flow 서문과 1~2장을 읽고, 행복을 외부 조건이 아니라 주의와 의식의 질서 문제로 다시 정리한 첫 번째 독서록. 언급: LLM Wiki의 핵심은 벡터 DB가 아니라 지식 아키텍처다 코드베이스 모듈 지도는 개발 에이전트의 작업 기억이다 Reasonofmoon 블로그 코드베이스를 모듈 지도 앱으로 만들고, 이를 개발 에이전트가 작업 전에 가져야 할 working memory로 해석합니다. 언급: LLM Wiki의 핵심은 벡터 DB가 아니라 지식 아키텍처다 책 TXT 색인을 검색 앱으로 만들면 LLM Wiki의 최소 단위가 보인다 Book Index Workbench 데모를 통해 서점 메타데이터, 로컬 TXT 청크, 인용 후보, YAML 초안이 어떻게 하나의 LLM Wiki 지식 객체로 묶이는지 살펴봅니다. 언급: LLM Wiki의 핵심은 벡터 DB가 아니라 지식 아키텍처다 단어 암기 카드를 인터랙티브 HTML로 만들면 무엇이 달라질까 LLM이 만든 단어 데이터가 카드 UI, 그림, 애니메이션, 검토 가능한 학습 산출물로 바뀌는 과정을 standalone HTML 데모로 살펴봅니다. 언급: LLM Wiki의 핵심은 벡터 DB가 아니라 지식 아키텍처다 Tool Calling은 함수 호출이 아니라 인터페이스 설계다 Tool Calling을 함수 호출 기능이 아니라 에이전트와 외부 세계 사이의 계약면, 스키마, 권한, 도메인 언어를 설계하는 일로 다시 봅니다.
Next Reading

더 읽어보기

A Personal RAG System: Turning Obsidian Notes Into An AI Reference Library A practical path for starting RAG from Obsidian note hygiene, metadata, reviewed permanent notes, and verification loops instead of jumping straight into vector databases. 나만의 RAG 시스템: Obsidian 노트를 AI의 참고서로 만드는 법 RAG를 벡터 DB부터 시작하지 않고, Obsidian 노트 정리, frontmatter, 검색 가능한 영구 노트, 검증 루프에서 시작하는 실전 안내. 코드베이스 모듈 지도는 개발 에이전트의 작업 기억이다 Reasonofmoon 블로그 코드베이스를 모듈 지도 앱으로 만들고, 이를 개발 에이전트가 작업 전에 가져야 할 working memory로 해석합니다.
Comments

댓글

GitHub 계정으로 의견을 남길 수 있습니다. 댓글은 GitHub Discussions에 저장됩니다.