관계를 읽을 수 있는 위키로 — Wiki Agent

이전 편의 Graphify가 산출하는 graph.json은 노드(개념/엔티티), 엣지(관계), 하이퍼엣지(다대다 관계)로 구성된 그래프 데이터예요. Leiden 클러스터링으로 커뮤니티를 분류하고, 각 관계에 EXTRACTED(원문 근거 있음) / INFERRED(추론) / AMBIGUOUS(불명확) 신뢰도 태그를 붙여요.

이 데이터의 한계는 명확해요:

• 구조만 있고 맥락이 없어요 — “A와 B가 연결돼 있다”는 알지만 “왜 연결돼 있는지”는 모름
• 원문 접근이 필요해요 — 실제 내용을 확인하려면 Raw 노트를 다시 열어봐야 함
• 탐색이 어려워요 — 특정 개념의 배경, 관련 개념, 맥락을 한눈에 볼 수 없음

wiki-schema.md에서 이 관계를 이렇게 정의하고 있어요:

Graphify가 뼈대를 만들면, Wiki Agent가 Raw 노트와 그래프 데이터를 함께 읽고 사람이 탐색할 수 있는 서술 위키로 변환하는 구조예요.

Wiki Agent의 article 포맷은 Wikipedia 패턴을 엄격하게 따라요:

# {개념/엔티티/주제 이름}

> {1~3문장 정의. 이 항목이 무엇인지 즉시 이해되게.}

## 배경
{역사적·문제적·문맥적 배경}

## {주제별 섹션 2~5개}
{구조, 특징, 비교, 적용, 원칙 등 — 주제에 따라 자유 구성}

## 관련 항목
- [[Graphify]] — {관계 한 줄 서술}
- [[RAG]] — {관계 한 줄 서술}

## 원전
- Self/Raw/2026-04-06_agent-design.md

파일 단위 규칙은 “1 article = 1 concept”이에요. 하나의 노드 또는 강한 응집 커뮤니티 하나가 하나의 문서가 돼요. Raw 노트 하나가 추가되면 보통 2~5개의 article이 새로 생기거나 갱신돼요(Fan-out).

frontmatter에는 그래프 메타데이터(커뮤니티 ID, God Node 여부, 신뢰도 통계)를 넣지만, 본문에는 절대 안 넣어요. 이건 이전에 실패했던 경험에서 나온 규칙이에요. (6 connections), cohesion: 0.40 같은 그래프 통계가 본문에 들어가면 사람이 읽는 위키가 아니라 기계 리포트가 돼버려요.

본문에서 금지하는 것:

• 그래프 통계 서술 (N connections, cohesion 수치)
• Raw 본문 그대로 반복
• 한영 혼용
• 원문에 없는 개념 확장이나 가치 판단

허용하는 것:

• [[...]] cross-reference (필수 — 최소 1개)
• Raw에 없는 맥락 서술 (배경, 역사, 관련 개념의 관계)
• 짧은 원문 인용 (1~2문장)
• INFERRED 관계의 완화 표현 (“~로 연결될 수 있다”)

두 Wiki Agent는 동일한 스키마(wiki-schema.md)를 따르지만, 서술 방식과 특화 기능이 달라요.

Wiki Agent A — 정체성 위키

경로 구조:

Self/
├── Raw/           # 내가 쓴 노트 (캡처, 회고, 작업 기록)
├── wiki/          # Wiki Agent A가 쓴다
│   ├── articles/  # Wikipedia 스타일 페이지
│   ├── index.md   # 네비게이션 허브
│   ├── signals.md # 콘텐츠 신호 리포트
│   └── gaps.md    # 갭 리포트
└── graphify-out/  # Graphify 산출물
    └── graph.json # 관계 데이터

Vault A만의 특화 기능:

