Graphify와 LLM Wiki: 폴더를 지식 그래프로 바꾸는 법

LLM을 오래 써 보면 반복적으로 부딪히는 문제가 있다.

어제 분명히 코드베이스를 읽혔고, 논문도 넣었고, 관련 문서도 정리했다. 그런데 오늘 다시 질문하면 모델은 또 처음부터 읽는다. 파일을 다시 찾고, 관련 부분을 다시 추론하고, 여러 문서를 다시 이어 붙인다. 대화는 똑똑해 보이지만, 지식은 누적되지 않는다.

이 지점에서 Andrej Karpathy가 제안한 LLM Wiki 아이디어는 매우 정확한 문제의식을 던진다. 질문할 때마다 원문 조각을 다시 검색하는 RAG만으로는 장기적인 지식 축적이 어렵다. 대신 LLM이 원천 자료를 읽고, 지속적으로 관리되는 마크다운 위키를 만들고, 새 자료가 들어오면 기존 위키의 엔티티 페이지, 개념 페이지, 요약, 모순 지점을 계속 업데이트하게 하자는 것이다. 지식이 매번 재발견되는 것이 아니라, 컴파일되어 쌓이는 구조다.

여기에 흥미롭게 연결되는 도구가 Graphify다. Graphify는 폴더 안의 코드, 문서, 논문, 이미지, 오디오, 비디오를 읽고, 그 안의 개념과 관계를 지식 그래프로 변환한다. 그리고 그 결과를 graph.json, GRAPH_REPORT.md, graph.html, 선택적으로는 위키 형태의 마크다운으로까지 내보낸다.

내가 보기에 이 둘은 경쟁 관계가 아니다. 오히려 같은 방향을 보는 서로 다른 층이다.

• LLM Wiki는 지식을 지속적으로 정리하고 유지하는 운영 철학이다.
• Graphify는 그 지식을 구조와 관계 중심으로 탐색하게 만드는 그래프 계층이다.

이 글에서는 Graphify가 무엇인지, Karpathy의 LLM Wiki와 어떤 점에서 맞물리는지, 그리고 개인 블로그, 연구 노트, 팀 코드베이스에서 어떤 식으로 활용할 수 있는지 실무 관점으로 정리한다.

한 줄 결론

LLM Wiki가 “LLM이 관리하는 지속형 마크다운 위키”라면, Graphify는 그 위키와 원천 자료 사이에 놓이는 “관계 중심 지도”다.

즉 Graphify의 진짜 가치는 단순 검색 최적화가 아니라, 파일 묶음을 개념, 관계, 커뮤니티가 드러나는 지식 그래프로 바꿔 LLM에게 더 좋은 컨텍스트 구조를 제공한다는 데 있다.

1. 문제: LLM은 잘 읽지만, 오래 기억하지 못한다

기존 RAG 방식은 보통 아래처럼 동작한다.

1. 문서 업로드
2. 임베딩/색인
3. 질문 입력
4. 관련 chunk 검색
5. 답변 생성

이 구조는 빠르게 시작하기 좋다. 하지만 장기적으로는 분명한 한계가 있다.

첫째, 질문할 때마다 지식을 다시 조립한다

이미 한 번 읽은 자료라도, 다음 질문에서는 다시 retrieval과 synthesis를 반복한다. 같은 문서를 바탕으로 여러 질문을 던질수록 “누적된 이해”보다 “반복 추론 비용”이 커진다.

둘째, 문서 사이의 연결 관계가 구조적으로 남지 않는다

RAG는 보통 chunk relevance에 집중한다. 그런데 실제 연구나 개발에서는 개별 chunk보다 문서 A와 문서 B가 어떤 관점에서 연결되는지, 코드와 문서가 어떤 개념을 공유하는지, 새 문서가 기존 주장과 어디서 충돌하는지가 더 중요할 때가 많다.

셋째, 좋은 비교표와 분석이 대화창 안에서 사라진다

