8분 분량

Memory.Wiki가 실제로 어떻게 동작하나.

문서가 생기고, 번들이 묶이고, 허브가 자동 발행되고, 수정이 전파되고, 어떤 AI라도 그 URL을 읽습니다. 이 페이지는 전체 라이프사이클을 그대로 보여줍니다 — 클라이언트에서 무엇이 일어나는지, 서버에서 무엇이 일어나는지, 외부 AI가 당신의 URL을 가져갈 때 무엇을 보는지.

1. 문서가 태어나는 순간

AI 대화의 유용한 한 덩어리를 캡처합니다 — 예를 들어 ChatGPT가 설명해준 React hooks. Chrome 확장 아이콘을 누릅니다. 3초 후 영구 URL이 생깁니다: memory.wiki/abc123.

원본

AI 채팅 페이지

ChatGPT / Claude / Gemini

→

캡처

DOM → 마크다운

UI 제거, 코드 보존

→

저장

memory.wiki/abc123

v1 + 편집 토큰

캡처 파이프라인 / 처음부터 끝까지 3초

내부에서 일어난 일:

확장이 채팅 페이지의 보이는 DOM을 따라가며 깨끗한 마크다운으로 변환합니다 — 코드 블록, 리스트, 헤딩은 보존, UI와 광고는 제거.
그 마크다운을 API로 POST합니다. 서버가 영구 ID를 발급하고, 이후 수정용 편집 토큰을 반환하고, 본문 옆에 YAML frontmatter 블록을 저장합니다.
문서가 버전 1이 됩니다. 이후 모든 편집은 새 버전을 만들고, URL은 절대 바뀌지 않고, 독자는 항상 최신 버전을 봅니다.
백그라운드로 doc_ontology 잡이 큐에 들어갑니다. LLM이 본문을 읽고, 문서가 다루는 개념들을 추출하고, 그 사이의 typed edge를 작성합니다. 이게 문서 레벨 지식 그래프입니다 (다음 섹션 참고).

1b. 문서 자체의 지식 그래프

문서는 단순한 마크다운이 아닙니다 — 작은 그래프이기도 합니다. 저장하자마자 백그라운드 추출기가 문서가 실제로 다루는 개념들 (분량에 따라 5~15개) 과 그 사이의 typed edge를 뽑아냅니다. 번들 레이어에서 쓰는 같은 edge 어휘 (supports / elaborates / contradicts / exemplifies / contains / defines / depends_on) 를 그대로 쓰되, 한 문서로 스코프가 좁혀져 있습니다.

입력

문서 마크다운

memory.wiki/abc123

→

doc_ontology 출력

개념 React Hooks · useState · useEffect · Stale closure · Dependencies array
관계 useState 는 일종의 React Hooks
관계 useEffect 는 일종의 React Hooks
관계 Stale closure 는 인해 발생 useEffect
관계 Dependencies array 가 좌우 Stale closure

문서 하나 → 자체 개념 그래프 / 번들 + 허브 레이어와 같은 어휘

이 edge들은 concept_relations에 문서 id를 evidence로 저장됩니다. 같은 개념이 다른 문서에 나타나면, 사람이 [[wikilink]]를 칠 필요 없이 허브 레벨에서 그래프가 자동으로 문서들을 엮습니다.

AI가 raw 엔드포인트로 memory.wiki/abc123을 가져오면 보이는 내용:

markdown

---
mw_doc: 1
title: "React hooks crash course"
url: https://memory.wiki/abc123
updated: 2026-05-26T10:14:00Z
source: "ChatGPT (chat.openai.com)"
tags: ["react", "hooks", "useEffect", "rendering"]
concept_count: 9
relation_count: 7
---

# React hooks crash course
…clean markdown body, exactly what you saved.

## Concepts (this doc)
- **React Hooks** — function-only API for stateful logic
- **useState** — local component state
- **useEffect** — side effects, cleanup, deps
- **Stale closure** — captured state pitfall in callbacks
- …

## Concept relations (this doc)
- **useState** → *is a* → **React Hooks**
- **useEffect** → *is a* → **React Hooks**
- **Stale closure** → *caused by* → **useEffect**
- **Dependencies array** → *governs* → **Stale closure**
- …

그게 Document URL의 모든 contract입니다: 깨끗한 마크다운 본문, AI에게 어떤 스코프를 받았는지 알려주는 frontmatter 블록, tags 리스트, 그리고 본문 아래에 추가되는 구조화된 grounding 시그널 — 문서 자체의 concept 그래프. SDK 없음, 인증 없음, rate limit 없음. 부록 빼고 공백만 정리한 본문이 필요하면 ?compact를 붙이세요.

