클라이언트 사이드 PDF 처리: WebAssembly를 활용한 인메모리 문서 제어

웹 애플리케이션에서 문서 제어 작업은 전통적으로 Poppler, Ghostscript, PDFKit 같은 무거운 네이티브 바이너리를 구동하는 백엔드 마이크로서비스에 의존해 왔습니다. 기밀 계약서를 병합하거나 의료 기록에서 특정 페이지만 추출해야 할 때, 일반적인 웹 서비스 방식은 암호화되지 않은 원본 파일 전체를 원격 클라우드 서버로 업로드하도록 요구합니다.

기업 환경, 법률 계약서, 민감한 개인정보를 취급할 때 외부 클라우드 인프라로 문서를 전송하는 방식은 공격 표면을 넓히고 규제 준수(GDPR의 국경 간 데이터 이전 평가 또는 CCPA 준수 의무 등)를 복잡하게 만듭니다.

LadeStack 개발자 도구의 핵심 유틸리티인 LS PDF를 구축하면서, 우리는 문서 내용이 외부 서버로 전송되지 않는 클라이언트 사이드 기반의 문서 처리 파이프라인을 설계했습니다. 브라우저 내 Uint8Array 인메모리 버퍼 위에서 컴파일된 WebAssembly(Wasm) 엔진을 직접 구동함으로써, 모든 문서 변환 작업을 로컬 RAM에서 안전하게 완결합니다.

제로 업로드(Zero-Upload) 프라이버시 모델

민감한 문서를 다룰 때 가장 강력한 보안 보장은 시스템 아키텍처 자체에서 비롯됩니다. **“서버는 수신하지 않은 데이터를 유출할 수 없다”**는 대원칙입니다.

전통적인 클라우드 PDF 서비스:
[브라우저 파일 선택] ──(대용량 네트워크 업로드)──► [클라우드 서버 / DB] ──► [디스크 쓰기] ──► [변환 처리] ──► [결과 다운로드]

LADESTACK LS PDF (WASM 클라이언트 모드):
[브라우저 파일 선택] ──► [로컬 RAM 상의 ArrayBuffer] ──► [WASM 실행 엔진] ──► [즉각적인 로컬 다운로드]
                                     ▲
                                     └─── 문서 페이로드 네트워크 전송량: 0 바이트

파일을 로컬 환경에 유지함으로써 다음과 같은 핵심 이점이 주어집니다.

• 네트워크 전송 오버헤드 전무: 150 MB 대용량 문서라도 처리 시간은 온전히 로컬 CPU와 RAM 속도에만 좌우되며, 불안정한 모바일 회선 업로드 병목을 겪지 않습니다.
• 데이터 노출 위험의 원천적 차단: 문서 본문이 외부 엔드포인트나 클라우드 스토리지 버킷을 통과하지 않으므로 제3자 서버 저장소 위험이 제거됩니다 (다만 포괄적인 규제 준수를 위해서는 단말기 보안과 사내 거버넌스 정책이 함께 수반되어야 합니다).
• 오프라인 처리 지원: 웹 애플리케이션 번들과 WASM 모듈이 브라우저에 캐시되면(Service Worker 등), 활성 인터넷 연결이 없는 독립 환경에서도 신뢰성 있게 동작합니다.

인메모리 바이너리 제어: ArrayBuffer 파이프라인

최신 웹 브라우저는 표준 W3C FileReader 및 Blob API를 제공하여 로컬 파일을 순수 바이트 스트림으로 읽을 수 있도록 지원합니다. LS PDF는 타입화 배열(TypedArray)을 통해 이 인터페이스와 직접 연동합니다:

/**
 * 로컬 사용자 파일을 메모리 내 Uint8Array 바이트 배열로 로드
 */
export async function readFileAsBinary(file: File): Promise<Uint8Array> {
  const arrayBuffer = await file.arrayBuffer();
  return new Uint8Array(arrayBuffer);
}

바이트 배열이 메모리에 적재되면 공유 메모리 포인터를 통해 WebAssembly의 선형 메모리 경계로 직접 전달됩니다.

WebAssembly 메모리 마샬링(Marshaling)

브라우저 내에서 C++나 Rust 기반의 고성능 문서 파싱 루틴을 준네이티브 속도로 구동하기 위해, 자바스크립트 호스트 환경은 WebAssembly 인스턴스의 선형 메모리 공간에 버퍼를 할당합니다:

// WebAssembly 선형 메모리 공간 내 버퍼 할당
const fileData = await readFileAsBinary(uploadedFile);
const wasmMemory = wasmInstance.exports.memory as WebAssembly.Memory;

// WASM 내부 할당자로부터 메모리 포인터 요청
const ptr = wasmInstance.exports.allocate_buffer(fileData.length);
const memoryView = new Uint8Array(wasmMemory.buffer, ptr, fileData.length);

