[AX] LLM WIKI 개념 및 실제 사용 방법

참이 감자 2026. 8. 21. 21:51

1. LLM WIKI 개념

일반 메모장 vs LLM WIKI

일반 메모장은 내가 쓰고, 내가 분류하고, 내가 찾는다. 자료 100개를 넣으면 100개가 그냥 쌓인다. 많아질수록 지저분해지고, 어디 적었는지 기억이 안 나면 끝이다.

누적은 되는데 복리가 안 된다. 이게 핵심 문제였다.

LLM WIKI는 역할이 뒤집힌다. 나는 자료를 던져 넣기만 한다. AI가 똑똑한 조수처럼 읽고, 요약하고, 분류하고, 기존 노트와 연결해서 서랍에 넣는다. 찾을 때는 서랍을 뒤지는 게 아니라 조수에게 물어본다.

	일반 메모장	LLM WIKI
분류	내가 한다	AI가 한다
검색	키워드 검색, 폴더 뒤지기	자연어로 질문
자료가 늘면	지저분해진다	기존 노트까지 같이 갱신돼 더 똑똑해진다
근거 추적	"어디서 봤더라"	모든 노트에 `source` 경로가 박혀 있다

이 구조는 올해 4월 Andrej Karpathy가 공유한 "LLM wiki" 패턴을 따른 것이다. 요지는 세 줄이다.

raw 원본은 내가 고른다. 절대 안 바뀐다.
wiki 페이지는 LLM이 쓴다. 나는 읽기만 한다.
schema는 LLM에게 "어떻게 행동할지" 적어둔 규칙이다.

Karpathy 표현을 빌리면 "다시 유도하는 걸 멈추고, 컴파일하라(stop re-deriving, start compiling)". 질문할 때마다 검색해서 읽고 잊어버리는 RAG와 달리, 위키는 한 번 정리한 지식이 남아서 쌓인다.

LLM WIKI를 쓰는 이유

써보고 느낀 이유는 네 가지다.

1) 복리로 쌓인다.
자료 하나를 넣을 때마다 AI가 기존 노트들과 다시 연결하고 재정리한다. Karpathy 방식에선 원본 하나가 10~15개 위키 페이지를 건드린다고 한다. 그래서 "A랑 B 종합하면 어떻게 돼?" 같은 질문에 시간이 갈수록 더 잘 답한다. 자료 수가 아니라 연결의 밀도가 자산이 된다.

2) 사람은 판단만, 사무노동은 AI가.
무엇을 넣을지 고르는 것과 방향 잡는 것만 내가 한다. 분류·요약·연결·중복 체크·갱신은 전부 AI 몫이다. "정리 귀찮아서 미루다 자료가 증발하는" 일이 없어졌다.

3) 출처가 항상 남는다.
원본은 절대 건드리지 않고, 정리 노트마다 어느 원본에서 왔는지 적는다. AI가 정리한 내용이 틀려도 원본에서 다시 만들 수 있고, "이거 근거가 뭐야?"에 항상 답할 수 있다.

4) 검색 엔진 없이도 잘 찾는다.
뒤에서 자세히 쓰지만, 모든 노트에 "이 노트로 답할 수 있는 질문" 목록과 한/영 동의어가 미리 박혀 있다. 벡터DB 없이 grep만으로 질문과 노트가 바로 매칭된다. 이게 된다는 게 처음엔 좀 의외였다.

Obsidian + Claude Code로 사용하는 이유

왜 노션이 아니라 Obsidian인가? 파일이 내 PC에 .md로 그대로 있기 때문이다.

노션은 API를 거쳐야 해서 AI가 훑기에 느리고, 데이터가 남의 서버에 있다. Obsidian은 그냥 폴더와 마크다운 파일이다. 사람도 읽기 쉽고 AI도 읽기 쉽고, [[위키링크]]로 노트 간 연결을 그래프로 볼 수 있다. 나중에 도구를 바꿔도 파일은 남는다.

