PKM 볼트에 그물을 짜다 — 22기 1주차 강의로 시작된 2일 사이클

한 줄 요약: 지피터스 22기 1주차(Vault 구축) 강의를 따라가다가 내 볼트의 깨진 위키링크 22개를 발견했고, 이틀 동안 진단 → 복구 → 허브 3개 생성 → 템플릿화까지 한 호흡에 끝냈다.

정량 결과: 위키링크 사용률 6% → 10%, 6개 허브가 모두 외부 백링크 10+ 도달, hub-template.md 공식 자산 확보, 70-collected가 처음으로 지식 그래프에 진입.

1. 소개 — 무엇을 시도했고, 왜 했나

시작점: 강의 자료를 그대로 따라가지 않기로 했다

2026년 5월 25일 월요일 아침, 지피터스 22기 1주차 강의 자료(week1-slides.html, "Vault + Claude Code")를 받았다. 강의가 제시하는 6단계 — 폴더 구조, 마크다운 4가지, 프론트매터 8필드, 백링크 그래프, 인덱스 위키, 슬래시 커맨드 — 를 내 환경과 비교해보니 흥미로운 발견이 있었다.

강의의 표준을 그대로 따랐다면 미니멀 원칙(메모리 feedback_minimal-frontmatter.md)이 깨졌을 것이다. 표준은 출발점이지 종착점이 아니다. 그래서 옵션 B — 기존 환경에 매핑·보완 — 를 선택했다.

진짜 문제 발견

강의의 "백링크 그래프" 단계에서 내 볼트를 점검했다.

find . -name "*.md" -not -path "*/.git/*" | wc -l  # 974
grep -rl "\[\[" --include="*.md" . | wc -l         # 58 → 6%

974개 노트 중 위키링크 사용 파일은 단 58개(6%). 그나마도 CLAUDE.md의 "이동 이력"을 보니, 두 달 전 Johnny Decimal로 폴더 재구성을 하면서 폴더는 옮겼는데 그 폴더를 가리키는 위키링크는 옛 경로 그대로 22개가 방치돼 있었다. 5개 허브 노트(habits, philosophy, ai-automation 등) 대부분이 그래프에서 끊긴 고립 상태.

가설을 다시 세웠다: "강의를 따라가는 것보다, 내 볼트의 부채를 청소하고 운영 사이클을 정착시키는 것이 1주차의 진짜 학습이다. 4주차 MCP 시연에서 Claude가 vault를 자율 탐색하려면 그래프가 살아 있어야 한다."

2. 진행 방법 — 도구와 워크플로우

사용한 도구

• Claude Code (Sonnet 4.6 1M context) — 메인 작업 파트너

• zettelkasten-linker 에이전트 — 974개 노트 전수 진단 위임 (별도 context window)

• Obsidian — 위키링크·그래프 시각화

• bash sed/grep — 일괄 치환 + 무결성 검증

• Johnny Decimal 폴더 시스템 — 내 운영 컨벤션

• CLAUDE.md (글로벌+프로젝트) — 운영 원칙 영구 기록

전체 워크플로우 (이틀 8단계)

[Day 1 — 2026-05-25 (월)]
오전  ① 진단     → grep으로 깨진 링크 22개 식별 (5개 패턴)
      ② 복구     → sed 일괄 치환 + Daily Note 자동 연결 로직
점심  ③ baseline → 에이전트 위임 (974개 전수 스캔, 15분)
오후  ④ n=1 허브 → running-hub.md (12섹션, 723회 자산)
저녁  ⑤ n=2 허브 → gg-work-hub.md (13섹션, 경기도청 자산)

[Day 2 — 2026-05-26 (화)]
오전  ⑥ 액션 실행 → 진단 단계 1+2 (37개 링크, 90분)
오후  ⑦ 옵션 A 마무리 → 23개 추가, 100파일 도달
저녁  ⑧ n=3 템플릿화 → reading-hub.md (14섹션) + hub-template.md

Day 1 ① — 깨진 위키링크 5가지 패턴 식별

CLAUDE.md의 폴더 "이동 이력" 표를 보고 옛 경로 → 새 경로 매핑을 도출했다.

Day 1 ② — 일괄 치환 + Daily Note 자동 연결

