
왜 우리는 맨날 개인 위키를 만들고 포기할까요?
노션으로 지식 베이스를 만들었다가 한 달 뒤 손 놓은 경험, 있으시죠?
옵시디언도 써봤고, 에버노트도 써봤고, 로그 리서치도 써봤습니다. 근데 어느 순간부터 정리하는 시간이 너무 많이 드는 거예요. 글 하나 추가할 때마다 기존 내용과 비교하고, 태그 달고, 연결 고리 업데이트하고, 오래된 내용도 다시 검토하고.
이게 반복되다 보면 어느 순간 위키 자체가 부담이 됩니다. 결국 열지도 않게 되죠.
저는 오랫동안 이게 의지 문제라고 생각했어요. 근데 아닙니다. 구조 문제였습니다.
개인 위키가 실패하는 이유는 지식이 없어서가 아닙니다. 유지하는 데 드는 에너지, 전문 용어로 '북키핑(Bookkeeping)' 비용이 너무 크기 때문입니다. 그리고 2026년 4월, 이 문제를 구조적으로 해결하는 개념이 등장했습니다.
1,600만 뷰를 기록한 트위터 한 줄
테슬라 AI 전 디렉터이자 오픈AI 공동 창업자인 안드레 카파시(Andrej Karpathy)가 2026년 4월에 짧은 글 하나를 올렸습니다.
"최근 나는 코드를 다루는 것보다 지식을 다루는 데 훨씬 많은 토큰을 쓰고 있다."
이 한마디가 1,600만 뷰를 넘기며 AI 커뮤니티 전체에 파장을 일으켰습니다. 그가 공유한 깃허브 Gist는 12시간 만에 별 2,100개 이상을 받았고요.
왜 이렇게 반응이 컸을까요?
그가 제안한 건 새로운 앱도, 라이브러리도, SaaS 제품도 아니었습니다. 단 하나의 마크다운 파일, 즉 '아이디어 파일'이었습니다. Claude Code나 OpenAI Codex 같은 에이전트에 복사해 붙여넣으면, AI가 그 패턴을 내 상황에 맞게 인스턴스화해주는 방식이었죠.
기술이 아니라 패턴을 공개한 겁니다. 그리고 그 패턴이 기존 AI 지식관리 방식을 완전히 뒤집는 것이었기 때문에 반응이 폭발적이었습니다.
우리가 지금 쓰는 RAG 방식의 진짜 문제
많은 사람이 AI 지식관리 도구로 RAG(검색 증강 생성) 방식을 씁니다. 노트북LM이나 ChatGPT 파일 업로드 기능이 대표적이에요.
RAG는 단순합니다. 파일을 올려두고, 질문하면 AI가 관련 내용을 찾아서 답해줍니다. 도서관 사서처럼요.
근데 결정적인 문제가 있습니다. 모델이 지식을 쌓지 않습니다. 오늘 질문해서 얻은 통찰이 내일 다시 같은 질문을 하면 처음부터 다시 도출됩니다. 3월에 읽은 글과 10월에 읽은 글 사이의 연결 고리도 자동으로 만들어지지 않죠. 매번 원자료에서 다시 '발견'하는 방식이라 지식이 복리로 쌓이지 않는 구조입니다.
요약하면 RAG는 답변을 만들어내지만, 지식을 쌓지는 않습니다.
LLM 위키는 완전히 다릅니다: 컴파일하는 방식
카파시가 제안한 LLM 위키는 접근법 자체가 다릅니다. 원문이 들어올 때 AI가 직접 구조화된 마크다운 위키를 만들고, 새 정보가 들어오면 기존 위키를 지속적으로 통합, 정리, 업데이트하는 방식입니다. 새 소스가 단순 저장되는 게 아니라, 구조화된 페이지로 합성되고, 기존 개념과 연결되고, 사전 지식과 비교되어 지식 자산으로 쌓입니다.
카파시는 이렇게 표현했습니다. "Obsidian은 IDE고, LLM은 프로그래머고, 위키는 코드베이스다." 위키를 직접 쓰는 일은 거의 없습니다. 사람은 질문하고 탐색하며, LLM이 데이터베이스 유지라는 반복 작업을 대신합니다.
AI가 사서 역할이 아니라 편집자 역할을 하는 것입니다. 지식이 복리로 증식하는 구조로 바뀌는 거죠.
3레이어 아키텍처, 이렇게 생겼습니다
LLM 위키 프레임워크는 세 가지 레이어로 구성됩니다. 첫 번째는 원문 소스(Raw Sources)로, PDF, 아티클, 회의 전사본, 이미지 등 수정하지 않는 불변의 진실 저장소입니다. 두 번째는 위키(Wiki)로, LLM이 완전히 관리하는 마크다운 파일 디렉토리입니다. 요약, 개념 페이지, 타임라인이 여기에 담깁니다. 세 번째는 스키마(Schema)로, CLAUDE.md 같은 설정 파일입니다. AI 에이전트에게 위키를 어떻게 구조화할지, 새 파일은 어떻게 인제스트할지, 답변은 어떻게 포맷할지를 알려주는 규칙 문서입니다.
이 세 레이어가 조합되면, 폴더 하나가 곧 살아있는 지식 베이스가 됩니다.
4가지 오퍼레이션으로 매일 운영하는 방법
카파시가 공개한 운영 방식은 네 가지입니다.
인제스트(Ingest)는 새 자료를 raw 폴더에 넣고 LLM에게 처리를 지시하는 단계입니다. LLM이 읽고, 요약하고, 관련 페이지를 업데이트하고, 새 개념이면 페이지를 새로 만듭니다.
쿼리(Query)는 위키에 질문을 던지는 단계입니다. LLM이 인덱스와 요약을 보고 관련 페이지를 찾아 답변을 생성합니다. 마크다운 아티클, 슬라이드, 차트 등 출력 형식도 지정할 수 있어요.
린트(Lint)는 주기적으로 전체 위키를 감사하는 단계입니다. 페이지 간 모순, 오래된 정보, 연결이 없는 고아 페이지 등을 점검합니다.
아카이브(Archive)는 쿼리 결과를 다시 위키에 저장하는 단계입니다. 좋은 답변이 사라지지 않고 위키 자체를 더 풍부하게 만들어줍니다.
RAG보다 70배 더 효율적이라는 분석도 있습니다
Andrej Karpathy's LLM Wiki는 벡터 데이터베이스 대신 일반 텍스트 파일을 사용하며, RAG 대비 약 70배 더 효율적이라는 분석이 나왔습니다.
물론 이 수치는 수백 개 규모의 개인 지식베이스에 한정된 이야기입니다.
수만 개 이상 파일을 다루는 기업용 대규모 문서 검색에는 RAG 인프라가 여전히 필요합니다. 하지만 개인이나 소팀 수준이라면 LLM 위키가 훨씬 단순하고 정확합니다. 벡터 DB 셋업, 임베딩, 청킹 파이프라인, 확률적 검색, 이런 복잡한 인프라가 필요 없습니다. 마크다운 파일 폴더 하나면 됩니다.
옵시디언을 뷰어로 쓰면 더 강력해집니다
카파시는 옵시디언을 실제 작업 공간 예시로 언급합니다. 옵시디언의 그래프 뷰는 모든 위키 페이지를 노드로, 위키 링크를 엣지로 표현해 지식 연결망을 시각화해줍니다. 허브 페이지는 더 크게, 고아 페이지는 독립된 노드로 표시됩니다. 덕분에 지식의 밀도와 공백을 한눈에 볼 수 있습니다.
LLM이 코드를 다루듯 위키를 관리하고, 사람은 그 결과물을 그래프로 탐색하는 그림입니다.
주의할 점: 사고까지 AI에게 맡기면 안 됩니다
카파시 본인도, 이 개념을 분석한 많은 전문가들도 공통적으로 경고하는 부분이 있습니다.
북키핑은 AI에게 맡겨도 됩니다. 하지만 무엇을 읽을지, 무엇이 중요한지, 어떤 질문을 던질지는 사람이 결정해야 합니다.
개념을 연결하는 사고, 맥락을 판단하는 능력, 이것이 학습의 본체입니다. 이것까지 AI에게 위임하면 잘 정리된 정보 창고는 생기지만, 지식이 쌓이는 건 아닙니다. 북키핑은 AI가, 사고는 내가. 이 분업이 제대로 이루어질 때 위키는 비로소 진짜 지식이 됩니다.
나한테 맞는 LLM 위키, 어떻게 시작하면 될까요?
처음부터 모든 지식을 담으려 하면 또 실패합니다. 좁은 도메인부터 시작하는 게 핵심입니다.
먼저 주제 하나를 정하세요. 보험 GA 규제 동향이든, 헬스케어 CRM 트렌드든, 매일 접하는 좁은 영역 하나면 충분합니다.
그다음 스키마 파일을 작성합니다. LLM에게 어떻게 정리할지 규칙을 알려주는 문서입니다. 페이지 형식, 태그 규칙, 링크 방식 등을 정의하면 됩니다.
Claude Code, OpenAI Codex 같은 에이전트에 카파시의 원본 Gist 내용을 붙여넣고, "이 아이디어 파일을 읽고 내 위키 스키마 파일을 만들어줘"라고 지시하면 AI가 CLAUDE.md를 작성하고, wiki/index.md와 wiki/log.md를 초기화한 뒤 "첫 번째 소스를 넣어주세요"라고 답합니다.
그다음은 아티클 하나를 넣어보고 위키가 어떻게 생성되는지 확인하고, 스키마를 다듬고, 반복하면 됩니다.
마무리
LLM 위키의 핵심 가치는 단 하나입니다. 지식 관리의 유지 비용을 거의 0에 가깝게 낮추는 것입니다.
정보를 넣으면 자동으로 정리되고, 연결되고, 업데이트됩니다. 사람이 할 일은 무엇을 넣을지 결정하고, 중요한 질문을 던지는 것입니다.
개인 위키를 만들고 포기했던 경험이 있다면, LLM 위키는 그 문제를 구조적으로 해결하는 접근입니다. 의지의 문제가 아니라 구조의 문제였다는 것, 이제는 그 구조를 AI가 대신 유지해줄 수 있다는 것. 이게 카파시가 던진 핵심 메시지입니다.
북키핑은 AI가, 사고는 내가. 서류 정리는 AI에게, 무엇을 담을지는 나에게. 이 분업이 제대로 이루어질 때 지식은 비로소 복리로 쌓입니다.
'IT > AI' 카테고리의 다른 글
| 🤖 클로드 코드(Claude Code) 200% 활용법, 7단계 테크트리로 완성하기 (0) | 2026.05.24 |
|---|---|
| 🧠 AI 시대, 진짜 폭등할 가치는 '지식'이 아니라 '관계'였다 (0) | 2026.05.23 |
| 🤖 Qwen3.6이 왔다! 오픈소스 AI가 Claude를 이긴다고? (1) | 2026.05.23 |
| 🤖 AI 에이전트, 이렇게 쓰면 왜 자꾸 실패할까? (0) | 2026.05.22 |
| 🔍 젠슨 황이 말하지 않은 것들 — Anthropic, OpenAI, 그리고 엔비디아의 진짜 전략 (0) | 2026.05.22 |