한 번 깊게 분석한 내용도 별도로 저장하지 않으면 다시 찾기 어렵다. 특히 장기 리서치나 코드베이스 온보딩처럼 며칠에서 몇 달 이어지는 작업에서는 이 손실이 매우 크다.

넷째, 무엇이 근거고 무엇이 추론인지 구분이 어렵다

LLM의 답변은 종종 그럴듯하지만, 어느 연결이 실제 문서에 있었고 어느 연결이 모델의 해석인지 추적하기 어렵다. 지식 시스템이 커질수록 이 문제는 더 심각해진다.

Karpathy의 LLM Wiki는 이 문제를 다음과 같이 재구성한다.

raw sources → LLM이 유지보수하는 wiki → 질문/탐색/새 분석 → 다시 wiki에 반영

이 구조에서 핵심은 사람과 LLM의 역할 분담이다.

• 사람은 자료를 고른다.
• 사람은 질문을 던진다.
• 사람은 무엇이 중요한지 판단한다.
• LLM은 요약한다.
• LLM은 교차참조를 만든다.
• LLM은 오래된 내용을 갱신한다.
• LLM은 구조를 유지한다.

Karpathy가 Obsidian을 IDE, LLM을 프로그래머, 위키를 코드베이스라고 비유한 이유도 여기에 있다. 지식 관리를 수기 메모가 아니라 유지보수 가능한 시스템으로 본 것이다.

2. Graphify는 무엇인가

Graphify를 한 문장으로 설명하면 이렇다.

폴더 안의 파일들을 LLM이 탐색하기 쉬운 지식 그래프로 바꾸는 도구다.

중요한 점은 대상이 코드만이 아니라는 것이다. Graphify가 흥미로운 이유는 한 프로젝트 안에 뒤섞여 있는 다양한 자료를 함께 본다는 데 있다.

예를 들어 한 폴더 안에 아래가 같이 있다고 해 보자.

• 코드 파일
• README와 설계 문서
• PDF 논문
• 스크린샷
• 다이어그램
• 화이트보드 사진
• 음성 메모
• 데모 비디오

보통 이 자료들은 서로 연결되어 있지만, 실제로는 파일 시스템 안에서 흩어져 있다. Graphify는 이런 이질적인 자료를 읽고 노드와 엣지로 정리된 구조로 바꾼다.

결과물도 꽤 실용적이다.

graphify-out/
├── graph.html
├── GRAPH_REPORT.md
├── graph.json
└── cache/

각 파일의 의미는 대략 이렇다.

• graph.html: 브라우저에서 시각적으로 보는 인터랙티브 그래프
• GRAPH_REPORT.md: 중요한 노드, 커뮤니티, 놀라운 연결, 추천 질문을 요약한 리포트
• graph.json: 이후 질의와 재활용을 위한 영속 그래프 데이터
• cache/: 변경된 파일만 다시 처리하기 위한 캐시

즉 Graphify는 단순 분석 결과 한 번 뽑고 끝나는 도구가 아니라, 반복 질의와 점진적 업데이트를 염두에 둔 중간 표현층을 만든다.

3. Graphify의 핵심 아이디어: 요약이 아니라 관계를 남긴다

많은 LLM 도구는 결과적으로 “요약문”을 만든다. 물론 요약도 중요하다. 하지만 실전에서 더 중요한 건 종종 관계 구조다.

예를 들어 이런 질문을 생각해 보자.

• 이 코드베이스에서 가장 중심적인 모듈은 무엇인가?
• 문서와 실제 코드 구조가 어디서 어긋나는가?
• 이 논문 개념이 코드에서는 어느 구현 포인트에 나타나는가?
• 이 프로젝트의 god node는 무엇인가?
• 이 파일 묶음에서 의외로 강하게 연결되는 개념은 무엇인가?

이런 질문은 단순 summary로는 잘 안 풀린다. 개별 문장을 잘 압축하는 것보다 무엇과 무엇이 연결되는가를 보는 구조가 필요하다.

