메타코드M의 **「클로드 x 옵시디언으로 우리 회사 LLM Wiki 만들기」**는 개인 메모 수준을 넘어, 회사 안에 흩어진 회의록·Slack 대화·프로젝트 문서·결정 기록을 **자동으로 축적·정리·검증하는 기업용 LLM Wiki** 구조를 설명합니다. ## RAG의 빈틈: 답은 만들지만 지식이 쌓이지 않는다 RAG는 질문이 들어올 때마다 관련 문서를 찾아 그 자리에서 답을 조립합니다. 문제는: - 답이 여러 문서에 흩어져 있을 수 있고 - 예전 문서와 최신 문서가 같이 검색될 수 있고 - 어렵게 조립한 결론이 다음 질문에 다시 활용되지 않을 수 있다는 점입니다. 즉 RAG는 **지식 발견**에는 강하지만, 그 결과를 계속 축적하는 구조는 아닙니다. ## LLM Wiki의 핵심 LLM Wiki는 질문 시점마다 원문을 처음부터 조립하는 대신, 원문을 미리 읽어 **정리된 지식 페이지를 계속 갱신**합니다. 쉽게 말하면: **RAG = 질문할 때 조립** **LLM Wiki = 자료가 들어올 때 조립** 입니다. 그래서 한 번 정리된 지식이 다음 질문의 재료가 됩니다. ## 3개 Layer 구조 영상에서는 LLM Wiki를 크게 세 층으로 나눕니다. ### 1. Raw Layer 사람이 넣는 원본 자료입니다. 예: - 회의록 - Slack 대화 - 프로젝트 문서 - 통화 메모 여기서는 LLM이 원문을 임의로 수정하지 않고 읽기만 합니다. ### 2. Wiki Layer LLM이 직접 작성·갱신하는 Markdown 지식 문서입니다. 예: - 고객사 - 담당자 - 의사결정 - 아키텍처 - 프로젝트 상태 등으로 구조화할 수 있습니다. ### 3. Schema Layer Wiki가 어떤 규칙으로 운영될지 정의합니다. 예: - 폴더 구조 - 문서 제목 규칙 - 링크 방식 - 충돌 정보 표기 - 상태값 같은 규칙을 담습니다. 영상에서는 이 Schema Layer가 Wiki 품질을 좌우하는 핵심으로 봅니다. ## 세 가지 핵심 동작: Ingest · Query · Lint ### Ingest 새 원본 문서가 들어오면 기존 Wiki와 비교해 관련 페이지를 생성하거나 수정합니다. ### Query 질문이 들어오면 Raw 문서 전체보다 이미 정리된 Wiki를 우선 참고해 답변합니다. ### Lint 시간이 지나며 생긴: - 모순 - 오래된 내용 - 깨진 링크 - 중복 을 찾아 정리합니다. 즉 Wiki는 한 번 만들어 놓고 끝나는 문서가 아니라 계속 유지되는 지식 시스템입니다. ## RAG와 LLM Wiki는 경쟁 관계가 아니다 영상에서 중요한 포인트는 둘 중 하나를 버리는 것이 아닙니다. RAG는 원문에서 근거를 찾는 역할을 하고, Wiki는 그 근거를 정리해 축적하는 역할을 합니다. 따라서 가장 실용적인 구조는: **Raw Source → RAG/검색 → Wiki 축적 → Query → 필요 시 원문 검증** 입니다. ## 자동 Wiki Builder가 필요한 이유 사람이 직접 Wiki를 계속 갱신하면 결국 다시 문서 관리 업무가 생깁니다. 그래서 영상에서는 Claude Code를 이용해 **자동 Wiki Builder Harness**를 만듭니다. ## 핵심 원칙 1: 판단은 Agent, 검산은 Code 영상에서 가장 중요한 설계 원칙 중 하나입니다. 다음처럼 매번 같은 결과가 나와야 하는 검사는 코드로 처리합니다. - 링크가 실제로 존재하는가 - JSON 형식이 맞는가 - 필수 필드가 있는가 - 파일 경로가 유효한가 반면 다음처럼 문맥을 읽고 판단해야 하는 일은 Agent에게 맡깁니다. - 어떤 문서를 업데이트할지 - 원문과 Wiki 내용이 일치하는지 - 기존 결정이 최신인지 즉: **Deterministic Check → Code** **Semantic Judgment → Agent** 로 역할을 나눕니다. ## 핵심 원칙 2: Writer와 Reviewer 권한 분리 Writer Agent만 실제 파일 쓰기 권한을 가집니다. Reviewer Agent는 읽기만 가능합니다. 이렇게 해야 Reviewer가: **자기가 고치고 → 자기가 통과시키는 문제** 를 막을 수 있습니다. Prompt로 '고치지 마'라고 말하는 것보다 아예 Tool 권한을 제거하는 방식입니다. ## Planner → Writer → Reviewer 자동 Wiki Builder는 크게 세 Agent로 나뉩니다. ### Planner 새 문서를 보고 어떤 Wiki 페이지를: - 새로 만들지 - 수정할지 - 연결할지 계획합니다. ### Writer Planner가 만든 계획을 바탕으로 실제 Wiki 초안을 작성합니다. ### Reviewer 작성된 Wiki를 원문과 대조해 사실 여부를 검증합니다. 전체 흐름은: **New Source → Detect → Plan → Validate Plan → Write → Lint → Review → Publish** 입니다. ## 실패하면 다시 Writer로 돌린다 Lint나 Review에서 실패하면 바로 게시하지 않습니다. Writer에게 다시 수정하도록 보내고 다시 검증합니다. 즉: **Write → Check → Fail → Rewrite → Check** 루프를 만듭니다. ## Build 공간과 Publish 공간을 분리 영상에서는 Agent가 작업하는 임시 Build 공간과, 실제 팀원이 읽는 Published Wiki 공간을 분리합니다. 이렇게 해야 편집 중인 불완전한 문서가 사용자에게 노출되지 않습니다. 즉: **Build Workspace ≠ Serving Workspace** 구조입니다. ## Gate는 Fail-Closed 검사 기록이 없거나 판정이 누락되면 통과시키지 않습니다. 즉: > 검증이 없으면 승인 이 아니라: > 검증이 없으면 차단 방식입니다. 이는 자동화 Pipeline에서 매우 중요한 안전 설계입니다. ## Reviewer도 실패할 수 있다 영상에서는 Reviewer가 특정 문장을 원문에서 찾지 못한 채 판정을 내리지 못하고 멈춘 사례를 소개합니다. 이 경험을 통해: - Writer뿐 아니라 Reviewer도 실패할 수 있고 - '판정 없음' 자체를 실패 상태로 처리해야 하며 - Reviewer 재실행 로직이 필요하다는 점 을 강조합니다. 즉 Harness는 Agent의 작업 실패뿐 아니라 **검증 Agent의 실패까지 고려해야 합니다.** ## 문서 신뢰 Lifecycle 자동 생성 Wiki는 모든 페이지를 동일하게 믿으면 안 됩니다. 영상에서는 문서 상태를 나눕니다. ### Draft LLM이 자동 생성했지만 사람이 아직 검토하지 않은 문서 ### Stable 사람 검토가 끝나 실무에서 신뢰해도 되는 문서 ### Deprecated 과거 기록으로 보존하지만 최신 정보는 아닌 문서 이런 Lifecycle을 두면 팀원이 문서를 어느 수준까지 신뢰해야 하는지 알 수 있습니다. ## 자동 Build 결과도 추적 가능해야 한다 Pipeline을 돌릴 때: - 어떤 Source가 새로 들어왔는지 - 어떤 Wiki가 생성됐는지 - 어떤 문서가 수정됐는지 - 어떤 Review가 실패했는지 를 Report로 남깁니다. Agent 자동화일수록 결과만 보는 것이 아니라 **왜 그렇게 바뀌었는지 추적할 수 있어야 합니다.** ## Obsidian의 역할 Obsidian은 Markdown 기반이라: - 파일 구조가 단순하고 - Git으로 버전 관리하기 쉽고 - 링크 기반 Knowledge Graph를 만들 수 있고 - Claude Code가 직접 읽고 수정하기 쉬워 LLM Wiki의 저장소로 적합합니다. 다만 핵심은 Obsidian 자체보다 **Markdown + Link + Schema + Harness** 구조입니다. ## 기업용 LLM Wiki 추천 구조 영상 내용을 실무 관점에서 정리하면 다음과 같습니다. 1. Raw Source는 원본 그대로 보존 2. Wiki Layer는 LLM이 요약·연결 3. Schema는 사람이 관리 4. Planner가 변경 범위 결정 5. Writer만 쓰기 권한 보유 6. Lint는 코드로 결정론적 검사 7. Reviewer는 원문과 의미 검증 8. 모든 검사 통과 후 Publish 9. Draft/Stable/Deprecated 상태 관리 10. RAG로 필요 시 원문 근거 재확인 ## 핵심 정리 이번 영상의 핵심은 단순히 'Obsidian에 Claude를 붙이는 법'이 아닙니다. 더 중요한 것은: > **회사의 흩어진 원문을 자동으로 지식으로 승격시키고, 검증을 통과한 지식만 팀에 배포하는 파이프라인을 만든다** 는 점입니다. 한 줄로 정리하면: **Raw Documents + LLM Wiki + Schema + Planner/Writer/Reviewer Harness + Deterministic Gates = 자동으로 자라는 기업 지식 시스템** 입니다.