• 반복 주제 프레이밍: God Node(많은 연결을 가진 중심 개념)가 있으면 “이 주제가 반복적으로 돌아온다”는 사실을 기술해요. 해석은 하지 않아요.
• 관점 진화 섹션: 이전 스냅샷 대비 변화가 있으면 ## 관점 진화 섹션을 추가해요. “최근 연결된 개념”, “약해진 연결”을 보여줘요.
• 긴장 표시: 한 군집 안에 상반된 개념이 공존하면 본문에 긴장 표시만 해요. 해석은 안 해요.

서술 규칙:

• 허용: 패턴 기술, 관계 기술, 변화 기술
• 금지: “당신은 이런 사람입니다” (규정), “이 패턴은 X를 의미합니다” (해석), “좋은/나쁜 패턴” (가치 평가)

Wiki Agent B — 지식 위키

경로 구조는 동일하되 External/ 아래에 위치해요.

Vault B만의 특화 기능:

• 개념 정의 중심: 각 article이 “이 개념은 무엇인가”를 원문 근거로 정의해요
• 비교 섹션: 같은 군집에 여러 개념이 있으면 공통점과 차이점을 정리해요
• Surprising Connection 확장: 예상 밖의 연결이 발견되면 구조적 근거를 서술하되, 추측은 금지. “~로 연결될 수 있다”는 완화 표현을 써요

서술 규칙:

• EXTRACTED 관계(원문 근거 있음)는 단정적 기술
• INFERRED 관계(추론)는 완화 표현 사용
• 가치 판단, 의도 추측, 원문에 없는 개념 확장 금지

Ingest 프로토콜은 9단계로 구성돼 있어요. 핵심은 Graphify의 스코핑 효과를 활용해서 읽기 비용을 줄이는 것이에요.

Step 0. Graphify 완료 상태 확인
Step 1. 변경 감지 — graph.json vs .last_graph_snapshot.json Diff
Step 2. 영향 범위 산정 — 변경된 노드 + 같은 커뮤니티 멤버
Step 3. Raw 스코프 재독 — 영향받는 파일만
Step 4. Article Fan-out 재작성 — 체크리스트 검증 후 저장
Step 5. index.md 재생성
Step 6. signals.md 재계산
Step 7. log.md append
Step 8. 스냅샷 저장
Step 9. 숙성/페르소나 시그널 알림

Step 2의 영향 범위 산정이 핵심이에요:

affected_articles = {}
for node in changed_nodes:
    affected_articles.add(node_to_article(node))
    for community in node.communities:
        for member in community.members:
            affected_articles.add(member_to_article(member))

변경된 노드뿐 아니라 같은 커뮤니티에 속한 멤버까지 포함해요. 한 개념이 바뀌면 관련 개념의 서술에도 영향을 줄 수 있으니까요. 그리고 affected_raw_files 크기에 따라 전략이 달라져요:

• 볼트가 10개 미만이면 → 전체 Raw를 읽어도 OK (스코핑 이득이 작아요)
• 볼트가 30개 이상이면 → 반드시 스코프 내로 제한

자정 크론(sullivan-graphify)의 실행 흐름을 보면 이 최적화가 더 잘 보여요:

1. Graphify가 --update 플래그로 변경분만 추출
2. graph.json의 SHA256 해시를 이전 값과 비교
3. 해시가 같으면(변경 없으면) Wiki Agent 호출 자체를 스킵
4. 해시가 다르면 + .wiki_enabled 파일이 있으면 → Wiki Agent 실행

이 게이팅 구조 덕분에 “변경 없는 날에는 아무것도 안 하고, 변경이 있는 날에만 영향받는 부분만 처리”하는 효율적인 파이프라인이 돼요.

Step 4에서 article을 재작성한 뒤에는 반드시 체크리스트를 돌려요:

• 그래프 통계가 본문에 없는지
• Raw 본문을 그대로 복사하지 않았는지
• cross-reference가 최소 1개 있는지
• 원전 링크가 있는지
• 깨진 문자가 없는지

체크리스트 실패 시 자가 수정 1회. 그래도 실패하면 그 article은 저장을 포기하고 log.md에 에러를 기록해요. 품질이 안 되면 차라리 안 쓰는 게 나으니까요.

