회사 자료를 노트북 밖으로 안 내보내는 팀 AI 위키 (로컬 LLM · 옵시디언 · Ollama)

회의록과 규정을 외부 AI 서비스에 올리기 어려운 팀은 같은 작업을 노트북 한 대 안에서 처리할 수 있습니다. 이 글은 코텍시스가 교육 영상용으로 실습한 구성(Ollama, 옵시디언, Karpathy LLM Wiki 플러그인)을 정리하고 M3 Pro 메모리 18GB 맥북에서 잰 시간과 작은 모델이 틀린 곳을 함께 기록합니다. 실습 자료는 가상의 마케팅팀 회의록·고객 미팅록·규정·설문 15건입니다. 온프레미스 모델 비교와 LLM 위키 운영 사례는 10월 1주 AI 동향에서 다뤘으므로 여기서는 노트북 구성과 실측만 다룹니다.

노트북 안에서 처리하는 이유

외부 AI 서비스에 자료를 넣으면 그 내용은 서비스 업체의 서버로 전송됩니다. 노트북에서 모델을 실행하면 요청과 답이 같은 컴퓨터 안의 localhost에서 오갑니다. 이 구성은 보안 인증을 대신하지 않습니다. 노트북 자체가 해킹당하거나 분실되면 자료도 같이 노출됩니다. 얻는 것은 자료가 처리되는 위치를 팀이 직접 정할 수 있다는 점입니다. 계약서·인사 자료처럼 밖으로 보내기 어려운 문서는 노트북의 작은 모델에 맡기고 공개 자료는 회사가 승인한 클라우드 AI에 맡기는 식으로 자료 등급별로 나눌 수 있습니다.

위키 방식을 고른 이유도 있습니다. 질문할 때마다 폴더 전체를 다시 뒤지는 대신 AI가 원문을 한 번 읽고 고객사별·주제별·규정별 페이지로 정리해 둡니다. 안드레이 카파시가 2026년 4월 4일 공개한 LLM Wiki 방식입니다. 원본 폴더는 AI가 읽기만 하고, 위키 폴더는 AI가 쓰고 고치며, 사람은 위키를 읽고 확인한 뒤 잠급니다.

구성 3가지와 데이터 흐름

흐름은 원본자료 폴더 → 플러그인 → Ollama → 플러그인 → wiki 폴더 순서입니다. 위키 페이지는 엔티티(사람·고객사), 개념(주제), 원문 요약 세 가지로 나뉘고 페이지 맨 위 YAML 이름표에 type, sources(근거 원문), aliases(다른 이름), reviewed가 붙습니다. reviewed: true인 페이지는 사람이 확인한 페이지로 보호되어 AI가 다시 정리할 때 고치지 않습니다.

설치와 연결 절차

1. Ollama를 설치하고 모델을 미리 내려받습니다. 8GB 파일이라 시간이 걸리므로 시연이나 업무 전에 받아 둡니다.
2. 옵시디언에서 팀 폴더를 볼트로 엽니다. 실습 볼트는 원본자료, 이번주_추가, wiki 세 폴더로 구성했습니다.
3. 설정의 커뮤니티 플러그인에서 Karpathy LLM Wiki를 설치합니다. 개인 개발자가 만든 플러그인이므로 회사 PC라면 IT 담당자에게 먼저 확인합니다.
4. 플러그인 설정에서 LLM Provider를 Ollama (Local)로 고르고 모델을 선택한 뒤 연결 테스트를 누릅니다.
5. 원본자료 폴더를 지정하고 수집을 시작합니다.

실습 볼트에 저장된 플러그인 설정은 Provider ollama, 주소 http://localhost:11434/v1, 모델 gemma4-wiki, 위키 언어 한국어, 페이지 생성 동시성 1, 호출당 최대 출력 4,096토큰, 추출 세분화 최소, 작업별 사고(thinking) 출력 끔입니다. gemma4-wiki는 gemma4 12B에 초안 모델(draft)을 붙이고 컨텍스트를 16,384토큰으로 지정해 Ollama에 따로 만든 모델입니다.

자료가 밖으로 나가는 설정이 두 군데 있으므로 함께 확인합니다. 플러그인의 Markdown 변환 백엔드에는 MinerU 선택지가 있고 화면 설명에 온라인 서비스이며 API 토큰이 필요하다고 적혀 있습니다. 실습에서는 내장 방식(native)을 썼습니다. Ollama 앱 설정에는 클라우드 모델과 웹 검색을 쓰는 Cloud 토글이 있으므로 노트북 안에서만 처리하려면 꺼 두었는지 확인합니다. 글을 쓰는 시점에 이 맥에서 lsof로 확인한 Ollama의 소켓은 모두 127.0.0.1이었습니다. 다만 이 확인은 모델이 답을 생성하지 않는 상태에서 한 것입니다.