2. 문서에서 번들로

문서 하나도 유용합니다. 같은 주제의 문서 12개가 모이면 그 이상이 됩니다 — 큐레이션된 리딩 리스트에 cross-document 인사이트가 얹힌 것. 그게 번들입니다: memory.wiki/b/bnd789.

memory.wiki/abc123

React hooks crash course

memory.wiki/def456

RSC field notes

+ 문서 10개 더

…

→

memory.wiki/b/bnd789

테마 RSC와 클라이언트, hook 조합
인사이트 3개 문서 동의, 2개 상충
개념 Hooks · Server Components · Suspense
핵심 + 정렬된 링크 리스트

N개 문서 → 1개 번들 URL / 분석은 캐시, 매 fetch마다 재실행 안 함

번들은 두 가지 방식으로 만듭니다. 에디터에서 직접 문서를 골라 묶거나, AI에게 묶어달라고 요청합니다 ("React 렌더링 관련된 거 다 묶어줘"). 어느 쪽이든 번들은 영구 URL을 얻습니다.

번들이 처음 분석될 때 LLM 한 번이 추출합니다: 한 줄 description, 문서들을 가로지르는 테마 3~5개, cross-document 인사이트와 모순점, concept relations, 핵심 takeaway. 분석은 번들의 digest에 캐시되고, 매 fetch마다 재생성되지 않습니다.

번들 URL은 분석을 인라인으로 함께 보내므로 받는 AI는 이전 AI의 작업을 공짜로 이어받습니다:

markdown

---
mw_bundle: 1
id: bnd789
title: "Frontend craft"
url: https://memory.wiki/b/bnd789
document_count: 12
updated: 2026-05-26T10:14:00Z
analysis_generated_at: 2026-05-24T08:00:00Z
analysis_stale: false
---

# Frontend craft
> A reading list around modern React, hooks, and rendering.

## Themes
- React Server Components vs client components
- Hook composition patterns
- Performance budgets

## Cross-document insights
- Three docs agree on "lift state up only when needed"
- Two docs contradict on RSC + Suspense boundaries

## Key takeaways
- ...

## Concepts (this bundle)
- **React Hooks** (from "React hooks crash course")
- **Server Components** (from "RSC field notes")
- **Suspense** (from "Streaming with Suspense")

