LLM Wiki, 직접 열어보니 — ‘자동 기억’이라는 오해와 몇 줄짜리 스키마#

2026-06-28

지난 글 하네스 스킬이라 부르기로 했다에서, 필자는 닫아 두었던 문을 열어 외부의 검증된 패턴을 하나씩 들여다보기로 했습니다. 그리고 침습도가 낮은 것부터 흡수하겠다고 적었습니다. 그 첫 번째 대상이 LLM Wiki였습니다. 이번 글은 그 다짐을 실제로 옮긴 기록입니다. 개념만 알던 것을 직접 저장소에 적용해 보았고, 그 과정에서 두 가지 오해를 바로잡게 되었습니다.

LLM Wiki가 뭐였더라#

LLM Wiki는 Andrej Karpathy(안드레이 카파시)가 2026년 4월에 제안해 화제가 된 패턴입니다. 한 줄로 말하면 “원본 문서 더미를, LLM이 직접 관리하는 위키백과로 바꿔 두는 것” 입니다.

이것이 왜 새로운지는 RAG(Retrieval-Augmented Generation, 질문할 때마다 원본에서 관련 조각을 검색해 답을 만드는 방식)와 비교하면 분명해집니다. RAG는 질문이 들어올 때마다 원본을 다시 뒤져 답을 짜냅니다. 어제 한 분석을 오늘 또 똑같이 반복하고, 문서 사이의 연결 관계는 매번 새로 발견해야 합니다. 지식이 쌓이지 않습니다.

LLM Wiki는 반대입니다. 새 자료가 들어오면 LLM이 그것을 읽고, 핵심을 추출해, 이미 있는 위키에 통합합니다. 개념 페이지를 갱신하고, 요약을 고치고, 새 자료가 기존 주장과 충돌하면 그 자리를 표시합니다. 지식을 한 번 컴파일해 두고 계속 최신 상태로 유지하므로, 시간이 갈수록 위키가 풍부해집니다. 카파시의 비유를 빌리면, Obsidian이 IDE이고 LLM이 프로그래머이며 위키가 코드베이스입니다.

여기까지는 지난 글에서 정리한 내용입니다. 문제는 직접 적용하려고 들여다보기 시작하면서부터였습니다.

첫 번째 오해 — “알아서 기억이 갱신된다”#

필자가 얼핏 들었던 인상은 “LLM Wiki를 깔아 두면 에이전트가 알아서 기억을 자동으로 쌓고 갱신해 준다"는 것이었습니다. 마치 백그라운드에서 스스로 도는 자율 메모리처럼 말입니다. 그런데 원본 문서를 직접 읽어 보니, 이것은 사실과 달랐습니다.

카파시의 원본 패턴은 철저히 사람이 개입하는(human-in-the-loop) 방식입니다. 그가 직접 쓴 문장은 이렇습니다. “나는 소스를 하나씩 넣으며 계속 관여하는 편이다 — 요약을 읽고, 갱신을 확인하고, 무엇을 강조할지 LLM에게 지시한다.” 그리고 “사람의 일은 소스를 큐레이션하고, 분석 방향을 정하고, 좋은 질문을 던지는 것"이라고 못 박습니다.

즉 위키는 사람이 “이 자료 정리해줘”, “한번 점검해줘"라고 말을 거는 순간 동작합니다. 스스로 돌면서 기억을 갱신하는 마법이 아닙니다. 흥미롭게도 카파시가 일부러 대비시킨 대상이 바로 “쓸수록 알아서 똑똑해진다는 AI”, 즉 암묵적이고 마법 같은 백그라운드 메모리입니다. LLM Wiki는 정반대로 명시적(explicit)이고 파일 기반이라는 점을 강점으로 내세웁니다.

그렇다면 “자동"이라는 인상은 어디서 왔을까요. 자동화되는 것은 트리거가 아니라 노동입니다. 한 번 “정리해줘"라고 하면, 그 뒤의 귀찮은 유지보수가 전부 자동입니다.

