IVGraph
아이디어의 출발점
2026년 4월 4일, OpenAI 공동 창립자이자 Tesla의 전 AI 책임자인 Andrej Karpathy가 llm-wiki.md라는 짧은 gist를 공개했어요. 도구나 저장소가 아니라 아이디어를 담은 파일이에요. 자신이 쓰는 LLM 에이전트(Claude Code, Codex 등)에 전달하면 에이전트가 사용자와 함께 구체적인 구현 방법을 구상하도록 작성됐어요. 몇 달 만에 스타를 5,000개 넘게 받았고, 커뮤니티에서 여러 구현 사례가 나왔으며, "LLM 위키"는 사람들이 적극적으로 검색하는 용어가 됐어요.
gist에 담긴 한 줄 소개는 이래요. "Obsidian은 IDE, LLM은 프로그래머, 위키는 코드베이스" — 자료를 고르고 질문하는 일은 계속 사용자가 맡고, 작성과 정리, 상호 참조는 모두 LLM이 처리해요.
LLM 위키 vs RAG: 한 번 컴파일하기 vs 끝없이 검색하기
AI와 문서를 결합한 대부분의 제품은 RAG(검색 증강 생성) 방식으로 작동해요. 파일을 업로드하면 질문할 때 모델이 관련 부분을 찾아 그 자리에서 답변을 만들어 내요. 효과는 있지만, 질문할 때마다 처음부터 다시 시작해요. 질문과 질문 사이에 쌓이는 것은 없어요.
LLM 위키는 이 방식을 뒤집어요. 새 자료가 들어오면 LLM이 즉시 읽고, 중요한 내용을 추출해 기존 페이지 네트워크에 통합해요. 개체 페이지를 업데이트하고, 요약을 수정하고, 이전 자료와 모순되는 부분을 표시하죠. 지식은 한 번 컴파일한 뒤 최신 상태로 유지해요. 그래서 답변할 때마다 가공되지 않은 조각이 아니라 이미 종합된 전체 내용을 출발점으로 삼아요.
| RAG | LLM 위키 | |
|---|---|---|
| 정보를 종합하는 시점 | 질문할 때마다 | 자료를 반영할 때 한 번 |
| 질문과 질문 사이 | 아무것도 쌓이지 않음 | 지식이 쌓이며 더 풍부해짐 |
| 모순 | 다시 발견하거나 놓침 | 자료를 반영할 때 표시 |
| 좋은 답변 | 채팅 기록 속으로 사라짐 | 위키에 페이지로 다시 저장 |
세 가지 계층
gist의 구조는 의도적으로 최소한의 요소만으로 설계돼 있어요.
- 원본 자료 — 기사, 논문, 녹취록, 데이터 파일이에요. 변경하지 않는 자료로, LLM은 읽기만 하고 절대 수정하지 않아요.
- 위키 — LLM이 생성한, 서로 연결된 페이지예요. 요약, 개체 페이지, 개념 페이지, 비교 등이 포함돼요. 이 계층은 전적으로 LLM이 관리하고, 사용자는 읽어요.
- 스키마 — 위키의 구조와 자료 반영, 답변, 유지 관리 시 행동 방식을 에이전트에 알려 주는 규칙 파일(CLAUDE.md, AGENTS.md)이에요. 일반적인 챗봇을 체계적인 사서로 바꿔 주는 요소예요.
일상적으로 위키는 세 가지 작업으로 운영돼요. 자료 반영(자료를 넣으면 LLM이 통합해요. 기사 하나가 10–15개 페이지에 영향을 줄 수 있어요), 질의(질문하면 좋은 답변은 새 페이지로 다시 저장돼요), 린트(모순, 더 이상 최신 정보가 아닌 주장, 들어오는 링크가 없는 고립 페이지를 정기적으로 점검해요)예요.
LLM 위키 vs 세컨드 브레인 vs 지식 베이스
이 용어들은 의미가 겹치고, 검색 결과에서도 끊임없이 혼용돼요. 다음처럼 구분하면 명확해요.
| 용어 | 의미 | 관리 주체 |
|---|---|---|
| 지식 베이스 | 체계적으로 정리된 정보 저장소라면 무엇이든 | 수고를 들여 관리하는 사람 |
| 세컨드 브레인 | 배운 내용을 기록하고 정리하는 개인적인 실천 방식 | 사용자 |
| LLM 위키 | LLM이 컴파일하고 최신 상태로 유지하는 지식 베이스 | LLM |
마지막 열이 핵심이에요. 사람들이 위키와 세컨드 브레인을 포기하는 이유는 상호 참조를 업데이트하고 기존 주장과 새 자료 사이의 불일치를 해소하는 관리 부담이 얻는 가치보다 더 빠르게 커지기 때문이에요. LLM은 지루해하지 않아요. 수동 시스템이 조용히 사라지는 곳에서도 이 방식이 계속 유지되는 이유예요.
만드는 방법
지식이 이미 어디에 저장돼 있는지에 따라 세 가지 실용적인 방법을 선택할 수 있어요.
- Markdown 파일 + Obsidian — Karpathy가 처음 사용한 구성이에요. 원본 자료 폴더, 위키 페이지 폴더, 규칙을 담은 CLAUDE.md, 터미널에서 실행하는 에이전트로 구성돼요. Obsidian의 클리퍼로 기사를 가져오고, 그래프 뷰로 점점 커지는 위키의 구조를 확인해요.
- 노션 + MCP — 메모와 데이터베이스가 이미 노션에 있다면 아무것도 옮길 필요가 없어요. 노션의 MCP 서버를 통해 에이전트를 연결하고 페이지를 직접 읽고 쓰도록 하면 돼요. 전체 과정은 노션용 LLM 위키: Claude 세컨드 브레인 + 3D 지식 그래프에 정리해 뒀어요.
- 팀 위키 — 같은 순환 과정에 회의 녹취록, 문서, 채팅 스레드를 넣고 사람이 업데이트를 검토하는 방식이에요. 팀에서 아무도 맡고 싶어 하지 않는 유지 관리를 LLM이 처리하므로 위키가 최신 상태로 유지돼요.
지식 그래프의 역할
위키는 텍스트지만, 그 구조는 그래프예요. 페이지는 노드이고 링크는 간선이에요. Karpathy의 gist에서도 커져 가는 위키의 구조를 살펴보는 가장 좋은 방법으로 그래프 뷰를 추천해요. 어떤 페이지가 허브가 됐는지, 어떤 페이지가 고립돼 있는지, 어디에 군집이 형성되는지 볼 수 있죠. 린트 작업은 말 그대로 그래프의 상태를 점검하는 일이에요.
LLM 위키가 노션에 있다면 이 점이 더욱 중요해요. 노션에는 기본 제공 그래프 뷰가 없기 때문이에요. IVGraph는 이 빈자리를 채워 줘요. 워크스페이스의 모든 페이지, 백링크, 데이터베이스 관계를 상호작용 가능한 3D 지식 그래프로 시각화하므로, LLM이 만드는 위키가 실제로 형태를 갖춰 가는 모습을 볼 수 있어요. 에이전트도 IVGraph LLM API를 통해 같은 구조를 프로그래밍 방식으로 조회할 수 있어요.
자주 묻는 질문
LLM 위키란 쉽게 말해 무엇인가요?
AI가 사용자를 위해 만들고 관리하는 지식 베이스예요. 자료와 질문을 주면 AI가 페이지를 작성하고, 서로 연결하고, 업데이트해요. 한 번 컴파일하고 최신 상태로 유지하는 방식으로, 질문할 때마다 원본 파일을 다시 검색하는 방식과는 반대예요.
GitHub에서 Karpathy의 LLM 위키는 어디에 있나요?
저장소가 아니라 2026년 4월 4일에 공개된 gist인 llm-wiki.md예요. 애초에 설치할 것이 없도록 설계됐어요. 자신이 쓰는 에이전트에 아이디어를 붙여 넣고 함께 자신만의 버전을 만들면 돼요.
LLM 위키와 세컨드 브레인 중 무엇이 필요한가요?
둘은 경쟁 관계가 아니에요. 세컨드 브레인은 실천 방식이고, LLM 위키는 LLM이 유지 관리를 맡았을 때 그 실천 방식이 취하는 형태예요. 이미 메모를 관리하고 있다면 이를 관리할 에이전트를 추가하는 것이 업그레이드 방법이에요. 역할이 어떻게 나뉘는지는 위 표를 참고해 주세요.
Obsidian이 꼭 필요한가요?
아니요. LLM이 읽고 쓸 수 있는 저장소라면 무엇이든 가능해요. 로컬 마크다운 파일이 가장 가벼운 선택이고, 지식이 이미 노션에 있다면 MCP를 통한 노션 연결이 자연스러운 선택이에요. 데이터베이스와 협업 기능까지 함께 사용할 수 있어요.