책 TXT 색인을 검색 앱으로 만들면 LLM Wiki의 최소 단위가 보인다

책 TXT 색인은 단순한 검색 자료가 아니다.

잘 만들면 책 한 권을 LLM Wiki의 최소 지식 객체로 바꾸는 출발점이 된다.

Book Index Workbench 데모 직접 열기

책을 파일이 아니라 객체로 보기

처음에는 이 작업을 이렇게 생각했다.

EPUB과 PDF를 TXT로 추출한다. 청크로 나눈다. SQLite FTS 색인을 만든다. 필요할 때 검색한다.

그런데 검색 앱으로 만들기 시작하면 관점이 바뀐다.

책 한 권은 단순한 .txt 파일이 아니다. 책에는 신원이 있다. 저자, 출판사, 출간일, ISBN, 표지, 서점 링크가 있다. 그리고 내가 가진 로컬 TXT, 청크, 인용 후보, 블로그 글감 메모가 붙는다.

그러면 책은 이런 구조가 된다.

type: book
title: "Designing Data-Intensive Applications"
authors:
  - "Martin Kleppmann"
isbn13: ""
provider: "google-books"
source_url: "..."
local_index:
  book_id: "designing-data-intensive-applications-82bedab2"
  chunks: 1219
  quote_candidates: 19
citation_policy: short_quote_only
agent_usable: false
topics:
  - distributed systems
  - replication
  - consistency

이 정도가 되면 책은 LLM에게 던지는 참고 문서가 아니라, 메타데이터와 사용 규칙을 가진 지식 객체가 된다.

LLM Wiki의 핵심은 벡터 DB가 아니라 지식 아키텍처다에서 말한 것도 결국 이 방향이다. 검색 엔진보다 먼저 필요한 것은 “이 지식이 무엇이고, 어디서 왔고, 어떻게 써도 되는가”를 설명하는 구조다.

공개 앱에는 원문을 넣지 않았다

이번 데모는 실제 내 로컬 책 색인의 규모를 보여준다.

현재 로컬 색인은 13권, 8,134개 청크, 1,437개 인용 후보로 구성되어 있다. 하지만 공개 앱에는 책 본문 청크를 넣지 않았다.

이유는 명확하다. 책 전문이나 긴 발췌를 GitHub Pages에 올리는 순간, 검색 앱은 개인 도구가 아니라 공개 복제물이 된다. 그건 글쓰기 도구의 목적과 맞지 않는다.

그래서 앱을 두 층으로 나눴다.

공개 데모:
  책 목록, 저자, 파일 형식, 청크 수, 인용 후보 수, 주제 신호

로컬 모드:
  사용자가 가진 books.json, chunks.jsonl, quote_candidates.jsonl을 브라우저에서 직접 로딩

로컬 모드에서는 파일이 서버로 올라가지 않는다. 브라우저 안에서만 읽고 검색한다. 공개 글에서는 구조를 보여주고, 실제 본문 검색은 개인 장치 안에 남긴다.

이 구분이 중요하다. AI 시대의 PKM은 “모든 것을 공개 데이터로 올리는 것”이 아니다. 개인 지식은 로컬에 두고, 공개 가능한 구조와 해석만 블로그로 내보내는 방식이 더 안전하다.

서점 API는 본문이 아니라 신원을 가져온다

앱 오른쪽에는 “진짜 책 찾기” 영역이 있다. 현재 데모는 Google Books Volume Search를 먼저 호출하고, 실패하면 Open Library Search API로 넘어간다.

운영형으로 키운다면 한국어 책은 알라딘, 카카오, 네이버 도서 API를 붙이는 쪽이 맞다.

• Google Books API
• Open Library Search API
• Kakao 책 검색 API
• Naver 책 검색 API
• Aladin OpenAPI 안내

다만 여기서도 원칙은 같다.

서점 API는 책의 본문을 가져오는 장치가 아니다. 책의 신원을 확인하는 장치다.

제목이 같은 책은 여러 판본이 있을 수 있다. 번역본과 원서가 다를 수 있다. 저자명이 다르게 표기될 수 있다. PDF 파일명은 엉망일 수 있다.

그래서 서점 메타데이터가 필요하다. 로컬에 있는 TXT가 어떤 책인지, 어떤 판본인지, 어떤 ISBN과 연결되는지 확인해야 한다.

이 작업이 끝나면 로컬 TXT 색인은 단순 파일 묶음이 아니라, 외부 세계에서 확인 가능한 책 목록이 된다.

