HoneyDrunk.Lore 구축하기: 나의 LLM 위키 및 데일리 뉴스 브리스트

Andrej Karpathy가 이 패턴을 처음 공개한 이후에 LLM 위키에 대해 이야기하는 것이 제가 다소 늦었다는 점은 알고 있지만, 제가 저만의 워크플로우(flow)에 이를 어떻게 구현했는지 소개하고자 합니다.

이 패턴은 제가 한동안 겪어온 문제를 정확히 짚어주었기에 제게 큰 울림을 주었습니다. 저는 많은 글을 읽습니다. 모델 발표, 에이전트 인프라(agent infrastructure) 포스트, .NET 및 Azure 업데이트, 아키텍처 기술 문서, 인디 소프트웨어 노트, 게임 개발(game-dev) 툴링, 보안 연구, 그리고 공식 기술 문서가 나오기 전 등장하는 무작위의 고신호(high-signal) 스레드들까지 말이죠. 이 모든 것들은 결국 HoneyDrunk에게 중요해질 수 있지만, 제가 읽는 바로 그 순간에는 거의 아무런 의미가 없습니다.

그 지점이 바로 일반적인 북마크(bookmarks)가 무너지는 곳입니다. 북마크는 링크는 보존하지만 이해(understanding)는 잃어버립니다. 채팅 기록(Chat history)은 대화는 보존하지만 지속 가능한 구조(durable structure)를 잃어버립니다. RAG(Retrieval-Augmented Generation)는 검색 가능한 청크(chunks)를 제공하지만, 질문을 던질 때마다 매번 매번 종합(synthesis) 과정을 다시 수행하게 만듭니다.

LLM 위키 아이디어는 다른 계층에서 작동합니다. 가공되지 않은 소스(Raw sources)가 들어오면, LLM이 이를 읽고 유용한 주장(claims)을 추출하며, 주제 페이지를 업데이트하고, 개념들을 서로 연결하며, 모순점을 추적하고, 저와 소스 더미 사이에서 관리되는 마크다운(markdown) 위키를 유지합니다. 위키는 하나의 컴파일된 결과물(compiled artifact)이 됩니다. 모델은 문맥(context)을 한 번 재발견하여 기록해 두고, 다음 쿼리(query)를 위해 이를 따뜻하게 유지(keeps it warm)합니다.

2026년 4월 4일에 생성된 Karpathy의 LLM Wiki gist와 사람들에게 이를 안내한 X 포스트가 이 패턴에 명확한 공개적 형태를 부여했습니다. 저의 구현체는 HoneyDrunk.Lore가 되었습니다.

Lore의 형태

HoneyDrunk.Lore는 스튜디오를 위한 저의 컴파일된 연구 지식 표면(knowledge surface)입니다. 이것은 플랫 파일(flat-file) 위키입니다. 디스크 상의 마크다운(markdown)이며, 소스에 기반하고, Obsidian과 호환되며, git으로 버전 관리되고, 명시적인 스키마(schema) 하에 에이전트(agents)에 의해 유지 관리됩니다.

파이프라인은 의도적으로 지루할 정도로 단순합니다:

가공되지 않은 소스 (raw sources)
  -> 컴파일된 위키 (compiled wiki)
  -> AGENTS/스키마 (AGENTS/schema)
...

raw/ 레이어는 증거 보관소 (evidence locker)입니다. 기사, 노트, 스크랩된 페이지, 선택된 소셜 포스트, 그리고 연구 결과물들이 불변의 소스 자료 (immutable source material)로서 이곳에 저장됩니다. 일단 무언가가 raw/에 들어오면, 규칙은 간단합니다. 추가하되, 역사를 다시 쓰지는 마십시오.

