LLM Wiki 구축기: 답변을 검증된 지식으로 옮기기

개요

AI를 오래 쓰다 보면 답변보다 먼저 관리해야 할 문제가 생긴다. 채팅 기록이다.

처음에는 이 기록도 자산처럼 보인다. 운영 장애를 분석한 대화, 코드 스타일을 정리한 대화, 투자 기준을 비교한 대화, 문서 초안을 고친 대화가 계속 남는다. 그런데 시간이 지나면 문제가 드러난다.

• 어떤 답변이 최신인지 알기 어렵다.
• 근거 원문과 모델의 해석이 섞인다.
• 좋은 답변이 나와도 다음 작업에서 다시 찾아 쓰기 어렵다.
• 같은 질문을 다시 하면 매번 비슷한 정리를 반복한다.

그래서 개인용 LLM Wiki를 만들기 시작했다. 목표는 거창한 사내 검색엔진이 아니었다. 내가 반복해서 쓰는 지식과 판단 기준을 Markdown 저장소에 남기고, LLM이 그 저장소를 읽고 갱신하며, 검증된 내용만 다시 꺼내 쓰게 만드는 것이었다.

이 글의 결론은 단순하다. 좋은 답변도 바로 wiki/에 넣지 않는다. 먼저 drafts/에 세워 두고, 근거와 최신성과 재사용 가능성을 확인한 뒤에만 trusted 문서로 승격한다. 내 LLM Wiki에서 가장 중요한 기능은 더 많이 저장하는 것이 아니라, 아직 믿으면 안 되는 문장을 멈춰 세우는 것이다.

이 아이디어는 두 자료에서 출발했다. 하나는 Andrej Karpathy가 2026년 4월 4일에 공개한 LLM Wiki GitHub Gist였다. 정확히는 GitHub Gist다. 다른 하나는 컬리 기술 블로그의 2026년 5월 21일 글 AI에게 도메인을 가르치다 두 번 갈아엎은 이야기였다.

이 글은 두 글을 요약하는 글이 아니다. 그 힌트를 바탕으로 내가 만든 llm-wiki 저장소를 어떤 기준으로 설계했는지 정리한 구축기다.

읽고 나면 세 가지 기준을 가져갈 수 있다.

• LLM 답변을 언제 draft로 남기고 언제 trusted 문서로 승격할지
• raw, drafts, wiki를 어떻게 나누면 지식 오염을 줄일 수 있는지
• 개인 Wiki 규모에서 검색 구조를 어디까지 작게 유지할 수 있는지

처음 만들 때 가장 먼저 배운 것은 속도가 아니었다. 좋은 답변을 빨리 쌓는 것보다, 아직 믿으면 안 되는 문장을 멈춰 세우는 일이 더 중요했다.

좋은 답변을 바로 wiki에 올리려다 멈춘 순간. 사진: daveoratox / Wikimedia Commons, CC BY 2.0

내가 풀고 싶었던 문제

처음 문제는 "문서를 어디에 저장할 것인가"가 아니었다. 이미 저장할 곳은 많았다. Notion, Obsidian, Google Docs, GitHub, Slack, Confluence, 로컬 Markdown까지 도구는 충분했다.

진짜 문제는 source of truth였다.

AI와 일할수록 좋은 답변은 많이 생겼다. 하지만 좋은 답변이 곧 신뢰 가능한 문서가 되지는 않았다. 어떤 답변은 코드와 로그를 확인한 결과였고, 어떤 답변은 그럴듯한 추론에 가까웠다. 어떤 것은 나중에 다시 봐도 맞았고, 어떤 것은 그때 상황에서만 유효했다.

결정적인 순간은 꽤 사소했다. 마음에 드는 답변을 그대로 wiki/에 옮기려다가 멈췄다. 문장은 매끄러웠지만, 그 안에는 로그로 확인한 사실, 내 해석, 모델의 추정이 한 문단에 붙어 있었다. 그대로 저장하면 다음 세션의 LLM은 그 문단을 검증된 지식처럼 읽을 수 있었다.

그때부터 목표가 바뀌었다. 좋은 답변을 보관하는 것이 아니라, 믿어도 되는 문장과 아직 보류해야 하는 문장을 분리하는 쪽으로 좁혔다.

그래서 LLM Wiki의 목표를 이렇게 좁혔다.

채팅에서 나온 답을 저장하는 것이 아니라, 근거가 있는 지식을 검증 가능한 단계로 이동시킨다.

이 기준을 잡고 나니 저장소가 단순한 메모장이 아니라 작은 콘텐츠 파이프라인처럼 보이기 시작했다.

