온라인 PDF 도구, 내 파일은 어디로 갈까
최종 수정일: 2026-07-27
회사에서 PDF 한 장을 급하게 손봐야 할 때, 대부분은 검색창에 “PDF 이미지 삽입”이나 “PDF 합치기”를 칩니다. 결과 페이지에는 무료 도구가 수십 개 뜨고, 파일을 올리면 몇 초 만에 결과물이 나옵니다. 편리합니다. 다만 한 번쯤 짚고 넘어갈 질문이 있습니다. 방금 올린 그 파일은 지금 어디에 있을까요?
업로드형 도구가 실제로 하는 일
대다수의 온라인 PDF 도구는 서버에서 파일을 처리합니다. 순서는 대략 이렇습니다. 브라우저가 파일을 HTTP로 업로드하고, 서버는 그것을 디스크나 오브젝트 스토리지에 임시 파일로 저장합니다. 서버에서 도는 프로그램(고스트스크립트, qpdf, 상용 PDF 엔진 같은 것들)이 그 파일을 열어 작업을 수행하고, 결과물을 다시 저장한 뒤 다운로드 링크를 내려줍니다.
여기서 눈여겨볼 부분은 “임시”라는 단어가 생각보다 넓다는 점입니다. 원본 파일, 처리 중간 산출물, 최종 결과 파일이 각각 디스크에 남습니다. 그 디스크는 보통 자동 백업 대상입니다. 웹 서버 로그에는 파일명과 접속 IP, 시각이 기록됩니다. 다운로드 링크가 CDN을 거친다면 엣지 캐시에도 사본이 생길 수 있습니다. 파일 하나를 올렸을 때 실제로 만들어지는 사본은 결코 하나가 아닙니다.
“1시간 후 자동 삭제”는 어디까지 믿을 수 있나
많은 서비스가 “업로드된 파일은 1시간 뒤 영구 삭제됩니다”라고 안내합니다. 대부분은 실제로 그렇게 운영하고 있을 겁니다. 문제는 이용자 입장에서 그것을 확인할 방법이 전혀 없다는 점입니다. 삭제 작업이 정말 돌았는지, 백업 스냅샷에서도 지워졌는지, 로그에서 파일명이 사라졌는지는 전부 서버 안쪽 일이라 밖에서 볼 수 없습니다. 그 문장은 기술적 보장이 아니라 약속입니다. 약속을 지키는 회사도 많지만, 지켰다는 사실을 증명해 보이지는 못합니다.
그리고 삭제되기 전 그 한 시간 동안 파일은 분명히 존재합니다. 그 사이에 서버가 침해당하면 파일도 함께 노출됩니다. 수사기관의 적법한 자료 제출 요구가 들어오면 제출 대상이 됩니다. 운영사가 어느 나라에 법인을 두고 있는지에 따라 적용되는 법도 달라집니다. 개인 영수증이라면 대수롭지 않겠지만, 미공개 계약서나 인사 자료라면 얘기가 다릅니다.
브라우저 안에서 끝나는 방식
다른 방식도 있습니다. PDF를 다루는 코드 자체를 자바스크립트나 WebAssembly로 만들어 브라우저에 내려보내고, 파일 처리는 전부 이용자 기기에서 하는 구조입니다. 이 경우 서버가 보내는 것은 프로그램 코드뿐이고, 파일은 한 번도 네트워크를 타지 않습니다. 서버에 저장될 파일이 애초에 없으니 보관 기간 정책도, 삭제 약속도 필요하지 않습니다.
어떤 방식인지 직접 확인하는 세 가지 방법
중요한 건 서비스의 설명을 믿는 게 아니라 직접 확인하는 겁니다. 세 가지 방법이 있습니다.
1. 개발자 도구 네트워크 탭. 도구 페이지에서 F12(맥은 Cmd+Option+I)를 눌러 개발자 도구를 열고 Network 탭으로 갑니다. 그 상태에서 PDF를 열고 작업을 실행해 보세요. 서버 전송형이라면 파일 크기에 맞먹는 요청, 즉 수 MB짜리 POST 요청이 목록에 나타납니다. Fetch/XHR 필터를 켜면 더 잘 보입니다. 브라우저 처리형이라면 처음 페이지와 스크립트를 받아온 뒤로는 파일과 관련된 요청이 거의 올라가지 않습니다.
2. 인터넷을 끊고 써 보기. 가장 직관적인 방법입니다. 페이지를 완전히 불러온 다음 Wi-Fi를 끄거나 개발자 도구 Network 탭의 Offline 옵션을 켭니다. 그 상태에서 PDF를 열고 이미지를 얹고 결과 파일을 저장하는 것까지 정상적으로 된다면, 처리 코드가 이미 브라우저 안에 들어와 있다는 뜻입니다. 서버로 보내야 하는 구조라면 이 시점에서 작업이 멈춥니다.
3. 개인정보처리방침 읽기. 지루하지만 5분이면 됩니다. 업로드한 파일의 보관 기간, 제3자 제공, 해외 이전 항목을 봅니다. 브라우저 처리 방식이라면 대개 파일을 수집하지 않는다는 문장이 명시되어 있습니다.
참고로 StickPDF는 pdf-lib와 pdf.js를 브라우저에서 돌려 이미지를 얹은 PDF를 만드는 방식이라, 위 세 가지 방법 중 어느 것으로 확인해도 파일이 나가지 않는 것을 보실 수 있습니다. 믿어달라는 말보다 직접 확인해 보시는 편이 낫습니다.
서버 처리가 나쁘다는 얘기는 아닙니다
오해를 피하기 위해 덧붙이면, 서버 처리 자체가 문제인 건 아닙니다. 스캔본 OCR처럼 큰 인식 모델이 필요한 작업, 수백 개 문서를 한꺼번에 돌리는 배치 작업, 폰트 하위집합을 다시 구성하는 정교한 변환, 사내 결재 시스템과의 연동은 서버에서 하는 편이 합리적이거나 아예 서버가 아니면 불가능합니다. 브라우저는 메모리 한계도 있어서 수백 MB짜리 문서는 버겁습니다.
핵심 질문은 “서버냐 아니냐”가 아니라 “내가 지금 다루는 문서의 민감도에 이 방식이 맞느냐”입니다. 공개 자료라면 어느 쪽이든 상관없습니다. 하지만 서명 전 계약서, 인사·급여 자료, 신분증 사본, 미공개 재무 자료라면 기기 밖으로 나가지 않는 쪽이 확실히 낫습니다. 회사에 따라서는 외부 웹 서비스에 사내 문서를 올리는 것 자체가 보안 규정 위반인 경우도 많으니, 사내 규정을 먼저 확인하시는 것이 좋습니다.
부득이하게 서버 방식을 써야 한다면 최소한 사업자 정보와 소재지가 명확한지, 데이터 처리 위탁 계약을 맺을 수 있는 곳인지, 보안 인증이나 처리 방침이 구체적으로 공개되어 있는지를 확인하세요. 결론은 단순합니다. 도구를 고르기 전에 30초만 들여 어디서 처리되는지 확인하는 습관이면 충분합니다.