쌓인 노트를 지식으로 — LLM Wiki와 Graphify

구체적으로 말하면, 매일 새로운 캡처가 Self/Raw/와 External/Raw/에 쌓이는데, 이 노트들 간의 관계를 추출하고 연결하는 작업을 사람이 수동으로 하는 건 비현실적이었어요. 옵시디언의 [[링크]]를 직접 걸어주는 것도 한 방법이지만, 그건 결국 노트를 쓸 때마다 기존 노트를 기억하고 있어야 가능한 거잖아요.

필요한 건 두 가지였어요:

1. 노트 사이의 관계를 자동으로 추출하는 것
2. 추출한 관계를 기반으로 읽을 수 있는 형태의 위키를 만들어주는 것

Karpathy의 LLM Wiki 패턴을 리서치하면서 핵심으로 뽑은 세 가지가 있어요.

소유권의 비대칭 분리 (3-Tier Model)

이 “교차 구조”가 핵심이에요. Raw는 사람이 쓰고 LLM이 읽고, Wiki는 LLM이 쓰고 사람이 읽어요. 이렇게 하면 원본이 오염되지 않아요. LLM이 Raw를 수정하는 일은 절대 없으니까요.

셀포지에서는 vault-note-guard.sh 훅으로 이 불변성을 강제하고 있어요. 에이전트가 Raw 파일을 수정하려고 하면 차단돼요.

Write-heavy, Read-cheap

비용 구조가 RAG와 정반대예요:

• RAG: 질문할 때마다 벡터 검색 + 조각 조합 (읽기가 비쌈)
• LLM Wiki: 노트를 수집할 때 위키를 갱신 (쓰기가 비쌈, 읽기는 저렴)

한 번 컴파일해두면 질문할 때는 이미 정리된 위키를 읽기만 하면 돼요. 이 구조 덕분에 자주 질문하는 것에 대한 부담이 줄어들어요.

Fan-out Ingest

소스 하나가 추가되면 10~15개 위키 페이지가 영향을 받아요. 요약 페이지, 개념 페이지, 비교 분석 등이 동시에 갱신되는 구조예요. 이걸 셀포지에서는 wiki-schema.md의 Ingest 프로토콜 9단계로 구현했어요.

구체적인 실험 조건을 볼게요. Sullivan 볼트의 37개 마크다운 파일에 “AI Native 근육이 왜 에이전트 설계, 콘텐츠 품질, 채용 패러다임 3개 영역을 관통하는가?”라는 질문을 던졌어요.

Method A (Raw 읽기): 37개 파일을 전부 LLM 컨텍스트에 넣고 답변 생성. Method B (Graphify 쿼리): graph.json에서 관련 노드를 BFS(depth 3)로 탐색, 81개 노드 중 40개 관련 노드 + 44개 엣지만 추출.

결과:

중요한 포인트는, Graphify 쿼리의 토큰은 코퍼스 전체 크기가 아니라 질문과 관련된 노드 수에 비례한다는 거예요. 그래서 코퍼스가 10배로 커져도 쿼리 비용은 거의 일정해요.

근데 솔직히, 37개 파일 규모에서 4.8배 절감은 “반드시 필요한” 수준은 아니에요. 10,913 토큰이면 Claude가 충분히 한 번에 읽을 수 있는 양이거든요. Graphify의 진짜 가치는 토큰 절감보다 다른 데 있었어요:

1. 관계의 사전 추출: Raw를 읽으면 LLM이 매번 “이 파일과 저 파일이 어떻게 관련있지?”를 처음부터 추론해야 해요. Graphify는 관계 타입(references, conceptually_related_to, semantically_similar_to)과 신뢰도(EXTRACTED/INFERRED)가 이미 태깅되어 있어요.

2. 반복 쿼리 비용: 같은 노트에 다른 질문을 5번 하면, Raw는 매번 전체 읽기로 ~55,000 토큰. Graphify는 쿼리만 바뀌니까 ~11,000 토큰.

3. 스케일 대응: 노트가 500개를 넘으면 Raw 전체 읽기는 컨텍스트 윈도우를 초과해서 물리적으로 불가능해져요.

