팀 LLM Wiki와 graphify로 정규화하는 AX 전환: 개인 지식 베이스 패턴을 챕터 자산으로

카파시의 LLM Wiki gist를 받아 읽고 정신이 들었다. "지식 베이스 유지에서 지루한 부분은 읽기나 생각이 아니라 bookkeeping이다." 이 한 문장이 챕터 AX 전환에서 가장 자주 놓치는 자리를 정확히 짚는다. 도구는 있다. 그러나 팀이 그 도구로 만든 산출물을 시간이 지나도 일관되게 유지할 운영 골격이 비어 있다.

지난 글(백엔드 챕터의 AI Native 전환 설계)에서 4단계 성숙도와 4축(측정·학습·표준화·자산화)을 정리했다. 그 위에 빠져 있던 한 가지가 있다. "챕터원들이 같은 도구를 같은 컨텍스트로 호출하게 하는 substrate를 무엇으로 만들 것인가." 이 질문에 카파시의 LLM Wiki gist와 graphify가 정확히 맞는다. 이 글은 개인용으로 설계된 LLM Wiki 패턴을 팀 단위로 정규화하기 위한 챕터 운영 노트다.

1. 출발: 카파시 gist가 진짜로 말하는 것

카파시의 llm-wiki.md gist는 "A pattern for building personal knowledge bases using LLMs." 한 줄로 시작한다. 흥미로운 건 이 gist가 도구 추천 글이 아니라는 점이다. 본인이 직접 "이건 idea 파일이고, 너의 LLM agent에 그대로 복붙해서 너에게 맞게 instantiate하라"고 명시한다. 즉 gist 자체가 schema의 reference 구현이다.

핵심 문장 셋만 원문으로 옮긴다.

"Instead of just retrieving from raw documents at query time, the LLM incrementally builds and maintains a persistent wiki." "You never (or rarely) write the wiki yourself — the LLM writes and maintains all of it." "The tedious part of maintaining a knowledge base is not the reading or the thinking — it's the bookkeeping."

이 셋이 합쳐지면 분업이 명확해진다. 사람은 큐레이션과 좋은 질문을, LLM은 위키 유지의 지루한 부분 전부를 맡는다. RAG와 다른 점이 여기다. RAG는 query마다 다시 검색하지만, LLM Wiki는 점진적으로 누적된 위키를 LLM이 계속 정돈한다. 시간이 지날수록 컨텍스트가 두꺼워진다는 뜻이고, 챕터 입장에서는 자산이 누적된다는 뜻이다.

카파시 본인의 운영 풍경은 한 줄이다.

"In practice, I have the LLM agent open on one side and Obsidian open on the other."

이 한 줄이 개인 도입의 출발선이지만, 팀에 옮기면 한 명의 사이드바 두 개로는 부족해진다. 무엇이 더 필요한지가 이 글의 본론이다.

2. 3계층 아키텍처와 3대 운영

gist의 골격은 깔끔하다. 한 장으로 정리한다.

LLM Wiki의 3계층과 3대 운영

3계층 (원문 그대로)

Raw sources: "immutable original documents that the LLM reads but never modifies." 원본은 절대 수정하지 않는다.
The wiki: "LLM-generated markdown files — Summaries, entity pages, concept pages, comparisons, an overview, a synthesis." 위키는 LLM이 만든 결과물.
The schema: CLAUDE.md 또는 AGENTS.md. "the key configuration file — it's what makes the LLM a disciplined wiki maintainer rather than a generic chatbot."

세 번째 문장이 핵심이다. schema가 없으면 LLM은 generic chatbot이고, schema가 있으면 disciplined wiki maintainer다. 팀 단위 도입에서 무엇을 가장 먼저 만들어야 하는지가 여기서 답이 나온다. 도구가 아니라 schema다.

3대 운영 (원문 그대로)

Ingest: "the LLM reads the source, discusses key takeaways with you, writes a summary page in the wiki, updates the index, updates relevant entity and concept pages across the wiki, and appends an entry to the log."
Query: "the LLM searches for relevant pages, reads them, and synthesizes an answer with citations." 좋은 답은 다시 wiki에 file back.
Lint: 정기 점검. "contradictions between pages, stale claims that newer sources have superseded, orphan pages with no inbound links."

