PaperPilot – 클라우드 없이 돌아가는 순수 Rust PDF 엔진(WASM·MCP 지원)

요약

PaperPilot은 파일을 밖으로 보내지 않고 내 컴퓨터에서 PDF를 다루는 순수 Rust 도구 모음입니다.

한 개발자가 GitHub에 공개한 오픈소스 프로젝트입니다. 하나의 Rust 엔진을 MCP(AI 에이전트가 외부 도구를 부르는 규약) 서버, 명령줄 도구, 브라우저용 WASM, 데스크톱 앱, 로컬 REST API가 함께 씁니다.

왜 중요한가

Claude Code나 Cursor 같은 AI 도구가 PDF 병합·분할·OCR(이미지 속 글자 인식)을 직접 실행할 수 있게 됩니다.
처리가 모두 로컬에서 끝나서 민감한 문서를 클라우드 서비스에 올리지 않아도 됩니다.

핵심 내용

페이지 병합·분할·회전·재배열, 소책자 배치, 압축 같은 편집 기능을 갖췄습니다.
텍스트·표 추출, PaddleOCR 모델을 쓰는 순수 Rust OCR, 개인정보 탐지, 서명 검증도 지원합니다.
브라우저판은 파일을 서버에 올리지 않고 브라우저 메모리 안에서만 처리한다고 밝혔습니다.
lopdf, pdf_oxide 같은 Rust 라이브러리 위에 지어서 Chromium이나 C++ 런타임이 필요 없습니다.
저장소의 커뮤니티판은 Apache 2.0 라이선스이고, SSO(통합 로그인)와 감사 로그를 더한 기업판은 따로 개발합니다.

HN 반응

printpdf 개발자 등은 이미 있는 Rust 라이브러리를 두고 AI로 또 만들었다고 비판했고, 작성자는 기존 PDF 수정이 목적이라 다르다고 답했습니다.
MuPDF(AGPL 라이선스) 코드를 옮긴 것 아니냐는 의혹에 작성자는 Apache·MIT 라이브러리만 썼다고 반박했습니다.

30개 표시 · 전체 87개

fschuett1일 전 HN

Rust로 된 PDF 엔진이 이미 있는데 왜 다들 바이브코딩으로 새로 만들려는 걸까요? 이 프로젝트가 기반으로 삼은 https://github.com/yfedoseev/pdf_oxide 는 https://github.com/fschutt/printpdf 를 완전히 놓치고 있습니다. printpdf는 (AI를 쓴 부분도, 안 쓴 부분도 있지만) 수년간 수많은 버그 수정을 거쳐 개발됐습니다. MIT 라이선스이고 WASM으로도 빌드되며, https://fschutt.github.io/printpdf/ 에서 데모가 돌아갑니다.

구글에서 "rust pdf library"를 한 번만 검색해도 나옵니다(네, 저 늙었습니다. 요즘은 아무도 "구글링" 안 한다는 거 압니다). 그런데도 사람들은 "자기만의" 어딘가 망가진 HTML -> PDF 렌더러를 갖겠다고 모든 걸 만들고 또 만들고 또 만듭니다. 그러고는 이미 예전에 고친 예외 상황에 똑같이 부딪히죠. 특히 타이포그래피에는 예외 상황이 정말 많습니다. 저는 최근에 1732년에 나온 어떤 책들의 스캔본을 OCR하고 정리하면서 Claude가 폰트를 자동으로 추출하게 했는데, 그 과정에서 고친 게 많았습니다. 레이아웃, 특히 단, 각주, 사이드바 처리와 관련된 예외 상황이 엄청나게 많았고, "히브리어 RTL 텍스트가 줄바꿈이 이상하게 되면 사라져 버린다"거나 "1비트 이미지 압축" 같은 문제도 있었습니다.

