LLM Wiki 구축 실습 —
회사 지식의 영속화
구요한 (커맨드스페이스) · 견적 판단, 회의록, 하자 대응 기록을 AI가 검색·연결하는 회사 지식 베이스로. 오픈소스 스타터킷(v1.11.0)을 온보딩하고, 업무 기록을 적재하고, 질의하고, 엑셀·PPT까지 지식화하는 다섯 단계. 녹화 후 따라해도 되는 속도로 진행합니다.
1. 오늘 쓰는 것 두 가지
스타터킷(위키 본체) + 샘플 업무 원천 자료(본인 회사 자료가 없을 때의 첫 재료).
⬇ LLM Wiki 스타터킷 v1.11.0 (GitHub Release ZIP) ⬇ 샘플 업무 원천 4건 (4KB) 🌐 llm-wiki.cmdspace.work — 킷 상세
2. 실습 — 5개 체크포인트
각 단계의 프롬프트를 복사해 붙여넣고 통과 기준을 확인하세요. 시간이 가장 드는 곳은 ①·② — 막히면 손 들어주세요.
셋업 — 셋업조차 프롬프트가 아니라 커맨드가 한다
- 위의 스타터킷 ZIP 다운로드 → 압축 해제 (위치는 아무 곳이나, 폴더명은 자유 — 예:
our-company-wiki) - Obsidian → Open folder as vault → 그 폴더 선택
- 같은 폴더에서 터미널을 열고 Claude Code 실행 (Codex도 동일하게 동작) → 아래 한마디
온보딩해줘
킷에 내장된 /onboard 인터뷰가 시작됩니다 — 이름·운영 모드·업종을 묻고 킷 전체의 placeholder를 대신 채웁니다.
통과 기준 — 인터뷰 완료 후 placeholder 자동 치환 + Core Context.md에 우리 회사 맥락이 채워짐.
적재(Ingest) — 업무 기록을 넣으면 위키가 자란다
- 본인 자료가 있으면 — 회의록·업무 메모를 킷의 00. Inbox/에 복사
- 없으면 — 위에서 받은 샘플 4건의 압축을 풀어 00. Inbox/에 복사
/ingest
또는 자연어로:
Inbox에 넣어둔 업무 기록들을 위키로 컴파일해줘. 각 기록을 왜 남겼는지 물어보면서 진행해.
통과 기준 — 10. Raw Sources/에 원문 보존 + 20. Wiki/에 페이지 생성 + 네 문서가 공유하는 개념(발주처 특성 · 단가 선반영 · 하자 패턴)을 위키가 스스로 발견해 연결.
확인 — 파일 4개가 네트워크가 됐다
- index.md — 위키의 현관에 새 페이지가 등록됐는지
- 20. Wiki/ — 발주처·단가 규칙 페이지와 [[크로스레퍼런스]] 링크
- Obsidian 그래프 뷰 — 흩어진 기록이 개념으로 이어진 그림 (좌측 리본 또는 ⌘G)
/status
통과 기준 — 그래프 뷰에서 원천 4건이 개념 페이지를 통해 연결된 모양이 보인다.
질의(Query) — 내 회사 지식에게 묻고, 근거와 함께 답 받기
/query 대현건설 다음 견적에서 주의할 게 뭐야? 근거가 되는 기록도 알려줘.
본인 자료를 넣었다면 본인 회사 질문으로 물어보세요.
통과 기준 — 답이 내 위키 페이지들을 근거로 합성되고, 근거 링크를 타고 원문까지 내려갈 수 있다. 챗 검색과의 결정적 차이: 답의 출처가 인터넷이 아니라 우리 회사 기록.
엑셀·PPT 지식화 — 원본은 두고, 판단만 꺼낸다
회사 자산의 대부분은 엑셀·PPT입니다. 변환하지 않습니다. 원본은 그대로 두고, 그 파일을 가리키는 판단 기록 한 장(결정 · 근거 · 재사용)만 마크다운으로 남깁니다. 샘플의 "견적판단-대현타워" 파일이 바로 그 형태 — 이제 본인 회사의 실제 엑셀 하나로 직접 만들어 봅니다:
우리 회사 견적서 엑셀 파일 하나를 지식화하려고 해. 파일을 열지 말고, 내가 답하는 내용으로 판단 기록 카드를 만들어줘. 이렇게 물어봐줘: ① 어떤 파일이고 무엇을 결정한 견적인가 ② 왜 그렇게 판단했나 ③ 다음에 또 쓸 기준은 무엇인가. 답을 받으면 00. Inbox/에 카드를 만들고 ingest 해줘.
완성된 순환 — 견적을 낼 때마다 판단 기록이 위키로 들어가고, 다음 견적은 위키에 쌓인 기준(발주처 특성·단가 규칙·하자 패턴)을 참조하며 시작합니다. 파일당 걸리는 시간은 60초. 이 순환이 회사의 지식 자산 — 특별한 솔루션이 아니라 폴더 하나와 그 사이의 습관입니다.
3. 여럿이 쓸 때의 규칙 — 쓰기는 넓게, 컴파일은 좁게
"10~20명이 몇 년간 쏟아부어도 관리가 되나"에 대한 답. 기술이 아니라 권한 설계가 답입니다.
