Graphify는 마크다운도 된다. 그래도 안 쓴 이유

이번 글의 결론은 Graphify가 마크다운 위키를 처리할 수 있지만, 현재 ai-survival-log에는 채택하지 않는다는 판단입니다.

처음에는 graphify update wiki 실패를 보고 Graphify를 코드 인덱서로 오해했습니다. 다시 확인하니 초기 인제스트 명령은 graphify ./wiki였고, Markdown도 Claude 기반 개념 추출 대상이었습니다.

그래서 판단 기준을 바꿨습니다. 문제는 Graphify가 할 수 있는지가 아니라, 현재 위키에 그래프 계층이 필요한지였습니다.

개인 위키가 커지면 index.md나 텍스트 검색만으로 연결 구조를 파악하기 어려워집니다. 어떤 개념이 어떤 주제와 얼마나 연결돼 있는지, 단순 목록으로는 잘 보이지 않습니다. Graphify는 마크다운 파일을 그래프 DB로 변환해 관계를 시각화하고 쿼리하는 흐름을 제공합니다.

raw 수집 경로가 먼저 정리됐습니다

Graphify 평가는 Obsidian Web Clipper 세팅을 마친 직후 시작됐습니다.

이날 저장소 구조를 4계층으로 정리한 다음, 수집 파이프라인을 붙이기로 했습니다. 자료가 raw/로 들어오는 경로를 명확히 하는 게 목표였습니다. 템플릿 10종을 설계해서 Obsidian Web Clipper에 등록했습니다.

raw/articles/  ← 아티클 클리핑
raw/videos/    ← 영상 트랜스크립트
raw/books/     ← 책 챕터 노트
raw/journals/  ← 대화 백업, 인사이트
raw/podcasts/  ← 팟캐스트 에피소드

각 템플릿에는 Why This Matters, Summary Seed, Extraction Priorities 같은 힌트 섹션을 넣었습니다. /wiki:ingest가 수집된 자료의 분석 방향을 빠르게 잡을 수 있도록 하는 구조입니다.

세팅 중 문제가 하나 나왔습니다. fallback 템플릿의 https://* 전역 트리거가 모든 URL을 가로챘습니다. 해결은 간단했습니다. 범용 템플릿은 트리거를 비우고 수동 선택 전용으로 운용했습니다.

첫 클리핑은 Graphify 평가로 이어졌습니다

수집 파이프라인이 준비되자 첫 자료를 골랐습니다.

위키가 계속 커지고 있었고, 관계 구조를 더 잘 확인할 방법이 필요했습니다. graphify.net/kr/에 있는 "AI 코딩 어시스턴트를 위한 지식 그래프 스킬" 아티클이 눈에 띄었습니다. Web Clipper 첫 번째 클리핑 대상으로 골랐습니다.

템플릿 구조는 잘 동작했습니다. Why This Matters, Summary Seed 섹션이 채워졌습니다. 다음 확인 대상은 Graphify를 이 위키의 파생 그래프 계층으로 둘 수 있는지였습니다.

Graphify를 이 위키의 파생 그래프 계층으로 둘 수 있을까?

그래서 설치 후 CLI 동작을 확인하기로 했습니다.

잘못된 서브커맨드가 성급한 결론을 만들었습니다

pip install graphifyy

graphifyy 0.4.23이 설치됐습니다. 위키 디렉토리를 대상으로 바로 테스트했습니다.

graphify update wiki
# → No code files found
# → Nothing to update

graphify wiki
# → unknown command 'wiki'

두 번 실패했습니다. 이 지점에서 결론을 성급하게 냈습니다.

"Graphify는 소스 코드 파일(.py, .js, .ts)을 스캔하는 도구입니다. 마크다운은 처리 대상이 아닙니다."

이렇게 판단하고 pip uninstall했습니다. 블로그 초안에도 "코드 인덱서였다"고 적었습니다.

그런데 이 결론은 틀렸습니다. graphify update가 코드 전용 서브커맨드였고, 올바른 명령을 한 번도 테스트하지 않았습니다.

공식 문서는 마크다운 처리 경로를 보여줬습니다

이 포스트를 쓰기 전에 graphify.net 공식 문서를 다시 확인했습니다.

올바른 초기 인제스트 명령은 다음과 같았습니다.

graphify .          # 현재 디렉토리 전체 처리
graphify ./wiki     # wiki/ 폴더만 처리

이 명령은 현재 디렉토리의 모든 마크다운 파일, 코드, 이미지를 분석하여 그래프로 변환합니다. graphify update는 이미 처리된 코드 파일의 증분 갱신 전용이었습니다. 처음 인제스트는 graphify .입니다.

Graphify의 실제 처리 방식을 정리하면 이렇습니다.

파일 유형	확장자	처리 방식
코드	.py .ts .js .go 등	tree-sitter AST 파싱 (LLM 없음)
문서	.md .mdx .html .txt	Claude LLM 기반 개념·관계 추출
PDF	.pdf	인용 채굴 + 개념 추출
이미지	.png .jpg .webp	Claude 비전 분석

