1.2 LLM위키는 무엇인가 원문 기반 심화 분석

원문 구조와 실무 의미

1. LLM위키는 앱이 아니라 반복 지식 운영 방식이다

원문은 LLM위키를 배우는 이유를 매번 같은 업무 배경을 다시 설명하지 않기 위한 것이라고 둔다. 팀 용어, 보고서 형식, 금지 표현, 이미 합의한 판단 기준은 한 번의 프롬프트에서 소비될 정보가 아니라 다음 작업에서도 다시 쓸 업무 지식이다.

따라서 이 절에서 가장 먼저 버려야 할 오해는 특정 제품을 설치하면 LLM위키가 된다는 생각이다. 도구가 달라도 raw 보존, wiki 컴파일, 질문, 산출물, 검증, 갱신이 유지되면 LLM위키 방식에 가깝다. 반대로 도구 이름이 그럴듯해도 원천과 정리본이 섞이고 출처가 없으면 좋은 LLM위키가 아니다.

2. 세 층은 신뢰 경계와 작업 계약을 만든다

raw는 사실의 출발점이다. 회의록, 업무 메모, 웹 문서, 코드 리뷰 기록처럼 나중에 다시 확인해야 할 자료가 들어간다. 가능하면 원본 상태를 보존해야 하며, 요약문이나 개인 해석이 원본 자리를 대신하면 안 된다.

wiki는 LLM이 정리한 활용 문서다. 단순 요약문이 아니라 개념, 결정, 절차, 질문을 나누고 서로 연결한 문서다. 다시 질문하고 산출물로 바꾸기 쉬워야 하므로 한 문장 요약, 근거, 확인된 내용, 확인 필요, 다음 질문 같은 구조가 필요하다.

schema 또는 rules는 작업 규칙이다. 실제 도구에서는 AGENTS.md, CLAUDE.md 같은 파일이 이 역할을 할 수 있다. raw를 덮어쓰지 않기, 확인되지 않은 주장을 확인 필요로 표시하기, 모든 wiki 문서에 출처를 남기기 같은 기준을 적는다.

3. 일반 대화와 LLM위키의 차이는 결과물의 수명이다

일반 대화형 사용에서는 회의록을 붙여 넣고 실행 항목, 담당자, 기한, 확인 방법을 표로 만들어 달라고 요청한다. 답변은 즉시 나오지만 다음 주에는 같은 형식과 제외 기준과 팀 용어를 다시 설명해야 한다.

LLM위키 방식은 회의록 원문을 raw로 보관하고, 결정 사항, 실행 항목, 반복 이슈를 wiki 문서로 정리한 뒤, 다음 회의록이 들어왔을 때 기존 wiki와 비교해 바뀐 점을 갱신한다. 한 번 답을 얻는 흐름이 계속 자라는 업무 지식을 만드는 흐름으로 바뀐다.

4. 컴파일은 raw를 업무 판단 가능한 wiki로 재구성하는 일이다

LLM위키에서 컴파일은 원천 자료를 다시 쓰기 좋은 wiki 문서로 바꾸는 일이다. 여기서 다시 쓰기 좋다는 뜻은 짧고 예쁜 요약이 아니라 업무 질문, 보고서, 실행 계획, 검증에 다시 사용할 수 있다는 뜻이다.

회의 메모 실습은 이 기준을 잘 보여 준다. 시간순 회의 메모는 raw이고, 고객 문의 라벨 추천 실험 같은 wiki 문서 후보는 업무 판단에 맞게 재구성한 결과다. 같은 내용이더라도 raw는 근거이고 wiki는 활용 문서다.

5. RAG, 노트 앱, 일반 위키와의 차이는 함께 쓸 수 있는 차이다

원문은 LLM위키가 RAG, 노트 앱, 일반 위키와 겹치는 부분이 많다고 인정한다. 중요한 것은 어느 쪽이 항상 우수한지가 아니라 무엇을 중심 질문으로 삼는가다.

6. 현재 사용 방식 진단은 도구 선택 전에 해야 한다

도구 후보를 고르기 전에 내 업무가 파일 업로드형, 노트형, 일반 위키형, LLM위키형 중 어디에 가까운지 알아야 한다. 첫 시작점은 작고 반복되는 업무가 좋다. 고객 문의 분류, 회의록 실행 항목 정리, 주간 보고서 초안처럼 범위가 작고 반복되는 업무가 적합하다.

7. 잘 맞는 상황과 신중해야 하는 상황

LLM위키가 잘 맞는 상황은 반복성과 근거성이 함께 있는 경우다. 같은 배경 설명을 반복하거나, 자료가 여러 곳에 흩어져 있거나, 답변의 근거를 확인해야 하거나, 보고서와 실행 계획을 반복해서 만들거나, 시간이 지나며 내용이 바뀌는 업무가 여기에 해당한다.

반대로 원천 자료가 거의 없으면 LLM이 추측으로 빈칸을 채울 수 있다. 정보가 매우 민감하면 외부 LLM 호출, 플러그인 권한, 저장 위치를 먼저 확인해야 한다. 정답이 실시간으로 바뀌는 내용은 wiki가 빠르게 오래될 수 있다. 수치 정확도가 핵심이면 원본 데이터와 계산 절차를 별도로 검증해야 한다.

실무 적용 절차

