# 지피터스 22기 2주차 — 나만의 LLMWiki 구축 개발 로그
AI 에이전트(Claude Code = 도라에몽 봇)와 함께 **파트너스컨텐츠 프로젝트용 LLMWiki**를 구축한 기록입니다.
---
## 0. 우리가 하려는 업무 플로우 (LLMWiki가 왜 필요한가)
우리 팀의 목표는 **파트너스컨텐츠**(쿠팡파트너스 + 올리브영 멀티, 콘텐츠 리서치+생성 전략) 운영이다. 핵심 업무 흐름은:
```
고반응 영상 발굴 → 상품 역매칭 → 스크립트·콘텐츠 제작 → 게시 → 성과 분석 → 반복
```
이 일을 **봇팀 4명**(도라=팀장/karpathy=리서치/명조=콘텐츠/모찌=자동화)이 나눠서 한다. 그런데 매일 영상·상품·후킹 공식·성과 데이터가 쌓이는데, 이게 흩어지면:
- 같은 상품을 또 리서치하고
- 어제 잘 된 후킹 패턴을 까먹고
- 봇마다 자료를 제각각 정리해서 서로 못 찾는다
그래서 **LLMWiki = 봇팀과 진구가 근거를 다시 꺼내 쓰는 중앙 지식 저장소**가 필요했다. 단순 메모장이 아니라, AI가 계속 자료를 넣고(Ingest) 질문하고(Query) 점검하는(Lint) 살아있는 위키.
---
## 1. 구축 기준과 이유 (어떻게 설계했나)
이번 주 핵심 과제는 "완성된 시스템"이 아니라 **앞으로 계속 쓸 수 있는 구조를 에이전트와 함께 시작**하는 것. 그래서 세운 기준:
| 기준 | 이유 |
|------|------|
| **원본과 요약 분리** (`raw/` ↔ `concepts/claims/...`) | AI 요약을 원본인 줄 착각하면 잘못된 사실이 굳어진다. 원본은 절대 안 건드린다. |
| **승격 상태로 검증 단계화** (draft→review_needed→verified) | "AI가 말함" ≠ "사실 확인됨". 검증 거친 것만 verified로 올린다. |
| **온톨로지로 일관성 확보** | 봇 4명이 자료 넣을 때 제각각이면 못 찾는다. "무엇을 무엇으로 부를지" 먼저 정한다. |
| **작게 시작, 굴리며 개선** | 처음부터 완벽한 위키 X. 1주차 wiki(v0.2)를 그대로 확장. |
| **출처 추적** (`derived_from` 관계) | 중요한 주장은 어느 원본에서 왔는지 거슬러 올라갈 수 있어야 한다. |
---
## 2. 온톨로지 설계 — 에이전트와 4단계 대화로
에이전트에게 "온톨로지 만들어줘" 한 번에 맡기지 않고, **하나씩 물어보며** 정했다. 이게 핵심이었다 — 내 머릿속 분류를 끄집어내는 과정 자체가 위키 설계였다.
```
에이전트 프롬프트(요지):
"온톨로지 함께 해보자. 단계별로 하나씩 물어보면서 진행해줘.
파트너스컨텐츠 위키 기준으로 추천안 붙여서 한 단계씩."
```
확정 결과 (`_meta/ontology.md`):
| 구분 | 정의 |
|------|------|
| **Entity 6** | person · product · video · platform · tool · bot |
| **Concept 6** | strategy · workflow · hook_pattern · scoring_rule · principle · risk |
| **Relation 7** | matched_with · proves · uses · published_on · created_by · derived_from · contradicts |
| **Promotion State 4** | draft → review_needed → verified → rejected |
→ SCHEMA를 v0.3으로 올리고, 문서 frontmatter에 `entity_type / concept_type / promotion_state / relations` 필드 추가.
### 실행하며 알게 된 것
- **추천안을 먼저 주니 결정이 빨라졌다.** 빈칸 던지면 막막한데, "이 6개 어때?"라고 물으니 "이대로" 한마디로 진행됐다.
- 온톨로지는 거창한 지식그래프 이론이 아니라 **헷갈리지 않기 위한 작은 운영 규칙**이라는 게 와닿았다.
---
## 3. 온톨로지를 실제 데이터에 적용 (문서로만 두지 않기)
규칙만 만들고 끝내면 죽은 문서다. 그래서 **실제로 한 번 굴렸다** — 콘텐츠 사이클에서 발굴한 틱톡 영상을 온톨로지대로 정리.
- 영상: `@iram0078_` "1만원 미만 기초꿀템" — 54.5만 조회 / 좋아요율 5.7% (yt-dlp로 **검증된 실측값**)
- entity 문서화: `published_on`(틱톡) + `created_by`(크리에이터) + `proves`(가격충격 후킹공식) + `derived_from`(원본 수집본) 관계 연결 → **verified**
- ⚠️ 단, 영상 속 **상품 SKU는 캡션에 없어서** 추측하지 않고 `review_needed`로 보류
### 실행하며 알게 된 것
- **추측 금지 원칙이 온톨로지의 promotion_state로 자연스럽게 구현됐다.** "모르는 건 review_needed" — 정직함이 구조에 박혔다.
- 차단된 플랫폼(틱톡) 데이터도 **우회 수집(WebSearch→URL→yt-dlp 검증)** 으로 가져와 위키에 넣을 수 있었다.
---
## 4. 옵시디언 연동 — 지식을 그래프로 보기
LLMWiki는 Markdown 폴더라 옵시디언으로 열면 바로 지식 그래프가 된다.
```
에이전트 프롬프트(요지):
"옵시디언으로 wiki 관리하자. 봇들과 함께 쓸 거라 이용 규칙도 명시해줘."
```
한 일:
- `index.md`를 **MOC(Map of Content)**로 전환 — 전부 `[[위키링크]]`라 Graph View에서 연결망으로 보임
- 그래프가 끊기지 않게 빈 노드(플랫폼·크리에이터·후킹공식) entity 추가
- `attachments/` 폴더로 이미지·PDF 분리
- **봇팀 공동 사용 규칙** `_meta/obsidian-team-rules.md` (원본 보존 / 승격 / 충돌 방지 / 민감정보 금지 + 봇별 쓰기 권한)
### 실행하며 알게 된 것
- 기존 문서가 일반 마크다운 링크(`[](file.md)`)였는데 **옵시디언 그래프는 `[[위키링크]]`만 인식**한다는 걸 알았다. 전환 후에야 진짜 연결망이 떴다.
- 봇이 여러 명이라 **"누가 어느 폴더에 쓸 수 있나"** 권한을 문서로 박아야 충돌이 안 난다.
---
## 5. Git + GitHub(private) 백업 — 안전장치
AI와 빠르게 고치다 보면 실수가 잦다. Git으로 되돌릴 수 있게 했다.
- `.gitignore`로 **민감정보(.env·token·key·auth) + 옵시디언 개인설정** 차단
- 커밋 전 민감정보 스캔 → 0건 확인 후 커밋
- **private repo**로 push (raw에 사업 자료가 있으니 비공개 필수)
### 실행하며 알게 된 것
- `.gitignore` 우선 설계가 중요. 한번 커밋되면 토큰 같은 건 이력에 남는다.
- 옵시디언 `workspace.json`(개인 화면배치)은 빼되, `graph.json`(그래프 설정)은 공유하면 봇팀이 같은 뷰를 쓸 수 있다.
---
## 6. 구축하면서 느낀 점 / 중요 사항
- **"AI가 만든 건 사실이 아니다"가 위키의 1번 원칙.** 이번에 에이전트가 도구 출력을 오판하거나 없는 데이터를 지어내는 일이 실제로 있었다. 그래서 promotion_state(검증 단계)와 derived_from(출처)이 *장식이 아니라 안전장치*라는 걸 체감했다.
- **대화형으로 만드니 내 것이 됐다.** 한 방에 생성된 위키는 남의 것 같지만, 한 단계씩 정한 온톨로지는 내가 이해하고 쓸 수 있다.
- **작게 시작이 맞다.** 1주차 wiki를 버리지 않고 확장하니 빨랐다.
---
## 7. 개선해야 할 점
- **검색/질의 계층이 없다.** 지금은 사람이 옵시디언으로 본다. 자료가 많아지면 DuckDB/SQLite로 "자료 몇 개? 중복? source_type별?" 관측이 필요.
- **봇 자동 쓰기 미연동.** 지금은 도라(Claude Code)가 파일을 직접 쓴다. Hermes 봇들이 직접 vault에 쓰려면 나중에 Obsidian CLI/headless 검토.
- **에이전트 환각 방지 루틴 강화.** 보고 전 도구 출력 재확인을 규칙으로 박았지만, 자동화된 self-eval 하네스로 굳혀야 함.
---
## 8. 앞으로 추가하고 싶은 점
- **LLMWiki Harness Skill** — "새 자료 안전 추가", "봇 결과물 self-eval" 같은 반복 작업을 스킬로 (가이드 확장과제)
- **자료 가공 체인** — PageIndex(긴 문서 구조화) → OpenKB(질의응답) → Graphify(관계 그래프) 단계적 실험
- **성과 데이터 축적** — 발굴 영상의 실제 게시 후 전환율을 다시 위키에 넣어 scoring_rule 보정
- **주간 Lint 자동화** — 깨진 링크·외톨이 문서·오래된 자료를 모찌(봇)가 주 1회 점검
---
## 산출물 / 기술 스택
- **LLMWiki**: `/Users/marklee/02_지피터스/1주차과제/wiki` (v0.3) → GitHub private `leecmin80-ops/llmwiki-partners`
- **에이전트**: Claude Code (도라에몽), Opus 4.8
- **지식관리**: Markdown + Obsidian Vault + Git
- **수집/검증**: yt-dlp, insane-search 우회, WebSearch
## 커밋 히스토리
| 날짜 | 커밋 | 설명 |
|------|------|------|
| 05/30 | `bab792d` | docs: LLMWiki v0.3 — 온톨로지 + 옵시디언 연동 + 봇팀 규칙 |