마크다운 파일은 Claude가 직접 읽고 개념과 관계를 추출합니다. 출력은 graphify-out/에 생성됩니다.

graphify-out/
├── graph.html        ← 인터랙티브 시각화
├── GRAPH_REPORT.md   ← 구조 리포트 (허브 노드, 커뮤니티, 고아 페이지)
├── graph.json        ← 그래프 데이터
└── obsidian/         ← Obsidian vault 내보내기

추가로 --mcp 플래그를 쓰면 MCP 서버가 뜨고, Claude Code에서 그래프 쿼리 인터페이스를 쓸 수 있습니다.

처음 평가에서는 초기 인제스트 명령, Markdown 처리 경로, MCP 연결 가능성을 확인하지 않았습니다.

가능하다는 사실과 필요하다는 판단은 달랐습니다

Graphify가 마크다운을 처리할 수 있다는 사실을 확인했으니, 다음 판단은 채택 여부였습니다.

이 위키의 운영 원칙에는 이런 말이 있습니다. "그래프 계층이 필요해지더라도 wiki/에서 파생되는 분석 레이어로 다룹니다." Graphify는 그 역할을 할 수 있습니다. wiki/ 구조를 바꾸지 않고 graphify ./wiki를 돌리면 파생 그래프가 생성됩니다. 원칙과 충돌하지 않는 방식으로 쓸 수 있습니다.

하지만 원칙과 충돌하지 않는다는 사실만으로 채택 이유가 되지는 않습니다.

쓰면 생기는 것	쓰면 생기는 비용
GRAPH_REPORT.md로 허브 노드, 고아 페이지 가시화	Claude API 호출 비용 (LLM 기반 추출)
graph.html로 위키 연결 구조 시각적 탐색	추가 의존성과 빌드 스텝
--mcp로 Claude에 그래프 쿼리 인터페이스 추가	그래프가 또 다른 유지보수 대상
Obsidian vault 내보내기 호환

현재 위키는 84페이지입니다. LLM Wiki Pattern이 제시하는 50~200페이지 sweet spot 안에 있습니다. 이 규모에서는 wiki lint가 고아 페이지를 잡아주고, index.md가 검색 인덱스 역할을 하고, Claude가 마크다운을 직접 읽습니다. 그래프 도구가 해결해줄 병목이 아직 없습니다.

현재 기준에서는 84페이지 위키에 Graphify를 붙이는 이유가 운영 병목보다 시각화 욕구에 더 가깝습니다. 그것은 좋은 채택 기준이 아닙니다.

채택 보류는 재검토 기준과 함께 남겼습니다

pip uninstall -y graphifyy

채택하지 않는다는 결론은 같지만 이유가 바뀌었습니다.

기존 결론은 "Graphify는 마크다운을 처리하지 못한다 → 안 쓴다"였습니다. 새로운 결론은 "Graphify는 마크다운을 처리할 수 있다 → 그런데 지금은 필요 없다"입니다.

두 결론의 방향은 같지만, 두 번째가 훨씬 정확합니다. 도구의 한계가 아니라 프로젝트의 현재 상태가 기준입니다.

이 위키의 로드맵에는 이렇게 적혀 있습니다. "graph DB는 필요가 생긴 뒤 파생 실험으로 검토합니다." 그 조건은 다음과 같이 생길 수 있습니다.

• 위키가 200페이지를 넘어서 index.md 탐색이 느려질 때
• Claude Code에서 MCP 쿼리 인터페이스가 실질적으로 필요해질 때
• GRAPH_REPORT.md가 줄 수 없는 wiki lint의 맹점이 발견될 때

그 시점이 오면, graphify ./wiki를 돌려볼 것입니다. wiki/ 구조를 바꾸지 않아도 되니까.

도구 평가는 가능 여부와 필요 여부를 나눠야 했습니다

Graphify를 평가하면서 두 가지 실수가 있었습니다.

첫 번째는 기술적 실수입니다. 잘못된 서브커맨드(graphify update)를 테스트해놓고, 올바른 명령(graphify .)을 한 번도 시도하지 않았습니다. 두 번의 실패만으로 도구의 능력을 판단했습니다.

두 번째는 평가 순서의 실수입니다. "이 도구가 무엇을 할 수 있는가"를 먼저 정확히 확인하지 않고, "이 도구가 필요한가"로 바로 넘어갔습니다.

도구 평가의 올바른 순서는 이렇습니다.

1. 도구가 실제로 무엇을 하는지 공식 문서로 확인한다
2. 올바른 명령을 찾아서 테스트한다
3. 그 위에서 현재 프로젝트에 필요한지 판단한다

도구가 할 수 있는 것과, 현재 프로젝트에 필요한 것은 다른 질문입니다.

Graphify는 좋은 도구입니다. 이 위키에서 지금 채택하지 않는 이유는 Graphify가 못해서가 아닙니다. 현재 위키가 아직 그 단계가 아니기 때문입니다.