두 가지 분리도 핵심이다. index.md는 content-oriented 카탈로그(페이지 한 줄 요약), log.md는 append-only 시간순 기록(무엇을 언제 했는가). 둘이 같으면 둘 다 못 한다.

3. 개인용에서 팀용으로 옮길 때 바뀌는 세 가지

gist는 의도적으로 personal하게 적혀 있다. 팀에 옮기면 세 가지가 바뀐다.

schema의 author가 한 명에서 팀으로 늘어난다. schema(CLAUDE.md)가 흔들리면 wiki가 흔들린다. 팀에서는 schema 자체가 MR 기반 변경 대상이고 책임자가 1명 지정되어야 한다.
raw/는 사람마다 누적되지 않고 공유되어야 한다. 개인은 자기 인박스만 관리하면 되지만, 팀은 누가 raw/에 무엇을 언제 넣었는지 추적이 가능해야 한다. git이 raw/의 원장 역할을 한다.
lint가 개인 의지에서 빌드 결과로 바뀐다. 카파시는 "주기적으로 직접 lint를 실행한다"고 적었다. 팀은 그게 의지로 안 된다. lint는 CI에 박혀 있어야 사람이 wiki를 버리지 못한다.

이 셋이 합쳐지면 결론은 한 줄이다. 개인 wiki는 "Obsidian + LLM agent" 한 쌍으로 충분하지만, 팀 wiki는 "git + schema MR + CI lint"라는 운영 골격이 추가로 필요하다. 이 추가분이 정확히 graphify가 채워 줄 자리다.

4. graphify가 이 패턴에 정확히 맞는 이유

graphify README는 카파시 패턴과 같은 어휘를 쓴다. 본문 안에서 "Andrej Karpathy keeps a /raw folder"를 동기 부여로 인용하고, 그 위에 그래프 레이어를 얹는다.

"Type /graphify in your AI coding assistant and it maps your entire project — code, docs, PDFs, images, videos — into a knowledge graph you can query instead of grepping through files."

본질은 시각화가 아니라 knowledge graph를 agent가 grep 대신 쓸 수 있는 컨텍스트 substrate다. LLM Wiki가 markdown 문서 레이어라면, graphify는 그 위에 자동으로 얹히는 그래프 레이어다. 같은 raw/에서 둘 다 파생된다.

graphify와 LLM Wiki의 결합 지점

LLM Wiki 패턴에 정확히 맞물리는 graphify의 자산 네 가지를 정리한다.

① god nodes: 어떤 entity 페이지를 먼저 두텁게 만들지 정량 신호. graphify는 README 표현으로 "highest-degree concepts (what everything connects through)"을 자동 식별해 GRAPH_REPORT.md에 적어 둔다. LLM Wiki에서 entity 페이지의 우선순위는 보통 사람의 직관에 의존하는데, god nodes 리스트가 그 직관을 객관적 신호로 대체한다.

② confidence 태그: frontmatter confidence 필드와 직결. graphify는 모든 edge에 EXTRACTED / INFERRED / AMBIGUOUS를 태깅한다. LLM Wiki 커뮤니티 가이드의 표준 frontmatter는 confidence: high | medium | low다. EXTRACTED → high, INFERRED → medium, AMBIGUOUS → low 로 일대일 매핑하면 위키 페이지 신뢰도가 그래프 차원에서 검증된다.

③ raw/ immutable: SHA256 cache로 검증 가능. 카파시의 immutable raw 원칙은 graphify cache(SHA256 기반)와 그대로 호환된다. raw/ 파일이 한 번 들어오면 hash가 바뀌지 않는다는 규약을 pre-commit hook으로 강제하면, graphify는 그 hash로 cache invalidation을 자동 수행한다.

④ MCP 서버: query_graph / get_node / get_neighbors / shortest_path. python -m graphify.serve graphify-out/graph.json으로 띄우면 Claude Code · Codex · Cursor · Aider가 같은 그래프를 컨텍스트로 받아 쓴다. LLM Wiki의 wiki/ 디렉토리도 agent-crawlable markdown이라 같은 query plane에 동시 마운트 가능. 구조적 쿼리(graphify)와 의미적 쿼리(wiki)가 한 세션에서 만난다.

5. 정규화의 다섯 가지 결합점

네 가지 자산을 팀 운영으로 옮길 때 만드는 결합점 다섯이다.