wiki/ 레이어는 컴파일된 표면 (compiled surface)입니다. 이곳은 소스 자료가 개념 페이지 (concept pages), 엔티티 페이지 (entity pages), 주제 인덱스 (topic indexes), 신뢰도 노트 (confidence notes), 그리고 링크로 변환되는 곳입니다. 이곳에서 주장 (claims)들이 강화되거나, 약화되거나, 대체되거나, 혹은 내가 이미 알고 있는 다른 것들과 연결됩니다. 단순한 요약 더미 이상의 가치를 갖게 만드는 작업이 바로 여기서 일어납니다.

AGENTS.md 파일은 스키마 (schema)이자 운영 매뉴얼 (operating manual)입니다. 이 파일은 에이전트 (agent)에게 디렉토리가 무엇을 의미하는지, 어떤 작업이 존재하는지, 인용 (citations)을 어떻게 처리할지, 언제 공백 (gaps)을 기록할지, 모순 (contradictions)을 어떻게 다룰지, 그리고 무엇이 지속 가능한 주장 (durable claim)으로 간주되는지를 알려줍니다. 이는 들리는 것보다 훨씬 더 중요합니다. 스키마가 없다면 LLM 위키는 그저 마크다운 (markdown)을 만드는 유능한 비서에 불과합니다. 하지만 스키마가 있다면, 규칙을 가진 유지 관리되는 지식 시스템 (knowledge system)이 됩니다.

쿼리 (Queries)는 output/에 다시 기록됩니다. 만약 내가 "오늘의 에이전트 보안 신호가 HoneyHub에 무엇을 시사하는가?"라고 묻는다면, 나는 그 답변이 인용, 신뢰도, 그리고 공백을 포함한 날짜가 지정된 결과물 (dated artifact)로 분류되기를 원합니다. 이후의 컴파일 패스 (compile passes)를 통해 해당 답변의 지속 가능한 부분들을 다시 위키로 결정화 (crystallize)할 수 있습니다. 질문은 채팅 기록 속으로 사라지는 대신, 또 다른 학습의 원천이 됩니다.

컴파일 (Compile)과 린트 (Lint)는 유지 관리 루프 (maintenance loop)입니다. 컴파일은 가공되지 않은 소스를 흡수하고, 주장을 조정하며, 인덱스를 업데이트하고, 지속 가능한 쿼리 출력물을 승격시킵니다. 린트는 고립된 항목 (orphans), 오래된 주장 (stale claims), 모순 (contradictions), 취약한 출처 (weak sourcing), 그리고 누락된 링크를 찾아냅니다. 그 보상은 바로 리듬 (rhythm)입니다. 위키는 건강함을 유지하기 위한 상시 프로세스를 갖추고 있으므로, 초기 집필의 폭발적인 시기가 지난 후에도 오랫동안 작동을 유지합니다.

The Daily Blast

Lore에 대한 가장 최근의 작업은 이 시스템을 개인적인 아카이브 (personal archive)라기보다 운영자 표면 (operator surface)처럼 느껴지게 만들었습니다.

매일 Lore는 Discord용 뉴스 블래스트 (news blast)를 생성할 수 있습니다. Lore는 가장 최근에 저장된 소스 창을 검토하여 유용한 시그널 (signal)을 추출하고, 이를 압축된 데일리 브리핑 (daily briefing)으로 변환합니다. 이 블래스트는 의도적으로 작게 유지됩니다. 즉, 현재 HoneyDrunk에게 중요한 세상의 부분들에 대한 의사결정 지원 요약 (decision-support summary) 역할을 합니다.

그 형태는 의도적으로 엄격합니다:

• 상위 10개의 웹 스토리.
• 상위 10개의 X/Twitter 포스트.
• 실제 소스 URL 및 트윗 URL.
• 두 세 문장의 요약.
• 각 항목이 왜 중요한지에 대한 HoneyDrunk 관점 (angle).
• 플랫폼 제한에 걸리지 않도록 분할된 Discord 메시지.
• 공개용 블래스트에는 비공개 내부 도구 이름을 포함하지 않음.