왜 채팅창이 아니라 Claude Code인가? 내 폴더의 파일을 직접 읽고 쓰는 AI이기 때문이다.

복붙하는 게 아니라, 터미널에서 vault 폴더를 열어두면 Claude가 raw를 읽고, 노트를 만들고, index를 갱신하고, lint를 돌린다. 여기에 두 가지 장치가 결정적이었다.

Hooks — 특정 시점(파일 수정 전, 질문 제출 시, 세션 종료 시)에 자동 실행되는 스크립트. "raw 수정하지 마"를 말로 하는 게 아니라 코드로 물리적으로 막는다.
Skills — SKILL.md에 절차를 적어두면 "이거 정리해줘" 한마디에 그 절차를 그대로 따른다.

정리하면 Obsidian은 저장소, Claude Code는 엔진, 규칙 파일(SCHEMA.md, CLAUDE.md)은 엔진에게 어떻게 움직일지 알려주는 설명서다.

2. 개인 위키 (PARA 구조)

먼저 혼자 쓰는 버전부터. 강의 녹취, 멘토링 회의록, 읽은 아티클이 주로 들어간다.

3 레이어 구조 (raw / compiled / SCHEMA)

뼈대는 세 층이다.

[1] raw/        ← 원본 금고. 강의 녹취·PDF·회의록. 절대 수정 X
      │  AI가 ingest(정리)
      ▼
[2] PARA 폴더   ← AI가 정리한 노트(.md). 내가 읽고 질문하는 곳
      │
[3] SCHEMA.md   ← 규칙. "어떻게 정리할지" 적어둔 설명서

레이어	역할	왜 분리하나
1. raw	손대지 않는 금고. 파일명 `YYYY-MM-DD 제목.확장자`	정리가 틀려도 원본에서 다시 만들 수 있다
2. compiled	AI가 유지하는 PARA 노트. 질문이 향하는 곳	원본은 지저분해서 AI가 바로 못 읽는다
3. 규칙	`SCHEMA.md`(권위) · `CLAUDE.md`(진입점) · `index.md`(지도) · `hot.md`(최근) · `log.md`(이력)	규칙이 파일마다 제각각이면 AI가 매번 다르게 정리한다

raw에는 txt, pdf, xlsx, docx, pptx 뭐든 들어간다. 웹 링크는 본문을 긁어 raw/reference/에 .md 스냅샷으로 박아둔 뒤 ingest한다. 링크가 죽어도 출처가 남는다.

PARA 구조 개념

Layer 2 폴더는 PARA로 나눴다. Tiago Forte가 제안한 정리법으로, Projects / Areas / Resources / Archives의 앞글자다.

폴더	무엇	내 예시
`01-projects/`	기한·목표가 있는 진행 중 작업	졸업작품, 심심이 프로젝트
`02-areas/`	기한 없이 계속 책임지는 영역	학업, 건강, 소마 멘토링
`03-resources/`	주제별 참고 지식	AI, 코드리뷰, SEO 노트
`04-archives/`	끝났거나 안 쓰는 것	지난 해커톤, 완료 과제

PARA의 핵심 질문은 "이 자료가 무슨 주제냐"가 아니다. "이 자료가 지금 내 삶에서 얼마나 실행 가능(actionable)하냐"다.

주제별로 나누면 폴더가 끝없이 늘어난다. 실행 가능성으로 나누면 4개면 끝난다. 학업·프로젝트·멘토링·사이드 프로젝트를 동시에 굴리는 사람한테 이게 딱 맞았다.

Skill, Hook 설명

이 시스템이 "말로만 하는 규칙"이 아니라 실제로 굴러가는 이유는 .claude/ 폴더 안의 hook 3개와 skill 3개 덕분이다.

.claude/
├─ settings.json         ← hook 등록
├─ hooks/
│  ├─ raw-guard.js        raw/ 불변 강제
│  ├─ wiki-context.js     질문할 때 관련 노트 자동 주입
│  └─ stop-lint.js        세션 종료 시 무결성 점검
└─ skills/
   ├─ wiki-ingest/        raw → 정리노트
   ├─ wiki-lint/          무결성 검사
   └─ wiki-archive/       완료 항목 보관

