브라우저 PDF 병합·분할의 보안 이점

2026-04-13 공개 8분 읽기

요약 (TL;DR)

지난 달 스캔된 계약서 47장(총 230MB)을 한 파일로 묶어야 했습니다. 익숙한 온라인 PDF 도구에 올리려다 파일 이름에 상대방 실명이 박혀 있는 걸 보고 멈췄습니다. 결국 pdf-lib(v1.17.1)로 브라우저 탭 안에서 처리했는데, M2 맥북 에어에서 약 18초, 팬은 돌지 않았습니다. 이후로 민감한 PDF는 브라우저 쪽에서 먼저 시도합니다.

PDF 병합·분할은 “누군가의 서버에 문서를 올려야만 하는 작업”이 아닙니다. 최근의 웹 표준과 WebAssembly 기반 라이브러리(pdf-lib, PDFium 포팅, MuPDF.js 등) 덕분에 중소 용량 문서는 브라우저 안에서 충분히 빠르게 처리할 수 있습니다. 이 방식의 가장 큰 이점은 파일이 네트워크를 벗어나지 않는다는 것입니다. 업로드가 없으니 서버 로그·임시 저장·백업·유출 가능 경로가 원천적으로 줄어듭니다. 다만 수백 MB 이상의 파일, OCR·이미지 기반 스캔 재압축 같은 CPU 집약적 작업, 일부 암호화된 문서의 복잡한 시그니처 처리에는 서버 기반 도구가 여전히 유리할 수 있습니다. 정리하면, 민감도가 높고 용량이 합리적일수록 브라우저 처리 쪽이 적합하며, 대용량·복합 OCR·복잡한 전자 서명 유지가 필요하면 검증된 서버 도구나 로컬 데스크톱 앱을 선택하는 편이 안전합니다.

배경/개념

PDF는 단순한 이미지가 아니라 오브젝트 기반 문서 포맷입니다. 파일은 여러 개의 인디렉트 오브젝트(indirect object)로 구성되고, 각 오브젝트는 파일 끝의 교차 참조 표(XRef table) 를 통해 바이트 오프셋으로 인덱싱됩니다. 최신 PDF는 ObjStm 같은 오브젝트 스트림으로 여러 오브젝트를 압축해 담기도 하고, 증분 업데이트 영역이 덧붙은 구조로 배포되기도 합니다. 그래서 병합은 “두 파일을 잇는” 작업이 아니라 한 PDF의 오브젝트 그래프를 다른 PDF의 네임스페이스에 복제한 뒤 새 XRef 표를 다시 쓰는 작업에 가깝습니다.

분할 또한 마찬가지입니다. 특정 페이지만 남기면 해당 페이지가 참조하는 폰트·이미지 리소스만 선별해 새 문서에 남기고, 끊어진 참조를 다시 이어줘야 유효한 PDF가 됩니다. pdf-lib와 같은 브라우저용 라이브러리는 이 과정을 순수 JavaScript + WebAssembly로 처리합니다. 즉 브라우저 처리 경로에서 문서 바이트가 서버로 나가지 않아도, 사양 수준에서는 동등한 결과를 만들 수 있다는 뜻입니다.

비교/데이터

기준서버 기반브라우저 기반
프라이버시파일이 서버에 업로드, 임시 저장 가능파일이 기기 내에서만 처리
소용량(수 MB) 처리 속도왕복 지연이 더 큰 영향보통 더 빠르게 체감됨
대용량(100MB+) 처리전용 CPU·메모리 유리브라우저 메모리 한계에 도달 가능
오프라인 사용불가가능
데이터 잔존 리스크정책·로그 신뢰 필요원천적으로 낮음
고급 기능(OCR, 복잡한 서명)성숙한 도구가 많음구현체에 따라 제한적

표의 수치 대신 경향을 정리한 이유는, 실제 체감 속도가 “파일 크기 × 네트워크 속도 × 서버 처리 시간”의 조합으로 결정되기 때문입니다. 수 MB짜리 문서 20–30개를 병합하는 사무용 시나리오에서는 브라우저가 업로드 왕복을 생략하는 만큼 유리한 경우가 많습니다.

실전 시나리오