마지막 줄이 중요합니다. 공개용 블래스트는 무엇이 일어났는지, 어디에서 왔는지, 그리고 왜 중요한지를 말해야 합니다. 소스를 수집한 비공개 워커 (worker), 스크립트 (script), 레인 (lane) 또는 로컬 프로세스 (local process)의 이름이 유출되어서는 안 됩니다. 공개 시그널은 깨끗한 시그널이어야 합니다.

X/Twitter 레인은 의도적으로 선택적입니다. 저는 Lore가 소셜 미디어를 광범위하게 크롤링 (crawling)하는 것을 원하지 않습니다. 그것은 즉시 노이즈 (noise)로 변하며, 위키가 스택 (stack)에서 가장 혼란스러운 표면에 의존하게 만듭니다. 하지만 때로는 유용한 시그널이 정말로 그곳에서 가장 먼저 나타나기도 합니다. 1차 소스 (primary-source) 출시 포스트, 개발자 스레드 (thread), 조기 경보, 또는 공식 블로그 포스트가 존재하기 전의 새로운 에이전트 패턴 (agent pattern)에 관한 토론 등이 그러합니다.

따라서 Lore는 X/Twitter를 영구적인 기록 (durable record)에 들어갈 자격을 얻어야 하는 '조기 시그널 레인 (early-signal lane)'으로 취급합니다. 선택된 포스트는 실제 트윗 URL과 함께 캡처되어 조기 시그널로 표시될 수 있으며, 다른 원시 소스 (raw source)와 마찬가지로 컴파일됩니다. 이후에 공식 블로그 포스트, 문서 페이지 (docs page), 변경 로그 (changelog), 모델 카드 (model card), 전사 (transcript) 또는 기술 문서 (technical writeup)와 같은 영구적인 소스가 나타나면, 해당 소스가 소셜 캡처를 대체하거나 합류해야 합니다. 트윗은 최초 보고 맥락으로서 유용하게 유지되지만, 권위를 갖기 전까지는 반드시 상호 확인 (corroboration) 과정을 거쳐야 합니다.

이러한 구분이 바로 "내가 무언가를 봤다"와 "위키가 무언가를 알고 있다"의 차이입니다.

내가 이것을 원했던 이유

내 머릿속에서 HoneyDrunk는 단일 제품을 만드는 회사가 아닙니다. 그것은 수십 년에 걸친 개인적인 워크숍입니다. 즉, 컴퓨팅 플랫폼이자, 스튜디오이며, 실험실이고, AI 에이전트 (AI agents)를 활용하여 장기적인 관점에서 기묘하면서도 유용한 것들을 계속해서 만들어 나가는 장소입니다.

그것은 연구 (research)의 의미를 변화시킵니다.

내가 소스 (sources)를 수집하는 이유는 그것들이 결국 의사결정에 영향을 미치기 때문입니다. 에이전트 보안 패턴 (Agent security patterns)은 내가 에이전트 툴링 (agent tooling)을 구축하는 방식을 형성할 수 있습니다. 전달 (Delivery) 및 멱등성 (idempotency)에 관한 글은 메시징 파이프라인 (messaging pipeline)에 영향을 줄 수 있습니다. 유니티 (Unity), 에셋 파이프라인 (asset pipeline), 게임 툴링 (game tooling)에 관한 포스트는 게임 개발 (game-dev) 작업의 밑거름이 될 수 있습니다. 가격 책정 (Pricing), 제품 (product), 그리고 1인 개발 (solo-dev)에 관한 노트는 다음 실험을 패키징하는 방식을 바꿀 수 있습니다. 무작위 모델 라우팅 (model-routing) 벤치마크는 오늘 당장은 중요하지 않을 수 있지만, 3개월 후에는 정확히 부족했던 맥락 (context)이 될 수도 있습니다.

Lore는 그러한 재료들이 복리로 쌓일 수 있는 공간을 제공합니다.

