AI에게 같은 설명을 반복하지 않으려면LLM Wiki와 회사 지식 저장소를 설계하는 법

1. 문제는 “AI가 모른다”가 아니라 “맥락이 흩어져 있다”이다

현업에서 AI 에이전트를 쓰다 보면 같은 설명을 반복하는 장면이 계속 나온다. 지난주 회의에서 결정한 기준, 누가 왜 그렇게 판단했는지, 특정 프로젝트에서 이미 정한 예외 규칙, 좋은 답변을 받았던 질문 흐름이 채팅방·회의록·개인 메모·문서 폴더에 흩어진다. 사람도 찾기 어렵고 AI도 매번 새로 설명을 들어야 한다.

이때 단순히 “문서를 더 넣자”로 접근하면 오히려 문제가 커진다. 문서 수는 늘어나지만 어떤 문서가 원본인지, 어떤 문서가 팀 기준인지, 어떤 내용은 개인의 생각인지, 어떤 규칙은 더 이상 쓰면 안 되는지 구분이 흐려진다. 지식 저장소의 본질은 저장 공간이 아니라 재사용 가능한 맥락의 운영 체계다.

2. RAG와 LLM Wiki는 출발점이 다르다

RAG는 보통 원본 문서를 쪼개 저장하고, 질문이 들어왔을 때 관련 조각을 검색해 답변에 붙이는 방식이다. 검색 기반 AI 응답 구조이기 때문에 문서가 많은 환경에서 빠르게 시작하기 좋다. 하지만 매번 검색하고, 다시 조립하고, 질문의 의도와 문서 조각의 맥락을 맞춰야 한다.

반면 LLM Wiki는 문서가 처음 들어오는 시점에 의미를 정리한다. 원본을 그대로 버리지 않되, 그 원본이 어떤 주제와 연결되는지, 어떤 결론을 남기는지, 어떤 다른 문서와 이어지는지를 위키 레이어에 기록한다. 쉽게 말해 RAG가 “물어볼 때 찾는 방식”이라면, LLM Wiki는 “들어올 때 정리해 두는 방식”이다.

3. 회사 지식 저장소는 세 레이어로 나눠야 한다

실무 설계에서 중요한 것은 “문서를 어디에 넣을까”보다 “문서의 지위를 어떻게 나눌까”다. 설명자료의 핵심은 원본, 정리된 위키, 규칙 레이어를 분리하는 것이다. 원본은 불변의 자료로 남기고, 위키는 원본을 사람이 읽고 AI가 다시 쓸 수 있는 형태로 정리하며, 규칙은 AI 에이전트가 이 저장소를 어떻게 읽고 쓸지 제한한다.

이 구조가 없으면 모든 문서가 같은 무게로 쌓인다. 좋은 아이디어, 확정된 정책, 개인의 임시 메모, 이미 폐기된 판단이 한 폴더에 섞이면 AI는 “무엇이 현재 기준인지”를 모른다. 결국 사람은 다시 설명하고, AI는 매번 다른 답변을 내놓는다.

4. Obsidian과 Git을 함께 쓰는 이유

비개발자에게는 Obsidian 같은 마크다운 노트 도구가 편하다. 문서 링크, 그래프, 템플릿, 폴더 구조를 사람이 눈으로 보면서 관리할 수 있다. 반면 개발자와 운영자는 Git을 통해 변경 이력, 리뷰, 되돌리기, 자동 검증을 사용할 수 있다. 이 둘을 같은 마크다운 저장소 위에 얹으면 사람이 쓰기 쉬운 지식 공간과 AI가 다루기 쉬운 파일 시스템이 만난다.

자료에서 제안하는 구조는 회사 공용 지식과 개인 작업 공간을 분리한다. 예를 들어 `context`는 팀이 합의한 공유 지식, `members`는 개인별 작업 공간, `_private`는 공유하지 않을 민감·임시 자료로 나눈다. 여기에 에이전트용 지시문과 스킬을 별도 폴더로 관리하면, AI가 아무 문서나 마음대로 읽고 쓰는 상황을 막을 수 있다.

5. 문서가 늘어나면 검색 계층이 필요해진다

처음에는 마크다운 위키만으로 충분해 보인다. 하지만 AI 에이전트가 업무 결과를 계속 기록하기 시작하면 문서 수가 빠르게 늘어난다. 인덱스 파일이 길어지고, 폴더 계층이 깊어지고, 관련 문서를 찾기 위해 사람이 다시 탐색해야 한다. 이 지점에서 RAG 또는 파일 시스템형 검색 계층이 필요해진다.

중요한 점은 순서다. 검색 계층을 먼저 붙인다고 지식 품질이 좋아지지 않는다. 검색은 이미 정리된 자료를 더 잘 찾게 해 주는 장치이지, 엉킨 문서를 자동으로 좋은 지식으로 바꾸는 장치가 아니다. 그래서 원본·정리본·규칙·로그를 먼저 세운 뒤, 늘어난 문서를 색인하고 검색하는 방식이 현실적이다.