저는 AI에 반대하지 않습니다. 저도 많이 씁니다. 다만 짜증 나는 건, 똑같은 일을 하는 기존 프로젝트가 쌓아 온 수년의 작업을 사람들이 완전히 무시한다는 점입니다. 포크하면 될 걸, 똑같은 작업을 토큰으로 다시 만들어 내죠. 아마 작성자는 "이미 있는 건 아닐까" 하고 조사하지 않았을 겁니다. 그게 짜증 나는 부분이고, 그러다 보면 비슷한 프로젝트 100개가 토큰을 써서 세상을 처음부터 다시 만들게 됩니다. 새로운 접근법을 더 빨리 탐색하는 데 도움이 될 때도 있지만, 대부분은 그렇지 않고 이미 해결된 예외 상황을 놓칩니다.
tchalla1일 전 HN

https://github.com/yfedoseev/pdf_oxide 는 https://github.com/fschutt/printpdf 를 완전히 놓치고 있습니다. printpdf는 수년간 수많은 버그 수정을 거쳐 개발됐습니다(AI를 쓴 부분도, 안 쓴 부분도 있습니다). MIT 라이선스이고 WASM으로도 빌드되며, https://fschutt.github.io/printpdf/ 에서 데모가 돌아갑니다.

fschutt/printpdf가 본인 프로젝트인 것 같은데요. 그렇다면 최소한 댓글에서 밝히셔야 합니다.
fschuett1일 전 HN

네, 제 저장소입니다. 사용자 이름만 봐도 알 수 있는 줄 알았어요. 죄송합니다.
rubyfan1일 전 HN

알 수 있어요.
vardhan12371일 전 HN

printpdf 작업에 큰 존경을 보냅니다. 의견도 남겨 주셔서 감사합니다!

Rust PDF 생태계를 살펴볼 때 printpdf는 PDF 생성용으로 가장 먼저 본 크레이트 가운데 하나였습니다. 그런데도 lopdf와 pdf-writer를 중심으로 한 스택을 택한 이유는 구조 때문이었습니다. PaperPilot이 주로 다루는 것은 이미 존재하는, 임의의, 종종 형식이 깨진 실제 PDF를 대규모로 조작하고 비파괴적으로 AST를 변환하는 일입니다(상호 참조 테이블 재정렬, 세밀한 /P 권한 비트마스크 해싱, 원시 오브젝트 스트림, 페이지 임포지션, 소책자 접기, 아웃라인 분할 등).

문서를 새로 합성하는 일(HTML/Markdown에서 PDF로)은 말씀하신 RTL이나 각주 문제 같은 타이포그래피와 예외 상황이 악명 높게 어렵습니다. 그 분야에서는 printpdf가 실전에서 검증한 접근법을 배우고 협업할 수 있으면 좋겠습니다. 피드백과 Rust PDF 생태계에 대한 모든 기여에 감사드립니다!
NullifyNAN1일 전 HN

작성하려는 소프트웨어와 똑같은 것이 이미 학습 데이터에 들어 있으면 LLM 성능이 크게 올라갑니다.
whizzter1일 전 HN

이 글이 올라오기 몇 시간 전에 .NET 서브레딧에도 다른 PDF 라이브러리가 올라왔는데, 저도 똑같은 생각을 했습니다.
thadt1일 전 HN

이건 라이브러리가 아니라 야심 찬 상용 지향[1] 도구라서 그렇습니다. 사용 사례와 필요가 그들이 노리는 기능 구성과 맞아떨어지고, 시장 조사와 전망대로 Adobe보다 자릿수가 다르게 싸게 팔 수 있다면, 뭔가 될 수도 있겠죠.

전략적 비전: PaperPilot을 최고 수준의 PDF 워크스테이션에서 인간과 AI 에이전트를 위한 범용 문서 운영체제로 진화시킨다. [2]

[1] https://github.com/KrushnaVardhanReddy/PaperPilot/blob/main/pricing_strategy.md

[2] https://github.com/KrushnaVardhanReddy/PaperPilot/blob/main/PHASES.md
fschuett1일 전 HN

"3.6 Gemini요? 이 사람 제정신이 아니네요. 의무실로 데려가세요."
djoldman1일 전 HN

https://github.com/KrushnaVardhanReddy/PaperPilot/commit/63d2824d9e9b8ca9f7133c09a8fccfbde3517862

저는 다른 사람들의 첫 커밋을 확인해 보는 걸 좋아해요 :)
pinyencheng1일 전 HN

