LLM에게 위키를 맡긴다 — 카파시의 LLM Wiki
물어볼 때마다 원문을 다시 읽히지 말고, 읽은 걸 위키로 쌓아두게 하자는 제안입니다.
Summary
- 과제
- 지금 방식은 물어볼 때마다 원문을 다시 뒤진다. 어제 한 이해가 오늘 남지 않는다.
- 수단
- LLM이 읽은 내용을 위키 문서로 쌓게 하고, 다음 질문은 원문이 아니라 그 위키에 던진다.
DETAILED DESCRIPTION
안드레이 카파시가 짧은 글을 하나 올렸습니다. LLM Wiki라고 부르는 방식입니다.
읽고 나서 특허 실무에 그대로 옮겨볼 만하다 싶어 정리해둡니다.
지금 방식의 아쉬운 점
요즘 흔히 쓰는 방식은 이렇습니다. 문서 더미를 넣어두고, 질문이 오면 관련된 대목을 찾아서 그것만 LLM에게 읽히고 답하게 합니다. (RAG라고 부릅니다 — 찾아서 읽히고 답하게 한다는 뜻입니다.)
잘 돌아가는데, 한 가지가 아쉽습니다. 매번 처음부터 다시 읽습니다.
어제 같은 질문을 했어도 오늘 또 원문을 뒤집니다. 어제 어렵게 이해한 게 어디에도 남지 않습니다. 쌓이지 않으니 열 번을 물어도 첫 번째와 열 번째의 답이 같은 수준입니다.
제안 — 읽은 걸 적어두게 한다
카파시의 제안은 간단합니다. 중간에 위키를 하나 둡니다.
원문 더미 → 위키 → 질문에 대한 답
(안 바뀜) (LLM이 씀)
새 문서가 들어오면 LLM이 읽고, 관련된 위키 문서 열댓 개를 고쳐 씁니다. 질문이 오면 원문이 아니라 그 위키를 찾아 답합니다.
핵심은 이겁니다. 위키는 한 번 쓰고 마는 게 아니라 계속 고쳐지는 문서입니다. 문서를 넣을수록 위키가 좋아지고, 위키가 좋아지면 답도 좋아집니다.
세 가지 동작
글에서는 이 방식이 하는 일을 셋으로 나눕니다.
| 하는 일 | |
|---|---|
| 넣기 | 새 문서를 읽고, 관련된 위키 문서들을 고쳐 쓴다 |
| 묻기 | 위키에서 찾아 답하되, 어느 문서에서 나왔는지 밝힌다 |
| 점검 | 앞뒤가 안 맞는 곳, 낡은 곳, 빠진 곳을 찾아낸다 |
점검이 특히 눈에 띕니다. 자동으로 쌓이는 것에는 반드시 앞뒤가 안 맞는 대목이 생기는데, 그걸 찾는 일까지 안에 넣어둔 것입니다. 쌓기만 하고 청소를 안 하면 결국 못 믿을 더미가 된다는 걸 아는 설계입니다.
특허 실무로 옮겨보면
읽으면서 계속 우리 일이 떠올랐습니다.
- 거절이유 — 같은 심사관, 같은 기술분야에서 반복되는 논리가 있습니다. 대응할 때마다 원문을 다시 읽는 대신, "이 유형의 거절이유에는 이런 반박이 통했다"가 쌓이면 어떨까요
- 선행문헌 — 한 번 읽고 분석한 문헌을 다음 사건에서 또 처음부터 읽습니다
- 출원인별 관행 — 청구항 스타일, 용어 선호, 도면 규칙. 아는 사람 머릿속에만 있습니다
다만 그대로 옮기기 어려운 지점도 분명합니다. 사건 자료를 한곳에 모으는 것 자체가 문제입니다. 위키가 사건을 넘나들며 쌓이면, 그 위키는 이제 사건 정보 덩어리가 됩니다. 어느 출원인의 이야기가 다른 출원인 사건을 답하는 데 쓰이는 구조가 되고요.
사건에 매이지 않는 것 — 법리, 심사기준 해석, 서식 규칙 — 부터 해보는 게 맞겠다는 생각입니다.
실제로 해봤습니다
읽고 나서 거절이유 대응 작업에 붙여봤습니다. 2026년 6월 20일부터 쓰고 있으니 두 달쯤 됐습니다.
세 계층
글에서 말한 세 계층을 그대로 옮겼습니다.
| 우리 쪽 | 누가 쓰나 | |
|---|---|---|
| 원문 | raw/ — 명세서·거절이유·인용문헌 |
아무도 안 고침 |
| 위키 | _wiki/ — 개념 문서 모음 |
LLM이 씀 |
| 규칙 | 지침 문서 하나 | 사람과 LLM이 같이 고침 |
raw/를 아무도 못 고치게 한 것이 생각보다 중요했습니다.
원문을 손대기 시작하면 나중에 "이게 원래 그렇게 쓰여 있었나"를 확인할 데가 없어집니다.
위키에 쌓인 것
두 달 동안 문서가 100개 가까이 쌓였습니다. 이름을 앞머리로 분류해두었습니다.
| 종류 | 개수 | 무엇 |
|---|---|---|
argument_ |
41 | 어떤 논리로 반박했고 통했는지 |
citation_ |
37 | 이 문헌이 무엇을 개시하고 무엇을 안 하는지 |
topic_ |
18 | 여러 건에 걸친 쟁점 |
argument_와 topic_이 값어치가 제일 컸습니다.
전에는 이런 일이 자주 있었습니다. 비슷한 거절이유를 만난 적이 있고, 그때 어떻게 반박했는지도 어렴풋이 기억납니다. 그런데 그게 어느 사건이었는지가 안 떠오릅니다. 한참 찾다가 못 찾고, 결국 논리를 처음부터 다시 세웁니다. 한 번 세워봤던 논리인데도요.
위키에 남기고부터 그 문제가 없어졌습니다. 논리를 사건에서 떼어내 적어두니, 사건이 기억나지 않아도 논리를 찾을 수 있습니다.
떼어내는 게 핵심이었습니다. 전에는 논리가 사건 폴더 안에 있었으니 사건을 기억해야만 논리에 닿았습니다. 기억이 열쇠였던 셈인데, 사람 기억은 몇 달만 지나면 열쇠 노릇을 못 합니다.
들어오는 자리와 나가는 자리
index.md— 진입점. 질문이 오면 여기부터 읽습니다log.md— 무슨 일이 있었는지 한 줄씩 덧붙이기만 합니다. 고치지 않습니다
카파시가 말한 점검은 스크립트로 따로 만들었습니다. 납품 전에 결과물을 돌려서, 검토 때 반복해서 걸리던 것들을 기계적으로 확인합니다. 위키가 스스로를 점검하게 하는 것까지는 아직 못 갔고, 사람이 정한 규칙을 기계가 확인하는 수준입니다.
안 되는 것
사건을 넘나드는 지식만 위키에 올립니다. 논리와 문헌은 여러 건에 걸쳐 쓰이지만, 어느 출원인의 무엇이라는 정보는 올리지 않습니다. 위키가 사건 정보 덩어리가 되는 순간 그건 다른 물건이 되기 때문입니다.
그런데 이건 참는 게 아니라 오히려 쓸모 있는 쪽이었습니다. 앞에서 적은 대로, 논리가 사건에서 떨어져 나와야 사건을 몰라도 찾을 수 있습니다. 안전하게 만드는 조건과 쓸모 있게 만드는 조건이 같았습니다.
남는 생각
이 방식의 값어치는 기술이 아니라 태도에 있는 것 같습니다.
"필요할 때 찾아본다"에서 **"읽은 것은 적어둔다"**로 옮기는 것인데, 사실 사람이 공부하는 방식이 원래 그렇습니다. 매번 교과서를 다시 펴는 게 아니라 노트를 만들고 그 노트를 고쳐가면서요.
LLM에게 노트를 못 만들게 해두고 매번 교과서를 다시 읽히고 있었다는 걸 이 글을 보고 알았습니다.