오늘 “Puppeteer PDF alternative”를 검색해서 여기까지 왔다면, 실제 질문은 아마 이런 형태일 겁니다.

“인보이스 하나 출력하려고 서버리스 함수가 왜 2초 동안 콜드 스타트를 하고 RAM을 900 MB나 쓰는 걸까?”

Puppeteer는 훌륭한 도구입니다. 하지만 많은 팀이 실제로 맡기는 일, 즉 구조화된 데이터를 예측 가능한 PDF로 바꾸는 작업에는 지나치게 무겁습니다. 이 글은 Puppeteer를 프로덕션에 넣기 직전, 더 합리적인 선택지가 있는지 조용히 따져보는 팀을 위한 비교입니다.

Puppeteer가 무게값을 하는 경우, 그렇지 않은 경우, 그리고 2026년에 실제 선택 기준표가 어떻게 보이는지 다룹니다.

Puppeteer로 실제 배포하는 것

npm install puppeteer를 실행하면 종속 패키지를 제외하고도 대략 170 MB Chromium 빌드를 내려받습니다. 실행 시점의 headless Chromium은 한 페이지 PDF 생성에 600–900 MB 상주 메모리가 필요하고, 브라우저를 띄우는 데 1–2초 콜드 스타트가 걸립니다. 각 PDF 생성은 다음 과정을 거칩니다.

브라우저 프로세스를 시작하거나 풀에서 재사용합니다.
새 탭을 엽니다.
HTML 또는 URL로 이동합니다.
domcontentloaded를 기다리고, 보통 폰트, 이미지, 웹 컴포넌트도 기다립니다.
page.pdf()를 실행해 그려진 페이지를 Chromium PDF 엔진으로 직렬화합니다.
탭을 닫습니다.

이것이 전체 웹 플랫폼을 끌고 오는 비용입니다. 문서가 SVG 차트가 박힌 90페이지 법무 계약서이든, 텍스트 다섯 줄짜리 한 페이지 배송 라벨이든 이 비용은 똑같이 붙습니다.

입력이 진짜로 CSS 레이아웃, JavaScript 기반 콘텐츠, 웹 폰트, 나머지 웹 플랫폼 기능을 필요로 하는 HTML-PDF 변환이라면 그 비용은 정당합니다. 그 밖의 인보이스, 배송 라벨, 영수증, 티켓, 명세서, 인증서라면 돈을 태우는 일에 가깝습니다.

Puppeteer가 이기는 곳

나중에 팀이 결정을 다시 의심하지 않게 하려면 먼저 이 부분을 솔직하게 봐야 합니다.

충실한 HTML/CSS 출력. 디자인 시스템이 HTML을 내보내고 그 HTML과 픽셀 단위로 같은 PDF가 필요하다면 Puppeteer는 이기기 어렵습니다. 사실상 Chrome으로 인쇄하는 것입니다.
웹 플랫폼 기능. 필터가 있는 SVG, CSS Grid의 까다로운 사례, 웹 컴포넌트, JavaScript로 평가되는 콘텐츠, 서드파티 iframe이 그대로 작동합니다.
시각적 디버깅. PDF 생성 중간에 스크린샷을 찍고, headless 모드에 DevTools를 붙여 엔진이 실제로 보는 화면을 확인할 수 있습니다.
변환 단계가 없습니다. 콘텐츠가 이미 웹페이지라면 스키마 매핑이 없습니다. page.goto(url); await page.pdf()가 전체 과정입니다.

이 항목 중 두 가지 이상이 실제 작업을 설명한다면 옮기지 마세요. Puppeteer가 맞는 답입니다.

Puppeteer가 크게 지는 곳

그 밖의 작업에서는 비용이 빠르게 쌓입니다.

서버리스 메모리와 콜드 스타트

Puppeteer를 실행하는 일반적인 Node 20 Lambda 또는 Cloudflare Container는 다음과 같습니다.

지표	일반적인 값
컨테이너 이미지 크기	250–400 MB (Chromium + Node + 사용자 코드)
콜드 스타트 시간	1.8–2.5초
1회 생성당 warm RAM	600–900 MB
1 GB 인스턴스당 동시 생성 수	1개(페이지가 아주 작으면 가끔 2개)

인보이스 서비스가 월 10만 회 PDF를 생성한다면, 그중 어느 것도 JavaScript 실행이 필요 없더라도 새 컨테이너가 뜰 때마다 브라우저 부팅 비용을 내는 셈입니다.

컨테이너 안 폰트 함정

Chromium에는 기본 폰트 세트가 포함되어 있지만, CJK, Cyrillic, Devanagari, Arabic 및 긴 꼬리의 문자별 글리프가 빠져 있는 경우가 많습니다. 프로덕션에서 이 문제는 보통 이렇게 드러납니다.