# 13개 파일에 5개 패턴 일괄 치환
for f in "${files[@]}"; do
  sed -i '' \
    -e 's|\[\[30-knowledge/33-relationships/|\[\[30-knowledge/33-knowledge-hub/|g' \
    -e 's|\[\[30-knowledge/36-philosophy/|\[\[30-knowledge/34-learning/|g' \
    -e 's|\[\[30-knowledge/38-habits/|\[\[30-knowledge/33-knowledge-hub/|g' \
    -e 's|\[\[40-personal/45-notes/|\[\[40-personal/46-notes/|g' \
    -e 's|\[\[10-projects/14-relationship-management/|\[\[20-operations/23-networking/relationship-management/|g' \
    "$f"
done

# 검증
grep -rl "\[\[30-knowledge/33-relationships" --include="*.md" .  # 0개 OK

결과: 13개 파일, 23 insertions / 23 deletions, 새 경로 7개 모두 실존 확인.

동시에 .claude/commands/daily-note.md에 Daily Note 자동 위키링크 채움 로직을 추가했다.

# 어제 (YY-MM-DD(요일) 형식)
YESTERDAY_DATE=$(date -v-1d +"%y-%m-%d")
YESTERDAY_DAY=$(LC_TIME=ko_KR.UTF-8 date -v-1d +"%a" | sed 's/요일//')

# 이번 주 일요일 (YYMMDD-WXX 형식)
DOW=$(date +%w)
SUNDAY_OFFSET=$(( (7 - DOW) % 7 ))
SUNDAY=$(date -v+${SUNDAY_OFFSET}d +"%y%m%d")
WEEK_NUM=$(date -v+${SUNDAY_OFFSET}d +"%V")

인라인 템플릿에 자동 채움 섹션:

## 🔗 관련 노트
- 어제: [[26-05-24(일)]]
- 이번 주: [[260531-W22]]

5분 투자 × 365일 = 30시간 절약 — 자동화는 한 번 만들면 매일 작동한다.

Day 1 ③ — 에이전트 위임 baseline 진단

zettelkasten-linker 스킬을 직접 실행하지 않고 에이전트에 위임했다. 이유:

1. vault 전체 스캔은 토큰 소비가 크고 main context 오염 가능성

2. 에이전트는 독립 context window에서 작업 후 요약만 반환

3. 974개 파일 raw output이 main에 쏟아지지 않음

위임 프롬프트의 핵심 5가지:

1. 배경(오전 복구 회고 경로 명시)

2. 폴더 구조(Johnny Decimal) + 분석 제외 영역

3. 우선순위: 허브 검증(최우선) → 40-personal → 70-collected → running

4. 제약: 미니멀 프론트매터, 노트 수정 금지, Strong connection만

5. 출력 형식: Executive Summary + 4 Phases + 품질 이슈 + 다음 단계

15분 대기 — 의심과 확인이 있었다. "왜 이렇게 오래 걸리지?" 사용자가 작업 중단 → 재개 지시. 사후 분석 결과:

• 974개 파일 전수 grep 스캔

• 6개 허브 각각 백링크 역추적

• Strong connection 판단 위해 후보 노트 본문 읽기

• 보고서 272줄 작성

→ 다음번 위임 시 예상 소요 시간 사전 명시 ("974개 파일 스캔으로 약 15분 소요 예상") — 신뢰의 핵심.

검증: 에이전트 산출물을 그대로 신뢰하지 않고 두 가지 cross-check.

1. 수치 검증: 허브 백링크 수가 실제 grep 결과와 일치하는지

2. 사실 검증: voice-memo 깨진 링크 6개가 정말 존재하는지 (CLAUDE.md 이동 이력 대조)

baseline 측정 결과:

허브 상태:

Day 1 ④ — n=1 running-hub.md (12섹션 가설)

3년 5개월간 723회를 달리며 쌓인 자산이 흩어져 있었다 — 시스템 자산(README, 누적_통계, 스킬), 데이터(76개 일일 + 16개 주간 + archive), 방법론(MAF 프로토콜), 회고 5개, 발표 4개, 가족 마라톤 이벤트.

기존 habits-mastery-hub.md를 참고 모델로 삼아 컨벤션 학습 후, 12섹션 구조 설계:

📌 한 눈에 보는 현황     (테이블 - 시작일/누적/페이스/현재 프로토콜)
🏆 마일스톤             (횟수 + 의미 있는 사건)
🛠️ 시스템 자산           (자동화 스킬)
📁 데이터 자산           (일일/주간/archive)
🧠 방법론·과학           (MAF + 5심박존 + 케이던스)
💎 회고 자산             (5건)
🎤 발표·콘텐츠 자산      (지피터스 4건)
🏅 특별한 이벤트         (첫 가족 마라톤)
💡 핵심 철학             (꾸준함·측정·아모르 파티)
🎯 비전                  (단기/중기/장기)
🔗 관련 허브             (4개)
📚 참고 자료             (책·이론 + 핵심 인용)

핵심 인용구를 허브 최상단에 박았다: "723번의 달리기, 0번의 포기."

미래에 의지가 약해질 때 이 한 줄이 첫 화면에 떠 있다는 사실만으로 다시 신발 끈을 묶게 된다.

위키링크 무결성 검증:

for p in $17개_경로; do
  [ -f "${p}.md" ] && echo "OK" || echo "MISSING: $p"
done
# 17/17 OK

양방향 back-link 3곳 추가: habits-mastery-hub.md + 15-running/README.md + 15-running/누적_통계.md. 동시에 누적 통계 숫자도 갱신: 657회 → 723회, 3,285km → 3,615km (2026-02-02 baseline 이후 갱신 부채 해소).

핵심 질문: running-hub의 12섹션이 달리기 전용 우연인지 재사용 가능한 패턴인지 검증해야 한다.

업무 영역에 그대로 못 옮기는 섹션이 있었다:

• "마일스톤"(횟수 기반) → 업무에서는 약함

• "데이터 자산"(일일/주간 기록) → 업무에서는 없음

• "특별 이벤트" → 업무에서는 "정책 활동"이 더 자연스러움

→ 80% 재사용 + 20% 영역 특화로 13섹션 재설계. 업무 철학 섹션에 박은 4개 원칙:

• "감정이 태도가 되지 않도록"

• "부처님의 귀로 듣는다"

• "데일 카네기 3원칙"

• "자동화로 마찰 제거"

→ running-hub의 "0번의 포기"가 의지 약해질 때 신발 끈을 묶게 한다면, 업무 허브의 인용구는 어려운 회의·인사 갈등 순간 평정심을 유지하게 한다. 영역별 허브의 인용구는 그 영역에서 가장 흔들리는 순간을 겨냥해야 한다.

위키링크 무결성 검증에서 첫 시도 34/36 - 깨진 2개 발견:

• 30-knowledge/31-reflections/260331(화)-AI도시연구회-...HWPX-자동변환-완료.md → 없음

• 30-knowledge/31-reflections/260429(수)-AI창의적브레인스토밍-...구조개편.md → 없음

원인: 두 회고는 60-gg-work/61-reflections/에 있는데 30-knowledge/31-reflections/로 오인. 폴더 분리 룰이 강할수록 검증 자동화가 필수임을 확인. 수정 후 재검증 → 36/36 OK.

양방향 back-link 4곳: 자산 3곳(CLAUDE.md / 69-ㅇㅇㅇㅇㅇ/README.md / 260213-팀별-타임라인.md) + 허브-허브 1곳(habits-mastery-hub의 "관련 허브" 섹션). 상위 허브가 신규 허브를 가리켜야 그래프에서 중심성이 살아남.

검증 결과: 12섹션 컨벤션이 80% 재사용 가능 + 20% 영역 특화. 영역마다 지배적 축이 다르다는 통찰: 달리기는 시간, 업무는 부서, 독서는 책, 인맥은 사람.

Day 2 ⑥ — 진단 액션 1+2 실행 (37개 링크, 90분)

아침에 어제 진단 보고서의 "다음 단계 권장" 섹션을 그대로 to-do로 변환했다. 보고서가 이미 4가지 작업에 대해 파일 경로·기대 효과·예상 소요 시간을 명시해뒀기 때문에 추가 분석 없이 곧장 실행.

단계 1 (30분) — 부채 청소 + 즉시 가능한 연결

단계 2 (60분) — 35-writing 11편 양방향 연결

여기서 함정 발견: 11개 파일에 동시 Edit 호출 → 첫 번째만 성공, 나머지 10개는 "File has not been read yet" 에러.

해결: 9개 파일을 병렬 Read(앞 3줄만 — 본문은 어차피 끝부분만 고치므로) → 다시 9개 병렬 Edit. 2-pass로 완료, 시간 손실 약 1분.

교훈: Edit 도구의 Read 선행 요구는 안전장치(파일 모르고 덮어쓰기 방지). 우회 대신 패턴 적응 — 다음 작업부터는 처음부터 Read 병렬 먼저.