Graphify는 바로 그 구조를 만든다. 요약을 버리는 게 아니라, 요약보다 한 단계 아래에 있는 지식의 형상(shape) 을 드러낸다고 보는 편이 정확하다.

4. 내부 동작: AST, 의미 추출, 그래프 클러스터링의 결합

Graphify가 흥미로운 이유는 모든 걸 LLM에게 통째로 맡기지 않는다는 점이다. 구조를 보면 꽤 좋은 분업이 들어가 있다.

4-1. 결정론적 코드 구조 추출

코드 파일에서는 tree-sitter 기반 AST 분석으로 클래스, 함수, import, 호출 관계, 주석, docstring 같은 구조를 먼저 뽑는다. 이 단계는 가능하면 모델 호출 없이 수행된다.

이 접근은 매우 중요하다. 코드의 기계적 구조는 굳이 LLM에게 맡길 이유가 없기 때문이다. 함수 호출 관계나 import 그래프 같은 것은 결정론적으로 추출하는 편이 더 빠르고 더 믿을 만하다.

4-2. 오디오/비디오 전사

오디오와 비디오는 전사를 통해 텍스트 층으로 올린다. 이렇게 하면 회의 녹음, 강의 영상, 데모 비디오도 이후 의미 추출 파이프라인에 편입할 수 있다.

이건 실제 연구 워크플로에서 꽤 유용하다. 지식은 텍스트 문서에만 있지 않다. 요즘은 오히려 고가치 맥락이 영상, 음성, 화면 캡처, 다이어그램에 숨어 있는 경우가 많다.

4-3. LLM 기반 의미 추출

문서, 논문, 이미지, 전사본 같은 비정형 자료에서는 LLM이 개념과 관계를 뽑는다. 여기서 중요한 것은 단순 키워드 추출이 아니라, 무엇이 어떤 맥락에서 연결되는지를 의미 수준에서 추출한다는 점이다.

4-4. 그래프 통합과 커뮤니티 탐지

추출된 노드와 엣지는 그래프로 합쳐지고, 커뮤니티 탐지 알고리즘을 통해 관련 개념 군집이 드러난다. 이 결과는 HTML, JSON, 마크다운 리포트, 위키 형태로 export된다.

즉 이 파이프라인은 다음처럼 요약할 수 있다.

files
 ↓
detect
 ↓
extract
 ↓
build_graph
 ↓
cluster
 ↓
analyze
 ↓
report / export

이 구조가 좋은 이유는, 결정론적인 층과 확률적인 층을 섞되 분리해 둔다는 것이다. 코드 구조는 기계적으로, 의미 연결은 LLM으로, 전체 형태는 그래프로 다룬다. 실무에서 꽤 바람직한 조합이다.

5. 무엇을 찾았고 무엇을 추론했는지 구분하는 설계가 좋다

LLM 기반 지식 도구에서 가장 중요한 문제 중 하나는 검증 가능성이다. 그럴듯한 연결은 많이 나오지만, 그것이 실제 원문 근거인지 모델의 해석인지 불분명하면 장기 지식 시스템으로 쓰기 어렵다.

Graphify가 좋은 이유는 edge에 confidence 성격을 구분해 붙인다는 점이다.

• EXTRACTED: 원문에서 직접 발견한 관계
• INFERRED: 합리적 추론으로 만든 관계
• AMBIGUOUS: 불확실해서 검토가 필요한 관계

이 구분은 매우 실용적이다.

예를 들어 블로그 글이나 연구 노트에서 다음처럼 말할 수 있다.

• 이 관계는 코드에 직접 나타난다.
• 이 관계는 문서와 코드 사이를 연결한 추론이다.
• 이 관계는 흥미롭지만 아직 검토가 필요하다.

지식 베이스가 커질수록 이런 레이블은 선택이 아니라 필수에 가깝다. 그렇지 않으면 시간이 지날수록 위키 전체가 “사실과 해석이 뒤섞인 상태”로 흐려진다.