// 로컬 바이트 버퍼를 WASM 메모리 영역으로 복사
memoryView.set(fileData);

// 핵심 문서 변환 로직 실행 (병합, 회전, 페이지 재배치 등)
const resultPtr = wasmInstance.exports.process_pdf(ptr, fileData.length);

JSON이나 Base64 직렬화 오버헤드 없이 선형 메모리 오프셋을 직접 연산함으로써 밀리초 단위의 신속한 응답성을 확보합니다.

메모리 수명 관리와 OOM 방지 가드레일

브라우저 메모리에서 대용량 문서를 다룰 때는 엄격한 자원 생명주기 관리가 필수적입니다. 표준 32비트 WebAssembly(wasm32)는 32비트 선형 주소 공간에서 동작하므로 이론적 상한은 4 GB($2^{32}$ 바이트)입니다. 실제 브라우저 엔진(Chromium V8 등)은 탭 안정성을 보호하기 위해 단일 WebAssembly 인스턴스당 1 GB~2 GB 수준의 힙 할당 제한을 부여합니다. 할당된 메모리를 명시적으로 해제하지 않으면 연속 작업 시 Out-Of-Memory(OOM) 오류로 브라우저 탭이 강제 종료됩니다.

명시적 포인터 해제(Deallocation)

WebAssembly의 선형 메모리에는 자동 가비지 컬렉터가 적용되지 않습니다. 따라서 할당된 모든 버퍼는 처리가 끝난 후 자바스크립트 측에서 명시적으로 해제되어야 합니다:

try {
  const processedLength = wasmInstance.exports.get_result_length();
  const processedBytes = new Uint8Array(
    wasmMemory.buffer,
    resultPtr,
    processedLength
  ).slice(); // V8 관리 자바스크립트 힙으로 안전하게 복제

  return new Blob([processedBytes], { type: 'application/pdf' });
} finally {
  // WASM 힙 버퍼를 명시적으로 해제
  wasmInstance.exports.deallocate_buffer(ptr, fileData.length);
  wasmInstance.exports.deallocate_buffer(resultPtr, processedLength);
}

변환 결과를 표준 자바스크립트 Blob 객체로 복제한 즉시 WebAssembly 힙 버퍼를 반환함으로써 메모리 스파이크를 방지하고 안정성을 극대화합니다.

네트워크 전송 대기시간과 로컬 연산: 이론적 지연 시간 비교

클라이언트 사이드 문서 처리 아키텍처의 가장 핵심적인 이점은 네트워크 전송 단계의 완전한 배제입니다. 기존 클라우드 기반 워크플로우에서는 대용량 문서의 업로드 및 다운로드 과정에서 물리적인 네트워크 전송 지연이 필연적으로 발생합니다.

데이터 전송 지연 계산 모델

네트워크 전송 소요 시간은 데이터 통신의 표준 물리 공식에 따라 계산됩니다:

$\text{전송 지연 } (T) = \frac{\text{데이터 크기 } (L)}{\text{유효 대역폭 } (R)}$

가상의 15 Mbps 모바일 업링크 채널에서 45 MB(360 메가비트) 문서 병합 작업을 처리하는 경우:

$\text{업로드 전송 지연} = \frac{360\text{ Mb}}{15\text{ Mbps}} = 24.0\text{ 초}$

변환 완료 문서 크기를 약 11.25 MB(90 메가비트)로 가정하면 다운로드에 추가 $6.0\text{ 초}$가 소요되어, 원격 서버 대기열 지연을 제외하더라도 총 30.0초의 불가피한 네트워크 전송 지연이 발생합니다.

아키텍처 비교 분석

방법론적 설명: 클라우드 전송 수치는 데이터 크기와 채널 대역폭 간의 이론적 계산치($T = L / R$)입니다. 로컬 WebAssembly 연산의 실제 처리 속도는 기기의 CPU 아키텍처와 PDF 내부 객체 복잡도(벡터 그래픽, 폰트 임베딩 등)에 직접적으로 좌우되며, 네트워크 전송이 0초라는 구조적 사실 외에 인위적인 고정 처리 시간을 단정하지 않습니다.

LadeStack 개발자 도구 제품군 적용

이 프라이버시 중심 아키텍처는 LadeStack 문서 도구 전반에 적용되어 있습니다:

• LS PDF 병합기: 클라우드 저장소 없이 복수의 계약 문서를 단일 파일로 신속하게 병합.
• LS PDF 페이지 분할기: 원하는 페이지 범위를 추출하여 수 초 만에 로컬 저장.
• 클라이언트 압축: 내부 스트림 객체 재인코딩 및 불필요한 메타데이터 제거.

모든 프라이버시 우선 도구는 LadeStack 앱 디렉토리에서 경험하실 수 있으며, 보안 철학은 개인정보 처리방침에서 확인하실 수 있습니다.