브라우저 기반 PDF 편집의 원리와 개인정보 보호가 중요한 이유

클라우드 기반 PDF 도구에 문서를 업로드할 때마다, 그 문서는 사용자가 통제할 수 없는 서버에 존재하고, 검사할 수 없는 소프트웨어로 처리되며, 자체적인 데이터 보존 및 보안 정책을 가진 회사에 저장됩니다. 잠시 동안, 계약서, 세금 신고서, 의료 기록, 또는 기밀 비즈니스 문서가 타인의 인프라에 보관되는 것입니다.

LuraPDF는 다르게 작동합니다. 모든 처리는 사용자의 브라우저 탭 안에서, 사용자의 하드웨어 위에서, 사용자의 운영체제 메모리 관리 하에 이루어집니다. 이 글에서는 이를 가능하게 하는 기술 아키텍처와 관련된 엔지니어링 트레이드오프를 설명합니다.

문서 처리 플랫폼으로서의 브라우저

현대의 브라우저는 단순한 HTML 렌더러가 아닙니다. 완전한 애플리케이션 실행 환경으로, 다음을 갖추고 있습니다:

• JavaScript 엔진 (Chrome의 V8, Firefox의 SpiderMonkey): 거의 네이티브 속도로 코드 실행
• WebAssembly (WASM): 샌드박스 환경 안에서 컴파일된 C/C++ 코드를 거의 네이티브 속도로 실행
• Canvas API: 픽셀 단위의 이미지 조작 가능
• File System Access API: 업로드 없이 로컬 파일 읽기 가능
• Web Workers: UI를 멈추지 않고 백그라운드 스레드에서 연산 실행
• ArrayBuffer / Blob: 메모리에서 원시 이진 데이터(PDF 바이트 등) 관리

이 기능들이 결합되어, 5년 전이라면 백엔드 서버가 필요했을 완전한 문서 처리 파이프라인을 실현합니다.

세 가지 핵심 라이브러리

LuraPDF는 세 가지 기반 오픈소스 라이브러리 위에 구축되었습니다:

pdf-lib

pdf-lib는 모든 JavaScript 환경에서 PDF 문서를 생성하고 수정하기 위한 TypeScript 라이브러리입니다. PDF 명세(ISO 32000)의 상당 부분을 구현하며, 다음을 포함합니다:

• 페이지 생성, 수정, 삭제
• 폰트 임베딩 (표준 14종 폰트 및 커스텀 TTF/OTF 폰트)
• 이미지 임베딩 (JPEG, PNG)
• 텍스트 어노테이션 배치
• 폼 필드 생성 및 조작
• 문서 메타데이터 (제목, 작성자, 생성 날짜 등)
• 문서 비밀번호 보호
• 교차 참조 테이블 관리

LuraPDF가 PDF를 병합할 때, pdf-lib를 사용하여 각 문서의 페이지 트리를 읽고, 공유 리소스를 정규화하며, 새 PDF를 조합합니다. 압축 시에는 이미지 객체를 낮은 품질 계수로 재인코딩합니다. 파일에 비밀번호를 설정할 때는 비밀번호에서 키를 유도하고, 모든 리더가 인식하는 PDF 표준 보안 핸들러를 사용하여 암호화된 문서를 작성합니다.

pdf-lib는 전적으로 ArrayBuffer 객체, 즉 브라우저 메모리 안의 원시 이진 데이터만을 대상으로 동작합니다. 네트워크 호출은 일절 이루어지지 않습니다.

pdfjs-dist

PDF.js는 Mozilla의 PDF 렌더링 엔진으로, npm에서 pdfjs-dist로 배포됩니다. Firefox의 내장 PDF 뷰어를 구동하는 엔진으로, 수백만 개의 실제 PDF를 대상으로 검증되었습니다.

LuraPDF는 pdfjs-dist를 다음 용도로 사용합니다:

• 페이지 렌더링: PDF 페이지를 Canvas ImageData로 변환하여 화면에 표시
• 텍스트 추출: PDF 페이지에서 텍스트 콘텐츠 스트림 읽기
• 페이지 메타데이터: 페이지 크기, 회전 값, 콘텐츠 유형 가져오기

LuraPDF 인터페이스에서 PDF가 렌더링된 모습, 즉 페이지의 시각적 미리보기가 바로 pdfjs-dist가 각 페이지를 HTML Canvas 요소에 그려낸 결과입니다.

Tesseract.js

Tesseract.js는 Tesseract OCR의 WebAssembly 컴파일 버전입니다. Tesseract는 HP Labs(1985년)에서 처음 개발하고 현재 Google이 유지 관리하는 오픈소스 OCR 엔진으로, 문자 인식에 LSTM(Long Short-Term Memory) 신경망 모델을 사용합니다.

브라우저에서 WebAssembly를 통해 Tesseract를 실행하면:

• 22 MB WASM 바이너리가 한 번 로드되어 브라우저에 캐시됩니다
• OCR 처리는 GPU가 아닌 WebAssembly를 통해 CPU에서 실행됩니다
• 처리 속도는 클라우드 OCR(GPU 클러스터 사용)보다 느리지만 동일한 품질의 결과를 생성합니다
• 문서 내용이 기기를 벗어나지 않습니다

20페이지 스캔 기준: 브라우저 OCR은 약 30~120초가 소요됩니다. 클라우드 서비스는 2~5초가 걸릴 수 있습니다. 이는 개인정보 보호와 속도 사이의 트레이드오프입니다.

아키텍처: 파일에서 출력까지

예를 들어 LuraPDF에서 PDF를 압축할 때 어떤 일이 일어나는지 살펴보겠습니다:

1. 파일 선택: PDF를 드롭존에 드래그합니다. 브라우저의 File API가 파일을 ArrayBuffer, 즉 브라우저 메모리의 원시 바이트로 읽어 들입니다. 업로드는 발생하지 않습니다.

2. 유효성 검사: ArrayBuffer의 시작 부분에 매직 바이트 %PDF가 있는지 빠르게 확인합니다.

3. 로딩: pdf-lib의 PDFDocument.load()가 교차 참조 테이블을 파싱하고, 객체 트리를 읽고, 문서의 메모리 내 표현을 구성합니다.

4. 이미지 열거: 라이브러리가 페이지 콘텐츠 스트림을 순회하며 이미지 XObject(임베딩된 이미지)를 찾습니다. 각 이미지의 너비, 높이, 압축 유형, 바이트 데이터가 추출됩니다.

5. 재인코딩: 각 이미지의 원시 픽셀 데이터를 HTML Canvas 요소에 그린 다음, canvas.toBlob('image/jpeg', quality)를 사용하여 낮은 JPEG 품질 계수로 재내보냅니다. 원본 이미지 객체는 더 작게 인코딩된 버전으로 교체됩니다.

6. 문서 직렬화: pdf-lib의 save() 메서드가 수정된 문서를 바이트로 다시 직렬화합니다. 객체 스트림은 DEFLATE로 압축됩니다.

7. 다운로드: 바이트가 Blob 객체로 래핑되고, 임시 객체 URL이 생성되며(URL.createObjectURL(blob)), 프로그래밍 방식의 <a> 클릭이 브라우저의 다운로드 메커니즘을 트리거합니다.

외부 서버로 전송되는 총 데이터: 0 바이트.

Web Workers: UI 반응성 유지

PDF 처리는 CPU를 많이 사용합니다. 메인 JavaScript 스레드에서 실행하면 브라우저 탭이 멈추어, 파일 처리 중 스크롤, 클릭, 또는 진행 상황 업데이트 확인이 불가능해집니다.

LuraPDF는 모든 무거운 연산(OCR, 대형 PDF 파싱, 이미지 재인코딩)을 Web Workers, 즉 백그라운드에서 실행되는 별도의 JavaScript 스레드에서 처리합니다. 메인 스레드는 UI를 담당하고, 진행 상황 표시줄을 표시하며, 메시지 전달(postMessage / onmessage)을 통해 워커와 통신합니다.

OCR 실행 중에는 각 페이지가 처리된 후 진행 이벤트가 발생합니다. 워커가 { page: 5, total: 20, confidence: 94 }를 메인 스레드로 보내면, 메인 스레드가 진행 상황 표시줄을 업데이트합니다. 처리 내내 UI는 반응성을 유지합니다.

메모리 관리

브라우저 메모리는 유한합니다. 200 MB PDF를 메모리에 로드하고, 처리하고, 저장하면 400~600 MB의 RAM이 필요할 수 있습니다(원본 바이트 + 중간 Canvas 데이터 + 출력 바이트). 메모리가 제한된 시스템에서는 메모리 압박이 발생할 수 있습니다.

사용되는 전략:

• 스트리밍 페이지 처리: 다중 페이지 작업의 경우, 페이지를 처리한 후 중간 Canvas 요소를 사용 후 즉시 삭제합니다
• URL.revokeObjectURL(): 다운로드 후 임시 Blob URL을 폐기하여 GC를 허용합니다
• 워커 종료: Web Workers는 작업 완료 후 종료하여 사용한 메모리를 회수합니다

매우 큰 파일(>100 MB)의 경우, 8 GB 이상의 RAM을 갖춘 시스템에서 현대 브라우저는 문제없이 처리합니다. 오래되었거나 메모리가 제한된 시스템은 100 MB 이상의 소스 파일에서 어려움을 겪을 수 있습니다.

개인정보 보호 아키텍처

보안 모델은 브라우저의 동일 출처 정책과 격리 아키텍처에 의해 적용됩니다:

• HTTP 요청 없음: 문서 처리 중 외부 API 호출, 원격 측정, 분석 호출 없음
• 샌드박스 실행: Web Workers는 외부 출처에 대한 네트워크 호출을 할 수 없음
• 영구 저장소 없음: 처리된 파일은 브라우저 저장소(localStorage, IndexedDB, 또는 File System Access)에 기록되지 않음
• 탭 범위 메모리: 탭을 닫으면 해당 탭과 연관된 모든 ArrayBuffer와 Blob 객체가 가비지 컬렉션됨

이 아키텍처는 검증 가능합니다: 파일을 처리하는 동안 DevTools의 네트워크 탭을 열어 보세요. 처리 작업 중 요청이 하나도 없음을 확인할 수 있습니다.

오픈소스 라이브러리: 검사 가능, 블랙박스 아님

세 가지 핵심 라이브러리, pdf-lib, pdfjs-dist, Tesseract.js는 모두 GitHub에 공개 저장소를 가진 오픈소스입니다. 구현 내용은 누구나 검사할 수 있습니다. LuraPDF에서 실행되는 PDF 처리 코드는 독점적인 블랙박스가 아니라, 실제 사용자, 이슈, 기여가 있는 공개 코드입니다.

이것은 신뢰에 있어 중요합니다. 클라우드 서비스가 "파일을 처리하고 삭제한다"고 말할 때, 그 말을 그대로 믿어야 합니다. LuraPDF가 네트워크 호출 없이 브라우저 샌드박스에서 오픈소스 라이브러리를 사용할 때는, 네트워크 탭을 관찰하여 그 주장을 직접 검증할 수 있습니다.

클라우드 처리와의 트레이드오프

브라우저 기반 모델에는 솔직하게 인정해야 할 실제 트레이드오프가 있습니다:

속도: 클라우드 서비스는 GPU 클러스터와 전용 인프라를 보유합니다. 대용량 문서에 대한 브라우저 OCR은 클라우드 동등 서비스보다 2~10배 오래 걸립니다. 압축은 Canvas API를 직접 사용하기 때문에 빠릅니다.

파일 크기 제한: 브라우저 메모리가 제약 요인입니다. 매우 큰 파일(>300 MB)은 일부 시스템에서 메모리 한계에 부딪힐 수 있습니다. 클라우드 서비스에는 이런 제약이 없습니다.

처리 능력: WASM은 네이티브 C++ 속도의 40~80%로 실행됩니다. 클라우드 서비스는 최적화된 네이티브 코드를 실행합니다. 대부분의 문서에서 이 차이는 체감하기 어렵지만, 100페이지 이상의 OCR 작업에서는 눈에 띕니다.

기능: 일부 고급 PDF 기능(PDF/X 준수 검사, 전문적인 색상 관리, CMYK 워크플로우)은 전문화된 서버 측 도구를 필요로 합니다. 브라우저 기반 처리는 95%의 경우를 처리합니다.

일상적인 문서 처리, 즉 압축, 병합, 서명, 변환, 삭제 등의 경우, 브라우저 기반 모델은 충분히 빠르고, 설계상 개인정보가 보호되며, 계정이나 구독이 필요 없습니다.

자주 묻는 질문

LuraPDF는 원격 측정 또는 사용 데이터를 수집합니까? LuraPDF는 집계된 페이지 뷰 통계를 위해 Google Analytics를 사용합니다. 문서 처리 작업은 분석 이벤트를 생성하지 않습니다. 파일의 내용은 절대 전송되지 않습니다.

업로드가 발생하지 않는다는 것을 확인할 수 있습니까? 네. 개발자 도구(F12)를 열고 네트워크 탭을 클릭한 후 "XHR" 또는 "Fetch"로 필터링하세요. 파일을 처리하면서 처리 중 문서 관련 네트워크 요청이 전혀 없음을 확인하세요.

다른 서비스에 비해 OCR이 왜 오래 걸립니까? 브라우저 기반 Tesseract.js는 WebAssembly를 통해 CPU에서 실행됩니다. 클라우드 OCR 서비스는 문자를 수십 배 빠르게 처리하는 GPU 클러스터에서 실행됩니다. 그 트레이드오프는 문서가 브라우저를 벗어나지 않는다는 것입니다.

처리 중 탭을 닫으면 어떻게 됩니까? 처리가 즉시 중단됩니다. 브라우저 탭의 메모리는 가비지 컬렉션됩니다. 디스크의 원본 파일은 변경되지 않습니다.

코드는 오픈소스입니까? 핵심 처리 라이브러리(pdf-lib, pdfjs-dist, Tesseract.js)는 오픈소스입니다. LuraPDF의 인터페이스 코드는 현재 오픈소스가 아니지만, 처리 파이프라인은 오픈소스 컴포넌트만을 사용합니다.

브라우저 기반 문서 처리로의 전환은 단순한 기믹이 아닙니다. 이는 집중적인 작업에서 속도를 희생하는 대신, 측정 가능한 개인정보 보호와 신뢰 이점을 갖춘 진정한 아키텍처적 선택입니다. 타인의 서버에 존재하지 않았으면 하는 문서라면, 이것이 올바른 트레이드오프입니다.