Karpathy가 LLM Wiki에서 raw source를 immutable source of truth로 두자고 말한 이유와도 정확히 맞닿아 있다. 위키나 그래프는 강력한 인터페이스지만, 최종 근거는 원천 자료여야 한다.

6. LLM Wiki와 Graphify를 함께 보면 구조가 더 선명해진다

Karpathy의 LLM Wiki는 기본적으로 마크다운 중심 패턴이다.

raw sources → markdown wiki → index/log/schema

Graphify를 여기에 연결하면 다음 같은 확장 구조를 상상할 수 있다.

raw sources → graph.json / GRAPH_REPORT.md / graph.html → wiki/index.md → agent navigation

내가 보기엔 두 시스템의 역할 분담은 이렇게 정리할 수 있다.

LLM Wiki가 잘하는 것

• 요약 누적
• 개념 페이지 유지보수
• 비교/분석 문서 축적
• index와 log 관리
• 사람이 읽기 쉬운 구조화

Graphify가 잘하는 것

• 개념 간 관계를 노드/엣지로 명시화
• 코드와 문서를 같은 맥락에서 읽기
• 중심 노드와 커뮤니티 파악
• 질문을 더 잘 만들게 돕기
• 변경 파일만 재처리하는 점진적 업데이트

즉 LLM Wiki가 정리된 문서층이라면, Graphify는 구조를 드러내는 지도층이라고 볼 수 있다.

특히 Graphify가 위키 스타일 마크다운까지 생성하고, 에이전트가 JSON을 직접 파싱하지 않고도 index.md부터 탐색하도록 도와주는 부분은 매우 흥미롭다. 결국 두 아이디어 모두 같은 방향을 본다.

파일을 그냥 모아 두지 말고, LLM이 계속 탐색하고 유지할 수 있는 구조로 바꾸자.

7. 이 조합이 블로그에 좋은 이유: 글감이 “검색”이 아니라 “관계”에서 나온다

블로그 글 품질은 종종 얼마나 많이 읽었느냐보다, 얼마나 좋은 질문을 만들었느냐에서 갈린다.

보통 도구 리뷰 글은 이렇게 흐른다.

• README를 읽는다.
• 설치법을 정리한다.
• 기능 목록을 나열한다.
• 짧은 의견을 붙인다.

이 정도로는 평범한 소개글이 된다. 반면 Graphify 같은 구조를 사용하면 더 좋은 질문을 만들 수 있다.

예를 들면 이런 질문이다.

• Graphify가 왜 AST 추출과 의미 추출을 분리했는가?
• Graphify는 왜 단순 검색 도구가 아니라 관계 도구에 가까운가?
• LLM Wiki 철학과 Graphify는 어디서 만나고 어디서 갈라지는가?
• confidence label은 왜 장기 위키 운영에서 중요한가?
• 이 프로젝트의 god node와 커뮤니티는 실제 설계 의도를 어떻게 드러내는가?

이런 질문은 단순 기능 소개보다 훨씬 좋은 분석 글을 만든다. 다시 말해 Graphify의 진짜 가치는 “답을 준다”보다, 더 좋은 질문을 가능하게 한다는 데 있다.

8. 개인 블로그와 연구 노트에 적용하는 방식

개인 블로그나 메모 시스템에 적용한다면 아래 같은 구조가 자연스럽다.

my-blog/
├── _posts/
├── raw/
│   └── graphify/
│       ├── README.md
│       ├── ARCHITECTURE.md
│       ├── Karpathy-LLM-Wiki.md
│       ├── notes.md
│       └── screenshots/
├── graphify-out/
│   ├── GRAPH_REPORT.md
│   ├── graph.json
│   └── wiki/
│       └── index.md
└── drafts/

흐름은 간단하다.