각 글마다 맞춤 1줄 설명을 박았다. 예:

• 260417 기억이라는이름의착각 → "음성 → 기록 → 글쓰기 파이프라인의 첫 산출물"

• 260423 사랑이라는이름의독백 → "소설 '롤리타'를 통해 사랑의 일방성과 경청을 성찰한 글"

• 260507 어머니의번역어 → "어머니의 '밥은 먹었니' 한 마디에 담긴 번역어를 풀어낸 사유"

→ 링크는 그래프를 만들지만, 1줄 설명이 그래프에 의미를 부여한다. 통일된 형식은 빠르지만 죽은 그래프를, 맞춤 설명은 느리지만 살아 있는 그래프를 만든다.

결과: content-creation-hub 받는 링크 6 → 17 (외향성 비대칭 1순위 해소). 어제 진단의 결론이 90분에 정량 변화로 입증.

Day 2 ⑦ — 옵션 A 마무리 (23개 추가)

같은 날 두 번째 사이클. "측정 → 다음 진단"의 전제는 단계 1+2가 완전히 닫혀 있어야 한다는 것. 잔여 30분을 남겨두면 다음 진단에서 또 "이건 닫혔는가?"가 첫 질문이 된다.

→ 어제 회고의 "24시간 부채 청소 원칙"의 두 번째 적용. voice-memo 4개를 24시간 내 닫은 것처럼, 단계 2 잔여도 같은 날 닫는다.

14개 파일을 첫 사이클부터 병렬 Read (오전 교훈 즉시 적용) → 1-pass 완료, 우회 비용 0. 같은 날 두 번째 사이클이 첫 사이클보다 무조건 빠르다 — 이것이 컨벤션의 가치.

명명 구분의 의미: 같은 백링크 작업이라도 출처에 따라 명명을 구분.

• Related Hubs (35-writing) = 내 글이 어느 허브에 속하는가 (소유)

• 내 지식과의 연결 (70-collected) = 외부 자료가 내 지식과 어디서 만나는가 (교차)

→ 같은 기능이라도 의미가 다르면 명명을 분리한다. 통일은 빠르지만 분화는 정확하다.

가장 의미 있는 변화: 6개 허브가 모두 외부 백링크 10+ 도달.

편차 5~17 → 10~29로 좁혀짐. vault에서 처음으로 "허브 1~2개가 받쳐주는 비대칭 구조"가 아닌 "6개 허브가 균등하게 받쳐주는 그물 구조" 도달.

또 하나의 마일스톤: 70-collected가 0% → 13% (4/30파일) 첫 진입. 1년간 수집만 하고 잊혀진 자료들이 처음으로 내 지식에 닿았다.

Day 2 ⑧ — n=3 reading-hub.md + hub-template.md 추출

같은 날 저녁, 옵션 B(자산 묶기, 창작 작업) 전환. 책 자산이 3개 영역에 흩어져 있었다:

• 40-personal/47-media/books/ — 6개 목록 파일 (35권 완독)

• 10-projects/18-reading-notes/ — 3개 책 폴더, 12개 챕터 노트

• 30-knowledge/35-writing/ — 11편 수필 중 책 기반 6편

세 영역이 한 번도 한 곳에서 묶인 적이 없었다.

reading 영역의 지배적 축은 책(gg-work 회고의 통찰). 14섹션 설계:

📌 한 눈에 / 🏆 마일스톤 / 🌟 인생 철학 시리즈 / 🌍 세계관 형성 3권 /
🧠 뇌과학·심리학 / 💰 부동산·투자 / 📈 비즈니스·자기계발 / ✍️ 문학·소설 /
📖 진행 중인 독서노트 / 🖋️ 책에서 글로 — 35-writing 연결 /
💡 핵심 철학 / 🎯 비전 / 🔗 관련 허브 / 📚 참고 자료

새 발명: "🖋️ 책에서 글로" 섹션 — running·gg-work에는 없는 독서만의 출구 구조. 책 → 챕터 노트 → 수필 → content-creation-hub 파이프라인이 vault에 처음으로 명시적 구조로 박혔다. "읽은 책이 글이 될 때 비로소 내 것이 된다"가 추상적 다짐이 아니라 그래프 형태가 됐다.

→ 영역마다 출구가 다르다: running의 출구는 발표·이벤트, gg-work의 출구는 회의록·hwpx, reading의 출구는 수필.