① schema 안에 graphify를 강제로 끼워 둔다. CLAUDE.md 첫 섹션에 한 줄을 박는다: "Before answering, query graphify MCP for relevant nodes and check confidence tags." 이게 없으면 agent는 graphify를 안 쓴다. schema가 도구 사용 규약의 단일 source of truth다.

② Ingest skill이 graphify 재빌드까지 한 호흡에. raw/에 새 파일이 들어오면 ingest skill이 ⓐ summary 페이지 작성 ⓑ index.md·log.md 갱신 ⓒ graphify --update로 그래프 재빌드까지 한 번에 처리. 빌드가 길면 chunked로 분리하되, ingest가 끝났을 때 그래프도 갱신되어 있어야 한다.

③ frontmatter 스키마에 graphify 메타데이터를 흡수. 팀 표준 frontmatter:

---
title: Page Title
type: concept | entity | source-summary | comparison
sources:
  - raw/papers/filename.md
related:
  - "[[related-concept]]"
confidence: high | medium | low      # graphify edge 태그에서 자동 채움
god_node_rank: 12                    # GRAPH_REPORT.md god nodes 순위
graphify_node_id: "DigestAuth"       # MCP 호출용 노드 키
created: YYYY-MM-DD
updated: YYYY-MM-DD
---

세 필드(confidence, god_node_rank, graphify_node_id)가 사람과 graphify 양쪽이 같은 페이지를 같은 식별자로 부르게 만드는 핵심 접점이다.

④ Lint를 CI nightly로. 카파시가 정의한 세 가지 lint 룰을 그대로 CI 잡으로 옮기고, graphify가 있어야만 검출 가능한 두 가지를 더 얹는다.

# .gitlab-ci.yml (발췌)
wiki-lint:
  stage: lint
  script:
    - graphify ./raw --update
    - python tools/wiki-lint.py \
        --rule contradictions \
        --rule stale-claims \
        --rule orphan-pages \
        --rule confidence-downgrade \
        --rule dangling-wikilink
    - python tools/wiki-lint.py --report mr-comment
  rules:
    - if: '$CI_PIPELINE_SOURCE == "schedule"'

confidence-downgrade(이전 EXTRACTED였다가 INFERRED로 떨어진 edge)와 dangling-wikilink는 graphify 없이는 검출 불가능한 룰이다. 두 자료를 합쳐야 비로소 lint가 두꺼워진다.

⑤ raw/는 pre-commit hook으로 append-only 강제.

# .git/hooks/pre-commit (발췌)
if git diff --cached --name-status | grep -E '^[MD]\s+raw/'; then
  echo "raw/ is immutable. New files only."
  exit 1
fi

수정·삭제는 거절, 신규만 허용. 카파시의 "immutable original documents" 한 줄을 git이 강제하게 만드는 가장 짧은 코드다.

6. 도입 4단계 시나리오

이 부분은 아직 챕터 합의 전이고, 내 노트 수준으로 적어 둔다.

Stage 1: 개인 파일럿 (1~2주)

내가 먼저 한 명 분량의 LLM Wiki를 만든다. raw/, wiki/, CLAUDE.md를 한 모듈(마이데이터 중계 서버)에 띄우고, Obsidian으로 사람 측 뷰, Claude Code로 agent 측 뷰를 동시에 본다. graphify를 같은 디렉토리에 돌려 god nodes 리스트가 우리가 아는 위험 모듈과 일치하는지 baseline 10건 비교.

Stage 2: schema 표준화 (3~4주차)

내가 쓴 CLAUDE.md를 챕터 표준 후보로 격주 패턴 공유 세션에 안건으로 올린다. frontmatter 표준, page type 4종(concept / entity / source-summary / comparison), slash skill 표준 명령(/wiki-ingest, /wiki-query, /wiki-lint) 을 한 번에 합의한다. 이 단계가 합의되지 않으면 다음으로 못 간다.

Stage 3: MCP 결합 + 챕터 plugin (5~8주차)

graphify MCP와 wiki MCP를 챕터 plugin으로 묶어 배포한다. 챕터원 누구나 /wiki-query "..." 한 줄로 같은 substrate를 호출한다. 변경은 MR 기반, 책임자 1명, semver. plugin이 있어야 챕터원 환경 편차가 사라진다.

Stage 4: CI lint와 KPI (9~12주차)

