클라이언트 사이드 PDF 처리는 어떻게 작동하나요 (브라우저 내, 업로드 없음)
업데이트 2026년 7월 13일
“브라우저에서 실행됩니다”는 거의 모든 PDF 사이트가 하단 어딘가에 적어두는 문구입니다. 하지만 그중 대부분은 여전히 내 파일을 업로드합니다. 이 주장이 사실이려면 실제로 무엇이 갖춰져야 하는지, 그리고 1분 안에 직접 확인하는 방법을 알려드립니다.
이것을 가능하게 하는 아키텍처: 웹어셈블리
페이지 병합, 이미지 재인코딩, 암호화된 스트림 재작성 같은 진짜 PDF 조작 작업은 네이티브 앱이 사용하는 것과 동일한 저수준 라이브러리를 필요로 합니다. 브라우저는 C/C++/Rust를 직접 실행할 수 없지만, **웹어셈블리(WASM)**는 실행할 수 있습니다 — 이런 라이브러리들을 브라우저가 거의 네이티브 속도로 실행하는 바이너리 형식으로 컴파일한 것입니다.
이것이 바로 클라이언트 사이드 도구와, 사실은 좀 더 세련된 업로드 양식일 뿐인 “브라우저 기반” 도구의 차이입니다. 드래그 앤 드롭 상자와 진행률 표시줄이 있는 페이지라도, 파일을 놓는 순간 조용히 서버로 POST 요청을 보낼 수 있습니다. UI뿐 아니라 실제 처리 자체가 로컬에서 이루어지게 만드는 것이 바로 WASM입니다.
메인 스레드가 아니라 웹 워커에서 실행하는 이유
100페이지짜리 PDF를 디코딩하고 다시 쓰는 것은 실제로 상당한 CPU 작업입니다. 브라우저의 메인 스레드에서 이 작업을 하면 페이지가 멈춰버립니다 — 스크롤도, 클릭도 안 되고, 파일이 조금만 커도 “탭이 응답하지 않습니다” 경고가 뜹니다. 웹 워커는 이 작업을 백그라운드 스레드에서 실행해, 인터페이스는 계속 반응하고 멈춘 탭 대신 실시간 진행률 표시줄을 보여줍니다. 파일의 바이트 데이터가 메모리로 읽혀 워커로 전달되고, 처리된 뒤 다시 돌아옵니다 — 이 모든 것이 내 브라우저 프로세스 안에서 일어납니다. 이 흐름 어디에도 서버가 필요하거나 도움이 되는 부분은 없습니다.
“업로드 없음”이 실제로 배제하는 것
도구가 진짜로 클라이언트 사이드라면 세 가지가 따라오고, 이 세 가지는 모두 확인 가능합니다.
- 업로드 엔드포인트가 없습니다. 도구가 호출할
/api/upload같은 것이 존재하지 않습니다 — 호출할 상대가 애초에 없기 때문입니다. - 파일 크기와 연결 속도에 좌우되는 처리 지연이 없습니다. 느린 연결로 200MB 파일을 업로드하면 시간이 걸리지만, 클라이언트 사이드 도구는 같은 파일이라도 내 기기의 CPU 성능에만 좌우되며 즉시 시작됩니다.
- 오프라인에서 작동합니다. 페이지가 한 번 로드되고 나면(PWA의 경우 서비스 워커에 캐시된 후), 도구는 인터넷 연결이 전혀 없어도 계속 작동합니다 — 애초에 작업을 위해 연결이 필요하지 않았기 때문입니다.
직접 확인하는 방법
개인정보 보호 주장을 그냥 믿을 필요는 없습니다.
- 도구를 실행하기 전에 개발자 도구를 열어 네트워크 탭으로 이동한 다음 파일을 처리해 보세요. 페이로드 크기가 내 파일 크기와 비례하는 요청이 있는지 지켜보세요. 그런 것이 보이지 않는다면 파일은 브라우저를 벗어나지 않은 것입니다.
- (페이지 자체가 로드된 후에) 인터넷 연결을 끊고 도구를 다시 시도해 보세요. 그래도 작동한다면 중간에 서버가 관여하지 않는 것입니다.
- 주장뿐 아니라 페이지 용량도 확인하세요. 실제로 로컬에서 무거운 작업을 하는 도구는 WASM 엔진을 로드합니다 — 흔히 해당 도구를 처음 사용할 때 수백 KB에서 수 MB에 이르는 지연 로딩 청크가 붙습니다 — 단순히 양식을 전송하는 작은 스크립트가 아닙니다.
이것이 바로 HivePDF가 만들어진 방식입니다. 병합, 압축, 보호, 편집 제거, 서명을 비롯한 모든 도구가 웹 워커 안의 작업별 WASM 엔진을 통해 실행되며, 그 뒤에는 업로드 엔드포인트가 전혀 없습니다. 이것이 실제로 어떤 의미인지 더 깊이 알아보려면 온라인 PDF 도구는 안전한가요와, 서버 기반 도구와의 솔직한 아키텍처 비교를 참고하세요.