Hacker News, Karpathy의 "LLM Wiki" 패턴에 주목
Original: LLM Wiki – example of an "idea file" View original →
RAG 대신 “계속 자라는 wiki”라는 제안
Andrej Karpathy가 2026년 4월 4일 공개한 LLM Wiki gist는, 대부분의 document workflow가 query 시점마다 raw 파일을 다시 찾고 재조합하는 RAG에 머물러 있다고 지적한다. 크롤링 시점의 Hacker News 토론은 274점, 89개 댓글 이었고, discussion의 핵심은 이 아이디어가 단순 note-taking을 넘어 agent workflow 설계 패턴으로 읽힌다는 점이었다. Karpathy의 제안은 raw sources 위에 LLM이 직접 유지·보수하는 markdown wiki를 두고, 그 wiki가 시간이 지날수록 축적된 synthesis를 보존하게 하자는 것이다.
핵심 차이는 “매 질문마다 다시 추론하는 retrieval”이 아니라, 한 번 정리한 지식을 계속 유지하는 compiled artifact를 만드는 데 있다. 새 source가 들어오면 agent는 단순 indexing으로 끝내지 않고, entity page를 업데이트하고, topic summary를 고치고, 기존 주장과 충돌하는 내용을 표시하며, cross-reference를 연결한다. 질문에 대한 답도 일회성 chat output으로 끝내지 않고 wiki page로 다시 편입할 수 있다. 즉 source ingest와 user exploration이 둘 다 knowledge base를 더 풍부하게 만드는 구조다.
세 개의 계층과 세 가지 operation
Karpathy는 구조를 세 계층으로 나눈다. 첫째는 immutable한 raw sources 다. 기사, 논문, 이미지, 데이터가 여기에 쌓인다. 둘째는 LLM이 쓰고 갱신하는 wiki 다. summary, entity page, concept page, comparison, synthesis가 모두 이 층에 속한다. 셋째는 schema 로, Codex의 AGENTS.md나 Claude Code의 CLAUDE.md처럼 wiki 구조와 workflow 규칙을 agent에게 지시하는 문서다. 이 schema가 없으면 agent는 generic chatbot에 머무르지만, schema가 있으면 disciplined wiki maintainer가 된다.
operation도 세 가지로 정리된다. Ingest 에서는 새 source 하나가 들어올 때 summary page, index, 관련 concept page, log까지 여러 파일이 함께 바뀐다. Query 에서는 agent가 wiki를 먼저 찾아 답을 만든 뒤, 그 결과를 다시 wiki page로 저장할 수 있다. Lint 는 오래된 주장, orphan page, 빠진 cross-link, 모순된 서술을 검사해 wiki를 건강하게 유지하는 단계다. index.md와 log.md를 분리해 content view와 chronological view를 동시에 확보하는 설계도 흥미롭다.
왜 지금 의미가 큰가
이 패턴이 주목받는 이유는 LLM을 검색 엔진이나 one-shot summarizer가 아니라 지속적으로 유지보수하는 editor 로 본다는 데 있다. Karpathy는 Obsidian을 사실상의 IDE로, LLM을 programmer로, wiki를 codebase로 비유한다. 이는 personal research, reading companion, team wiki, due diligence, competitive analysis처럼 시간이 지날수록 정보가 쌓이는 작업에 잘 맞는다. optional tool로 qmd 같은 on-device search를 붙일 수 있다는 제안도 있어, 작은 markdown repo에서 시작해 점차 기능을 확장하는 경로가 비교적 현실적이다.
결국 LLM Wiki는 “RAG를 더 잘하자”가 아니라 “knowledge maintenance 자체를 agent에게 넘기자”는 제안이다. 사람이 source selection과 판단에 집중하고, cross-reference와 bookkeeping은 LLM이 맡는 구조가 가능해진다면, 오래 유지되지 못했던 personal wiki와 team wiki의 경제성이 달라질 수 있다.
Related Articles
Google I/O 2026의 핵심은 Gemini를 앱 안의 챗봇보다 넓은 실행 계층으로 밀어 올리는 흐름이다. Gemini 3.5 Flash는 API와 Antigravity, Search, Gemini app에 풀렸고, Gemini Omni는 video 생성과 편집을 전면에 세웠다.
Zai의 ZCube 사례에서 관심은 새 GPU가 아니라 같은 GPU·같은 software stack으로 throughput 15%와 first-token tail latency 40.6% 개선을 냈다는 점에 모였다.
모델을 하나 고르는 시대보다, 요청마다 비용·속도·성능을 갈아타는 운영층에 돈이 몰리고 있다. OpenRouter는 주간 25조 토큰, 400개 이상 모델, 800만 명 이상 사용자라는 숫자로 $113 million Series B를 끌어냈다.
Comments (0)
No comments yet. Be the first to comment!