Graphify의 파이프라인은 2-pass 구조예요:

Pass 1 — 구조 추출 (결정론적, LLM 불필요) 코드 파일이 있으면 tree-sitter AST로 구조를 정확히 추출해요. import, 함수 호출 같은 관계는 파싱으로 100% 정확하게 뽑을 수 있으니까 LLM을 쓸 이유가 없어요.

Pass 2 — 의미 추출 (LLM 병렬) 마크다운, PDF, 이미지 같은 비정형 파일에서 개념과 관계를 추출해요. Claude 서브에이전트가 파일 묶음별로 병렬 실행돼요.

이 분리가 핵심 설계 판단이에요. 확실한 건 결정론으로, 불확실한 것만 LLM으로. 비용 효율과 신뢰도를 동시에 잡는 구조예요.

관계 신뢰도 분류

모든 엣지에 신뢰도가 태깅돼요:

EXTRACTED (confidence_score: 1.0)
  → 소스에서 직접 발견. import문, 인용, 명시적 참조.

INFERRED (confidence_score: 0.4~0.9)
  → LLM이 추론. 공유 데이터 구조, 간접 의존성.
  → 각 엣지마다 개별 점수. 0.5를 기본값으로 쓰지 않아요.

AMBIGUOUS (confidence_score: 0.1~0.3)
  → 불확실. 검토 필요 플래그.

클러스터링

Leiden 커뮤니티 감지로 관련 노드를 묶어요. 임베딩이 아니라 그래프 토폴로지 기반이에요. 노드 간 연결 밀도만으로 클러스터를 찾는 거예요. 벡터 DB 없이 순수하게 연결 구조만으로 “이 개념들이 한 덩어리”라는 걸 파악해요.

산출물

SHA256 캐시를 쓰기 때문에 한번 추출한 파일은 변경되지 않는 한 재처리하지 않아요. --update 플래그로 변경분만 증분 처리하고요.

디렉토리 구조

{VAULT}/
├── Raw/                    # 사람이 쓴다 (불변)
├── wiki/                   # Wiki Agent가 쓴다
│   ├── index.md            # 네비게이션 허브
│   ├── log.md              # append-only 감사 추적
│   ├── signals.md          # 콘텐츠 신호 리포트
│   ├── .last_graph_snapshot.json
│   └── articles/
│       └── {page-name}.md  # Wikipedia 스타일 페이지
└── graphify-out/           # Graphify 산출물
    ├── graph.json           # 관계 데이터 (기계용)
    ├── GRAPH_REPORT.md      # 분석 리포트 (사람용)
    └── cache/               # SHA256 추출 캐시

자정 크론의 흐름

매일 00:00에 sullivan-graphify 크론이 실행돼요:

1. Vault A 그래프 업데이트: /graphify {VAULT}/Self/Raw --update --no-viz
2. Vault B 그래프 업데이트: /graphify {VAULT}/External/Raw --update --no-viz
3. graph.json 변경 감지: SHA256 해시를 이전 실행 값과 비교
4. 변경된 Vault만 Wiki Agent 실행: .wiki_enabled 게이트 확인 후, 해당 Wiki Agent에 Ingest 프로토콜 수행 요청

변경 감지가 핵심이에요. 둘 다 변경 없으면 Wiki Agent를 아예 호출하지 않아요. 불필요한 토큰 소모를 막는 short-circuit 구조예요.

Graphify 스코핑이 Wiki Agent에 주는 이점

Wiki Agent가 전체 Raw를 다시 읽지 않아도 되는 이유가 여기에 있어요:

graph.json에서 changed_nodes 감지
  → 영향받은 커뮤니티 멤버 ID 계산
  → 해당 멤버의 source_file만 Read
  → affected_articles만 재작성

볼트가 30개 파일 이상이면 이 스코핑이 필수예요. wiki-schema.md에도 명시되어 있어요:

볼트 ≥ 30 파일: 반드시 스코프 내로 제한

Graphify와 Wiki Agent의 역할 분리

Graphify가 뼈대를 세우고, Wiki Agent가 살을 붙이는 거예요. 이 분리 덕분에 각자 잘하는 일에 집중할 수 있어요.