위 §5④의 CI 잡을 nightly로 돌린다. 챕터 KPI 보고서에 네 컬럼을 추가한다.

AMBIGUOUS edge 비율
orphan 페이지 수
god node in-degree 변동
wiki 페이지 수의 주간 증가량

"활성 사용률"만 보면 도입은 흥하고 운영은 망한다. 속도 KPI와 안전 KPI를 같은 보고서에 묶는 것, 이게 지난 글 5번에서 짚었던 원칙의 연장이다.

7. 운영 거버넌스: 무엇을 어디까지 자동화할 것인가

LLM Wiki 패턴이 가진 가장 큰 위험은 자동화의 욕심이다. Ingest 자동화, Query 자동화, Lint 자동화까지는 좋다. 그러나 schema 변경과 raw/ 추가만은 사람이 검토한다. 둘을 자동화하면 위키 전체가 한 번에 망가질 수 있다.

자동화 OK: ingest의 summary 작성, index.md·log.md 갱신, graphify 재빌드, lint 잡, MR 봇 코멘트
자동화 금지: schema(CLAUDE.md) 변경, raw/ 추가, lint가 잡은 contradiction의 해결

가장 위험한 시나리오는 LLM이 자기 schema를 자기가 고치는 자기 강화 루프다. schema는 read-only로 agent에 노출하고, 변경은 사람이 MR로만, 이걸 첫날부터 박아 둔다.

8. 시니어 시선 인사이트

① bookkeeping이 진짜 일이라는 것

카파시 gist의 가장 짧은 한 줄이 가장 무겁다. "The tedious part of maintaining a knowledge base is not the reading or the thinking — it's the bookkeeping." 챕터 AX에서 우리가 자동화해야 할 1순위는 새로운 능력이 아니라 새로운 자료를 정돈하는 잡일이다. 멋진 agent demo보다 lint CI 한 번 돌리는 게 6개월 뒤 더 큰 자산을 남긴다.

② schema가 substrate의 진짜 뼈대다

도구·MCP·plugin은 갈아 끼울 수 있다. 그러나 CLAUDE.md 한 장이 무너지면 wiki 전체가 흔들린다. schema MR을 누가 review하고 어떤 검수 절차로 머지되는지가 챕터의 진짜 거버넌스 자리다. 도구 선택보다 schema 책임자 지정이 먼저다.

③ god nodes와 confidence는 KPI의 뼈대로 흡수한다

graphify의 god nodes 리스트와 AMBIGUOUS 비율은 챕터 안전 KPI를 만드는 데 가장 가치 있는 신호 둘이다. OKR에 god node in-degree 변동률과 AMBIGUOUS 비율 상한을 박지 않으면, graphify는 "처음에 신기했던 도구"로 잊힌다. 시각화는 PR 자료에 쓰고, 운영은 그래프 메타데이터로 한다.

④ 사람의 일을 줄이는 게 아니라 자리를 옮기는 패턴이다

LLM Wiki 패턴의 가치는 사람을 빼는 게 아니다. "읽고 쓰고 기억하는" 일에서 "큐레이션하고 좋은 질문하고 lint 결과를 판단하는" 일로 사람의 자리를 옮기는 것이다. 챕터 오너로서 이 자리 이동을 분명하게 전달하지 못하면 도입은 저항을 만난다. "여러분의 일이 없어지는 게 아니라, 더 결정적인 자리로 옮겨갑니다." 이 한 줄을 첫 사내 세션의 슬라이드 1번에 박아 둔다.

마무리: 한 문장으로 줄이면

카파시의 LLM Wiki는 패턴이고, graphify는 그 패턴을 팀에서 운영 가능하게 만드는 골격이다. 둘 사이에 schema MR과 CI lint가 있어야 챕터 자산으로 남는다.

다음 액션 아이템은 셋이다. 첫째, 마이데이터 중계 서버에 raw/wiki/CLAUDE.md 1주 파일럿: god nodes 리스트와 우리 직관이 일치하는지 baseline을 잡는다. 둘째, 챕터 격주 세션에 CLAUDE.md 표준 후보를 1순위 안건으로 올린다. 셋째, CI nightly lint 잡(wiki-lint) 초안을 한 모듈에 먼저 붙여 본다.

도구는 손에 있다. 패턴도 있다. 다음은 그 사이에 흐를 schema와 CI를 챕터 자산으로 누적시키는 일이다.