책을 24배 압축해 에이전트에 먹인다 — book-to-skill과 지식의 새 포장 단위

책을 통째로 읽히는 대신 에이전트가 참조할 형태로 재포장한다 — 이것은 검색(RAG)의 재탕인가, 아니면 지식 유통의 단위 자체가 바뀌는 신호인가.

도입

7월 30일 GitHub 트렌딩 일간 1위는 virgiliojr94/book-to-skill이었다 — 하루 1,421개의 스타. 이 도구가 하는 일은 한 문장으로 요약된다. 기술서·문서·지식 자료를 에이전트가 쓸 수 있는 “스킬(skill)“로 변환하되, 원본 PDF를 통째로 컨텍스트에 밀어 넣는 것 대비 토큰 소비를 24~51배 줄인다.

에이전트에게 방대한 참고 문헌을 붙여 쓰는 실무자에게 이 숫자는 즉각적인 의미를 갖는다. 300쪽짜리 기술서를 매 세션 컨텍스트에 넣는 것은 비용으로도, 성능으로도 지속 불가능하다 — 바로 전날 HANDBOOK.md가 보여준 롱컨텍스트 열화 문제와 정확히 맞닿는 지점이다. book-to-skill의 제안은 “다 넣지 말고, 필요한 것만 꺼내 쓰도록 미리 구조화하라”는 것이다.

토큰 비용을 구체화하면 매력이 분명해진다. 300쪽 기술서를 대략 15만 토큰으로 잡으면, 매 세션 전체를 넣는 것은 입력 비용만으로도 부담이고 그마저 후반부는 흐려진다. book-to-skill이 약속하는 2451배 압축은 이를 3천6천 토큰 규모의 상시 로드 가능한 크기로 낮춘다. 항상 켜 두는 4K 토큰의 핵심과, 질의에 따라 불러오는 1K 토큰짜리 장들 — 이 계층 구조가 “필요한 것만”이라는 원칙을 토큰 회계로 번역한 것이다.

그러나 이 도구가 트렌딩 1위에 오른 것은 단지 토큰 절약 때문이 아니다. 그 이면에는 두 개의 더 큰 질문이 있다. 하나는 기술적 질문 — 이것은 우리가 몇 년간 써 온 RAG(검색 증강 생성)와 무엇이 다른가. 다른 하나는 법적 질문 — 저작권이 있는 책을 에이전트용 스킬로 변환해 배포하는 것은 무엇을 침해하는가. 이 글은 그 두 질문을 따라간다.

무엇을 어떻게 압축하는가

book-to-skill의 파이프라인은 세 단계다. 이 구조를 이해하면 이 도구가 RAG와 어디서 갈라지는지가 보인다.

첫째, 추출. PDF·EPUB·DOCX부터 Markdown·HTML·MOBI까지 폭넓은 포맷을 받는다. “기술” 모드는 Docling으로 표와 코드를 보존하며 쪽당 약 1.5초, “텍스트 중심” 모드는 pdftotext/pypdf로 즉시 처리한다. 여기까지는 통상적인 문서 파싱이다.

둘째, 분석. 여기서 결정적 차이가 나온다. Claude가 문서의 구조를 분석해 장(chapter)을 감지하고, 원문을 요약하는 것이 아니라 프레임워크를 합성(synthesize)한다. 저장소의 표현을 빌리면, 스킬은 “구조화된 산문을 추론 도구로 바꾼 것”이며, 키워드로 검색 가능한 텍스트가 아니라 미리 추출된 프레임워크와 의사결정 규칙이다.

셋째, 출력. 결과물은 스킬 폴더다 — 핵심 멘탈 모델과 장 색인을 담은 약 4K 토큰의 SKILL.md, 필요 시에만 로드되는 장별 파일(각 약 1K 토큰), 그리고 glossary.md·patterns.md·cheatsheet.md 같은 참조 계층. 에이전트는 이 폴더를 통째로 읽지 않고, /book-slug topic-query 형태로 필요한 조각만 선택적으로 로드한다.

이 설계는 RAG와 표면적으로 비슷하지만 철학이 다르다. RAG는 원문을 청크로 쪼개 임베딩하고, 질의와 유사한 청크를 검색해 그대로 붙인다 — 지식의 원형을 보존하되 검색 시점에 관련 조각을 찾는 방식이다. book-to-skill은 그 반대다. 검색 시점이 아니라 변환 시점에, 사람(정확히는 Claude)이 책 전체를 읽고 프레임워크·결정 규칙·치트시트로 재구조화한다. RAG가 “찾아서 붙이기”라면 이것은 “미리 소화해서 개조식으로 요약하기”에 가깝다.