도쿄 사무소의 2025년 3분기 인보이스가 ▢▢▢▢ 2025年第3四半期로 출력됩니다. 고객이 문제를 에스컬레이션합니다. 팀은 Dockerfile 폰트 설치와 CSS 대체 폰트를 디버깅하느라 스프린트 하나를 씁니다.

NotoSans CJK만 넣어도 이미지에 약 50 MB가 추가됩니다. 전 세계 문자권을 위한 Noto 대체 폰트 세트를 넣으면 약 250 MB가 더 붙습니다. 일본어 인보이스 하나를 출력하기 위해 Chromium과 거대한 폰트 묶음을 함께 들고 다니는 셈입니다.

결정성

Puppeteer 출력은 Chromium 버전이 바뀌면 바이트 단위로 동일하지 않습니다. 패치 업그레이드만으로도 커닝, 폰트 기준선, 페이지 나누기 위치가 미묘하게 달라질 수 있습니다. PDF 차이를 비교하는 테스트 스위트가 있다면, 그리고 있어야 합니다, Chromium 업데이트마다 작은 발굴 작업을 하게 됩니다. 어떤 출력이 왜 바뀌었고 의도한 변화인지 확인해야 합니다.

PDF 생성 시점의 JavaScript

“정적” HTML 페이지도 파싱, 레이아웃 계산, 페인트, 직렬화를 거칩니다. warm 프로세스에서도 경험적으로 페이지당 80–400 ms가 걸립니다. 대부분은 페인트가 아니라 레이아웃입니다.

비교하면, JSON을 바이너리 PDF 생성 엔진에 바로 넘기는 서버는 같은 한 페이지 인보이스를 3–8 ms에 처리합니다. 이 수치는 아래에서 다시 보겠습니다.

gPdf가 맞는 곳

gPdf는 모델을 뒤집습니다. 문서를 HTML로 설명하고 브라우저에 그리게 하는 대신, 구조화된 JSON(DocumentRequest)으로 설명합니다. WebAssembly로 컴파일된 Rust 기반 PDF 생성 엔진이 PDF를 직접 발행합니다. 브라우저도, DOM도, JavaScript 레이아웃 단계도 없습니다.

이 방식은 제한적입니다. HTML 형태의 문제에는 그렇습니다. 하지만 인보이스 / 배송 라벨 / 영수증 / 명세서 / 인증서 계열 문서에는 JSON 우선 모델이 오히려 더 잘 맞습니다.

데이터가 이미 구조화되어 있습니다. 인보이스는 보통 어딘가에 { customer, lines, totals, taxes, notes } 객체로 존재합니다. 그것을 먼저 HTML로 만든 뒤, 브라우저가 다시 HTML을 레이아웃으로 읽게 만들 필요는 없습니다. 데이터에서 PDF로 바로 가는 편이 낫습니다.
레이아웃이 안정적인 인터페이스가 됩니다. font_size: 11이 항상 11포인트이고 gap: 8이 항상 8포인트라면, PR을 보는 두 엔지니어가 정확히 같은 출력을 봅니다. display: flex 해석 차이가 없습니다.
출력이 바이트 단위로 동일합니다. 같은 입력 → 같은 바이트입니다. 두 PDF를 git diff해도 실제로 바뀐 부분만 보입니다.
콜드 스타트는 브라우저 부팅이 아니라 실행 환경 시작 시간입니다. Cloudflare Workers의 V8 isolate는 5–20 ms에 초기화됩니다. 같은 isolate에서는 WASM 모듈이 메모리에 warm 상태로 남아 있습니다.

gPdf로 한 페이지 인보이스를 생성하면 보통 Edge에서 3–5 ms p50 wall-clock 안에 끝납니다. 사용자가 닿은 Cloudflare colo에서 바로 처리됩니다. Puppeteer의 warm 경로보다 약 두 자릿수 배 빠르고, cold 경로보다 세 자릿수 배 빠릅니다.

선택 기준표

기술 설계 리뷰에서 실제로 쓸 만한 표는 다음과 같습니다.

작업	Puppeteer 사용	gPdf 사용
기존 HTML 보고서 → PDF	✅ 1순위	⚠️ 재작성 필요
인보이스, 명세서, 영수증	⚠️ 너무 무거움	✅ 1순위
바코드가 있는 배송 라벨	❌ 피하는 편이 좋음(폰트 문제)	✅ 1순위
전자 인보이스(Factur-X / ZUGFeRD / EN 16931)	❌ 내장 지원 없음	✅ 내장
PDF/A 장기 보존	⚠️ Ghostscript 후처리 필요	✅ 내장 프로파일
픽셀 단위로 같은 디자인 시스템 목업	✅ 1순위	❌ 맞지 않는 도구
실제 D3 / Recharts가 필요한 차트	✅ 1순위	❌ 맞지 않는 도구
티켓, 인증서, 이름표	⚠️ 과한 선택	✅ 1순위
생성 시점 JavaScript가 필요한 모든 것	✅ 유일한 선택	❌ 맞지 않는 도구

