AI에게 답변뿐 아니라 ‘지식 위키’를 관리하게 하기 — Karpathy의 LLM Wiki

고객이 “결제가 두 번 됐는데 환불은 어떻게 받나요?”라고 물었다고 해보겠습니다. 답하려면 결제 안내와 환불 정책을 찾고, 비슷한 문의를 전에 어떻게 처리했는지도 확인해야 합니다. 지난번에도 찾아본 자료인데, 정책이 바뀌었을 수 있어 다시 읽게 됩니다.

오늘은 이런 자료를 AI가 정리하고 갱신하게 하는 Karpathy의 LLM Wiki를 살펴보겠습니다. 고객 문의 대응을 예로 들어 자료를 넣고, 질문하고, 바뀐 내용을 반영하는 과정을 설명하겠습니다. 기존 방식보다 어떤 점이 편해지는지, 시작하려면 무엇이 필요한지, 별도 서버까지 띄워야 하는지도 함께 다루겠습니다.

 

LLM Wiki란 무엇인가?

LLM Wiki는 AI가 마크다운 파일을 만들고 고치며 지식을 정리하는 방식입니다. Claude Code나 Codex처럼 파일을 편집할 수 있는 에이전트를 사용합니다. Karpathy가 공개한 것은 설치해서 쓰는 완제품이 아니라, 각자 필요한 형태로 만들어 볼 수 있는 설계안입니다.자료를 추가하면 AI가 내용을 읽고 관련 문서에 반영합니다. 다른 자료와 연결하고, 기존 내용과 맞지 않는 주장도 표시합니다. 질문하다 얻은 비교나 분석도 문서로 저장해 둘 수 있습니다.

질문할 때마다 처음부터 정리하지 않으려면

자료를 올리고 질문하는 방식에서는 답이 대화 안에 남는 경우가 많습니다. 며칠 뒤 비슷한 질문을 하면 같은 자료를 다시 찾아 설명하게 됩니다.

LLM Wiki에서는 정리한 내용을 파일로 남깁니다. 예를 들어 환불 정책을 정리해 두었다면, 새 정책이 들어왔을 때 그 문서를 고치고 관련 결제 안내에도 변경 사항을 반영합니다. 다음 질문은 이 문서들에서 출발합니다. 원문이 전형적인 RAG 방식과 비교해 설명하는 차이도 이 부분입니다.

파일은 어떻게 나누나

파일은 크게 세 가지로 나눕니다. 원본 자료는 그대로 보관하고, AI가 정리한 문서는 위키 폴더에 둡니다. 원본을 수정하지 말 것, 출처를 표시할 것 같은 규칙은 별도 파일에 적습니다. Claude Code에서는 CLAUDE.md, Codex에서는 AGENTS.md를 쓸 수 있습니다.문서가 늘어나면 index.md에 목록을, log.md에 작업 내역을 남깁니다. 무엇이 있는지 찾고, 최근에 어떤 내용이 바뀌었는지 확인하기 위한 파일입니다.

서버까지 띄워야 하나?

혼자 쓰면서 필요할 때 실행하는 정도라면, 별도 웹 서버는 없어도 됩니다. 작업 폴더를 하나 만들고, 그 안의 파일을 읽고 수정할 수 있는 AI 에이전트를 연결하면 됩니다. 문서는 텍스트 편집기로 읽어도 됩니다. Obsidian을 쓰면 문서 사이의 링크를 따라가기가 편하고요.

다만 파일을 내 컴퓨터에 보관한다고 해서 AI도 로컬에서 돌아가는 것은 아닙니다. 자료가 어디로 전송되는지와 이용 비용은 선택한 도구와 모델 설정을 확인해야 합니다.

폴더에 자료를 넣기만 하면 알아서 갱신되는 것도 아닙니다. 처음에는 “이 파일을 위키에 반영해 줘”라고 직접 요청하면 됩니다. 자료가 들어올 때마다 자동 실행하거나, 팀원들이 함께 검색하는 화면이 필요해지면 그때 자동화와 공유 방식을 붙이면 됩니다.

고객 문의 대응에 적용해 보면

고객 문의에 답하는 업무를 예로 들어 보겠습니다. 승인된 정책과 FAQ, 과거 문의 사례를 자주 찾아보는 상황을 가정했습니다.

