익은 지식이 콘텐츠가 되기까지 — 자산화 파이프라인

시리즈 1-4에서 다룬 데이터 흐름을 요약하면 이래요:

Raw(사람이 쓴다) → Graphify(관계 추출) → Wiki Agent(서술 위키) → Insight Agent(교차 탐색)

이 파이프라인은 지식을 구조화하는 것까지만 담당해요. 자산화 레이어는 여기서 한 단계 더 나가야 해요 — “이 지식이 콘텐츠로 변환될 준비가 됐는가?”를 판단하고, 실제로 변환하는 과정이에요.

AGENTS.md의 Layer 3 정의를 보면, 자산화 레이어에는 세 개의 콘텐츠 파이프라인(웹사이트, LinkedIn, 네이버 블로그)과 PM 에이전트(셀피)가 있어요. 그리고 이 모든 파이프라인의 입구에 signals.md라는 파일이 있어요. 이게 지식 레이어와 자산화 레이어를 연결하는 다리 역할을 해요.

전체 구조는 이렇게 돼요:

[지식 레이어]                    [자산화 레이어]
Wiki Agent → signals.md    →    셀피(검수) → 콘텐츠 파이프라인
             (숙성 시그널)        (5축 평가)    (웹사이트/LinkedIn/네이버)

signals.md는 Wiki Agent가 매 Ingest(위키 갱신) 후에 자동으로 재계산하는 부속 리포트예요. wiki-schema.md에 정의된 포맷은 이래요:

# 콘텐츠 신호

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

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

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

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

signals.md는 Vault A(내 사고)와 Vault B(외부 지식) 각각에 하나씩 존재해요. 역할이 달라요:

숙성 시그널의 트리거 조건은 wiki-agent-b.md에 정의돼 있어요:

• 특정 커뮤니티 멤버 5개 이상 도달
• 특정 God Node 엣지 8개 이상 도달
• Surprising Connection confidence 0.8 이상 새로 등장

조건을 충족하면 텔레그램 알림이 가는데, 여기서 중요한 규칙이 하나 있어요 — 시스템 용어를 절대 쓰지 않아요. “God Node 엣지 8개 돌파”가 아니라, “흐민이 최근 포착한 글들이 하나의 주제로 모이고 있어요”라고 보내요. 알림은 기술 보고가 아니라 편집자의 제안이에요.

자정 크론(sullivan-graphify)의 전체 흐름은 이래요:

Step 0. 크론 자가 점검 (누락된 크론 재등록)
Step 1. Graphify — Vault A (Self/Raw/) 그래프 업데이트
Step 2. Graphify — Vault B (External/Raw/) 그래프 업데이트
Step 2.5. graph.json 해시 비교 (short-circuit)
Step 3. .wiki_enabled 게이트 확인
Step 4. Wiki Agent A 실행 (Vault A 변경 시)
Step 5. Wiki Agent B 실행 (Vault B 변경 시)
Step 6. git sync

핵심 최적화는 Step 2.5의 해시 비교예요. 각 Vault의 graph.json SHA256 해시를 이전 실행 값과 비교해서, 변경이 없으면 Wiki Agent 호출 자체를 스킵해요:

CURRENT_HASH=$(shasum -a 256 "$GRAPH" | cut -d' ' -f1)
PREV_HASH=$(cat "$HASH_FILE" 2>/dev/null || echo "none")
echo "$CURRENT_HASH" > "$HASH_FILE"
[ "$CURRENT_HASH" = "$PREV_HASH" ] && CHANGED=false || CHANGED=true

네 가지 경우의 수가 있어요:

• 둘 다 변경 없음 → Wiki Agent 전체 스킵, 로그에 NO-CHANGE 기록
• Vault A만 변경 → Wiki Agent A만 실행
• Vault B만 변경 → Wiki Agent B만 실행
• 둘 다 변경 → 둘 다 실행

.wiki_enabled 게이팅은 각 Vault 독립적이에요. Vault A 위키만 끄고 Vault B 위키는 돌릴 수 있어요. 게이트에 막히면 로그에 GATED: .wiki_enabled 없음, ingest 보류를 남기고 조용히 넘어가요.

에러 대응도 계층적이에요:

• Graphify 실패 → 다음 날 자동 재시도, 별도 알림 없음
• Wiki Agent 체크리스트 실패 → 해당 article만 저장 포기, 나머지는 계속
• Wiki Agent 전체 실패 → Graphify 산출물은 유지, 위키만 다음 날 재시도

크론 자체도 자가 치유 구조예요. Step 0에서 6개 크론이 모두 등록돼 있는지 확인하고, 누락된 게 있으면 스케줄러 스킬을 읽어서 자동으로 재등록해요.

콘텐츠 시그널 검수는 selfy-콘텐츠시그널 크론으로 매주 토요일 09:00에 실행돼요. 흐름은 이래요:

1. 크론 점검 (셀피 크론 5개 확인)
2. signals.md 수집 (Vault A + Vault B)
3. site-editor evaluate 모드 호출
4. 검수 결과 텔레그램 전달
5. 흐민 응답 처리 (승인/수정/거절)

site-editor의 evaluate 모드는 5축 평가를 수행해요:

판정 기준:

