이번 주 가장 큰 반향을 일으킨 건, Karpathy가 공유한 'LLM으로 개인 위키 만드는 법'이라는 아이디어인거 같아요.
2백만 뷰를 넘기면서, AI 시대에 지식을 어떻게 정리해야 하는지에 대한 논의가 활발해졌습니다.
포커스
AI가 실행을 맡을수록, 인간에게 남는 역할은 '지식을 설계하는 것'이 되고 있습니다.
코드를 공유하지 말고 아이디어를 공유하라
Karpathy가 공유한 LLM 기반 개인 지식 베이스 구축법이 큰 반향을 일으켰습니다.
구조는 단순합니다. 논문, 아티클, 코드 같은 raw 데이터를 폴더에 모아두면, LLM이 이걸 읽고 마크다운 위키로 정리하는 거죠. Obsidian 같은 도구로 보면서 직접 편집하고, 위키가 충분히 커지면 에이전트에게 Q&A를 맡기는 구조입니다.
흥미로운 건 별도 RAG(검색 증강 생성, 외부 데이터를 LLM에 연결하는 기법) 시스템 없이도 100개 문서, 40만 단어 규모까지는 LLM 자체 인덱스로 충분하다는 거구요.
2백만 뷰를 넘긴 후속 트윗에서 한 말이 더 인상적입니다. "이 시대엔 코드나 앱을 공유하는 게 아니라 아이디어를 공유하면 된다. 각자의 에이전트가 현지화해서 실행한다."
실제로 이 아이디어에서 영감을 받아, Claude Code용 지식 베이스 컴파일 플러그인을 만든 개발자도 나왔습니다. 컨텍스트 토큰을 84% 줄이면서도 에이전트가 필요한 정보에 접근할 수 있게 하는 구조라고 합니다.
아이디어 하나가 공유되고, 각자의 환경에서 에이전트가 구현하는 흐름이 실시간으로 벌어진 셈이죠.
grep이 attention을 이기는 이유
Karpathy의 위키가 왜 잘 작동하는지를 설명해주는 연구 결과도 나왔습니다.
Duke 대학 연구에 따르면, 코딩 에이전트가 밀리언 토큰 컨텍스트 윈도우(한 번에 읽을 수 있는 텍스트 길이)보다 긴 문서 처리에서 17.3% 더 나은 성능을 보인다고 합니다. 이유가 재밌는데요. grep(텍스트 검색)과 sed(텍스트 편집) 같은 전통적인 도구가 모델의 attention 메커니즘보다 더 정확한 검색 도구이기 때문이라는 겁니다.
쉽게 말하면, 정보를 한꺼번에 다 읽히는 것보다, 잘 정리해두고 필요한 부분만 찾아서 읽게 하는 편이 낫다는 거죠.
이 원리를 실전에 적용한 사례도 있습니다. raw 폴더 전체를 knowledge graph(지식 그래프)로 컴파일해서 71.5배 토큰 절감을 달성했다는 보고가 올라왔구요. 벡터 데이터베이스를 완전히 제거하고 트리 구조로 문서를 인덱싱하는 PageIndex라는 접근도 나왔습니다.
방향은 같습니다. 모델에게 더 긴 컨텍스트를 주는 게 아니라, 더 좋은 구조를 주는 쪽이 이기고 있다는 거죠.
서기에서 시스템 설계자로
이런 흐름을 관통하는 하나의 진단이 있습니다. 인간의 역할이 정보를 기록하는 '서기'에서, 지식의 아키텍처를 설계하는 '시스템 설계자'로 전환되고 있다는 거죠.
에이전트 도구들의 방향도 이걸 뒷받침합니다.