참고한 힌트

Karpathy의 Gist에서 얻은 핵심은 "LLM이 raw document를 매번 다시 읽는 대신, 지속적으로 유지되는 Markdown Wiki를 만든다"는 발상이었다. 사용자는 source를 고르고 질문을 던진다. LLM은 요약, 연결, 파일 정리, 로그 관리 같은 반복 유지 작업을 맡는다.

컬리 글에서 얻은 핵심은 "검색 책임을 분리해야 한다"는 점이었다. 처음에는 Markdown 색인을 만들고, 다음에는 본문 임베딩을 시도하고, 마지막에는 요약 임베딩과 본문 FTS를 분리한다. 이 흐름을 보면서 LLM Wiki도 결국 검색 단위와 검증 단위를 함께 설계해야 한다는 점을 배웠다.

내 저장소에는 두 자료를 그대로 복사하지 않았다. 아래처럼 필요한 원칙만 가져왔다.

이 선택의 이유는 단순했다. 개인 지식 저장소에서 가장 위험한 실패는 검색이 조금 느린 것이 아니라, 아직 검증되지 않은 해석이 trusted 지식처럼 굳어지는 것이다.

핵심 설계: raw -> drafts -> wiki

처음에는 Karpathy 글처럼 raw와 wiki 두 계층만 있어도 충분해 보였다. 하지만 내가 다루려던 내용에는 운영 판단, 코드 스타일, 투자 기준, 팀 도메인 지식처럼 맥락 의존적인 주제가 섞여 있었다. 이런 내용은 한 번의 요약만으로 바로 신뢰 문서가 되기 어렵다.

그래서 중간에 drafts/를 넣었다.

llm-wiki/
├── raw/
│   ├── sources/
│   ├── assets/
│   └── sources.csv
├── drafts/
│   ├── source-notes/
│   ├── candidates/
│   ├── reports/
│   └── index.md
├── wiki/
│   ├── index.md
│   └── log.md
├── scripts/
└── AGENTS.md

각 계층의 역할은 명확하게 나눴다.

이 구조에서 중요한 규칙은 하나다.

좋은 답변이 나와도 바로 wiki/에 넣지 않는다.

채팅에서 쓸 만한 답이 나오면 먼저 drafts/candidates/에 남긴다. source가 어디인지, 최신성이 맞는지, 다른 문서와 충돌하지 않는지 확인한 뒤에만 wiki/로 승격한다.

운영 방식

LLM Wiki를 만들면서 가장 중요했던 파일은 AGENTS.md였다. 처음에는 이 파일을 "AI에게 주는 설명서" 정도로 생각했다. 만들고 보니 역할이 더 컸다.

AGENTS.md는 저장소의 운영 프로토콜이었다.

• 세션 시작 시 어떤 index를 먼저 읽을지 정한다.
• 새 source를 수집할 때 어떤 순서로 파일을 만들지 정한다.
• draft를 wiki로 승격할 조건을 정한다.
• 답변할 때 trusted 지식과 draft 기반 추론을 구분하게 한다.
• 세션 종료 시 어떤 검증 스크립트를 실행할지 정한다.

이 규칙이 없으면 LLM은 매번 현재 대화의 목표만 보고 움직인다. 그 순간에는 빠르게 보일 수 있지만, 시간이 지나면 지식 저장소의 일관성이 깨진다.

내가 원한 것은 빠른 답변이 아니라 반복 가능한 유지 관리였다. 그래서 AGENTS.md를 프롬프트 조각이 아니라 maintainer protocol로 다뤘다.

프로토콜만으로는 충분하지 않았다. 저장소가 계속 같은 방식으로 움직이려면 운영 루프도 필요했다.

ingest, query, lint 루프

저장소가 생겼다고 지식 시스템이 되는 것은 아니다. 계속 같은 방식으로 넣고, 찾고, 점검할 수 있어야 한다.

카드 카탈로그 서랍에 보관된 색인 카드. 사진: Maksym Kaharlytskyi / Unsplash

현재 운영 흐름은 네 단계다.

1. ingest: 원문을 raw/sources/에 저장하고 raw/sources.csv에 metadata와 hash를 기록한다. source별 1차 정리는 drafts/source-notes/에 둔다.
2. query: 질문이 들어오면 먼저 wiki/index.md를 읽는다. trusted 문서가 없으면 drafts/index.md와 관련 후보를 확인한다.
3. writeback: 좋은 답변이나 반복 가치가 있는 정리는 채팅에 버리지 않고 draft 후보로 저장한다.
4. lint: source 누락, index 누락, trusted frontmatter 누락, 오래된 후보를 점검한다.

