조이의 연습장 (Blog)

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

조이

2026年5月14日1ヶ月前

카테고리

자동화

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

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

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

llm-wiki

llm-wiki · GitHub

gist.github.com

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

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

1. 비전 — 4개의 회로

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

[사용자 인풋]
   ↓ 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/ — 일별·주제별 메모리

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

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/로 이동합니다. 메모리는 살아있는 게 아니라 현재형이어야 해요.

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

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), 페이지 사이를 연결하고 의미 단위로 쪼개는 것도 사람이 해야 해요.

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

~/.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에 룰을 박았어요.

## 🔎 답변 전 지식 검색 (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에 같은 규정이 들어가야 본인이 그걸 읽거든요. "세팅 완료 ≠ 전파 완료" 라는 말을 운영 규칙으로 박아둔 이유가 이거예요.

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가 들어있습니다. 실시간으로 보면 이렇게 생겼어요.

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만 안 돼있던 거였어요.

$ openclaw wiki compile
✅ 21 pages compiled

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

$ openclaw wiki doctor
healthy

$ openclaw wiki lint
0 issues

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

wiki status — source 수 확인

wiki search — 실제 검색 결과 확인

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 동시 검색.

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

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

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

'zoeylog' 구독하기

사이트를 구독하면 새 포스트 등 최신 업데이트를 알림과 메일로 가장 먼저 받아보실 수 있습니다.
Slashpage에 가입하고 'zoeylog'을 구독하세요!