Rust PDF 엔진은 이미 몇 달 전부터 있었어요. 바퀴 좀 그만 만들어야 해요. 이미 있는 훌륭한 프로젝트에 기여해야죠. 또 새로 만들지 말고 PR을 보내세요.
Surac1일 전 HN

저는 요즘 PDF를 만들 때 주로 typst를 씁니다. 모든 것을 typ 파일과 템플릿으로 변환하도록 여러 프런트엔드와 커넥터를 직접 만들었고, sphinx의 백엔드로도 씁니다.
foresterre1일 전 HN

i18n, 테마, 템플릿은 어떻게 쓰고 계신가요? 이런 것들을 모두 typst 바깥에서 정의하고, 예를 들면 typst 컴파일러에 섀도 파일을 추가하는 식인가요?

제가 최근에 비슷한 작업을 하고 있어서 여쭙습니다. 제 typst 파일은 템플릿이라, 같은 입력이라도 결과가 달라질 수 있고 번역도 서로 달라야 할 수 있습니다. 그래서 typst로 작은 i18n 라이브러리를 직접 만들었습니다(물론 typst 파일마다 번역 세트가 함께 있어야 한다고 요구하는 방법도 있겠지만요).
Surac1일 전 HN

주로 함수와 변수 정의가 들어 있는 typst 템플릿 파일이 있습니다. 그리고 그 템플릿의 함수를 활용하는 docutil -> typst 재작성기가 있습니다. 소스 파일에 올바른 텍스트가 이미 들어 있어서 i18n은 저한테는 문제가 아닙니다. 대신 fontutils로 여러 나라 글리프가 들어간 ttf 폰트를 만들어 두었습니다. sphinx와 typst 둘 다 유니코드를 지원하니 그냥 됩니다. 이후 PDF를 후처리해서 쓰이지 않은 글리프는 모두 제거하고, 일부 PDF 스트림도 지워서 용량을 줄입니다.
evilmonkey191일 전 HN

Typst에서 i18n을 어떻게 하시는지 궁금합니다. 흥미로워 보이네요.
alwinaugustin1일 전 HN

저도 로컬에서 도는 도구 모음을 만들었습니다. https://toolbit.app/ 에서 써 보실 수 있고, 저장소는 https://github.com/alwin-augustin/toolbit 입니다. 지금 데스크톱 앱을 작업 중이고, 맥 실리콘 앱은 이미 완성돼 잘 돌아갑니다.
colesantiago1일 전 HN

이 PDF 엔진은 바이브코딩으로 만들어졌고, MuPDF 소스 코드를 읽고 (C에서 Rust로) 옮긴 것 아닌가요? 몇몇 곳에서 MuPDF를 언급한 흔적이 조금 보이는데요.

그렇다면 그 사실을 밝혀야 하고, 라이선스도 Apache가 아니라 AGPLv3여야 합니다.
ligarota1일 전 HN

Rust로 된 hayro를 쓰고 있습니다.
vardhan12371일 전 HN

절대 아닙니다! PaperPilot에는 MuPDF 코드도, FFI도, 트랜스파일도 전혀 없습니다.

PDF 파싱과 AST 조작의 핵심은 순수 Rust 라이브러리인 lopdf(0.45), pdf-writer, hayro, image 위에서 만들어졌습니다. 모두 Apache 2.0 또는 MIT 라이선스입니다.

문서나 기획 노트에서 MuPDF를 언급한 것은 전적으로 아키텍처 트레이드오프 분석의 일부였습니다(PyMuPDF 같은 기존 Python/C 추출 파이프라인과 순수 Rust를 비교 평가한 것입니다). paperpilot-pdf의 크레이트 스택 전체는 100% Apache 2.0 / MIT로 깨끗합니다.
jacquesm1일 전 HN

라이선스는 너무 옛날 얘기죠. /s

농담은 접어두고, 예를 들어 줄 수 있나요?

tredre31일 전 HN