위키링크 무결성 검증 — 첫 시도부터 36/36 OK. 이유: gg-work 때 깨진 링크 패턴(폴더 분리 룰 혼동)을 이번엔 사전에 인지하고 경로 작성. 검증 자동화가 같은 실수를 두 번 만들지 않게 한다.

양방향 back-link 5곳 (3→4→5로 진화):

• 자산 4곳: books-completed.md / 18-reading-notes/README.md / 가난한-찰리의-연감/README.md / 우리는-어떻게-마음을-움직이는가/README.md

• 허브-허브 1곳: relationship-wisdom-hub (받는 10 → 11). 약한 허브를 의식적으로 선택해서 별도 작업 없이 자연 회복.

→ 약한 허브 보강은 매 허브의 부산물로 일어나도록 룰화.

핵심 사건: 허브 직후 hub-template.md 추출. 3개 허브의 공통 패턴:

• 공통 필수 7개 섹션: 한 눈에 / 핵심 철학 / 비전 / 관련 허브 / 참고 자료 + (마일스톤 or 주요 사건) + (회고 자산)

• 영역 특화 3~6개 섹션: 지배적 축에 따라 자산 카테고리화

• 총 12~14섹션이 일반 범위

템플릿에 박은 컨벤션 메모:

• 위키링크 절대 경로 / 폴더 직접 링크 금지 / | 표시명 / 1줄 설명 의무

• 무결성 검증 bash 스크립트

• back-link 5곳 가이드 (자산 4 + 허브-허브 1)

• 인용구 작성 가이드 ("영역의 가장 흔들리는 순간을 겨냥")

• 마일스톤 vs 주요 사건 선택 기준 (단조 증가 vs 시점 기반)

다음 허브부터는 이 템플릿 복사 → 5분 작업 가능. n=3에서 패턴이 외화의 임계점에 도달했다.

📸 Obsidian 그래프 뷰 — 작업 전후 비교

• 작업 전: 5개 허브가 옛 경로로 끊긴 고립 상태 (사용률 6%, 6개 허브 평균 9.7개)

  

  ALT

  점이 있는 원의 이미지

• 작업 후: 6개 허브 + 100개 파일 + 70-collected 4개 첫 진입한 그물 구조 (사용률 10%, 6개 허브 평균 20.7개)

ALT

점 네트워크의 흑백 이미지

3. 결과와 배운 점

정량 결과 (이틀 누적)

배운 점 (10가지)

1. 측정 없는 PKM은 신앙이다 "잘 되고 있다"는 느낌은 baseline 없으면 환상. 974개 전수 스캔으로 6.1%라는 baseline을 잡고 나서야 "10% 도달"이라는 변화가 측정 가능해졌다. PKM에서 "느낌으로 관리"는 결국 무너진다.

2. "다 고쳤다"는 항상 거짓이다 오전에 깨진 링크 22개를 0개로 만들고 만족했는데, 진단을 돌리니 voice-memo 폴더에 6개가 더 있었다. "내가 본 곳에서 0개"와 "vault 전체에서 0개"는 다르다. 정량 측정이 없으면 누락은 영원히 부채로 남는다.

3. 진단은 다음 날 실행되어야 진단이다 진단 보고서의 가치는 보고서 자체가 아니라 다음 날 아침 "옵션 A부터 할까요?"에 "응" 한 마디로 90분 작업이 시작된 것에 있었다. 추상적 권고("연결을 더 많이 하세요")는 죽은 진단. baseline이 있어야 변화를 인지하고, 변화를 인지해야 동기가 유지된다.

4. 부채는 발견 후 24시간 안에 닫는다 voice-memo 깨진 링크 6개를 24시간 안에 닫지 않았다면 다음 진단에서 또 발견되어 "원래 있던 부채"로 굳었을 것이다. 새 발견과 오래된 문제는 처리 비용이 10배 다르다.

5. n=1 가설, n=2 검증, n=3 템플릿화 running-hub(n=1)는 가설이었다. gg-work-hub(n=2)에서 12섹션 컨벤션이 80% 재사용됨을 확인. reading-hub(n=3)에서 패턴이 외화 가치를 갖는다고 판단해 hub-template.md로 추출. 머릿속의 패턴이 vault 자산이 되는 임계점은 3. 두 번은 우연일 수 있지만, 세 번이면 우연이 아니다.

