책을 미리 증류할까, 그때그때 찾을까 — 벡터 DB를 직접 굴려 본 사람이 본 '스킬 컴파일'의 자리

▶ 동영상 개요 — '스킬 컴파일'의 자리

5분 17초 — 압축 시점·실패의 가시성·상주 비용 세 축을 훑는다 — NotebookLM 동영상 개요로 생성

나는 개인 문서를 약 17,000개의 청크(검색하기 좋게 잘게 나눈 문서 조각)로 인덱싱한 검색 증강 생성 파이프라인을 직접 지어서 운영하고 있다. 질문이 들어오면 관련 조각을 찾아 프롬프트에 끼워 넣고 모델이 답하는 구조다. 그래서 기술서 한 권을 통째로 스킬로 컴파일해 준다는 오픈소스를 처음 봤을 때 반응이 곱지 않았다. 결국 요약본 아닌가. 검색이 있는데 왜 미리 압축하지?

그 반응이 틀렸다는 걸 깨닫는 데는 두 도구의 구조를 나란히 그려 보는 것으로 충분했다. 둘은 같은 문제를 푸는 경쟁자가 아니라, 압축을 언제 하느냐가 다른 두 전략이었다. 그리고 이 시점 차이가 비용 구조와 실패 방식까지 전부 갈라놓는다.

찾는 쪽 — 압축이 질문 시점에 일어난다

▲ 검색 증강 방식 — 질문이 올 때 고른다

다이어그램 설명. "질문이 들어온다"에서 출발해 매번 새로 재료를 고르는 흐름이다. 원문은 잘게 쪼개진 채 그대로 보관돼 있고, 어떤 조각을 쓸지는 질문을 본 다음에 정해진다. 이 구조의 강점은 원문이 손실 없이 남아 있다는 것이다. 오늘 못 찾은 문단도 내일 다른 질문에는 걸릴 수 있다. 대신 대가가 분명하다 — 매 질문마다 임베딩 계산과 검색이 다시 돌고, 고르는 과정 자체가 매번 실패할 기회가 된다.

미리 증류하는 쪽 — 압축이 제작 시점에 끝난다

▲ 스킬 컴파일 방식 — 만들 때 미리 고른다

다이어그램 설명. "책 한 권"이 딱 한 번 통독되고, 그 결과가 지침 파일로 굳어진 뒤로는 원문을 다시 열지 않는 흐름이다. 앞의 검색 방식과 결정적으로 다른 지점은 산출물의 형태다. 검색 방식은 원문 조각을 그대로 꺼내 오지만, 이쪽은 "저자가 말하는 핵심 프레임워크 여섯 개"처럼 원문에 그 형태로는 존재하지 않는 구조를 만들어 낸다. 통독 한 번에 책 전체를 보고 판단할 수 있으니 가능한 일이다. 검색은 질문에 걸린 조각만 보기 때문에 이런 요약을 만들지 못한다. 함정은 정확히 그 대칭점에 있다 — 증류 과정에서 버려진 뉘앙스는 영원히 사라진다. 원문은 남아 있어도 이 스킬은 다시 안 본다.

세 축으로 놓고 보면

축	검색해서 찾기	미리 증류해 두기
압축 시점	질문마다 (runtime)	제작 때 한 번 (compile time)
원문 보존	손실 없이 보관	증류 후 원문은 참조하지 않음
비용이 붙는 곳	질문 횟수에 비례	책 권수에 비례 (권당 약 1달러 선불)
맥락 점유	고른 조각만큼만	그 책을 쓰는 동안 지침 약 4천 토큰 상주
대표적 실패	관련 문단을 못 찾음	그럴듯하지만 틀린 요약이 굳어짐
실패의 가시성	높음 — 결과가 비거나 엉뚱함	낮음 — 매끄러운 답이 나옴

표에서 내가 가장 오래 들여다본 줄은 마지막 두 개다. 검색이 실패하면 티가 난다. 엉뚱한 문단이 딸려 오거나 아예 빈손으로 돌아오니 사람이 바로 알아챈다. 반면 증류가 실패하면 매끄럽고 자신 있는 답이 나온다. 책의 3장이 통째로 잘못 쪼개져 있어도, 그 위에서 만들어진 요약은 문법적으로 완벽하고 어조도 확신에 차 있다. 앞선 글에서 다뤘던 챕터 감지 사고 — 실제 10개인 챕터가 355개로 잡히거나 2개로 뭉개지는 — 가 무서운 이유가 여기 있다. 파이프라인은 오류를 내지 않고 조용히 끝까지 돌아간다.