검증 스크립트도 이 루프를 기준으로 만들었다.

이 검증은 완전한 품질 보증은 아니다. 그래도 LLM이 파일을 여러 개 수정하는 작업에서 최소한의 안전장치가 된다. 특히 raw/sources.csv와 wiki/index.md는 사람과 LLM이 모두 읽는 라우터이기 때문에 깨지면 다음 세션의 품질이 바로 떨어진다.

검색 책임은 어디까지 나눴나

컬리 글에서 가장 흥미로웠던 부분은 검색 구조를 두 번 갈아엎은 과정이었다. 처음에는 prefix bucket 기반 Inverted Index를 만들고, 다음에는 본문 임베딩으로 넘어가고, 마지막에는 요약 임베딩과 본문 FTS를 분리한다.

내 저장소에도 이 구조를 바로 넣을 수는 있었다. 예를 들어 search/indexes/hot 와 search/indexes/cold를 만들고, 초성별 prefix 파일을 둘 수 있다.

하지만 현재 규모에서는 그 구조가 오히려 부채라고 판단했다.

llm-wiki의 문서 수는 아직 wiki/index.md 한 파일로 라우팅할 수 있는 수준이다. 이 단계에서 색인 파일을 여러 개로 나누면 LLM이 먼저 읽어야 할 파일만 늘어난다. 그래서 검색 index를 물리 파일로 만들기보다, 문서 frontmatter에 미래 검색을 위한 필드만 남겼다.

푸른 배경 위의 돋보기. 사진: Markus Winkler / Unsplash

후보 문서에는 아래 필드를 둘 수 있게 했다.

summary: '한 문장 요약'
aliases: [동의어, 사내약어]
keywords: [핵심어, API, 이벤트명]
domain_area: knowledge-system
doc_type: workflow
evidence_status: single_source

이 구조의 의도는 분명하다.

• summary, aliases, keywords는 의미 검색 입력으로 쓴다.
• 본문 전체는 API path, Kafka topic, MQTT topic, class 이름 같은 정확 검색에 쓴다.
• 검색 index는 source of truth가 아니라 파생 산출물로 둔다.
• trusted 여부는 검색 결과가 아니라 문서 계층과 frontmatter로 판단한다.

즉, 검색을 미루는 것이 아니라 검색 책임을 먼저 정해둔 것이다.

실제 적용 사례

초기에는 좋은 후보 문서를 빨리 wiki/로 올리고 싶었다. 그래야 "Wiki가 쌓인다"는 느낌이 났기 때문이다.

그런데 곧 문제가 보였다. LLM이 만든 문장은 그럴듯했지만, 어떤 문장이 원문 근거인지, 어떤 문장이 내 해석인지, 어떤 문장이 운영 규칙인지 한눈에 갈라지지 않았다. 이 상태로 wiki/가 차면 나중에는 더 위험해진다. 검증되지 않은 말이 오래 살아남고, 다음 답변이 그 말을 다시 근거로 삼을 수 있기 때문이다.

그래서 기준을 바꿨다.

이 변경 이후 wiki/는 느리게 쌓이기 시작했다. 대신 한 번 들어간 문서는 다시 꺼내 쓸 수 있는 기준이 분명해졌다.

실제로 나눠 보니 달랐던 문서들

차이는 실제 문서를 다룰 때 분명해졌다.

공매도 설명은 SEC Investor.gov, SEC Regulation SHO, 금융위원회 자료를 raw source로 모은 뒤 source note와 candidate를 거쳐 wiki/securities-short-selling.md로 승격했다. 공매도의 기본 구조, 차입 공매도와 무차입 공매도의 구분, 제도 해석의 주의점은 source를 붙여 재사용할 수 있는 지식에 가까웠다. 그래서 trusted wiki로 올릴 수 있었다.

반대로 2026년 6월 18일에 만든 포트폴리오 리밸런싱 리포트는 다르게 처리했다. 그 문서는 Toss Invest read-only snapshot, 당시 가격, 현금, 매도 가능 수량, 주문 가능성 확인에 묶여 있었다. 계산 과정은 유용했지만 문서 자체는 특정 시점의 판단이었다. 그래서 drafts/reports/에 참고 리포트로 남겼고, trusted wiki로 승격하지 않았다.