6. 영역마다 지배적 축이 다르다 달리기는 시간(623→723회), 업무는 부서(ㅇㅇㅇㅇㅇ/ㅇㅇㅇㅇㅇ), 독서는 책(35권 카테고리). 같은 12섹션 컨벤션이라도 축을 영역에 맞게 재해석해야 진입점이 명확해진다. 영역마다 출구도 다르다 — running은 발표, gg-work는 회의록·hwpx, reading은 글.

7. 허브는 사전이지 노트가 아니다 허브에 모든 걸 다 적고 싶은 충동을 참아야 한다. 허브의 미덕은 압축이지 완전함이 아니다. 깊이는 가리킴 받은 노트에 위임. 허브에 너무 많은 내용을 쓰면 허브가 노트가 된다.

8. 외향성 과다 허브는 글쓴이의 시각 한계가 만든 패턴이다 content-creation-hub가 받는 6, 나가는 21이었던 이유: 글을 쓸 때는 앞으로 간다. 백링크를 거는 일은 뒤를 돌아보는 일이다. 두 가지를 동시에 하면 인지 부하가 크기 때문에, 글은 글대로 쓰고 백링크는 한 번에 묶어서 처리하는 분리가 효율적.

9. 같은 기능이라도 의미가 다르면 명명을 분리한다 Related Hubs(내 글) vs 내 지식과의 연결(수집물) — 두 글자만 다르지만 의미는 크다. 전자는 소유, 후자는 교차. 통일은 빠르지만 분화는 정확하다.

10. 교훈은 회고에 박혀야 하는 게 아니라 다음 작업에 박혀야 한다 오전 회고의 "Read 병렬 먼저" 교훈이 오후 옵션 A에서 즉시 검증됐다(1-pass 완료). 만약 회고를 일요일에 썼다면 이 교훈은 5일 뒤 잊혀졌을 가능성이 크다. 회고 직후 같은 패턴 작업이 있을 때 그 교훈이 가장 강하게 박힌다.

시행착오

시행착오 1 — 에이전트 위임 15분 대기에서 의심 974개 파일 스캔이 15분 걸리니 "잘 되는 거 맞아?" 의문이 들어 사용자가 작업 중단·재개 지시. 사후 분석으로 정상 시간임을 확인. → 다음번엔 위임 직후 예상 소요 시간을 명시. "974개 파일 스캔 + 본문 읽기로 약 15분 소요 예상" — 신뢰의 핵심.

시행착오 2 — 11개 파일 동시 Edit 실패 (10/11) Edit 도구는 파일당 Read 선행을 요구. 한 메시지에서 11개 파일 처음 편집 시 첫 번째만 성공. → 9개 병렬 Read(앞 3줄만) → 다시 9개 병렬 Edit. 2-pass로 완료. → 다음 작업(옵션 A 14개)에서는 처음부터 Read 병렬 먼저 → 1-pass 완료. 우회 대신 패턴 적응.

시행착오 3 — 폴더 분리 룰 혼동으로 깨진 링크 2개 업무 회고(60-gg-work/61-reflections/)와 개인 회고(30-knowledge/31-reflections/)를 분리해둔 룰 자체는 좋지만, gg-work-hub 작성 중 두 폴더 혼동. → 검증 스크립트가 즉시 발견. 분리 룰이 강할수록 검증 자동화는 필수. 시각 확인은 누락을 영원히 잡지 못한다.

시행착오 4 — sed vs Edit 가이드 충돌 CLAUDE.md는 "Edit files: Use Edit (NOT sed/awk)"를 권장하지만 13개 파일에 같은 5개 패턴 일괄 치환은 sed가 적합. → sed로 진행하되 git diff + 깨진 링크 0개 검색으로 즉시 검증. 도구 가이드는 기본값이고, 작업 특성에 따라 의도적으로 다른 선택 가능 — 단 검증 책임은 더 무거워진다.

시행착오 5 — 진단 보고서 수치와 실제의 미세 오차 보고서가 "깨진 링크 6개"라고 명시했지만 실제 grep 결과는 4개 (폴더 링크 4개를 포함해 셌을 가능성). → 4개만 수정해도 0개 도달. 위임 결과의 수치는 핵심만 검증하고 미세 오차는 무시. 결론(부채 해소 필요)이 같다면 OK.

핵심 인용구의 역할

각 허브에 박은 첫 줄 인용구가 단순 장식이 아니라는 발견:

