Lumen - AI Agent를 위한 지속 가능한 두뇌
왜 만들었는가
AI 에이전트는 모든 대화를 기억상실증 상태에서 시작합니다.
Claude Code, Cursor, Codex, Mastra 하네스, LangChain 파이프라인 — 이 도구들은 세상을 알지만 당신의 세상은 전혀 모릅니다. 당신이 읽은 200편의 논문, 당신이 출시하는 코드베이스, 지난 분기에 내린 아키텍처 결정, 새벽 2시에 그 버그를 잡아냈을 때 마침내 통했던 트래젝토리. 모든 세션이 같은 컨텍스트를 다시 학습하고, 같은 실수를 반복하며, 한 시간 전의 사용자 피드백을 잊어버리고, 같은 도메인을 다시 설명하느라 토큰 예산을 태웁니다.
저는 이 상황에 지쳤습니다. 시간이 지날수록 복리로 더 유용해지는 에이전트를 원했습니다. 매주 일하는 동안 제가 실제로 하는 일에 점점 더 능숙해지는 에이전트. 적게도 같지도 않게, "매주 화요일마다 다른 방식으로 유용한" 것도 아니게. 새 동료가 팀에 합류했는데 "여기서는 Auth.js가 아니라 Better Auth를 씁니다"를 40번의 대화에 걸쳐 40번 설명해야 한다면 저는 그 동료를 해고할 것입니다. 그런데 왜 토큰당 비용을 청구하는 도구에게는 그것을 용인하고 있었을까요?
Lumen은 그 답답함에서 나왔습니다. 에이전트가 읽는 모든 것과 에이전트가 하는 모든 것 사이에 자리잡는 로컬 우선 지식 컴파일러입니다. 학습한 내용의 구조화된 그래프를 구축하고, 효과가 있었던 패턴을 캡처하며, 그 그래프의 적절한 부분을 모든 세션에 다시 공급합니다. 에이전트는 더 이상 같은 것을 다시 학습하지 않습니다. 에이전트는 복리로 성장하기 시작합니다.
┌─────────────────────────────────────────────────┐
│ │
│ Lumen 없이 │
│ ────────── │
│ │
│ 세션 1 ──► 학습 데이터로 답변 │
│ 세션 2 ──► 학습 데이터로 답변 │
│ 세션 3 ──► 학습 데이터로 답변 │
│ │
│ 세션당 누적 지식: 0 │
│ │
└─────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────┐
│ │
│ Lumen과 함께 │
│ ──────────── │
│ │
│ 세션 1 ─► 읽고 + 캡처하고 + 점수 부여 ──┐ │
│ │ │
│ ▼ │
│ 세션 2 ─► 두뇌 먼저 조회 ──► 더 추가 │
│ │ │
│ ▼ │
│ 세션 3 ─► 더 풍부해진 두뇌 발견 ──► 더 추가 │
│ │
│ 세션당 누적 지식: 단조 증가 │
│ │
└─────────────────────────────────────────────────┘
이 글은 그 루프가 어떻게 동작하는지, 각 부품이 무엇을 하는지, 그리고 솔직한 트레이드오프가 어디에 있는지를 설명합니다.
지식이 복리로 쌓이는 모습
Lumen 없이 — 평평함
┌──┐ ┌──┐ ┌──┐ ┌──┐ ┌──┐ ┌──┐ 세션당 누적 지식: 0
│ │ │ │ │ │ │ │ │ │ │ │ 매번 같은 컨텍스트를 다시 설명
└──┘ └──┘ └──┘ └──┘ └──┘ └──┘
S1 S2 S3 S4 S5 S6
─── 시간 흐름에 따른 세션 ───►
Lumen과 함께 — 복리로 성장
┌──┐
│██│
┌──┐ │██│
│██│ │██│
┌──┐ │██│ │██│ 세션당 누적 지식:
│██│ │██│ │██│ 단조 증가
┌──┐ │██│ │██│ │██│
┌──┐ │██│ │██│ │██│ │██│ 매 대화가 두뇌를 확장
┌──┐ │██│ │██│ │██│ │██│ │██│
│██│ │██│ │██│ │██│ │██│ │██│
─└──┘──└──┘──└──┘──└──┘──└──┘──└──┘─
S1 S2 S3 S4 S5 S6
막대가 자라는 이유는 매 세션이 두뇌에 새로운 것을 기록하기 때문입니다 — 캡처된 트래젝토리, 유용한 개념에 대한 +1, 수정된 truth — 그리고 다음 세션은 그 모든 것을 이미 담고 있는 두뇌를 읽기 때문입니다.
Lumen이 무엇인지, 한 문단으로
Lumen은 두 가지 인터페이스 — CLI (lumen-kb)와 Model Context Protocol 서버(도구 23개) — 를 가진 로컬 우선 지식 컴파일러입니다. URL, PDF, 논문, YouTube 자막, 전체 코드 저장소, 데이터셋, 심지어 대시보드 스크린샷까지 입력으로 받습니다. 내용을 청킹하고, 하이브리드 검색을 위해 인덱싱하며, 소스마다 Claude 패스를 돌려 이름이 부여된 개념과 가중치 엣지를 추출하고, 모든 것을 ~/.lumen/lumen.db라는 하나의 SQLite 파일에 저장합니다. MCP를 구사하는 에이전트 — 기본 지원되는 Claude Code, Cursor, Codex, 그 외 무엇이든 — 는 답변하기 전에 그래프를 검색하고, 응답 후 새로운 아이디어를 캡처하며, 개념에 찬반 투표를 하고, 과거 작업의 성공적인 도구 호출 시퀀스를 재생할 수 있습니다. 전체가 단일 파일입니다. 그 파일 하나만 백업하면 모든 것이 보존됩니다.
파이프라인
INGEST CHUNK STORE SEARCH
────── ───── ───── ──────
URL ─┐ ┌─ Markdown ┌─ Sources ┌─ BM25 (FTS5)
PDF ─┤ │ │ │
YouTube ─┤ ├─ HTML ├─ Chunks ├─ TF-IDF
arXiv ─┤ Extract│ ─► │ ─►│
File/Dir ─┼────────►├─ Plain text ├─ Concepts ├─ Vector ANN
Code ─┤ │ ├─ Edges │
Dataset ─┤ ├─ Code + sigs ├─ Aliases ├─ Graph walk
Image ─┤ │ ├─ Trajectories │
Obsidian ─┘ └─ Schema tables └─ Embeddings └─ RRF fusion
│
▼
Budget cut
│
▼
Ranked chunks
│
▼
LLM synthesis
다섯 개의 수평 단계입니다. 각 단계는 독립적으로 테스트 가능합니다. 어떤 단계도 네트워크 접근을 요구하지 않습니다. 예외는 (a) 사용자가 요청한 URL을 가져오는 경우, (b) compile / ask 중 선택적인 Claude 호출, (c) embed 중 선택적인 임베딩 제공자 호출뿐입니다.
Ingest — 포맷별 익스트랙터. URL은 @extractus/article-extractor, PDF는 pdf-parse, YouTube는 Innertube 자막 API, arXiv는 Atom + PDF, 코드 저장소는 .gitignore 인식 워크와 언어별 시그니처 추출이 포함된 얕은 git clone, 데이터셋(CSV / TSV / JSONL / HuggingFace)은 스키마 테이블 + 20행 프리뷰, 이미지는 선택적인 Tesseract OCR로 처리합니다. 모든 익스트랙터는 동일한 ExtractionResult를 반환하므로, 다운스트림 코드는 결코 입력 타입에 따라 분기하지 않습니다.
Chunk — 마크다운 인식 구조적 분할. 헤딩은 새 청크를 시작하고, 코드 펜스는 원자적으로 유지되며, 50토큰 미만의 조각은 앞으로 병합되고, 1,000토큰을 초과하는 큰 블록은 문장 경계에서 분할됩니다. 각 청크는 자기 위에 있는 가장 가까운 헤딩을 섹션 컨텍스트로 상속받습니다.
Store — SQLite WAL, 증분 인덱싱을 위한 FTS5 트리거, 선택적인 벡터 ANN을 위한 sqlite-vec. 스키마는 v15이며 마이그레이션은 추가 전용입니다. ~/.lumen/에 단일 파일이 위치합니다.
Search — 세 가지 신호의 융합. SQLite 내장 bm25()를 통한 BM25(Porter 스테밍), 인메모리 역색인 기반 TF-IDF(cosine), 상위 결과의 1–2홉 이웃 개념에 앵커링된 청크를 주입하는 그래프 워크. Reciprocal Rank Fusion으로 결합합니다(score = Σ w / (k + rank), k=60). 출력은 relevance-density 예산 컷을 통과합니다. 짧고 가치 높은 청크가 길고 가치 낮은 청크를 이깁니다.
Compile — 유일하게 필수적인 LLM 패스. Claude가 처리되지 않은 각 소스를 읽고 구조화된 {concepts[], edges[]}을 방출합니다. 각 개념은 compiled_truth(시스템의 현재 최선의 이해)와 어떤 소스가 기여했는지의 timeline을 저장합니다. 병렬 실행(-c N), 델타 인식(--all을 주지 않으면 처리되지 않은 소스만 건드림), 그리고 프롬프트 캐싱(cache_control: ephemeral)을 통해 세션 내 반복 호출 시 약 60–80%의 비용 절감을 제공합니다.
사용하면서 두뇌가 자동으로 업데이트되는 방식
이것이 바로 "복리"라는 주장에서 핵심이 되는 부분입니다. 두뇌는 사용자가 소스를 인제스트한 뒤 그대로 머물지 않습니다. 에이전트가 세션을 거치는 매 순간 성장하고, 성장하면서 점수가 매겨지고 통합됩니다.
Claude Code 세션
│
│ 사용자 프롬프트
▼
CLAUDE.md 발동: "답변하기 전에 두뇌를 확인하라"
│
▼
brain_ops(query) via MCP
│
├── 개념 조회 매칭? ──► compiled_truth + edges를 컨텍스트로
├── 그래프 경로 매칭? ──► 연결 체인을 컨텍스트로
├── 이웃 매칭? ──► 관련 개념 클러스터를 컨텍스트로
└── 하이브리드 검색 폴백 ──► 상위 랭크 청크를 컨텍스트로
│
▼
에이전트가 두뇌 컨텍스트로 답변, [Source: title] 인용
│
▼
Stop 후크 발동: "새 지식이 나타났다면 capture를 호출하라"
│
▼
capture(type, title, content, related_slugs)
│
│ DB 쓰기 전
▼
PII 게이트 — 이메일, API 키, JWT, Luhn으로 검증된 신용카드,
전화번호, 사설 IPv4, 홈 경로를 redact
│
▼
┌─────────────────────────────────────────────────────────┐
│ alias 머지 게이트 (셋 다 만족해야 함): │
│ slug 유사도 ≥ 0.7 (Levenshtein 정규화) │
│ content Jaccard ≥ 0.6 (서로 다른 ≥3자 토큰 기준) │
│ 양쪽 토큰 수 ≥ 4 (얇은 콘텐츠 가드) │
└─────────────────────────────────────────────────────────┘
│
├── 셋 다 통과 ──► 기존 canonical에 합쳐넣기
│ (alias 행 작성; 향후 조회 시 해석됨)
└── 하나라도 실패 ──► 새 개념 + timeline 항목으로 upsert
│
▼
sync_journal 추가 (같은 트랜잭션)
│
▼
다운스트림: 검색 인덱스, tier 스코어링, 동기화 데몬 푸시
│
▼
다음 대화를 위해 두뇌가 더 풍부해짐
매 사이클마다 지식이 추가됩니다. 에이전트는 대화 이후 개념을 보강합니다. 다음에 같은 주제가 나올 때 brain_ops가 그것을 찾아냅니다. 차이는 매일 복리로 쌓입니다.
루프, 단계별로
┌──────────────┐ ┌──────────────┐
┌──▶│ brain_ops │────────▶│ 답변 │──┐
│ │ 두뇌 조회 │ │ 소스 인용 │ │
│ └──────────────┘ └──────────────┘ │
│ │
│ ▼
┌──────────────┐ ┌──────────────┐
│ 사용자 │ │ capture │
│ 프롬프트 │ │ + PII 게이트│
└──────────────┘ └──────────────┘
▲ │
│ │
│ ┌─────────────────────┐ │
└───────────│ 두뇌 │◀───────────┘
│ 다음에 더 풍부 │
└─────────────────────┘
한 바퀴마다 두뇌가 더 풍부해짐 · 한 턴당 약 5번의 MCP 도구 호출
Claude Code에서 한 바퀴 도는 데 약 6초 소요
파란 펄스는 루프 한 바퀴를 약 6초에 돕니다 — 실제로 Claude Code가 두뇌 조회 → 답변 → 캡처 한 사이클을 완료하는 데 걸리는 시간과 비슷합니다. 모든 루프는 capture로 끝나고, 이는 sync_journal에 기록되며, 데몬이 이를 픽업해 릴레이로 보냅니다 — 사용자가 아무것도 입력하지 않아도 다른 모든 디바이스가 그 루프의 결과를 받습니다.
계층적 보강 (Tiered enrichment)
모든 개념이 같은 해상도로 존재하지는 않습니다. 각 개념은 Tier 3 — 기본 요약을 가진 스텁 — 으로 시작합니다. 더 많은 소스가 그것을 참조함에 따라 티어가 올라갑니다.
Tier 3 ───── 한 번 언급됨
▲ 스텁 + 요약
│
Tier 2 ───── 2개 이상의 소스에서 3회 이상 언급됨
▲ 연결과 컨텍스트로 보강
│
Tier 1 ───── 3개 이상의 소스에서 6회 이상 언급됨
전체 compiled_truth — 사용자가 읽은
모든 것에서 합성된 시스템의 현재
최선의 이해
lumen enrich를 실행하여 업그레이드 큐를 처리하거나, lumen enrich --status로 현재 상태를 확인할 수 있습니다. 티어 사다리는 시스템이 매번 지나가는 모든 언급이 아니라, 여러 소스에 걸쳐 실제로 중요하다고 입증된 개념에 LLM 토큰을 사용하도록 보장합니다.
스킬 스코어링과 은퇴
개념 피드백 이벤트
│ │
│ brain_feedback을 통한 +1 / -1 투표 ◄─────┘
▼
score = Σ deltas
│
├── score ≥ +N ──► brain_ops에서 더 높이 랭킹
└── score ≤ -3 ──► retired_at = now
retire_reason = 가장 최근의 부정적 사유
기본 검색에서 숨김
이력 조회는 여전히 가능
brain_ops를 통해 다시 살릴 수 있음
에이전트가(또는 사용자가) 작업하면서 잘못되거나 오래되었거나 반박된 개념에 플래그를 답니다. 나쁜 지식은 자동으로 사라집니다. 좋은 지식은 더 자주 노출됩니다. 수동 큐레이션 없이 두뇌가 스스로 정리됩니다.
트래젝토리 캡처 + 재생
에이전트가 다중 단계 작업을 성공적으로 완료할 때 — 새로운 MCP 도구 추가, 타입체크 오류 수정, 새 포맷 인제스트 — read / edit / bash 호출의 문자 그대로의 시퀀스와 각 호출이 반환한 내용이 capture_trajectory를 통해 트래젝토리로 저장될 수 있습니다. 유사한 작업을 하는 미래의 에이전트는 replay_skill(task)를 호출하여 레시피를 힌트로 받습니다. 드리프트 캐비엣(코드베이스 리비전 차이, 누락된 파일 참조, 실패 결과)도 함께 받아, 에이전트는 레시피가 캡처된 이후 무엇이 바뀌었는지 알 수 있습니다.
세션 N 성공적인 다중 단계 작업
│
▼
capture_trajectory(steps, outcome, metadata)
│
▼
source 행, source_type='trajectory'
FTS5용으로 청크 인덱싱
세션 N+M 다른 에이전트, 유사한 작업
│
▼
replay_skill(task) ──► 매칭된 트래젝토리 + 드리프트 캐비엣
│
▼
에이전트가 다시 도출하는 대신 레시피를 사용
모든 곳에서 스코프 인식
모든 소스, 개념, 트래젝토리는 (scope_kind, scope_key) 쌍을 가집니다. codebase, framework, language, personal, 또는 team 중 하나입니다. 검색은 기본적으로 스코프로 필터링되므로 저장소 A에서의 작업이 저장소 B의 결과를 오염시키지 않습니다. 코드베이스 식별성은 깔끔하게 일치합니다 — 같은 저장소의 SSH 클론과 HTTPS 클론은 동일한 스코프 키를 생성합니다. 동기화가 활성화되면 같은 스코프 라우팅이 와이어에도 적용됩니다. 즉, 디바이스가 관심을 가진 스코프만 그 디바이스에 머터리얼라이즈됩니다.
디바이스 간 동기화 — 모든 노트북에 두뇌를
로컬 우선 두뇌는 노트북이 두 대 생기는 순간까지는 훌륭합니다. Lumen의 동기화 레이어는 저장 시 암호화, 전송 시 암호화, 그리고 릴레이에 대해 제로 지식(zero-knowledge) 원칙을 지킵니다.
Device A Cloudflare Worker Device B
───────── (lumen-relay) ─────────
쓰기 발생
(concept / trajectory / feedback / retire / truth_update)
│
▼ 같은 트랜잭션
sync_journal append
│
│ Tier 6 데몬 틱 (적응형 30s / 300s)
▼
X25519 + XChaCha20-Poly1305 엔벨로프
│
▼
POST /relay/{user_hash}/journal ───────────► D1 행 저장
불투명한 암호문만
식별 불가능한 해시로 키잉
│
▼ Device B의 데몬이 폴링
▼
GET /relay/{user_hash}/journal?since=cursor
│
▼
엔벨로프 복호화 (Kx에서 유도된 X25519)
│
▼
op별 apply 핸들러
│
▼
Device B의 lumen.db 업데이트
B의 다음 세션이 그것을 찾음
릴레이가 보는 것
user_hash sync_id (UUIDv7) envelope (ciphertext) received_at
─────────── ────────────────── ───────────────────── ──────────
abc1... 01h93... opaque bytes 2026-05-19T..
abc1... 01h94... opaque bytes 2026-05-19T..
그게 전부입니다. 내용 없음. 스코프 없음(필터링을 위한 HMAC 태그만). 사용자의 Kx가 유도하는 것 외의 디바이스 식별성 없음. 서로 다른 마스터 키를 가진 두 사용자는 완전히 다른 네임스페이스로 라우팅되며, 서로의 블롭을 읽을 수 없습니다.
A → 릴레이 → B 로 흐르는 저널 엔트리
Device A Cloudflare Worker Device B
┌───────────────┐ ┌──────────────────┐ ┌───────────────┐
│ Claude Code │ │ 불투명한 암호문 │ │ 다음 세션에서 │
│ 세션 │ │ 만 저장 │ │ 두뇌가 발견 │
├───────────────┤ ├──────────────────┤ ├───────────────┤
│ capture() │ ●─────▶ │ │ ────▶●│ 데몬 폴링 │
│ ↓ store + │ │ D1 행 키: │ │ ↓ 엔벨로프 │
│ journal │ │ SHA256(Kx)[:16] │ │ 복호화 │
│ ↓ 엔벨로프 │ │ │ │ ↓ 로컬 apply │
│ 봉인 │ │ │ │ │
└───────────────┘ └──────────────────┘ └───────────────┘
POST · 봉인됨 GET · 봉인됨
◆ Kx (32바이트) — 마스터 키, 디바이스에만 존재.
릴레이는 이로부터 어떤 것도 유도할 수 없음.
● XChaCha20-Poly1305 봉인 · 엔벨로프마다 새 X25519 키페어.
와이어를 통과하는 것은 이것뿐임.
두 개의 암호화된 패킷만이 와이어를 통과합니다 — 릴레이는 평문도, 스코프도 보지 못하며, 오직 불투명한 봉인된 엔벨로프와 user-hash 라우팅 키만을 봅니다.
CRDT인 척하지 않는 정직한 LWW
두 디바이스가 같은 개념의 compiled_truth를 거의 동시에 편집할 수 있습니다. 우리는 updated_at으로 해소하고, 진 쪽을 device_id와 함께 concept_truth_history 테이블에 추가합니다.
device A: T₁에 truth_update
device B: T₂에 truth_update (T₂ > T₁)
양쪽 디바이스에서 apply:
incoming.updated_at > existing.updated_at ?
│ │
▼ ▼
winner 승리 loser 보존
UPDATE concepts SET INSERT concept_truth_history
truth = winner (slug, truth, updated_at, device_id)
│
▼
나중에 수동 머지를 위해
감사 행을 조회 가능
자유 텍스트가 CRDT-머지 가능한 척하기보다 이 방식을 택한 이유는 디버깅 가능성이 마법처럼 보이는 것보다 더 중요하기 때문입니다. truth가 잘못 보일 때 누가 언제 무엇을 썼는지 정확히 추적할 수 있습니다.
Tier 6 데몬
수동 lumen sync push는 사용자가 더 이상 그것을 입력하지 않는 순간까지만 좋습니다. Tier 6 데몬이 수동 루프를 자율 루프로 바꿉니다.
lumen sync daemon install
│
▼
launchd plist (macOS) / systemd --user unit (Linux)
│
▼
장수명 틱 루프:
latest_sync_id 워터마크를 프로브
케이던스 결정: Active 30s 저널 압력 또는 최근 pull 행이 있으면
Idle 300s 아무것도 푸시되지 않은 채 N번의 빈 틱 후
푸시 결정: 5초의 조용한 기간 후 배치 푸시
pull은 항상 실행
pull된 항목 apply
다음 틱까지 슬립
한 번 설치한 뒤로는 동기화 명령을 다시 입력할 일이 없습니다. 노트북 A에서 지식을 캡처하면 30초 뒤 노트북 B에 도착합니다. B에서 어떤 개념에 피드백을 주면 30초 뒤 모든 디바이스에서 점수가 반영됩니다. 서브스트레이트는 보이지 않게 됩니다.
Lumen을 구별 짓는 것
지금 설치 가능한 대부분의 "AI 메모리" 또는 "RAG" 도구는 벤더의 클라우드에 자리하며, 사용자의 자료를 벤더의 인덱스로 인제스트하고, API를 통해 검색 결과를 반환합니다. 편의성은 분명하지만 프라이버시 측면은 심각합니다. 사용자의 읽기 목록은 어쩌면 가장 민감한 데이터 중 하나입니다 — 무엇을 배우고 있고, 무엇에 혼란을 느끼며, 무엇을 만들고 있는지를 모두 드러냅니다. 그러한 데이터는 본인의 머신에 있어야 합니다.
Lumen이 다르게 하는 몇 가지 구체적 사항입니다.
기본값이 로컬 우선. 노트북 위의 SQLite. CLI, 웹 대시보드, MCP 서버 모두 같은 파일을 읽습니다. 사용자가 동기화를 옵트인하지 않는 한 노트북을 떠나는 데이터는 없습니다. 동기화 레이어는 종단 간 암호화되어 있고, 릴레이는 세 번의 wrangler 명령으로 자체 호스팅할 수 있는 단일 파일 Cloudflare Worker입니다.
벡터 데이터베이스 없음. Lumen은 의도적으로 dense embedding을 주력으로 사용하지 않습니다. BM25 + TF-IDF + graph walk의 조합은 임베딩 서버, 인덱스 리빌드, 모델 버전 관리의 운영 부담 없이 어휘적, 가중치 기반, 의미-구조적 검색을 모두 커버합니다. 의미적 유사도는 컴파일 그래프에 인코딩되며 — compile 중 LLM이 추출한 엣지로 — 질의 시 그래프 워크를 통해 노출됩니다. 벡터 임베딩은 원한다면 세 번째 레인으로 사용할 수 있지만, 절대 필수가 아닙니다.
에이전트 네이티브, 후처리가 아님. MCP 서버, 트래젝토리 캡처, 스코프 차원, 티어 스코어 보강, PII 게이트 — 이것들은 사후 보강이 아닙니다. 프로젝트가 현재의 모양으로 존재하는 이유 그 자체입니다. 코딩 에이전트를 사용하고 있다면, Lumen은 "또 하나의 관리해야 할 지식 도구"보다는 "처음부터 에이전트가 가졌어야 할 메모리"에 더 가깝습니다.
정직한 충돌 해소. 이력 테이블을 가진 last-write-wins는 화려하지 않지만 정확하고 디버그할 수 있습니다. 우리는 compiled_truth가 마법처럼 CRDT라고 우기지 않습니다.
합성 단계까지는 결정론적. 모든 단계 — 인제스트, 청크, 중복 제거, 검색, 그래프 순회, alias 머지, 스코어링, 동기화 — 는 같은 입력이 주어지면 결정론적입니다. 비결정론적인 단계는 LLM compile과 ask뿐이며, 둘 다 재현성을 위해 전체 요청/응답 로그를 audit.log에 기록합니다.
앞으로의 방향
지금 가장 큰 관심사는 자율성(autonomy)과 다중 디바이스 일관성(parity)입니다.
- Tier 6 데몬이 이번 달에 출시되었습니다. 한 번 설치하면 동기화는 완전히 백그라운드입니다.
- MCP fire-and-forget 푸시(이슈 #30)는 에이전트가 만든 저널 쓰기를 즉시 동기화 이벤트로 만들어 디바이스 간 전파 지연을 약 60초에서 약 5초로 줄입니다.
lumen sync daemon logs --follow(이슈 #31)는 로그 파일을 grep하지 않고도 CLI에서 데몬을 관찰 가능하게 만듭니다.
목표는 첫 커밋 이후로 바뀌지 않았습니다. 작업의 내용을 외부로 흘리지 않으면서 그 작업에 점점 더 능숙해지는 로컬 우선 지식 컴파일러. 에이전트에게 세션을 넘어 복리로 성장하는 지속 가능한 두뇌를 제공하는 시스템. 그리고 사용자에게 절대 동기화 명령을 입력하라고 요구하지 않는 도구.
lumen-kb로 빌드. MIT 라이센스. 소스는 Sardor-M/Lumen에 있습니다.
