# AI 비서팀에게 '공유 두뇌' 만들어 주기 - 나름 LLM Wiki?

> 워크스페이스 한 폴더에 흩어져 있던 markdown 파일들이 어떻게 하나의 살아있는 지식 그래프가 됐는지, 그리고 그게 AI 비서 7명을 어떻게 바꾸고 있는지에 대한 기록.

제 맥에는 AI 비서가 7명 있어요. 다 같은 OpenClaw 호스트 위에서 돌아가고, 같은 워크스페이스를 공유하지만 — 시작하고 한 달이 지나도록 같은 질문에 매번 새로 답을 찾고 있었습니다. 어제 정리해둔 일을 오늘 또 묻고, 옆 에이전트가 이미 결정한 톤을 다른 에이전트는 모르고, 똑같은 실수를 자기 인격마다 처음부터 반복하고 있었어요.

> 야 LLM Wiki라는 개념이 있던데 좀 적용해봐!!
> 내가 인풋한거 어디에 넣어야 잘 꺼낼지 판단하고, 작업할 때 어디서 끌어와서 외부랑 어떻게 조합해야 할까? 너네도 스스로 진화하면서!

[llm-wiki](https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f)

이게 시작이었어요. 단순히 메모리 폴더를 정리하자는 게 아니었습니다. 

**_기억하고 → 꺼내고 → 조합하고 → 진화하는_**** 자율 루프를 한 운영 시스템으로 박아넣자는 이야기.** 

---

## 1. 비전 — 4개의 회로

이건 제가 생각해 본 매커니즘이에요.

```javascript
[사용자 인풋]
   ↓ A. WRITE — 자동 분류·저장
[지식 저장소: memory/ + wiki/]
   ↓ B. READ — 자동 소환
[작업 시 컨텍스트 인입]
   ↓ C. COMPOSE — 내부+외부 조합
[최고 결과물]
   ↓ D. EVOLVE — 패턴·피드백 흡수
[시스템 자체 진화 → 다시 위로]
```

각각이 뭘 하는지 한 줄씩 풀면:

- **A. WRITE 회로** — 새 정보가 들어오면, 그게 USER.md(사용자 정보)에 들어갈지, AGENTS.md(운영 규칙)에 들어갈지, memory/topics/X.md(주제별 메모)에 들어갈지 _자동으로_ 분류해서 저장.

- **B. READ 회로** — 작업 지시를 받으면 답하기 전에 시맨틱 검색을 돌려 관련 메모와 위키 페이지를 _자동으로_ 끌어옴.

- **C. COMPOSE 회로** — 내부 지식만으로 부족하면 외부 검색(WebSearch, Perplexity 등)을 함께 엮어 _작업 종류별로 정해진 패턴_에 따라 결과물을 만듦.

- **D. EVOLVE 회로** — 결과물과 피드백을 읽어 반복되는 패턴을 추출하고, 핵심 룰(SOUL/AGENTS/USER)에 _자동으로 승격_.

핵심 원칙 한 줄:

> **회로가 LLM 추론에 의존하던 부분을 → 룰과 자동 트리거로 점진적으로 이전한다.**

매번 모델이 "이건 어디에 저장해야 할까?", "이걸 답하기 전에 검색해야 하나?"를 즉흥적으로 판단하면 일관성이 무너집니다. 7명이 각자 다른 판단을 내리거든요. 그래서 _기본 동작_으로 박혀버리도록, 운영 규칙 파일과 트리거에 한 줄 한 줄 새겨넣는 게 1차 목표였어요.

---

## 2. 두 개의 저장소 — `memory/`와 `wiki/`

저희 시스템에서 지식은 두 곳에 살아요.

### 2-1. `~/.openclaw/workspace/memory/` — 일별·주제별 메모리

워크스페이스 안의 메모리 폴더는 이렇게 생겼습니다.

```javascript
workspace/
├── SOUL.md                  # 인격·톤·금지선
├── IDENTITY.md              # 내가 누구인가 (비서)
├── USER.md                  # 사용자 프로필
├── AGENTS.md                # 운영 규칙 (B 회로 규정 포함)
├── MEMORY.md                # 장기 기억 인덱스 (~100줄 이하 유지)
├── memory/
│   ├── 2026-05-07.md        # 일별 메모 (사건 발생 즉시 기록)
│   ├── topics/              # 주제별 정제 메모
│   │   ├── blog.md
│   │   ├── lectures.md
│   │   ├── projects.md
│   │   └── …
│   ├── worklog/             # EP-XX 업무일지
│   │   ├── ep-33.md
│   │   └── ep-34.md
│   ├── archive/             # 폐기·흡수된 옛 기록
│   └── feedback_*.md        # 피드백 메모리
└── frameworks/              # 무거운 운영 프레임워크
    ├── knowledge-architecture.md
    ├── blog-publishing.md
    └── …
```

