PDF 하나 합치려고 서버에 올리던 시절
PDF 두 개를 합치거나 몇 페이지만 잘라내야 할 때, 검색하면 나오는 온라인 PDF 사이트에 파일을 올려본 적 있으시죠? 편하긴 한데 찜찜할 때가 있어요. 그 파일이 계약서나 연봉 정보가 담긴 문서, 고객 개인정보가 들어간 보고서라면 더 그렇죠. "이거 저 회사 서버에 남는 거 아냐?"라는 생각이 드는 순간 손이 멈추거든요.
PaperPilot은 바로 이 문제를 겨냥한 오픈소스 프로젝트예요. 이름에 붙은 키워드 세 가지가 핵심인데요, 파일이 내 기기 밖으로 나가지 않는 Zero-Cloud, C/C++ 라이브러리 없이 Rust로만 작성된 Pure-Rust, 그리고 WASM과 MCP 지원이에요. 하나씩 풀어볼게요.
왜 '순수 Rust'가 중요할까
PDF 엔진을 만드는 건 생각보다 훨씬 큰일이에요. PDF 표준(ISO 32000) 문서만 수백 페이지에 달하고, 폰트 임베딩, 압축 스트림, 암호화, 주석, 폼 필드까지 전부 다뤄야 하거든요. 게다가 실제로 돌아다니는 PDF 중에는 표준을 안 지킨 '깨진 파일'이 정말 많아요. 그래서 대부분의 도구는 엔진을 직접 만들지 않고 구글의 PDFium, Artifex의 MuPDF, Poppler 같은 검증된 C/C++ 라이브러리를 가져다 써요.
문제는 PDF 파서가 보안 사고의 단골이라는 거예요. 외부에서 받은 파일을 열어 복잡한 구조를 해석해야 하니, 메모리 버그 하나가 그대로 공격 경로가 돼요. 2021년 아이폰을 노린 스파이웨어 공격 'FORCEDENTRY'도 PDF 처리 경로에 있던 JBIG2 이미지 디코더의 정수 오버플로 버그를 파고든 사례였어요.
Rust는 메모리 안전성을 컴파일 단계에서 강제하는 언어예요. 쉽게 말해 이미 해제된 메모리를 다시 쓰거나 배열 범위를 넘어서 읽는 식의 실수를 컴파일러가 대부분 막아줘요. 믿을 수 없는 입력을 파싱해야 하는 PDF 엔진과 잘 맞는 성격이죠.
순수 Rust의 장점이 하나 더 있는데, 빌드와 배포가 단순해진다는 거예요. C 라이브러리가 끼어 있으면 OS마다 빌드 환경을 맞춰야 하고, 웹어셈블리로 옮기려면 Emscripten 같은 별도 툴체인도 거쳐야 해요. 순수 Rust라면 컴파일 타깃만 바꾸면 돼요.
cargo build --target wasm32-unknown-unknown --release
WASM: 브라우저 안에서 돌아가는 PDF 엔진
WASM(WebAssembly)이 뭐냐면, 브라우저에서 네이티브에 가까운 속도로 실행되는 바이너리 포맷이에요. Rust 코드를 WASM으로 컴파일하면 웹 페이지가 PDF 엔진을 통째로 내려받아 사용자 컴퓨터에서 직접 실행해요. 파일은 브라우저 메모리 안에서만 처리되고 서버로는 아무것도 전송되지 않아요. 'Zero-Cloud'가 가능한 이유가 바로 이거예요. 무거운 연산을 사용자 기기가 맡으니 서비스 운영자는 정적 파일만 호스팅하면 된다는 장점도 있어요.
MCP: AI 에이전트가 PDF를 다룰 수 있게
MCP(Model Context Protocol)는 Anthropic이 2024년 말에 공개한 표준인데, AI 모델이 외부 도구를 호출하는 방식을 하나로 통일한 규격이에요. USB-C처럼 이 규격만 맞추면 어떤 AI 앱에든 꽂아서 쓸 수 있다고 생각하면 돼요. Claude Desktop, Cursor 같은 여러 클라이언트가 이미 지원하고 있어요.
PDF 엔진이 MCP 서버로 동작한다는 건, AI 에이전트에게 "이 폴더에 있는 견적서 PDF를 하나로 합쳐줘"라고 부탁하면 에이전트가 로컬에서 PaperPilot을 불러서 처리할 수 있다는 뜻이에요. 문서를 통째로 클라우드에 올리는 대신, 실제 작업은 로컬 도구가 하고 AI는 지시만 내리는 구조를 만들 수 있죠. 다만 텍스트를 추출해서 모델에 넘기면 그 내용은 결국 모델 쪽으로 넘어가요. 그러니 어떤 데이터가 어디까지 이동하는지는 여전히 꼼꼼히 따져봐야 해요.
다른 도구들과 비교해 보면
Rust 생태계에는 이미 PDF 관련 크레이트가 여럿 있어요. 저수준 조작용 lopdf, Typst 팀이 만든 PDF 생성용 pdf-writer, PDFium 바인딩인 pdfium-render 같은 것들이요. 그런데 대부분 생성, 조작, 렌더링 중 한 영역에만 집중하거나 C 라이브러리에 기대고 있어요. JavaScript 쪽에서는 렌더링용 pdf.js와 생성·수정용 pdf-lib가 대표적이고, 셀프호스팅 PDF 툴킷으로는 Java 기반의 Stirling-PDF가 많이 쓰여요.
PaperPilot의 차별점은 순수 Rust 코드 하나로 브라우저, 로컬, AI 에이전트를 모두 커버하려는 방향성이에요. 다만 개인 계정에서 공개된 비교적 새 프로젝트라서, 실제로 어떤 기능까지 지원하는지와 깨진 PDF를 얼마나 잘 견디는지는 README와 이슈를 직접 보고 판단하는 게 좋아요. PDF는 엣지 케이스가 끝없이 나오는 포맷이라, 수십 년 다듬어진 PDFium 수준을 기대하기엔 아직 이르거든요.
한국 개발자에게 주는 시사점
한국에는 개인정보보호법이나 금융권 망분리 규제 때문에 외부 서버에 문서를 올리면 안 되는 환경이 정말 많아요. 사내 문서 도구를 만들 때 WASM 기반으로 클라이언트에서 처리하는 구조는 보안 심사를 통과하기 훨씬 수월한 선택지가 될 수 있어요. 사내에 AI 에이전트를 도입하려는 팀이라면, MCP 서버 형태의 로컬 문서 도구가 어떻게 생겼는지 참고하기에도 좋아요. Rust를 공부하는 분에게는 파서, WASM, MCP라는 요즘 트렌드 세 가지를 한 저장소에서 볼 수 있는 좋은 학습 자료이기도 하고요.
마무리
한 줄 정리: 문서 처리는 내 기기에서 하고 AI는 지시만 내리는 구조. PaperPilot은 '로컬 우선' 문서 처리가 어디로 가는지 보여주는 프로젝트예요.
여러분 회사에서는 PDF를 어떻게 처리하고 있나요? 클라우드 API, 서버 라이브러리, 브라우저 처리 중 어떤 구조가 가장 현실적이라고 보시나요?
🔗 출처: Hacker News