Lore가 무엇이 아닌지를 말하는 것도 중요합니다. Lore는 HoneyDrunk의 거버넌스 (governance)가 아닙니다. 거버넌스는 아키텍처 문서 (architecture docs), ADR (Architecture Decision Records), 불변량 (invariants), 그리고 리포지토리 계약 (repo contracts)에 존재합니다. Lore는 의사결정에 정보를 제공할 수는 있지만, 의사결정을 공식화하지는 않습니다.

또한 그것은 에이전트 메모리 (agent memory)도 아닙니다. 에이전트 메모리는 런타임 상태 (runtime state), 선호도 (preferences), 세션 히스토리 (session history), 그리고 작업 컨텍스트 (working context)입니다. Lore는 소스에 기반한 의사결정 지원 (source-backed decision support)입니다. 만약 Lore가 무언가를 말한다면, 그것은 소스를 지목할 수 있어야 하고, 신뢰도 (confidence)를 보고할 수 있어야 하며, 공백 (gaps)을 명시할 수 있어야 합니다. 나는 에이전트가 한 번 작성했다는 이유만으로 인용되지 않은 위키 산문 (wiki prose)이 교리 (doctrine)가 되는 것을 원하지 않습니다.

그 경계가 바로 핵심입니다. Lore가 유용할 수 있는 이유는 그것이 마법 (magic)이 되도록 허용되지 않기 때문입니다.

다르게 느껴지는 부분

가장 큰 돌파구 (unlock)는 위키가 구축된 산출물 (built artifact)이라는 점입니다. 그것은 코드와 같은 방식으로 컴파일 (compiled)되고, 유지 관리 (maintained)되며, 앞으로 전달됩니다.

검색 (Search)은 "그것을 다시 찾을 수 있는가?"라고 묻습니다. Lore는 "그것이 내가 이미 알고 있는 형태의 지식으로 소화되었는가?"라고 묻습니다. 이 둘은 서로 다른 질문입니다. 하나는 검색 (retrieves)하는 것이고, 다른 하나는 복리로 쌓는 (compounds) 것입니다.

매일 진행되는 Discord blast를 통해 그것이 가시화되었습니다. 소스(source)는 가공되지 않은 기사나 트윗에서 검토된 일일 시그널(daily signal)로 변환됩니다. 이 시그널은 원래의 URL을 그대로 유지합니다. 요약은 휴대폰에서 읽기에 충분할 만큼 짧습니다. HoneyDrunk의 관점은 관련성을 명시적으로 만들어 줍니다. 나중에 해당 항목이 지속 가능하다고 판단되면, compile 단계에서 이를 위키(wiki)에 통합할 수 있습니다. 만약 내용이 약하다면, lint 단계를 통해 이를 소멸(decay)시킬 수 있습니다. 더 나은 소스가 나타나면, 이전의 주장은 조용히 덮어쓰여지는 대신 대체(superseded)될 수 있습니다.

이것이 제가 장기적인 워크숍(workshop) 주변에 두고 싶은 시스템의 모습입니다. 자신만의 리듬으로 작동하며, 이미 배운 것을 보존하고, 세션 사이의 간극을 메워주는(stays warm) 무언가 말입니다.

관리되는 위키. 일일 시그널 검토. 첨부된 소스 URL. 가시적으로 유지되는 신뢰도. 숨기는 대신 명시된 공백들.

모든 유용한 개인용 시스템이 그렇듯, 아직 곳곳이 거칠긴 합니다. 하지만 이것은 이미 읽는 경험의 느낌을 바꾸어 놓았습니다. 소스들은 더 이상 제 주의력을 그저 스쳐 지나가지 않습니다. 소스들은 착륙할 장소, 컴파일(compiled)될 방법, 그리고 거버넌스(governance)나 진리인 척하지 않으면서 워크숍의 장기 기억의 일부가 될 기회를 갖게 되었습니다.

이것이 바로 제가 필요로 했던 LLM 위키 패턴의 버전입니다. 제가 수십 년 동안 계속해서 구축해 나갈 스튜디오를 위한, 소스에 기반한 연구 표면(research surface) 말입니다.