• running-hub: "723번의 달리기, 0번의 포기." — 의지 약해질 때 신발 끈을 다시 묶게 한다

• gg-work-hub: "감정이 태도가 되지 않도록." — 어려운 회의·인사 갈등에서 평정심 유지

• reading-hub: "읽은 책이 글이 될 때 비로소 내 것이 된다." — 책→글 파이프라인 의식화

→ 영역별 허브의 인용구는 그 영역에서 가장 흔들리는 순간을 겨냥한 무기. 의지가 약해질 때, 어려운 회의 전에, 책을 덮은 직후 — 각 상황에 적절한 한 줄이 첫 화면에 떠 있다.

앞으로의 계획

단기 (이번 주)

• 두 번째 진단 실행 — 1주일치 변화 정량 검증 (사용률 / 6개 허브 백링크 / 신규 부채)

• 4번째 허브 (투자 vs 영어 vs 가족) 작성으로 hub-template 5분 작업 가설 검증

• 진행 중 책 2권의 챕터 노트 추가 → reading-hub의 "📖 진행 중인 독서노트" 갱신

중기 (이번 달)

• 70-collected 나머지 26개 파일 점진적 진입 (목표: 13% → 50%)

• running-hub 외부 백링크 12 → 17 이상 (달리기 회고 미연결분 추가 연결)

• 4번째 허브 완성 후 hub-template.md 사용 회고 — 5분 작업 가설이 맞았는가

• books-completed.md의 각 책 항목에 한 문단 회고 추가 (한 줄 평 → 단락 평)

장기 (3개월)

• vault 전체 위키링크 사용률 10% → 30%

• 40-personal 사용률 3% → 15%

• 6개 허브 평균 외부 백링크 20.7개 → 30개 (모든 허브가 hub-of-hubs 수준)

• 100권 완독 + 책 → 글 파이프라인 (완독한 책마다 최소 1편 35-writing 수필)

• GPTers 22기 4주차 MCP 시연 — Claude가 vault를 자율 탐색하면서 글쓰기/분석에 활용

4. 도움 받은 글 / 참고

이재엽 & 온어닷 스터디장님의 강의와 자료

• 지피터스 22기 1주차 강의 자료 (week1-slides.html — Vault 구축)

내 메모리 시스템 (영구 운영 원칙)

• ~/.claude/CLAUDE.md — 글로벌 사용자 원칙 (미니멀 원칙 포함)

• .claude/CLAUDE.md — 프로젝트 규칙 (Johnny Decimal + 이동 이력)

• feedback_minimal-frontmatter.md — 프론트매터 미니멀 원칙

• feedback_never-overwrite-files.md — 파일 버전 분리 원칙

• feedback_writing-to-daily-note.md — 콘텐츠 결과 Daily Note 자동 기록

운영 도구

• zettelkasten-linker 스킬 — PKM 볼트 분석 + 노트 연결 제안

• daily-note 슬래시 명령 — 위키링크 자동 채움 로직 포함

이틀간 산출물

• 30-knowledge/33-knowledge-hub/running-hub.md (194줄, 12섹션)

• 30-knowledge/33-knowledge-hub/gg-work-hub.md (약 190줄, 13섹션)

• 30-knowledge/33-knowledge-hub/reading-hub.md (약 240줄, 14섹션)

• 00-system/01-templates/hub-template.md (공식 템플릿 + 컨벤션 메모)

• 30-knowledge/31-reflections/ 8건 회고 (진단/실행/허브생성/마무리 사이클)

핵심 한 줄들

"vault는 외부 뇌(external brain)다. 노트들이 서로를 모르면, 그건 파일 더미지 지식 자산이 아니다." 🧠

"측정 없는 PKM은 신앙이다. baseline이 있어야 시스템은 진화한다." 📊

"자산이 흩어져 있으면 그건 잠재력이지 능력이 아니다. 허브는 잠재력을 능력으로 바꾼다." 🏃

"하나의 영역에서 잘 작동하는 패턴이 두 번째 영역에서도 작동할 때, 비로소 그것은 패턴이 된다." 🏢

"n=1 가설, n=2 검증, n=3 템플릿화. 머릿속의 패턴이 vault 자산이 되는 임계점은 3이다." 📖

"교훈은 회고에 박히지 않는다. 다음 작업에 박힌다. 6개 허브 균등 10+ — vault에 처음으로 그물이 만들어졌다." 🕸️