1. 원천 자료를 raw/에 모은다.
2. Graphify로 그래프와 리포트를 만든다.
3. LLM은 GRAPH_REPORT.md, wiki/index.md, graph.json 기반으로 관계를 읽는다.
4. 블로그 초안을 만든다.
5. 좋은 분석 결과는 다시 위키나 노트에 편입한다.

이 구조의 장점은 분명하다.

• 매번 원문 전체를 다시 읽지 않아도 된다.
• 개념 연결이 더 선명해진다.
• 블로그 소재 발굴 속도가 빨라진다.
• 질문이 점점 더 좋아진다.
• 같은 주제를 시간이 지나며 더 깊게 파고들기 쉽다.

결국 이건 블로그 자동화라기보다, 블로그를 중심으로 한 개인 지식 운영 체계에 가깝다.

9. 팀 코드베이스에서는 왜 더 실용적인가

이 조합은 개인보다 팀에서 더 실용적으로 느껴질 수도 있다.

대부분의 AI 코딩 어시스턴트는 검색은 잘한다. 하지만 처음 프로젝트에 들어오면 코드베이스의 전체 형상은 잘 모른다. 어느 모듈이 중심인지, 어떤 문서가 핵심인지, 어디서 설계가 갈라지는지, 무엇이 놀라운 연결인지 알기 어렵다.

이때 Graphify의 GRAPH_REPORT.md 같은 결과물은 일종의 사전 지도 역할을 한다.

• 어떤 노드가 중심적인가
• 어떤 커뮤니티로 나뉘는가
• 어떤 연결이 의외인가
• 무엇부터 읽어야 하는가

이건 온보딩, 리팩터링, 코드 리뷰, 아키텍처 설명에서 모두 유용하다. 팀원이든 LLM이든, 맨땅에서 코드베이스를 읽는 것보다 지도를 먼저 받는 편이 훨씬 빠르다.

특히 graph 결과물을 git에 커밋해 두면, 팀 내 여러 사람이 같은 구조 지도를 공유할 수 있다. 이건 문서와 코드가 자주 어긋나는 조직에서 꽤 큰 장점이다.

10. RAG와는 어떻게 다른가

Graphify와 LLM Wiki를 RAG의 대체재라고 부르면 조금 부정확하다. 더 정확히는 RAG 앞단의 구조화 계층 혹은 RAG 없이도 쓸 수 있는 중간 지식 표현층에 가깝다.

RAG

질문 → chunk 검색 → 답변

강점은 원문 조각을 빠르게 찾아오는 데 있다.

LLM Wiki

source ingest → wiki page 갱신 → 질문 → wiki 기반 답변

강점은 해석과 요약, 비교를 누적하는 데 있다.

Graphify

source ingest → graph 생성 → report/wiki/query → 답변

강점은 관계를 명시화하고, 구조를 드러내는 데 있다.

이 차이가 중요하다. Graphify는 “더 잘 검색하는 도구”보다, 문서와 코드 사이 관계를 볼 수 있게 만드는 도구에 가깝다. 그래서 embedding이나 vector DB 같은 전형적 RAG 인프라와는 문제를 푸는 방식이 다르다.

11. 기대할 수 있는 실제 효과

이 조합에서 기대할 수 있는 효과는 크게 세 가지다.

1) 토큰 절감

한 번 비싸게 읽고 구조를 만들어 두면, 이후에는 전체 자료 대신 필요한 서브그래프나 위키 일부만 읽으면 된다. 코퍼스가 커질수록 이 차이는 더 커질 가능성이 높다.

2) 구조적 명확성

무엇이 중심이고 무엇이 주변인지, 어떤 개념이 어디에 연결되는지, 어느 파일이 실제 허브인지가 더 잘 드러난다. 이건 단순 token savings보다 더 큰 가치일 수 있다.

3) 답변 품질보다 질문 품질 향상

지식 그래프는 곧바로 정답을 주지 않을 수도 있다. 대신 더 좋은 질문을 만든다. 장기적으로는 이게 더 중요하다. 깊은 글, 깊은 설계, 깊은 리서치는 좋은 질문에서 나온다.