Hook — 규칙을 코드로 강제한다.

Claude Code의 hook은 도구 호출 전(PreToolUse), 질문 제출 시(UserPromptSubmit), 세션 종료 시(Stop) 같은 시점에 실행되는 스크립트다. PreToolUse에서 exit code 2로 종료하면 그 도구 호출이 차단되고, stderr 내용이 Claude에게 "왜 막혔는지"로 전달된다.

훅	언제	하는 일
`raw-guard`	Edit/Write/Bash 실행 전	`raw/` 기존 파일의 수정·덮어쓰기·`rm`·`>` 리다이렉트를 차단. 새 파일 추가와 `mv` 리네임은 허용
`wiki-context`	내가 질문할 때마다	PARA 노트의 `keywords`·`aliases`·`title`·질문 섹션을 grep해서 점수를 매기고, 상위 6개 노트 경로와 raw 출처를 컨텍스트에 자동 주입
`stop-lint`	세션 종료 시	`wiki-lint`를 1회 실행. 문제 있을 때만 보여주고 없으면 조용히 통과

솔직히 처음엔 hook까지는 과하다고 생각했다. 그런데 "raw 수정 금지"를 CLAUDE.md에만 적어둔 동안 Claude가 정리하다 원본을 덮어쓴 게 두 번 있었다. raw-guard를 넣은 뒤로는 0건이다.

README에 적어봤자 사람은 안 읽고, AI는 가끔 무시한다. hook은 --dangerously-skip-permissions 모드에서도 돌기 때문에 사실상 유일한 안전장치다.

Skill — 반복 절차를 표준화한다.

skill은 SKILL.md라는 마크다운 파일에 절차를 적어둔 폴더다. 이름과 설명만 항상 컨텍스트에 올라가 있고, 관련 요청이 오면 그때 전문을 읽어 따른다.

스킬	트리거	하는 일
`wiki-ingest`	"이 강의 정리해줘", `/wiki-ingest`	raw 텍스트 추출 → PARA 분류 → 허브 1 + atomic n 노트 생성 → index/hot/log 갱신 → lint
`wiki-lint`	"점검해줘", `/wiki-lint`	깨진 `[[링크]]`, frontmatter 누락, TL;DR·질문섹션 누락, 고아 노트, 미-ingest raw, raw 네이밍 위반 검사
`wiki-archive`	"이 프로젝트 끝났어", `/wiki-archive`	노트를 `04-archives/`로 이동, `status: archived` 부여, index 정리. raw는 안 옮긴다

노트 형식 — 검색이 잘 되는 진짜 이유.

ingest된 모든 노트는 같은 골격을 갖는다.

---
title: ...
aliases: [한/영 동의어]
keywords: [검색할 법한 단어들]
source: raw/lectures/2026-05-29 Obsidian + Claude Code.txt
related: ["[[다른 노트]]"]
---
> [!tldr] 첫 3줄 안에 핵심 답

## 이 노트로 답할 수 있는 질문
- (예상 질문 4~6개)

## 본문 ...

## 출처

## 이 노트로 답할 수 있는 질문이 핵심이다. 일종의 역방향 인덱스다. "이 문서는 이런 질문에 답한다"를 미리 써두면, 내가 던지는 질문 텍스트와 직접 매칭된다. 여기에 aliases·keywords의 한/영 동의어가 검색 정확도의 대부분을 결정한다.

사용하는 방법

핵심은 간단하다. 딱 3단계.

1) 넣기(ingest)
강의 녹취, 회의록, PDF, 웹 링크를 raw/ 하위폴더에 던진다. 분류 고민은 안 한다. Claude Code에서 /wiki-ingest 또는 "이거 정리해줘".