이 둘의 차이가 신뢰 경계의 핵심이다. wiki/는 잘 쓴 답변을 모아두는 곳이 아니다. 비교적 안정적인 개념과 날짜 의존적인 판단을 갈라서, 다음 답변이 어디까지 믿어도 되는지 알려주는 표지판이다.

실제로 달라진 작업 방식

LLM Wiki를 만든 뒤 가장 크게 바뀐 점은 답변을 대하는 태도다.

예전에는 답변이 만족스러우면 그 자리에서 끝났다. 지금은 질문을 하나 더 한다.

이 답은 다시 쓸 가치가 있는가?

다시 쓸 가치가 없다면 채팅에서 끝낸다. 다시 쓸 가치가 있다면 source note나 candidate로 남긴다. 검증까지 끝났다면 wiki로 승격한다.

이 차이는 작아 보이지만 누적 효과가 컸다.

• 코드 스타일 기준이 여러 채팅에 흩어지지 않는다.
• 운영 장애 RCA 원칙이 한 번 정리되면 다음 분석에서 다시 쓴다.
• 투자 관련 설명은 source note, report, trusted wiki를 구분한다.
• 도메인 지식은 Slack 한 줄을 바로 사실로 만들지 않고 코드와 문서 근거를 확인한다.

특히 "trusted 지식"과 "draft 기반 추론"을 구분하는 습관이 생긴 점이 컸다. LLM이 그럴듯하게 말하는지보다, 어떤 계층의 근거를 보고 말하는지가 더 중요해졌다.

적용하면 좋은 경우와 아닌 경우

LLM Wiki는 모든 사람에게 필요한 구조는 아니다.

아래 상황이라면 굳이 만들 필요가 없다.

• 질문이 대부분 일회성이다.
• 원문 근거보다 빠른 요약이 더 중요하다.
• 문서가 적어서 검색 비용이 거의 없다.
• trusted와 draft를 구분할 필요가 없다.

반대로 아래 상황이라면 충분히 해볼 만하다.

• 같은 판단 기준을 반복해서 다시 쓴다.
• 운영 기록, 코드 근거, 문서 근거가 자주 충돌한다.
• LLM 답변을 팀/개인 지식으로 축적하고 싶다.
• "무엇을 믿어도 되는가"를 답변마다 구분해야 한다.

내 경우에는 두 번째에 가까웠다. AI를 많이 쓰는 것보다, AI가 만든 결과를 어디까지 믿을 수 있는지 구분하는 일이 더 중요했다.

다음 보강

아직 완성된 시스템은 아니다. 지금 구조는 Markdown 기반의 작은 지식 저장소에 가깝다.

다음 단계에서 보강하고 싶은 것은 네 가지다.

1. summary, aliases, keywords 품질을 자동 점검하는 테스트
2. draft 후보가 오래 방치되는지 확인하는 report
3. 정확 검색과 의미 검색을 함께 쓰는 로컬 검색 도구
4. trusted 문서 승격 전 사람이 확인할 review checklist

다만 지금 당장 가장 중요한 것은 검색 엔진을 붙이는 일이 아니다. source와 해석, trusted 문서를 섞지 않는 현재 경계를 유지하는 것이다.

결론

LLM Wiki를 만들면서 배운 것은 "AI에게 도메인을 가르치는 법"이라기보다 "AI가 다룰 수 있도록 내 지식을 다시 정리하는 법"에 가까웠다.

만들기 전에는 LLM이 더 좋은 답변을 해주면 문제가 풀린다고 생각했다. 만들고 나서는 반대로 보게 됐다. 좋은 답변은 출발점일 뿐이고, 그 답변을 어떤 신뢰 단계에 둘지 결정하는 일이 시스템의 핵심이었다.

Karpathy의 Gist는 지속적으로 유지되는 Markdown Wiki라는 큰 방향을 줬고, 컬리 글은 검색 책임을 어디에 둘지 구체적인 힌트를 줬다. 내가 실제로 만든 구조는 그 사이에 drafts/라는 신뢰 완충 지대를 넣은 형태다.

그래서 지금의 결론은 조금 더 좁다.

LLM 시대의 개인 Wiki는 많이 저장하는 도구가 아니라, 무엇을 아직 믿으면 안 되는지 표시하는 시스템이어야 한다.

이 문장이 이번 구축기의 핵심이다. 잘못된 지식 시스템은 틀린 말을 많이 만들어서 망하는 것이 아니라, 아직 검증되지 않은 말을 검증된 말처럼 재사용하면서 망한다. 내 LLM Wiki는 그 재사용 지점을 늦추고, 표시하고, 필요할 때만 승격시키기 위한 첫 번째 버전이다.