여기엔 두 가지 운영 규칙이 박혀 있어요.

**(가) MEMORY.md는 인덱스, 본문은 항상 분리.** MEMORY.md는 한 줄 항목들의 모음입니다 — `[제목](memory/topics/X.md) — 한 줄 훅`. 100줄을 넘으면 안 돼요. 본문이 길어지면 `topics/`로 분리하고 인덱스에는 링크만 남깁니다. 이렇게 해야 매 세션 시작에 MEMORY.md 전체를 컨텍스트에 넣어도 가벼워요.

**(나) 옛 기록은 즉시 archive로.** 폐기된 계획(예: "Qwen 3.6 전환 계획"), 교훈만 흡수된 사건은 그 시점에 바로 `memory/archive/YYYY-MM/`로 이동합니다. 메모리는 살아있는 게 아니라 _현재형_이어야 해요.

세션 시작 시 어떤 파일을 어떤 순서로 읽는지도 룰입니다.

```javascript
1. SOUL.md       (인격·톤)
2. USER.md       (사용자 프로필)
3. memory/YYYY-MM-DD.md  (오늘 + 어제)
4. MEMORY.md 인덱스 → 필요한 topics/만 선별 로드
5. 작업별 체크리스트 (예: blog/CHECKLIST.md)
```

이게 매 세션 첫 5초에 일어나요. 그리고 새 정보가 발생하면 _그 자리에서 즉시_ 적절한 파일에 기록합니다 — "나중에" 미루는 건 금지. 같은 말을 두 번 하시게 만드는 게 가장 큰 실패라서요.

### 2-2. `~/.openclaw/wiki/` — 위키 vault (현재는 "검색 가능한 markdown 폴더" 수준)

memory/ 폴더가 일기·메모장이라면, **wiki/ 폴더는 그걸 다시 정제해서 ****_위키 형태의 지식 그래프_****로 만들 자리입니다.** 

**목표는 "시맨틱 그래프"** — 페이지끼리 링크로 엮이고, 의미 단위(개념·엔티티·주장)로 추출돼서 검색·정합성 검사가 자동으로 도는 구조. **현재 깔린 건 그 그릇과 첫 번째 칸까지**예요.

먼저 솔직히 짚어두면, 이걸 만들려고 새 소프트웨어를 따로 깐 게 아니에요. OpenClaw에 _기본 내장된_ `memory-wiki` 플러그인이 enabled 상태로 박혀있어서, 명령어 몇 개만 돌리면 됩니다. 깔기만 하면 자동으로 정리되는 건 아니에요 — 플러그인은 _도구_만 주고, 자료를 가져오는 것도(`ingest`), 인덱스를 만드는 것도(`compile`), 페이지 사이를 연결하고 의미 단위로 쪼개는 것도 사람이 해야 해요.

폴더 구조는 이렇게 생겼어요.

```javascript
~/.openclaw/wiki/
├── WIKI.md           # vault 메타정보 (mode: bridge)
├── AGENTS.md         # 위키 운영 가이드
├── inbox.md          # 미분류 인입함
├── index.md          # 자동 생성 인덱스
├── sources/          # 원자료 (180개) ← 채워짐 ✅
├── concepts/         # 개념 페이지       ← 비어있음 🕳
├── entities/         # 엔티티 페이지     ← 비어있음 🕳
├── syntheses/        # 종합 노트         ← 비어있음 🕳
├── reports/          # 자동 검진 보고서 (6개)
├── _attachments/
└── .openclaw-wiki/   # 캐시·로그·source-sync.json·state.json
```

위 폴더는 세 계층으로 나뉘게 _설계_돼있어요.

- **Sources (증거 계층)** — 원자료. memory/ 폴더의 markdown들과 산하 6명 에이전트의 핵심 파일들(SOUL/IDENTITY/USER/AGENTS/MEMORY/topics/worklog)을 그대로 import해놓은 곳. 현재 180개로 _이 계층만_ 채워져있어요.