2) 물어보기(query)
폴더를 뒤지지 않는다. "지난주 멘토링에서 배차 얘기 뭐였지?"라고 그냥 묻는다. wiki-context 훅이 관련 노트를 찾아 주입하고, Claude가 종합해서 raw 출처를 인용해 답한다. 위키에 근거가 없으면 "위키에 근거 없음"이라고 명시하게 해뒀다. 이게 없으면 그럴듯하게 지어낸다.

3) 점검(lint)
가끔 /wiki-lint. 세션 끝날 때 자동으로 한 번 돌아가니 사실 신경 안 써도 된다.

프로젝트가 끝나면 /wiki-archive. 이게 전부다.

사용 시 이점

Before: 녹취 파일 20개가 다운로드 폴더에 있고, 뭐가 어느 강의인지 파일명만 보고는 모른다. 필요할 때 찾다가 포기한다.

After: 파일명만 YYYY-MM-DD 제목으로 맞춰 넣으면 끝. 한 달 뒤 "그 강의에서 코드리뷰 관련해서 뭐라고 했지?" 하면 해당 문단과 날짜가 같이 나온다.

구체적으로는:

정리 부담이 0에 가깝다. 미루다 잊어버리는 자료가 없어졌다.
질문에 출처가 붙는다. "어디서 봤더라"가 아니라 "2026-05-29 강의 녹취"로 답이 온다. 블로그나 발표 자료 만들 때 근거를 바로 끌어온다.
연결이 쌓인다. 새 강의를 넣으면 예전 노트의 related에 역링크가 붙는다. 몇 달 전 메모가 오늘 질문에 딸려 나온다.
안전하다. raw가 물리적으로 보호되니 AI한테 마음 놓고 맡긴다. 정리가 맘에 안 들면 지우고 다시 ingest하면 된다.
이식 가능하다. 전부 로컬 .md라 Obsidian 없이도, Claude 없이도 읽힌다.

활용 방법

실제로 이렇게 쓰고 있다.

강의 복습 — 특강 녹취를 넣고 "이 강의에서 실무에 바로 쓸 수 있는 팁만 뽑아줘". 허브 노트 + 개념별 atomic 노트로 쪼개져 있어서 나중에 개념 하나만 다시 꺼내기 쉽다.
멘토링 맥락 복원 — "소마 멘토링에서 DRT 관련해서 멘토님이 지적한 거 전부 모아줘". 여러 회차 회의록에서 관련 대목만 날짜순으로 모아준다. 이 글 맨 앞에 쓴 그 문제가 이걸로 해결됐다.
글쓰기 재료 수집 — 블로그 주제를 정하면 "이 주제 관련 내 노트 전부 보여주고 빠진 관점 알려줘". 이 글도 그렇게 시작했다.
"이거 어디에 넣어야 돼?" — 분류가 애매한 자료는 그냥 Claude한테 묻는다. Projects인지 Resources인지 판단하고 이유까지 말해준다.

3. 팀 위키

개인 위키가 잘 굴러가니 팀 프로젝트에도 옮기고 싶어졌다.

그런데 팀은 조건이 다르다. 여러 명(+AI)이 동시에 노트를 고치고, 비개발 팀원도 있고, 회의록·기획서·리서치가 쏟아진다. 개인용을 그대로 복사했다가 일주일 만에 구조를 갈아엎었다.

내 구조 설명

설계 철학은 세 가지로 정했다.

1) 실행 우선(Action-First) — 완벽한 문서를 쓰려고 개발·고객 인터뷰를 미루지 않는다. 뼈대만 갖추고 인사이트를 계속 커밋하며 살을 붙인다. 문서는 결과물이 아니라 도구다.

2) AI가 읽기 쉽게(AI-Readability) — 모든 노트를 같은 봉투(envelope) 형식으로 감싼다. frontmatter → # 제목 → > [!tldr] → ## 이 노트로 답할 수 있는 질문 → 본문 → ## 출처. 이 일관성이 검색 정확도를 결정한다.

