브라우저 기반 PDF 편집은 어떻게 작동할까요? (그리고 개인정보 보호가 중요한 이유)

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

LuraPDF는 다른 방식으로 작동합니다. 모든 작업은 브라우저 탭, 하드웨어, 운영 체제의 메모리 관리 기능을 통해 이루어집니다. 이 글에서는 이러한 방식을 가능하게 하는 기술 아키텍처와 관련된 엔지니어링상의 장단점을 설명합니다.

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

최신 브라우저는 더 이상 단순한 HTML 렌더링 도구가 아닙니다. 다음과 같은 기능을 갖춘 완벽한 애플리케이션 실행 환경입니다.

• 자바스크립트 엔진(Chrome의 V8, Firefox의 SpiderMonkey): 네이티브 앱과 거의 동일한 속도로 코드를 실행합니다.
• 웹어셈블리(WASM): 샌드박스 환경 내에서 컴파일된 C/C++ 코드를 네이티브에 가까운 속도로 실행합니다.
• Canvas API: 픽셀 단위 이미지 조작을 가능하게 합니다.
• 파일 시스템 접근 API: 업로드 없이 로컬 파일을 읽을 수 있습니다.
• 웹 워커: UI를 멈추지 않고 백그라운드 스레드에서 연산을 실행합니다.
• ArrayBuffer / Blob: PDF 바이트와 같은 원시 바이너리 데이터를 메모리에서 관리합니다.

이러한 기능들을 종합하면 5년 전에는 백엔드 서버가 필요했던 완벽한 기능을 갖춘 문서 처리 파이프라인을 구현할 수 있습니다.

세 가지 핵심 라이브러리

LuraPDF는 세 가지 핵심 오픈 소스 라이브러리를 기반으로 구축되었습니다.

pdf-lib

pdf-lib는 모든 JavaScript 환경에서 PDF 문서를 생성하고 수정할 수 있는 TypeScript 라이브러리입니다. 이 라이브러리는 다음과 같은 PDF 사양(ISO 32000)의 상당 부분을 구현합니다.

• 페이지 생성, 수정 및 삭제
• 글꼴 포함(표준 14개 글꼴 및 사용자 지정 TTF/OTF 글꼴 모두 지원)
• 이미지 삽입(JPEG, PNG)
• 텍스트 주석 배치
• 폼 필드 생성 및 조작
• 문서 메타데이터(제목, 작성자, 작성일 등)
• PDF 암호화(AES-128 및 AES-256)
• 상호 참조 테이블 관리

LuraPDF는 PDF를 병합할 때 pdf-lib 라이브러리를 사용하여 각 문서의 페이지 트리를 읽고, 공유 리소스를 정규화하고, 새로운 PDF를 생성합니다. 압축 시에는 이미지 객체를 더 낮은 품질 계수로 재인코딩합니다. 암호화 시에는 웹 암호화 API를 사용하여 문서에 AES-256 암호화를 적용합니다.

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 요소에 렌더링한 것입니다.

테서랙트.js

Tesseract.js는 Tesseract OCR을 WebAssembly로 컴파일한 버전입니다. Tesseract는 원래 HP Labs(1985년)에서 개발하고 현재 Google에서 유지 관리하는 오픈 소스 OCR 엔진입니다. 문자 인식을 위해 LSTM(장단기 메모리) 신경망 모델을 사용합니다.

웹어셈블리를 통해 브라우저에서 Tesseract를 실행한다는 것은 다음과 같은 의미입니다.

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

20페이지 스캔 기준으로 브라우저 OCR은 약 30~120초가 소요됩니다. 클라우드 서비스는 2~5초 정도면 충분합니다. 개인정보 보호와 속도 중 하나를 선택해야 합니다.

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

예를 들어 LuraPDF에서 PDF 파일을 압축하면 다음과 같은 일이 발생합니다.

1. 파일 선택: PDF 파일을 드롭존으로 드래그합니다. 브라우저의 파일 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바이트.

웹 워커: UI 반응성 유지

PDF 처리는 CPU 자원을 많이 소모합니다. 메인 JavaScript 스레드에서 실행하면 브라우저 탭이 멈춰 스크롤, 클릭, 진행 상황 업데이트를 볼 수 없게 됩니다.

LuraPDF는 OCR, 대용량 PDF 파싱, 이미지 재인코딩과 같은 모든 무거운 연산 작업을 웹 워커(백그라운드에서 실행되는 별도의 JavaScript 스레드)에서 처리합니다. 메인 스레드는 UI를 처리하고, 진행률 표시줄을 표시하며, 메시지 전달(postMessage/onmessage)을 통해 워커와 통신합니다.

