개인용 PDF 툴킷 구축: 문서 처리를 전적으로 클라이언트 측으로 이전

Source: Dev.to

우리는 모두 그런 경험을 해봤을 겁니다. 민감한 계약서를 빨리 압축하거나, 몇 개의 청구서를 합치거나, NDA에 서명해야 할 때 말이죠. 그런데 구글 첫 페이지를 살펴보면 거의 모든 도구가 개인 파일을 원격 서버에 업로드하도록 강요한다는 것을 알 수 있습니다. 그냥 운에 맡겨서 나중에 데이터를 삭제해 주길 바랄 수밖에 없습니다.

학생으로서 뭔가를 만들다 보면, 두 페이지를 합치기 위해 100 MB짜리 거대한 PDF를 네트워크를 통해 전송하는 것이 굉장히 비효율적이고 솔직히 좀 수상하게 느껴졌습니다.

이 문제를 해결하고 싶어 PDFOmni를 만들었습니다. 브라우저 기반 PDF 툴킷으로, 모든 무거운 작업이 사용자의 기기에서 로컬로 이루어집니다. 백엔드 저장소도 없고, 서버 대기열도 없으며, 여러분의 문서에 대한 어떠한 지식도 갖고 있지 않습니다.

대부분의 전통적인 문서 도구는 무거운 백엔드 라이브러리를 사용해 서버 측에서 처리합니다. 워크플로우는 언제나 동일합니다: 파일을 업로드하고, 서버가 처리한 뒤, 다시 다운로드합니다.

연산을 완전히 클라이언트 측으로 옮기면 아키텍처가 완전히 바뀝니다. 브라우저가 파일을 직접 메모리로 로드하고, 스크립트를 이용해 로컬에서 처리한 뒤, 바로 디스크에 저장합니다.

순수하게 클라이언트 측 도구를 만들 때 가장 큰 장애물은 메모리 관리입니다. 브라우저는 메모리 사용량이 급증하면 탭을 강제로 종료시키는 경향이 있기 때문에 매우 조심해야 합니다.

로컬 PDF 압축기를 만들 때, 브라우저가 무거운 이미지가 많이 포함된 스캔 문서를 크래시 없이 처리할 수 있도록 해야 했습니다. 로컬 스크립트를 최적화함으로써 사이트는 브라우저 내에서 최대 500 MB 파일도 편하게 처리할 수 있게 되었습니다. 목표 크기만 선택하면 브라우저가 중복 데이터를 제거하고 이미지를 로컬에서 다운샘플링하는 작업을 수행합니다.

PDF 병합 도구에도 동일한 논리가 적용됩니다. 여러 문서를 브라우저 메모리에 보관한 뒤 버퍼를 하나의 다운로드 가능한 블롭으로 합치면서도 인터페이스를 반응성 있게 유지하는 것이 핵심이었습니다.

또한 문서를 요약하거나 질의할 수 있는 AI 어시스턴트를 추가하고 싶었지만, 프라이버시를 보호하기 위해 신중히 다루어야 했습니다.

보안을 유지하기 위해 전체 RAG(검색 강화 생성) 파이프라인을 사용자의 기기에서 로컬로 실행합니다. 앱은 텍스트를 추출하고 PDF의 관련 부분을 브라우저 내부에서 바로 검색합니다.

문서와 대화하고 싶을 때, 앱은 사용자가 직접 OpenRouter API 키를 입력하도록 요청합니다