비슷한 코드가 있다는 뜻이라면 저는 판단할 수 없지만, 그게 아니라면 mupdf가 언급된 곳은 AI 지침 파일뿐입니다.

    > **The Opportunity:** Capturing the high-growth enterprise AI engineering market by replacing bloated, slow Python extraction pipelines (`Unstructured.io`, `Docling`, `Marker`, `LlamaParse`, `PyMuPDF4LLM`) with a pure-Rust, sub-10ms, multi-format ingestion kernel.
    - This structure guarantees that if we ever swap the PDF engine to `pdfium` or `mupdf`, not a single line of business logic in `paperpilot-core` or CLI tools will need to be rewritten.
    > Directly captures the high-growth AI Engineering & RAG pipeline market (displacing bloated Python stacks like Docling, Marker, PyMuPDF4LLM, and Camelot) with sub-10ms, pure-Rust, on-device parsing.
    | A.2.5 | `MuPdfBackend` adapter (Future) | Use MuPDF for OCR-heavy workflows via FFI |

jacquesm1일 전 HN

그건 막연히 비슷한 게 아니에요. 파생이죠. AI식 표현을 빌리자면요.
jasomill1일 전 HN

맥락 없이 위 내용만 읽으면, 플러그인 방식으로 PDF 엔진을 갈아 끼울 수 있게 추상 인터페이스를 만들려는 것처럼 들립니다. 모든 라이선스가 AGPL v3와 호환되고, AGPL 엔진이 포함된 빌드를 AGPL 조건에 따라서만 쓴다면 라이선스 문제는 없을 겁니다. ffmpeg의 "--enable-gpl" 스위치와 비슷한 방식입니다.
_rwo1일 전 HN

저는 한동안 PDF 관련 작업을 전부 https://github.com/SimonBure/presse 로 처리해 왔는데, 지금까지는 아주 잘 됩니다(관계자는 아닙니다). 대부분은 간단한 CLI만으로 충분합니다.
febed1일 전 HN

알고 있는 비밀번호로 암호를 해제하는 기능과 서명을 추가하는 기능이 있으면 유용하겠습니다.
vardhan12371일 전 HN

둘 다 이미 지원합니다! 비밀번호를 알려 주면 비밀번호로 보호된 PDF를 풀어 주는 pdf_decrypt가 있고, 암호화 서명을 적용하는 pdf_sign, 인증서를 검증하는 pdf_validate_signatures도 있습니다.
Latitude79731일 전 HN

Bento PDF를 소개하고 싶습니다. https://www.bentopdf.com/

브라우저에서 돌아가고, 프라이버시를 지켜 주며, 번거로운 것도 없습니다. 원하면 로컬에 직접 호스팅할 수도 있습니다.
bawana1일 전 HN
인터페이스는 마음에 드는데, 버그가 거슬립니다.
1. 텍스트 상자를 클릭하고(IRS 1040 양식을 예로 들겠습니다) 글자 간격을 기본값(0)에서 다른 값으로 바꿨다가 다시 0으로 돌려 보세요. 원래 텍스트로 돌아오지 않습니다.
2. 텍스트 상자를 추가하면, 마우스를 올렸을 때 사방 화살표가 나오는데도 옮길 수 없고 화살표 키로도 안 움직입니다.
3. 텍스트 상자를 추가하고 텍스트를 입력한 뒤 선택해서 줄 간격을 바꾸면 간격은 바뀌는데, 입력란의 숫자는 1.25로 그대로입니다.
4. 글자 간격과 단어 간격이 작동하지 않습니다.
5. 마지막 업데이트가 1년 전입니다.
ffin21시간 전 HN

README에 있는 GIF를 보면 UI가 눈에 띄게 깨져 있어요(헤더 오른쪽 텍스트의 세로 정렬이 안 맞습니다).

사람이 이 프로젝트를 제대로 들여다본 적이 있는지 모르겠습니다. 누군가의 과열된 openclaw 에이전트 같은 게 만든 결과물 같아요.
efields1일 전 HN

이 댓글들을 보니 로컬 PDF 솔루션이 이렇게 많다는 것(그리고 그것들에 대한 의견도 이렇게 많다는 것)에 놀랐어요.

Hacker News에서 보기 ↗