이번 주에는 이미 만들어둔 LLM Wiki를 실제 업무에 어떻게 운영할지 실험했습니다.
지난주가 “LLM Wiki를 어떻게 설계할까”였다면, 이번 주의 핵심 질문은 “AI가 어떤 자료를 어느 정도 신뢰하고 답변 근거로 써도 되는가?”였습니다.
특히 IT 관련 법률·규제 검토 업무에서는 검증되지 않은 문서를 AI가 근거처럼 인용하는 것이 가장 큰 리스크라고 느꼈습니다.
그래서 이번 주에는 LLM Wiki를 단순 문서 저장소가 아니라, AI가 안전하게 답변하기 위한 “판단 레이어”로 운영하는 구조를 정리했습니다.
고민한 주제는 크게 네 가지였습니다.
- Slack thread, 내부 문서, 공개 가이드, 과거 검토 사례를 어떻게 ingest할 것인가
- 기존 사내 지식저장소와 LLM Wiki를 어떻게 조화시킬 것인가
- 과거 검토 corpus를 근거가 아니라 reference signal로 어떻게 활용할 것인가
- draft를 어떤 기준으로 공식 context에 승격할 것인가
진행 방법
사용한 도구는 AI 업무 어시스턴트, Markdown 기반 LLM Wiki, 기존 사내 지식저장소, 과거 검토 corpus였습니다.
Wiki 구조는 아래처럼 나누었습니다.
text
wiki/
├── raw/ # 원문 또는 snapshot
├── sources/ # 원문을 정제한 source note
├── drafts/ # AI/개인 초안
├── review-drafts/ # 승격 검토 후보
├── context/ # 승인된 canonical 판단
├── SCHEMA.md # 문서 type/frontmatter/lint 규칙
├── AGENT.md # agent 운영 룰
├── index.md # 페이지 카탈로그
└── log.md # 운영 로그
핵심은 raw → sources → drafts → context를 섞지 않는 것이었습니다.
특히 context는 AI가 답변 근거로 사용할 수 있는 승인된 판단 영역으로 두고, 사람 승인 전까지는 draft를 context로 승격하지 않도록 했습니다.
기존 사내 지식저장소는 원문 SoT로 유지했습니다.
LLM Wiki는 기존 지식저장소를 대체하지 않고, 내부 문서나 가이드를 실무 판단에 어떻게 적용할지 정리하는 “판단 레이어”로 두었습니다.
과거 검토 corpus도 연결했지만, 공식 근거로 쓰지는 않았습니다.
유사 사례 탐색, 반복 쟁점 확인, draft 후보 발굴을 위한 reference signal로만 사용하고, 최종 결론은 법령·가이드·사내 원문·승인된 context로 cross-check하도록 했습니다.
사용한 프롬프트 예시는 아래와 같습니다.
text
지금 위키 구조 평가해봐
이 프롬프트로 raw/source/context가 잘 분리되어 있는지, 승인되지 않은 문서가 context에 들어가 있지 않은지, 민감정보가 노출될 위험은 없는지 점검했습니다.
text
이 쓰레드 내용 ingest해줘
Slack thread를 저장할 때 사용했습니다. 단순 저장이 아니라 raw 저장, source 정제, draft 후보 생성, index/log 갱신, context 승격 전 확인 필요 사항 정리까지 진행했습니다.
text
그럼 린트는 어떤 과정으로 이루어지는거야
이 질문을 통해 lint를 markdown 문법 검사가 아니라 “AI가 이 문서를 답변 근거로 써도 되는지 확인하는 안전 게이트”로 정의했습니다.
text
위키를 팀으로 확장한다면 봇을 하나의 채널에 운영하는게 좋을지,
각자가 사내 Git에 pull/push를 하는게 좋을지 고민해줘
팀 확장 방식을 고민하면서 Slack-first, Git-backed, approval-gated 모델을 정리했습니다.
text
Slack: 팀원이 쉽게 요청하는 입구
Bot: ingest, triage, draft 생성
Git: 변경 이력과 승인 게이트
Lint: 안전 검사
Owner: context 승격 승인
활용 이미지로는 아래 3가지를 남기면 좋을 것 같습니다.
text
1. Wiki 폴더 구조 캡처
2. raw → sources → drafts → context 흐름도
3. Slack-first, Git-backed 운영 모델 다이어그램
결과와 배운 점
가장 큰 배움은 “LLM Wiki의 핵심은 ingest 자동화가 아니라, ingest 이후의 판단 권한 설계”라는 점이었습니다.
자료를 많이 넣는 것은 쉽지만, 어려운 것은 다음을 구분하는 일이었습니다.
- 어떤 자료는 참고만 해야 하는가
- 어떤 자료는 draft로 남길 수 있는가
- 어떤 자료는 AI가 인용하면 안 되는가
- 어떤 자료는 사람 승인 후에만 context가 되는가
특히 과거 검토 corpus는 유용하지만 위험했습니다.
비슷한 사례가 검색된다고 해서 현재 질문의 결론이 되는 것은 아니었습니다. 당시 서비스 구조, 계약 관계, 동의 문구, 법령 버전이 모두 다를 수 있기 때문입니다.
그래서 corpus는 “근거”가 아니라 “힌트”로만 쓰고, 최종 판단은 반드시 공식 가이드, 법령, 사내 원문, 승인된 context로 확인하는 원칙을 세웠습니다.
시행착오도 있었습니다.
첫째, 좋은 답변을 바로 context로 올리고 싶어지는 문제였습니다.
하지만 질문에 대한 답변은 그 순간의 맥락에 묶여 있고, context는 반복적으로 인용될 canonical judgment이므로 둘을 분리해야 했습니다.
둘째, 사내 문서를 Wiki에 복제하려는 유혹이 있었습니다.
그러나 그렇게 하면 두 개의 SoT가 생깁니다. 그래서 사내 문서는 원문으로 두고, Wiki에는 판단 포인트와 적용 기준만 얇게 남기는 방식으로 바꿨습니다.
셋째, 팀 확장 방식도 고민했습니다.
Slack만 쓰면 접근성은 좋지만 통제가 약하고, Git만 쓰면 안전하지만 기여 장벽이 높습니다. 그래서 Slack은 입력 창, Git은 승인과 이력 관리 도구로 나누는 방식이 현실적이라고 봤습니다.
나만의 꿀팁은 다음입니다.
1. Wiki를 문서 저장소가 아니라 판단 레이어로 보기
2. raw, source, draft, context를 반드시 분리하기
3. corpus는 근거가 아니라 reference signal로만 사용하기
4. lint를 문법 검사가 아니라 안전 게이트로 설계하기
5. 팀 확장은 Slack-first, Git-backed로 시작하기
앞으로는 ingest workflow를 더 자동화하고, 승격 후보를 주간 단위로 모아 리뷰하며, context 승격 전 lint script를 만드는 것이 목표입니다.
팀 확장은 처음부터 모두가 Git에 직접 기여하는 방식보다, 하나의 Slack 채널에서 AI Bot을 운영하고 승인된 내용만 Git-backed Wiki에 반영하는 방식으로 파일럿을 해보려 합니다.
도움 받은 글 (옵션)
이번 실험에서 참고한 큰 흐름은 Karpathy의 LLM Wiki 아이디어입니다.
핵심은 일반 RAG처럼 질문할 때마다 raw document chunk를 검색해 즉석에서 답하는 것이 아니라, LLM이 원문을 읽고 markdown wiki를 계속 갱신하면서 지식을 write-time에 compile한다는 점입니다.
이번 실험에서는 이 아이디어를 IT 관련 법률·규제 검토 업무에 맞게 더 보수적으로 변형했습니다.
text
Karpathy LLM Wiki
→ raw / wiki / schema
Regulated Workflow Wiki
→ raw / sources / drafts / context
→ approved-only citation
→ 기존 지식저장소는 SoT
→ corpus는 reference signal
→ lint는 safety gate
→ context 승격은 사람 승인
즉, 일반 LLM Wiki 패턴을 규제·검토 업무에 맞게 governance 모델로 바꿔 적용한 사례였습니다.