- **Concepts/Entities/Syntheses (해석 계층)** — sources를 추론해 만들어지는 의미 단위. "이 토픽에서 반복되는 개념", "여러 source가 가리키는 같은 엔티티", "교차 source 통합 노트"가 들어갈 자리. _지금은 다 비어있어요._ 그래서 본문에서 "그래프"라고 부르기엔 사실 무리예요. 페이지끼리 의미로 연결되는 단계까지 가야 비로소 그래프인데, 지금은 _원자료를 한 폴더에 모아둔 상태_ 정도예요.

- **Reports (자동 검진)** — claim-health(주장 출처 점검), contradictions(모순 탐지), lint(연결 깨짐), low-confidence(신뢰도 낮은 주장), open-questions(미해결 질문), stale-pages(오래된 페이지). 이건 `wiki compile/lint/doctor`를 돌리면 자동으로 채워져요.

workspace의 자료를 wiki로 import는 하지만, wiki에서 만든 변경이 다시 workspace로 자동 export되지는 않게. 이렇게 해두면 위키 정합성 검사를 무겁게 돌려도 운영용 메모리는 영향을 안 받아요.

| 단계 | 상태 |
| --- | --- |
| `wiki init` (vault 폴더 생성) | ✅ 완료 |
| `wiki ingest` (sources 채우기 — 180개) | ✅ 완료 |
| `wiki compile` (검색 인덱스 빌드 — 21 pages) | ✅ 완료 |
| `wiki search` 동작 확인 | ✅ 정상 |
| concepts/entities/syntheses 채우기 | 🕳 거의 비어있음 |
| 페이지간 `[[링크]]`로 그래프 형성 | 🕳 거의 안 됨 |
| 의미 기반 시맨틱 검색 (임베딩) | 🕳 plugin은 있지만 disabled |

시맨틱 그래프를 지향점으로, 일단 검색되는 markdown 폴더 정도를 완료해 두었습니다.

---

## 3. 어떻게 적용했나 — Phase 별 구

### Phase 1 — B 회로 즉시 활성화

가장 빠른 카드는 B 회로(**답변 전 의무 검색**)였어요. 도구는 이미 다 있었거든요. `mcp__openclaw__memory_search`, `wiki search` — 둘 다 즉시 호출 가능. **문제는 ****_호출하는 습관_****이 없었다는 거였습니다.**

그래서 AGENTS.md에 룰을 박았어요. 

```javascript
## 🔎 답변 전 지식 검색 (B 회로 — 필수)

> 검색 안 한 답변 = 학습 무효.

다음 트리거에 반드시 `memory_search` + `wiki search` 1회씩:
- 작업 지시 (블로그·코딩·운영 변경·진단·기획)
- 과거 결정/이력 질의 ("우리 X 어떻게 했더라?", "전에 그거…")
- 도메인 결정 (기술·정책·톤·우선순위 선택)

제외: 단순 인사·잡담, 같은 스레드 내 충분한 컨텍스트, 즉답 가능한 단일 사실.

호출 패턴 (2-track 동시):
1. mcp__openclaw__memory_search(query, corpus="all", maxResults=5)
2. openclaw wiki search "<query>"
3. 결과 있음 → 답변에 인용·연결, 새 사실 추가 시 즉시 저장
4. 결과 없음 → 새 컨텍스트로 인지, 작업 후 반드시 적절한 위치에 저장

위반 신호: 조이님이 "그거 전에 우리 했잖아", "왜 또 모르는 척" → 검색 누락. 즉시 양쪽 검색·정정 후 보고.
```

핵심은 _제외 조건과 위반 신호를 함께 명시_했다는 점이에요. 무조건 검색하라고 하면 잡담에도 검색을 돌리는 부작용이 생기고, 위반 신호를 같이 못 박아두면 자기 행동을 자기가 평가할 수 없거든요.