12. 주의할 점

물론 이 구조를 만능으로 보면 안 된다. 몇 가지 현실적인 주의점이 있다.

첫째, 그래프 관계도 검증이 필요하다

특히 INFERRED나 AMBIGUOUS 관계는 흥미로운 힌트로 봐야지, 곧바로 사실로 취급하면 위험하다. 장기 위키 운영에서는 source file, source location 같은 근거 역추적 습관이 중요하다.

둘째, privacy 경계를 알아야 한다

로컬 처리되는 층과 모델 API를 통해 의미 추출이 일어나는 층은 분리해서 봐야 한다. 사내 문서나 민감 데이터에 적용할 때는 어떤 파일이 외부 모델로 보내지는지 반드시 확인해야 한다.

셋째, 위키와 그래프 모두 lint가 필요하다

Karpathy가 LLM Wiki에서 강조한 contradiction, stale claim, orphan page, missing cross-reference, data gap 점검은 Graphify 같은 그래프 계층과 결합할 때 더 중요해진다. 구조가 커질수록 drift도 커지기 때문이다.

넷째, source of truth는 여전히 원천 자료다

위키와 그래프는 매우 강력한 인터페이스다. 하지만 최종 근거는 원문이어야 한다. 이 원칙이 무너지면 시스템은 편리해지지만 점점 덜 신뢰할 수 있게 된다.

13. 내가 보는 가장 좋은 활용 시나리오

이 조합이 특히 매력적인 곳은 세 군데다.

1) 코드베이스 온보딩 지도

새 오픈소스 프로젝트를 볼 때 README만으로는 전체 구조가 잘 안 보인다. Graphify는 god node, 커뮤니티, 놀라운 연결을 통해 “무엇이 핵심인가”를 빠르게 보여 줄 수 있다.

2) 논문·코드·블로그를 묶은 연구 위키

논문, 구현 코드, 블로그 글, 강의 노트, 스크린샷을 한 폴더에 넣고 관계를 보면 개념이 문서 간에 어떻게 이동하는지 더 잘 보인다. 이건 단순 검색보다 훨씬 연구 친화적이다.

3) 블로그 소재 발굴 시스템

단순 요약 글은 누구나 쓸 수 있다. 하지만 관계와 커뮤니티를 읽으면 “왜 이 설계가 나왔는가”, “이 프로젝트는 어떤 더 큰 흐름 위에 있는가”, “기존 패턴과 정확히 어디서 만나는가” 같은 더 좋은 글감을 만들 수 있다.

결론: Graphify는 LLM에게 주는 지도다

Karpathy의 LLM Wiki가 LLM을 단순 답변기가 아니라 지식 베이스 유지보수자로 보는 관점이라면, Graphify는 그 아이디어를 코드, 문서, 이미지, 오디오, 비디오가 섞인 실제 폴더에 적용할 수 있게 해 주는 그래프 계층이다.

내가 보기에 Graphify의 핵심 가치는 세 가지다.

1. 원천 자료를 매번 다시 읽지 않아도 되게 한다.
2. 코드와 문서 사이의 관계를 명시적인 edge로 남긴다.
3. LLM이 직접 찾은 관계와 추론한 관계를 구분하게 만든다.

LLM을 잘 쓰는 방법은 점점 “프롬프트를 잘 쓰는 법”에서 “컨텍스트 구조를 잘 설계하는 법”으로 이동하고 있다. 그런 의미에서 Graphify와 LLM Wiki는 정확히 같은 방향을 가리킨다.

raw files를 그대로 던지는 시대에서, LLM이 읽고 유지보수할 수 있는 지식 구조를 설계하는 시대로.

이제 블로그, 코드베이스, 연구 노트는 단순한 파일 묶음이 아니라, LLM이 계속 탐색하고 갱신할 수 있는 지식 그래프가 될 수 있다.