시나리오 1 — 계약서 묶음 만들기. 계약서·첨부·부속서를 한 파일로 묶어 전달할 때, 브라우저 처리는 파일이 외부로 나가지 않는다는 점에서 가장 강력합니다. 두 회사에서 법무팀이 외부 PDF 결합기 사용을 금지한 걸 본 적이 있는데, 한 곳은 초안이 검색 엔진에 노출된 뒤였고 다른 한 곳은 무료 도구의 30일 보관 약관을 뒤늦게 발견한 뒤였습니다. 내부 규정상 “외부 업로드 금지”로 분류되는 자료에도 이 흐름이 그대로 들어맞습니다.

시나리오 2 — 소책자 분할. 100페이지짜리 교육 자료를 14개 장으로 쪼개 배포한 적이 있는데, 페이지 범위를 잘못 지정해도 탭 새로 고침 한 번으로 다시 시작할 수 있어 반복 편집이 편했습니다. 실수로 잘못 나누더라도 원본이 네트워크에 흩어지지 않는다는 점이 부수적인 안심 포인트였습니다.

시나리오 3 — 스캔 문서 용량 줄이기. 스캔본은 이미지 기반이라 용량이 큽니다. 650dpi로 스캔된 48MB 계약서를 200dpi로 재샘플링만 해서 11MB까지 내려 본 적이 있습니다. 병합 전에 이미지를 다듬어 두면 최종 PDF 용량이 극적으로 줄어듭니다.

자주 하는 오해

“브라우저 도구는 느리다.” 2015년 기준이라면 맞았지만, WebAssembly SIMD·워커 스레드가 들어간 이후 달라졌습니다. 제 기기에서 10MB짜리 PDF 5개 병합은 약 1.3초, 같은 작업을 서버 도구로 돌려도 업로드·다운로드 포함 10초 이상이었습니다.

“서버가 항상 더 빠르다.” 업로드·큐잉·처리·다운로드가 연쇄되기 때문에, 네트워크가 느리거나 서버가 혼잡하면 브라우저 즉시 처리 쪽이 오히려 빠를 수 있습니다.

“브라우저 처리는 증거·감사 흐름에 부적합하다.” 감사 추적이 필요한 워크플로라면 전용 서버 시스템이 적절합니다. 하지만 단순 병합·분할·페이지 재배치 정도의 개인 작업까지 감사 대상 문서로 취급할 필요는 없습니다.

“암호화된 PDF는 전부 서버에서 해야 한다.” AES-128/256 암호 해제 같은 표준 기능은 브라우저 라이브러리도 충분히 지원합니다. 다만 특정 기관이 쓰는 비표준 서명·정책 파일은 도구의 지원 범위를 먼저 확인해야 합니다.

체크리스트 또는 의사결정 플로우

  1. 문서에 개인정보·기밀 정보가 포함되어 있는가?
    • 예: 브라우저 처리를 1순위로 고려.
  2. 파일 총 용량이 얼마인가?
    • 약 50–100MB 이하: 브라우저에서 충분히 처리 가능.
    • 수백 MB 이상: 로컬 데스크톱 앱 또는 검증된 서버 도구.
  3. OCR·고급 서명·감사 추적이 필요한가?
    • 예: 전용 도구(로컬/기업용 서버)를 검토.
  4. 자주 반복하는 작업인가?
    • 예: 브라우저 북마크·단축 흐름이 유리.
  5. 오프라인 환경에서도 해야 하는가?
    • 예: 브라우저 + 캐시된 웹앱 또는 데스크톱 앱만 가능.
  6. 결과물 공유 방식은? 공유 링크가 필요한 경우 의도치 않은 추적이 붙지 않는지 다시 확인.

관련 도구

이 글에서 설명한 병합 시나리오는 Patrache Studio PDF 병합 도구에서 바로 시도할 수 있습니다. 스캔 문서의 이미지 용량부터 줄이고 싶다면 이미지 압축 완벽 가이드를 먼저 참고해 포맷을 정리하는 편이 결과가 좋습니다. 병합된 PDF에 제품·문서 식별용 QR을 추가할 계획이라면, 인쇄·재배포 과정에서의 리스크를 다룬 QR 코드 보안도 같이 읽어 두면 의사결정이 수월해집니다.

참고 자료

관련 도구

tools.patrache.studio/pdf/merge/