AI에게 "이번 달 전환율이 왜 떨어졌나요?"라고 물었을 때, AI가 그럴듯한 답을 내놓는다면 — 그 답이 우리 회사의 '전환' 정의를 기반으로 한 것인지 어떻게 알 수 있을까요?
범용 LLM은 세상의 지식은 알지만, 나만의 기준은 모릅니다. LLM WIKI는 이 간극을 메우는 지식 레이어입니다. 이 글에서는 LLM 위키가 무엇인지, 왜 필요한지, 그리고 기업에서는 어떻게 구성할 수 있는지를 설명합니다.
LLM이 지식을 다루는 두 가지 방식 — 학습된 것과 주입된 것
범용 LLM 모델이 지식을 다루는 방식은 크게 두 가지로 나뉩니다.
첫 번째는 파라메트릭 지식(parametric knowledge)입니다. 모델이 사전 학습 과정에서 방대한 텍스트를 읽고 가중치(weight)에 새겨 넣은 지식입니다. GPT나 Claude가 역사적 사실, 일반적인 언어 패턴, 프로그래밍 문법을 아는 것은 이 방식 덕분입니다.
두 번째는 컨텍스트 지식(contextual knowledge)입니다. 모델이 추론하는 시점에 프롬프트나 외부 검색을 통해 주입되는 지식입니다. 오늘의 주가, 최신 뉴스, 그리고 우리 회사의 지표 정의가 이 방식으로 전달됩니다.
범용 LLM은 파라메트릭 지식만으로 작동하기 때문에 "매출"의 언어적인 정의가 무엇인지는 알지만, 우리 회사가 환불 건을 매출에서 차감하는지, 특정 상황에서의 해당 단어의 정의에 대해서는 파악할 수 없습니다. 파라메트릭 지식의 또 다른 한계는 시간입니다. 모델은 사전 학습 데이터의 지식의 유입 이후 정보를 반영하지 못하며, RAG(검색 증강 생성)가 이 한계를 보완하는 주요 아키텍처로 주목받는 것도 같은 이유입니다. 이것은 모델 성능의 문제가 아니라 구조의 문제라고 할 수 있습니다.
LLM 위키 개념의 등장 — RAG와 무엇이 다른가
지금까지 이 한계를 해결하는 주요 접근법은 RAG(검색 증강 생성)였습니다. 질의가 들어오면 관련 문서를 검색해 LLM의 답변 생성에 주입하는 방식입니다. 하지만 RAG 방식도 근본적인 한계가 있습니다. 바로 질문이 들어올 때마다 매번 문서를 검색한다는 점입니다. 예를 들어, AI에게 "휴가는 며칠 사용할 수 있나요?"라는 질문을 하면 관련 규정을 찾아 답변합니다. 그런데 이어서 "반차는 어떻게 사용하나요?", "연차 이월은 가능한가요?"처럼 비슷한 질문을 해도 AI는 이전에 찾은 내용을 활용하지 않고, 그때마다 다시 문서를 검색합니다. 결과도 이전과 정확하게 같지 않습니다.
오픈AI 공동 창립자 안드레이 카파시가 2026년 4월 공개한 아이디어에서 출발한 LLM 위키는 이 문제를 다르게 접근했습니다. 바로 LLM이 단순히 문서를 검색하는 RAG 방식 대신 영구적이고 점진적으로 축적되는 위키를 직접 작성·유지하는 구조를 만들기를 제안한 것입니다.
이 구조에서 LLM은 문서를 검색만 하는 것이 아니라, 구조화된 위키를 직접 작성하고 유지합니다. 새로운 지식이 들어오면 AI가 그것을 읽고, 핵심 정보를 추출하고, 기존 위키에 통합합니다. 관련 페이지를 업데이트하고, 모순점을 표시하고, 참조를 유지합니다. 지식이 한 번 컴파일(저장)되면 매번 재발견할 필요가 없습니다.
LLM 위키의 구성 요소
LLM 위키는 최소 5가지의 요소로 구성됩니다.
my-llm-wiki/ raw/ wiki/ index.md log.md CLAUDE.md 또는 AGENTS.md
raw/ — 원문 저장소 (절대 수정하지 않는 증거 레이어)
웹 문서, PDF, 회의록, 인터뷰 기록 등 아직 정리되지 않은 원본 자료를 보관하는 공간입니다. 핵심 원칙은 이곳의 파일을 절대 수정하지 않는 것입니다. 이후 위키나 요약 문서에 오류가 생기더라도 언제든 원본을 확인할 수 있는 기준점이 필요하기 때문입니다. 예를 들어 고객이 인터뷰에서 "가격이 비싸다"라고 말한 내용을 위키에 "가격 민감도가 높다"라고 정리할 수는 있습니다. 하지만 두 표현은 완전히 같은 의미가 아닐 수 있으므로, 원문의 맥락은 raw/에 그대로 보존되어야 합니다.
wiki/ — LLM이 관리하는 지식층
raw/에 저장된 원문을 바탕으로 주제별 지식을 정리하는 공간입니다. 하나의 원문이 여러 위키 페이지를 갱신할 수도 있고, 하나의 위키 페이지가 여러 원문을 근거로 만들어질 수도 있습니다. 즉, 문서는 출처별로 보관하지만 지식은 주제별로 관리합니다. 각 페이지에는 개념 정의, 핵심 내용, 근거가 되는 원문, 관련 문서, 아직 확인되지 않은 내용 등을 함께 기록합니다.
CLAUDE.md / AGENTS.md — AI에게 주는 운영 규칙
AI에게 "이 위키를 어떻게 다뤄야 하는지" 알려주는 규칙 파일입니다. 이것이 없으면 매번 다른 방식으로 정리될 수 있습니다. 스키마에는 "raw/는 수정하지 않는다", "출처 없는 주장은 표시한다", "모순을 발견하면 덮어쓰지 말고 기록한다"와 같은 규칙이 들어갑니다. 특히 중요한 것은 불확실성, 할루시네이션을 다루는 규칙입니다. AI는 빈칸을 채우려는 경향이 있으므로, 확인되지 않은 내용은 사실처럼 쓰지 않도록 정확하게 명시해야 합니다.
index.md — 위키의 지도
LLM위키가 방대해지면 좋은 내용이 있어도 어디 있는지 파악을 못하는 문제가 생깁니다. index.md는 위키의 구조를 사람이 이해할 수 있게 보여주는 말 그대로 위키를 인덱스해주는 문서입니다. 핵심 개념, 진행 중인 프로젝트, 최근 중요한 결정, 검토가 필요한 문서를 보여주는 운영 대시보드 역할로도 기능합니다.
log.md — 변경 추적과 감사 기록
AI가 어떤 자료를 읽고, 어떤 문서를 만들고, 무엇을 바꾸었는지 기록합니다. 위키가 커질수록 로그의 가치는 커집니다. 왜 이런 결정을 내렸는지, 언제 어떤 자료를 근거로 바뀌었는지 확인할 수 있기 때문입니다.
기업의 LLM 위키 활용 — 회사 고유 지식을 AI 추론의 기반으로
카파시는 LLM Wiki를 소개하며 개인 지식 관리뿐 아니라 비즈니스와 팀 환경에서의 활용 가능성도 제시했습니다.
이 개념을 기업의 데이터 분석과 AI 거버넌스에 적용하면 관리 대상은 개인 메모가 아니라 회사의 지식이 됩니다. 지표 정의, 이벤트 택소노미, 비즈니스 규칙처럼 AI가 추론에 활용해야 하는 정보를 체계적으로 관리하는 것입니다.
구조는 단순합니다. raw/에는 회의록, 데이터 사전, 정책 문서 등 원본 자료를 그대로 보관합니다. wiki/에는 여러 문서를 바탕으로 정리한 지식을 주제별로 축적합니다. 그리고 스키마에는 "리텐션은 7일 내 재방문으로 정의한다", "전환은 첫 결제 이벤트를 기준으로 한다"와 같은 회사 고유의 규칙을 기록합니다. AI는 답변을 생성할 때 이 구조를 참조해 추론합니다.
이러한 구조가 필요한 이유는 실제 성능 차이에서도 확인됩니다. Spider 2.0 벤치마크에 따르면, 실제 엔터프라이즈 데이터베이스 환경에서 기본 에이전트 설정으로 SQL을 생성했을 때 정확도는 약 10%대에 그쳤습니다. 반면 동일한 모델에서 정답이 잘 정리된 공개 데이터셋을 대상으로 한 Spider 1.0 테스트에서는 86% 이상의 정확도를 기록했습니다. 이는 모델의 성능이 갑자기 떨어진 것이 아니라, 기업마다 다른 데이터 스키마와 비즈니스 규칙을 알지 못한 상태에서 추론했기 때문임을 증명하고 있습니다.
도입 방법 — 직접 구축 vs. 플랫폼 활용
LLM Wiki 패턴을 기업에 직접 구축하는 것은 가능합니다. 하지만 구축보다 더 어려운 것은 지식을 지속적으로 최신 상태로 유지하고, 조직 전체에서 신뢰할 수 있도록 운영하는 것입니다.
데이터 스키마가 변경되면 위키의 지표 정의도 함께 수정해야 하고, 새로운 이벤트가 추가되면 이벤트 택소노미와 비즈니스 규칙도 반영해야 합니다. 실제 데이터와 LLM Wiki의 내용이 어긋나는 순간, AI는 오래된 정보를 바탕으로 추론하게 됩니다. Spider 2.0 연구에서도 데이터베이스의 테이블이 추가·분할·병합되는 등 스키마가 변경되면 text-to-SQL 정확도가 최대 24%p까지 하락하는 것으로 나타났습니다. AI 모델의 성능만큼이나 지식과 스키마를 최신 상태로 유지하는 것이 중요하다는 의미입니다.
기업 환경에서는 실무자 개인마다 관리하는 LLM Wiki를 하나로 통합하는 일도 쉽지 않습니다. 부서마다 사용하는 용어와 지표 정의가 다를 수 있고, 동일한 개념을 서로 다른 방식으로 관리하는 경우도 많습니다. 여기에 문서별 접근 권한, 개인정보, 보안 정책까지 함께 고려해야 합니다. 단순히 문서를 한곳에 모으는 것만으로는 기업이 신뢰할 수 있는 LLM Wiki를 만들기 어렵습니다.
이러한 문제를 해결하려면 LLM Wiki는 단순한 문서 저장소를 넘어 AI가 신뢰할 수 있는 지식 인프라로 동작해야 합니다. 지표 정의와 이벤트 택소노미가 AI의 추론 기반과 연결되어 있어야 하고, 스키마나 비즈니스 규칙이 변경되면 AI도 자동으로 최신 기준을 반영해야 합니다. 또한 사용자는 SQL이나 코드를 작성하지 않고도 자연어만으로 회사의 기준에 맞는 분석과 답변을 얻을 수 있어야 합니다. 그래야 LLM Wiki가 단순한 기록이 아니라 실제 업무에 활용되는 시스템이 됩니다.
이러한 구조를 직접 구축할 수도 있지만, 이미 이를 지원하는 플랫폼을 활용하는 방법도 있습니다.
ThinkingAI Agentic Engine는 기업의 정형 데이터와 비정형 데이터를 하나의 지식베이스로 연결해 AI가 함께 활용할 수 있도록 설계됐습니다. 데이터베이스 스키마와 이벤트 정의 같은 정형 데이터뿐 아니라 정책 문서, 데이터 사전, 회의록, 운영 가이드 등 비정형 데이터도 함께 참조하여 회사 고유의 지식베이스를 구성합니다.
또한 권한 관리와 접근 제어를 통해 조직의 지식을 안전하게 통합하고, 변경된 지표 정의와 비즈니스 규칙도 AI의 추론 과정에 반영할 수 있도록 지원합니다. 이를 통해 사용자는 SQL 없이도 자연어만으로 회사의 기준에 맞는 일관된 분석 결과를 얻을 수 있습니다.
하지만 데이터·지식·컴플라이언스 등 규범의 최신화에 민감하고, 권한 관리가 필요하며, LLM을 연결하는 시스템까지 구축해야 한다면,
