뜯어본 것공개

옵시디언 LLM 위키

3계층 구조는 제 쪽이 이미 4계층이었습니다. 새로 얻은 셋 중 둘은 위생 규칙이고, 제일 탐났던 하나는 보류했습니다.

구조를 배우러 갔다가 위생 규칙 둘을 얻어 왔습니다. 25분짜리 영상이 LLM 위키라는 공개 구조를 옵시디언과 Claude Code로 구현한 사례를 보여줍니다. 원천 자료·위키·규칙 3계층으로 회사의 두뇌를 만들고, AI가 직접 읽고 정리하게 하는 방식입니다. 제 것과 대조해 보니 계층은 이미 제 쪽이 더 세분화돼 있었고, 야간 자동 점검도 승인 게이트까지 붙여 돌고 있었습니다. 실제로 남은 건 구조가 아니라 운영 규칙 둘이었고, 제일 탐났던 하나는 보류했습니다.

3계층 — 지식을 매번 다시 넣지 않고 한 번 컴파일해 쌓는다 ① 원천 자료 녹음 · 회의록 · 메모 · 메일 고치지 않고 원본 그대로 둔다 ② 위키 AI 가 읽고 정리한 파생 지식 서로 링크되어 맥락을 만든다 ③ 규칙 운영 규칙 문서 + 색인 + 접근 기록 사람용 지도와 기계용 안내판을 따로 그 위에 도는 동작 셋 수집 — 원본을 받는다 질의 — 위키를 거쳐 답한다 점검 — 위생을 자동 검사한다 ⇒ 비유가 정확하다 — 편집기는 IDE · 모델은 작성자 · 위키는 코드베이스
세 계층 자체보다 그 위에 도는 동작 셋이 중요하다. 특히 마지막 「점검」이 있느냐 없느냐가 갈린다.

무엇을 하는 물건인가

공개된 구조 하나를 실제로 굴려 본 사례입니다. 핵심 명제는 슬라이드 한 줄입니다 — “지식을 매번 재입력하지 않고, 한 번 컴파일해 계속 축적한다.” 매번 자료를 새로 주는 대신 한 번 만든 허브에 AI를 붙입니다.

본인은 이걸 「도서관」이라 부르고 공간을 다섯으로 나눕니다. 작업장 / 도서관 / 개인 금고 / 대화 채널 / 매뉴얼 아카이브. 일은 작업장에서, 기억은 도서관에, 개인은 금고에 — 그리고 승인·검토가 끝난 확정본만 도서관으로 옮깁니다. 2~3개월째 운영 중이라고 합니다.

운영 원리가 다섯 줄입니다.

규칙 내용
확정본만 작업 중인 것은 도서관에 안 들어간다
한 자료는 딱 한 자리 중복 금지
애매하면 인박스 판단을 미루고 일단 받는다 → 새벽에 자동 분류
삭제 대신 이동 오래된 건 지우지 않고 레거시로
접근을 기록한다 어느 AI가 언제 뭘 봤는지 로그 파일에 남긴다

그리고 새벽 3시 15분에 위생검사가 돌고 월요일에 주간 리포트가 나옵니다. 다만 감독은 사람이 합니다 — 자동 점검이 개선 제안을 내면 사람이 봅니다.

대표 기법 — 제일 실용적인 건 녹화였다

화면 녹화로 업무 매뉴얼을 자동 생성합니다. 직접 만든 브라우저 확장이 업무 과정을 녹화하면서 클릭·스크린샷·설명을 캡처하고, 그걸 마크다운 매뉴얼로 정리합니다. 결과물은 문서 하나 + 이미지 폴더이고, 그 폴더를 그대로 “위키에 추가해 줘” 라고 시키면 원본은 원천 자료 층에 보존되고 파생 지식 페이지가 따로 생깁니다.

용도가 명확합니다 — 온보딩·업무 위임·인수인계. 그다음부터는 “월별 매출 정리해 줘” 같은 요청에 위키 맥락과 출처까지 반영된 답이 나옵니다.

깨본 결과

구조 자체는 새롭지 않고, 영상도 그걸 감추지 않습니다. 3계층은 공개된 개념을 그대로 가져온 것이고 출처를 앞에서 밝힙니다. 이 영상의 값어치는 개념이 아니라 두 달 굴려 본 운영 기록에 있습니다.

