AI · Local LLM · Knowledge System

나만의 LLM Wiki 구축 전략
로컬 LLM·RAG·노트·업무지식을 연결하는 실전 설계도

“M5 프로맥스 128GB로 나만의 LLM Wiki를 구축한다”는 아이디어의 핵심은 고성능 장비 자랑이 아니다. 진짜 포인트는 개인의 문서·메모·업무 맥락을 LLM이 읽고, 찾고, 추론하고, 다시 지식으로 축적하는 개인 지식 운영체제를 만드는 데 있다.

1. LLM Wiki란 무엇인가: 위키, 검색, 챗봇의 중간이 아니다

전통적인 위키는 사람이 읽기 좋게 문서를 정리하는 시스템이다. 검색엔진은 키워드를 기준으로 문서를 찾는다. 챗봇은 대화형 인터페이스를 제공한다. LLM Wiki는 이 셋을 단순히 합친 것이 아니다. 핵심은 문서의 위치를 찾는 데서 멈추지 않고, 문서 사이의 관계를 묶고, 사용자의 질문 목적에 맞게 답을 재구성하며, 답변의 근거 문서를 다시 제시하는 것이다.

따라서 LLM Wiki는 “ChatGPT에 파일을 많이 넣어둔 것”과 다르다. 파일을 많이 넣어도 문서가 중복·오래됨·출처 불명·버전 충돌 상태라면 모델은 그럴듯하지만 틀린 답을 한다. 반대로 문서 수가 적어도 파일명, 요약, 태그, 작성일, 적용 범위, 폐기 기준이 정리되어 있으면 LLM은 훨씬 안정적으로 작동한다.

LLM Wiki의 본질은 모델 성능보다 지식의 정리 상태를 모델이 활용 가능한 형태로 바꾸는 것이다. 좋은 위키는 검색 가능한 창고가 아니라 질문에 답할 수 있는 지식 회로다.

2. 왜 지금 로컬 LLM Wiki인가: 클라우드 AI만으로는 부족한 이유

클라우드 LLM은 편하고 강력하다. 하지만 개인·팀 지식 시스템으로 쓰려면 세 가지 제약이 생긴다. 첫째, 민감한 내부 문서나 사적인 메모를 외부 서비스에 올리기 어렵다. 둘째, 장기적으로 문서가 많아질수록 매번 업로드하고 컨텍스트를 구성하는 과정이 번거롭다. 셋째, “어떤 문서를 참고했는지”를 통제하지 않으면 답변 재현성이 떨어진다.

로컬 LLM Wiki는 이 문제를 줄인다. 모델과 문서 인덱스가 개인 장비나 내부 서버에 있기 때문에 민감 자료를 더 세밀하게 통제할 수 있고, 사용 패턴에 맞춰 검색·요약·태그 규칙을 바꿀 수 있다. 특히 64GB·128GB급 통합 메모리나 고성능 GPU 환경은 큰 문서 세트와 중간급 오픈 모델을 함께 운영할 여지를 넓힌다.

현실적인 결론은 하이브리드다. 민감 문서 검색과 1차 요약은 로컬에서 처리하고, 공개 자료 기반 심화 추론이나 고난도 작성은 클라우드 모델을 선택적으로 쓴다. 이때 중요한 것은 “모든 것을 로컬로 해야 한다”가 아니라 “어떤 데이터가 어디까지 나가도 되는지”를 기준으로 라우팅하는 것이다.

3. 전체 아키텍처: LLM Wiki는 6개 층으로 나눠야 한다

이 6개 층을 구분하지 않으면 시스템이 금방 엉킨다. 예를 들어 모델 실행층에서 성능이 나빠 보이는 문제가 실제로는 원천 자료의 파일명이 엉망이거나, 청킹이 문맥을 끊었거나, 오래된 문서가 최신 문서를 덮어버린 문제일 수 있다. LLM Wiki의 문제는 대개 모델 문제가 아니라 지식 파이프라인 문제다.

4. 하드웨어 판단: 128GB 메모리는 무엇을 해결하고, 무엇을 해결하지 못하나

고성능 로컬 장비의 장점은 분명하다. 더 큰 모델을 올릴 수 있고, 긴 컨텍스트·여러 도구·동시 작업을 더 안정적으로 돌릴 수 있다. 특히 통합 메모리 구조의 고사양 맥은 CPU·GPU가 큰 메모리 풀을 공유하기 때문에 로컬 추론 실험에 매력적이다. 다만 128GB 메모리가 모든 문제를 자동으로 해결하지는 않는다.