24~51배라는 압축비는 이 차이에서 나온다. RAG는 관련 청크를 원문 그대로 붙이므로 청크 크기만큼 토큰을 쓴다. book-to-skill은 원문을 버리고 합성된 구조만 남기므로 압축비가 극적이다. 대신 잃는 것이 있다 — 원문의 정확한 문구, 뉘앙스, 그리고 합성 과정에서 Claude가 누락하거나 왜곡한 부분을 사후에 검증할 방법이다.

두 방식이 배타적인 것은 아니라는 점도 짚어 둘 만하다. 실무에서는 계층을 나눌 수 있다 — 개념적 뼈대와 의사결정 규칙은 book-to-skill식 합성 스킬로 상시 로드하고, 정확한 인용이 필요한 순간에는 RAG로 원문 청크를 끌어오는 하이브리드다. 스킬이 “무엇을 어디서 찾을지”의 지도를 제공하고, RAG가 “그 지점의 원문”을 공급하는 역할 분담이다. 실제로 book-to-skill의 장별 파일 구조는 이런 2단 조회 — 먼저 색인, 다음에 세부 — 를 염두에 둔 설계로 읽힌다.

지식 포장의 새 단위, 그리고 그 대가

이 도구의 진짜 의미는 토큰 절약을 넘어선다. book-to-skill은 지식의 유통 단위가 “문서”에서 “에이전트가 소비하는 구조”로 이동하고 있음을 보여주는 신호다.

기술적 함의. 전날의 HANDBOOK.md 결과와 겹쳐 읽으면 이 도구의 논리가 선명해진다. HANDBOOK.md는 긴 문서를 통째로 준다고 에이전트가 따르지 않음을 보였다. book-to-skill은 정반대 방향에서 같은 문제를 공략한다 — 애초에 긴 문서를 통째로 주지 말고, 4K 토큰의 핵심과 온디맨드 장으로 쪼개 주자는 것이다. 문서의 실효 밀도를 높이는 두 가지 처방 중, HANDBOOK.md가 “핵심 규칙 재주입”을 시사했다면 book-to-skill은 “사전 구조화”를 구현한 셈이다. Agent Skills라는 열린 표준을 통해 Claude Code·Copilot CLI·Amp에 두루 꽂힌다는 점도, 이것이 특정 벤더의 기능이 아니라 포맷 경쟁의 한 후보임을 시사한다.

그러나 대가는 분명하다. 합성 압축은 손실 압축이다. 원문을 버리고 Claude의 요약만 남기면, 그 요약이 틀렸을 때 되돌아갈 원본이 컨텍스트에 없다. 기술서의 미묘한 단서 — “단, X인 경우는 예외” 같은 — 가 프레임워크 합성 과정에서 증발하면, 에이전트는 그 예외를 영영 모른다. 이는 “쿼리 시점에 원문 청크를 보는” RAG가 오히려 나은 지점이다. 압축비와 충실도(fidelity)는 트레이드오프이며, book-to-skill은 그 축의 압축 극단에 서 있다.

법적 함의. 여기가 진짜 지뢰밭이다. 저장소는 이 문제를 정직하게 다룬다 — 변환기 코드는 MIT 라이선스이고, 도구 자체는 책 내용을 담아 배포하지 않으며(처리는 로컬에서), 사용자가 만든 출력물은 사용자 소유로 학습 노트에 준한다는 입장이다. 그러나 같은 문서가 곧바로 경고한다 — 저작권이 있는 저작물의 생성된 스킬을 재배포하면 침해가 될 수 있다.

이 경계선은 생각보다 미묘하다. 개인이 산 책을 자기 학습용 스킬로 변환해 로컬에서 쓰는 것은 사적 이용에 가깝다. 그러나 그 스킬 폴더를 GitHub에 올리거나 팀에 공유하는 순간, “학습 노트”와 “2차적 저작물의 배포” 사이의 선을 넘는다. 합성 요약이 원문을 얼마나 대체하는가 — 즉 시장 대체성 — 가 공정 이용 판단의 핵심 변수인데, 24~51배 압축된 프레임워크가 원서 구매를 대체한다면 그 방어는 약해진다. 개조식 요약이라 해서 저작권을 벗어나는 것은 아니다. 표현이 아니라 구조와 선택·배열에도 창작성이 인정될 수 있기 때문이다.

