최근 안드레이 카파시(Andrej Karpathy)의 Gist 하나가 기술 커뮤니티에서 빠르게 퍼지고 있습니다. 읽고 나서 가장 먼저 든 생각은 “이 아이디어는 대부분이 생각하는 것보다 옵시디언(Obsidian)과 더 깊은 연결점이 있다"는 것이었습니다. 이 글은 그 이야기입니다.
카파시는 누구인가
AI 업계를 팔로우한다면 이 이름은 익숙할 겁니다. 하지만 잘 모르는 분들을 위해 먼저 설명하는 게 좋겠습니다.
카파시는 “대기업에서 제품을 관리하는 AI 리더” 같은 인물이 아닙니다. 그는 진정한 딥러닝 분야의 ‘자체 제작(own)’ 인물입니다.
스탠포드에서 페이-페이 리(Fei-Fei Li) 교수 밑에서 박사 학위를 받았습니다. 페이-페이 리는 ImageNet을 주도하여 사실상 현대 컴퓨터 비전의 문을 연 사람입니다. 카파시는 페이-페이 리 연구실을 떠난 후 오픈AI(OpenAI)의 공동 창업자 중 한 명이 되었습니다. 2017년에는 테슬라(Tesla)가 그를 스카우트하여 오토파일럿(Autopilot)의 시각 인식 시스템을 이끌게 했습니다.
테슬라에서의 몇 년 동안, 지금은 많은 사람이 그 결과를 알고 있습니다. 당시 테슬라는 순수 비전 접근법을 고집한 거의 유일한 자율주행 회사였습니다. 라이다(LiDAR) 없이, 오직 카메라와 신경망만으로요. 이 접근법은 당시 너무 급진적이라는 비판을 많이 받았습니다. 그 결과는 이후 모두가 알게 되었습니다.
그는 2022년 테슬라를 떠났고, 2023년 잠시 오픈AI로 돌아왔다가 다시 떠나 자신의 AI 교육 프로젝트인 karpathy.ai를 시작했습니다.
그에게서 흥미로운 점은 이력뿐만 아니라, 그가 유지하는 드문 상태입니다. 세계적 수준의 엔지니어링을 할 수 있으면서도, 일반인에게 기술의 근본 원리를 설명하는 글을 쓰고 강의를 녹화하는 데 시간을 기꺼이 쏟는다는 점입니다.
그의 nanoGPT와 micrograd는 GitHub에서 GPT와 역전파(backpropagation)를 최소한으로 재구현한 것으로, 일반인이 진정으로 이해할 수 있도록 설계되었습니다. YouTube의 CS231n 강의는 수많은 사람에게 딥러닝을 가르쳤습니다.
그래서 그가 GitHub에 “LLM으로 지식 베이스 관리하기"라는 Gist를 올렸을 때, 기술 커뮤니티에 빠르게 퍼졌습니다. 꼼꼼히 읽어볼 가치가 있다고 생각합니다.
그가 말한 것
Gist의 제목은 LLM Wiki: A pattern for building personal knowledge bases with LLMs입니다. 원본 링크:
https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f
그의 출발점은 많은 사람이 공감하는 느낌입니다. “지식 베이스는 계속 커지지만, 실제로 쓸 수 있는 것은 점점 줄어든다.”
기사를 북마크하고, Notion에 독서 노트를 작성하고, Obsidian에 노트 더미를 쌓지만, 다음에 특정 지식이 필요할 때 찾을 확률은 높지 않습니다. 못 찾는 것이 아니라, 너무 분산되어 있고 연결이 없습니다. 찾더라도 조각조각이라 스스로 조립해야 합니다.
그는 이 문제를 기존 두 가지 해결책의 한계로 돌립니다.
첫째: 북마크 방식.
원문을 그대로 넣어두고 아무것도 하지 않으며, 전적으로 검색에 의존합니다. 문제는 검색이 문서를 찾아주지, 답을 찾아주지는 않는다는 점입니다. 여전히 읽고, 이해하고, 종합해야 합니다.
둘째: RAG 방식(Retrieval-Augmented Generation).
AI에 여러 문서를 제공하면 검색하여 즉석에서 답을 생성합니다. 북마크보다 훨씬 낫지만, 항상 임시방편이며 매번 처음부터 시작하므로 축적이 없습니다.
그가 제안한 LLM Wiki는 다른 아이디어입니다. 검색할 때 AI가 임시로 정리하게 하지 말고, 대신 AI가 계속 업데이트되는 위키를 유지하도록 하자는 것입니다.
LLM Wiki 작동 방식
전체 아키텍처는 세 개의 레이어로 구성됩니다.
원자료(Raw Sources)
평소에 읽는 것들: 기사, 책, 영상 자막, 회의 노트. 이것들은 가공되지 않은 원재료로서 그대로 저장됩니다.
위키(Wiki)
Markdown 파일들의 모음으로, 각 파일은 하나의 주제, 개념, 또는 개체에 해당합니다. 예를 들어 “머신러닝 - 과적합” 페이지, “독서노트 - 게임에 몰입하다” 페이지, “인물 - 파인만” 페이지가 있을 수 있습니다.
이 파일들은 여러분이 작성하는 것이 아닙니다. AI가 작성하고 지속적으로 유지보수합니다. 새 자료가 들어올 때마다 AI가 관련 페이지를 업데이트하고, 페이지 간 상호참조(cross-reference)를 설정하며, 모순이 생기면 표시합니다.
스키마(Schema)
“이 위키가 어떻게 생겨야 하는지"를 AI에 알려주는 설정입니다. 예를 들어 각 노트에 포함해야 할 필드, 정리 방식, 고립된 노트(orphan note)의 기준, 별도 페이지가 필요한 개념 등입니다.
그리고 세 가지 핵심 작업:
수집(Ingest)
새 자료가 들어올 때마다 AI가 읽고 10~15개의 위키 페이지를 업데이트합니다. 단순히 새 페이지를 만드는 것이 아니라, 기존 내용을 업데이트하고, 상호참조를 추가하며, 추가 확인이 필요한 부분을 표시합니다.
질의(Query)
질문을 하면 AI가 위키에서 답을 종합합니다. 핵심은: 질의 자체가 가치 있는 새로운 통합을 만들어내면, AI가 그것을 다시 위키에 기록한다는 점입니다. 즉, 사용할수록 위키가 더 풍부해집니다.
린트(Lint)
그가 특별히 언급한 작업으로, 이 계획에서 가장 영리한 부분이라고 생각합니다. AI가 정기적으로 전체 위키의 건강 상태를 점검합니다:
- 서로 모순되는 내용을 가진 두 페이지가 있는가?
- 오래된 진술이 있는가?
- 다른 페이지에서 링크되지 않은 고립 페이지(orphan page)가 있는가?
- 명백히 누락된 상호참조가 있는가?
이런 작업을 수동으로 하려면 지루하고 거의 지속하기 어렵습니다. 하지만 AI에게는 순수한 잡일(grunt work)일 뿐입니다.
역할 분담은 다음과 같습니다.
인간의 역할: 선별(curation, 무엇을 포함할지 선택), 비판적 판단(이 결론이 올바른가?), 감독(정기적으로 AI 업데이트 검토)
AI의 역할: 부기(bookkeeping)—상호참조, 일관성 유지, 고립 노드 정리, 포맷팅
그가 사용한 용어: 부기(bookkeeping). 이 단어는 잘 선택되었습니다. AI가 여러분을 대신해 생각하게 하는 것이 아니라, 해야 한다는 것을 알면서도 계속 미루는 유지보수 작업을 AI에 넘기는 것입니다.
옵시디언 사용자가 특히 주목해야 할 이유
최근에 프로그래밍 커뮤니티의 친구들 중 예전에는 Obsidian에 관심 없던 사람들이 하나둘씩 사용하기 시작한 것을 발견했습니다.
이유를 물으면 대답이 거의 같습니다: AI와 함께 사용하기에 너무 적합해서. 로컬 파일, 평문 Markdown, 종속성 없음—이전에는 마니아들의 선호였지만, 이제는 장점이 되었습니다. Claude Code 같은 도구는 추가 설정 없이 Obsidian Vault를 직접 읽고 쓸 수 있으며, AI가 할 수 있는 것을 바로 할 수 있습니다.
어떤 면에서 카파시의 Gist는 이를 더 명확히 해줍니다.
저도 한동안 Obsidian을 사용해왔는데, 이 Gist를 읽고 강한 느낌이 들었습니다.
그가 설명한 위키는 본질적으로 AI가 능동적으로 유지보수하는 Obsidian Vault입니다.
생각해보세요: Obsidian의 핵심은 무엇인가요? 양방향 링크로 연결된 로컬 Markdown 파일들입니다.
LLM Wiki의 핵심은 무엇인가요? Markdown 파일들과, 링크 생성 및 유지, 내용 통합, 건강 상태 점검을 도와주는 AI입니다.
기반 매체가 정확히 동일합니다. Obsidian Vault는 LLM Wiki의 가장 자연스러운 구현체라고 할 수 있습니다.
지금 수동으로 하는 작업들—노트에 양방향 링크 만들기, MOC(Maps of Content) 작성, 정기적인 정리 및 아카이빙—이 중 상당 부분을 AI가 LLM Wiki 설계에서 “부기 작업"으로 수행할 수 있습니다.
제 예를 들어보겠습니다: 글을写完 후 양방향 링크를 생성하고 정리하는 단계는 이제 Skill이 처리합니다. AI가 제 노트 보관함을 스캔하여 관련 글을 찾고 자동으로 양방향 링크를 추가합니다. 예전에는 이 단계를 매번 미뤘지만, 이제는 거의 신경 쓰지 않습니다.
카파시의 LLM Wiki는 이를 더 발전시킵니다. 글写完 후 한 번 실행하는 것이 아니라, 전체 지식 베이스를 지속적으로 유지보수되는 상태로 두고, Ingest, Query, Lint를 모두 자동화합니다.
물론 이 접근법에 문제가 있다고 보는 의견도 있습니다.
기술 커뮤니티에서는 일부가 젯텔카스텐(Zettelkasten)과 비교했습니다. 전통적인 젯텔카스텐은 능동적으로 노트를 작성하는 행위 자체가 이해의 과정이라고 강조합니다—수집이 아니라, 쓰기를 통해 연결을 구축하는 것입니다. AI가 요약하고 연관성을 만들어준다면, 그 이해 과정이 사라지는 것 아닐까요? 깔끔한 지식 베이스는 얻지만, 머릿속에는 아무것도 남지 않는 걸까요?
이것은 진짜 질문이며, 정답은 없다고 생각합니다.
하지만 Obsidian 사용자로서 제 판단은: 이 두 가지는 모순되지 않습니다. 단, 어떤 작업이 “진정한 사고가 필요한 작업"이고 어떤 작업이 “짜증 나는 부기 작업"인지 명확히 구분한다면 말이죠.
예를 들어:
- 기사를 읽고 핵심 아이디어를 추출하고 자신의 느낌과 생각을 쓰는 것 → 이것은 사고, 스스로 해야 함
- 3개월 동안 링크되지 않은 노트가 있는지 확인하는 것 → 이것은 부기, AI에 맡겨도 전혀 문제없음
- 어떤 개념 아래 여러 출처를 종합하는 것 → AI가 초안을 작성하고, 사용자가 검토
- 여러 노트의 프론트매터(frontmatter) 필드를 유지보수하는 것 → 순수 잡일, AI가 처리
진짜 위험은 AI를 사용해서 생각을 멈추는 것이 아니라, “AI가 이 기사를 요약한 것"과 “내가 이 기사를 읽었다"는 것을 동일시하는 데 있습니다.
이것만 구분할 수 있다면, LLM Wiki 접근법은 Obsidian 사용자에게 상당히 가치 있는 확장입니다.
다음 단계
카파시의 Gist는 현재 “좋은 패턴을 제안했지만, 즉시 사용할 수 있는 도구를 제공하지는 않은” 상태입니다.
커뮤니티에서 몇몇 사람들이 다양한 방향으로 이 아이디어를 구현하기 시작했지만, 아직 초기 단계입니다.
저는 제 설정을 본격적으로 업그레이드할 계획입니다. 먼저 Obsidian 노트 보관함을 LLM Wiki 방식으로 재구성한 다음, 기존의 양방향 링크 Skill을 더 발전시켜 Ingest와 Lint 로직을 추가하여 더 완전한 Skill로 만들려고 합니다.
Claude Code + Obsidian Vault를 사용하여 처음부터 끝까지 전체 과정을 실행해볼 것입니다—무엇이 잘 통하는지, 함정은 무엇인지, 무엇을 재설계해야 하는지 알아보기 위해서요. 잘 작동하면 전체를 패키지화하여 공유할 예정입니다. 그러면 다른 사람들이 처음부터 구축할 필요 없이 바로 사용할 수 있게 됩니다.
다음 장에서 이 실습 과정을 다룰 것입니다.
요약
오늘 배운 내용:
- 카파시는 스탠포드 출신의 딥러닝 연구자로, 테슬라 오토파일럿의 순수 비전 접근법을 이끌었고, 오픈AI의 공동 창업자이며, 현재 AI 교육에 집중하고 있습니다.
- LLM Wiki는 “AI가 지식 베이스를 능동적으로 유지보수하는” 패턴으로, RAG의 수동적 검색과 대조됩니다.
- 핵심 아키텍처는 세 개의 레이어: 원자료 → 위키(Markdown 파일 모음) → 스키마(구조 정의).
- 세 가지 작업: 수집(Ingest, 수집 및 업데이트) / 질의(Query, 질의 및 기록) / 린트(Lint, 건강 상태 점검).
- 핵심 역할 분담: 인간은 선별과 판단, AI는 “부기”—상호참조, 일관성 유지, 고립 노드 정리.
핵심 포인트:
- Obsidian Vault는 그 자체로 Markdown 파일 모음이며, LLM Wiki의 매체와 매우 일치하여 거의 가장 자연스러운 구현체입니다.
- 지금 수동으로 만드는 양방향 링크와 MOC는 바로 LLM Wiki에서 AI가 자동으로 유지하는 상호참조입니다.
- “AI가 생각을 대신한다"는 걱정은 일리가 있지만, 그것과 AI가 “부기"를 하는 것은 다릅니다—혼동하지 마세요.
- 이 패턴은 현재 즉시 사용 가능한 도구가 없으며, 직접 구축해야 합니다.
- 다음 장에서는 실습 구현 과정을 다룰 것입니다. 잘 작동하면 Skill로 패키지화하여 공유하겠습니다.