1. 작업 폴더를 준비합니다. 예를 들어 customer-wiki 폴더 안에 raw 폴더와 wiki 폴더를 둡니다. raw에는 제품 안내문, 승인된 FAQ, 개인정보를 제거한 문의 사례 등 원본을 보관합니다. 처음에는 읽기 쉬운 텍스트나 마크다운 자료로 시작합니다. PDF나 녹음은 도구에 따라 추출·변환 과정이 필요할 수 있습니다.
2. 폴더를 AI 에이전트의 작업 대상으로 지정합니다. 해당 폴더에 대한 읽기·쓰기 권한이 있어야 실제 문서를 갱신할 수 있습니다. 채팅에 자료를 붙이고 답변만 받으면, 폴더의 위키 파일이 저절로 바뀌지는 않습니다.
3. 첫 설정을 요청합니다. “이 폴더를 고객 문의 대응 위키로 구성해 줘. raw는 수정하지 말고 wiki에 주제별 문서와 index.md, log.md를 만들어 줘. 운영 규칙 파일에 원본 보존, 출처 표시, 정책과 사례의 구분, 충돌 시 검토 필요 표시를 기록해 줘.” 파일명과 구조는 이 예시를 위한 제안입니다.
4. 자료 하나를 반영합니다. 새 환불 정책을 raw에 저장하고 “이 파일을 읽고 기존 환불·결제 문서에서 바뀔 부분을 먼저 보여 줘. 확인 후 반영하자”라고 요청합니다. 날짜와 적용 대상이 다른 정책을 하나로 합치지 않았는지 검토합니다.
5. 실제 업무 질문을 합니다. “위키를 기준으로 중복 결제 문의의 답변 초안을 만들어 줘. 근거 문서를 링크하고, 확인되지 않은 조건은 질문으로 남겨 줘.” AI가 만든 문장을 검토한 뒤 업무에 사용합니다.
6. 검토한 결과를 다시 남깁니다. “확정된 대응 기준만 기존 문서에 반영하고, 사례는 정책과 구분해 저장해 줘.” 다음 작업 때도 같은 폴더를 열고 “먼저 운영 규칙과 위키 목록을 읽어 줘”라고 요청합니다. 대화가 바뀌어도 파일로 남긴 내용을 다시 읽어 이어갈 수 있습니다.

매주 한 번은 “출처 없는 주장, 오래된 정책, 서로 충돌하는 문서, 끊어진 링크를 찾아 수정안을 보여 줘”라고 점검해 보세요. AI가 편집한 파일은 변경 내역을 확인하고, 백업이나 버전 기록도 남겨 두는 편이 좋겠습니다.

어떤 업무에서 쓸 만할까

같은 주제를 계속 찾아보는 업무라면 차이가 날 수 있습니다. 고객 문의 하나를 처리할 때마다 정책, FAQ, 과거 사례를 뒤지던 일을 생각해 보세요. 조건과 근거를 한 문서에 모아 두고 새 정책이 나올 때 고치면, 다음 문의에서는 그 정리부터 확인할 수 있습니다.

그렇다고 AI가 만든 위키를 그대로 믿어도 된다는 뜻은 아닙니다. 잘못 요약한 내용을 계속 재사용하면 오류도 쌓입니다. 자료를 반영하고 확인하는 데 드는 시간과 비용까지 계산해야 합니다. 한 번 읽고 끝낼 자료보다는, 자주 꺼내 보고 내용도 바뀌는 자료로 시험하는 편이 낫겠습니다.

비슷한 문의 몇 개를 기존 방식과 위키 방식으로 처리해 보면 감이 잡힙니다. 답변을 쓰고 검토하는 시간이 줄었는지, 오래된 정책을 인용하거나 필요한 조건을 빠뜨리지는 않았는지 비교해 보세요.

자료를 넣을 때 쓸 요청문

업무 주제가 달라도 요청 방식은 비슷합니다. 다음 문장을 필요한 부분만 바꿔 써도 됩니다.

이 자료를 내 지식 위키에 반영해 줘. 먼저 기존 문서를 읽고 수정할 곳을 제안해 줘. 원본은 보존하고, 관련 문서에 필요한 내용과 연결을 추가해 줘. 사실에는 출처를 붙이고, 네 해석은 따로 표시해 줘. 기존 내용과 충돌하는 주장은 근거를 나란히 적고 확인할 항목으로 남겨 줘. 마지막에 변경 목록을 보여 줘.

변경 내용을 볼 때는 원문에 없는 말이 추가되지는 않았는지, 적용 조건이 다른 사례를 섞지는 않았는지 확인하세요. 특히 정책이 바뀐 이유와 출처를 따라갈 수 있어야 합니다.

시작은 자료 몇 개로

처음부터 모든 자료를 넣을 필요는 없습니다. 자주 찾는 주제 하나를 고르고, 직접 읽어 본 자료 몇 개로 위키를 만들어 보세요. 다음 자료를 넣었을 때 기존 문서가 어떻게 바뀌는지 보면 이 방식이 필요한지 판단하기 쉽습니다.

AI가 정리를 맡아도 무엇을 남길지, 어느 내용을 믿을지는 사람이 결정해야 합니다. 그 판단에 쓸 근거를 찾고 문서를 고치는 수고가 줄어든다면, 계속 써 볼 이유가 있겠습니다.

참고 자료
Andrej Karpathy — LLM Wiki (GitHub Gist)

llm-wiki