실측: 걸린 시간과 속도

병목은 속도였습니다. 아래 값은 실습에서 이 노트북(M3 Pro, 메모리 18GB)으로 잰 것입니다.

실습 정리에서는 자료 한 건 분석에 2~6분이 걸렸고, 플러그인 기록에는 문서 한 건의 수집 전체가 3분 반에서 20분 사이로 남아 있습니다. 14건 기록을 합하면 약 2시간 33분이라 전체 시간과 맞습니다. 처음 설정으로는 14분이 지나도 한 쪽도 만들지 못했습니다. 설정을 조정한 뒤 수집이 끝났고, 볼트에 저장된 최종 설정은 앞 절에 적은 값입니다. 어느 항목이 결정적이었는지는 따로 확인하지 않았습니다.

결과 위키에 가을 프로모션 예산 1,800만 원의 결재선을 물으면 마케팅팀장, 경영지원팀장, 대표이사라는 답과 근거 문서 링크가 나옵니다. 회의록에는 마케팅팀장과 경영지원 순서만 적혀 있고, 1,000만 원 초과 시 대표이사 결재를 더하는 조항은 예산집행 규정에 있습니다. 두 문서를 합친 답이 원문 링크와 함께 나오므로 사람이 바로 대조할 수 있습니다.

작은 모델이 틀리는 곳과 점검 절차

고객 설문 30건을 Ollama 채팅에 첨부하고 가장 불편했던 점을 유형별로 세게 했습니다.

원본에는 가격 2건과 포장 상태 2건이 더 있고, 표는 실습에서 비교한 네 항목만 옮겼습니다. qwen3.5 9B는 한 항목을 하나 더 세고 다른 항목을 빼면서 합계는 28건이라고 적었습니다. 실습에서는 실행할 때마다 틀리는 곳도 달라졌습니다.

위키에도 같은 유형의 오류가 남았습니다. 린트는 42쪽에서 출처와 맞지 않는 인용 14곳, 없는 페이지로 가는 링크 8개, 다른 페이지가 링크하지 않는 고아 페이지 3개, 별칭 누락 3쪽을 찾았습니다. 8주차 회의록의 신규 가입 605명이 6055명으로, 참석자 정하늘이 성하늘로, 예산 "확정"이 "적정"으로 옮겨졌습니다. A식품 페이지는 sources에 7월 미팅만 연결되어 8월 재발 내용이 빠졌습니다. 문장은 자연스럽고 숫자 하나만 열 배가 되는 형태라 읽기만 해서는 놓치기 쉽습니다.

점검 순서는 다음과 같습니다. 숫자 세기, 날짜 계산, 긴 문서 뒤쪽 내용, 링크는 작은 모델이 자주 틀리는 항목이므로 우선 확인합니다. 수집이 끝나면 린트를 실행하고 표시된 인용을 원문과 맞춰 고칩니다. 사람이 다 읽은 페이지에는 reviewed: true를 붙여 다음 수집 때 AI가 덮어쓰지 않게 합니다. 새 회의록은 이번주_추가 폴더에 넣고 한 건씩 수집합니다.

노트북으로 처리하는 범위와 서버로 넘길 범위

노트북 구성에 맞는 일은 팀 하나가 쓰는 텍스트 문서 수십 건을 정리하는 작업입니다. 초당 12토큰이면 15건에 2시간 반 정도 걸리므로 퇴근 전에 수집을 시작해 두고 다음 날 아침에 점검하는 방식이 현실적입니다. 실습 자료는 미리 텍스트(마크다운)로 바꿔 둔 것이고 한글(HWP)·엑셀 원본은 이 조합에서 바로 읽히지 않았습니다. 이 글의 절차는 맥에서만 확인했습니다.

문서가 수백 건으로 늘거나 여러 팀이 함께 쓰거나 질문마다 즉시 답이 필요하면 GPU를 갖춘 사내 서버나 회사가 승인한 클라우드로 옮깁니다. 한글·엑셀 원본을 그대로 다뤄야 할 때도 같습니다. 어느 쪽이든 자료를 공개·내부·기밀로 나누고 등급마다 처리할 위치를 먼저 정해 두면 노트북에서 시작한 위키를 서버로 옮길 때 기준을 그대로 쓸 수 있습니다.

참고

• Andrej Karpathy, LLM Wiki (GitHub Gist, 2026-04-04)
• Ollama
• Obsidian
• Karpathy LLM Wiki 플러그인 제작자 GitHub (green-dalii)