3) 중복 없이 상속(DRY) — 같은 내용을 여러 곳에 복붙하지 않는다. 한 곳에서만 정의(canon)하고 나머지는 [[링크]]로 참조한다. "우리 타깃 고객이 누구야?"의 답은 ICP.md 하나뿐이어야 한다.

폴더는 PARA 대신 종류별 flat 구조다.

00-meta/       ← SCHEMA, glossary, 템플릿, 스크립트
01-product/    ← 제품의 뿌리 (GOAL·ICP·VALUE) — canon
02-planning/   ← 기획
03-specs/      ← 스펙/PRD
04-decisions/  ← 결정 기록 (ADR)
05-meetings/   ← 회의록
06-research/   ← 리서치
07-individual/ ← 개인 노트 (낮은 우선순위)
90-archive/
raw/           ← Google Drive 심볼릭 링크 (git 제외)

개인용과 달라진 점을 짚어보면 이렇다.

PARA를 버린 이유. 팀 프로젝트는 제품 하나를 중심으로 돈다. "지금 실행 가능하냐"보다 "이게 회의록이냐 결정이냐 스펙이냐"가 더 중요한 질문이었다. 종류별 flat은 제품 1개일 때 가장 단순하고, AI가 탐색하기도 쉽다.

가변성 class 추가. 문서마다 "어떻게 변하는가"가 다르다. 이걸 frontmatter class:로 구분했다.

class	예시	변경 규칙
🟦 canon	GOAL·ICP·VALUE·SCHEMA	단일 진실. 사람 승인 없이 못 바꿈
🟩 log	회의록·리서치	추가만. 과거 기록 수정은 역사 왜곡
🟨 decision	ADR	스냅샷. 뒤집으면 `superseded` + 새 ADR
🟥 raw	원본	불변

canon-guard 훅 추가. canon 문서를 AI가 수정하려 하면 멈추고 before→after diff를 보여준 뒤, 사용자가 APPROVE CANON: <파일>을 직접 입력해야 통과한다. 타깃 고객 정의가 AI 손에 몰래 바뀌면 팀 전체 의사결정이 흔들린다.

07-individual 분리. 개인 의견은 팀 합의와 권위가 다르다. wiki-context 훅이 이 폴더 노트는 별도 블록("~님의 개인 의견, 참고용")으로 주입해서 canon/log와 섞이지 않게 했다.

<br.

type별 본문 템플릿. 봉투는 공통이지만 회의록엔 참석자·안건·Action Items, ADR엔 맥락·선택지·결정·근거가 필요하다. 00-meta/templates/에 type별 템플릿을 두고 ingest 시 따르게 했다. 노트 품질이 눈에 띄게 고르게 나온다.

Google Drive + Git을 사용하는 이유

팀 위키에서 가장 고민 많이 한 결정이다. 결론은 raw와 compiled를 다른 곳에 둔다.

raw → Google Drive

원본은 PDF·녹취·엑셀 등 바이너리·대용량이 많다. Git에 넣으면 레포가 비대해지고 LFS는 귀찮다.
원본은 안 바뀌니까 버전 관리가 필요 없다. 파일 공유면 충분하다.
비개발 팀원도 Drive에 드래그만 하면 된다. Git을 몰라도 된다. 이게 제일 컸다.

compiled → Git

정리 노트는 여러 명(+AI)이 동시에 고친다. Git이 3-way merge로 충돌을 해결해 준다. Drive에 .md를 두면 동시 편집 시 "파일 (1)" 충돌 사본이 생긴다. 실제로 겪었다.
이력·되돌리기·PR 리뷰가 된다.
git pull 한 줄로 팀 전체가 최신 상태를 받는다.

둘은 심볼릭 링크로 잇는다. 프로젝트 폴더 안에 raw/가 있지만 실제로는 Drive 경로를 가리키는 링크다. AI는 raw/meetings/2026-07-01 킥오프.txt처럼 로컬 경로로 접근하고, .gitignore가 raw/를 제외한다. 팀원마다 Drive 마운트 경로가 다르니(macOS/Windows/WSL) .env에 자기 경로를 넣고 setup-raw-link.sh를 한 번 실행하면 된다.