signals.md는 매 Ingest 후 자동으로 재계산되는 부속 리포트예요. 콘텐츠 파이프라인(Content Strategy 에이전트)이 읽는 정형 인터페이스 역할을 해요.

---
type: wiki-signals
vault: A | B
generated: YYYY-MM-DD HH:MM
---

# 콘텐츠 신호

## God Node 변화
- [[개념]]: N edges → M edges (변화량)

## 숙성 시그널 (글 쓸 시점)
- [[article]] — 멤버 N개 도달
- [[God Node]] — 엣지 N개 돌파

## Surprising Connection (confidence 0.7 이상)
- [[A]] ↔ [[B]] — {간단 해석 제안}

## 최근 관점 진화 (Vault A 전용)
- {커뮤니티}에 {새 개념} 합류 → 반복 주제 변화 감지

Vault A와 B에서 숙성 시그널을 판단하는 기준이 달라요:

Vault B (지식 위키)의 숙성 판단:

• 특정 군집의 멤버가 5개 이상 모이면 → “이 주제로 글을 쓸 수 있을 만큼 자료가 모였다”
• 중심 개념(God Node)의 연결이 8개 이상이면 → “이 주제에 충분한 깊이가 생겼다”
• 예상 밖 연결(Surprising Connection)의 신뢰도가 0.8 이상이면 → “독자에게 놀라움을 줄 수 있는 소재”

Vault A (정체성 위키)의 변화 감지:

• 중심 개념의 순위가 바뀌면 → “반복적으로 생각하는 주제가 달라졌다”
• 새로운 군집이 등장하면 → “새로운 관심 영역”
• 기존 중심 개념에 연결된 노드가 3개 이상 바뀌면 → “관점이 진화하고 있다”

이 시그널들이 자산화 레이어의 입력이 돼요. Wiki Agent A는 “각도”(어떤 관점으로 쓸지)를, Wiki Agent B는 “소재”(무슨 내용을 쓸지)를 제공해요.

알림은 Ingest 프로토콜의 마지막 단계(Step 9)에서 발생해요. 두 에이전트의 알림 채널은 모두 Sullivan 채널(telegram-sullivan)이에요.

알림 작성 규칙:

• God Node, community, edge, cohesion, ingest, affected_articles 같은 시스템 용어 절대 노출 금지
• 패턴명은 사용자가 쓴 표현이나 원문 그대로 사용
• 구조: “왜 보냈는지 → 뭘 알면 좋은지 → 뭘 할 수 있는지” 순서 필수

Wiki Agent A의 알림에는 “승인/기각/수정” 3단 선택지가 자연어로 포함돼요. 페르소나 파일을 직접 수정하지 않고, 제안만 하고 흐민이 승인해야 반영되는 구조예요. 이 역시 “AI는 해석하지 않는다, 드러낸다”는 원칙의 연장선이에요.

wiki-schema.md에서 이 문제를 “article 두께 자동 조절”이라고 정의해요:

• Raw가 이미 잘 정리된 문서: article은 얇게 나와요 (정의 + 관련 항목 + 원전). 허브 역할.
• Raw가 파편적·원재료적 (즉석 캡처, 발췌, 대화 로그): article이 종합 역할을 해서 두꺼워져요.

스키마는 동일하지만 두께가 자연스럽게 달라지는 거예요. “얇음을 문제 삼지 말 것”이 명시된 규칙이에요.

현재 구현 상태와 검증 계획:

1. 크론 등록은 돼 있지만 실행은 보류 중 — .wiki_enabled 게이트 스위치가 없으면 Wiki Agent가 호출돼도 로그만 남기고 종료해요
2. 수동 트리거는 허용 — “Vault A 재컴파일”이라고 직접 요청하면 실행돼요
3. 검증 기준: (a) Raw 대비 article 가독성이 높은지 (b) 다른 Raw와의 맥락이 드러나는지 (c) Raw 반복 서술이 없는지
4. 첫 실증 조건: 원재료성 Raw 1건(트윗 캡처, 논문 발췌, 대화 로그)이 들어왔을 때 수동 ingest → 결과 확인