1. 현재 LLM 사용 방식을 적고 파일 업로드형, 노트 앱형, 일반 위키형, LLM위키형 중 어디에 가까운지 표시한다.
2. 고객 문의 분류, 회의록 실행 항목 정리, 주간 보고서 초안처럼 작고 반복되는 업무 하나를 고른다.
3. 팀 용어, 보고서 형식, 금지 표현, 판단 기준, 참고 문서, 결정 이력처럼 매번 다시 설명하는 배경을 분리한다.
4. 회의록, 업무 메모, 웹 문서, 기존 양식, 코드 리뷰 기록 중 나중에 다시 확인할 수 있는 자료만 raw 후보로 둔다.
5. raw 후보마다 출처, 확인일, 자료 성격, 민감 정보 여부를 적는다.
6. 첫 wiki 문서 후보에 한 문장 요약, 근거, 확인된 내용, 확인 필요, 다음 질문을 포함한다.
7. raw를 덮어쓰지 않기, 출처 남기기, 확인 필요 표시하기, 민감 정보 보류하기를 작업 규칙에 쓴다.
8. LLM에게 원천 문서명 유지, 추정 분리, 확인 필요 표시, 다음 질문 생성을 조건으로 raw를 wiki 후보로 컴파일하게 한다.
9. 컴파일 결과를 원문 기준으로 검토하고 출처, 구조, 연결, 갱신 기준을 확인한다.
10. 한 번 답하고 끝날 질문이면 LLM위키로 과하게 만들지 않는다.
11. 채택된 기준은 wiki에 반영하고, 반영 사실은 log.md에 남긴다.
12. 개인정보, 계약 정보, 비공개 코드, 고객 원문은 도구 저장 위치와 외부 전송 범위를 확인하기 전까지 보류한다.

컴파일 산출물 템플릿

체크리스트

개념 이해

• LLM위키를 특정 앱이나 서비스명으로 단정하지 않았다.
• LLM위키를 원천 자료를 오래 쓸 업무 지식으로 바꾸는 패턴으로 설명할 수 있다.
• raw, wiki, schema 또는 rules의 책임을 구분했다.
• 일반 대화, RAG, 노트 앱, 일반 위키와 LLM위키의 차이를 시점과 책임으로 설명할 수 있다.

구조와 컴파일

• raw 원천 자료와 wiki 정리 문서가 분리되어 있다.
• wiki 문서가 raw의 유일한 사본이 되지 않는다.
• 작업 규칙 파일에 raw 보존, 출처 표기, 확인 필요 표시가 있다.
• 컴파일 결과에 출처, 확인된 내용, 확인 필요, 다음 질문, 갱신 기준이 남아 있다.
• 원문에 없는 추정이 확인된 사실처럼 들어가지 않았다.

적용 판단

• 같은 배경 설명을 반복하는 업무인지 확인했다.
• 원천 자료가 실제로 존재한다.
• 답변의 근거 확인이 업무상 중요하다.
• 보고서나 실행 계획 같은 output으로 반복 전환할 필요가 있다.
• 민감 정보, 실시간 정보, 수치 정확도 요구를 별도로 점검했다.

좋은 질문과 검증 질문

LLM에게 던질 좋은 질문

• 아래 raw 메모를 LLM위키 문서 후보로 컴파일해 주세요. 한 문장 요약, 근거, 확인된 내용, 확인 필요, 다음 질문, 갱신 기준으로 나누고 원천 자료명을 유지해 주세요.
• 이 업무가 LLM위키에 적합한지 진단해 주세요. 반복 배경, 흩어진 자료, 근거 확인 필요성, 반복 산출물, 최신성 위험, 민감 정보 여부를 기준으로 평가해 주세요.
• 현재 문서 묶음이 RAG형 파일 업로드, 노트 앱, 일반 위키, LLM위키 중 어디에 가까운지 판단하고 다음 행동을 제안해 주세요.
• 아래 wiki 문서가 단순 요약인지, 컴파일 결과인지 점검해 주세요. 출처, 구조, 연결, 갱신 기준, 확인 필요 누락을 표로 표시해 주세요.

사람이 확인할 검증 질문

• 이 문서는 원천 자료를 보존하는가, 아니면 요약문이 원본을 대체하는가?
• wiki 문서의 핵심 주장이 어느 raw 또는 원문에서 왔는가?
• 컴파일 과정에서 빠진 중요한 사실이나 보류해야 할 민감 정보가 있는가?
• 이 작업은 미리 정리한 wiki 구조가 필요한 반복 업무인가, 아니면 한 번 답하고 끝낼 질문인가?
• 도구가 로컬 저장을 한다고 해도 URL 수집, 웹 검색, LLM 호출, 플러그인 권한이 조직 정책에 맞는가?
• 검토할 사람이 없는데 컴파일 결과를 확정 지식처럼 운영하고 있지 않은가?

관련 문서

• 1장. LLM위키가 필요한 이유: LLM위키가 필요한 문제 배경을 장 수준에서 정리한다.
• 1.1 LLM을 써도 지식이 남지 않는 이유: 반복 업무 맥락과 첫 위키 후보를 찾는다.
• 1.3 이 책에서 만들 결과물: 이 패턴이 어떤 최소 파일 구조와 산출물로 남는지 확인한다.
• 2.1 지식이 쌓이는 세 층: raw, wiki, rules의 신뢰 경계를 더 엄밀히 나눈다.
• 2.3 좋은 위키 문서의 조건: 출처, 재사용성, 링크 조건을 개별 wiki 문서 품질 기준으로 확장한다.
• 3.1 시작 방식 비교하기: 수동 Markdown, 에이전트, CLI, 데스크톱 방식 중 시작 방식을 고른다.
• 5.1 자료를 넣기 전에 정할 기준: LLM위키에 넣을 raw 자료 기준을 수집 카드로 구체화한다.
• 6.2 답변의 근거 확인하기: 컴파일된 wiki 기반 답변을 문장 단위로 검증한다.
• 8.2 정리와 감사 흐름 만들기: 출처, 최신성, 중복, 충돌을 주기적으로 감사하는 흐름을 만든다.