작업실 일지

스스로 축적되고 연결되는 조직 기억 — LLM Wiki와 온톨로지

#지식관리#온톨로지#RAG#위키

3줄 요약

  • AI 조직(HQ)의 모든 산출물·결정·사고·규칙이 자동으로 위키 카드가 되고, 온톨로지 관계로 연결되는 지식 계층을 구축했다 — 현재 위키 카드 271장, 그중 온톨로지 DB 등재 262노드·관계 엣지 1,500+.
  • 검색은 키워드(BM25)와 의미 임베딩(bge-m3)의 하이브리드, 관계 채움은 KGE 링크예측 + 증거 게이트(예측이 아니라 증거가 있는 관계만 채택)로 자동화했다.
  • 품질은 사람이 아니라 린트가 지킨다 — 끊어진 링크 0, 유령 참조 0을 6종 자동 검사 + cron 감사로 상시 유지. 고아 카드는 156→46으로 감소.

지식그래프 실측 렌더 — 위키 카드 271장 중 온톨로지 등재 262노드 / 1,523엣지.

1. 문제 — AI의 산출물은 쌓이는데 지식은 쌓이지 않는다

에이전트 조직이 일을 할수록 markdown 산출물이 폭증했다. 그런데 산출물의 존재와 조직이 그것을 기억하는 것은 다른 문제였다:

  • 3개월 전의 결정을 다시 논쟁한다 — 결정 기록이 어디 있는지 아무도(어떤 에이전트도) 모른다.
  • 같은 외부 라이브러리 함정에 두 번 빠진다 — 첫 번째 사고 기록이 검색되지 않는다.
  • 지식이 파일로는 있지만 연결이 없다 — 이 규칙이 어느 사고에서 나왔고 어느 훅이 강제하는지 추적 불가.

2. 설계 — 위키는 사람이 쓰는 것이 아니라 컴파일되는 것

핵심 결정: 위키를 수기 문서고가 아니라 빌드 산출물로 정의했다.

산출물(raw) ──▶ archivist 에이전트가 컴파일 ──▶ 카드(pages/) ──▶ index·log 자동 갱신
                                                  │
              자산(에이전트 28·스킬 29·훅 16) ──▶ census 생성기가 카드 73장 자동 생성
                                                  │
                              온톨로지 DB(SQLite) ◀─ 노드 262 · 엣지 1,500+ · 관계 유형 11종
  • 스키마 강제: 모든 카드는 slug/type/status/SSOT/관계(enforces, derived_from, supersedes…) frontmatter를 갖는다. 카드 유형은 doctrine(규칙)·decision(결정)·incident(사고)·pattern(패턴)·asset(자산)·external(외부지식) 등으로 분류 — “이 규칙은 저 사고에서 나왔고(derived_from) 이 훅이 강제한다(enforced_by)“가 그래프로 추적된다.
  • 검색 2계층: 정확 키워드는 BM25, 의미 검색은 bge-m3 임베딩(온톨로지 등재 262노드 전량), 두 결과를 RRF로 융합. “라우터이지 카탈로그가 아니다” — 위키는 답을 주는 곳이 아니라 정본(SSOT)으로 보내는 곳이라는 원칙을 유지했다.
  • 관계 자동 채움 + 증거 게이트: 링크예측 모델(TransE)로 누락 관계 후보를 뽑되, 본문에 증거가 확인되는 것만 채택한다. 그럴듯한 연결이 아니라 검증된 연결만 그래프에 들어간다.

3. 운영 — 품질을 사람이 아니라 파이프라인이 지킨다

자동 검사 (6종)현재 상태
끊어진 링크0
유령 SSOT 참조0
관계 비대칭 (A→B인데 B→A 없음)0
상태 모순 (폐기됐는데 참조됨)0
고아 카드 (어디서도 연결 안 됨)156 → 46
부패 카드 (오래 미갱신)62건 추적 중

이 린트는 cron 감사 에이전트가 정기 실행하고 위반은 로그로 남는다. 사람이 “위키 정리하자”고 마음먹을 필요가 없는 구조 — 품질이 습관이 아니라 파이프라인에 있다.

실패에서 배운 것도 기록해 둔다: 초기에 시도한 그래프 워크 검색(노드를 따라가며 답을 찾는 방식)은 실측에서 단순 개요 문서보다 못해 폐기했다. 폐기 결정 자체가 카드로 남아 같은 시도를 반복하지 않는다.

4. 결과 — 어디에 팔리는 역량인가

  • 기업 지식관리(KM)/사내 위키 구축: “문서는 많은데 찾을 수 없다”는 모든 조직의 문제에 대한 실증 답안 — 자동 컴파일 + 하이브리드 검색 + 린트 상시 감시.
  • 연구실·팀 단위 지식 축적: 구성원이 바뀌어도 결정·사고·노하우가 그래프로 남는 구조. 교육과 묶어 이식 가능.
  • RAG 도입 컨설팅: “임베딩 검색 붙이기”가 아니라 코퍼스 품질(정규화·정본화·프로비넌스)이 검색 상한을 결정한다는 것을 자체 실험으로 검증한 경험 — 미니 RAG 실증에서 “코퍼스에 없는 답은 그럴듯한 오답이 된다”를 확인하고 교정 루프 필요성을 도출했다.

방법론 박스 — 재사용되는 원칙

  1. 위키는 빌드 산출물. 사람이 쓰는 문서고는 반드시 부패한다 — 컴파일러와 린트가 유지하는 구조로 만든다.
  2. 라우터, 카탈로그 아님. 지식 계층은 답을 복제하지 않고 정본(SSOT)으로 안내한다.
  3. 증거 게이트. 자동 생성된 관계·요약은 원문 증거가 확인될 때만 채택한다.
  4. 실패도 카드다. 폐기한 설계를 기록하는 것이 같은 실험의 반복을 막는 가장 싼 방법이다.