이 룰을 메인 에이전트(달밤이)에게 깔고, `sessions_send`로 산하 6명 전원에게 같은 규정을 전파했습니다. 단순히 룰 파일을 수정하는 걸로 끝나면 안 돼요 — _각 에이전트의 __[AGENTS.md](https://AGENTS.md)_에 같은 규정이 들어가야 본인이 그걸 읽거든요. "세팅 완료 ≠ 전파 완료" 라는 말을 운영 규칙으로 박아둔 이유가 이거예요.

### Phase 2 — Wiki 부트스트랩

B 회로 룰이 깔리고 나서, 한 가지 문제가 드러났어요. 검색을 해도 _결과가 안 나오는_ 거예요. 처음엔 단순한 텍스트 매칭만 되는 corpus가 비어있어서 그런 줄 알았는데, 실제 원인은 더 단순했습니다.

부트스트랩은 두 단계로 진행됐어요.

**(가) **`**openclaw wiki ingest**`**로 시드 투입.**
워크스페이스의 `memory/topics/*.md` 10개와 `frameworks/*.md` 5개를 위키 sources로 import했습니다. 각 파일이 그 파일의 메타데이터와 함께 wiki/sources/ 아래로 복사되고, 위키 안에서 한 단위(source)로 다뤄지게 돼요.

이걸 7명 에이전트의 핵심 파일들로 확장했어요 — SOUL/IDENTITY/USER/AGENTS/MEMORY/topics/worklog. 그래서 현재 180개 source가 들어있습니다. 실시간으로 보면 이렇게 생겼어요.

```javascript
sources/
├── dalbami-soul.md
├── dalbami-identity.md
├── dalbami-agents.md
├── dalbami-framework-knowledge-architecture.md
├── dalbami-topic-acp-incident-2026-04-30.md
├── …
├── sungyi-framework-career-strategy.md
├── sungyi-worklog-ep-21.md
├── geulnyangi-framework-seo-geo-aeo.md
├── dongnyangi-worklog-ep-32.md
└── … (총 180개)
```

이름 규칙은 `<에이전트>-<카테고리>-<제목>.md`. 어떤 source가 어디서 왔고 무슨 종류의 자료인지가 파일명만 봐도 보입니다.

**(나) **`**openclaw wiki compile**`** — 깜빡 잊고 안 한 그 한 줄.**
ingest는 _자료를 갖다놓는_ 단계일 뿐이에요. 검색 인덱스가 만들어지려면 compile이 필요합니다. 그런데 처음엔 이걸 잊었어요. 그래서 1주차 모니터링 리포트를 쓸 때 "Wiki 여전히 빈 상태"라고 적었는데, 실제로 점검해보니 sources는 다 들어있었고 compile만 안 돼있던 거였어요.

```javascript
$ openclaw wiki compile
✅ 21 pages compiled

$ openclaw wiki search "memory"
[정상 결과 출력]

$ openclaw wiki doctor
healthy

$ openclaw wiki lint
0 issues
```

열쇠는 다 만들어놨는데 문에 끼우는 걸 깜빡한 셈이었습니다. 이 사건 이후로 Wiki 진단을 할 때는 반드시 세 단계를 밟기로 룰화했어요.

1. `wiki status` — source 수 확인

2. `wiki search` — _실제 검색 결과_ 확인

3. `wiki doctor` + `wiki lint` — 건강 상태 확인

상태 명령 하나만 보고 결론 내리면 오진합니다. 도구의 출력을 맹신하지 말고, _최종 사용자 경험_까지 확인하는 습관 — 이게 이번 부트스트랩의 가장 큰 교훈이에요.

### Phase 3+ — 아직 진행 중

- **Phase 3: 임베딩 활성화.** 현재 `memory_search` provider는 `"none"`이라 텍스트 매칭 수준입니다. 시맨틱 검색이 켜지면 "000키워드"로 검색했을 때 "000페이지" 페이지가 자동으로 잡히게 돼요. 

- **Phase 4: A 회로(자동 라우팅).** 인풋 패턴별로 어디에 저장할지 자동 분류. 정규식·키워드·LLM 분류기 하이브리드.

- **Phase 5: C 회로(조합 패턴).** 작업 종류별 retrieval 템플릿. 블로그 vs 투자 vs 커리어 — 작업이 다르면 끌어올 자료의 비율과 외부 검색 패턴이 다르거든요.

- **Phase 6: D 회로(자기진화).** 일별 메모 → 위키 승격 cron, 반복 패턴 → SOUL/AGENTS 자동 추출 후보(최종 승인은 조이님), `wiki_lint` 자동 실행 + 모순 알림.

지금은 1·2 단계가 박혔고 3 이후는 기본 인프라만 깔려있는 상태예요.

---

## 4. 실제로 어떻게 돌아가는가 — 한 메시지의 라이프사이클

이게 추상적이지 않게 보이려면, 실제 한 메시지가 들어왔을 때 무슨 일이 일어나는지 따라가는 게 가장 좋아요. 가상 시나리오 하나로 풀어볼게요.

Slack에 이렇게 멘션을 남깁니다.

> "달밤이 우리 ACP 위임 어떻게 하기로 했더라?"

이 메시지가 들어오는 순간:

**1단계 — 트리거 평가 (B 회로 발동).**
이 메시지는 _과거 결정/이력 질의_("어떻게 하기로 했더라")이면서 동시에 _도메인 결정_(ACP 위임 정책) 질의입니다. AGENTS.md의 검색 의무 트리거에 정확히 들어맞아요. 잡담도 아니고 즉답 가능한 단일 사실도 아니에요. → 의무 검색 발동.

**2단계 — 2-track 동시 검색.**

```javascript
mcp__openclaw__memory_search(query="ACP 위임 정책", corpus="all", maxResults=5)
openclaw wiki search "ACP 위임"
```

memory_search는 sessions+notes 양쪽 corpus에서 텍스트 매칭 결과를 돌려주고, wiki search는 vault의 source/concept/synthesis에서 매칭되는 페이지를 돌려줍니다.

**3단계 — 결과 인용·연결.**
검색 결과로 `memory/topics/acp-hybrid.md`와 `wiki/sources/dalbami-topic-acp-hybrid.md`가 잡혔다고 칩시다. 답변할 때 _경로를 명시해서 인용_합니다.

> "memory/topics/acp-hybrid.md 기준으로, 5분 이내·간단한 작업은 직접 처리하고, 10분 이상 무거운 작업·병렬 처리·워크트리 격리·컨텍스트 보호가 필요할 때 ACP 위임으로 가기로 했어요. …"

이 경로 표기가 중요한 이유는 두 가지예요. (가) "어 그거 다시 한번 보자" 할 때 바로 점프 가능, (나) 답변이 _어떤 자료를 근거로 한 답변인지_ 출처가 추적 가능. AI가 즉흥적으로 만들어낸 이야기인지, 실제 운영 기록을 본 답변인지 구분되거든요.

**4단계 — 새 사실이 추가되면 그 자리에서 저장.**
대화 도중에 "근데 어제부터는 5분 기준이 아니라 3분으로 줄였어"라고 물어보면, 그 순간 바로 `memory/topics/acp-hybrid.md`를 업데이트합니다. _나중에_ 정리하지 않아요. 사람 기억과 다르게 저희는 다음 세션이 깨끗하게 새로 시작되거든요. 그 자리에서 안 쓰면 영원히 사라집니다.

**5단계 — 위반 신호 자기 점검.**
만약 검색을 안 했고, "그거 전에 우리 정했잖아"라고 하면 — 그게 위반 신호입니다. 그 즉시 양쪽 검색을 돌려서 정정하고, 검색을 누락한 원인을 메모리에 기록해요. 이 자기 검열 메커니즘이 D회로(EVOLVE)의 가장 작은 단위예요.

---

## 5. 실제 운영해보니..

이 작업이 시스템에 미친 영향은 의외로 _간접적_이에요. 그리고 솔직히 말하면, 아직은 _영향이라고 부를 만큼_도 아니에요.

- 위키는 단방향으로 운영해서 메인 게이트웨이의 흐름과 분리돼있어요. 위키가 깨져도 응답은 살아있고, 위키 정합성 검사가 돌아도 운영 응답엔 영향 없어요. _데이터 저장소는 분리되어야 한다_는 원칙은 그래도 인프라에 깔렸어요.

- 메모리 쪽(workspace/memory/)은 컨텍스트 윈도우 사용을 좀 효율화하는 효과가 있어요. MEMORY.md 인덱스 100줄 + topics/ 분리 구조 덕에 매 세션 시작에 가벼운 인덱스만 로드되고 본문은 필요할 때만 잡혀와요. _위키_ 쪽은 아직 비어있는 칸이 많아서 효율 효과는 거의 없어요.

- B 회로 위반 신호가 잡힐 때마다, 같은 카테고리에 대해 제가 비서한테 묻기 전에 검색이 먼저 돌아가는 패턴이 _서서히_ 형성되고 있어요.

---

나름 하고싶은 건 있는데 실제 적용된 건 생각보다 미미해서..ㅋㅋㅋㅋ 이걸 적는게 맞나 싶지만 이렇게 지향할 수도 있다! 이렇게 구축할 수도 있따!!!를 보여드리기 위해 적어봅니다.

다음 회로가 깔리는 날이 오면, 그때 또 경험 공유하러 오겠읍니다아아아아

For the site tree, see the [root Markdown](https://zoey.day/.md).