숨은 비용은 상주분에 있다

비용 이야기를 한 번 더 짚고 싶다. 흔히 인용되는 건 "책 통째로 붙이는 것보다 수십 배 절약"이라는 수치인데, 이건 비교 대상을 잘못 고른 계산이다. 400쪽 책을 매 대화에 붙여 넣는 사람은 애초에 없다. 진짜로 따져야 할 비교 대상은 검색 방식이고, 그 축에서 보면 그림이 달라진다.

검색 방식의 맥락 점유는 고른 조각만큼이다. 인덱스에 문서가 만 개든 십만 개든 프롬프트에 들어가는 양은 변하지 않는다. 반면 스킬 방식은 그 책을 참조하는 동안 지침 약 4천 토큰이 맥락에 얹힌다. 정확히는 호스트에 따라 지침 본문이 발동 시점에 로드되기도 하지만, 발동되는 순간 그 분량이 통째로 들어오고 이후 대화 내내 유지된다는 점은 같다. 책 한 권이면 무시할 만하고, 열 권이면 무시할 수 없다.

그래서 이 방식은 규모를 키우는 방향으로 확장되지 않는다. 실제로 저장소 관리자도 여러 문서를 가로지르는 지식 그래프를 만들자는 제안을 "이 도구는 단일 소스를 증류하는 물건"이라며 명시적으로 거절했다. 다른 개발자가 여러 책에 한 번에 질문하는 별도 도구를 따로 만든 것도 같은 이유다 — 스킬을 여러 개 쌓는 문제는 원래 도구의 설계 범위 밖이다.

그래서 나는 이렇게 나눴다

두 방식을 놓고 고민하다가, 판단 기준을 "무엇을 넣느냐"가 아니라 "그 문서를 어떻게 대하느냐"로 잡으니 선이 깔끔하게 그어졌다.

• 권위 있는 텍스트를 체화하고 싶을 때 → 증류해서 스킬로. 설계 원칙을 정리한 기술서처럼, 내가 그 저자의 사고 틀을 빌려 쓰고 싶은 경우다. 이때 필요한 건 "몇 쪽에 뭐라고 쓰여 있더라"가 아니라 판단 기준 자체다.
• 내가 쌓아 온 기록을 뒤질 때 → 검색으로. 작업 노트나 일지처럼 계속 늘어나고 원문 그대로가 중요한 경우다. 여기서 증류는 손해다 — 나중에 어떤 질문이 올지 모르는데 미리 버릴 이유가 없다.
• 둘 다 아닐 때 → 아무것도 하지 않는다. 한 번 보고 말 문서를 파이프라인에 태우는 건 그 자체가 비용이다.

결국 나에게 남은 결론은 하나다. 압축을 미리 할지 나중에 할지는 문서의 성격이 정하는 게 아니라, 내가 그 문서에게 무엇을 기대하는지가 정한다. 판단 기준을 빌리고 싶으면 미리 증류하고, 사실을 되찾고 싶으면 그대로 두고 찾는다. 이 문장 하나를 얻으려고 두 구조를 그려 본 셈이지만, 덕분에 다음에 새 문서 더미를 받았을 때 어느 쪽으로 보낼지 망설이지 않게 됐다.

---

참고한 공개 자료:

• book-to-skill 저장소 및 사용 가이드 — github.com/virgiliojr94/book-to-skill, booktoskill.is-a.dev/guide
• 이슈 #45 — 여러 문서를 가로지르는 지식 그래프 제안과 거절 사유 — issues/45
• 여러 책에 한 번에 질문하는 별도 도구 the-knowledge-guy — github.com/vitalysim/the-knowledge-guy

---

이 글은 생성형 AI의 도움을 받아 작성되었습니다. 원본 자료를 기반으로 AI가 초안을 생성하고, 작성자가 검토·편집하였습니다.