6. 지식 저장소에서 가장 어려운 것은 기술이 아니라 거버넌스다

자료의 후반부에서 가장 중요한 대목은 “AI에게 어디까지 맡길 것인가”다. AI는 요약, 링크 정리, 중복 후보 탐지, 형식 검사, 관련 문서 추천을 잘할 수 있다. 그러나 팀 공식 지식으로 확정하는 일, 민감 자료를 공개 범위로 옮기는 일, 삭제하는 일, 보안 권한을 바꾸는 일은 자동화만으로 처리하면 위험하다.

따라서 지식 저장소 운영은 사람과 AI의 역할을 나눠야 한다. AI는 귀찮고 반복적인 정리와 점검을 맡고, 사람은 지식의 지위와 책임을 결정한다. 이 분리가 있어야 저장소가 오래 간다.

7. 작은 회사일수록 “개인 메모”와 “팀 지식”을 섞지 말아야 한다

스타트업이나 작은 조직에서는 속도가 빠르기 때문에 개인이 발견한 팁과 팀의 공식 기준이 쉽게 섞인다. 처음에는 공유가 잘되는 것처럼 보이지만, 시간이 지나면 누가 확정한 내용인지 알 수 없어진다. 특히 AI 에이전트가 이 자료를 읽기 시작하면 개인의 임시 판단이 회사의 공식 규칙처럼 사용될 수 있다.

그래서 저장 위치 자체가 의사결정이어야 한다. 개인 영역에 있는 문서는 참고자료, 공용 영역에 있는 문서는 팀 기준, 원본 영역은 근거, 비공개 영역은 검색 제외 자료로 취급해야 한다. 이 단순한 구분만 지켜도 AI가 읽을 맥락의 품질이 크게 달라진다.

• 개인 영역: 실험, 학습, 임시 판단, 개인 업무 메모를 둔다. 바로 팀 기준으로 쓰지 않는다.
• 공용 영역: 반복 사용 가치가 있고 사람이 승인한 기준을 둔다. AI 에이전트의 기본 참조 대상이다.
• 원본 영역: 계약서, 회의록, 링크, PDF처럼 근거가 되는 자료를 둔다. 해석본과 분리한다.
• 비공개 영역: 민감 자료, 개인 테스트, 공유하면 안 되는 자료를 둔다. 자동 색인에서 제외한다.

8. AI 업무 품질은 모델보다 “재현 가능한 맥락”에서 나온다

좋은 AI 답변을 한 번 받는 것은 어렵지 않다. 어려운 것은 다른 팀원이 같은 기준으로 비슷한 품질의 답변을 반복해서 받는 것이다. 이를 위해서는 프롬프트 몇 줄보다 더 큰 체계가 필요하다. 어떤 문서를 기본으로 볼지, 어떤 스킬을 쓸지, 어떤 검증을 통과해야 하는지, 어떤 답변은 다시 지식 저장소로 들어갈지를 정해야 한다.

이 관점에서 LLM Wiki는 단순한 노트 정리법이 아니다. 회사의 업무 기준, 의사결정 근거, AI 에이전트 운영 규칙을 연결하는 기반이다. 잘 설계하면 새 직원이나 새 에이전트에게 매번 긴 설명을 하지 않아도 된다. 반대로 설계 없이 문서만 쌓으면 AI가 더 많은 쓰레기를 더 빠르게 읽게 될 뿐이다.

9. 지금 바로 적용한다면 이 순서가 현실적이다

처음부터 완성형 지식 그래프나 대규모 검색 시스템을 만들 필요는 없다. 업무에서 반복 설명이 많은 영역 하나를 골라 작게 시작하는 편이 낫다.

1. 반복 설명이 많은 업무 하나를 고른다. 예: 블로그 운영 기준, 계약 검토 기준, 고객 응대 규칙, 개발 배포 절차.
2. 원본 폴더와 위키 폴더를 분리한다. 원문 자료와 AI가 읽을 정리 문서를 한 파일에 섞지 않는다.
3. 문서 frontmatter를 통일한다. 주제, 상태, 출처, 담당자, 공개 범위, 마지막 업데이트일을 최소 항목으로 둔다.
4. 팀 지식 승격 절차를 만든다. 개인 메모가 공용 기준이 되려면 리뷰와 승인 흔적이 남아야 한다.
5. AI가 할 일과 못 할 일을 적는다. 요약·링크·중복 탐지는 맡기되 삭제·권한·공식 기준 변경은 승인 절차를 둔다.
6. 문서량이 늘어난 뒤 검색 계층을 붙인다. 먼저 정리 체계를 만들고, 그다음 색인과 검색을 자동화한다.