필자가 이 패턴에서 가장 끌린 대목이 바로 여기, ‘무엇이 자동화되는가’였습니다. 카파시는 지식베이스 유지의 진짜 병목이 읽기나 사고가 아니라 부기(bookkeeping, 장부를 적듯 자료를 빠짐없이 기록하고 갱신하는 일) 라고 짚습니다. 사람이 위키를 포기하는 이유는 이 부기 부담이 가치보다 빨리 늘어나기 때문입니다. LLM은 지치지 않고 한 번에 열다섯 개 파일을 고칩니다. 유지 비용이 0에 수렴하므로 위키가 살아남습니다.

정리하면, “알아서 갱신되는 자동 기억"은 오히려 카파시가 거리를 둔 쪽이고, 진짜 가치는 사람이 방향을 잡고 LLM이 부기를 떠맡는 분업에 있습니다.

두 번째 오해 — “뭔가 특별한 기술이 있겠지”#

어디선가 “LLM Wiki, 별거 아니야. 몇 줄짜리 글이 다야"라는 평을 들은 적이 있습니다. 처음엔 폄하처럼 들렸는데, 원본을 읽고 나니 기술적으로는 정확한 지적이었습니다.

LLM Wiki에는 별도 라이브러리도, 벡터 데이터베이스도, 특별한 런타임도 없습니다. 구성 요소는 단 두 가지입니다. 하나는 폴더 컨벤션(원본을 담는 곳과 위키 페이지를 담는 곳), 다른 하나는 스키마(schema) 라 불리는 운영 지침 문서 한 장입니다. 이 스키마가 LLM에게 “이 위키를 어떻게 구성하고, 무슨 규칙으로 갱신하라"고 알려 줍니다. 잡담하는 챗봇을 규율 있는 위키 관리자로 바꾸는 것이 바로 이 한 장입니다.

그래서 “몇 줄짜리 글이 다야"는 맞습니다. 다만 가치가 그 몇 줄에 있는 게 아니라, 그 규칙을 따라 시간이 지나며 쌓이는 결과물에 있을 뿐입니다. 마법 같은 기술은 없다는 회의적 시선은 옳습니다. 다만 진짜 효과는 기술이 아니라, 그것을 꾸준히 운영하며 지식을 축적하는 데서 나옵니다.

여기서 한 가지가 더 분명해졌습니다. 카파시가 공개한 것은 ‘그대로 가져다 쓰는 완성품’이 아니라 ‘아이디어 파일(idea file)’ 입니다. 그는 문서 첫머리에 이렇게 적었습니다. “이것은 아이디어 파일이며, 당신의 LLM 에이전트에 복사해 붙여 넣도록 설계되었다. 목표는 큰 그림을 전달하는 것이고, 구체적인 것은 당신의 에이전트가 당신과 협력해 만들어 낼 것이다.” 그리고 문서 말미에서 “이 문서는 의도적으로 추상적이다. 정확한 디렉토리 구조, 스키마 규칙, 페이지 형식, 도구는 당신의 도메인과 취향, 그리고 당신이 쓰는 LLM에 따라 달라진다"고 다시 한번 강조합니다.

다시 말해 카파시의 gist는 메타 템플릿입니다. 그것을 에이전트에 붙여 넣으면, 에이전트가 사용자와 대화하며 사용자의 도메인에 맞는 실제 스키마를 만들어 냅니다. 응용은 각자의 몫이라는 뜻입니다. 이 점은 지난 글의 또 다른 통찰과도 맞닿습니다 — 이 시대에는 코드가 아니라 아이디어를 공유하면, 나머지는 에이전트가 채웁니다.

그래서 직접 적용해 보았다#

오해를 걷어 내고 나니, 적용 방법은 오히려 단순했습니다. 이 블로그 저장소에 LLM Wiki를 다음과 같이 들였습니다.

먼저 카파시의 3계층 구조를 그대로 따라 wiki/ 디렉토리를 만들었습니다.