장비를 살지 말지의 기준은 “모델 몇 B를 돌릴 수 있나”만 보면 안 된다. 하루에 몇 번 질문하는지, 문서가 얼마나 민감한지, 인터넷 없이 작업해야 하는지, 검색 지연시간을 얼마나 줄여야 하는지, 여러 사람이 동시에 쓸지까지 봐야 한다. 개인용 LLM Wiki라면 128GB급 장비는 강력한 옵션이지만, 먼저 작은 구조로 시작해 병목을 확인한 뒤 확장하는 편이 안전하다.

5. 문서 구조: LLM이 잘 읽는 위키는 사람이 보기 좋은 위키와 조금 다르다

사람은 문맥을 추론할 수 있지만 LLM 검색 시스템은 문서 조각을 기준으로 검색한다. 따라서 긴 문서 하나에 모든 것을 넣는 방식은 RAG에 불리할 수 있다. 반대로 너무 잘게 쪼개면 문맥이 끊긴다. 좋은 LLM Wiki 문서는 한 페이지 안에 핵심 요약, 적용 범위, 원문 출처, 관련 문서, 업데이트 일자를 갖춰야 한다.

Obsidian 같은 마크다운 기반 노트앱은 이런 구조를 만들기 좋다. 파일이 로컬에 남고, 링크와 태그를 사람이 직접 다듬을 수 있으며, 필요하면 다른 도구가 폴더를 읽어 인덱싱하기도 쉽다. 다만 노트앱 자체가 LLM Wiki는 아니다. 노트앱은 지식의 저장소이고, LLM Wiki는 그 저장소를 검색·추론·검증하는 운영 레이어다.

6. RAG 설계: 벡터DB만 붙이면 끝난다는 착각

RAG는 문서를 검색해 LLM 답변에 넣는 방식이다. 하지만 “벡터DB에 넣었다”는 말만으로는 충분하지 않다. 검색 품질은 청킹, 임베딩 모델, 메타데이터, 키워드 검색, 재랭킹, 답변 검증 방식에 좌우된다. Chroma 문서가 설명하듯 벡터 검색은 문서·메타데이터 저장, 임베딩, 밀집·희소·하이브리드 검색, 메타데이터 필터링 같은 여러 기능으로 구성된다.

좋은 RAG는 “비슷한 문서 찾기”가 아니라 “지금 질문에 답할 수 있는 최신·신뢰 문서만 골라내기”다. 특히 개인 위키에서는 오래된 아이디어, 임시 메모, 확정 문서가 섞인다. 따라서 문서 상태와 업데이트 일자를 메타데이터로 넣는 것이 모델 선택만큼 중요하다.

7. 도구 조합: 처음부터 복잡하게 만들 필요는 없다

LLM Wiki를 구축할 때 도구 욕심이 생기기 쉽다. Ollama, llama.cpp, AnythingLLM, Chroma, LlamaIndex, Obsidian, Open WebUI, Docker, NAS, OCR, 자료 수집 자동화까지 한 번에 붙이고 싶어진다. 하지만 처음부터 거대한 시스템을 만들면 운영이 안 된다. 추천은 3단계다.

Ollama는 오픈 모델을 쉽게 실행하는 진입점으로 좋다. llama.cpp는 다양한 하드웨어에서 로컬 추론을 세밀하게 다루는 데 강점이 있다. AnythingLLM은 문서 기반 대화 인터페이스를 빠르게 만들기에 적합하다. LlamaIndex는 데이터 연결·RAG·에이전트 워크플로를 더 구조적으로 만들 때 유용하고, Chroma는 임베딩과 검색 인프라를 직접 설계할 때 선택지가 된다.

8. LLM Wiki의 폴더 설계: 업무 시스템처럼 나눠야 한다

개인 지식 저장소는 대개 처음에는 자유롭게 시작한다. 하지만 LLM Wiki로 전환하려면 폴더 구조가 운영 기준이 된다. 추천 구조는 “주제별 폴더”가 아니라 “사용 방식별 폴더”다. 예를 들어 자료, 결정, 실행, 회고, 템플릿, 아카이브를 나누면 모델이 문서의 역할을 더 잘 구분한다.