다만 검증 가능한 수치가 없습니다. 위키를 붙여서 얼마나 나아졌는지, 할루시네이션이 얼마나 줄었는지에 대한 측정이 하나도 없습니다. “할루시네이션↓ 정확도↑” 는 도입부 슬라이드의 주장이고 뒷받침이 없습니다.

그리고 영상 후반이 자기 제품 소개입니다. 자체 앱을 공개하고 강의를 안내합니다 — 흠은 아니지만, 운영 사례로 읽을 부분과 홍보로 읽을 부분을 갈라서 봐야 합니다.

내 것과 대조 — 겹치는 넷, 남은 셋 3계층 구조 이미 4계층 — 내 쪽이 더 세분화 야간 자동 점검 + 주간 리포트 이미 크론 + 승인 게이트까지 그래프 시각화 이미 있음 허브 폴더 이미 있음 한 자료는 딱 한 자리 · 애매하면 인박스 채택 — 중복 스텁 문제와 맞닿는다 어느 AI가 언제 봤는지 접근 기록 채택 — 지금 여러 경로가 같은 설정을 공유한다 화면 녹화 → 업무 매뉴얼 자동 생성 보류 — 제일 탐났는데 지금은 아니다
겹치는 칸이 넷이라는 건 배울 게 없다는 뜻이 아니다. 어디를 봐야 하는지가 좁혀졌다는 뜻이다.

내 환경에 대봤다

계층은 제 쪽이 이미 더 잘게 나뉘어 있었습니다. 영상이 셋으로 가른 자리를 저는 넷으로 쓰고 있고, 야간 점검도 자동 제안 뒤에 사람 승인 게이트까지 붙여서 돌고 있습니다. 그래프 시각화도 이미 만들어 뒀습니다.

그래서 남은 건 구조가 아니라 규칙 둘이었습니다.

하나, 한 자료는 딱 한 자리. 제 볼트에 같은 내용의 스텁이 여러 자리에 흩어진 문제가 이미 기록돼 있습니다. “애매하면 인박스에 넣고 나중에 분류” 는 그 문제의 발생 자체를 막는 규칙입니다 — 판단을 미루되 자리를 안 늘립니다.

둘, 접근 기록. 지금 제 환경은 메인 세션·예약 실행·메신저 워커가 같은 설정 폴더를 공유합니다. 누가 언제 뭘 읽고 고쳤는지 남는 곳이 없어서, 뭔가 어긋났을 때 범인을 찾는 데 시간이 갑니다. 로그 파일 하나면 됩니다.

셋, 화면 녹화 매뉴얼은 보류했습니다. 제일 탐났고 QA 재현 절차를 클릭·스크린샷 포함으로 자동 문서화하면 바로 쓸 것 같았는데, 이건 이미 한 번 검토하고 미뤄 둔 안건입니다. 재촉하지 않기로 한 이유가 그대로 유효합니다 — 지금 재현 절차가 안 써져서 막히는 일이 실제로 없습니다. 불편 표본이 0인데 도구부터 들이면 그 도구를 유지하는 비용만 남습니다.

판정

무엇 판정
한 자료 한 자리 · 애매하면 인박스 채택. 중복 발생을 사후에 잡는 대신 발생 자체를 막는다
AI 접근 기록 채택. 여러 경로가 같은 설정을 공유하는 지금 필요하다
화면 녹화 → 매뉴얼 보류 유지. 불편 표본 0
재개 조건: 재현 절차를 못 써서 막히는 일이 실제로 생길 때
3계층 구조 이미 있음. 넷으로 더 세분화
야간 점검 · 그래프 시각화 · 허브 이미 있음
수치 인용 금지. 측정된 값이 하나도 없다

이 편에서 값을 치른 교훈은 이겁니다 — 남이 나보다 앞선 부분과 뒤진 부분은 같은 자료 안에 섞여 있습니다. 구조는 제 쪽이 앞서 있었는데 운영 규칙은 뒤져 있었습니다. 구조만 보고 “이미 다 있네” 로 닫았으면 규칙 둘을 놓쳤을 겁니다.

그리고 ⚠ 제일 탐나는 것이 제일 필요한 것은 아닙니다. 화면 녹화 매뉴얼은 이 영상에서 제일 인상적이었는데, 제 불편 표본은 0이었습니다. 인상과 필요를 갈라 두지 않으면 도구가 늘어납니다.