결론부터 말씀드리면: PDF 폰트 서브셋화가 90%의 용량을 줄일 수 있는 근본 원인은, 중국어 폰트는 무려 15-20MB이지만 문서에서 실제로 사용되는 문자는 1-2천 개에 불과하기 때문입니다. 서브셋화의 핵심 원리는 세 단계입니다. 문서에서 실제로 사용된 문자 집합 스캔, CMap 매핑 테이블 재구축, 글리프 인덱스 재정렬 및 미사용 글리프 폐기. 어원 송체(Source Han Serif) 전체 파일이 18MB이지만 서브셋화 후에는 단 0.4MB로, 감소율은 97.7%입니다. 아래에서는 폰트 파일 구조부터 설명하고, 서브셋화의 기술 원리를 상세히 다루며, 세 가지 폰트의 실제 측정 비교 데이터를 첨부합니다.
PDF 압축의 전체 방법에 익숙하지 않으시다면, 먼저 PDF 압축 원리와 방법 상세 설명을 읽어보시길 권장합니다.
1. 폰트 파일 구조: 왜 중국어 임베디드 폰트가 그렇게 큰가
서브셋화가 왜 효과적인지 이해하려면 먼저 폰트 파일에 무엇이 들어 있는지 알아야 합니다. TrueType(.ttf)과 OpenType(.otf) 폰트 파일은 여러 데이터 테이블로 구성되며, 각 테이블은 서로 다른 기능을 담당합니다. PDF에 임베드할 때, 이 테이블들은 문서에서 몇 글자를 사용했는지에 관계없이 완전히 패키징됩니다.
| 데이터 테이블 | 기능 | 일반적인 비율 | 서브셋화 가능 여부 |
|---|---|---|---|
| cmap | 문자 인코딩에서 글리프 인덱스로의 매핑 | 1%–3% | 재구축 필요 |
| glyf | TrueType 글리프 윤곽 데이터 | 70%–85% | 크게 축소 가능 |
| CFF | OpenType CFF 글리프 윤곽(PostScript) | 60%–80% | 크게 축소 가능 |
| loca | 글리프 데이터 위치 인덱스 | 1%–2% | 재구축 필요 |
| hmtx | 수평 메트릭(글자 너비/전진량) | 2%–5% | 재구축 필요 |
| name | 폰트 이름, 저작권 등 메타 정보 | 0.5%–1% | 유지 |
| post | PostScript 이름 매핑 | 1%–3% | 부분 축소 |
위 표에서 볼 수 있듯이, 글리프 윤곽 데이터(glyf 테이블 또는 CFF 테이블)가 폰트 파일 용량의 60%–85%를 차지합니다. 중국어 폰트 하나는 2만~7만 개의 글리프를 포함하며, 각 한자의 벡터 윤곽 데이터는 평균 300–600바이트로, 합계 10–20MB입니다. 반면 50페이지 PDF 문서는 보통 800–2,000개의 서로 다른 문자만을 사용하므로, 95% 이상의 글리프 데이터가 낭비됩니다. 이것이 바로 서브셋화의 압축 공간이 있는 곳입니다.
2. 서브셋화 원리: 미사용 글리프를 폐기하는 세 단계
폰트 서브셋화의 핵심 아이디어는 문서에서 실제로 사용된 글리프만 유지하고 나머지는 폐기하는 것입니다. 구현 과정은 세 가지 핵심 단계로 나뉘며, 각 단계는 폰트 테이블 구조의 정밀한 작업을 포함합니다.
| 단계 | 작업 | 원리 | 처리되는 데이터 테이블 |
|---|---|---|---|
| 1. 문자 사용 스캔 | PDF의 모든 페이지 콘텐츠 스트림을 순회하여 표시된 문자 인코딩 추출 | 텍스트 연산자(Tj/TJ)를 구문 분석하여 Unicode 코드 포인트 수집 | 없음(문자 집합 생성) |
| 2. CMap 테이블 재구축 | 사용된 문자에 따라 인코딩에서 글리프 인덱스로의 매핑 재구축 | 사용된 문자의 매핑 항목만 유지, 나머지 삭제 | cmap |
| 3. 글리프 인덱스 리매핑 | 사용된 글리프를 연속적으로 재정렬하고 모든 참조 인덱스 업데이트 | 원본 인덱스는 불연속적일 수 있으며, 재정렬 후 0에서 N까지 연속 | glyf/CFF, loca, hmtx |
1) 문자 사용 스캔
첫 번째 단계는 PDF 문서를 스캔하여 실제로 표시된 모든 문자를 찾는 것입니다. PDF의 텍스트는 텍스트 연산자(Tj 표시 문자열, TJ 표시 배열)를 통해 콘텐츠 스트림에 기록되며, 각 문자는 하나의 인코딩에 해당합니다. 서브셋화 도구는 모든 페이지의 콘텐츠 스트림을 순회하여 이 인코딩을 추출한 다음, 폰트의 현재 CMap 테이블을 통해 Unicode 코드 포인트로 변환하여 최종적으로 "사용된 문자 집합"을 얻습니다.
스캔 시 특수 상황도 처리해야 합니다. ToUnicode CMap(역방향 매핑), 다바이트 인코딩(CJK 폰트에서 일반적), 임베디드 폰트의 서브셋화 접두사(여섯 문자 + 형식). 50페이지 중국어 PDF는 일반적으로 스캔 후 800–2,000개의 서로 다른 Unicode 문자가 추출되며, 구두점과 숫자를 더하면 유지해야 할 글리프는 총 1,000–2,500개 정도입니다.
2) CMap 테이블 재구축
CMap 테이블은 폰트의 "목차"이며, 각 문자 인코딩에 대응하는 글리프 인덱스(glyph ID)를 기록합니다. 원본 중국어 폰트의 CMap 테이블은 2만~7만 개의 매핑 항목을 포함하지만, 서브셋화 후에는 사용된 문자에 해당하는 항목만 유지됩니다. 재구축 시 다양한 인코딩 서브 테이블 형식도 처리해야 합니다.
| CMap 서브 테이블 형식 | 인코딩 범위 | 용도 | 서브셋화 처리 |
|---|---|---|---|
| Format 0 | 0–255 | 단일 바이트 ASCII/Latin | 미사용 항목 축소 |
| Format 4 | BMP 기본 평면 | 중일한 일반 문자 | 세그먼트 테이블 재구축 |
| Format 12 | 전체 Unicode | 모든 문자 커버 | 미사용 세그먼트 축소 |
3) 글리프 인덱스 리매핑
이것은 가장 핵심적이면서도 복잡한 단계입니다. 원본 폰트의 글리프 인덱스(GID)는 0에서 N까지 연속적으로 정렬되어 있지만, 유지해야 할 글리프는 여러 곳에 분산되어 있을 수 있습니다. 리매핑은 유지할 글리프를 새 순서로 연속 정렬하는 것입니다. 원본 GID 0(.notdef)은 변경되지 않고 유지되며, 원본 GID 1523은 새 GID 1이 되고, 원본 GID 8944는 새 GID 2가 되는 식입니다.
리매핑 후에는 GID를 참조하는 모든 테이블을 동기화하여 업데이트해야 합니다. glyf 테이블(또는 CFF 테이블)은 해당 글리프 데이터만 유지하고 새 인덱스 순서로 정렬, loca 테이블은 위치 인덱스 재구축, hmtx 테이블은 수평 메트릭 데이터 재구축, post 테이블은 PostScript 이름 매핑 업데이트. 이 단계를 잘못 처리하면 폰트가 손상되므로, OpenType 사양을 엄격히 준수해야 합니다.
3. 실측 데이터: 세 가지 폰트 서브셋화 전후 비교
저희는 세 가지 일반적인 폰트를 선정하여 서브셋화 실측을 진행했습니다. 각각 중국어 폰트(어원 송체, 마이크로소프트 야명)와 영어 폰트(Arial)를 대표합니다. 테스트 문서는 50페이지 중국어 입찰서이며, 사용 문자 수는 1,342개입니다.
| 폰트 | 원본 파일 | 글리프 수(원본) | 글리프 수(서브셋) | 서브셋화 후 | 감소율 |
|---|---|---|---|---|---|
| 어원 송체 Regular | 18.2MB | 65535 | 1342 | 0.42MB | 97.7% |
| 마이크로소프트 야명 Regular | 15.6MB | 28622 | 1342 | 0.35MB | 97.8% |
| Arial Regular | 0.82MB | 3257 | 96 | 0.06MB | 92.7% |
실측 데이터에 따르면, 중국어 폰트 서브셋화 효과가 가장 현저합니다. 어원 송체가 18.2MB에서 0.42MB로 감소하여 97.7%의 감소율을 보였습니다. 이는 중국어 폰트의 글리프가 많지만(6만 이상) 문서에서 사용되는 것은 적기(1천 이상) 때문에, 축소 공간이 막대하기 때문입니다. 영어 폰트 Arial의 원본은 단 0.82MB이며 서브셋화 후 0.06MB로, 감소율은 92.7%이며, 절대 용량은 작지만 비율 또한 상당합니다.
다시 어원 송체를 예로 들어, 다양한 문자 사용량에 따른 서브셋화 효과를 살펴보겠습니다.
| 문서 유형 | 사용 문자 수 | 서브셋화 후 용량 | 감소율 | 설명 |
|---|---|---|---|---|
| 단문 통지(1페이지) | 약 200 | 0.08MB | 99.6% | 문자 극히 적음, 서브셋 극소 |
| 회의 회의록(10페이지) | 약 600 | 0.19MB | 99.0% | 일상 사무 문서 |
| 입찰서(50페이지) | 약 1342 | 0.42MB | 97.7% | 전문 문서, 문자 커버리지 넓음 |
| 기술 매뉴얼(200페이지) | 약 2800 | 0.85MB | 95.3% | 문자 사용량 큼 |
| 백과사전(1000페이지) | 약 6500 | 1.92MB | 89.5% | 한계 커버리지에 근접 |
4. 서브셋화 도구 비교 및 시나리오 권장
폰트 서브셋화는 오픈 소스 명령행 도구부터 상용 압축 엔진까지 다양한 도구로 수행할 수 있으며, 각각 장단점이 있습니다. 아래 표는 주류 솔루션을 비교합니다.
| 도구 | 서브셋화 능력 | CFF 지원 | 배치 처리 | 통합 난이도 |
|---|---|---|---|---|
| SmartSlim | ★★★★★ | 예 | 지원 | SDK/API/데스크톱 |
| fonttools (Python) | ★★★★☆ | 예 | 스크립트 필요 | 중간 |
| Adobe Acrobat | ★★★★☆ | 예 | 제한적 | GUI 작업 |
| Ghostscript | ★★★☆☆ | 부분 | 지원 | 명령행 |
| 온라인 도구 | ★★☆☆☆ | 부분 | 지원 안 함 | 낮음(프라이버시 위험 있음) |
SmartSlim은 자체 개발한 Rust 압축 엔진을 기반으로, 서브셋화 시 TrueType과 OpenType CFF 두 가지 글리프 형식을 자동으로 처리하며, 수백 개의 PDF를 배치 드래그 처리할 수 있습니다. 더 중요한 것은, 서브셋화 전체 과정이 로컬에서 완료되어 폰트 데이터와 문서 내용이 어떠한 외부 서버도 거치지 않으며, 비밀 관련 문서와 기업 민감 파일에 특히 중요합니다.
다양한 시나리오의 서브셋화 전략 권장 사항:
| 시나리오 | 서브셋화 권장 여부 | 주의 사항 | 권장 도구 |
|---|---|---|---|
| 최종본 보관 배포 | 강력 권장 | 서브셋화 후 새로운 문자 편집 불가 | SmartSlim |
| 기업 배치 보관 | 강력 권장 | API 자동화로 배치 처리 | SmartSlim 서버 버전 |
| 온라인 게시/미리보기 | 권장 | 다운로드 용량 줄여 로딩 속도 향상 | fonttools 스크립트 |
| 여전히 편집이 필요한 초안 | 권장하지 않음 | 편집 가능하도록 완전 폰트 유지 | 서브셋화 보류 |
| 비밀 관련/기밀 문서 | 권장 | 반드시 로컬 처리, 온라인 도구 사용 금지 | SmartSlim |
더 많은 PDF 최적화 팁은 PDF 선형화 최적화 가이드와 Word 문서 압축 방법을 참조하시기 바랍니다.
5. 자주 묻는 질문 FAQ
Q1: PDF 폰트 서브셋화가 표시 효과에 영향을 주나요?
영향이 없습니다. 폰트 서브셋화는 문서에서 사용되지 않는 문자와 글리프 데이터만 폐기하며, 유지된 문자는 원본 폰트와 완전히 일치하여 표시 효과에 영향이 없습니다. 서브셋화 후에도 폰트는 여전히 벡터 윤곽이므로 확대 축소가 자유롭고, 색상, 굵기 등 속성도 유지됩니다. 유일한 제한은 서브셋화 후의 폰트가 해당 문서에서만 사용 가능하며, 다른 문서에서 재사용할 수 없다는 것입니다.
Q2: 폰트 서브셋화로 얼마나 용량을 줄일 수 있나요?
이는 문자 사용량과 원본 폰트 크기의 비율에 따라 다릅니다. 중국어 폰트(예: 어원 송체 18MB)는 보통 1,000-2,000개의 문자만 사용하며, 서브셋화 후 용량은 0.3-0.8MB로 감소하여 95% 이상 감소합니다. 영어 폰트(예: Arial 0.8MB)는 사용 문자가 더 적으며, 서브셋화 후 0.05-0.1MB로, 감소율은 약 90%입니다. 폰트가 클수록, 사용 문자가 적을수록, 서브셋화 효과가 더 현저합니다.
Q3: 서브셋화 후 PDF에서 여전히 텍스트를 편집할 수 있나요?
제한이 있습니다. 서브셋화는 문서에서 이미 사용된 문자만 유지하며, 편집 시 새 문자(원본 문서에 나타나지 않는 글자)를 입력하면 해당 문자가 표시되지 않고 사각형 또는 공백으로 표시됩니다. 따라서 서브셋화는 최종본 보관과 배포에 적합하며, 여전히 많은 편집이 필요한 문서에는 적합하지 않습니다. 편집이 필요한 경우 완전 폰트를 유지하거나 서브셋을 재임베드할 것을 권장합니다.
Q4: PDF가 이미 폰트 서브셋화되었는지 어떻게 확인하나요?
Adobe Acrobat으로 PDF를 열고, 파일-속성-폰트를 클릭하여 임베디드 폰트 목록을 확인합니다. 폰트 이름에 여섯 문자 접두사(예: ABCDEO+어원 송체)가 있으면 서브셋화된 것입니다. SmartSlim으로 PDF를 열어도 엔진이 폰트 임베드 상태를 자동으로 분석하고 서브셋화 필요 여부를 알리며, 예상 압축 용량을 제시합니다.
요약
PDF 폰트 서브셋화는 PDF 용량을 줄이는 가장 효과적인 수단 중 하나이며, 특히 중국어 폰트가 임베드된 문서에서 효과가 현저합니다. 핵심 원리는 세 단계 작업입니다. 사용 문자 스캔, CMap 매핑 테이블 재구축, 글리프 인덱스 재정렬 및 미사용 글리프 폐기. 실측 데이터에 따르면, 어원 송체 18MB가 서브셋화 후 단 0.4MB로, 감소율 97.7%이며, 표시 효과에 영향이 없습니다.
실제 작업 권장 사항: 최종본 배포 전에 반드시 폰트 서브셋화를 수행하고, 비밀 관련 문서는 로컬 도구로 처리하십시오. PDF 파일을 배치로 처리해야 할 경우, SmartSlim은 PDF/이미지/비디오/Office/OFD 등 10개 분야 40개 이상의 형식을 지원하며, 자체 개발한 Rust 압축 엔진을 기반으로 폰트 서브셋화를 자동 완료하고, 데이터가 외부로 나가지 않습니다.