사례 5 — 지식 플라이휠: 위키가 스스로 도는 구조
문제
기록은 쌓이는데 다시 안 읽게 되는 — 노트의 운명을 바꾸고 싶었다.
해결
원본 하나에서 화면·검색·공개가 자동 파생되는 구조 + 브라우저에서 바로 쓰는 기록 루프.
결과
294문서가 15페이지 공개 사이트·FTS5 검색·이슈 기반 기록으로 자동 순환 — 이 케이스 스터디도 그 산출물이다.
배경과 시기GitHub에서 피드백 남기기
- 2026-07-16
LLM Wiki 첫 커밋: 3정체성 지식 베이스— 개발자·투자자·철학자의 기록 통합. - 문서가 200개를 넘어도 “쓰고 잊는” 상태. 검색도, 뷰어도, 공개도 없었다.
방향이 바뀐 순간GitHub에서 피드백 남기기
- 지식의 가치는 저장이 아니라 파생에서 나온다: 같은 원본이 화면·검색·공개물로 자동 변형되어야 매번 다시 읽게 된다.
- 두 번째 통찰: 파생이 자동이면 기록 장벽이 결정적이다. 쓰기가 어려우면 플라이휠이 멈춘다 — 그래서 "브라우저에서 폼 한 장"으로 시작하는 입구를 만들었다.
목표GitHub에서 피드백 남기기
- 원본 수정 → 화면·검색 자동 반영 (수동 단계 제거)
- 비공개 지식을 안전하게 공개 (화이트리스트)
- 폰·외부 기기에서도 기록·수정 가능
결정한 것과 버린 것GitHub에서 피드백 남기기
-
기성 위키(Notion·Obsidian Publish)자체 파이프라인
자체 선택
자체 선택. 이유: 화이트리스트 기반 공개(비공개 294문서 중 일부만 노출)와 CI 검증·SHA 치환 같은 감사 요소가 필요했다. 기성품은 이 경계 통제가 약하다.
-
검색: 벡터 DBFTS5+그래프
FTS5 선택
FTS5 선택. 이유: 한국어 형태소 문제를 토크나이저로 직접 제어 가능하고, 그래프 확장(위키링크 간선)으로 연관 문서 탐색이 되며, 의존성이 Node 내장 SQLite뿐이다.
-
쓰기: 앱 개발GitHub Issue 딥링크
딥링크 선택
딥링크 선택. 정적 사이트 제약 하에 인증·스팸 방지를 GitHub에 위임하는 가장 얇은 해법.
만든 것GitHub에서 피드백 남기기
- 자체 정적 빌더(Node 24 + markdown-it, 294줄) — CSP·금지문자열·경계 감사 내장
- FTS5 검색 엔진(Docker 2컨테이너) + 15분 워치독 자동 push (246페이지)
- 페르소나 콘솔(:5174, launchd 상시) — 비공개 관제 화면
- 기록 폼(/record/) → GitHub Issue → 주간 트리아지 → vault 커밋
- 문서별 「GitHub에서 편집」 버튼, 건강검진 워치독(매주 링크·frontmatter 점검)
지표 — 전과 후GitHub에서 피드백 남기기
-
문서 검색
파일 뒤지기FTS5+그래프 질의즉시
엔진 실측 (246페이지 색인)
-
공개 화면
015페이지 사이트+15
HTTP 200 실측 ×14
-
기록→반영
수동 편집폼→이슈→트리아지→커밋당일
이슈 #17 → 커밋 d938941
-
문서 규모
0264 (엔진 246 색인)축적
vault 실측
-
배포 리드타임
수동 다단계push→CI→publish→라이브~5분
run 32821023191 실측
-
외부 기기 기록
불가브라우저 폼가능
record 폼 실측
실패한 가설과 대응GitHub에서 피드백 남기기
가설: “한국어도 그냥 검색될 것”
→ 실패. 조사가 붙으면 엔진이 못 찾음. → 명사형 보정 로직(
refineQuery())을 만들고 그 근거를 문서화 — "레버리지를 어떻게 봤지"는 못 찾고 "레버리지"는 찾는 것을 공개 문서로 남김.가설: “로컬 콘솔과 엔진은 항상 같다”
→ 어긋남. 원인은 옛 wiki_id 기본값. → 패리티 비교를 상시 도구화, 수정 후 완전일치 3/5·상위3 4/5 검증.
가설: “CI만 있으면 배포다”
→ 404. artifact 이동 단계 부재 발견 → publish 스크립트 신설.
교훈
파이프라인의 각 경계(CI→artifact→배포)는 별도의 검증 대상이다.
면접용 2분 답변GitHub에서 피드백 남기기
상황
“노트가 200개를 넘었는데도 다시 안 읽게 되는, 지식 저장의 고질적 문제가 있었습니다.”
과제
“기록이 자동으로 화면·검색·공개물이 되는 구조를 만드는 게 목표였습니다.”
행동
“기성 위키 대신 자체 파이프라인을 선택했습니다. 원본 하나에서 콘솔·FTS5 검색·화이트리스트 공개 사이트가 파생되고, 기록 입구는 브라우저 폼→GitHub 이슈→주간 트리아지로 만들어 인증과 스팸 방지를 GitHub에 위임했습니다.”
결과
“294문서가 15페이지 공개 사이트와 검색 엔진으로 자동 반영되고, 기록→커밋이 당일 처리됩니다. 배포 리드타임은 5분입니다. 이 케이스 스터디도 그 파이프라인의 산출물입니다.”
증거GitHub에서 피드백 남기기
| 주장 | 증거 |
|---|---|
| 62커밋 축적 | llm-wiki git log 07-16 ~ 08-25 |
| 3계층 라이브 | 콘솔 200 · 엔진 health ok · Pages 200 (2026-08-25) |
| 기록 루프 | Issue #17 (closed) → 커밋 d938941 |
| 검색 실측 | “커리어” 질의 → Career 문서 히트 |
| 배포 리드타임 | run 32821023191 (12s) → publish → 200 |
다음으로GitHub에서 피드백 남기기
- 지식 시스템의 승부처는 저장이 아니라 파생과 입구다
- 경계마다 검증을 두면 실패가 자산이 된다 (패리티·health·200 실측)
이후 이어진 이야기GitHub에서 피드백 남기기
- 이 구조 위의 커리어 기록: index