무엇을 테스트했고, 무엇을 테스트하지 않았나요?
이 웹사이트의 PDF 압축기에서 사용하는 것과 동일한 압축 코드를 변경 없이 테스트했습니다. 다만 측정할 때는 브라우저에서 실행하지 않고 Node.js에서 직접 호출했습니다. 이렇게 하면 각 실행의 입력 파일, 설정, 저장된 결과를 정확히 기록할 수 있습니다.
- 압축 모듈: WebAssembly로 제공되는 QPDF 12.2.0, 래퍼 버전 0.3.0. 래퍼 빌드 스크립트에서 QPDF 12.2.0을 지정하고 있으며, 설치된 모듈에 버전을 조회해도 12.2.0으로 표시됩니다.
- 환경: Windows 11, 빌드 26200, x64에서 실행한 Node.js 24.18.1.
- 범위: 인위적으로 생성한 입력 파일 세 개, 아홉 차례의 압축 실행, 거부되어야 하는 서명 자리표시자 포함 테스트 파일 한 개.
- 사후 검증: 저장된 PDF 열두 개, 총 24페이지에 대해 각각 구조 검사와 렌더링된 페이지 확인을 진행했습니다.
이번 측정에 포함되지 않은 항목은 다음과 같습니다.
- 처리 시간. 시간은 측정하지 않았습니다.
- 개별 브라우저 또는 실제 스마트폰과 태블릿에서의 동작.
- 실제 사진, 스캔, 대용량 파일 또는 사용자 문서.
- 다른 압축 프로그램이나 온라인 서비스.
- 사용자 파일에서 기대할 수 있는 평균 절감량.
테스트 파일, 설정 및 다운로드
테스트에는 직접 생성한 PDF만 사용했습니다. 고객 문서, 실제로 촬영한 사진, 실제 인물의 서명은 포함하지 않았습니다. 이미지 파일에 들어 있는 이미지 역시 생성한 것으로, 그라데이션이 있는 질감을 표현하며 사진이나 스캔이 아닙니다.
- 텍스트 파일, 3,029바이트: 텍스트, 값이 입력된 양식 필드, 링크, 페이지 회전, 구조 트리의 표시가 포함된 두 페이지입니다.
- 이미지 파일, 1,359,079바이트: 동일한 구성 요소에 640 × 800픽셀의 생성 이미지가 추가되어 있습니다. 이미지가 없는 텍스트 파일은 3,029바이트에 불과하므로, 이 파일 크기의 대부분은 이미지가 차지합니다.
- 이미 최적화된 텍스트 파일, 2,721바이트: 더 이상 크기를 줄일 수 없는 사례로 사용합니다.
- 서명 자리표시자가 있는 파일, 3,139바이트: 서명 구조만 포함되어 있으며 실제 디지털 서명은 없습니다. 압축기가 서명된 파일을 거부하는지 확인하는 데 사용합니다.
모든 실행의 시작 조건을 동일하게 유지
- 각 실행은 변경하지 않은 원본 바이트에서 시작합니다. 한 번의 실행에서 여러 차례 시도해야 하는 경우에도, 이후의 각 시도는 이전 결과가 아닌 원본에서 다시 시작합니다.
- 모든 결과에는 두 페이지 전체가 포함되어 있습니다. 페이지를 삭제하거나, ZIP으로 묶거나, 이미지의 픽셀 수를 줄이거나, 페이지 전체를 이미지로 변환하지 않았습니다. 그래야 모드별 바이트 수를 서로 비교할 수 있습니다.
- 각 결과는 별도의 파일 이름으로 저장했습니다. 입력 파일과 출력 파일의 바이트 수 및 SHA-256 체크섬을 기록했습니다. 체크섬은 파일의 지문과 같습니다. 단 한 바이트만 바뀌어도 체크섬이 바뀝니다.
- 각 실행의 모드, 해당하는 경우 목표 크기, 실제 사용한 JPEG 품질을 기록했습니다.
세 가지 모드의 기술적 동작
기록과 표에서는 모드 이름을 lossless, balanced, small로 표시합니다. 도구에서는 다음 이름으로 찾을 수 있습니다. lossless는 무손실 최적화, balanced는 균형, small은 더 작은 파일입니다. 무손실 최적화는 파일의 구조, 즉 객체와 압축된 데이터 스트림만 최적화합니다. 균형은 이에 더해 적합한 이미지를 품질 수준 80의 JPEG로 다시 인코딩합니다. 목표 크기에 도달하지 못하면 70으로 시도합니다. 더 작은 파일은 수준 65에서 시작하며, 목표에 도달하지 못하면 50, 그다음 40으로 낮춥니다. 목표 크기를 지정했고 원본이나 구조를 최적화한 버전이 이미 그 목표를 충족한다면, 손실이 발생하는 JPEG 인코딩을 시도할 필요가 없습니다. 마지막에는 검사한 버전 중 가장 작은 버전을 채택합니다. 원본보다 작은 버전이 없으면 원본을 유지합니다. 따라서 특정한 절감량을 보장하지는 않습니다.
QPDF 12.2 문서에 따르면, 이 과정에서 QPDF는 이미지 해상도를 낮추지 않습니다. 다만 JPEG로 다시 인코딩하면 눈에 보이는 압축 흔적이 생길 수 있으며, QPDF는 다시 인코딩한 이미지 데이터가 더 작을 때만 이를 채택합니다. 이것이 이미지 품질에 어떤 의미인지 품질 손실 없이 PDF 압축하기 안내에서 설명합니다.
직접 확인할 수 있는 파일과 체크섬
아래 표에는 모든 테스트 파일과 결과 파일의 링크가 있습니다. 다운로드한 뒤 원하는 체크섬 도구로 SHA-256 체크섬을 비교하세요. 일치하면 측정에 사용한 바로 그 파일입니다. 영어로 작성된 기록 파일 reproducibility-manifest.json에는 모든 실행의 정확한 호출 내용과 설정이 들어 있습니다.
결과: 파일 크기를 있는 그대로 공개
2026년 10월 13일 측정 실행 결과 차트
이 차트는 Windows 11의 Node.js에서 QPDF 12.2.0 (WASM)으로 수행한 측정의 아홉 차례 실행 결과를 모두 보여줍니다. 테스트 파일이나 방식으로 필터링하고, 정확한 바이트 수와 백분율로 표시한 남은 크기 사이를 전환하세요.
9회 실행 중 9회 표시
텍스트 · 무손실
크기 감소
- 원본
- 3,029 바이트 · 100 %
- 결과
- 2,721 바이트 · 89.83 %
- 지정된 한도
- 지정된 한도 없음
이미지 · 무손실
크기 감소
- 원본
- 1,359,079 바이트 · 100 %
- 결과
- 1,358,764 바이트 · 99.98 %
- 지정된 한도
- 지정된 한도 없음
이미지 · 균형
크기 감소
- 원본
- 1,359,079 바이트 · 100 %
- 결과
- 179,708 바이트 · 13.22 %
- 지정된 한도
- 지정된 한도 없음
이미지 · 균형, 반복 실행
크기는 같고 체크섬은 다름
- 원본
- 1,359,079 바이트 · 100 %
- 결과
- 179,708 바이트 · 13.22 %
- 지정된 한도
- 지정된 한도 없음
이미지 · 강력
크기 감소
- 원본
- 1,359,079 바이트 · 100 %
- 결과
- 125,710 바이트 · 9.25 %
- 지정된 한도
- 지정된 한도 없음
이미지 · 강력
목표 달성
- 원본
- 1,359,079 바이트 · 100 %
- 결과
- 125,710 바이트 · 9.25 %
- 지정된 한도
- 250,000 바이트
이미지 · 강력
목표 미달성, 완전한 PDF 제공
- 원본
- 1,359,079 바이트 · 100 %
- 결과
- 74,707 바이트 · 5.5 %
- 지정된 한도
- 128 바이트
이미지 · 강력
이미 목표 충족
- 원본
- 1,359,079 바이트 · 100 %
- 결과
- 1,358,764 바이트 · 99.98 %
- 지정된 한도
- 1,359,079 바이트
이미 최적화된 텍스트 · 무손실
원본을 변경 없이 보관
- 원본
- 2,721 바이트 · 100 %
- 결과
- 2,721 바이트 · 100 %
- 지정된 한도
- 지정된 한도 없음
변경 없음 – 원본 유지
과거 측정 결과이며, 브라우저, 휴대전화, 현재 버전 또는 다른 도구에 대해서는 아무것도 입증하지 않습니다. 백분율은 절감량이 아닌 남은 크기를 나타냅니다. 입력된 한도는 수치상의 목표이며 달성을 보장하지 않습니다. 아래 표에는 필터와 관계없이 아홉 차례 실행 결과가 모두 포함되어 있습니다.
이 테스트로 사용자 PDF의 크기가 얼마나 줄어들지 예측할 수는 없습니다. 파일에 어떤 내용이 들어 있는지에 따라 달라집니다. 테스트 파일 세 개만으로도 차이가 드러납니다. 작은 텍스트 파일은 lossless 모드에서 10.17퍼센트 줄었지만, 이미지 파일은 같은 모드에서 0.02퍼센트만 줄었습니다. 이미지 파일은 JPEG로 다시 인코딩한 뒤에야 86.78퍼센트의 절감 효과를 얻었습니다. 표에는 유의미한 절감 효과가 없었던 실행까지 아홉 차례의 실행을 모두 담았습니다.
절감량은 항상 실제 바이트 수를 기준으로 계산합니다. 줄어든 바이트 수를 원본 크기로 나눕니다. balanced 실행에서는 1,359,079바이트 중 1,179,371바이트가 줄었으므로 86.78퍼센트입니다. 사용자 파일의 절감량은 압축률 계산기로 계산할 수 있습니다.
JPEG 품질은 크기 감소율이 아닙니다
80, 65, 40 같은 값은 JPEG 인코더의 설정이며, 크기가 몇 퍼센트 줄어드는지를 나타내지 않습니다. 여기서는 품질 수준 80에서 86.78퍼센트, 수준 65에서는 90.75퍼센트가 줄었습니다. 다른 파일에서는 같은 수준을 사용해도 결과가 크게 달라질 수 있습니다.
절감 효과가 없는 사례도 포함한 이유
최고의 절감 효과만 보여 주는 테스트는 중요한 사례를 빠뜨립니다. 더 이상 크기를 줄일 수 없으면 어떻게 될까요? 이미 최적화된 2,721바이트의 텍스트 파일에서는 lossless 모드로 더 작은 버전을 만들지 못했습니다. 따라서 압축기는 원본을 유지했습니다. 출력은 2,721바이트, 절감량은 0바이트이며, 입력 파일과 출력 파일의 SHA-256 체크섬도 같습니다. 이를 통해 이런 경우에는 아무 이득 없이 다시 작성된 파일을 받게 되지 않는다는 점을 실제 압축 모듈로 확인했습니다. 이때 취할 수 있는 방법은 PDF 크기가 줄어들지 않음 안내에서 확인할 수 있습니다.
목표 크기 달성, 미달 또는 이미 충족한 경우
- 목표 250,000바이트: 수준 65로 실행한 첫 시도에서 이미 125,710바이트가 나왔습니다. 이로써 목표를 달성했으며, 결과는 목표를 지정하지 않은 실행과 바이트 단위까지 완전히 같습니다.
- 목표 128바이트: 이미지가 포함된 두 페이지에 적용하기에는 비현실적으로 작은 크기입니다. 마지막 수준인 40에서도 74,707바이트까지만 줄었습니다. 압축기는 목표 미달을 알리지만 파일은 제공합니다. 이 테스트 파일의 경우 저장된 74,707바이트 결과 파일에 두 페이지가 모두 포함되어 있었으며, 아래에 설명한 기능 검증도 통과했습니다. 이 과정에서 이미지 데이터는 손실 방식으로 다시 인코딩되었습니다. 이 실행이 다른 모든 파일에서도 모든 콘텐츠가 유지된다는 사실을 입증하지는 않습니다.
- 목표 1,359,079바이트, 즉 원본 크기와 정확히 같은 경우: 목표를 이미 충족한 것으로 판단했습니다. 구조에 대한 무손실 최적화만 실행했습니다. 결과는 1,358,764바이트로, lossless 실행과 같은 크기였습니다. 이미지는 JPEG로 다시 인코딩하지 않았으며, 기록된 호출 내용에도 JPEG 설정이 없습니다.
크기는 같고 체크섬은 다름
balanced 실행을 반복했을 때 다시 정확히 179,708바이트가 나왔지만 SHA-256 체크섬은 달랐습니다. 목표가 이미 충족된 실행 역시 lossless 실행과 크기는 같지만 별도의 체크섬을 갖습니다. 가능한 이유 중 하나는 PDF를 기록할 때 새 문서 식별자 등이 생성될 수 있다는 점입니다. 반면 목표를 지정하지 않은 small 실행과 목표를 250,000바이트로 지정한 실행은 바이트 단위까지 완전히 같았습니다. 따라서 체크섬은 저장된 특정 파일을 식별합니다. 브라우저를 포함해 실행을 반복하면 크기가 같더라도 반드시 바이트 단위까지 동일한 파일을 얻는 것은 아닙니다.
화면 표시와 기능을 별도로 검증
파일이 작아졌다는 사실만으로 텍스트, 양식, 링크가 보존되었는지는 알 수 없습니다. 미리보기가 잘 보인다고 해서 입증되는 것도 아닙니다. 따라서 저장된 파일을 서로 독립적인 라이브러리 두 개로 검사했습니다. pdf-lib는 저장된 내부 구조를 읽고, PDF.js 6.4.299는 페이지를 렌더링하고 텍스트와 주석을 읽어 냅니다. 이를 위해 PDF.js는 격리된 Chromium 버전 151.0.7922.34 인스턴스에서 실행했습니다. 완성된 파일에 대한 이 검증은 Windows 11의 Node.js에서 측정한 압축과는 별개입니다. 브라우저나 모바일 기기에서의 압축은 측정하지 않았으며, 이 검증으로 다른 PDF 프로그램의 동작을 알 수는 없습니다. 각 검증에는 고유한 방법이 있으며, 결과는 이 테스트 파일에만 적용됩니다.
양식 필드에 관한 세부 사항이 있습니다. 해당 값은 PDF.js의 일반 텍스트 추출에서 안정적으로 나타나지 않아 주석을 통해 읽었습니다. 따라서 압축된 PDF에서 입력한 양식 값을 검색해 찾지 못하더라도, 그 값이 없다는 뜻은 아닙니다.
balanced와 small에서는 이미지를 손실 방식의 JPEG로 다시 인코딩했습니다. 단, 처리 전부터 목표가 충족된 small 실행은 예외입니다. 이 과정에서 텍스트와 선에 대한 디코딩된 콘텐츠 명령은 그대로였지만, 질감 이미지의 데이터는 달라졌습니다. 이미지 파일에서 나온 결과를 페이지로 렌더링했을 때, 이미지의 위치와 차지하는 범위, 페이지 회전은 원본과 같았습니다. 직접 파일을 살펴볼 때 알아둘 점이 있습니다. 생성 이미지는 원본에서부터 여러 줄의 텍스트 위에 놓여 있습니다. 이러한 겹침은 테스트 파일의 일부이며 압축으로 생긴 손상이 아닙니다. 결과에도 그대로 유지됩니다. 이것만으로 모든 줄의 가독성을 판단하거나 품질 점수를 매길 수는 없습니다. 또한 질감과 그라데이션이 있는 생성 이미지만으로는 사진, 스캔 또는 스캔의 작은 글씨에 동일한 품질 수준을 적용했을 때 어떤 결과가 나올지 알기 어렵습니다. 관련 내용은 스캔 PDF 크기 줄이기 안내를 참고하세요.
서명 자리표시자로 확인한 것은 압축기가 서명 구조가 있는 파일을 인식하고 처리하지 않는다는 점뿐입니다. 압축 코드에 따르면 암호화된 파일과 인증된 파일도 거부합니다. 이 테스트는 실제 서명의 유효성을 확인하지 않으며, 보호 기능을 우회하지도 않습니다. 자세한 내용은 서명과 양식이 있는 PDF 압축하기 안내에서 확인할 수 있습니다.
한계와 직접 검증하는 방법
이 도구는 PDF24나 Adobe보다 좋은가요?
이 페이지는 그 질문에 답하지 않습니다. 동일한 파일을 다른 프로그램이나 온라인 서비스로 처리하지 않았습니다. 따라서 품질, 속도 또는 가격을 비교해 판단할 근거가 없습니다. 백분율이나 슬라이더를 보여 주는 순위 목록도 이러한 비교를 대신하지 못합니다. 공정하게 비교하려면 동일한 전체 입력 파일과 동일한 페이지를 사용하고, 설정과 정확한 바이트 수를 기록하며, 모든 결과에 동일한 기능 검증을 적용해야 합니다.
자신의 PDF를 검증하는 방법
- 변경하지 않은 원본 사본을 보관하세요.
- PDF 압축기를 열고 파일을 선택하세요. 이미지의 세부 표현이 중요하다면 무손실 모드부터 시작하세요.
- 파일 속성 등에서 원본과 결과의 정확한 바이트 크기를 확인해 기록하고, 압축률 계산기로 절감량을 계산하세요.
- 추가로 시도할 때마다 이미 압축한 결과가 아닌 원본으로 다시 시작하세요. 기존 파일을 덮어쓰지 않도록 각 결과를 새로운 파일 이름으로 저장하세요.
- 저장한 파일을 수신자도 사용하는 프로그램에서 여세요. 모든 페이지를 확인하고, 알고 있는 단어를 검색하고, 양식에 입력된 값과 링크를 점검한 다음 이미지와 작은 글씨를 원본 크기로 살펴보세요.
- PDF에 디지털 서명이 있거나 암호화 또는 인증되어 있다면 이 도구로 압축하지 말고 발급자와 처리 절차를 확인하세요.