<br.

절대 하면 안 되는 것: 레포를 통째로 Drive 폴더 안에 두기. .git 디렉토리가 Drive 동기화와 충돌해서 저장소가 깨진다. 레포는 Drive 밖, raw만 Drive 링크.

`wiki-ingest-and-push` 스킬 추가

개인 위키는 ingest하면 끝이지만, 팀 위키는 정리한 노트를 공유해야 끝난다. 그래서 스킬을 둘 더 만들었다.

스킬	하는 일
`push`	`git pull --rebase` → lint 사전점검(실패 시 멈춤) → `git add -A` → 한글 커밋(`docs(05-meetings): 킥오프 회의록 ingest`) → `git push` → Slack 알림
`wiki-ingest-and-push`	`wiki-ingest` + `push`를 한 번에. lint 통과 못 하면 push 안 함

lint → commit → push → Slack 알림을 매번 손으로 하면 반드시 하나는 빼먹는다. "ingest하고 푸시해줘" 한마디로 끝나야 팀원이 실제로 쓴다.

팀에서 사용하는 방법

① 사람: Drive에 raw 넣기 (파일 드래그, Git 몰라도 됨)
   ↓  Drive가 각 PC로 동기화 (보통 몇 초~1분)
② AI에게: "ingest하고 푸시해줘"
   ↓  sync 확인 → raw 읽기 → 봉투 노트 생성 → index/hot/log 갱신 → lint → 커밋 → push → Slack 알림
③ 팀원: Slack 알림 보고 git pull → 최신 노트로 질문·열람

비개발 팀원에게 설명하는 규칙은 딱 3개다.

raw는 안 고친다. 새 원본은 새 파일로.
canon(GOAL·ICP·VALUE) 변경은 승인을 거친다.
compiled 노트는 자유롭게 고쳐도 된다. Git이 이력을 남긴다.

읽을 때는 Obsidian으로 열고 index.md에서 시작하거나, 그냥 Claude한테 묻는다. hot.md는 "어제 뭐 바뀌었어?"용(최신이 위), log.md는 전체 이력용(시간순)이다.

사용 시 이점

Before: 회의록은 노션에 쌓이는데 아무도 다시 안 본다. "그때 가격 정책 왜 그렇게 정했지?" 하면 기억에 의존한다. 타깃 고객 정의가 기획서·스펙·슬라이드에 제각각 복붙돼 있어서 셋이 다 다르다.

After:

회의록이 실제로 검색된다. "지난달 가격 정책 어떻게 결정했지?" 하면 ADR과 관련 회의록을 모아 출처와 함께 답한다.
단일 진실이 지켜진다. ICP.md 하나를 [[링크]]로 참조한다. 어긋날 수가 없다.
결정의 이유가 남는다. ADR 덕분에 새 팀원도 "그때 왜 그랬는지"를 추적한다.
진입 장벽이 낮다. 비개발 팀원은 Drive 드래그 + AI한테 한마디. 개발자는 익숙한 Git.
AI가 실수해도 복구된다. raw 불변 + Git 이력 + lint 게이트, 세 겹이다.

활용 방법

킥오프 직후 — GOAL·ICP·VALUE를 canon으로 먼저 박는다. 이후 모든 기획·스펙이 여기를 참조한다.
회의 끝나면 — 녹취/메모를 Drive에 넣고 "ingest하고 푸시해줘". Action Items는 - [ ] @담당 ~납기 형식으로 자동 추출된다.
고객 인터뷰·리서치 — 웹 소스는 Exa MCP로 검색해 raw/reference/ 스냅샷으로 저장 후 ingest. 링크가 죽어도 근거가 남는다.
의사결정 회의 전 — "이 주제 관련 기존 결정과 리서치 요약해줘". 맥락을 갖고 들어간다.
온보딩 — 새 팀원에게 00-meta/WIKI 사용법.md 하나 주고 "궁금한 건 Claude한테 물어봐".