여기에 색인 역할의 index.md(질의할 때 가장 먼저 읽는 카탈로그)와 시간순 기록인 log.md를 더했습니다. 그리고 빈 껍데기로 두지 않으려고, 이번에 조사한 LLM Wiki 자체를 첫 번째 소스로 넣어 raw → pages → index → log 한 바퀴가 실제로 돌아가게 했습니다.

핵심은 이 다음입니다. 매번 긴 지시를 반복해 타이핑하지 않도록, 스키마는 파일로 두고 진입점에서 한 줄로 참조하게 했습니다. 즉 CLAUDE.md에 “위키를 다룰 때는 wiki/SCHEMA.md를 따른다"는 한 줄을 추가한 것입니다. CLAUDE.md는 항상 컨텍스트에 자동 로드되므로, 이 한 줄만으로 에이전트가 위키 운영 규칙을 늘 알고 있게 됩니다. 사실 이 블로그가 이미 .cursor/rules/나 .memory/를 같은 방식으로 참조하고 있어서, 결이 잘 맞았습니다.

마지막으로 수집(ingest) / 질의(query) / 점검(lint) 세 작업을 정형화한 /wiki 슬래시 명령어를 만들었습니다. 다만 이것은 필수가 아니라 편의 장치입니다. 원본 패턴에는 명령어가 없고, 그저 평소 말로 “이 기사 위키에 정리해줘"라고 해도 똑같이 동작합니다. 명령어는 그 지시를 표준화해, 매번 길게 설명하지 않아도 스키마 규칙대로 돌게 만든 것뿐입니다.

여기서 한 가지 선택지가 남습니다. 손도 대지 않고 완전히 무인으로 갱신되게 하려면, raw/에 파일이 추가될 때 자동 수집을 실행하는 훅(hook)이나 매일 도는 스케줄 에이전트를 붙이면 됩니다. 다만 이는 카파시의 원본 컨셉을 넘어선 확장입니다. 그가 굳이 사람을 개입시킨 이유는 무엇을 강조하고 무엇을 버릴지는 사람의 판단이 필요하기 때문입니다. 완전 무인으로 돌리면 위키 품질이 떨어질 수 있습니다. 그래서 필자는 일단 사람이 트리거하는 기본형으로 시작하기로 했습니다.

닫아 두었던 문을, 하나 열었다#

이번 적용에서 얻은 것은 디렉토리 구조가 아니라 바로잡은 두 가지 이해입니다. 하나, LLM Wiki는 자동으로 기억하는 마법이 아니라 사람이 방향을 잡고 LLM이 부기를 떠맡는 분업입니다. 둘, 그 핵심은 거창한 기술이 아니라 ‘몇 줄짜리 스키마’와 그 위에 쌓이는 지식입니다.

지난 글에서 필자는 “잘하고 있다는 느낌이 더 배울 것이 없다는 착각으로 미끄러지는 것"을 경계하겠다고 적었습니다. 이번에 침습도가 낮은 LLM Wiki를 실제로 열어 보니, 필자가 이미 쓰던 저장소 기반 메모리(.memory/)와 사상적으로 거의 같으면서도, ‘원본은 불변, 위키는 LLM 소유, 스키마로 규율’ 이라는 더 정돈된 골격을 배울 수 있었습니다. 통째로 갈아엎은 것이 아니라, 좋은 아이디어 하나를 골라 흡수한 셈입니다.

문 하나를 열었습니다. 다음 문도, 같은 방식으로 열어 볼 생각입니다.

관련 글#

• 하네스 스킬이라 부르기로 했다 — 잘하고 있다는 착각을 깨고 내 하네스를 열기까지 — 이 글의 출발점이 된 글. LLM Wiki를 ‘하네스 스킬’로 명명하고, 외부 패턴을 흡수하기로 마음먹은 배경을 담았습니다.

참고 자료#

• Andrej Karpathy — LLM Wiki (gist)
• Andrej Karpathy — LLM Wiki 관련 트윗