PDF 크기 분석기의 '페이지별 크기', 사실은 용량이 아니다
"이 PDF의 어느 페이지가 용량을 많이 차지하는지 알고 싶다"는 요청은 자연스러워 보입니다. 그런데 이 질문에 정확한 숫자로 답하는 것이 PDF 파일 형식 자체의 구조 때문에 원천적으로 어렵다는 사실은 잘 알려져 있지 않습니다. PDF 크기 분석기가 "페이지별 크기" 항목에서 실제로 무엇을 보여주는지, 그리고 왜 바이트 단위 용량을 보여줄 수 없는지 구조적인 이유부터 짚어봅니다.
1. PDF 페이지는 독립된 파일 조각이 아니다
JPG나 PNG처럼 페이지마다 완전히 독립된 이미지 파일이라면 "이 페이지가 몇 KB"라는 질문에 답은 간단합니다. 하지만 PDF는 그렇게 설계되지 않았습니다. PDF 내부에는 폰트, 이미지, 색상 프로필 같은 "리소스 객체"가 별도로 저장되고, 각 페이지는 이 리소스를 "참조"하는 방식으로 구성됩니다. 문서 전체에서 같은 폰트를 쓴다면 그 폰트 데이터는 파일 안에 딱 한 번만 저장되고, 모든 페이지가 같은 객체를 가리킵니다. 즉 페이지 수가 100장이어도 폰트 용량은 1번만 계산되는 구조입니다.
2. "귀속 문제"가 발생하는 지점
이 공유 구조 때문에 "페이지 5의 용량은 몇 바이트인가"라는 질문 자체가 모호해집니다. 예를 들어 문서 전체가 공유하는 폰트 파일이 500KB라고 할 때, 이 500KB를 페이지 5에 귀속시켜야 할까요, 아니면 그 폰트를 처음 쓴 페이지에만 귀속시켜야 할까요, 아니면 그 폰트를 쓰는 모든 페이지에 균등하게 나눠야 할까요? 어느 방식을 택해도 "정답"이라고 부를 근거가 없습니다. 이미지 하나가 여러 페이지에 반복 삽입된 경우도 마찬가지입니다. 그래서 pdf.js 같은 라이브러리는 애초에 "페이지별 바이트 크기"라는 값 자체를 제공하지 않습니다.
pdf.getPage(i)로 불러온 뒤 pg.getViewport({scale:1})로 뷰포트의 width·height(포인트 단위)만 읽습니다. 이 값을 mm로 환산해 A4·Letter 등 표준 용지 이름과 ±5mm 오차 안에서 매칭하고, 막대그래프는 이 폭(포인트) 값을 페이지 간에 상대 비교한 것입니다. 바이트 단위 크기는 어디에도 계산되지 않습니다.
3. "페이지별 크기" 막대그래프가 실제로 보여주는 것
화면에 나타나는 막대그래프는 각 페이지의 종이 폭(너비)을 기준으로 상대 길이를 그린 것뿐입니다. 폭이 넓은 페이지(가로 방향 페이지 등)일수록 막대가 길게 나타나지만, 이는 그 페이지에 이미지가 많이 들어있거나 용량이 크다는 뜻이 전혀 아닙니다. 텍스트만 있는 A4 페이지와 고해상도 사진이 가득한 A4 페이지는 물리적 치수가 같으므로 이 도구에서는 막대 길이도 동일하게 표시됩니다.
| 항목 | 실제로 계산되는 값 | 계산되지 않는 값 |
|---|---|---|
| 페이지별 크기 | 물리적 치수(포인트→mm 환산, 표준 용지명 매칭) | 바이트 단위 데이터 용량 |
| 막대그래프 길이 | 페이지 폭(포인트)의 상대 비교 | 해당 페이지의 이미지·폰트 사용량 |
4. 예시로 보는 오해
10페이지짜리 PDF 중 3페이지에만 고해상도 사진이 5장씩 들어있고 나머지는 순수 텍스트라고 가정하면, 실제 데이터 용량은 그 3페이지에 압도적으로 몰려 있을 가능성이 높습니다. 하지만 모든 페이지가 A4로 동일하다면, 이 도구의 "페이지별 크기" 막대그래프는 10개 페이지 모두 똑같은 길이로 표시됩니다. 즉 이 화면만 보고 "어느 페이지가 무거운지"를 판단하면 실제와 정반대의 결론에 이를 수 있습니다.
5. 실제 페이지별 용량이 필요하다면
이 도구는 파일이 서버에 업로드되지 않고 브라우저 안에서만 처리되는 대신, PDF.js가 안정적으로 제공하는 정보(치수)만 다룹니다. 페이지별 실제 바이트 용량까지 알고 싶다면 Acrobat 같은 전문 편집기의 "PDF 최적화" 리포트를 쓰거나, PDF 페이지 추출기로 페이지를 개별 파일로 분리한 뒤 각 파일 크기를 직접 비교하는 방법이 현재로선 가장 정확합니다. 전체 파일 용량 자체를 줄이는 것이 목적이라면 PDF 압축기를 바로 사용하는 편이 빠릅니다.
자주 묻는 질문
Q. 그러면 "페이지별 크기"라는 이름 자체가 오해의 소지가 있는 것 아닌가요?
그렇습니다. "크기"라는 단어가 한국어에서 데이터 용량과 물리적 치수 양쪽에 다 쓰이기 때문에 생기는 혼동입니다. 이 도구에서는 종이 크기(A4, Letter 등)를 의미하며, 화면 하단 FAQ와 SEO 설명에서도 이 점을 명시하고 있습니다.
Q. 다른 PDF 도구는 페이지별 바이트 용량을 보여주나요?
Adobe Acrobat 같은 데스크톱 전문 편집기는 문서를 재작성(rewrite)하는 최적화 과정에서 내부적으로 리소스를 페이지별로 재배치·계산하는 리포트 기능을 제공하기도 합니다. 다만 이 역시 공유 리소스를 어떤 기준으로 페이지에 배분할지는 도구마다 내부 알고리즘이 다르므로 절대적인 정답은 아닙니다.
Q. 파일 전체 용량이 큰 원인을 페이지 단위로 알 수 없다면 어떻게 줄여야 하나요?
페이지 단위 분석 없이도 이미지 압축률을 낮추거나 불필요한 폰트 임베딩을 제거하는 방식으로 전체 용량을 줄일 수 있습니다. PDF 압축 도구는 페이지별 귀속 계산 없이 문서 전체의 리소스를 일괄 재인코딩하는 방식으로 동작하므로 이 문제와 무관하게 사용할 수 있습니다.
Q. 작성일/수정일이 이상한 문자열로 나오는 것도 같은 맥락인가요?
별개의 이슈입니다. 이는 PDF 표준이 날짜를 D:20240115093000+09'00' 형식으로 저장하는데, 이 도구가 pdf.js의 원본 문자열을 그대로 표시할 뿐 사람이 읽기 쉬운 형태로 변환하는 코드가 없어서 발생합니다. 페이지 크기 이슈와는 원인이 다릅니다.