llm-wiki/
  00_inbox/                # 아직 정리하지 않은 캡처·메모·파일
  10_sources/              # 원문 자료: PDF, 웹클립, 공식 문서, 링크 요약
  20_notes/                # 사람이 정리한 주제별 노트
  30_decisions/            # 의사결정 기록: 왜 그렇게 결정했는가
  40_projects/             # 프로젝트별 진행 맥락과 산출물
  50_templates/            # 프롬프트, 보고서, 체크리스트, 회의록 템플릿
  60_evaluations/          # 모델 답변 평가셋, 실패 사례, 개선 기록
  90_archive/              # 오래되었지만 보존할 자료

각 문서 상단 공통 메타데이터:
- title: 문서 제목
- status: active / draft / archived / superseded
- source: official / internal / personal / web
- updated: YYYY-MM-DD
- scope: 적용 범위
- related: 관련 문서

이 구조에서 가장 중요한 폴더는 `30_decisions`와 `60_evaluations`다. 많은 지식 저장소가 자료 수집에는 강하지만, 왜 그렇게 판단했는지와 답변이 언제 틀렸는지를 기록하지 않는다. LLM Wiki는 실패 기록을 먹고 좋아진다. 틀린 답변, 누락된 문서, 잘못된 검색 결과를 따로 모아야 다음 인덱싱 전략을 고칠 수 있다.

9. 운영 루틴: 매일 쓰지 않으면 위키는 죽는다

LLM Wiki는 한 번 구축해서 끝나는 프로젝트가 아니다. 위키는 운영 루틴이 없으면 곧바로 낡는다. 가장 현실적인 루틴은 매일 10분, 매주 60분, 매월 2시간으로 나누는 것이다.

LLM Wiki의 경쟁력은 지식량이 아니라 업데이트 습관에서 나온다. 매일 들어오는 자료가 정리되지 않으면 위키는 곧 쓰레기장을 닮는다. 반대로 문서가 적어도 매주 실패 사례를 반영하면 답변 품질은 빠르게 좋아진다.

10. 보안과 프라이버시: 개인 위키일수록 더 조심해야 한다

로컬 LLM Wiki는 데이터 통제력이 높지만, 그만큼 실수도 직접 책임져야 한다. 개인 금융자료, 계약서, 가족 정보, 고객 문서, 회사 내부 자료를 한 저장소에 넣을 경우 유출 위험이 커진다. 특히 클라우드 모델과 하이브리드로 연결할 때는 어떤 문서 조각이 외부 API로 나가는지 반드시 통제해야 한다.

11. 답변 품질 평가: 좋은 위키는 테스트셋을 가진다

LLM Wiki를 운영하면 어느 순간 “잘 되는 것 같은데 믿어도 되나?”라는 문제가 생긴다. 이때 필요한 것이 평가셋이다. 자주 묻는 질문 30개, 정답 근거 문서, 허용 가능한 답변 기준, 실패 기준을 만들어야 한다. 모델을 바꾸거나 임베딩 모델을 바꾸거나 청킹 전략을 바꿀 때 이 평가셋으로 비교한다.

평가 질문: 〈실제로 자주 묻는 질문〉
정답 근거 문서: 〈문서 경로 또는 링크〉
반드시 포함할 내용: 〈핵심 사실 3개〉
절대 하면 안 되는 답변: 〈오래된 규칙, 추정, 출처 없는 단정〉
통과 기준:
1. 근거 문서 제목을 제시한다.
2. 최신 문서를 우선한다.
3. 모르는 부분은 모른다고 말한다.
4. 실행 가능한 다음 행동을 제안한다.
5. 답변 후 보강해야 할 문서를 알려준다.

이 평가셋이 있으면 도구 선택이 감이 아니라 데이터가 된다. Ollama 모델 A가 빠르지만 근거를 놓치는지, llama.cpp로 돌린 모델 B가 느리지만 안정적인지, 클라우드 모델 C가 요약은 잘하지만 내부 규칙을 과하게 일반화하는지 비교할 수 있다.

12. 구축 로드맵: 30일 안에 쓸 수 있는 LLM Wiki 만들기

처음부터 완벽한 시스템을 만들려 하면 실패한다. 30일 로드맵은 작게 시작해 실제 질문을 기준으로 확장하는 방식이 좋다.