검색 앱은 RAG 이전 단계다

많은 사람이 책을 LLM에 연결한다고 하면 바로 RAG를 떠올린다.

하지만 이 앱은 RAG를 먼저 하지 않는다. 먼저 사람이 검색한다. 스니펫을 본다. 인용 후보를 고른다. YAML 초안을 만든다.

이 순서가 중요하다.

책 메타데이터 확인
→ 로컬 TXT 연결
→ 청크 색인
→ 사람이 검색
→ 인용 후보 저장
→ LLM Wiki 카드 생성
→ 필요할 때 에이전트/RAG에 제공

LLM에게 곧장 책 전체를 던지는 것보다, 먼저 검색 가능한 지식 객체를 만드는 편이 낫다. 그래야 출처, 판본, 인용 정책, 주제 태그, 사용 가능 여부를 함께 관리할 수 있다.

이 점에서 Book Index Workbench는 RAG 앱이 아니다. RAG 이전에 있어야 할 지식 정리 앱이다.

에이전트가 쓸 수 있는 책

에이전트가 책을 쓰려면 책의 본문만 있으면 부족하다.

에이전트는 이런 질문에 답할 수 있어야 한다.

이 책은 어떤 책인가? 어떤 판본인가? 이 문장은 어디서 왔는가? 긴 인용을 해도 되는가? 이 내용은 블로그 글감으로만 쓸 것인가, 코드 생성 컨텍스트로도 쓸 것인가?

그래서 YAML 초안에 citation_policy, agent_usable, local_index 같은 필드를 넣었다.

이것은 작은 정책 레이어다.

Tool Calling은 함수 호출이 아니라 인터페이스 설계다에서 도구 호출을 행동의 인터페이스로 봤다면, Book Index Workbench는 책을 지식의 인터페이스로 만든다. 책이 그대로 LLM 안으로 들어가는 것이 아니라, 사람이 검토 가능한 표면을 거쳐 에이전트에게 제공된다.

글감 생성 버튼이 의미하는 것

앱에는 “글감 생성” 버튼이 있다. 아직은 단순하다. 현재 검색어, 선택된 책, 상위 검색 결과를 묶어 블로그 글의 초안을 만든다.

하지만 이 작은 버튼이 다음 단계를 보여준다.

검색 결과는 결과 목록으로 끝나지 않아도 된다. 검색 결과는 글감이 될 수 있다. 글감은 블로그 글이 될 수 있다. 블로그 글은 다시 LLM Wiki의 노드가 될 수 있다.

이 흐름은 단어 암기 카드를 인터랙티브 HTML로 만들면 무엇이 달라질까에서 다룬 패턴과 같다. 거기서는 단어 데이터가 학습 카드 앱이 되었다. 여기서는 책 색인이 검색 워크벤치가 된다.

둘 다 핵심은 같다.

데이터를 그냥 쌓아두지 않는다. 사람이 판단할 수 있는 인터페이스로 바꾼다.

다음 버전

MVP는 정적 앱으로 충분하다. 하지만 운영형으로 키운다면 다음이 필요하다.

1. 알라딘/카카오/네이버 API 프록시
2. ISBN 기준 판본 매칭
3. 로컬 SQLite FTS와 브라우저 검색 인덱스 동기화
4. 인용 후보를 Obsidian 노트로 내보내기
5. 블로그 초안 frontmatter 자동 생성
6. 에이전트가 사용할 수 있는 read-only MCP 도구

특히 API 프록시는 중요하다. 카카오, 네이버, 알라딘 키를 정적 HTML에 직접 넣으면 안 된다. GitHub Pages에 공개되는 순간 키도 같이 공개된다. 운영형 앱은 작은 서버나 서버리스 함수에서 API 키를 보관하고, 브라우저는 그 프록시만 호출해야 한다.

결론

책 TXT 색인은 검색 도구로 시작하지만, 거기서 끝나지 않는다.

서점 메타데이터가 붙으면 책의 신원이 생긴다. 청크가 생기면 검색 가능해진다. 인용 후보가 생기면 글감이 된다. YAML 카드가 생기면 LLM Wiki에 들어갈 수 있다.

책 한 권은 이제 파일이 아니다.

책 한 권은 신원, 본문 색인, 인용 정책, 해석 가능성을 가진 작은 지식 시스템이다.

Book Index Workbench는 그 최소 단위를 보여주는 첫 번째 앱이다.