OCR이 실행되는 동안 각 페이지 처리가 완료되면 진행률 이벤트가 발생합니다. 작업자는 메인 스레드로 { page: 5, total: 20, confidence: 94 } 전송하고, 메인 스레드는 진행률 표시줄을 업데이트합니다. 이 과정 동안 사용자 인터페이스는 계속해서 상호 작용할 수 있습니다.

메모리 관리

브라우저 메모리는 한정되어 있습니다. 200MB 크기의 PDF 파일을 메모리에 로드하고 처리한 후 저장하려면 400~600MB의 RAM(원본 바이트 + 중간 Canvas 데이터 + 출력 바이트)이 필요할 수 있습니다. RAM 용량이 제한적인 시스템에서는 이로 인해 메모리 부족 현상이 발생할 수 있습니다.

사용된 전략:

• 스트리밍 페이지 처리: 여러 페이지를 처리하는 경우, 페이지가 순차적으로 처리되고 사용 후 중간에 생성된 Canvas 요소는 삭제됩니다.
• URL.revokeObjectURL(): 임시 블롭 URL은 다운로드 후 가비지 컬렉션(GC)을 위해 취소됩니다.
• 작업자 종료: 웹 작업자는 작업을 완료한 후 사용한 메모리를 회수하기 위해 종료됩니다.

파일 크기가 매우 큰 경우(>100MB), 최신 브라우저는 8GB 이상의 RAM을 탑재한 시스템에서 문제없이 처리할 수 있습니다. 하지만 구형 시스템이나 메모리 용량이 부족한 시스템에서는 100MB 이상의 파일을 처리하는 데 어려움을 겪을 수 있습니다.

개인정보 보호 아키텍처

이 보안 모델은 브라우저의 동일 출처 정책 및 격리 아키텍처에 의해 시행됩니다.

• HTTP 요청 없음: 문서 처리 중 외부 API 호출, 원격 측정, 분석 호출이 전혀 없습니다.
• 샌드박스 실행: 웹 워커는 외부 출처로 네트워크 호출을 할 수 없습니다.
• 영구 저장소 없음: 처리된 파일은 브라우저 저장소(localStorage, IndexedDB 또는 파일 시스템 액세스)에 기록되지 않습니다.
• 탭 범위 메모리: 탭을 닫으면 해당 탭과 연결된 모든 ArrayBuffer 및 Blob 객체가 가비지 컬렉션됩니다.

이 아키텍처는 검증 가능합니다. 파일을 처리하는 동안 브라우저 개발자 도구에서 네트워크 탭을 열어보세요. 처리 작업 중에는 요청이 전혀 표시되지 않을 것입니다.

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

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

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

클라우드 처리와 장단점 비교

브라우저 기반 모델에는 솔직하게 인정해야 할 실질적인 단점들이 있습니다.

속도: 클라우드 서비스는 GPU 클러스터와 전용 인프라를 갖추고 있습니다. 대용량 문서에 대한 브라우저 OCR 처리 시간은 클라우드 서비스보다 2~10배 더 오래 걸립니다. 압축은 Canvas API를 직접 사용하기 때문에 빠릅니다.

파일 크기 제한: 브라우저 메모리가 제약 조건입니다. 매우 큰 파일(>300MB)은 일부 시스템에서 메모리 제한에 걸릴 수 있습니다. 클라우드 서비스에는 이러한 제약 조건이 없습니다.

처리 능력: WASM은 네이티브 C++ 속도의 40~80% 수준으로 실행됩니다. 클라우드 서비스는 최적화된 네이티브 코드를 실행합니다. 대부분의 문서에서는 이러한 속도 차이가 거의 느껴지지 않지만, 100페이지 이상의 OCR 작업에서는 확연한 차이를 볼 수 있습니다.

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

일상적인 문서 처리(압축, 병합, 서명, 변환, 수정)에는 브라우저 기반 모델이 충분히 빠르고, 설계상 개인 정보 보호가 보장되며, 계정이나 구독이 필요하지 않습니다.

자주 묻는 질문

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

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

OCR이 다른 서비스에 비해 시간이 오래 걸리는 이유는 무엇인가요? 브라우저 기반 Tesseract.js는 WebAssembly를 통해 CPU에서 실행됩니다. 클라우드 OCR 서비스는 GPU 클러스터에서 실행되어 문자를 훨씬 빠르게 처리합니다. 하지만 그 대신 문서가 브라우저를 벗어나지 않는다는 단점이 있습니다.

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

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

브라우저 기반 문서 처리로의 전환은 단순한 유행이 아닙니다. 이는 측정 가능한 개인정보 보호 및 신뢰도 향상 효과를 가져오는 진정한 아키텍처적 선택입니다. 다만, 고부하 작업 시 속도는 다소 저하될 수 있습니다. 타인의 서버에 저장되고 싶지 않은 문서라면 이러한 절충안이 타당합니다.