오른쪽 열에 해당하는 줄이 세 개를 넘는다면, 절감 효과는 결코 작지 않습니다.

실제 비교: 한 페이지 인보이스 생성

같은 콘텐츠, 같은 용지 크기, 같은 폰트(NotoSans), 같은 PDF/A-3b 출력 프로파일입니다.

	Puppeteer(warm Lambda, 1 GB)	gPdf(warm Cloudflare Worker)
p50 지연 시간	180 ms	3.4 ms
p99 지연 시간	420 ms	8 ms
콜드 스타트 페널티	첫 생성 +1800 ms	첫 생성 +12 ms
최대 메모리	720 MB	18 MB
이미지 / 모듈 크기	280 MB	4.5 MB
CJK 글리프	❌ 명시적으로 설치해야 함	✅ NotoSans CJK 내장
10만 회 생성 비용	~$240(Lambda 컴퓨팅)	~$5(gPdf Basic 플랜)

마지막 줄은 많은 사람을 놀라게 합니다. 비용 차이는 실제이며, 낚시성 가격이 아니라 구조적인 차이입니다. Chromium 부팅, 브라우저 메모리, 컨테이너 콜드 스타트를 가격에 나눠 실을 필요가 없기 때문에 1회 생성 단가가 실제로 매우 작습니다.

“하지만 10만 페이지에 5달러는 너무 싸게 들립니다. 함정이 뭔가요?”

함정은 정확히 우리가 브라우저를 함께 배포하지 않는다는 점입니다. warm V8 isolate에서 바이너리 PDF 생성 엔진을 돌리는 비용은 ms 단위 CPU와 KB 단위 메모리입니다. 여기에 Puppeteer 형태의 가격을 붙이면, 운영하지도 않는 인프라 비용을 청구하는 셈입니다.

그래도 Puppeteer를 골라야 할 때

우리에게 물어봤을 때 항상 “gPdf를 쓰세요”라는 답이 나온다면 최악의 조언자일 것입니다. 실제로는 그렇지 않습니다. 정직한 경우는 다음과 같습니다.

이미 Puppeteer를 프로덕션에 배포했고 잘 작동합니다. 바꾸기 위해 바꾸지 마세요. gPdf를 평가할 적절한 시점은 Puppeteer가 아프기 시작할 때입니다. 보통 월 컴퓨팅 청구액이 400달러를 넘거나, 콜드 스타트 SLA가 하류 시스템을 깨뜨릴 때입니다.
문서가 말 그대로 기존 웹페이지입니다. 디자인 시스템으로 스타일링된 60페이지 사용자 생성 보고서에 중첩 차트와 동적 콘텐츠가 있다면, 그것은 JSON 전환이 아니라 재설계입니다.
웹 미리보기와 픽셀 단위 일치가 필요합니다. “편집기에서 보이는 그대로 출력” 같은 사용 방식은 양쪽 모두에서 Chromium을 PDF 생성 엔진으로 써야 하는 경우가 있습니다.

해당하지 않는다면 계산은 단순합니다. 더 작은 배포물, 더 낮은 지연 시간, 더 낮은 청구서, 바이트 단위로 동일한 출력, 그리고 폰트 설치 문제의 감소입니다.

실제 작업을 옮기는 방법

시도해 볼 만큼 설득되었다면, 전환은 보통 재설계가 아니라 문서 유형당 1~2일짜리 검증 작업입니다.

문서 하나를 고릅니다. 가장 복잡한 것이 아니라 가장 많이 생성되는 문서부터 시작하세요.
HTML 템플릿의 논리적 섹션을 gPdf JSON 요소(text, box, table, barcode, image)에 매핑합니다.
실제 DocumentRequest를 Playground에서 반복 조정해 출력이 맞을 때까지 확인합니다.
기존 데이터 형태를 받아 JSON을 발행하는 작은 매퍼 함수를 연결합니다.
새 엔드포인트를 Puppeteer 엔드포인트와 일주일 동안 A/B합니다. PDF 차이를 비교하고 결정합니다.

대부분의 팀은 하루 안에 JSON 모델이 감이 옵니다. 어려운 부분은 새 도구가 아니라, 오래된 템플릿이 시간이 지나며 쌓아 온 HTML/CSS 묘기를 풀어내는 일입니다.

TL;DR

Puppeteer는 웹페이지에는 맞는 답입니다. 문서에서는 문서를 데이터로 설명하는 한 번의 작은 비용을 피하려고 매번 100–200배 비용을 내고 있습니다. 인보이스, 배송 라벨, 영수증, 명세서, 티켓처럼 “형태는 항상 같고 값만 바뀌는” 문서를 생성하는 시스템이라면, gPdf 같은 Edge 기반 PDF 생성 엔진이 측정 가능한 수준으로 더 빠르고, 작고, 싸고, 더 결정적입니다.

Playground에서 직접 시도해 보세요. 실제 Edge Worker이고, 가입 없이 브라우저에서 5 ms 미만 응답을 확인할 수 있습니다.