• 적합: 4개 이상 충족 → 콘텐츠 후보
• 보류: 2-3개 충족 → 소스 축적 후 재평가
• 부적합: 1개 이하 → 제외

검수 결과는 이런 형식으로 텔레그램에 전달돼요:

[셀피] 이번 주 콘텐츠 시그널 검수 결과

━━ 적합 (콘텐츠 후보) ━━
1. {제목안} — {추천 유형}
   {왜 지금인가 한 줄}

━━ 보류 ━━
- {시그널}: {부족한 점}

━━ 편집자 코멘트 ━━
{site-editor 소견}

승인이 떨어지면 site-editor의 write 모드가 호출되고, 수정 요청이 오면 피드백을 반영해서 다시 write로 넘겨요. 거절이나 무응답이면 다음 주까지 보류해요. 어떤 경우에도 사람의 판단 없이 글쓰기가 시작되지 않아요.

세 파이프라인의 에이전트 구성을 정리하면 이래요:

웹사이트:

site-editor (discover → write → curate → evaluate)

site-editor는 단독 에이전트가 네 가지 모드로 동작해요. discover로 소스를 발굴하고, write로 아티클을 쓰고, curate로 기존 콘텐츠를 큐레이션하고, evaluate로 시그널을 검수해요.

LinkedIn:

@source-reader → [소스 브리프 확인] → @content-strategy
  → @linkedin-writer → @content-reviewer → @brand-voice → @qa-validator

소스 브리프 확인이 중요한 게이트예요. content-strategy가 실행되기 전에 오케스트레이터가 사람에게 소스 브리프를 보여주고 확인을 받아요. 핵심 소재가 뭔지, 어떤 각도로 쓸 건지를 사람이 먼저 동의해야 해요.

LinkedIn 파이프라인에는 obsidian 모드와 direct 모드가 있어요. obsidian 모드에서는 source-reader가 볼트에서 노트를 수집하고, direct 모드에서는 주제를 직접 입력해요. direct 모드에서 주제가 모호하면 content-strategy가 2-3개 방향을 제안하고, 사람이 선택한 뒤 진행해요.

네이버:

@naver/photo-analyzer → @naver/research-agent(조건부)
  → @naver/content-strategy → @naver/naver-writer
  → @naver/brand-voice → @naver/qa-validator

세 파이프라인의 공통 제약사항은 AGENTS.md에 명시돼 있어요:

자동 발행 절대 없음 — 결과물은 Markdown 파일로만 출력, 사람이 확인 후 수동 발행
Brand Voice 에이전트 필수 — 모든 최종 아웃풋은 Brand Voice를 통과해야 함

오케스트레이터(메인 Claude Code 세션)가 이 파이프라인을 조율해요. 서브에이전트는 다른 서브에이전트를 직접 호출할 수 없고, 오케스트레이터가 한 단계씩 넘겨줘요.

전체 시스템의 데이터 흐름을 정리하면 이래요:

[사고 레이어]
텔레그램 메시지 → capture-agent → Raw/ (Obsidian)
                                     ↓
[지식 레이어]                        ↓
sullivan-graphify 크론 (매일 00:00)   ↓
  ├─ Graphify → graph.json          ↓
  ├─ 해시 비교 (short-circuit)       ↓
  ├─ Wiki Agent A → Self/wiki/      ↓
  ├─ Wiki Agent B → External/wiki/  ↓
  └─ signals.md 갱신                 ↓
                                     ↓
[자산화 레이어]                      ↓
selfy-콘텐츠시그널 크론 (토 09:00)    ↓
  ├─ signals.md 수집                 ↓
  ├─ site-editor evaluate (5축 평가) ↓
  └─ 텔레그램 알림                   ↓
       ↓ (사람 승인)                 ↓
  콘텐츠 파이프라인                   ↓
  ├─ 웹사이트: site-editor write     ↓
  ├─ LinkedIn: source-reader → ... → qa-validator
  └─ 네이버: photo-analyzer → ... → qa-validator
       ↓                            ↓
  Markdown 파일 출력                 ↓
       ↓ (사람 확인 + 수동 발행)     ↓
  발행된 콘텐츠                      ↓
       ↓                            ↓
  새로운 생각 ─────────────────────→ 처음으로

이 루프에서 사람이 직접 관여하는 지점은 세 곳이에요:

1. 포착: 텔레그램으로 생각을 던지는 것
2. 시그널 승인: 토요일 검수 결과를 보고 진행 여부 결정
3. 발행 확인: 최종 결과물을 읽고 수동 발행

나머지는 전부 자동이에요. 자정 크론이 Graphify와 Wiki를 돌리고, 토요일 크론이 시그널을 검수하고, 파이프라인이 초안을 만들어요. 하지만 사람의 판단이 빠지는 지점은 없어요.

그리고 이 루프의 마지막 화살표 — “새로운 생각 → 처음으로” — 가 이 시리즈의 핵심이에요. 자산화는 끝이 아니라 다음 사고의 입력이에요. 글을 쓰면서 생긴 새로운 질문, 검수하면서 발견한 새로운 각도, 발행 후 받은 피드백 — 이 모든 게 다시 Raw가 되고, 다시 그래프가 되고, 다시 위키가 돼요.