이 구도는 낯설지 않다. LLM 학습 데이터 논쟁이 정확히 같은 축을 돌고 있다 — 저작물을 대량으로 소화해 만든 산출물이 원저작물의 시장을 대체하는가. book-to-skill은 그 논쟁을 개인 규모로 축소해 재현한다. 대형 랩의 학습이 수백만 권을 소화하는 것이라면, 이 도구는 한 명이 한 권을 소화하는 것이다. 규모는 다르지만 법리의 쟁점 — 시장 대체성과 변형적 이용 — 은 동일하다. 차이가 있다면, 대형 랩은 법무팀과 라이선스 협상력을 갖췄지만 GitHub에 스킬을 올리는 개인은 그렇지 않다는 점이다.

같은 주 GitHub 트렌딩에는 deepfakes/faceswap도 다시 올라와 있었다. 무관해 보이지만 공통점이 있다 — 둘 다 “기술적으로 가능한 것”과 “법적·윤리적으로 허용되는 것”의 간극에 서 있는 도구다. book-to-skill의 인기는 그 간극을 사용자 각자가 감당하라는 면책 위에 서 있다.

실무자에게, 그리고 지식 생산자에게

이 도구가 던지는 실무 질문을 정리한다.

소비자(엔지니어) 관점. book-to-skill은 사내 문서·오픈 라이선스 자료·자신이 산 참고서를 로컬 에이전트용으로 압축하는 데 즉시 유용하다. 다만 두 가지를 지켜야 한다. 첫째, 손실 압축임을 잊지 말 것 — 정확성이 중요한 규정·API 스펙은 합성 요약이 아니라 원문 참조나 도구 게이트로 다뤄야 한다(HANDBOOK.md의 교훈). 둘째, 배포 경계를 지킬 것 — 저작권 있는 책의 스킬은 로컬에 머물러야 하고, 공유 저장소에 올리는 순간 침해 위험이 현실화된다.

생산자(저자·출판사) 관점. 여기가 더 큰 변화다. 지식이 “읽히는 책”에서 “에이전트가 참조하는 스킬”로 소비 형태를 바꾸면, 저자의 수익 모델과 통제권이 흔들린다. 한 권을 사서 스킬로 변환하면 그 팀 전체가 원서 없이 핵심을 쓸 수 있다면, 판매 단위와 소비 단위의 괴리가 커진다. 역으로 기회도 있다 — 출판사가 공식 스킬 포맷을 직접 제공하는 것이다. 충실도를 통제한 공인 스킬을, 저자가 검수해 배포하는 모델. “에이전트가 읽을 판본”이 종이책·전자책에 이은 세 번째 판형이 될 수 있다.

전망 시나리오 — 낙관적으로는, Agent Skills가 표준으로 자리 잡고 출판사가 공인 스킬을 판매하는 정식 시장이 열려, 충실도와 저작권이 함께 해결된다. 비관적으로는, 저작권 책의 비공식 스킬이 GitHub에 범람하고 대규모 침해 분쟁이 터지면서 도구 자체가 규제 대상이 된다. 현실적 중간값은, 사내·오픈 자료 압축이라는 안전한 용도로 폭넓게 쓰이면서, 저작권 자료 변환은 회색지대에서 개인 이용으로 조용히 지속되는 — LLM 학습 데이터 논쟁이 걸어온 길을 축소판으로 반복하는 — 상태일 것이다.

결론

리드 질문에 답하자면, book-to-skill은 RAG의 재탕이 아니라 지식 포장 단위의 이동을 보여주는 신호다. 검색 시점이 아니라 변환 시점에 지식을 소화해 두는 이 접근은, 롱컨텍스트의 한계라는 실재하는 문제에 대한 합리적 대응이며 24~51배라는 숫자가 그 매력을 증명한다. 그러나 그 압축은 충실도를 대가로 지불하고, 그 재포장은 저작권이라는 미해결 지뢰 위에 서 있다.

한 권의 책을 4K 토큰으로 소화한다는 것은 놀라운 효율이자 위험한 단순화다. 이틀에 걸친 두 도구 — HANDBOOK.md와 book-to-skill — 는 사실 같은 동전의 양면이다. 하나는 긴 문서를 에이전트가 못 따른다는 것을 측정했고, 다른 하나는 그렇다면 문서를 짧게 재포장하자고 제안한다. 둘을 겹쳐 놓으면 2026년 여름 에이전트 실무의 핵심 질문이 드러난다 — 에이전트에게 무엇을, 얼마나, 어떤 형태로 줄 것인가. 컨텍스트는 무한하지 않고, 무한한 척해도 후반부는 흐려진다.

당신이 다음에 에이전트에 물릴 지식은 원문인가, 누군가의 합성 요약인가 — 그리고 그 요약이 놓친 “단, X인 경우는 예외”를 당신은 어떻게 알아챌 것인가. 지식을 압축하는 시대에, 압축되지 않은 원본에 대한 접근권이야말로 새로운 특권이 될지 모른다.


출처: