PDF 안의 emoji는 예전에는 단순한 장식처럼 보였습니다. 이제는 그렇지 않습니다.

고객에게 전달되는 문서에서 emoji는 실제 정보를 담는 경우가 많습니다.

영수증에서는 ✅가 결제 완료, 🎁가 보상, ⭐가 평점, 🔥가 한정 혜택을 의미할 수 있습니다.
배송 알림에서는 📦, 🚚, 🙏가 빠른 상태 신호가 됩니다.
고객 지원 기록에는 WhatsApp, LINE, KakaoTalk, WeChat 메시지가 포함될 수 있고, emoji가 증거의 일부가 될 수 있습니다.
인증서, 쿠폰, 티켓, 멤버십 카드에서는 🏆, 🎓, 🎉, 💯가 디자인의 일부가 됩니다.

이 emoji가 사라지거나 빈 사각형으로 바뀌거나 PDF를 수백 KB씩 키우면 문서는 원본 내용을 충실히 반영하지 못합니다. 대량 생성 시스템에서는 제품, 저장소, 전송, 이메일, 아카이브, 때로는 컴플라이언스 문제가 됩니다.

“emoji 지원”은 단순한 체크박스가 아닙니다. PDF 생성기는 브라우저나 OS 폰트에 의존할 수 있고, 호출자에게 emoji 폰트 설정을 요구할 수 있으며, emoji를 이미지나 벡터 artwork로 바꾸거나 컬러 폰트 데이터를 임베드할 수도 있습니다. 모두 작동할 수 있지만 대가는 다릅니다.

현실적인 문제: 지원과 크기

컬러 emoji는 일반 흑백 glyph가 아니기 때문에 PDF에서 다루기 어렵습니다. PDF Association은 이 문제를 잘 설명합니다. OpenType 컬러 폰트에는 여러 경쟁 포맷이 있지만, 이 포맷들은 전통적인 outline font처럼 PDF에 단순하게 native로 들어가지 않습니다.

따라서 renderer는 표현 방식을 선택해야 합니다.

브라우저나 OS의 컬러 폰트를 사용;
컬러 emoji 폰트 데이터를 embed 또는 subset;
emoji를 이미지나 벡터 artwork로 변환;
또는 monochrome glyph, missing-glyph box, plain text로 fallback.

emoji가 한두 개라면 차이가 작을 수 있습니다. 하지만 emoji가 많은 영수증, 쿠폰, 채팅 내보내기, 지원 아카이브에서는 차이가 빠르게 커집니다.

작은 benchmark: 일반 emoji 50개

2026년 5월 20일, 동일한 한 페이지 A4 샘플로 local smoke test를 실행했습니다.

일반 텍스트만 있는 버전;
본문에 50개의 일반 emoji가 있는 버전;
Chrome 148 headless print-to-PDF;
동일한 50 emoji set을 사용한 gPdf local generation.

모든 문서나 모든 engine version에 대한 universal benchmark는 아닙니다. 많은 종류의 컬러 emoji가 들어갈 때 파일 크기가 어떻게 변하는지 보여주는 간단한 테스트입니다.

Renderer	Plain PDF	Same page with 50 emoji	Increase	Ratio
Chrome 148 print-to-PDF	31,250 bytes	435,630 bytes	+404,380 bytes	13.94x
gPdf local generation	8,766 bytes	43,466 bytes	+34,700 bytes	4.96x

Chrome 출력은 AppleColorEmoji Type 3 subset을 embed했습니다. emoji를 보이게 하는 유효한 방법이지만, 이 샘플에서 파일 크기 영향은 분명합니다.

gPdf 출력은 전체 컬러 emoji 폰트를 embed하지 않았습니다. emoji가 있는 버전이 텍스트 버전보다 큰 것은 당연합니다. 컬러 artwork는 어딘가에 표현되어야 합니다. 차이는 출력이 브라우저나 OS의 넓은 font path가 아니라 실제 문서에 사용된 emoji artwork에 따라 증가한다는 점입니다.

구매자가 물어야 할 질문은 “내 노트북에서 웃는 얼굴 하나가 보이나?”가 아닙니다.

실제 프로덕션 시스템에서 PDF를 생성할 때, 문서에 수십 개의 서로 다른 emoji가 있으면 어떻게 되는가?

다른 PDF 생성기는 emoji를 어떻게 처리하나

정직한 비교는 “다른 도구는 실패한다”가 아닙니다. 여러 성숙한 PDF 도구가 컬러 emoji를 지원합니다. 중요한 것은 어떻게 지원하며, 그것이 설정, 재현성, 출력 크기에 어떤 의미를 갖는가입니다.

Puppeteer, Chrome, Chromium 기반 API

Puppeteer는 Chrome의 PDF 출력 경로를 사용합니다. 문서는 page.pdf()를 print media type으로 페이지 PDF를 생성하는 API라고 설명하며, guide는 기본적으로 폰트 로드를 기다린다고 말합니다. 원본이 이미 웹 페이지라면 유용합니다.

emoji가 많은 구조화 문서에서는 출력이 브라우저와 폰트 환경에 의존하는 것이 tradeoff입니다. 로컬 샘플에서 Chrome은 emoji를 올바르게 표시했지만 파일은 31 KB에서 436 KB로 증가했습니다.

이것이 Puppeteer가 틀렸다는 뜻은 아닙니다. Puppeteer는 우선 브라우저 자동화 도구입니다. 기존 웹 페이지를 캡처하려면 적합합니다. 작고 반복 가능한 영수증, 라벨, 티켓, 명세서, 지원 기록을 만들려면 브라우저 경로가 무거울 수 있습니다.

DocRaptor와 Prince

DocRaptor는 Prince를 감싼 서비스이고, Prince는 강력한 HTML-to-PDF engine입니다. 입력이 실제 HTML/CSS이고 복잡한 paged media 기능이 필요하다면 좋은 선택입니다.

DocRaptor의 Pipeline 9 / Prince 14 발표는 컬러 emoji 지원을 명시합니다. Prince 14 release notes도 SVG-in-OpenType, CBLC/CBDT color emoji fonts, Apple sbix, emoji tag sequences 지원을 나열합니다. 따라서 올바른 주장은 “DocRaptor는 emoji를 렌더링하지 못한다”가 아닙니다.

더 정확한 경계는 이렇습니다. DocRaptor/Prince는 고품질 HTML-to-PDF 경로이고, gPdf는 structured JSON-to-PDF 경로입니다. 입력이 이미 데이터이고 emoji가 많은 구조화 문서라면, gPdf는 문제를 범용 HTML/CSS renderer로 밀어 넣지 않습니다.

PDFreactor

PDFreactor도 컬러 emoji를 지원합니다. manual은 컬러 emoji가 기본으로 사용되며 CBDT, SBIX, OpenType-SVG 같은 컬러 폰트 포맷을 지원한다고 설명합니다.

같은 manual은 제한도 말합니다. OpenType-SVG 사용 시 PDF 크기가 커지고, 해당 color-font path에서는 selection/copying이 없습니다. “emoji 지원”을 yes/no 기능으로 보기 전에 이해해야 할 tradeoff입니다.

iText와 pdfHTML

iText는 문서에 해당 characters를 그릴 수 있는 font program이 있으면 emoji를 생성할 수 있습니다. 공식 pdfHTML emoji guide는 emoji-capable font를 FontProvider에 추가한 뒤 conversion을 실행하는 방식을 보여줍니다.

SDK-level control이 필요한 팀에는 강력합니다. 하지만 폰트 설정, 테스트, 배포, 장기 유지보수는 애플리케이션 팀의 책임입니다.

coverage가 중요한 이유

잘못된 것을 테스트하기 쉽습니다. renderer가 😂를 보여준다고 해서 실제 사용자가 보내는 emoji를 처리한다는 뜻은 아닙니다.

현실의 emoji 사용에는 다음이 포함됩니다.

variation selectors;
skin-tone modifiers;
zero-width-joiner sequences;
국기와 tag sequences;
CJK, Arabic, Latin 등과 섞인 emoji;
오래된 PDF viewer와 enterprise document pipelines.

고객 문서에서 일관성은 제품의 일부입니다. 지원 transcript가 서버에 따라 다른 emoji를 보여서는 안 됩니다. 영수증이 macOS에서는 status mark를 보이고 Linux container에서는 box를 보여서도 안 됩니다. marketplace가 모든 merchant에게 같은 emoji font stack 설치를 요구해서도 안 됩니다.

gPdf의 입장은 단순합니다. generated PDFs에서 컬러 emoji는 고객에게 emoji 폰트 설치, browser runtime 조정, 큰 output file 수용을 요구하지 않고 작동해야 합니다.

emoji가 특히 중요한 문서

emoji-heavy PDF는 consumer marketing에만 있는 것이 아닙니다. 운영 시스템에서도 나타납니다.

문서 유형	왜 중요한가
영수증과 바우처	상태, 보상, 평점, 프로모션은 고객 경험의 일부입니다.
배송 및 예약 확인	confirmed, packed, shipped, delivered 상태를 빠르게 읽을 수 있습니다.
고객 지원 기록	chat export에서 emoji가 빠지면 tone과 evidence가 사라집니다.
커뮤니티와 소셜 아카이브	emoji는 대화의 일부입니다.
인증서와 achievement badges	트로피, 졸업, 축하 기호는 디자인 일부가 될 수 있습니다.
다국어 고객 PDF	emoji는 언어 경계를 넘어 status cue를 전달합니다.

그래서 파일 크기가 중요합니다. 한 번 400 KB 증가하는 것은 작아 보입니다. 월 100,000건의 영수증이라면 storage, bandwidth, email deliverability, mobile download time, archive cost가 됩니다. chat export 규모에서는 영향이 더 큽니다.

gPdf가 맞는 경우

gPdf는 완전한 브라우저가 되려 하지 않으며, 모든 HTML-to-PDF engine의 대체품도 아닙니다. source document가 임의의 웹 페이지, 복잡한 editorial layout, JavaScript chart가 있는 live dashboard라면 브라우저나 성숙한 HTML-to-PDF engine을 사용해야 합니다.

gPdf는 다른 경우를 위해 만들어졌습니다.

입력이 이미 structured data;
출력이 predictable해야 함;
시스템이 high volume으로 동작;
PDF가 compact해야 함;
같은 payload가 환경을 넘어 consistent output을 내야 함;
emoji, CJK, barcodes, PDF/A, metadata가 product requirements.

이 workload에서 emoji support는 조용히 작동해야 합니다. 상태, 감정, 고객 언어 cue를 문서에 넣기 위해 PDF generation이 폰트 설치 프로젝트가 되어서는 안 됩니다.

PDF vendor에게 물어볼 것

emoji 지원을 평가할 때 screenshot 이상을 요청하세요.

50개의 서로 다른 common emoji가 들어간 PDF를 generate할 수 있나요?
emoji가 있을 때와 없을 때 file size는 얼마인가요?
output이 operating-system fonts에 의존하나요?
customer가 emoji font를 install/register해야 하나요?
ZWJ sequences, flags, variation selectors는 어떻게 되나요?
runtime upgrade 이후 output이 stable한가요?
emoji behavior가 documented되어 있나요, 아니면 host environment의 side effect인가요?

답변은 emoji support가 진짜 product capability인지, runtime의 accidental result인지 보여줍니다.

PDF의 컬러 emoji: 지원 범위, 파일 크기, 실무 가치