LLM Wiki를 만들 때 문서를 많이 넣는 것보다 중요한 것들

LLM Wiki는 사내 문서를 LLM이 읽고 답하게 만드는 시스템입니다. 이름은 거창하지만 목표는 단순합니다.

사람이 매번 찾던 지식을 AI가 빨리 찾아주고, 틀리면 고치기 쉽게 만드는 것.

여기서 중요한 건 문서를 많이 넣는 게 아닙니다. 많이 넣기만 하면 검색 범위가 커지고, 오래된 문서와 최신 문서가 섞이고, LLM은 그럴듯하게 틀릴 확률이 높아집니다.

좋은 LLM Wiki는 “문서 창고”가 아니라 “관리되는 지식 제품”에 가깝습니다.

실패하는 LLM Wiki의 공통점

많은 팀이 처음에 이렇게 시작합니다.

1. Notion, Google Drive, Slack, Confluence를 전부 연결한다.
2. 임베딩을 만든다.
3. 챗봇을 붙인다.
4. “이제 우리 회사 지식 다 물어보세요”라고 공지한다.

처음 며칠은 신기합니다. 그런데 곧 문제가 생깁니다.

• 오래된 문서를 최신 정보처럼 답한다.
• 초안 문서와 확정 문서를 구분하지 못한다.
• 같은 주제의 문서가 여러 개라 답변이 흔들린다.
• 출처는 보여주는데, 어느 출처가 정답인지 모른다.
• 결국 사람들은 다시 담당자에게 물어본다.

이건 LLM 문제가 아닙니다. 지식 관리 문제입니다.

LLM Wiki에 꼭 필요한 5가지 메타데이터

문서 본문보다 먼저 정리해야 할 것이 있습니다. 메타데이터입니다.

1. 상태

문서가 초안인지, 확정인지, 폐기됐는지 알아야 합니다.

status: draft | approved | deprecated

LLM은 기본적으로 모든 텍스트를 비슷하게 취급합니다. “초안입니다”라고 적힌 문서도 검색 결과에 들어오면 답변에 섞일 수 있습니다. 그래서 검색 단계에서 초안과 폐기 문서를 걸러야 합니다.

2. 소유자

누가 책임지는 문서인지 있어야 합니다.

owner: product-team

AI 답변이 틀렸을 때 누구에게 수정 요청을 보낼지 알아야 합니다. 소유자가 없는 문서는 시간이 지나면 쓰레기가 됩니다.

3. 유효기간

정책, 가격, 운영 절차는 시간이 지나면 바뀝니다.

valid_from: 2026-05-01
valid_until: 2026-06-30

특히 세일즈 자료, 가격표, 법무 문서, 고객지원 정책은 날짜가 중요합니다. LLM Wiki는 최신 문서를 우선해야 하고, 유효기간이 지난 문서는 답변 근거에서 제외해야 합니다.

4. 대상 독자

같은 주제라도 고객용 문서와 내부 운영 문서는 다릅니다.

audience: customer | internal | developer | executive

고객에게 말하면 안 되는 내부 정책이 답변에 섞이면 위험합니다. 문서 접근 권한과 대상 독자를 분리해서 관리해야 합니다.

5. 신뢰도

모든 문서가 같은 무게를 가지면 안 됩니다.

confidence: official | team-note | meeting-memo | personal-note

회의 메모는 참고자료입니다. 공식 정책 문서는 기준입니다. LLM Wiki는 공식 문서를 더 강하게 참고해야 합니다.

문서 구조는 짧고 반복 가능해야 한다

LLM이 잘 읽는 문서는 사람이 보기에도 명확합니다.

좋은 문서 구조는 이렇습니다.

# 제목

## 한 줄 요약
이 문서가 답하는 질문을 한 문장으로 씁니다.

## 적용 범위
어떤 상황에 적용되는지 씁니다.

## 규칙
- 조건 A이면 B
- 조건 C이면 D

## 예외
- 예외 1
- 예외 2

## 예시 질문
- 사용자가 이렇게 물으면 이렇게 답한다

## 변경 이력
- 2026-05-03: 환불 기간 변경

이 구조가 좋은 이유는 간단합니다. LLM이 답변에 필요한 부분을 찾기 쉽고, 사람이 수정하기도 쉽습니다.

답변보다 “정정 루프”가 중요하다

LLM Wiki를 운영하면 틀린 답변은 반드시 나옵니다. 중요한 건 틀리지 않는 시스템을 꿈꾸는 게 아니라, 틀렸을 때 빨리 고치는 구조입니다.

필수 기능은 세 가지입니다.

1. 답변마다 출처 문서를 남긴다.
2. 사용자가 “이 답변 틀림”을 누를 수 있게 한다.
3. 틀린 답변이 어떤 문서 때문에 나왔는지 운영자가 볼 수 있게 한다.

이게 없으면 LLM Wiki는 시간이 지날수록 신뢰를 잃습니다. 반대로 정정 루프가 있으면 답변 품질이 계속 좋아집니다.

검색 품질을 올리는 실전 팁

문서 제목을 질문처럼 쓰세요

나쁜 제목:

환불 정책

좋은 제목:

배송 시작 후 주문 취소가 가능한가?

사용자는 질문으로 검색합니다. 문서 제목도 질문에 가까울수록 잘 잡힙니다.

한 문서에 여러 주제를 넣지 마세요

“주문/결제/배송/환불 정책 총정리” 같은 문서는 사람이 보기에는 편해도 RAG에는 불리합니다. 질문 하나에 답하는 작은 문서가 더 좋습니다.

오래된 문서는 삭제보다 폐기 처리하세요

삭제하면 과거 답변을 추적하기 어렵습니다. deprecated 상태로 바꾸고, 대체 문서 링크를 걸어두는 편이 낫습니다.

답변 금지 영역을 정하세요

LLM Wiki가 모르는 내용을 아는 척하면 안 됩니다.

답변 금지:
- 법적 판단
- 투자 수익 보장
- 의료 진단
- 공개 전 가격 정책

모르는 것은 “문서에서 확인되지 않는다”고 말하게 해야 합니다.

LLM Wiki와 일반 위키의 차이

일반 위키는 사람이 탐색합니다. LLM Wiki는 모델이 검색해서 조합합니다. 그래서 일반 위키보다 더 엄격해야 합니다.

• 문서 상태가 필요합니다.
• 권한 정보가 필요합니다.
• 문서 소유자가 필요합니다.
• 변경 이력이 필요합니다.
• 질문 예시가 필요합니다.
• 답변 금지 규칙이 필요합니다.

그냥 기존 문서함에 챗봇을 붙이면 LLM Wiki가 아닙니다. 그건 “문서 검색 챗봇”입니다.

지금 할 일

LLM Wiki를 만들고 싶다면 첫날에 모든 문서를 넣지 마세요.

먼저 팀에서 가장 많이 반복되는 질문 30개를 고르세요. 그 질문에 답하는 공식 문서만 정리하세요. 각 문서에 상태, 소유자, 유효기간, 대상 독자, 신뢰도를 붙이세요. 그리고 답변 로그를 보면서 문서를 고치세요.

LLM Wiki의 품질은 모델 크기보다 문서 운영 방식에서 갈립니다. 문서를 관리할 자신이 없다면 더 큰 모델을 써도 같은 문제가 반복됩니다.