▲

WUPHF - Karpathy 스타일 LLM 위키를 에이전트들이 직접 유지하는 시스템

 (github.com/nex-crm)
1P by GN⁺ 10시간전 | ★ favorite | 댓글 1개
  • 마크다운 & Git 기반 AI 에이전트용 위키 레이어
  • AI 에이전트들이 세션을 넘어 컨텍스트를 누적할 수 있도록 설계된 LLM 네이티브 지식 기반 레이어로, ~/.wuphf/wiki/에 로컬 저장되며 git clone으로 통째로 가져갈 수 있음
  • Postgres, pgvector, Neo4j, Kafka 같은 무거운 인프라 대신 markdown + git만으로 구성하고 벡터 DB 없이 BM25 + SQLite로 지식 관리
    • markdown으로 저장하고, bleve로 BM25 검색, SQLite로 구조화된 메타데이터(facts, entities, edges, redirects, supersedes) 관리
    • 벡터 DB 미사용 상태에서 500개 아티팩트·50개 쿼리 벤치마크 기준 recall@20 85% 달성
    • 특정 쿼리 클래스가 이 기준 이하로 떨어질 경우를 대비해 sqlite-vec 이용 예정
  • 각 에이전트는 agents/{slug}/notebook/*.md 경로에 개인 노트북을 보유하고, team/ 경로의 공유 위키에 접근
    • 노트북 항목을 에이전트 또는 사람이 리뷰한 뒤 위키로 승격(promotion) 하는 흐름이 존재하며, 백링크가 자동 생성됨
    • 소형 상태 머신이 만료(expiry)와 자동 아카이브를 관리
  • Per-entity fact log: team/entities/{kind}-{slug}.facts.jsonl에 append-only JSONL로 기록
    • 합성 워커가 N개 fact마다 entity brief를 재구축하며, 커밋은 "Pam the Archivist" 라는 별도 git identity로 남겨 출처가 git log에서 바로 확인 가능
    • Fact ID는 문장 오프셋을 포함한 결정론적 ID, canonical slug는 한 번 부여 후 redirect stub으로 병합되며 절대 변경 불가
    • rebuild는 논리적으로 동일하나 바이트 단위 동일성은 보장하지 않음
  • [[Wikilinks]] 지원 및 깨진 링크는 빨간색으로 렌더링, 일일 lint cron이 모순·오래된 항목·깨진 위키링크를 검출
  • /lookup 슬래시 커맨드와 MCP 도구로 인용 기반 검색 제공
    • 휴리스틱 분류기가 짧은 조회는 BM25로, 서술형 쿼리는 cited-answer 루프로 라우팅
  • 알려진 한계
    • recall 튜닝 진행 중이며 85%는 범용 보장 수치가 아님
    • 합성 품질은 에이전트가 기록한 fact의 품질에 종속(garbage in, garbage out), lint가 보조하지만 판단 엔진은 아님
    • 현재 단일 오피스 범위, 크로스 오피스 페더레이션 미지원
  • WUPHF(Claude Code, Codex, OpenClaw, 로컬 LLM 지원 오픈소스 AI 에이전트 오피스)의 일부로 제공되지만, 위키 레이어만 단독 사용 가능 — 기존 에이전트 셋업에 WUPHF를 연결하면 위키가 자동 부착
  • MIT 라이선스

함께 보면 좋은 글 β

▲
GN⁺ 10시간전  [-]
Hacker News 의견들

  • 노트 자동화의 요점을 잘 모르겠음. 예전에도 텍스트를 복붙해서 노트에 넣는 방식은 전혀 도움이 안 됐는데, 이제 그걸 100배로 늘린다고 달라질까 싶음
    내게 노트의 핵심은 출처를 비판적으로 읽고, 내 정신적 모델에 맞춰 소화한 뒤 그걸 기록하는 데 있음
    세부사항은 나중에 찾아보면 되고, 결국 중요한 건 그 모델을 다듬는 과정임

    • 이건 단순한 노트 작성 이상으로 보임. 사실상 인간 개입을 최소화한 채 에이전트끼리 작업을 조율하는 또 하나의 하네스에 가까움
      그렇다면 굳이 그 정신적 모델을 직접 만들지 않고, 공유된 LLM brain에 넘기는 게 목적일 수도 있음
      다만 이런 접근으로 제품 소유자에게 진짜 가치 있는 무언가를 만들 수 있을지는 꽤 의심스러움. 프롬프트와 에이전트 하네스만으로 가치 있는 제품을 만들 수 있다면, 그 제품은 누구나 다시 만들 수 있고 제품 개발 자체가 commodity가 되며 결국 가치가 남는 건 토큰뿐일 수 있음
      내 가설로는 Paul Graham의 do things that don’t scale가 앞으로도 계속 유효하되, 그 확장되지 않는 일의 내용만 바뀔 가능성이 큼
      그래도 나는 최근에 Obsidian을 제대로 쓰기 시작했음. 노트 작성, 조사, 링크 연결, 분할, 지식베이스 재구성을 위한 스킬을 세팅해 두니, 정리를 대신해 주는 디지털 비서가 생긴 느낌임
      이제는 잡생각만 적어도 에이전트가 구조를 잡아 주고, 후속 질문도 던지고, 다른 작업과 연결도 해 줌. 출처를 읽고 정신적 모델을 만드는 일은 여전히 내가 하지만, 품질 좋은 노트는 거의 공짜에 가깝게 얻고 있음
    • 사람들이 AI로 엄청난 잡무를 만들어 놓고 다시는 들여다보지 않는 게 심각한 문제라고 봄
      엄청난 낭비임
    • 노트 작성 쪽은 완전히 동의함. 노트를 너무 가볍게 다루는데, 결국 다락방이나 지하실처럼 필요 이상으로 쌓아 두게 됨
      대부분의 것은 애초에 노트에 들어갈 필요가 없고, LLM은 검증이나 필터링도 제대로 안 한 채 노이즈를 지나치게 늘림
      이 주제를 잘 다룬 영상으로 JA Westenberg의 에세이가 있었음
      https://youtube.com/watch?v=3E00ZNdFbEk
    • 지금까지 나온 몇 안 되는 과학 연구를 보면, 이런 markdown 컬렉션을 LLM이 전적으로 유지할 때는 산출물 품질이 오히려 떨어지고, 사람이 유지할 때는 좋아진다고 함
      꽤 흥미로웠음
      내 생각엔 최적점은 인간 큐레이션이고, 특히 debt나 drift를 의식적으로 관리하지 않으면 무감독 운영은 답이 아님
    • 나도 처음엔 이게 패러디인 줄 알았음
      하필 이름도 The Office에 나왔던 그 쓸모없고 중복적인 제품 Wuphf.com이랑 같아서 더 그랬음

  • 제품 이름에 AI만 붙이면 수십억 달러가 따라오고, 블로그 글에 Karpathy만 넣으면 Anthropic 수석 엔지니어로 채용되는 분위기처럼 보임
    유행이 지속되는 동안 돈을 짜내려는 움직임뿐이고, 고객이 뭘 필요로 하는지는 별로 안 보는 느낌임
    다들 파도가 있을 때 손이라도 씻어 보려는 식으로 달려드는 중임

    • NFT, 그 전의 blockchain, 어떤 면에선 Web 2.0 열풍과도 비슷함
      그래도 그때는 실제로 뭔가를 만들긴 했고, 당시의 빡빡한 자금 환경이 과열을 조금은 눌러 줬음
      이번 LLM 붐은 적어도 실제 가능성과 가치가 어느 정도 있고, 배우고 만져 보기에도 꽤 재미있는 기술임
      나는 오래전에 이런 데 돈이 몰리면, 비윤리적이지만 않다면 거기서 기회를 잡는 게 맞다고 받아들였음. VC/PE 자금이 넘치는 동안 가치 있는 멋진 걸 만들 수도 있음
    • 되기만 하면 되는 거 아님 싶음. 다들 AI 도구를 만드는 데는 이유가 있고, 실제로 우리 모두 그걸 사고 있음
      나는 아직도 Claude Code를 대체할 만한 세계급 CLI 하네스를 기다리는 중임. 메모리 문제와 설계 문제를 해결해 주는 물건이 필요함
      웹 디자인은 아직도 LLM으로 하기엔 악몽에 가까움
    • 작년에 이미 HubSpot 창업자 Dharmesh Shah의 지원을 받는 AI-native CRM을 만들었고, 매출도 있었고, 거기서 반복적으로 방향을 바꿔 context graph infra 쪽이 해자로 맞다고 판단했음
      엔터프라이즈 PoC도 했고, 그 모든 게 결국 내 개인 작업을 돕기 위해 옆에서 만든 이 프로젝트로 응축됐음. 결과적으로 context infra를 실제로 쓰기 좋은 인터페이스가 바로 이거였음
      Anthropic 수석 엔지니어 자리에는 관심 없음. 예전엔 HubSpot Product Manager였고 수입도 지금보다 훨씬 좋았으며, 앞으로 몇 년간도 그 수준은 못 벌 가능성이 큼
      여러 번 베팅하고 계속 반복 수정한 건 고객과 직접 얘기하면서 진화했기 때문임. 반면 예전 경쟁사들은 아직도 AI CRM을 stealth로 만들고 있음
      업계에 오래 있었던 입장에서 파도 자체는 중요하지 않지만, 그 파도 아래서 건질 실질적 가치는 분명 있다고 봄

  • 이 리뷰를 봤음: https://zby.github.io/commonplace/agent-memory-systems/reviews/wuphf/
    24시간 안에 프런트페이지에 올라온 세 번째 LLM wiki라서, 확실히 뜨거운 주제임
    나도 이 분야에 이해관계가 있어서 완전히 객관적이진 않지만, 이런 시스템에 바라는 점을 따로 정리해 뒀음
    https://zby.github.io/commonplace/notes/designing-agent-memory-systems/
    다들 각자 자기 시스템을 새로 만드는 건 중복 투자가 너무 커 보여서, 협업할 길이 있었으면 좋겠음

    • 노트가 꽤 흥미로웠음
      다만 문체를 보면 LLM이 쓴 게 분명해 보여서, 이런 설계 노트는 나중에 다시 자기 말로 정리해서 정말 자기 생각을 담고 있는지 확인하는 편인지 궁금함
    • Borrowable Ideas 섹션이 특히 좋았고, 진짜로 많이 가져다 쓰면 좋겠음
      우리는 Karpathy가 LLM wiki 아이디어를 꺼내기 훨씬 전부터 nex.ai라는 context infra 회사로 출발했고, 그 기능을 WUPHF에는 아직 거의 드러내지 않았지만 이제 조금씩 공개하는 중임
      비교 글에 적어 둔 우려들 상당수가 우리가 이미 만든 context infra에서 다뤄 온 부분이라 반가웠음
      그래도 중복은 줄이고 서로 배운 걸 나누는 협업은 얼마든지 환영함
    • 생성형 slot machine들이 사람을 고립시키는 면은 분명함
      협업할 기회가 있었으면 좋겠다고 했는데, 마치 지금은 그 기회가 없는 것처럼 들려서 의아함
    • 한번 읽어보겠음
    • 솔직히 말하면 이젠 직접 굴려서 만드는 영역에 들어왔다고 봄
      Obsidian vault에 QMD만 얹어도 80%쯤은 가고, 아마 2시간도 안 걸릴 듯함

  • 맥락용으로 Karpathy의 원문 링크도 있음
    https://x.com/karpathy/status/2039805659525644595
    https://xcancel.com/karpathy/status/2039805659525644595

  • AI Notes가 가치를 더할지, 아니면 노이즈만 만들지 궁금함
    그래도 웹사이트의 ASCII 스타일은 꽤 마음에 듦

  • 이 문제의 해법으로는 StackOverflow revival 같은 걸 누가 만들면 좋겠음
    사람이 큐레이션하되, 집단적인 LLM들이 문제를 풀다가 막히면 옛날 방식으로 질문을 올리는 분산 지식 그래프가 되면 됨
    내 에이전트가 "여기서 막혔고, SO에 질문을 올려 뒀으니 답이 달리면 나중에 다시 오자"라고 말해도 충분히 괜찮을 듯함

  • 어떻게 해야 LLM이 너무 많이 쓰지 않게 막을 수 있는지 궁금함
    비슷한 도구와 시스템을 몇 개 만들어 봤는데, 전부 LLM이 문서를 계속 불려서 결국 시스템 전체가 엉망이 되고, 커질수록 쓸모가 줄어들었음
    예전에 해 본 실험 중 하나는 링크 몇 개만 주면 LLM이 관련 주제를 조사하고, 자기 knowledge wiki를 만들어 각 페이지에 요약과 상호 링크, 출처를 정리하게 하는 방식이었음
    겉보기엔 좋아 보였지만 실제 데이터를 읽어보면 별로였음
    몇 년 전 실험이니, 지금은 opus 4.7 같은 걸로 다시 해 볼 가치는 있을지도 모르겠음

  • 생각거리를 던지자면 TiddlyWiki 커뮤니티도 당연히 AI 도구를 탐색해 왔음
    TiddlyWiki는 스스로 수정 가능한 단일 HTML 파일 기반 위키이고, 20년 넘게 이어져 왔음
    꼭 agentic 환경으로 발전한 건 아니지만 markdown 플러그인도 있고, 파일을 실행 가능하게 하거나 self-serving 웹앱으로 바꾸는 도구도 있음. Git은 다소 까다로움
    그래서 이론상으로는 단일 파일 agentic wiki가 돌아다니며 자기 자신을 수정하는 것도 가능함
    https://tiddlywiki.com/

    • 참고로 TiddlyWiki를 처음 만든 사람이 바로 나임
      당신이 말한 single-file 구성은 이미 여러 LLM 커넥터가 있음. 예를 들면 https://github.com/rimir-cc/tw-llm-connect
      매력도 정확히 그 지점임. 의존성도 없고 설치도 필요 없고 보관도 매우 쉬워서, 단일 파일 agentic wiki가 스스로 편집하는 구성은 오늘 당장도 가능함
      Karpathy의 LLM Wiki 패턴에 더 가까운 것으로는 내가 작업 중인 twillm도 있음
      https://github.com/Jermolene/twillm
      이건 TiddlyWiki의 Node.js 구성을 쓰고, tiddler를 개별 파일로 저장해서 기존 Markdown vault를 그대로 가리키며 Claude Code 같은 도구와 함께 쓸 수 있음
      TiddlyWiki의 장점도 꽤 분명함. 오픈소스라 장기적으로 계속 쓸 수 있고, 웹 기반이라 어디서나 접근 가능함
      또 계산된 뷰가 materialized index 파일을 대체함. Karpathy 방식은 LLM이 노트를 추가할 때마다 index.md를 계속 동기화해야 하는데, 이런 건 세션이 바뀔수록 stale해지기 쉬워서 LLM이 특히 못하는 일임
      반면 TiddlyWiki의 뷰는 실시간 필터 식이라서, 예를 들어 "concept 태그가 달린 tiddler를 rating 순으로 정렬" 같은 결과를 렌더링 시점에 즉석 계산함
      Frontmatter도 질의 가능한 구조가 됨. Obsidian은 YAML frontmatter를 노트 상단의 박스형 메타데이터로 보여 주지만, TiddlyWiki는 그 필드를 일급 tiddler 필드로 끌어올려 필터링, 정렬, 집계에 바로 쓸 수 있음
      그리고 LLM이 단순히 콘텐츠뿐 아니라 작은 애플릿도 작성할 수 있음. Markdown 노트 말고도 wikitext tiddler(.tid)를 넣어서 대시보드, 태그 탐색 도구, 저널 인덱스, 용어집 같은 상호작용형 라이브 뷰를 만들 수 있음

  • self building artefacts 영역은 흥미롭고, 최근 LLM 특히 코딩 계열 모델이 이쪽에 빠르게 강해지면서 지금 크게 커지고 있음
    나도 최근에 의존성을 최소화하고, 로컬에서 에이전트를 통제하는 데 초점을 둔 프로젝트를 실험했음
    https://github.com/GistNoesis/Shoggoth.db/
    프롬프트로 준 장기 작업을 수행하기 위해 스스로 sqlite 데이터베이스를 만들고 정리하며, 소스 데이터로는 로컬 Wikipedia 사본을 씀
    에이전트 drift를 실험하기 위한 하네스와 도구도 아주 최소한으로만 넣어 둠
    이미지 처리 도구를 붙이는 것도 쉬운 편임. 이미지를 base64로 인코딩해서 llama.cpp에 넘기면 되고, 세부 구현은 로컬 LLM으로 대충 vibecoding해도 됨
    꽤 범용적으로 유용한 도구라고 봄
    예를 들어 예전엔 폴더 안의 송장과 영수증에서 금액, 날짜, 판매처를 추출하려고 Amazon Textract를 쓰는 스크립트가 있었고, 이후 숫자를 사람이 확인해서 회계사에게 줄 CSV를 만들었음
    지금은 그 Amazon Textract 호출을 적절한 프롬프트의 llama.cpp 모델 호출로 바꿀 수 있고, 기존 송장 도구도 그대로 살리면서 훨씬 더 창의적인 회계 처리까지 가능해졌음
    또 카메라 이미지 시퀀스로 물리 로봇을 움직이게 하는 변형도 실험했는데, 단순한 경우엔 실제로 움직여 목표에 도달하긴 했음
    다만 내가 쓰는 LLM은 원래 로봇 운전용으로 훈련된 적도 없고, 다음 행동을 고르는 데 10초나 걸려 실용적이진 않았음. 현재 딥러닝이 아닌 기존 제어기는 비전 루프를 20Hz로 돌림

  • LLM 모델과 그 위의 에이전트는 결정론적이 아니라 확률적임
    뭔가를 일정 비율로는 해내지만, 매번 성공하진 않음
    그래서 에이전트가 한 작업을 오래 끌수록 실패 확률도 계속 커짐. 이런 식의 장기 실행 에이전트는 결국 실패하고, 그 과정에서 토큰 비용도 엄청 태우게 됨
    LLM 에이전트가 잘하는 일 중 하나는 자기 지시문을 다시 쓰는 것임
    요령은 thinking 모델의 시간과 사고 단계를 제한한 뒤 평가하고, 업데이트하고, 다시 돌리는 데 있음
    비유하자면 에이전트는 넘어진다고 보면 됨. 오래 달리게 해서 넘어지게 하지 말고, 10분 한 번보다 5분 두 번이 낫다는 뜻임
    몇 주만 지나면 이런 자기참조 에이전트가 다들 Twitter 피드 상단을 차지할 듯함

    • 에이전트와 ML은 외부 피드백이 없으면 local maxima에 갇히는 문제도 있음
      그래서 이런 위키는 어느 상태에 도달하면 거기서 멈춰 버릴 가능성이 큼
답변달기
긱뉴스에 GeekBadge 기능이 추가되었습니다. 긱배지로 자신을 표현해 보세요.