피보팅이 될 때

스타트업은 제품이 바뀌거나 늘어난다. flat 구조는 제품 1개일 때 최적인데, 2개 이상이 되면 products/<제품>/ 하위로 unfold한다.

mkdir -p products/<제품명>
git mv 01-product/*  products/<제품명>/
git mv 02-planning   products/<제품명>/planning
git mv 05-meetings   products/<제품명>/meetings
# ...

이게 비용 거의 0으로 되는 이유는 두 가지다.

[[wikilink]]는 경로가 아니라 파일명 기준이라 폴더를 옮겨도 안 깨진다. [링크](../01-product/GOAL.md) 같은 상대경로를 썼으면 전부 깨졌을 거다.
source: raw/...는 Drive에 전역 고정이라 compiled가 어디로 가든 출처가 유지된다.

기존 제품 문서는 지우지 않는다. 피보팅 전 결정은 superseded ADR로 남기고, 끝난 문서는 90-archive/<연도>/로 git mv한다. 삭제하면 "왜 그 방향을 접었는지"라는 제일 값진 기록이 사라진다.

4. 사용하고 느낀 점 및 앞으로의 계획

느낀 점

정리의 병목은 분류가 아니라 귀찮음이었다.

분류 체계를 아무리 잘 만들어도 내가 안 하면 소용없다. 분류를 AI한테 넘기고 나서야 자료가 실제로 쌓이기 시작했다.

보고서 작성 시간이 엄청 줄어들었다.

리서치, 나의 의견, 개발 등 다양하게 해왔던 기록들이 모두 저장돼있고, 이것을 AI가 잘 찾아준다. 따라서, '딸깍' 하나에 내가 이전에 했던 것들이 다 기록으로써 바로바로 나올 수 있으므로, 남들에게 내 의견과 작업을 보고서로써 전달하는 것이 매우 빨라졌다.

검색 품질은 ingest 시점에 결정된다.

keywords·aliases·"이 노트로 답할 수 있는 질문"을 얼마나 풍부하게 넣었느냐가 몇 달 뒤 적중률을 좌우한다. 벡터DB 없이 grep만으로 충분히 쓸 만하다는 게 의외였다.

hook 없는 규칙은 규칙이 아니다.

위에 썼지만 다시 쓴다. 문서에 적어둔 동안엔 사고가 났고, hook을 넣고 나선 0건이다.

개인과 팀은 다른 구조가 맞다.

개인은 "지금 실행 가능하냐"(PARA), 팀은 "어떤 종류의 문서냐 + 얼마나 바뀌어도 되냐"(type + class). 하나로 통일하려다 둘 다 어정쩡해지는 걸 겪었다.

복리는 진짜다.

석 달 치 강의·회의가 쌓이니 "A 강의에서 배운 걸 B 프로젝트에 적용하면?" 같은 질문에 내가 생각 못 한 연결을 가져온다. 이 순간에 "만들길 잘했다" 싶었다.

앞으로의 계획

콘텐츠 생성

WIKI에 있는 knowledge base를 기반으로 PPT, 영상, 게시글 등 콘텐츠를 만들어 수익을 창출해볼 계획이다.

실제 기업용 WIKI 만들기

이렇게 local 기반으로 작업을 하기엔, 문서가 많아질수록 부담이 커질 수 있다. 따라서 'openwiki', 'GraphRAG' 등 공부를 하며 실제 기업적으로 사용할 수 있는 WIKI를 만들어보고 싶다.

5. Tl;DR

자료는 던져 넣기만, 원본은 건드리지 않고, AI가 정리하고, 찾을 땐 묻는다. 쌓일수록 똑똑해진다.

혹시 비슷한 걸 만들어 쓰고 계신 분이 있다면 어떤 구조로 굴리시는지 궁금하다. 특히 팀 위키 쪽은 아직 개선할 게 많아서, 댓글로 의견 남겨주시면 감사하겠습니다!!