1. [React hooks crash course](https://memory.wiki/abc123) — the primer
2. [RSC field notes](https://memory.wiki/def456) — production lessons
…

Compact 번들 digest는 모든 멤버 문서를 인라인하는 것보다 토큰이 5~9× 저렴하면서도, 받는 AI가 필요시 특정 문서로 walk할 수 있게 해줍니다. 그 trade-off가 번들 레이어가 존재하는 이유 전부입니다.

3. 허브

당신의 허브는 발행한 모든 문서와 번들을 담는 namespace입니다. 제 것은 memory.wiki/@hyunsang입니다. 당신 것은 memory.wiki/@<you>입니다.

memory.wiki/@you

문서 47개 발행, public
번들 8개 큐레이션, 분석 캐시 포함
index.md 사람이 읽는 디렉토리
SCHEMA.md 기계가 읽는 구조
log.md 시간순 히스토리
llms.txt AI가 찾아낼 매니페스트
Concept index 허브 전체, 자동 추출

namespace 하나. 저장하면 전부 자동 발행.

허브 URL은 단일 문서를 가져오지 않습니다 — AI가 당신의 지식 레이어에 뭐가 있는지 파악할 수 있는 매니페스트를 반환합니다. llms.txt 표준을 따라:

markdown

# Hyunsang's hub — memory.wiki/@hyunsang

> Personal knowledge base, public docs.

## Documents
- [React hooks crash course](https://memory.wiki/abc123) — the primer
- [Cross-AI eval methodology](https://memory.wiki/ghi321) — how we benchmark
…

## Bundles
- [Frontend craft](https://memory.wiki/b/bnd789) — React reading list
- [LLM eval](https://memory.wiki/b/bnd654) — methodology notes

## Concepts (hub-wide)
- React Hooks, Server Components, Suspense, RAG, hybrid retrieval, …

매니페스트는 발행하는대로 자동으로 빌드됩니다 — 수동 큐레이션 없음. 허브는 index.md (사람용), SCHEMA.md (기계용 구조), log.md (시간순 히스토리) 도 자동 발행합니다. 허브 전체에 걸친 concept index는 모든 문서를 가로질러, 같은 아이디어가 어디어디에 등장하는지를 드러냅니다.

Claude나 ChatGPT에 허브 URL을 한 번 붙여넣는 것으로 충분합니다 — AI가 매니페스트를 가져와서, 필요한 문서로 walk합니다. 전체 corpus가 한 context window에 들어갈 필요가 없습니다.

4. 수정이 일어날 때

문서를 편집합니다 — URL은 그대로. 새 버전이 스냅샷됩니다. 독자는 항상 최신을 보지만, 버전 간 diff를 볼 수도 있고, 이전 버전을 복원할 수도 있습니다.

저장: memory.wiki/abc123에 편집을 저장. URL 그대로, 버전이 v2로.

번들: 이 문서를 포함하는 번들들이 digest에 analysis_stale: true 표시.

허브 매니페스트: 재발행 — llms.txt, index.md, log.md 전부 업데이트.

Concept index: 백그라운드에서 증분 upsert — 전체 재빌드 없음.

재분석: 번들 재분석 (클릭 또는 스케줄) 으로 stale 플래그를 지우고 인사이트를 갱신.

한 번의 편집 → 번들과 허브로 자동 전파.

결과: 모든 URL이 항상 살아있음. 404 나는 거 없음. Stale 상태는 숨겨지지 않고 드러남. 노트를 위해 CI 파이프라인을 유지하지 않아도 됨.

5. 붙여넣었을 때 AI가 보는 것

전체 아키텍처는 받는 AI가 깨끗하게 읽을 수 있을 때만 의미가 있습니다. Claude나 ChatGPT에 Memory.Wiki URL을 붙여넣었을 때 일어나는 일:

사용자

URL 붙여넣기

memory.wiki/@you

→

/raw fetch

인증 없음, SDK 없음

→

서버

마크다운 반환

frontmatter + 본문

Claude · ChatGPT · Gemini · Cursor · Codex 모두 동일 흐름.

markdown

You: read memory.wiki/@hyunsang and answer using my notes
Claude: (fetches /raw/hub/hyunsang → gets the manifest)
        (walks links to specific docs as needed)
        Based on your "Cross-AI eval methodology" doc and
        "Frontend craft" bundle, here's the answer …

Claude (또는 ChatGPT, Gemini, Cursor) 가 raw 엔드포인트 — /raw/hub/<you> — 를 치고 frontmatter 블록이 붙은 plain 마크다운을 받습니다. Frontmatter가 AI에게: 이건 허브 매니페스트지 단일 문서가 아니라고 알려줍니다. AI는 매니페스트의 링크를 따라 필요한 문서로 walk합니다.

받는 쪽은 SDK도, API 키도, 플러그인도 필요 없습니다. URL을 fetch할 수 있는 능력만 있으면 됩니다 — 모든 모던 AI 도구가 갖춘 능력.

토큰 경제: 어떤 raw URL에든 ?compact를 붙이면 공백과 quote 블록이 제거됩니다 (보통 30~50% 절감). 번들에 ?full=1을 붙이면 모든 멤버 문서가 인라인됩니다. 번들의 ?graph=0은 분석 섹션을 뺍니다. 옵션들은 조합 가능.

6. 실제로 동작하나?

URL contract는 주장입니다. 독립적으로 검증하기 위해 오픈 cross-AI 평가를 돌립니다 — 모든 주요 AI에 대해, 모델이 학습 때 봤을법한 허브와 절대로 못 봤을 허브 둘 다.

핵심: 보이지 않는 허브에 대한 paste 모드에서 faithfulness 100%. Browse 모드 (AI가 URL을 직접 fetch) 98% — 2% 갭은 fetch 실패지, contract 실패가 아님. Adversarial refusal도 100% — URL 스코프 밖의 것을 물으면 AI가 답을 지어내지 않고 거부.

전체 방법론, judge 프롬프트, 라운드별 결과, 재현 레시피 → 벤치마크 페이지 보기.

7. 일부러 만들지 않은 것

예상했을 법한 세 가지, 일부러 빠뜨린 것:

[[wikilink]] 없음. 전통적 위키는 사람이 그래프를 타이핑하게 합니다. Memory.Wiki는 concept index를 자동 추출합니다 — 링크는 AI가 걸고, 당신은 글만 씁니다.
SDK 없음. 인터페이스는 URL입니다. URL을 fetch할 수 있는 모든 것이 클라이언트.
독자 블록 없음. 포맷은 마크다운 그 자체. Memory.Wiki가 내일 사라져도 당신 문서는 여전히 어떤 에디터에서든 열리는 마크다운 파일.

그게 시스템 전부. 직접 구현하고 싶으면 오픈 스펙이 모든 엔드포인트와 query 옵션을 문서화하고 있습니다.