30일 뒤 목표는 “멋진 데모”가 아니라 매일 쓰는 시스템이다. 검색 결과가 조금 거칠어도 괜찮다. 중요한 것은 질문이 생겼을 때 위키를 먼저 열고, 답변이 틀렸을 때 문서를 고치고, 다시 검색 품질이 좋아지는 순환을 만드는 것이다.

13. 바로 복사해 쓰는 구축 프롬프트

LLM Wiki 구축의 첫 단계는 도구 설치가 아니라 현재 지식 상태 진단이다. 아래 프롬프트는 폴더 구조, 문서 상태, 우선순위, RAG 설계를 한 번에 점검하도록 만든 것이다.

역할: 너는 개인 지식관리 시스템 설계자이자 RAG 아키텍트다.
목표: 내 문서와 메모를 기반으로 로컬 LLM Wiki를 구축하려 한다.

입력 정보:
- 주 사용 목적: 〈투자 리서치 / 업무 매뉴얼 / 글쓰기 / 코드 지식 / 개인 기록 중 선택〉
- 현재 자료 형태: 〈PDF, 웹클립, 마크다운, 회의록, 이미지, 표, 코드 등〉
- 문서 규모: 〈대략 파일 수와 용량〉
- 민감도: 〈외부 전송 가능 / 로컬만 허용 / 일부만 허용〉
- 사용 장비: 〈CPU, GPU, 메모리, 저장공간〉
- 선호 도구: 〈Obsidian, Ollama, llama.cpp, AnythingLLM, Chroma, LlamaIndex 등〉

산출물:
1. 추천 폴더 구조
2. 문서 메타데이터 규칙
3. 인덱싱 전 정리해야 할 자료 목록
4. RAG 구성안 2가지: 간단형과 확장형
5. 보안상 외부 전송 금지 데이터 기준
6. 첫 30일 구축 로드맵
7. 매주 점검할 품질 지표

품질 기준:
- 도구 이름 나열보다 운영 루틴을 우선한다.
- 오래된 문서, 중복 문서, 출처 없는 문서 처리법을 포함한다.
- 모르는 영역은 추정하지 말고 추가 확인 질문으로 분리한다.
- 최종 답변은 표와 체크리스트 중심으로 작성한다.

역할: 너는 지식 저장소 편집자다.
목표: 아래 문서를 LLM Wiki에 넣기 좋은 형태로 정리한다.

입력 문서:
〈문서 본문 또는 요약〉

작업:
1. 한 줄 요약을 만든다.
2. 핵심 키워드 5~8개를 뽑는다.
3. 문서 상태를 active, draft, archived, superseded 중 하나로 제안한다.
4. 적용 범위와 유효기간을 추정하되, 확실하지 않으면 확인 질문으로 남긴다.
5. 관련 문서로 연결하면 좋은 주제를 제안한다.
6. RAG 검색용 짧은 요약과 사람이 읽을 긴 요약을 따로 만든다.
7. 답변에 쓰면 위험한 모호한 표현을 표시한다.

출력 형식:
- YAML 메타데이터
- 5문장 요약
- 관련 질문 예시 5개
- 보강 필요 항목

14. 최종 판단: LLM Wiki는 개인 생산성 도구가 아니라 기억의 인프라다

LLM Wiki를 구축하려는 사람은 보통 “내 자료를 AI가 다 기억해주면 좋겠다”에서 출발한다. 하지만 실제로 얻는 가치는 단순 기억보다 크다. 잘 만든 LLM Wiki는 내가 무엇을 알고 있는지, 무엇을 잊었는지, 어떤 판단이 어떤 근거에서 나왔는지, 어떤 문서가 낡았는지를 계속 드러낸다.

따라서 성공적인 LLM Wiki의 목표는 “AI가 대신 생각하게 만들기”가 아니다. 사람의 판단은 남기고, 반복 검색·문맥 회수·1차 구성·근거 추적을 시스템화하는 것이다. 로컬 LLM과 RAG는 그 목표를 위한 기술 레이어이고, 노트 구조와 운영 루틴은 그 기술이 실제로 작동하게 만드는 토대다.

지금 시작한다면 거창한 시스템보다 작은 위키가 낫다. 핵심 문서 50개, 질문 30개, 평가 기준 10개, 주간 정리 루틴 하나면 충분하다. 이 작은 루프가 안정적으로 돌기 시작하면 장비와 도구를 확장해도 늦지 않다.