논문 1,000편을 몇 분 만에 훑는다는 말, 직접 재봤습니다
논문 관리 도구에 AI 플러그인을 붙이면 라이브러리에 쌓인 논문 1,000편을 몇 분 만에 훑을 수 있다는 이야기가 주기적으로 돌아옵니다. 그럴듯하게 들리지만 “훑는다”가 무엇을 뜻하는지에 따라 필요한 계산량이 수십 배 달라집니다. 그래서 실제 arXiv 논문 10편을 내려받아 각 단계를 초 단위로 재고, 1,000편 규모로 환산해 봤습니다.
왜 읽어야 하나
이 글은 라이브러리에 수백에서 수천 편의 논문을 쌓아 두고 그중 무엇을 읽을지 매번 고민하시는 연구자와, 사내에 문서 요약 파이프라인을 깔아야 하는 ML 엔지니어를 위한 글입니다. 어떤 플러그인이 더 좋은지 고르는 비교글이 아니라, 그 플러그인들이 대신 해 주는 계산이 실제로 얼마나 무거운지 숫자로 확인하려는 분에게 쓸모가 큽니다. 핵심 결론을 먼저 말씀드리면 이렇습니다. 1,000편을 몇 분 만에 처리한다는 주장은 스크리닝에 한해 사실이고 전문 독해에는 사실이 아니며, 그 경계를 가르는 것은 도구가 아니라 어느 단계에 LLM을 넣느냐입니다. 저희 측정에서 임베딩으로 1,000편을 정렬하는 데는 35초가 걸렸지만, 같은 1,000편의 전문을 LLM에 밀어 넣으면 프롬프트만 24.38M 토큰이 쌓였습니다.
읽을 사람과 물어야 할 질문을 먼저 정리했습니다.
개요
Zotero는 논문 PDF와 서지 정보를 모아 두는 오픈소스 관리 도구이고, 그 위에 붙는 AI 플러그인이 최근 몇 년 사이 여러 갈래로 늘었습니다. 대표적인 것이 PapersGPT입니다. 공식 사이트 기준으로 별 2,500개를 받았고, 상용 API 모델과 함께 Gemma, Qwen, gpt-oss 같은 오픈 모델을 로컬에서 돌리는 경로를 제공하며, 여러 PDF를 한꺼번에 대화 대상으로 삼는 기능과 라이브러리를 일괄 처리하는 AutoPilot 기능을 내세웁니다. 중국어권에서 쓰이는 zotero-AI-Butler처럼 라이브러리에 들어온 논문을 자동으로 정독해 Zotero 노트로 남기는 오픈소스 플러그인도 공개되어 있습니다.
플러그인 배포본 안에 무엇이 들어 있는지가 궁금하시다면 PapersGPT 131MB를 뜯어본 글을 먼저 보셔도 좋습니다. 그 글이 “이 도구가 무엇으로 만들어졌나”를 다뤘다면, 이 글은 “이 도구가 대신 하는 계산이 얼마나 무거운가”를 다룹니다.
이런 도구들이 공통으로 파는 가치는 명확합니다. 읽을 논문을 고르는 일에 드는 시간을 줄여 준다는 것입니다. 다만 홍보 문구에 등장하는 숫자는 대체로 어느 단계를 측정한 것인지 밝히지 않습니다. PDF에서 글자를 뽑는 일, 뽑은 글자를 벡터로 바꿔 질의와 비교하는 일, 그리고 전문을 언어 모델에 넣어 요약을 받는 일은 비용이 서로 다른 세 작업입니다. 특히 마지막 단계는 앞의 두 단계를 합친 것보다 훨씬 무겁습니다.
그래서 이번에는 도구를 평가하는 대신 그 밑에 깔린 계산을 직접 재기로 했습니다. 측정 대상은 2026년 7월에 arXiv에 올라온 에이전트 관련 논문 10편이고, 환경은 맥북 한 대에 Python 3.12.8입니다. 모든 숫자는 이 환경에서 나온 실측값이며, 1,000편 환산치는 실측값에 논문 수를 곱한 산술 결과입니다.
이 파이프라인은 무엇인가
논문 트리아지는 보통 다음 세 단계로 나뉩니다. 도구마다 이름은 다르지만 하는 일은 같습니다.
flowchart TB
A[라이브러리<br/>논문 PDF 1,000편] --> B[1단계<br/>텍스트 추출<br/>pypdf 등 PDF 파서]
B --> C{어디에 LLM을<br/>넣을 것인가}
C -->|전문 투입| D[전문 요약 경로<br/>1,000편 전체를<br/>언어 모델에 입력]
C -->|앞부분만 투입| E[2단계 스크리닝<br/>임베딩 벡터화<br/>EmbeddingGemma-300M]
E --> F[질의와 코사인 유사도<br/>순위 정렬]
F --> G[3단계<br/>상위 K편만<br/>전문 요약]
D -.프롬프트 24.38M 토큰.-> H[요약 노트]
G -.프롬프트 0.49M 토큰.-> H
핵심은 가운데 분기입니다. 전문을 그대로 언어 모델에 넣는 경로와, 값싼 임베딩으로 먼저 순위를 매긴 뒤 상위 몇 편만 읽는 경로는 결과물이 비슷해 보여도 계산량이 완전히 다릅니다. 플러그인 홍보에서 말하는 “몇 분”은 대개 왼쪽 경로가 아니라 오른쪽 경로의 일부를 가리킵니다.
임베딩 단계에 쓴 모델은 Google이 공개한 EmbeddingGemma-300M입니다. HuggingFace 모델 카드 기준으로 월 다운로드가 186만 건을 넘고, 파라미터가 3억 개 규모라 노트북에서도 상주시킬 수 있습니다. 저희는 이 모델을 로컬 서버로 띄워 두고 스킬 검색에 쓰고 있었기 때문에, 이번 측정에도 같은 서버를 그대로 사용했습니다.
설치 및 통합
측정에 쓴 구성은 특별하지 않습니다. PDF 파싱은 저장소 공용 가상환경에 이미 있던 pypdf를 썼고, 임베딩은 로컬 서버에 HTTP로 요청을 보냈습니다.
임베딩 서버는 다음 명령으로 띄웁니다. 포트 42666에서 뜨고, 준비가 끝나면 /healthz가 응답합니다.
bash .claude/skills/embeddinggemma/scripts/embeddinggemma_ctl.sh start
bash .claude/skills/embeddinggemma/scripts/embeddinggemma_ctl.sh status
문서를 벡터로 바꿀 때는 클라이언트가 붙여 주는 접두어가 중요합니다. EmbeddingGemma 계열은 문서와 질의에 서로 다른 접두어를 요구하며, 이를 빼먹으면 유사도 분포가 눈에 띄게 뭉개집니다.
from embeddinggemma_client import embed, cosine
doc_vecs = embed(paper_heads, kind="document", dims=768) # title: none | text: ...
q_vec = embed(research_question, kind="query", dims=768) # task: search result | query: ...
ranked = sorted(((cosine(q_vec, v), pid) for pid, v in zip(ids, doc_vecs)), reverse=True)
PDF 텍스트 추출은 페이지 단위로 순회하면서 시간을 재는 방식입니다. 스크리닝 단계에서는 전문이 필요 없기 때문에 앞쪽 2,000자만 모으고 즉시 중단합니다. 이 조기 중단이 스크리닝 비용을 낮추는 실질적인 장치입니다.
buf, total = [], 0
for page in PdfReader(path).pages:
chunk = page.extract_text() or ""
buf.append(chunk); total += len(chunk)
if total >= 2000: # 스크리닝에는 앞부분이면 충분합니다
break
측정 스크립트 두 개는 각각 추출 벤치마크와 스크리닝 벤치마크를 담당하며, 결과는 JSON과 로그로 남깁니다.
python3 scripts/blog/_zotero_triage_bench_20260729.py # 다운로드 + 전문 추출
python3 scripts/blog/_zotero_triage_embed_20260729.py # 앞 2,000자 임베딩 + 질의 정렬
별도로 설치한 패키지는 없습니다. PDF 파서는 기존 가상환경에 이미 들어 있었고 임베딩 서버는 다른 용도로 이미 떠 있었기 때문에, 이번 측정은 새 의존성 없이 끝났습니다. 이 점 자체가 하나의 관찰입니다. 논문 트리아지 파이프라인의 두 축인 PDF 파서와 문장 임베딩 모델은 이미 대부분의 개발 환경에 흔한 부품이고, 상용 플러그인이 파는 것은 이 부품들이 아니라 이 부품들을 Zotero 화면 안에 이어 붙인 통합 경험에 가깝습니다.
실제 실험 결과
측정 환경과 표본입니다. 1,000편 수치는 모두 이 실측값을 스케일링한 결과입니다.
먼저 텍스트 추출입니다. 논문 10편은 모두 실제 arXiv PDF이고, 합계 298쪽이었습니다.
| 항목 | 실측값 |
|---|---|
| 논문 수 | 10편 |
| 총 페이지 | 298쪽 |
| 전문 추출 총 시간 | 3.92초 |
| 논문당 추출 시간 | 0.392초 |
| 추출 처리량 | 초당 76.0쪽 |
| 논문당 토큰(추정) | 중앙값 22,156, 평균 24,379 |
가장 오래 걸린 논문은 82쪽짜리 2607.16900으로 0.90초였고, 14쪽짜리 2607.20064는 0.24초였습니다. 페이지 수에 거의 비례합니다. 토큰 수는 영어 기준 문자 3.8개당 1토큰으로 환산한 추정치이므로 [추정] 표시를 붙여 읽으셔야 합니다.
다운로드 시간도 함께 쟀는데, 여기서는 특이한 점이 없었습니다. 파일 크기가 0.43MB에서 10.41MB까지 흩어져 있었지만 내려받는 데는 편당 0.06초에서 0.73초가 걸렸습니다. 이미 로컬에 쌓여 있는 라이브러리를 다루는 상황이라면 이 단계는 아예 없어집니다. 네트워크는 이 파이프라인의 병목이 아니라는 뜻이고, 그래서 이후 논의에서는 다운로드를 빼고 추출과 추론만 봅니다.
이 값을 1,000편으로 늘리면 그림이 선명해집니다. 전문 텍스트 추출만 391.9초, 즉 6.5분이 걸립니다. 단일 프로세스 기준이라 병렬화하면 줄어들지만, 이미 이 단계에서 “몇 분”의 예산 상당 부분을 씁니다. 그리고 진짜 벽은 그다음입니다. 1,000편의 전문을 언어 모델에 넣으면 프롬프트 토큰만 24.38M이 됩니다. 이 분량을 5분 안에 소화하려면 프리필 처리량이 초당 81,266토큰이어야 하고, 10분이면 40,633토큰, 30분이면 13,544토큰, 한 시간을 줘도 6,772토큰이 필요합니다. 노트북에 올린 소형 모델이 낼 수 있는 수치가 아닙니다. 서빙 클러스터의 배치 추론 영역입니다.
전문을 그대로 읽히는 경로에서 5분이라는 목표가 요구하는 처리량입니다.
스크리닝 경로는 반대쪽 끝에 있습니다. 논문 10편의 앞 2,000자를 임베딩하는 데 걸린 시간은 전체 0.35초, 논문당 0.035초였습니다. 질의 한 건을 벡터로 바꾸는 데는 0.01초가 걸렸습니다. 1,000편으로 환산하면 35.0초입니다. 홍보 문구의 “몇 분”보다 오히려 빠릅니다.
정렬 품질도 확인했습니다. “장기 과제를 수행하는 LLM 에이전트의 하네스 메모리와 컨텍스트 관리”라는 질의를 넣었더니 상위 세 편이 이렇게 나왔습니다.
| 순위 | 코사인 유사도 | arXiv ID | 논문 |
|---|---|---|---|
| 1 | 0.6897 | 2607.20064 | PRO-LONG (프로그래매틱 메모리) |
| 2 | 0.6350 | 2607.16621 | From Memory to Skills (MSCE) |
| 3 | 0.5620 | 2607.13285 | Harness Handbook |
질의와 직접 관련된 메모리, 하네스 논문 세 편이 그대로 위로 올라왔고, 런타임 거버넌스를 다루는 2607.13716이 0.4263으로 맨 아래에 놓였습니다. 상위와 하위의 간격이 0.26 정도라 절대적으로 큰 편은 아니지만, 읽을 순서를 정하는 용도로는 충분히 갈립니다.
여기서 실질적인 처방이 나옵니다. 스크리닝으로 1,000편을 35초에 정렬한 뒤 상위 20편만 전문 요약에 넘기면, 프롬프트는 24.38M 토큰에서 약 0.49M 토큰으로 줄어듭니다. 50분의 1입니다. 이 정도면 5분 안에 끝내는 데 필요한 프리필 처리량이 초당 1,625토큰으로 내려가고, 이는 로컬 소형 모델로도 도달 가능한 범위입니다. 같은 노트북, 같은 라이브러리인데 어느 단계에 LLM을 넣느냐만 바꿔서 두 자릿수 배율의 차이가 생깁니다.
스크리닝을 앞에 두면 필요한 프리필 처리량이 초당 1,625토큰까지 내려갑니다.
ThakiCloud 제품 적용 시사점
이 결과는 저희가 운용하는 두 제품에 서로 다른 방식으로 닿습니다.
ai-platform 관점에서 보면, 전문 요약 경로는 전형적인 배치 추론 워크로드입니다. 24.38M 토큰짜리 프리필은 대화형 서빙과 성격이 다릅니다. 지연 시간은 느슨해도 되지만 처리량은 끝까지 뽑아야 하고, 요청은 사람 없이 한꺼번에 들어옵니다. 저희 ai-platform은 Kubernetes 위에서 Kueue로 GPU 큐를 나누고 vLLM으로 모델을 서빙하는 구조라, 이런 작업은 대화형 엔드포인트와 다른 큐에 넣어 야간 배치로 돌리는 편이 자원 효율이 좋습니다. 사내 문서나 논문처럼 밖으로 내보내기 어려운 자료를 다룰 때 온프레미스에서 같은 파이프라인을 돌릴 수 있다는 점도 실무에서는 크게 작용합니다. 라이브러리 전체를 상용 API에 밀어 넣는 순간, 비용보다 반출 심사가 먼저 문제가 되는 조직이 많습니다.
Paxis 관점에서는 스크리닝 단계가 더 흥미롭습니다. Paxis는 ai-platform 위에서 도는 Agent-Native Cloud 제어 평면으로, 스킬과 도구, 정책, 감사 로그를 일급 리소스로 다룹니다. 그 안의 스킬 하네스는 960개가 넘는 스킬 중에서 지금 필요한 것을 골라내는 문제를 매 요청마다 풀어야 하는데, 이번 논문 트리아지와 구조가 같습니다. 후보가 많고, 전부 읽을 수는 없고, 값싼 신호로 먼저 좁힌 뒤 비싼 판단을 소수에만 쓰는 구조입니다. 저희가 스킬 검색에 쓰는 임베딩 서버를 이번 측정에 그대로 재사용할 수 있었던 이유도 여기에 있습니다. 논문이든 스킬이든 문서든, 검색 대상만 바뀔 뿐 값싼 스크리닝과 비싼 독해를 분리한다는 원칙은 그대로 옮겨 갑니다.
두 관점을 합치면 이렇게 정리됩니다. 스크리닝을 싸게 만드는 일은 Paxis의 선택 계층이 하고, 살아남은 소수를 제대로 읽는 일은 ai-platform의 배치 추론이 받습니다. 이 분업이 서 있으면 “논문 1,000편”이라는 규모가 문제가 되지 않습니다.
한계 및 반론
이번 측정이 다루지 못한 세 가지 조건입니다.
측정에는 분명한 한계가 있습니다. 표본이 10편이라 논문 길이 분포를 대표한다고 말하기 어렵고, 82쪽짜리 한 편이 평균을 끌어올렸습니다. arXiv에 올라온 텍스트 레이어가 살아 있는 PDF만 다뤘기 때문에, 스캔본이나 그림으로 된 표가 많은 문서에서는 추출 시간이 크게 늘어납니다. 그런 문서는 OCR과 레이아웃 분석이 필요하고, 그 순간 초당 76쪽이라는 숫자는 의미를 잃습니다.
토큰 수도 추정치입니다. 실제 토크나이저를 돌린 값이 아니라 문자 수를 3.8로 나눈 값이라, 수식과 표가 많은 논문에서는 과소평가될 가능성이 있습니다. 프리필 처리량 요구치는 이 추정 토큰 수에서 나온 산술 결과이므로 같은 오차를 물려받습니다.
임베딩 스크리닝 자체에 대한 반론도 가능합니다. 앞 2,000자는 대체로 초록과 서론 앞부분인데, 기여가 논문 후반부에 몰려 있는 경우 이 방식은 그 논문을 놓칩니다. 유사도 상위와 하위의 간격이 0.26 정도로 좁았다는 점도 같은 맥락에서 읽을 수 있습니다. 정밀도가 중요한 리터러처 리뷰라면 스크리닝을 필터가 아니라 정렬 도구로만 쓰고, 하위권도 사람이 제목 수준으로는 훑는 편이 안전합니다.
마지막으로 이 글은 플러그인들의 성능을 측정한 것이 아닙니다. PapersGPT나 zotero-AI-Butler를 설치해 그 안의 처리 속도를 잰 것이 아니라, 그 도구들이 대신 수행하는 계산을 같은 재료로 직접 돌려 본 것입니다. 실제 플러그인은 캐싱과 병렬화, 증분 처리로 저희 단순 측정보다 빠를 수 있습니다.
정리
“논문 1,000편을 몇 분 만에”라는 문장은 절반만 참입니다. 저희 측정 기준으로 1,000편을 임베딩으로 정렬하는 데는 35초면 충분했고, 이건 홍보 문구보다도 빠릅니다. 반면 같은 1,000편의 전문을 언어 모델에 읽히려면 프롬프트만 24.38M 토큰이 필요하고, 5분 안에 끝내려면 초당 81,266토큰의 프리필 처리량이 있어야 합니다. 노트북에서 일어날 일이 아닙니다.
그래서 도구를 고르실 때 물어보실 질문은 “몇 편을 처리하나”가 아니라 “어느 단계에 LLM이 들어가나”입니다. 전문을 통째로 모델에 넣는 도구는 라이브러리가 커질수록 선형으로 비싸지고, 값싼 신호로 먼저 좁히는 도구는 라이브러리가 커져도 비용이 거의 늘지 않습니다. 오늘 바로 해 보실 수 있는 일은 간단합니다. 라이브러리에서 논문 열 편을 골라 앞 2,000자만 임베딩하고 지금 쓰고 계신 연구 질문으로 정렬해 보십시오. 그 순위가 납득이 간다면, 전문 요약은 상위 스무 편에만 쓰시면 됩니다. 나머지 980편은 읽지 않아도 되는 논문이라는 사실을 35초 만에 아는 것, 그게 이 파이프라인이 실제로 파는 가치입니다.